new RPM version and Feature process (was: Heads-up: brand new RPM version about to hit rawhide)
2008/7/10 Jesse Keating <email@example.com>:
> On Wed, 2008-07-09 at 20:41 -0500, Callum Lerwick wrote:
>> Am I wrong?
> Yes. As previously stated the feature pages are way more than just
> marketing fluff. Features have very real schedule impact, just consider
> this time around, RPM with a bunch of new features, and a new gcc coming
> at some point soon. Usually we want to rebuild for both of those.
> Without some high level coordination, how do we schedule so that we
> rebuild once for all of the right reasons instead of multiple times
Okay yes, I'm seeing the need for Release Engineering to keep tabs on
invasive and risky changes. But I think we need to keep in mind that
this and marketing are two similar but orthogonal problems, that
happen to have a very similar solution. Thus we end up with two
1) The feature process is voluntary and optional.
2) Unless Release Engineering (not FESCo) deems a change is invasive
enough to threaten the release schedule.
Two problems, who's solution currently seems to be somewhat
indistinctly mashed together in one process. Perhaps this should be
fedora-devel-list mailing list