On 11/01/2012 07:08 PM, Adam Williamson wrote:
On Thu, 2012-11-01 at 09:56 -0400, Matthew Miller wrote:
On Thu, Nov 01, 2012 at 09:24:52AM +0200, Panu Matilainen wrote:
There are features and features... some of them are new versions of
leafnode packages or a just bunch of new packages which nothing else
depends on, and some of them affect *everything* in the distro.
Perhaps the invasive changes should have a considerably earlier
deadline, and if the deadline is not met then the feature would be
"automatically" postponed to next release.

Right now, the Feature template has this sections:

   == Scope ==
   <!-- What work do the developers have to accomplish to complete the feature
   in time for release?  Is it a large change affecting many parts of the
   distribution or is it a very isolated change? What are those changes?-->

Maybe the explanation could be strengthened, and some "checkbox" options
added:

Choose one of:

  ☐ "This is a "leaf" feature adding new, stand-alone functionality.

  ☐ This feature brings new functionality which changes the default user
    experience for many users.

  ☐ This feature introduces changes which affect the user experience only in
    its own area.

To make things clearer I think you could drop 'brings new functionality
which' from the second checkbox. The key thing we're trying to isolate
is whether the feature has implications for 'normal' usage; it doesn't
matter whether it's introducing new functionality.

I was rather thinking we can simply take advantage of the critical path
definition here. After all, when we came up with the critpath, the idea
was it was a general concept which could be useful beyond the idea of a
'critpath package'. So why don't we just introduce the concept of a
'critpath feature' - any feature with implications for the critical
path?

Nod. The critical path package set would serve at least as a point for refining the feature process. What the actual implications of critpath feature would be, Debian-style earlier freeze and/or something else, is probably a whole another (no doubt lengthy) topic :)

        - Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Reply via email to