Im not opposed to any of it as long as the administrative work is not
adding unnecessary load on developers. But, if we have to vote I vote
for 3 just because im used to bugzilla.
( adam stokes ) || ( adam.stokes(a)gmail.com )
On Tue, Jul 5, 2011 at 10:31 AM, Perry Myers <pmyers(a)redhat.com> wrote:
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