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