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.