{{admon/note | This page is currently OPEN for suggestions on fixing the Feature Process. Comments will close, at least temporarily, on '''June 15, 2011,''' so that the list can be assessed and we can move on to next steps.}}

+

{{admon/note | This page is currently OPEN for suggestions on fixing the Feature Process. Comments will close, at least temporarily, on June 15, 2011, so that feedback can be assessed and we can move on to next steps.}}

* We really have multiple goals with features and the requirements for them should be different: --[[User:Toshio|abadger1999]] 19:26, 1 June 2011 (UTC)

+

** Features that require package maintainers to coordinate with each other (NetworkManager updates, systemd, programing language updates) --[[User:Toshio|abadger1999]] 19:26, 1 June 2011 (UTC)

+

** Features that we want release noted and to hit marketing (new version of blender/inkscape/other self-contained app) --[[User:Toshio|abadger1999]] 19:26, 1 June 2011 (UTC)

+

** Some features have some degree of cross-over (gnome3, kde4 for instance) as they're both major end user changes and require coordination with others --[[User:Toshio|abadger1999]] 19:26, 1 June 2011 (UTC)

+

* Features that fall into the first category (requiring maintainers to coordinate with each other) arriving late in the cycle but being approved either as (1) part of another feature or (2) because we don't consider the burden it might place on other maintainers. --[[User:Toshio|abadger1999]] 19:26, 1 June 2011 (UTC)

+

* I agree, there are two major groups. Imho it's leaf packages, which can't broke other packages, and critical packages that can. I would create two categories. First one would be things like Aeolus, only release notes & marketing. It's nice to have it in Fedora, but they are leaf packages and Fesco doesn't have to control them. The second group should be critical things - interpreters like Python, init - systemd. There should be rules 'what to check' before adding them or replace as default. Fesco should work with feature owners, control list of (tracking) bugs and problems. In case critical feature would broke other packages, it should be taken back and Contingency plan from feature page should be used. [[User:mmaslano]] 19:36, 3 June 2011 (GMT)

+

** Along this dimension, I think there are actually three separate groups:

+

*** relnote-only features (new functionality, new packages)

+

