On Fri, 2005-07-22 at 09:24 -0400, Luis Villa wrote: > > (2) Obviously the distros want to include an incredibly minimal set > of patches in their maintenance releases. But those releases also lag > anywhere between months and years behind HEAD. Better collaborative > 'enterprise' management of the stable branch after .1/.2 but *before* > the enterprise releases would help everyone quite a bit, I think, and > not jeopardize anyone's post-release patch management strategy.
Our current model is: - keep the latest HEAD GNOME in Fedora, do all development on HEAD - eventually ship a RHEL based on that - once RHEL is out, we can only fix bugs that a customer asks for, or that are really bad, or security; we can't roll forward to any version that has bugfixes we can't prove a customer cares about, even if all the fixes are perfectly sane. This rule is becoming stronger rather than weaker over the last couple years... The only time we need to do much backporting these days is in the gap between Fedora and the final RHEL shipment. i.e. if we ship a Fedora and then branch RHEL and freeze it for a multi-month beta, there's time for a moderate number of backported patches to build up. But this is a once-per-2-years event. I think you might be suggesting that this gap is where we should be doing more upstream-based work. That may be true, but you'd only see Red Hat involved in that every 3rd or 4th GNOME release, since the rest of the time we're either backporting very small patches to already-released RHEL (this is something like a dozen patches per quarter, perhaps, and to totally fossilized GNOME versions) or working on HEAD in Fedora. Havoc _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list