On Jan 7, 2008 2:11 PM, Bill Nottingham <email@example.com> wrote:
> John Poelstra (firstname.lastname@example.org) said:
> > Okay, maybe that is too "corporate speak"
> > Up until now the rationale I've seen has mostly been "we should do this
> > because Fedora should do all of its own stuff" or "if we had a separate
> > instance everything would be better". So far I haven't found any of these
> > arguments to be compelling enough in the face of the disruption it would
> > cause to Fedora and Red Hat.
> > Would we be creating more new problems than we are solving?
> - ease of incorporating new upstream versions
> - with those versions, easier to move bugs and link them to other
> upstream bug trackers
> - able to wipe out old bugs
RH bugzilla needs to do all these things too, even if RHEL Engineering
doesn't realize it yet. I'd suggest that convincing RH of this,
instead of just breaking away, is one of those ways that Fedora can
help ensure (or ideally increase) RH's continued investment in Fedora.
> - removal of various non-upstream 'features' that RH uses that Fedora
> doesn't need
I agree that it would be hard to get this without splitting, and that
Bugzilla is cluttered enough as-is, but given the other benefits of
staying upstream, I'd suggest that greasemonkey or a server-side
'fedora view' which hide these extra features are better ways to solve
> - RH developers no longer have one-stop shopping
> - would need RH changes to support moving bugs to RH bugzilla
> - would need to run our own instance
- RHEL should view Fedora as an integral part of the RHEL development
and QA process. Fedora should be doing everything it can to encourage
that belief, so that more RHEL QA happens in Fedora, rather than in
RHEL. Going in the opposite direction by making this harder is cutting
off your nose to spite your face.
> - would wipe out old bugs
Wiping out old bugs is a good thing; on balance, unless you have
*bazillions* of testers, most old bugs cost more time to regularly
test/recheck/update/etc. than they are worth.
fedora-advisory-board mailing list