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 Salkeldasalkeld@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?)
#!/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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/matahari