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
Cheers,
Perry