Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On 11/06/2012 05:35 AM, Garrett Holmstrom wrote: On 2012-11-05 12:22, Jóhann B. Guðmundsson wrote: On 11/05/2012 07:52 PM, Miloslav Trmač wrote: A crit path update that affects, say, two packages and nothing else, could be approved by default as well. Many of the crit path features however affect a large or extremely large package set (e.g. the sysv-systemd script migration), in which case explicitly involving every maintainer as the feature owner before even proposing the feature wouldn't scale; that's where FESCo does need to step in as a more efficient way to represent the large group of packagers. Case in point for F18 [1] and perfect example of one thing that should have been completed within one release cycle... JBG 1.http://fedoraproject.org/wiki/Features/PackagePresets As that feature is about changing distribution-wide policy, I cannot act on it until said policy is written. (See https://fedorahosted.org/fesco/ticket/945) The feature's owners do not appear to be interested in doing so. If you are, I would greatly appreciate it if you would add a proposal to that FESCo ticket so I can have a clear path forward. Well I guess we probably should follow what other distributions most notably opensuse I suppose since they switched to using preset a while back but I'm not finding any clause about packages preset files themselves [1] so I'm not sure how they handled it unless they just have stricter rules that everything should be defaulted to off which can be seen by the default preset policy for opensuse [2] compared to our bloated one [3]. Issues like these are perfect example for something that should have been resolved *before* the feature was accepted by FESCO... JBG 1.http://en.opensuse.org/openSUSE:Systemd_packaging_guidelines 2.https://build.opensuse.org/package/view_file?file=default-openSUSE.presetpackage=systemd-presets-branding-openSUSEproject=Base%3ASystem 3.http://pkgs.fedoraproject.org/cgit/systemd.git/tree/90-default.preset -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On Thu, Nov 1, 2012 at 7:10 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/01/2012 06:09 PM, Jaroslav Reznik wrote: We were thinking with a few folks more about Self contained feature but yeah, there's a lack of real definition. Other thing is - these Self contained features could be approved implicitly once are announced on devel list (in cooperation with Feature Wrangler). Features that requires integration etc. will be still approved by FESCo, but idea is to offload amount of work from FESCo so they can give more time to track these features. Not to bother with leaf features or enhancements. And as these should be very visible (thanks to announcement) anybody could escalate any feature to the FESCo for discussion/explicit approval. That's the idea, I promised my proposal delivered to FESCo before Beta;-) But you know, moving target Any suggestions are welcomed! Blindly accepting features are unacceptable from QA stand point and arguably minor release updates should be kept out of the feature process An important part of this proposal is to make the mailing list announcement and time for discussion mandatory; that would actually significantly increase the visibility of many features. Also, the feature would not be accepted automatically, only by default - anyone, including QA, could move the feature into the full process. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On Thu, Nov 1, 2012 at 7:34 PM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Nov 01, 2012 at 02:09:21PM -0400, Jaroslav Reznik wrote: That sounds good. Maybe recast those ideas as three levels? - Critical Path Feature - Other Enhancement Feature - New Leaf Feature We were thinking with a few folks more about Self contained feature but yeah, there's a lack of real definition. I think Leaf is better than Self contained, since it's unlikely for the feature to have zero outside dependencies. I think it'd be fine for such a feature to rely on small changes to existing packages (version updates, say). Self-contained in the proposal is intentionally more broad than leaf. For example, it allows a small SIG for a less-used language that does not affect the rest of the distribution to agree to do a major version upgrade and to coordinate among the SIG members (as they would coordinate in any case), without FESCo playing an useless middle-man. (The suggested definition of self-contained is something like maintainers of all affected packages sign up to participate on the work for the feature.) Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On Mon, Nov 05, 2012 at 05:45:14PM +0100, Miloslav Trmač wrote: I think Leaf is better than Self contained, since it's unlikely for the feature to have zero outside dependencies. I think it'd be fine for such a feature to rely on small changes to existing packages (version updates, say). Self-contained in the proposal is intentionally more broad than leaf. For example, it allows a small SIG for a less-used language that does not affect the rest of the distribution to agree to do a major version upgrade and to coordinate among the SIG members (as they would coordinate in any case), without FESCo playing an useless middle-man. (The suggested definition of self-contained is something like maintainers of all affected packages sign up to participate on the work for the feature.) I don't mind too much what the actual name is as long as the scope is clear. Here, I think you're smooshing together two of the three levels I'd suggested, putting both non-crit-path enhancements and new leaf functionality into one category. Is that correct? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On Mon, Nov 5, 2012 at 7:34 PM, Matthew Miller mat...@fedoraproject.org wrote: On Mon, Nov 05, 2012 at 05:45:14PM +0100, Miloslav Trmač wrote: I think Leaf is better than Self contained, since it's unlikely for the feature to have zero outside dependencies. I think it'd be fine for such a feature to rely on small changes to existing packages (version updates, say). Self-contained in the proposal is intentionally more broad than leaf. For example, it allows a small SIG for a less-used language that does not affect the rest of the distribution to agree to do a major version upgrade and to coordinate among the SIG members (as they would coordinate in any case), without FESCo playing an useless middle-man. (The suggested definition of self-contained is something like maintainers of all affected packages sign up to participate on the work for the feature.) I don't mind too much what the actual name is as long as the scope is clear. Here, I think you're smooshing together two of the three levels I'd suggested, putting both non-crit-path enhancements and new leaf functionality into one category. Is that correct? Yes, the self-contained wording covers both leaf features and a subset of non-leaf features. Non-crit-path and all relevant maintainer are involved are different subsets of non-leaf features, however. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On Mon, Nov 05, 2012 at 07:55:26PM +0100, Miloslav Trmač wrote: Here, I think you're smooshing together two of the three levels I'd suggested, putting both non-crit-path enhancements and new leaf functionality into one category. Is that correct? Yes, the self-contained wording covers both leaf features and a subset of non-leaf features. Non-crit-path and all relevant maintainer are involved are different subsets of non-leaf features, however. From the point of view of evaluating impact, and for that matter for the release notes, I think it's good to have big-non-crit-path-enhancements and leaf functionality categorized separately. Both of them would need to be self contained in the sense you're suggesting. In fact, for that matter, wouldn't crit path updates _also_ benefit from the all relevant maintainers rule? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On Mon, Nov 5, 2012 at 8:38 PM, Matthew Miller mat...@fedoraproject.org wrote: On Mon, Nov 05, 2012 at 07:55:26PM +0100, Miloslav Trmač wrote: Here, I think you're smooshing together two of the three levels I'd suggested, putting both non-crit-path enhancements and new leaf functionality into one category. Is that correct? Yes, the self-contained wording covers both leaf features and a subset of non-leaf features. Non-crit-path and all relevant maintainer are involved are different subsets of non-leaf features, however. From the point of view of evaluating impact, and for that matter for the release notes, I think it's good to have big-non-crit-path-enhancements and leaf functionality categorized separately. Both of them would need to be self contained in the sense you're suggesting. Sure, the primary measure is the overall impact on the OS. The proposal is to treat self-contained features as approved by default, nothing more; features with large impact would still go through the full process by overriding the default approval. In fact, for that matter, wouldn't crit path updates _also_ benefit from the all relevant maintainers rule? A crit path update that affects, say, two packages and nothing else, could be approved by default as well. Many of the crit path features however affect a large or extremely large package set (e.g. the sysv-systemd script migration), in which case explicitly involving every maintainer as the feature owner before even proposing the feature wouldn't scale; that's where FESCo does need to step in as a more efficient way to represent the large group of packagers. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On 11/05/2012 07:52 PM, Miloslav Trmač wrote: A crit path update that affects, say, two packages and nothing else, could be approved by default as well. Many of the crit path features however affect a large or extremely large package set (e.g. the sysv-systemd script migration), in which case explicitly involving every maintainer as the feature owner before even proposing the feature wouldn't scale; that's where FESCo does need to step in as a more efficient way to represent the large group of packagers. Case in point for F18 [1] and perfect example of one thing that should have been completed within one release cycle... JBG 1.http://fedoraproject.org/wiki/Features/PackagePresets -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On 2012-11-05 12:22, Jóhann B. Guðmundsson wrote: On 11/05/2012 07:52 PM, Miloslav Trmač wrote: A crit path update that affects, say, two packages and nothing else, could be approved by default as well. Many of the crit path features however affect a large or extremely large package set (e.g. the sysv-systemd script migration), in which case explicitly involving every maintainer as the feature owner before even proposing the feature wouldn't scale; that's where FESCo does need to step in as a more efficient way to represent the large group of packagers. Case in point for F18 [1] and perfect example of one thing that should have been completed within one release cycle... JBG 1.http://fedoraproject.org/wiki/Features/PackagePresets As that feature is about changing distribution-wide policy, I cannot act on it until said policy is written. (See https://fedorahosted.org/fesco/ticket/945) The feature's owners do not appear to be interested in doing so. If you are, I would greatly appreciate it if you would add a proposal to that FESCo ticket so I can have a clear path forward. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
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? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
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
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
- Original Message - On Thu, Nov 01, 2012 at 10:08:39AM -0700, Adam Williamson wrote: 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? That sounds good. Maybe recast those ideas as three levels? - Critical Path Feature - Other Enhancement Feature - New Leaf Feature We were thinking with a few folks more about Self contained feature but yeah, there's a lack of real definition. Other thing is - these Self contained features could be approved implicitly once are announced on devel list (in cooperation with Feature Wrangler). Features that requires integration etc. will be still approved by FESCo, but idea is to offload amount of work from FESCo so they can give more time to track these features. Not to bother with leaf features or enhancements. And as these should be very visible (thanks to announcement) anybody could escalate any feature to the FESCo for discussion/explicit approval. That's the idea, I promised my proposal delivered to FESCo before Beta ;-) But you know, moving target Any suggestions are welcomed! Jaroslav I think this is nice for presenting the list of features overall, actually, both on the web site and in the eventual release notes. I also still like the idea of some other basic checkbox options which encourage people to clarify the wider implications of the feature. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On 11/01/2012 06:09 PM, Jaroslav Reznik wrote: We were thinking with a few folks more about Self contained feature but yeah, there's a lack of real definition. Other thing is - these Self contained features could be approved implicitly once are announced on devel list (in cooperation with Feature Wrangler). Features that requires integration etc. will be still approved by FESCo, but idea is to offload amount of work from FESCo so they can give more time to track these features. Not to bother with leaf features or enhancements. And as these should be very visible (thanks to announcement) anybody could escalate any feature to the FESCo for discussion/explicit approval. That's the idea, I promised my proposal delivered to FESCo before Beta;-) But you know, moving target Any suggestions are welcomed! Blindly accepting features are unacceptable from QA stand point and arguably minor release updates should be kept out of the feature process JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
- Original Message - On 11/01/2012 06:09 PM, Jaroslav Reznik wrote: We were thinking with a few folks more about Self contained feature but yeah, there's a lack of real definition. Other thing is - these Self contained features could be approved implicitly once are announced on devel list (in cooperation with Feature Wrangler). Features that requires integration etc. will be still approved by FESCo, but idea is to offload amount of work from FESCo so they can give more time to track these features. Not to bother with leaf features or enhancements. And as these should be very visible (thanks to announcement) anybody could escalate any feature to the FESCo for discussion/explicit approval. That's the idea, I promised my proposal delivered to FESCo before Beta;-) But you know, moving target Any suggestions are welcomed! Blindly accepting features are unacceptable from QA stand point and arguably minor release updates should be kept out of the feature process Definitely not blinding accepting - the feature would have to go through the Feature Wrangler as for now and then it should be announced in public way. So the Feature is not blindly accepted as many Features on FESCo meeting to get rid of a queue of unapproved ones and even it gets better visibility - so developers can interact with Feature owner and in case of any issues - raise it to FESCo. And FESCo will have time to actually work on it, not just +1-ing it. Jaroslav JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On Thu, Nov 01, 2012 at 02:09:21PM -0400, Jaroslav Reznik wrote: That sounds good. Maybe recast those ideas as three levels? - Critical Path Feature - Other Enhancement Feature - New Leaf Feature We were thinking with a few folks more about Self contained feature but yeah, there's a lack of real definition. I think Leaf is better than Self contained, since it's unlikely for the feature to have zero outside dependencies. I think it'd be fine for such a feature to rely on small changes to existing packages (version updates, say). Other thing is - these Self contained features could be approved implicitly once are announced on devel list (in cooperation with Feature Wrangler). Features that requires integration etc. will be still approved by FESCo, but idea is to offload amount of work from FESCo so they can give more time to track these features. Not to bother with leaf features or enhancements. And as these should be very visible (thanks to announcement) anybody could escalate any feature to the FESCo for discussion/explicit approval. That's the idea, I promised my prposal delivered to FESCo before Beta ;-) But you know, moving target Any suggestions are welcomed! Jaroslav I think this is nice for presenting the list of features overall, actually, both on the web site and in the eventual release notes. I also still like the idea of some other basic checkbox options which encourage people to clarify the wider implications of the feature. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On Thu, Nov 1, 2012 at 7:34 PM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Nov 01, 2012 at 02:09:21PM -0400, Jaroslav Reznik wrote: That sounds good. Maybe recast those ideas as three levels? - Critical Path Feature - Other Enhancement Feature - New Leaf Feature We were thinking with a few folks more about Self contained feature but yeah, there's a lack of real definition. I think Leaf is better than Self contained, since it's unlikely for the feature to have zero outside dependencies. I think it'd be fine for such a feature to rely on small changes to existing packages (version updates, say). I'd argue that this isn't a feature ... otherwise we could advertise every version upgrade as feature. If it does not affect a large amount of users it is simply a version upgrade not a fedora feature. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
- Original Message - On Thu, Nov 1, 2012 at 7:34 PM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Nov 01, 2012 at 02:09:21PM -0400, Jaroslav Reznik wrote: That sounds good. Maybe recast those ideas as three levels? - Critical Path Feature - Other Enhancement Feature - New Leaf Feature We were thinking with a few folks more about Self contained feature but yeah, there's a lack of real definition. I think Leaf is better than Self contained, since it's unlikely for the feature to have zero outside dependencies. I think it'd be fine for such a feature to rely on small changes to existing packages (version updates, say). I'd argue that this isn't a feature ... otherwise we could advertise every version upgrade as feature. If it does not affect a large amount of users it is simply a version upgrade not a fedora feature. The question is - how do you know if it affects large amount of users, it's not an important one, without letting people know, there's such feature? Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On Thu, Nov 1, 2012 at 7:45 PM, Jaroslav Reznik jrez...@redhat.com wrote: - Original Message - On Thu, Nov 1, 2012 at 7:34 PM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Nov 01, 2012 at 02:09:21PM -0400, Jaroslav Reznik wrote: That sounds good. Maybe recast those ideas as three levels? - Critical Path Feature - Other Enhancement Feature - New Leaf Feature We were thinking with a few folks more about Self contained feature but yeah, there's a lack of real definition. I think Leaf is better than Self contained, since it's unlikely for the feature to have zero outside dependencies. I think it'd be fine for such a feature to rely on small changes to existing packages (version updates, say). I'd argue that this isn't a feature ... otherwise we could advertise every version upgrade as feature. If it does not affect a large amount of users it is simply a version upgrade not a fedora feature. The question is - how do you know if it affects large amount of users, it's not an important one, without letting people know, there's such feature? Does a lot of other packages depend on it? - Likely affects a lot of users. Is it installed by default or a commonly used application / package ? - Likely affects a lot of users. Is it a new package that isn't intended to be installed by default? - Probably does not affects a lot of users. ... etc. So while there is no 100% accurate definition applying some common sense helps here. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On Thu, Nov 1, 2012 at 2:45 PM, Jaroslav Reznik jrez...@redhat.com wrote: - Original Message - On Thu, Nov 1, 2012 at 7:34 PM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Nov 01, 2012 at 02:09:21PM -0400, Jaroslav Reznik wrote: That sounds good. Maybe recast those ideas as three levels? - Critical Path Feature - Other Enhancement Feature - New Leaf Feature We were thinking with a few folks more about Self contained feature but yeah, there's a lack of real definition. I think Leaf is better than Self contained, since it's unlikely for the feature to have zero outside dependencies. I think it'd be fine for such a feature to rely on small changes to existing packages (version updates, say). I'd argue that this isn't a feature ... otherwise we could advertise every version upgrade as feature. If it does not affect a large amount of users it is simply a version upgrade not a fedora feature. The question is - how do you know if it affects large amount of users, it's not an important one, without letting people know, there's such feature? Version upgrades of _most_ packages are not features. When someone is updating or installing a new Fedora they _expect_ to be getting newer versions of packages already. It doesn't make much sense to update your local Fedora install if you aren't actually going to get new things. Coordination among the other packages in the distro should already be handled with ABI/soname change notifications in rawhide. In the rare case a package change some file format that users need to manually handle or otherwise be aware of, release notes can cover that under a special update section. It doesn't make that version update a feature. For things like Gnome 3.6, or KDE 4.whatever, or MATE, then sure a Feature might be warranted there. Those are clearly large undertakings that need to be carefully coordinated. Updating postgresql or gwibber or cowsay or less are not. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On Thu, Nov 01, 2012 at 07:41:21PM +0100, drago01 wrote: I think Leaf is better than Self contained, since it's unlikely for the feature to have zero outside dependencies. I think it'd be fine for such a feature to rely on small changes to existing packages (version updates, say). I'd argue that this isn't a feature ... otherwise we could advertise every version upgrade as feature. If it does not affect a large amount of users it is simply a version upgrade not a fedora feature. Sorry, I wasn't clear. It may be that some set of new functionality requires small version upgrades. The feature is the new functionality, not the version upgrades. An example: I want to propose Scratch, the educational programming language, as a feature for F19. It's not big, but it's popular and there's a new book, generating public interest so it'd be nice for it to be included in the process. Scratch itself is a new package. But it requires an update to Squeak VM in order to work properly. This is incidental to the feature itself -- so it'd be weird to classify this as an update to existing functionality -- but the feature isn't self contained. That said, a significant version upgrade to something _should_ be able to be a feature in itself. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On Thu, 2012-11-01 at 19:50 +0100, drago01 wrote: On Thu, Nov 1, 2012 at 7:45 PM, Jaroslav Reznik jrez...@redhat.com wrote: - Original Message - On Thu, Nov 1, 2012 at 7:34 PM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Nov 01, 2012 at 02:09:21PM -0400, Jaroslav Reznik wrote: That sounds good. Maybe recast those ideas as three levels? - Critical Path Feature - Other Enhancement Feature - New Leaf Feature We were thinking with a few folks more about Self contained feature but yeah, there's a lack of real definition. I think Leaf is better than Self contained, since it's unlikely for the feature to have zero outside dependencies. I think it'd be fine for such a feature to rely on small changes to existing packages (version updates, say). I'd argue that this isn't a feature ... otherwise we could advertise every version upgrade as feature. If it does not affect a large amount of users it is simply a version upgrade not a fedora feature. The question is - how do you know if it affects large amount of users, it's not an important one, without letting people know, there's such feature? Does a lot of other packages depend on it? - Likely affects a lot of users. Is it installed by default or a commonly used application / package ? - Likely affects a lot of users. Is it a new package that isn't intended to be installed by default? - Probably does not affects a lot of users. ... etc. So while there is no 100% accurate definition applying some common sense helps here. Well. It's worth considering the underlying problem here, which we've known about for a while: the feature process is overloaded. We use it for multiple purposes. In this thread we're mostly concerned with the aspects of the feature process that deal with genuine technical / QA issues: are we doing well enough at evaluating and overseeing features from a technical perspective. However, the feature process achieves other things too. The other obvious big one is publicity/documentation: that's the reason all these leaf features are made features at all, so they can be written up in our announcements and documentation. I think the direction we're driving here will actually address that problem too; if we split features into 'critpath' and 'leaf' (and maybe some other category/ies) we will be able to make the process more sane. For 'leaf' features we can concentrate on the PR/documentation stuff and we really don't have to worry too much about the technical / release schedule side of things for those features. So if we go down the road of categorizing features and do a good job of it, I think that rather makes the issue of 'why are these little things features at all?' go away. They'd be features simply for the PR, and we could codify that. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
The other thing that we mustn't forget are major changes that aren't put through the feature process, but slip in via the back door. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On Thu, Nov 01, 2012 at 08:13:57PM +, Richard W.M. Jones wrote: The other thing that we mustn't forget are major changes that aren't put through the feature process, but slip in via the back door. That's where the critpath vs. other enhancement distinction comes in -- for critpath we can be more strict about requiring the process without making it more onerous for other changes. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On 11/01/2012 08:13 PM, Richard W.M. Jones wrote: The other thing that we mustn't forget are major changes that aren't put through the feature process, but slip in via the back door. As far as I know you are not obligated to participate in the feature process and what do you exactly define as slip in via the back door ? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On Thu, 2012-11-01 at 21:28 +, Jóhann B. Guðmundsson wrote: On 11/01/2012 08:13 PM, Richard W.M. Jones wrote: The other thing that we mustn't forget are major changes that aren't put through the feature process, but slip in via the back door. As far as I know you are not obligated to participate in the feature process and what do you exactly define as slip in via the back door ? 'not participate in the feature process', I think =) I think I once proposed that FESCo should formally have the ability to declare that a given change ought to be a feature and force it through the feature process, but that proposal was rejected. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On Thu, Nov 01, 2012 at 02:43:00PM -0700, Adam Williamson wrote: I think I once proposed that FESCo should formally have the ability to declare that a given change ought to be a feature and force it through the feature process, but that proposal was rejected. I think that requiring the feature process for major critical path changes is at least the platonic ideal, even if we're not at a point where we can do it yet. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
