On 07/05/2011 10:16 AM, Perry Myers wrote:
On 07/05/2011 06:57 AM, Angus Salkeld wrote:
On Tue, Jul 05, 2011 at 01:35:41PM +1000, Andrew Beekhof wrote:
On Tue, Jul 5, 2011 at 11:18 AM, Angus Salkeldasalkeld@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 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?)
Interesting. Did you write that?
Yip, "man bugzilla" + http://develop.github.com/p/issues.html + google "python json"
Neat script...
fwiw, I still prefer sticking to bugzilla, but would like folks on the team to come to some sort of consensus so we can proceed forward.
beekhof, stokes, zaneb, russellb, what do you guys want to do?
Options are:
- github issues w/ sync script
- Community->Matahari with components broken out by functional area
- Community->Matahari with a single component (matahari)
Let's vote and proceed forward with one of these
If my vote matters (and it probably shouldn't since I don't do any coding), I say option 3.