We've set up a bugzilla project for matahari on bugzilla.redhat.com site under the 'Community Classification'.

The plan is to use this for tracking distro independent bugs as well as project features, etc. Fedora bugzilla would then only be used for Fedora specific bugs, and we can easily mirror between Red Hat RHEL bugzilla, Fedora and the project. 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

But this seems not quite so useful For upstream projects (see the Corosync Cluster Engine for example), the components of a project are broken down into functional areas rather than SRPM/RPMs. Given that packaging is inherently a distro specific thing, I think it makes sense to map to functional areas. So the question is, what functional areas do we want to create as components for our project? core libraries host agent net agent services agent config agent (well, after we decide on the naming here) dbus transport qmf transport Thoughts? Perry _______________________________________________ Matahari mailing list Matahari(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/matahari

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).

> 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?

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.

Perry

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?)

#!/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

On Tue, Jul 05, 2011 at 01:35:41PM +1000, Andrew Beekhof wrote: > 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? Yip, "man bugzilla" + http://develop.github.com/p/issues.html + google "python json"

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 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? >> >> 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: > 1) github issues w/ sync script > 2) Community->Matahari with components broken out by functional area > 3) 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. _______________________________________________ Matahari mailing list Matahari(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/matahari

On Tue, Jul 5, 2011 at 10:16 AM, Perry Myers<pmyers(a)redhat.com> wrote: > > beekhof, stokes, zaneb, russellb, what do you guys want to do? > > Options are: > 1) github issues w/ sync script > 2) Community->Matahari with components broken out by functional area > 3) Community->Matahari with a single component (matahari) My vote is #2. I don't imagine that it's much more work than #3 and could prove valuable at some point in the future if we want to do some data mining on issue history. If there's something about bugzilla that makes #2 a sizable amount more work for some reason, #3 is fine too.

I've been down the road of #1 before and it was not pretty at all. It didn't scale well. I wrote a script similar to this one (2 different issue tracking systems, though). It started out simple, but it got really messy. The most significant problem I hit over time was keeping the two different systems in sync. I eventually got everything moved back into one system, eliminated the need for the script, and life got much better.

On 6/07/11 6:08 AM, Perry Myers wrote: > On 07/05/2011 03:39 PM, Russell Bryant wrote: >> On Tue, Jul 5, 2011 at 10:16 AM, Perry Myers<pmyers(a)redhat.com> wrote: >>> >>> beekhof, stokes, zaneb, russellb, what do you guys want to do? >>> >>> Options are: >>> 1) github issues w/ sync script >>> 2) Community->Matahari with components broken out by functional area >>> 3) Community->Matahari with a single component (matahari) >> >> My vote is #2. I don't imagine that it's much more work than #3 and >> could prove valuable at some point in the future if we want to do some >> data mining on issue history. If there's something about bugzilla >> that makes #2 a sizable amount more work for some reason, #3 is fine >> too. Also agree on #2

(btw. is this coming out as plain text? hard to tell with the new thunderbird)

On Wed, Jul 6, 2011 at 3:38 AM, Zane Bitter<zbitter(a)redhat.com> wrote: > Since the consensus seems to be that it's between #2& #3, I'll cast my vote > for #3. Everybody always thinks that one day they'll do data mining. Nobody > ever does. In the meantime it's just a bunch of extra work (that tends to > grow over time as people think of new things they might one day want to data > mine). This is not a big project. If we are going to have multiple > components I'd limit it to 2: > > * matahari core > * matahari agents meh ... at that point I think we might as well just use 1 component. I say we call it resolved with using bugzilla with 1 component and then get back to our regularly scheduled programming. :-)

matahari component is now present in the matahari project under the community classification in bugzilla

https://bugzilla.redhat.com/page.cgi?id=browse.html&tab=&product=... A link like above o.k. to use?