= phenomenon =
The current Feature process has worked for us for a while now, however it is a bit cumbersome and ambiguous. I would like to work on refining the process in time for Fedora 19.
= background analysis =
In the beginning, there was work. It was done ad hoc and at times in an uncoordinated manner. Then the Feature process came along to help coordinate large features and highlight things for Public Relations purposes. This has arguably served us well, however it has two problems with it.
1) The "feature" list continues to grow because the definition is ambiguous.
This leads to what I perceive as "Feature bloat", as well as causing review of feature pages that are not necessarily features. F17 had an absurd number of features, many of which just read as a changelog of version upgrades.
2) The Feature page form itself is somewhat unwieldly.
The sections present require information to be duplicated for seemingly no good reason. This can be a waste of developer time.
= implementation recommendation =
I am still thinking about how to solve these issues, but I thought I would open the ticket for discussion early. Feedback welcome.
I've CC'd Jaroslav as well.
Also, previous work on updating the feature process was captured here: http://fedoraproject.org/wiki/Fixing_features
We seem to have a number of features that could just as well be simple changelog entries. Along with the description of what a feature is, would it be worth mentioning some things that are ''not'' features, such as beats and general release notes, for comparison? ("Is this really a feature or is it $foo?")
Replying to [comment:1 toshio]:
Summarizing that a bit (I don't personally agree with all of these, I'm just distilling the page):
Good * Features help write better release notes/marketing * When a Feature is submitted FESCo has some oversight
Bad * Feature pages aren't updated or scoped properly * Features submitted fall into multiple categories and the process doesn't accommodate the varying types * Milestones are murky to developers * We lack integration with Fedora Marketing (or possibly deferment of Features to Marketing) * Lack of clarity on who is responsible for the work for a Feature
We should also make sure we look closely at what to do about contingency plans in Feature submissions.
First and foremost the feature process needs to be able to identified what is considered an feature in the first place before anything else is decide and arguably minor releases of a relevant software stack aren't features but major release is.
For example https://fedoraproject.org/wiki/Features/F18Boost150 https://fedoraproject.org/wiki/Features/Fontconfig2.10 https://fedoraproject.org/wiki/Features/GHC741 https://fedoraproject.org/wiki/Features/Gnome3.6 etc..
Current feature process and proposals lack the ability to handle features that span over multiple release cycle which either needs to be created catogarized or the hard requirement that features should be fully integrated within on release cycle should be made to avoid having half implemented things in the distribution which result in several breakage and general confusion among users and developers as opposed to smooth transaction and inclusion in the distribution.
QA of an feature in the feature process should be delegated to and handled by the QA Community, Including but not limited to ensuring the "how to test" are written and are tested via test days or any other means the QA community deems fit to determent if feature is in ready enough state to be included in the distribution or the "contingency plan" should be acted upon in due time.
If an feature is not 100% completed by by $X time contingency plan should be enacted and the feature reverted or flagged as an multiple release feature.
Just my 2 cents...
Replying to [comment:5 johannbg]:
We have some proposals to solve this, it's "just" a matter of jreznik finding some time.
This is a major concern of mine. I do think that we need to move towards moving from one consistent and well-working release into another (at least for the default spin or a similar set of important packages) instead of having $N parallel alternative models (and constantly adding more). However we can and should make significant improvements in other areas independently from tackling this (surely to be difficult and controversial) aspect.
QA of an feature in the feature process should be delegated to and handled by the QA Community Having independent QA would be really great; does the QA community have enough interested volunteers to handle that task, though?
Replying to [comment:7 mitr]:
Replying to [comment:5 johannbg]: First and foremost the feature process needs to be able to identified what is considered an feature in the first place before anything else is decide and arguably minor releases of a relevant software stack aren't features but major release is. We have some proposals to solve this, it's "just" a matter of jreznik finding some time.
There is also one other thing I should mention is it optional to participate in the feature process or should it be mandatory for everything that the decisive proposal would cover in the distribution?
Current feature process and proposals lack the ability to handle features that span over multiple release cycle which either needs to be created catogarized or the hard requirement that features should be fully integrated within on release cycle should be made to avoid having half implemented things in the distribution which result in several breakage and general confusion among users and developers as opposed to smooth transaction and inclusion in the distribution. This is a major concern of mine. I do think that we need to move towards moving from one consistent and well-working release into another (at least for the default spin or a similar set of important packages) instead of having $N parallel alternative models (and constantly adding more). However we can and should make significant improvements in other areas independently from tackling this (surely to be difficult and controversial) aspect.
Arguably the whole development cycle is to short and should be extend to 9 months or 12 months given that we have never managed to release on time and current Anaconda mess just highlights that fact.
So an hard look at why and what benefits continuing to have 6 months release cycle is bringing us needs to be looked at.
I understand your concerns now that I'm coming back to QA after being focusing on the sysv to systemd migration two active groups have died off "Bugzappers" and "Proven Testers" but there is enough core people to do that, that have been there for several release cycles so let us worry about that we need to have a wide variate of tasks to attract QA community members and have them actively engage and participate in in the QA community.
Well, the idea of having QA as a part of the Feature Process decision making makes sense to me, as QA can state the commitment to test the feature(s).
The overall idea of the proposal is to a) give proposed feature more visibility within the community and b) offload the work from FESCo, so FESCo will have free hands to work more on potentially "dangerous" features and to track the development more closely, not acking every single feature sent from Wrangler to FESCo.
Ad a) all feature will have to be announced publicly, probably on the the devel-list (it would have some impact on the list, as it won't be low traffic), so the discussion could be possible, possible conflicts/integration issues could be solved on list or escalated to the FESCo. Reason: currently the visibility of accepted features is very low, it's hard to enter the approval process, people usually discuss the feature after the FESCo approval, so the interaction is bad etc.
Ad b) Based on the ongoing discussion and this proposal - FESCo should have the main decision power on "critical path" features, the self-contained/lead features could be offloaded to a) different body (see [https://fedoraproject.org/wiki/Feature_Process_%28draft%29 toshio's draft] - Feature Wrangling SIG - consisting from Feature Wrangler/FESCo member/QA member), b) or it would be enough just to publicly announce the feature (see Ad a) after the formal requirements are checked and/or give SIGs the decision power (but this applies to a) too) Conflicts/issues could be escalated to FESCo as proposed above in the visibility section. Reason: we need proper tracking of the main feature's development, just acking features around the submission deadline takes too much energy/time from FESCo.
Other difference between "critical path" and "self-contained/leaf" feature could be timing - for the "critical path" features we need strong deadlines/checkpoints to track feature, integrate with the rest of the system (give bigger period for integration before Alpha). There should not be this strong requirements for the second sort of feature - the Feature 100% complete deadline should be enough. Reason - for "critical path" feature we need strong tracking, the rest are usually just acked by FESCo even a) submitted after the deadline, b) not meeting the milestone requirements and if postponed to the next release if 100% complete deadline is not met. For "critical path", the requirements has be enforced.
Please discuss the proposed changes on the next FESCo meeting, so the schedule for F19 could be adjusted. It's the last moment call, sorry. But this is more a tune up of current process, than revamping from scratch - it's definitely for bigger discussion together with release cycle etc.
Since people seem to fail to understand or accept that there is no governing structure in QA ( hence the suggestion that an single QA member would serve on a SIG ) the workflow will need to be that the Feature Wrangler or the Feature Wrangler SIG opens a ticket in QA trac for each submitted feature ( as is with any task needed to be performed within the QA community ) so that any available member of the community can grab that ticket and work on it as opposed to having a single QA member in the Feature wrangler SIG left with trying to handle that stuff which he or she may or may not have adequate time to do.
We ( as in QA/FESCO/Feature Wrangler (SIG)) just need to come up with an well defined SOP on how to handle that process and come up with an request template for the wrangler(s) to use.
Replying to [comment:10 johannbg]:
But what you proposed now is exactly the same situation we'd like to avoid for FESCo - the overhead of Features to be approved. And to offload the work from FESCo as the whole body and escalate only potential issues. So this delegate from FESCo/QA would not have a decision power for his body but more consultancy role - "hey, this feature could be an issue, let's file bug to FESCo/QA). Btw. having "Features SIG" was just an idea but that "announce feature" has to be in place.
Btw. I don't think we have such a big problem with Features and the process but with Features that were never proposed and we don't know about (new upgrade tool, lvm as an example - New Installer UI actually matches proposed Feature quite well) .
Replying to [comment:11 jreznik]:
It's not up to us QA to approve features, it's our responsibility to ensure that proper testing takes place on approved features and arguable ensure that there is proper contingency plans in place and it works ( either come up with ourselves or test the contingency plan with releng community ) and we determine if feature can be consider 100% or at least oversee that process.
I would say it was feature wranglers or feature wranglers SIG purpose is to determine if what is being submitted actually is an feature in the first place ( not just an incremental fix with minor enhancement to a component as in an minor release not a major one as in not 1.2 but 2.0 etc ) and once they have done that him or they move the feature to FESCO for approval which responsibility is to determine the technical aspect of the feature and the scope of it along with it implementation and how it's implementation affects the community in whole.
What I was mentioning above in comment 11 was the workflow to use in QA and it's approach to the feature process.
Basically I picture the workflow being like this....
An feature creator creates an feature and submits it to feature wrangler(s) --> feature wrangler(s) determine if what has been submitted is considered an actual feature in the first place, if so pass it on to fesco, fesco go over the technical aspect of the feature and determine the scope of it. If approve they open a ticket in QA trac to oversee the QA aspect of the feature, we (QA) then report to fesco at feature freeze if we consider the feature being an feature is ready enough to be implemented or if we recommend it should be reverted for the good of the community.
We could also just drop the feature wrangler(s) role altogether, setup a trac instance for the feature process where feature creators submit their proposal and we ( as in Fesco, QA and Releng community ) come together on ( weekly ) meetings determine all of the above and either approve or reject it. And if we approve it we ensure in our community's that the feature that was approved gets the coverage it needs etc...
In any case first we need to determine what is consider as an feature in the first place, once that has been established ( at that point we should already have a SOP or at least a check list to follow ) we need to decide if all maintainers are obligated to follow the feature process or if it continues to be opt in,opt out and once that has been decide we can discuss/plan on how we handle the rest of the process ( from my pov ).
I guess we need to start with "what we want to solve".
1/ I see the fisrt problem in badly worded or missing scope of feature or not announcing the feature at all. Imho features with wider impact must be mandatory.
2/ Another problem is "who will do the work". If the feature is having impact on many other packages, then the maintainer of feature must be responsible for fixing bugs in packages, which were broken by his/her change. The problem start with scope. Maintainer of feature must create list of packages hit by this change and provide guidance or patches.
3/ "what if something went terribly wrong". Revert the feature. Prevent disasters by working in different branches or build tag if possible.
Let's start the discussion about reworked Feature process https://fedoraproject.org/wiki/User:Mmaslano/Feature_process
What I am missing from the feature process, is some indication whether a feature is meant to be implemented for more than one release. For example there was once a Feature for a smooth boot process ([http://fedoraproject.org/wiki/Features/BetterStartup Better Startup F10]), but it seems to be broken in later releases. I believe there were other examples on the devel mailing list. IMHO it should be avoided to implement such features only for one release.
So here's one classic problem that I have been trying to point out to you guys with regards to the feature process and I have experienced first hand ( on few occasion for example with the deprecation part of the cluster [2] ) myself with the sysv to systemd migration.
Here [1] we have Kay Sievers going through code for an "feature" identified a problem and potentially gone through the work of patching it spending maybe 1 or 2 beer hours in it. submits the patch and the bug gets closed WONTFIXED because it turns out that the maintainer is going to deprecate the component!
So I'm going to emphasize the point once more that we need to be done orphaning packages/retiring packages as early in the process and no later then alpha so feature owners are only working on packages that are actually going to be in and actively maintained in the distribution we are about to release.
One side of the problem we have to identify unmaintained packages in the distribution and the other is somehow get maintainers to orphan/retire packages at the beginning of the release cycle.
Replying to [comment:16 johannbg]:
Here [1] we have Kay Sievers going through code for an "feature" identified a problem and potentially gone through the work of patching it spending maybe 1 or 2 beer hours in it. submits the patch and the bug gets closed WONTFIXED because it turns out that the maintainer is going to deprecate the component! So I'm going to emphasize the point once more that we need to be done orphaning packages/retiring packages as early in the process and no later then alpha so feature owners are only working on packages that are actually going to be in and actively maintained in the distribution we are about to release.
This case would not be handled by orphaning/retiring packages earlier - the package has a maintainer who has responded within a day; there would be no grounds for automatically orphaning/retiring it.
This case notwithstanding, I agree that an orphaning/retiring run at the start of the release process (whether in addition to, or instead of, the current one), would be beneficial - but that is unrelated to the feature process.
jreznik, what would be the best place/way to discuss and/or possibly change this?
Replying to [comment:17 mitr]:
Replying to [comment:16 johannbg]: This case would not be handled by orphaning/retiring packages earlier - the package has a maintainer who has responded within a day; there would be no grounds for automatically orphaning/retiring it.
Falls under the other case.
I think we were looking into the general packaging cleanup process on another ticket and least to determine how big/small is the problem
I beg the differ since feature owners might be spending time on those components.
In my case I spent 4 -8 hours migrating the cluster suit daemons only to find out at submission time that there where plans to deprecated it.
If I had not found the packages via repoquery or some other way known that there where plans to deprecate I could have spent those 4 - 8 hours on migrating other legacy sysv initscripts
I think it would suffice either asking or make mandatory that maintainers that are planning to deprecate,orphan etc, components do so at branch time.
Johann, I agree that is a problem, but I'd like to split it off improved feature process discussion. Would you mind to start another ticket? The removal of old packages will be separate process. At least it should work outside of features.
I see one problem with deprecation of packages in branching time. What if new feature will replace the package? Features could be finished few months after branching...
Replying to [comment:16 johannbg]: Here [1] we have Kay Sievers going through code for an "feature" identified a problem and potentially gone through the work of patching it spending maybe 1 or 2 beer hours in it. submits the patch and the bug gets closed WONTFIXED because it turns out that the maintainer is going to deprecate the component! So I'm going to emphasize the point once more that we need to be done orphaning packages/retiring packages as early in the process and no later then alpha so feature owners are only working on packages that are actually going to be in and actively maintained in the distribution we are about to release. This case would not be handled by orphaning/retiring packages earlier - the package has a maintainer who has responded within a day; there would be no grounds for automatically orphaning/retiring it. This case notwithstanding, I agree that an orphaning/retiring run at the start of the release process (whether in addition to, or instead of, the current one), would be beneficial - but that is unrelated to the feature process. jreznik, what would be the best place/way to discuss and/or possibly change this?
Looking to schedule - orphaning rawhide packages happens the same time as branching (for F18 it was 2012-08-07), so it is definitely before Alpha. So I think this should be a part of the "when to branch" discussion - and seems like general opinion is on moving it sooner before Alpha (to have time for the integration part of development and thus it would help to avoid this situation too).
Replying to [comment:15 till]:
I'd say it's "partially" covered by this proposal (but not explicitly written) - the idea would be: for the first time Feature is proposed - it fits into the "Complex" features category - usually integration aspects has to be reviewed and agreed on etc., so it requires action from FESCo (but really depends on each single feature proposed), broader communication within the project if this Feature span through the more releases (as for example SysV to Systemd), then it's more continuous effort to finish what was agreed on before - fits the "self contained" category and could be easily re-proposed, with less bureaucracy, approval from FESCo...
If this makes sense for you, I can extend the proposal more explicit to contain it as an example (even making the process more fast track - not requiring the new Feature page for every release, just marking it continuous but still announced and subject of raise to FESCo policy).
Replying to [comment:21 jreznik]:
Replying to [comment:15 till]: What I am missing from the feature process, is some indication whether a feature is meant to be implemented for more than one release. For example there was once a Feature for a smooth boot process ([http://fedoraproject.org/wiki/Features/BetterStartup Better Startup F10]), but it seems to be broken in later releases. I believe there were other examples on the devel mailing list. IMHO it should be avoided to implement such features only for one release. I'd say it's "partially" covered by this proposal (but not explicitly written) - the idea would be: for the first time Feature is proposed - it fits into the "Complex" features category - usually integration aspects has to be reviewed and agreed on etc., so it requires action from FESCo (but really depends on each single feature proposed), broader communication within the project if this Feature span through the more releases (as for example SysV to Systemd), then it's more continuous effort to finish what was agreed on before - fits the "self contained" category and could be easily re-proposed, with less bureaucracy, approval from FESCo...
Features spanning more then one release cycle should not have to be re-proposed and re-approved.
FESCO has already approved it thus the feature and related work has already started and is being worked on.
From the 2012-12-05 FESCo meeting:
Given that, ticket remains open. Work proceeds.
Here are proposed new feature templates: * [https://fedoraproject.org/wiki/User:Mitr/SelfContainedFeatures] (and [https://fedoraproject.org/wiki/Special:ComparePages?page1=Features%2FEmptyTemplate&rev1=&page2=User%3AMitr%2FSelfContainedFeatures&rev2=&action=&diffonly=&unhide= diff]) * [https://fedoraproject.org/wiki/User:Mitr/SystemwideFeatures] (and [https://fedoraproject.org/wiki/Special:ComparePages?page1=Features%2FEmptyTemplate&rev1=&page2=User%3AMitr%2FSystemwideFeatures&rev2=&action=&diffonly=&unhide= diff])
Replying to [comment:24 mitr]:
Here are proposed new feature templates: * [https://fedoraproject.org/wiki/User:Mitr/SystemwideFeatures]
Given that systemwide features will have FESCo shepherd cant we just drop
Last updated: (DATE)
Percentage of completion: XX%
completely and just have it the shepards task to keep tap on it if the feature is finished in due time for the target release cycle?
Replying to [comment:25 johannbg]:
Replying to [comment:24 mitr]: Here are proposed new feature templates: * [https://fedoraproject.org/wiki/User:Mitr/SystemwideFeatures] Given that systemwide features will have FESCo shepherd
Given that systemwide features will have FESCo shepherd
That hasn't been agreed to.
Having the simple - Self contained feature template (as we should make these features more easier to propose) and require more information for system wide - is generally a good idea. The drawbacks are - it's one more step when creating feature page and then migration - if self contained feature is escalated for FESCo review, missing details has to be added (or converted to the system wide template).
Here's [1] one example how utterly misleading and useless these % are
Would you conclude of all the % mentioned there on the feature page that this feature had been complete? Yet it is flagged as "Percentage of completion: 100%"
1.http://fedoraproject.org/wiki/Features/Cluster
In principle, reducing the scope of a feature is a perfectly fine way to get to 100% status. 100% can mean "We didn't do all we wanted, but the result is functional and we can release F18 like this".
Replying to [comment:29 mitr]:
Sorry not following how an feature can mean 100% and not yet be done.
Does not reducing the scope of a feature kinda point out the fact that the completion of an relevant feature actually spans over multiple release cycle instead of one thus should be flagged as such and marked incomplete until it actually has been fully implemented into the release?
Replying to [comment:30 johannbg]:
Replying to [comment:29 mitr]: In principle, reducing the scope of a feature is a perfectly fine way to get to 100% status. 100% can mean "We didn't do all we wanted, but the result is functional and we can release F18 like this". Sorry not following how an feature can mean 100% and not yet be done. Does not reducing the scope of a feature kinda point out the fact that the completion of an relevant feature actually spans over multiple release cycle instead of one thus should be flagged as such and marked incomplete until it actually has been fully implemented into the release?
In my opinion is okay, when you claim to support in your feature A, B, C, D and then honestly say only first three will be supported in next Fedora. It's still better than not mentioned at all that last option is not supported and it's planned for next release. Of course it couldn't be blocker for Fedora release.
As a stop-gap for Fedora 19, FESCo will vote en bloc on Features that do not have an explicit question/objection. This was agreed to in the 2013-01-09 meeting.
Is someone still writing up the discussion and proposals that were done at FUDCon revolving around the Feature (planning) process? I would, but I was not present for the entire discussion because my flight left earlier in the day.
Replying to [comment:33 jwboyer]:
Notes from the meeting: http://etherpad-fudcon2013.rhcloud.com/p/FeatureImprovements
And updated proposal based on FUDCon discussion: https://fedoraproject.org/wiki/User:Mmaslano/Feature_process
Sorry it took longer :(
The new planning process was approved with change of name from features to changes (+7,-0,0)
The changes will be done on wiki pages and are still open to comments for rest of the FESCo.
The first step - with Mitr and based on his proposed templates (https://fedoraproject.org/wiki/User:Mitr/SelfContainedFeatures and https://fedoraproject.org/wiki/User:Mitr/SystemwideFeatures), we created a merged version. The reason is - it will be easier to update Self Contained Change to System Wide just by providing more details and it will be easier to check, if all details are provided correctly. See https://fedoraproject.org/wiki/JaroslavReznik/ChangeProposalTemplate
For status tracking, I'd like to go with [https://fedorahosted.org/fesco/ticket/979 Features process proposal: Track features in bugzilla] - see the inline comment in the template.
Another step - replacement for Features List. Currently it's only a list with percentage of completion (we'd like to get rid of it - see the Bz for tracking), short summary (cut down to be short enough) and last update date, all generated by a script from Feature pages.
What I'd like to have is to change it more to the overview of Changes (but still automatically generated), so the status will be clearly visible and the tracking bug, owners/people working on change + possibly more details for other teams (see bellow). For self contained changes, maybe the table would be sufficient. Disadvantages - could be a big page (but System Wide changes first) and it's not sortable as table.
Initial draft, https://fedoraproject.org/wiki/Releases/20/ChangeSet
For Change Set page and Change Proposals pages itself, I'd like to change it in the way to be useful for other teams too, not only for the owner/develop and to have "centralized" planning and tracking process, that does not get out of sync (was the change someone is preparing for Release Notes or Talking Points, Announcements ever finished? - we hit the issue several times). Of course it depends on Docs (the idea partially comes from the team) and Marketing/other teams if they would like to join the effort. And what details they require in the Change/ChangeSet pages. See Docs/Marketing ML.
FESCo meeting 2013-03-27: The merged template for Change proposals is approved as per jreznik's proposal.
Login to comment on this ticket.