*** SIG-scope features (doesn't affect anything outside packages maintained by a specific SIG; may need coordination within a SIG): FESCo could fairly often delegate the technical details to the SIG (or the SIG and FPC), and treat the feature almost as relnote-only

+

*** distribution-wide features

+

** --[[User:Mitr|Mitr]] 20:31, 6 February 2012 (UTC)

+

* The feature process isn't necessarily mandatory at this point, and I personally think that it's a flaw. Major features *should* be required to go through the features process, not only from a technical governance and integration standpoint, but in an effort to help with documentation and marketing. [[User:Jsmith|Jsmith]] 16:02, 6 June 2011 (UTC)

+

** I was pondering if we can actually enforce people to go through the feature process. Enforcing something means that if they don't something will happen. So what could happen if someone makes a big change without going through the feature process? People who are making features are mostly people already quite involved in Fedora and who should understand the burden of late rebuild/late update as regard to dependency management or broken path/package (I have in mind the /root-selinux example of miss-coordination). --[[User:Pingou|Pingou]] 06:40, 7 June 2011 (UTC)

+

+

* Maintainers are still unclear about what the various milestones/dates mean for them. At Feature Freeze/Alpha/Beta/etc, what do I have to have done and what can still be left for later? --[[User:Toshio|abadger1999]] 20:08, 6 June 2011 (UTC)

+

** FESCo also tends to err on the side of letting late features through rather than keeping them out (which is not always bad). Some of this could be helped by separating the types of Features and having an understanding that things for documentation have one due date (needing to be sure it's in so that release notes and translations of release notes can be finalized) while things requiring coordination need a much earlier (or sequence of much earlier) deliverable date so that coordination and fixing of dependent packages can happen. --[[User:Toshio|abadger1999]] 20:08, 6 June 2011 (UTC)

+

* Awesome new version of (insert your favorite desktop app here) came out the week after a new Fedora release. Waiting 6 months for it sucks. Or, similarly, maybe you're really into a particular app (Firefox, Gimp, Inkscape, etc.) and want to track the upstream devel version rather than the stable version. The current feature process doesn't (or so I've been given this as an excuse) leave much room for a major app update to be applied in a given release after GA. Even if it's just a 'leaf' app and doesn't involve the core OS. Since one of our major principles is 'first' it seems like a worthy problem to solve. (Yes, Fedora People repos can solve this to some extent but are limited.) --[[User:Duffy|Duffy]] 01:46, 7 June 2011 (UTC)

+

* Features are routinely approved where the release notes or other sections have been filled very poorly and just to have something in the template. See the recently approved btrfs feature release notes for a good example. Feature wrangler should push back and not nominate any features to FESCo till developers make a more serious attempt to document the feature properly. I bought this up in devel list before this feature was even accepted but it seems to have made no difference. This makes life difficult for people writing release notes or release announcements --[[User:sundaram|Rahul Sundaram ]] 17:45, 13 June 2011 (IST)

+

* Who does the work? Should the Feature Proposer have already lined up the necessary work to make the changes or is the expectation that FESCo approved Features must be done by the package owners? --[[User:Toshio|abadger1999]] 19:03, 14 November 2011 (UTC)

+

** For features that are somewhat optional to implement (for instance, moving files to a different location when backwards compatible symlinks exist or changing the initscripts from one format (that is supported for backwards compat) to a different one that works better), the above becomes even more pertinant as a feature that doesn't have any workers can be approved but nothing might be done with it.--[[User:Toshio|abadger1999]] 19:03, 14 November 2011 (UTC)

+

* With Features that, if not implemented, do not break the system it is unclear who needs to do the work (as noted above), when the Feature can be considered done, and what to do with the Feature if it isn't "done". An example would be a feature that specifies moving files to a different directory in packages (certs moving to /etc/pki/ for instance). If 40 out of 80 packages change, should the Feature be documented? Should it be discarded and brought back up for the next release? The release in which it reaches 100% of the packages? --[[User:Toshio|abadger1999]] 19:03, 14 November 2011 (UTC)

+

** The kernel rule is "if you change the API, you fix all users", and I think that's a good approach most of the time. However, perhaps this should be applied to a smaller set of packages (... which is difficult to define - perhaps "the default DVD + everything necessary to build it"?) - i.e. it would be the feature owner's responsibility to make sure this set of packages is covered, and packages outside of this set are primarily the responsibility of their maintainers. --[[User:Mitr|Mitr]] 20:35, 6 February 2012 (UTC)

+

** The definition of testable is unclear so package maintainers, this years fesco, next year's fesco, etc have different ideas of how complete a feature must be by the milestones in the schedule.

+

* From time to time, features in effect define new distribution-wide policies, and these are often not recorded anywhere outside of the feature. --[[User:Mitr|Mitr]] 20:04, 17 July 2012 (UTC)

=== Things that work ===

=== Things that work ===

Do you think that some particular things work *well* in the Feature process? List them here -- the goal should be to fix the things that are broken, and keep the things that work well.

Do you think that some particular things work *well* in the Feature process? List them here -- the goal should be to fix the things that are broken, and keep the things that work well.

* Paul Frields expressed profound satisfaction with the feature process helping to get proper press attention to features Fedora wanted to highlight in a release --[[User:Toshio|abadger1999]] 19:27, 1 June 2011 (UTC)

* NetworkManager update in F15 arrived after the Feature process was closed to new features and left us scrambling and we weren't able to fix Sugar by release time. --[[User:Toshio|abadger1999]] 19:30, 1 June 2011 (UTC)

+

** And while KDE Plasma was "fixed" by release time, the hack which shipped (a parallel API for the whole NetworkManager) caused a lot of a support mess for the entire distro (NM updates would keep fixing one API, but breaking the other, hitting both KDE and non-KDE users in alternation) and in the end broke down entirely (forcing us to rush out the native NM 0.9 version of kde-plasma-networkmanagement as an update before it was ready, causing a few regressions which took time to fix). At the time Fedora 15 shipped, it was not clear at all how the upgrade path would work out (the compatibility API only supported the exact feature set of the kde-plasma-networkmanagement snapshot it was developed for, new features in newer upstream snapshots did not work (and we were depending on rebases to fix bugs), and when native NM 0.9 support would be ready was entirely unknown at that time, as was whether migration to it would work well enough to go out as an update). It actually worked out surprisingly well, but it was not without bumps, and it could easily have been worse. --[[User:Kkofler|Kkofler]] 01:06, 9 February 2012 (UTC)

+

* Python2.7 upgrade in F14 -- the feature was accepted on time but the rebuilds to implement the feature happened late, leaving us with modules that had to be fixed in order to work very late (sometimes too late) in the cycle --[[User:Toshio|abadger1999]] 19:30, 1 June 2011 (UTC)

+

* Boost upgrade in F14 -- the feature was accepted on time, but the ABI changing upgrade landed roughly at the same time as Python2.7, right before branching. There should be some coordination as to when major rebuilds should happen during each cycle. --[[User:Kalev|Kalev]] 19:39, 22 June 2011 (UTC)

+

* NetworkManager brought lot of unplanned work for KDE team. Also changing /run into root added work to selinux team. Such change wasn't discussed with selinux maintainers before, so they couldn't prepare it and co-operate on changes. Both updates of /run and new selinux rules should go out in one update. [[User:mmaslano]] 19:21, 3 June 2011 (GMT)

+

* The [[Features/RemoveSETUID| Remove SetUID feature]] says it reached 100% and is in Fedora 15 but Fedora 15 is not even close to having this feature implemented. (There's still many applications that are setuid and there are no packaging guidelines for using file capabilities instead of setuid).

+

* As noted by Tore Anderson in [https://bugzilla.redhat.com/show_bug.cgi?id=538499 Bug #538499], Fedora 12 advertised IPv6 support in NetworkManager, but it simply didn't work. Yet it was 100% at the time of release. It seems to me that if something is a Fedora Feature, it should be a release blocker if it doesn't work. [[User:Sschmit|Sschmit]] 03:40, 23 June 2011 (UTC)

+

* Take a look at [https://fedoraproject.org/wiki/Releases/15/FeatureList the Fedora 15 feature list]. "Consistent Network Device Naming" is still at 90%. Fedora 15 is released. How is that possible? [[User:Sschmit|Sschmit]] 03:40, 23 June 2011 (UTC)

+

* UsrMove for F17. As the feature developed it involved more people (rpm, releng for builder updates, anaconda) but the feature page didn't reflect them and those groups were not informed that they would be needed to do work until the last minute; leading to conflicts. --[[User:Toshio|abadger1999]] 18:59, 8 February 2012 (UTC)

* Split the process -- a set of criteria and due dates for features that need external marketing and a different set of criteria and due dates for features that need internal coordination. Probably give different names to each of these to avoid confusion. Initially, FESCo and the Feature Wrangler may need to tell people that their feature was submitted to the wrong group, point out the relevant criteria, and help the feature owner move them. --[[User:Toshio|abadger1999]] 20:16, 6 June 2011 (UTC)

+

* Different expectations around who does the work depending on when a coordination requiring feature is publicized. For instance, if you introduce API changes in the first stage of release creation, the dependent packages have primary responsibility for fixing their packages. If you introduce API changes later than that, the package maintainers introducing the API changes have primary responsibility for fixing the dependent packages. --[[User:Toshio|abadger1999]] 20:16, 6 June 2011 (UTC)

+

* Please treat features involving the core OS differently than features involving 'leaf' items. Too harsh requirements on things that don't need it are bad, too lax policies on things that really should have stricter requirements are bad - seeing examples of each above on this page. --[[User:Duffy|Duffy]] 01:39, 7 June 2011 (UTC)

+

* It would be cool to track newly-packaged apps from a marketing point-of-view. Many times new and interesting packages are added with a new version of Fedora, yet there is no marketing around their inclusion. For example, 10 new fonts in this release, this new app is packaged, etc. And none of these are things that the release should be held up for; more that I think it would help give our marketing materials more heft and generate more interest in new releases. --[[User:Duffy|Duffy]] 01:39, 7 June 2011 (UTC)

+

* Would it be possible to add arrays: requirements and dependencies? Nice example is btrfs. It needs changes in anaconda, so feature page of anaconda or at least bug number could be in requirements. Dependencies will be eg powermanagement/performance/... Maintainers of dependent packages/features won't be surprised by broken dependencies or new features, which they should provide for next Fedora. [[User:mmaslano|mmaslano]] 8:34, 22 June 2011 (GMT)

+

* Perhaps an "Acked-by" field that allows owners of major affected components to declare their support for a feature without accepting responsibility for the implementation - right now FESCo does not have this information readily available; OTOH I probably wouldn't want FESCo to routinely defer feature approval pending acks; overall I'm not sure whether it would be a net win. --[[User:Mitr|Mitr]] 20:38, 6 February 2012 (UTC)

+

* It's not clear to me that "New version of X" is really a feature, yet many new features (including some that I've sponsored) fall into that category. At the same time, many major updates happen in Fedora releases that don't become features. Therefore I think "New version of X" should be tracked separately. Before Fedora is released, we compare the package versions of Fx and Fx-1, and cover all major updated packages as a section of the release notes. Features that are just "New version of X" are no longer needed and can be rejected. [[User:Rjones|Rjones]] 20:38, 8 February 2012 (UTC)

* At the moment any non-trivial feature (i.e. not only adding new packages) is proposed (transitions to "ready for wrangler" in current process), notify fedora-devel about it to start discussion (and make this notification mandatory, or, even better, automated).

+

* Split the features so that they can be monitored differently. The split could be by :

+

Time:

+

* early feature: requires mass-rebuild and should land early

+

* classic feature: which works only involves adding new packages and doing some updates, these coud follow the class feature path with the current milestone

+

Importance/span:

+

* classic feature similar to : the new eclipse version or PHP or D

+

* major feature: distro wide changes which are influencing a number of componnent in the distro (systemd, usrmove, pa to some extend)

+

This way early feature should be prepared early and could have a different agenda that 'classic' features. Also major feature could be monitored more closely. Toshio proposed on the devel list that a Fesco member could be assigned to the features, that only possible for a limited set of features, I would recommend the major features. Major features could also be advertised more broadly to the lists (devel/test/anaconda if needed/kernel/rpm...) if needed. Each features are different and categorize them might help to supervize them more easily. --[[User:Pingou|Pingou]] 20:51, 10 February 2012 (UTC)

+

* Feature Shepard: a specific FESCo member needs to step up to be in charge of making the integration of a feature as smooth as possible. They would be in charge of the feature, watch it as it evolves, pick apart all the points where it requires coordination with other groups, and make sure that those groups were informed that the feature was in progress. If the feature fails to coordinate with some other group until the last minute, it then becomes a failure of that particular FESCo member.

+

** To be honest, I am not a big fan of putting the blame on one FESCo member only. If I do like the idea of dividing the load of feature monitoring among FESCo members, I would prefer that if something goes wrong, the whole FESCo as a body and not a person remain the object of the blames. --[[User:Pingou|Pingou]] 17:48, 11 February 2012 (UTC)

+

* We could ask that the features are not targeting one specific release anymore. They become "independent" of the release. "Here is my feature, I would like to work on it, what does FESCo thinks about it", FESCo agrees, team work on it. When the work is ready, the feature is merge in rawhide after the next branching, allowing few months for testing or reverting if necessary before it ends up on the release branch.

+

** Advantages:

+

*** More time to test features as they should be merged in rawhide "right" after branching

+

*** Features are no longer targeting a specific Fedora release : i.e. there is no pressure to get the release in before this dead-line

+

** Inconvenient:

+

*** More pressure on FESCo to review Features early and often as the features can be proposed at any time

+

*** Reverting features might still be a lot of work as people will have built on it in rawhide in the meanwhile

* After FESCo meeting, which has ~18 features on agenda, I'm in favour of dropping leaf packages nominated as features. Those should go into release notes and don't go under review of FESCo at all. FESCo should review more closely invasive changes, namely - replacement of default package in Base group, change which will impact heavily impact Base/... groups. The reviews should be aimed on dependencies and scope of feature. I'd like to improve way of tracking those changes. Some features didn't have in the scope essential dependencies, but they didn't fix by themselves - anaconda, SElinux is mostly ignored and broken. I guess reverse process, where maintainers of feature would discuss with developers before they broke installation would be nice. Tracker bug on the more complicated feature would be also helpfull and bugs for each component, where would be tracked process and possibility of a fix. [[User:mmaslano|mmaslano]] February 9, 2012

Latest revision as of 15:36, 31 October 2012

This page is currently OPEN for suggestions on fixing the Feature Process. Comments will close, at least temporarily, on June 15, 2011, so that feedback can be assessed and we can move on to next steps.

A good number of people think that the Feature Process, as it exists currently, is broken. This page is an attempt to start gathering feedback, information, specific examples, suggestions, flames, praise, or anything else you'd like to leave.

I (Robyn) will leave this wiki page open for commentary through 2011-06-15. After that, I'll attempt to concatenate some of the information into a readable format by 2011-06-20, and start figuring out what next steps should be, if any.

Please remember: This is a wiki page, BE BOLD! Feel free to add additional sections, information, etc. as you see fit. If people want to use the discussion tab, go for it.

We really have multiple goals with features and the requirements for them should be different: --abadger1999 19:26, 1 June 2011 (UTC)

Features that require package maintainers to coordinate with each other (NetworkManager updates, systemd, programing language updates) --abadger1999 19:26, 1 June 2011 (UTC)

Features that we want release noted and to hit marketing (new version of blender/inkscape/other self-contained app) --abadger1999 19:26, 1 June 2011 (UTC)

Some features have some degree of cross-over (gnome3, kde4 for instance) as they're both major end user changes and require coordination with others --abadger1999 19:26, 1 June 2011 (UTC)

Features that fall into the first category (requiring maintainers to coordinate with each other) arriving late in the cycle but being approved either as (1) part of another feature or (2) because we don't consider the burden it might place on other maintainers. --abadger1999 19:26, 1 June 2011 (UTC)

I agree, there are two major groups. Imho it's leaf packages, which can't broke other packages, and critical packages that can. I would create two categories. First one would be things like Aeolus, only release notes & marketing. It's nice to have it in Fedora, but they are leaf packages and Fesco doesn't have to control them. The second group should be critical things - interpreters like Python, init - systemd. There should be rules 'what to check' before adding them or replace as default. Fesco should work with feature owners, control list of (tracking) bugs and problems. In case critical feature would broke other packages, it should be taken back and Contingency plan from feature page should be used. User:mmaslano 19:36, 3 June 2011 (GMT)

Along this dimension, I think there are actually three separate groups:

relnote-only features (new functionality, new packages)

SIG-scope features (doesn't affect anything outside packages maintained by a specific SIG; may need coordination within a SIG): FESCo could fairly often delegate the technical details to the SIG (or the SIG and FPC), and treat the feature almost as relnote-only

The feature process isn't necessarily mandatory at this point, and I personally think that it's a flaw. Major features *should* be required to go through the features process, not only from a technical governance and integration standpoint, but in an effort to help with documentation and marketing. Jsmith 16:02, 6 June 2011 (UTC)

I was pondering if we can actually enforce people to go through the feature process. Enforcing something means that if they don't something will happen. So what could happen if someone makes a big change without going through the feature process? People who are making features are mostly people already quite involved in Fedora and who should understand the burden of late rebuild/late update as regard to dependency management or broken path/package (I have in mind the /root-selinux example of miss-coordination). --Pingou 06:40, 7 June 2011 (UTC)

Maintainers are still unclear about what the various milestones/dates mean for them. At Feature Freeze/Alpha/Beta/etc, what do I have to have done and what can still be left for later? --abadger1999 20:08, 6 June 2011 (UTC)

FESCo also tends to err on the side of letting late features through rather than keeping them out (which is not always bad). Some of this could be helped by separating the types of Features and having an understanding that things for documentation have one due date (needing to be sure it's in so that release notes and translations of release notes can be finalized) while things requiring coordination need a much earlier (or sequence of much earlier) deliverable date so that coordination and fixing of dependent packages can happen. --abadger1999 20:08, 6 June 2011 (UTC)

Awesome new version of (insert your favorite desktop app here) came out the week after a new Fedora release. Waiting 6 months for it sucks. Or, similarly, maybe you're really into a particular app (Firefox, Gimp, Inkscape, etc.) and want to track the upstream devel version rather than the stable version. The current feature process doesn't (or so I've been given this as an excuse) leave much room for a major app update to be applied in a given release after GA. Even if it's just a 'leaf' app and doesn't involve the core OS. Since one of our major principles is 'first' it seems like a worthy problem to solve. (Yes, Fedora People repos can solve this to some extent but are limited.) --Duffy 01:46, 7 June 2011 (UTC)

Features are routinely approved where the release notes or other sections have been filled very poorly and just to have something in the template. See the recently approved btrfs feature release notes for a good example. Feature wrangler should push back and not nominate any features to FESCo till developers make a more serious attempt to document the feature properly. I bought this up in devel list before this feature was even accepted but it seems to have made no difference. This makes life difficult for people writing release notes or release announcements --Rahul Sundaram 17:45, 13 June 2011 (IST)

Who does the work? Should the Feature Proposer have already lined up the necessary work to make the changes or is the expectation that FESCo approved Features must be done by the package owners? --abadger1999 19:03, 14 November 2011 (UTC)

For features that are somewhat optional to implement (for instance, moving files to a different location when backwards compatible symlinks exist or changing the initscripts from one format (that is supported for backwards compat) to a different one that works better), the above becomes even more pertinant as a feature that doesn't have any workers can be approved but nothing might be done with it.--abadger1999 19:03, 14 November 2011 (UTC)

With Features that, if not implemented, do not break the system it is unclear who needs to do the work (as noted above), when the Feature can be considered done, and what to do with the Feature if it isn't "done". An example would be a feature that specifies moving files to a different directory in packages (certs moving to /etc/pki/ for instance). If 40 out of 80 packages change, should the Feature be documented? Should it be discarded and brought back up for the next release? The release in which it reaches 100% of the packages? --abadger1999 19:03, 14 November 2011 (UTC)

The kernel rule is "if you change the API, you fix all users", and I think that's a good approach most of the time. However, perhaps this should be applied to a smaller set of packages (... which is difficult to define - perhaps "the default DVD + everything necessary to build it"?) - i.e. it would be the feature owner's responsibility to make sure this set of packages is covered, and packages outside of this set are primarily the responsibility of their maintainers. --Mitr 20:35, 6 February 2012 (UTC)

The definition of testable is unclear so package maintainers, this years fesco, next year's fesco, etc have different ideas of how complete a feature must be by the milestones in the schedule.

From time to time, features in effect define new distribution-wide policies, and these are often not recorded anywhere outside of the feature. --Mitr 20:04, 17 July 2012 (UTC)

NetworkManager update in F15 arrived after the Feature process was closed to new features and left us scrambling and we weren't able to fix Sugar by release time. --abadger1999 19:30, 1 June 2011 (UTC)

And while KDE Plasma was "fixed" by release time, the hack which shipped (a parallel API for the whole NetworkManager) caused a lot of a support mess for the entire distro (NM updates would keep fixing one API, but breaking the other, hitting both KDE and non-KDE users in alternation) and in the end broke down entirely (forcing us to rush out the native NM 0.9 version of kde-plasma-networkmanagement as an update before it was ready, causing a few regressions which took time to fix). At the time Fedora 15 shipped, it was not clear at all how the upgrade path would work out (the compatibility API only supported the exact feature set of the kde-plasma-networkmanagement snapshot it was developed for, new features in newer upstream snapshots did not work (and we were depending on rebases to fix bugs), and when native NM 0.9 support would be ready was entirely unknown at that time, as was whether migration to it would work well enough to go out as an update). It actually worked out surprisingly well, but it was not without bumps, and it could easily have been worse. --Kkofler 01:06, 9 February 2012 (UTC)

Python2.7 upgrade in F14 -- the feature was accepted on time but the rebuilds to implement the feature happened late, leaving us with modules that had to be fixed in order to work very late (sometimes too late) in the cycle --abadger1999 19:30, 1 June 2011 (UTC)

Boost upgrade in F14 -- the feature was accepted on time, but the ABI changing upgrade landed roughly at the same time as Python2.7, right before branching. There should be some coordination as to when major rebuilds should happen during each cycle. --Kalev 19:39, 22 June 2011 (UTC)

NetworkManager brought lot of unplanned work for KDE team. Also changing /run into root added work to selinux team. Such change wasn't discussed with selinux maintainers before, so they couldn't prepare it and co-operate on changes. Both updates of /run and new selinux rules should go out in one update. User:mmaslano 19:21, 3 June 2011 (GMT)

The Remove SetUID feature says it reached 100% and is in Fedora 15 but Fedora 15 is not even close to having this feature implemented. (There's still many applications that are setuid and there are no packaging guidelines for using file capabilities instead of setuid).

As noted by Tore Anderson in Bug #538499, Fedora 12 advertised IPv6 support in NetworkManager, but it simply didn't work. Yet it was 100% at the time of release. It seems to me that if something is a Fedora Feature, it should be a release blocker if it doesn't work. Sschmit 03:40, 23 June 2011 (UTC)

Take a look at the Fedora 15 feature list. "Consistent Network Device Naming" is still at 90%. Fedora 15 is released. How is that possible? Sschmit 03:40, 23 June 2011 (UTC)

UsrMove for F17. As the feature developed it involved more people (rpm, releng for builder updates, anaconda) but the feature page didn't reflect them and those groups were not informed that they would be needed to do work until the last minute; leading to conflicts. --abadger1999 18:59, 8 February 2012 (UTC)

Split the process -- a set of criteria and due dates for features that need external marketing and a different set of criteria and due dates for features that need internal coordination. Probably give different names to each of these to avoid confusion. Initially, FESCo and the Feature Wrangler may need to tell people that their feature was submitted to the wrong group, point out the relevant criteria, and help the feature owner move them. --abadger1999 20:16, 6 June 2011 (UTC)

Different expectations around who does the work depending on when a coordination requiring feature is publicized. For instance, if you introduce API changes in the first stage of release creation, the dependent packages have primary responsibility for fixing their packages. If you introduce API changes later than that, the package maintainers introducing the API changes have primary responsibility for fixing the dependent packages. --abadger1999 20:16, 6 June 2011 (UTC)

Please treat features involving the core OS differently than features involving 'leaf' items. Too harsh requirements on things that don't need it are bad, too lax policies on things that really should have stricter requirements are bad - seeing examples of each above on this page. --Duffy 01:39, 7 June 2011 (UTC)

It would be cool to track newly-packaged apps from a marketing point-of-view. Many times new and interesting packages are added with a new version of Fedora, yet there is no marketing around their inclusion. For example, 10 new fonts in this release, this new app is packaged, etc. And none of these are things that the release should be held up for; more that I think it would help give our marketing materials more heft and generate more interest in new releases. --Duffy 01:39, 7 June 2011 (UTC)

Would it be possible to add arrays: requirements and dependencies? Nice example is btrfs. It needs changes in anaconda, so feature page of anaconda or at least bug number could be in requirements. Dependencies will be eg powermanagement/performance/... Maintainers of dependent packages/features won't be surprised by broken dependencies or new features, which they should provide for next Fedora. mmaslano 8:34, 22 June 2011 (GMT)

Perhaps an "Acked-by" field that allows owners of major affected components to declare their support for a feature without accepting responsibility for the implementation - right now FESCo does not have this information readily available; OTOH I probably wouldn't want FESCo to routinely defer feature approval pending acks; overall I'm not sure whether it would be a net win. --Mitr 20:38, 6 February 2012 (UTC)

It's not clear to me that "New version of X" is really a feature, yet many new features (including some that I've sponsored) fall into that category. At the same time, many major updates happen in Fedora releases that don't become features. Therefore I think "New version of X" should be tracked separately. Before Fedora is released, we compare the package versions of Fx and Fx-1, and cover all major updated packages as a section of the release notes. Features that are just "New version of X" are no longer needed and can be rejected. Rjones 20:38, 8 February 2012 (UTC)

At the moment any non-trivial feature (i.e. not only adding new packages) is proposed (transitions to "ready for wrangler" in current process), notify fedora-devel about it to start discussion (and make this notification mandatory, or, even better, automated).

Split the features so that they can be monitored differently. The split could be by :

Time:
* early feature: requires mass-rebuild and should land early
* classic feature: which works only involves adding new packages and doing some updates, these coud follow the class feature path with the current milestone
Importance/span:
* classic feature similar to : the new eclipse version or PHP or D
* major feature: distro wide changes which are influencing a number of componnent in the distro (systemd, usrmove, pa to some extend)

This way early feature should be prepared early and could have a different agenda that 'classic' features. Also major feature could be monitored more closely. Toshio proposed on the devel list that a Fesco member could be assigned to the features, that only possible for a limited set of features, I would recommend the major features. Major features could also be advertised more broadly to the lists (devel/test/anaconda if needed/kernel/rpm...) if needed. Each features are different and categorize them might help to supervize them more easily. --Pingou 20:51, 10 February 2012 (UTC)

Feature Shepard: a specific FESCo member needs to step up to be in charge of making the integration of a feature as smooth as possible. They would be in charge of the feature, watch it as it evolves, pick apart all the points where it requires coordination with other groups, and make sure that those groups were informed that the feature was in progress. If the feature fails to coordinate with some other group until the last minute, it then becomes a failure of that particular FESCo member.

To be honest, I am not a big fan of putting the blame on one FESCo member only. If I do like the idea of dividing the load of feature monitoring among FESCo members, I would prefer that if something goes wrong, the whole FESCo as a body and not a person remain the object of the blames. --Pingou 17:48, 11 February 2012 (UTC)

We could ask that the features are not targeting one specific release anymore. They become "independent" of the release. "Here is my feature, I would like to work on it, what does FESCo thinks about it", FESCo agrees, team work on it. When the work is ready, the feature is merge in rawhide after the next branching, allowing few months for testing or reverting if necessary before it ends up on the release branch.

Advantages:

More time to test features as they should be merged in rawhide "right" after branching

Features are no longer targeting a specific Fedora release : i.e. there is no pressure to get the release in before this dead-line

Inconvenient:

More pressure on FESCo to review Features early and often as the features can be proposed at any time

Reverting features might still be a lot of work as people will have built on it in rawhide in the meanwhile

After FESCo meeting, which has ~18 features on agenda, I'm in favour of dropping leaf packages nominated as features. Those should go into release notes and don't go under review of FESCo at all. FESCo should review more closely invasive changes, namely - replacement of default package in Base group, change which will impact heavily impact Base/... groups. The reviews should be aimed on dependencies and scope of feature. I'd like to improve way of tracking those changes. Some features didn't have in the scope essential dependencies, but they didn't fix by themselves - anaconda, SElinux is mostly ignored and broken. I guess reverse process, where maintainers of feature would discuss with developers before they broke installation would be nice. Tracker bug on the more complicated feature would be also helpfull and bugs for each component, where would be tracked process and possibility of a fix. mmaslano February 9, 2012