On Tue, Jul 5, 2011 at 11:18 AM, Angus Salkeld
<asalkeld(a)redhat.com> wrote:
> On Mon, Jul 04, 2011 at 04:48:42PM -0700, Steven Dake wrote:
>> On 07/03/2011 08:31 AM, Perry Myers wrote:
>> > On 07/03/2011 10:20 AM, Russell Bryant wrote:
>> >> On Sat, Jul 2, 2011 at 11:27 PM, Angus
Salkeld<asalkeld(a)redhat.com>
>> >> wrote:
>> >>> On Sat, Jul 02, 2011 at 11:03:05AM -0400, Perry Myers wrote:
>> >>>> We've set up a bugzilla project for matahari on
bugzilla.redhat.com
>> >>>> site
>> >>>> under the 'Community Classification'.
>> >>>
>> >>> What about using github "issues" they are nice and
lightweight. And the
>> >>> project is then hosted in one place.
>> >>
>> >> That crossed my mind, too. I figured it was just a matter of wanting
>> >> to centralize issue tracking with other Red Hat sponsored projects.
>> >> If github is an option, that gets my vote (as long as github issues
>> >> doesn't suck, I haven't used that github feature yet).
>> >
>> > The main benefit of going with bugzilla is easy cloning of issues from
>> > downstream to up and vice versa (easy to move bugs between Fedora/RHEL
>> > and the project itself)
>> >
>> > I'm not opposed to using github, but if we do that we'll need to
>> > manually copy RFEs/bugs that we want to track upstream after they're
>> > created downstream. If someone is willing to maintain that, I'm fine
>> > with using a different tracking system.
>> >
>> > Also, re:
>> >>> What we need to do is define what 'components' we want to
create under
>> >>> the Matahari project. In other places (Fedora, RHEL) a component
maps
>> >>> to an SRPM, so from that perspective we'd only have two
components in
>> >>> the matahari project: matahari and mingw32-matahari
>> >> Why? matahari is not exaclty a big project, isn't this just
>> >> making more work when managing bugs?
>> >
>> > I'm also fine with a single component for bugzilla as well. We'll
see
>> > what the other folks working on the project think.
>> >
>> > Steve recently went through this process for Corosync, so I'd be
>> > interested in his thoughts/rationale here.
>> >
>>
>> I wasn't totally convinced one component would trigger the bugzilla
>> admin to create a separate bugtracking for me. Also when I submitted I
>> broke things down into 6 categories (sam, confdb, cpg, quorum, totem,
>> unknown) which are all separate systems.
>>
>> The reason I went with corosync bugzilla hosted at redhat is because
>> nearly every one of our upstream bugs turns into a clone into 2 separate
>> products. This is really about making my life easier as a maintainer.
>> We could have used github tracking or some other tool, but then I'd just
>> have to copy the bug which IMO is a waste of time and creates two sets
>> of issue tracking.
>>
>> We were using rawhide as our "version" previously which is not the
>> purpose of rawhide. Rawhide is for distro specific issues, corosync
>> bugzilla for corosync specific issues.
>
> Cloning from github issues to bugzilla seems easy to me:
> (not sure what the fuss is about?)
Interesting. Did you write that?
>
> #!/usr/bin/env python
>
> import simplejson
> import urllib
>
> if __name__ == '__main__':
> issue_url =
'http://github.com/api/v2/json/issues/show/asalkeld/libqb/%s' % ('1')
> comment_url =
'http://github.com/api/v2/json/issues/comments/asalkeld/libqb/%s' % ('1')
>
> issue_env = simplejson.load(urllib.urlopen(issue_url))
> issue = issue_env['issue']
> comments_env = simplejson.load(urllib.urlopen(comment_url))
> comments = comments_env['comments']
>
> text = issue['body']
> for c in comments:
> text += '\n------------------------'
> text += '\nComment by: %s (at %s)\n%s' % (c['user'],
c['created_at'], c['body'])
>
> cmd = "bugzilla --product='Fedora' --version='15'
--component='libqb' \
> --url=%s --comment=\"%s\" --summary=\"%s\"" %
(issue['html_url'], text, issue['title'])
>
> print cmd
>
>
>>
>> Regards
>> -steve
>>
>> > Perry
>>
>> _______________________________________________
>> Matahari mailing list
>> Matahari(a)lists.fedorahosted.org
>>
https://fedorahosted.org/mailman/listinfo/matahari
> _______________________________________________
> Matahari mailing list
> Matahari(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/matahari
>
_______________________________________________
Matahari mailing list
Matahari(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/matahari