new RPM version and Feature process (was: Re: Heads-up: brand new RPM version about to hit rawhide)

[Callum Lerwick]

2008/7/10 Jesse Keating <jkeating at redhat.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
> individually?

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
criteria:

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
clarified.