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