Re: features and percentages [was Re: RFC: Feature process improvements]
On 12/05/2012 09:38 PM, Matthew Miller wrote: One approach: a convention where each feature gets a tracking bug, and then various tasks can be marked as blocking that. *Then*, each release can have a tracking bug for accepted features themselves, and the tool to produce the chart can simply be pointed at that and follow the tree downward. Trackign them in bugzilla makes so much sense and seems so blatantly obvious now that you said it... its kinda hard to understand why that hasn't been done from the start. Please make it so :) - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: features and percentages [was Re: RFC: Feature process improvements]
Dne 6.12.2012 10:14, Panu Matilainen napsal(a): On 12/05/2012 09:38 PM, Matthew Miller wrote: One approach: a convention where each feature gets a tracking bug, and then various tasks can be marked as blocking that. *Then*, each release can have a tracking bug for accepted features themselves, and the tool to produce the chart can simply be pointed at that and follow the tree downward. Trackign them in bugzilla makes so much sense and seems so blatantly obvious now that you said it... its kinda hard to understand why that hasn't been done from the start. Please make it so :) - Panu - Don't think it makes more sense then the percentage in wiki. I remember migration from Ruby 1.8.7 to Ruby 1.9.3. We needed to adjust every ruby package in fedora and rebuild them. Some of them were piece of cake, some needed patches, other packages needed to be retired and some of them replaced. Not sure how could bugzilla provide better estimates. Even tracking of this issues in BZ would be significant overhead. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: features and percentages [was Re: RFC: Feature process improvements]
On 12/06/2012 12:50 PM, Vít Ondruch wrote: Dne 6.12.2012 10:14, Panu Matilainen napsal(a): On 12/05/2012 09:38 PM, Matthew Miller wrote: One approach: a convention where each feature gets a tracking bug, and then various tasks can be marked as blocking that. *Then*, each release can have a tracking bug for accepted features themselves, and the tool to produce the chart can simply be pointed at that and follow the tree downward. Trackign them in bugzilla makes so much sense and seems so blatantly obvious now that you said it... its kinda hard to understand why that hasn't been done from the start. Please make it so :) - Panu - Don't think it makes more sense then the percentage in wiki. I remember migration from Ruby 1.8.7 to Ruby 1.9.3. We needed to adjust every ruby package in fedora and rebuild them. Some of them were piece of cake, some needed patches, other packages needed to be retired and some of them replaced. Not sure how could bugzilla provide better estimates. Even tracking of this issues in BZ would be significant overhead. I dont see anybody suggesting tracking a feature requiring mass-rebuilds on single package level. If a feature requires substantial mass-rebuilds, then the mass-rebuild tracker might be *one* bug where the mass-rebuild progress is tracked, and on which the feature depends. And hard-to-resolve rebuilds which require significant extra work could be tracked in their own bugs which in turn block the main mass-rebuild bug. Or something like that. As the current feature percentage meter means absolutely nothing at all, its kinda hard to do worse than that :) - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: features and percentages [was Re: RFC: Feature process improvements]
- Original Message - On Wed, Nov 28, 2012 at 09:39:03PM -0500, John Dulaney wrote: a feature, especially a crit path feature, is not ready for prime time. Obviously, if a feature is not %100 by feature freeze, then it needs to be dropped. I would even venture to suggest that we include in the SOP something along the lines of If feature is not 80% by point X (X being two weeks prior to freeze), then FESCo should at that point evaluate enacting the fall back. I don't think percent-complete is very helpful. The numbers are often completely arbitrary, and even if they are actually accurate to that project hard to compare in a relative sense. 80% of a small feature may be far closer to complete than 99% of a major one. That's the reason why I tried to ask feature owners to provide a comment, not only percentage update as what's important for us is - what's needed to get feature completed not how far do we think we are. As even that last 1% could be a show stopper and also it's not easily comparable as you said. For Feature tracking on wiki - it's really very suboptimal, hard to update manually (especially the Feature List), it has to be in sync with Feature page Status Section... Using Categories often leads to disappearing of Feature due to errors (FeatureReadFESCo and you have a problem). At FUDCon Milan, we discussed using Trac to manage Spin process - it's actually very similar process. And for tracking stuff I think it's more suitable than Bugzilla - custom states, better overviews + use Wiki just for feature description/overview as it's easier editable than Trac ticket. I already added Feature Process component to Project Schedule trac - I can try to draft it (and set it up there). Also FESCo voting on Features could be moved from theirs Trac as it's quite polluting it (but it really depends - another Trac instance, you're kidding...). For F19 we try the smaller steps as the process should be running right now and submission deadline is in month and half. But I'd like to call FUDCon session on making features/development/scheduling better - as it's very closely tight together... Jaroslav I like burndown charts. Low overhead, easily read, and generally more concrete than guesses at percentage done. I wonder if there's a way we can easily provide a widget in the wiki for keeping them up to date. This: http://joel.inpointform.net/software-development/burn-down-charts-tutorial-simple-agile-project-tracking/ has a decent Google Docs template, but we wouldn't want to make that requirement for our process. -- 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: features and percentages [was Re: RFC: Feature process improvements]
On Thu, Dec 06, 2012 at 11:14:19AM +0200, Panu Matilainen wrote: Trackign them in bugzilla makes so much sense and seems so blatantly obvious now that you said it... its kinda hard to understand why that hasn't been done from the start. Please make it so :) https://fedorahosted.org/fesco/ticket/979 -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: features and percentages [was Re: RFC: Feature process improvements]
On Thu, Dec 06, 2012 at 08:11:01AM -0500, Jaroslav Reznik wrote: At FUDCon Milan, we discussed using Trac to manage Spin process - it's actually very similar process. And for tracking stuff I think it's more suitable than Bugzilla - custom states, better overviews + use Wiki just for feature description/overview as it's easier editable than Trac ticket. The reason I like Bugzilla over Trac for this is that it's easy to link the actual work (in the form of bugzilla entries against packages), which reduces the overhead by making it almost automatic once the tracking bug is set up. By contrast, a Trac instance would need to be manually updated and maintained, wouldn't it? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: features and percentages [was Re: RFC: Feature process improvements]
On Thu, Dec 06, 2012 at 11:50:01AM +0100, Vít Ondruch wrote: Don't think it makes more sense then the percentage in wiki. I remember migration from Ruby 1.8.7 to Ruby 1.9.3. We needed to adjust every ruby package in fedora and rebuild them. Some of them were piece of cake, some needed patches, other packages needed to be retired and some of them replaced. Not sure how could bugzilla provide better estimates. Even tracking of this issues in BZ would be significant overhead. This is the kind of overhead professional software engineers work with all the time. :) But in seriousness, back when I was running the BU Linux distribution, we did this in our bugzilla for mass updates covering small amounts of work to large numbers of packges, and it was actually really helpful. (We used a custom script to bulk file the bugs.) The ones that are a piece of cake get closed quickly, and for the rest you can track what's going on with those packages and replacements and so on. But, I don't think we'd mandate that rebuilds like you describe would *have* to happen that way. There could simply be a single rebuild all x because yy for zz bug covering all that work, with blockers spawned from that for the tricky cases. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: features and percentages [was Re: RFC: Feature process improvements]
On Thu, Dec 6, 2012 at 1:04 PM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Dec 06, 2012 at 08:11:01AM -0500, Jaroslav Reznik wrote: At FUDCon Milan, we discussed using Trac to manage Spin process - it's actually very similar process. And for tracking stuff I think it's more suitable than Bugzilla - custom states, better overviews + use Wiki just for feature description/overview as it's easier editable than Trac ticket. The reason I like Bugzilla over Trac for this is that it's easy to link the actual work (in the form of bugzilla entries against packages), which reduces the overhead by making it almost automatic once the tracking bug is set up. By contrast, a Trac instance would need to be manually updated and maintained, wouldn't it? Trac is also horrible to work in. Bugzilla isn't leaps and bounds better but at least it sends reasonable plain-text emails that don't have horrible wiki syntax in them. Thank you for avoiding new suggested uses of trac. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
features and percentages [was Re: RFC: Feature process improvements]
On Wed, Nov 28, 2012 at 09:39:03PM -0500, John Dulaney wrote: a feature, especially a crit path feature, is not ready for prime time. Obviously, if a feature is not %100 by feature freeze, then it needs to be dropped. I would even venture to suggest that we include in the SOP something along the lines of If feature is not 80% by point X (X being two weeks prior to freeze), then FESCo should at that point evaluate enacting the fall back. I don't think percent-complete is very helpful. The numbers are often completely arbitrary, and even if they are actually accurate to that project hard to compare in a relative sense. 80% of a small feature may be far closer to complete than 99% of a major one. I like burndown charts. Low overhead, easily read, and generally more concrete than guesses at percentage done. I wonder if there's a way we can easily provide a widget in the wiki for keeping them up to date. This: http://joel.inpointform.net/software-development/burn-down-charts-tutorial-simple-agile-project-tracking/ has a decent Google Docs template, but we wouldn't want to make that requirement for our process. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: features and percentages [was Re: RFC: Feature process improvements]
On Wed, Dec 05, 2012 at 08:19:15PM +0100, Fabian Deutsch wrote: I like burndown charts. Low overhead, easily read, and generally more concrete than guesses at percentage done. I wonder if there's a way we can easily provide a widget in the wiki for keeping them up to date. This: http://joel.inpointform.net/software-development/burn-down-charts-tutorial-simple-agile-project-tracking/ has a decent Google Docs template, but we wouldn't want to make that requirement for our process. I must say that the Ubuntu folks are distilling their bugzilla informations quite well on http://status.ubuntu.com/ubuntu-raring/ . The good thing about this solution is, that bugzilla is (AFAIK) used to track the progress of a feature - and using bugzilla could be also a doable to track our features. Well, it's their launchpad bug tracker, not bugzilla. It's a great idea, though. Anyone want to volunteer to write something that extracts data from our bugzilla and presents it in this format? One approach: a convention where each feature gets a tracking bug, and then various tasks can be marked as blocking that. *Then*, each release can have a tracking bug for accepted features themselves, and the tool to produce the chart can simply be pointed at that and follow the tree downward. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: features and percentages [was Re: RFC: Feature process improvements]
On Wed, Dec 05, 2012 at 08:19:15PM +0100, Fabian Deutsch wrote: I like burndown charts. Low overhead, easily read, and generally more concrete than guesses at percentage done. I wonder if there's a way we can easily provide a widget in the wiki for keeping them up to date. This: http://joel.inpointform.net/software-development/burn-down-charts-tutorial-simple-agile-project-tracking/ has a decent Google Docs template, but we wouldn't want to make that requirement for our process. I must say that the Ubuntu folks are distilling their bugzilla informations quite well on http://status.ubuntu.com/ubuntu-raring/ . The good thing about this solution is, that bugzilla is (AFAIK) used to track the progress of a feature - and using bugzilla could be also a doable to track our features. Well, it's their launchpad bug tracker, not bugzilla. It's a great idea, though. Anyone want to volunteer to write something that extracts data from our bugzilla and presents it in this format? Ah yes, it's launchpad ... One approach: a convention where each feature gets a tracking bug, and then various tasks can be marked as blocking that. *Then*, each release can have a tracking bug for accepted features themselves, and the tool to produce the chart can simply be pointed at that and follow the tree downward. Yes - I think that's a good convention in general, to have tracker bugs for all features requested for a new release. And this convention can be independent from the tool visualizing the resulting bug tree. We could even start with a blocker bug for a release itself. - fabian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: features and percentages [was Re: RFC: Feature process improvements]
One approach: a convention where each feature gets a tracking bug, and then various tasks can be marked as blocking that. *Then*, each release can have a tracking bug for accepted features themselves, and the tool to produce the chart can simply be pointed at that and follow the tree downward. Yeah. This makes sense. Wiki for tracking isn't a bright idea really. Even package wishlists could be converted into bug reports like Debian does. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: features and percentages [was Re: RFC: Feature process improvements]
* Rahul Sundaram [06/12/2012 00:39] : Yeah. This makes sense. Wiki for tracking isn't a bright idea really. And the time-tracking is already built in to bugzilla so most of the code needed is already written. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Feature process improvements
On 12/01/2012 02:26 AM, Adam Williamson wrote: On Fri, 2012-11-30 at 12:21 -0500, Matthew Miller wrote: On Thu, Nov 29, 2012 at 05:42:15AM -0500, Marcela Maslanova wrote: I think we do need more clarity on system-wide/defaults changing features or critical path components. What's the threshold for defaults? (LVM, for a specific example.) What's the threshold for a change to a critical path component? We were discussing even critpaths, but currently is in critical path almost everything. If true, I think that asking for clarity on the thresholds is even more important. If almost everything really is on the critical path, we need to either a) find a way to reduce that or b) recognize it and treat features more carefully. It's not really true, no, though it can seem that way. https://admin.fedoraproject.org/pkgdb/lists/critpath?tg_format=plaincollctn_list=f18 is the current F18 critpath list. It's 583 packages; quite big, but a long way from 'almost everything'. That's short. I thought KDE and GNOME will be bigger, but there are only the essential packages. I guess critpaths as system-wide features might be doable. -- Marcela Mašláňová BaseOS team Brno -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Feature process improvements
Dne 30.11.2012 18:16, Matthew Miller napsal(a): On Fri, Nov 30, 2012 at 03:28:52PM +0100, Vít Ondruch wrote: I'd love to see the feature process to be turned opposite, i.e. make the feature auto-approved as default. It could look like: In general, features _have_ been approved by default, so in practice, this isn't a major change. It particularly makes sense for leaf features. I missed to point out that another advantage of this proposal is that you don't need to specify what is leaf/self contained feature ;) Although everybody understands what the leaf feature is, it is not always so clear in reality. 3) There might be some period, let say one week, for community review and discussion (of course this period might get extended for some controversial features) Having a devel-announce message for each feature seems good, ideally with some standard subject tag for filtering. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Feature process improvements
Hello, On Thu, Nov 29, 2012 at 12:32 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: Lacks clarification on what's considered an feature. The proposal continues to use the current wide definition - it only treats some differently. Arguably it should be mandatory for feature owners to provide or work with the documentation and or marketing communities documenting and publishing what benefits changes their feature brings to users/community/the distribution in whole etc. I think the existing feature template is supposed to already cover that. Is there something missing? Will it still be optional to participate in the feature process? That's one of the aspects of the feature process not addressed by this proposal. (To make the feature process mandatory, we would also have a mechanism to enforce this requirement - which is a pretty large can of worms.) Ideally, everybody affected by a change should already be notified per the current policy (http://fedoraproject.org/wiki/Package_maintainer_responsibilities#Notify_others_of_changes_that_may_affect_their_packages ). How much that happens in practice is another matter, unfortunately. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Feature process improvements
On Thu, Nov 29, 2012 at 1:21 AM, Matthew Miller mat...@fedoraproject.org wrote: I think we do need more clarity on system-wide/defaults changing features or critical path components. What's the threshold for defaults? (LVM, for a specific example.) What's the threshold for a change to a critical path component? I don't think we need a strict definition; in the proposal anyone can ask FESCo to consider a feature 'complex', so in practice, the threshold would be somebody asked FESCo to (and of course, that somebody can be the feature owner). Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Feature process improvements
On Thu, Nov 29, 2012 at 10:50 AM, Richard W.M. Jones rjo...@redhat.com wrote:
Well fair enough, but at the moment these have to go through the
feature process, which is extremely cumbersome for a routine upgrade.
Take a look at:
https://fedoraproject.org/wiki/Features/GHC741
That's a huge amount of text for a routine version bump in a set of
minor packages.
A naive count[1] makes that 421 packages, which is a huge number.
OTOH this feature is exactly one of the cases we had in mind for the
self-contained feature case, where a language SIG that owns all
affected packages can use the lightweight process.
We do need to specify in more detail the feature template sections
that would be not required in the lightweight process, though.
Mirek
[1] repoquery -a 'ghc*' --qf '%{name}' |sort -u |wc -l
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Feature process improvements
On Fri, Nov 30, 2012 at 04:31:51PM +0100, Miloslav Trmač wrote: I think we do need more clarity on system-wide/defaults changing features or critical path components. What's the threshold for defaults? (LVM, for a specific example.) What's the threshold for a change to a critical path component? I don't think we need a strict definition; in the proposal anyone can ask FESCo to consider a feature 'complex', so in practice, the threshold would be somebody asked FESCo to (and of course, that somebody can be the feature owner). Then I think this fails to address the primary problem. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Feature process improvements
On Fri, Nov 30, 2012 at 03:28:52PM +0100, Vít Ondruch wrote: I'd love to see the feature process to be turned opposite, i.e. make the feature auto-approved as default. It could look like: In general, features _have_ been approved by default, so in practice, this isn't a major change. It particularly makes sense for leaf features. 3) There might be some period, let say one week, for community review and discussion (of course this period might get extended for some controversial features) Having a devel-announce message for each feature seems good, ideally with some standard subject tag for filtering. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Feature process improvements
On Thu, Nov 29, 2012 at 05:42:15AM -0500, Marcela Maslanova wrote: I think we do need more clarity on system-wide/defaults changing features or critical path components. What's the threshold for defaults? (LVM, for a specific example.) What's the threshold for a change to a critical path component? We were discussing even critpaths, but currently is in critical path almost everything. If true, I think that asking for clarity on the thresholds is even more important. If almost everything really is on the critical path, we need to either a) find a way to reduce that or b) recognize it and treat features more carefully. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Feature process improvements
On Fri, 2012-11-30 at 12:21 -0500, Matthew Miller wrote: On Thu, Nov 29, 2012 at 05:42:15AM -0500, Marcela Maslanova wrote: I think we do need more clarity on system-wide/defaults changing features or critical path components. What's the threshold for defaults? (LVM, for a specific example.) What's the threshold for a change to a critical path component? We were discussing even critpaths, but currently is in critical path almost everything. If true, I think that asking for clarity on the thresholds is even more important. If almost everything really is on the critical path, we need to either a) find a way to reduce that or b) recognize it and treat features more carefully. It's not really true, no, though it can seem that way. https://admin.fedoraproject.org/pkgdb/lists/critpath?tg_format=plaincollctn_list=f18 is the current F18 critpath list. It's 583 packages; quite big, but a long way from 'almost everything'. -- 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: RFC: Feature process improvements
On Wed, Nov 28, 2012 at 03:56:04PM -0600, Chris Adams wrote: Once upon a time, Richard W.M. Jones rjo...@redhat.com said: * Simplifying the process for self-contained features (e.g. individual package version upgrades) I don't see why these are features at all. Surely it's better towards the end of each release cycle for someone to compare the versions of packages and add something in the release notes for each major GUI / programming language / user application that got a big update. Rather than make someone review a whole bunch of stuff, it would be much easier for maintainers to submit what they are doing. Frankly, if a maintainer doesn't think it is worth their while to announce a major change, then it isn't worth someone else's time to sift through the whole distribution and look for notable changes. Well fair enough, but at the moment these have to go through the feature process, which is extremely cumbersome for a routine upgrade. Take a look at: https://fedoraproject.org/wiki/Features/GHC741 That's a huge amount of text for a routine version bump in a set of minor packages. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Feature process improvements
- Original Message - From: Jóhann B. Guðmundsson johan...@gmail.com To: devel@lists.fedoraproject.org Sent: Thursday, November 29, 2012 12:32:35 AM Subject: Re: RFC: Feature process improvements On 11/28/2012 08:08 PM, Miloslav Trmač wrote: Hello, this proposal was recently linked in various places, so let's formally introduce it: https://fedoraproject.org/wiki/User:Mmaslano/Feature_process This an incremental change, not a major overhaul designed to solve all problems. The benefits expected from this proposal: * Making proposed features more visible to Fedora contributors, and making it easier for Fedora contributors to discuss the feature before FESCo votes on it. * Simplifying the process for self-contained features (e.g. individual package version upgrades) * Getting FESCo more involved in scheduling and testing of features with large impact on the rest of the distribution or schedule. * Making sure some frequently forgotten-about items, like rel-eng impact, are included in the feature proposal. For details, please see the proposal at the above-mentioned link. Marcela Mašláňová, Tomáš Mráz, Jaroslav Řezník, Miloslav Trmač Lacks clarification on what's considered an feature. Arguably it should be mandatory for feature owners to provide or work with the documentation and or marketing communities documenting and publishing what benefits changes their feature brings to users/community/the distribution in whole etc. it's just absurd having us ( QA ) adjusting release criteria while we are trying to follow it so feature that might affect the current release criteria and or critical components will need to be approved by QA before alpha so we can but not be limited to making the necessary changes to the release criteria in due time and make sure proper testing takes place and each approved feature arguably should have associated test day with it ( if relevant ). Will it still be optional to participate in the feature process? JBG The discussion about features on f-d could help QA to focus on important changes, don't you think? Or would you prefer something else what could help QA? I'd rather see feature process for wide system changes mandatory. People are complaining about features, which went terribly wrong. I don't see any other way than control their progress better and help feature owners with stuff around (broken dependencies etc.). Also in the past some features weren't announced at all and than later added because they didn't work well. For example upgrade of Java (I'm not picking on Java, just remember this one, but there were surely more). -- Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Feature process improvements
- Original Message - From: Matthew Miller mat...@fedoraproject.org To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Thursday, November 29, 2012 1:21:01 AM Subject: Re: RFC: Feature process improvements On Wed, Nov 28, 2012 at 09:08:59PM +0100, Miloslav Trmač wrote: this proposal was recently linked in various places, so let's formally introduce it: https://fedoraproject.org/wiki/User:Mmaslano/Feature_process As discussed earlier, I liked the three-tier approach better, but I'm in favor of any improvement, which I think this clearly is. I think we do need more clarity on system-wide/defaults changing features or critical path components. What's the threshold for defaults? (LVM, for a specific example.) What's the threshold for a change to a critical path component? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org We were discussing even critpaths, but currently is in critical path almost everything. Maybe splitting packages into tiers wouldn't be bad, but I have no idea how to do it. -- Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Feature process improvements
- Original Message - From: Richard W.M. Jones rjo...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Thursday, November 29, 2012 10:50:48 AM Subject: Re: RFC: Feature process improvements On Wed, Nov 28, 2012 at 03:56:04PM -0600, Chris Adams wrote: Once upon a time, Richard W.M. Jones rjo...@redhat.com said: * Simplifying the process for self-contained features (e.g. individual package version upgrades) I don't see why these are features at all. Surely it's better towards the end of each release cycle for someone to compare the versions of packages and add something in the release notes for each major GUI / programming language / user application that got a big update. Rather than make someone review a whole bunch of stuff, it would be much easier for maintainers to submit what they are doing. Frankly, if a maintainer doesn't think it is worth their while to announce a major change, then it isn't worth someone else's time to sift through the whole distribution and look for notable changes. Well fair enough, but at the moment these have to go through the feature process, which is extremely cumbersome for a routine upgrade. Take a look at: https://fedoraproject.org/wiki/Features/GHC741 That's a huge amount of text for a routine version bump in a set of minor packages. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top Yes, but the feature owners surely wants proper testing. We were also wondering if some features couldn't be acked only by SIG. For example ghc SIG could be fine with update proposal and write only release note for marketing, couldn't they? -- Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Feature process improvements
On Wed, 2012-11-28 at 16:03 -0600, Bruno Wolff III wrote: On Wed, Nov 28, 2012 at 15:01:21 -0700, There are several mechanisms for a developer to get their work into the release notes. The rel-notes BZ tag was wholly unused during this cycle, to the best of my knowledge. There were no bugs filed against the release-notes bugzilla product to request inclusion. When no emails were sent to the Docs mailing list, we put out a request on devel-announce for developers to get in touch; the only person that responded already had a well composed Feature page for us to work from. There was at least one bug where I suggested getting a release note in. But I didn't know of rel-notes tag. It's actually 'fedora_requires_release_note' - you can find it with the other, more familiar tags. The response from Chris reminded me of the value of brevity, so I'll add one comment before leaving the discussion to those qualified to participate: Documenting a distribution is a lot like law enforcement. You might get results from routine patrols, but it is largely a complaint-driven venture. --pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Feature process improvements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Nov 29, 2012 at 08:31:25AM -0700, pete wrote: It's actually 'fedora_requires_release_note' - you can find it with the other, more familiar tags. The response from Chris reminded me of the value of brevity, so I'll add one comment before leaving the discussion to those qualified to participate: Documenting a distribution is a lot like law enforcement. You might get results from routine patrols, but it is largely a complaint-driven venture. I've not heard truer words spoken. At this late date if there isn't something already in the Release Notes that should be it would be good to just open a bug against the Release Notes. By the way, if you don't know how the Release Notes are created it would be good to look at the Beats[0] which then get churned into DocBookXML and extruded through Publican to create the pretty final product. The Docs Project is always looking for new/additional content writers for these Beats. [0] https://fedoraproject.org/wiki/Category:Documentation_beats - --Eric -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJQt4rbAAoJEIB2q94CS7PRUKkP/i5kyQG/8DXvXiGEwFhgvlSX BTAqSNfUsKtBqRFZBmdR1U6b60nKdv3sHEODJKgVBUK13gPOHQ4F1584m62JtQxC sHq2TsbKMih1rtfXqBAnkiMBfY9H0V6qZYq8udayTjhIuEnak1bS1BcVKxpRRHQg LvUANaH0jGxjwamcsNOQMMuzfVfDdkkfQoVYpYPh1T9I5Uvnmcym7hTdz90K4EJu TwDlSOtP6YM/kVE1bU0X3IFivPua1n+R5SQubmEDiCUCmeiWZ+PnY3o+a5U75z7r VQXhet3VZfmUSljVofZpjNSSeDVqmSxpmWyXrB7hhbZvKqGTJb5F6f7cBQer4/lv BCmgdAZFaFYLDLTPgc2RKtMoEOGCaAnARwJQQCuxxYmta/LhfeZFY6lZJp875DUR AUuQp+rSsdHUGzNv9tKYtXKDONF604qK657CVzZeG9ZuztTLtwKoTStJb3LQcCKU gqJwgvSi3BBsmDy4X/ps9W1NTXg8di30Rb6yHZv0hKaJpFZeAOwVIPWM+u1R5do0 xN2JSUUKXobWPiBKnQEXc2WiRQmX5syyzC9m6E4DoFCwPcVFf32ZBJY7FCeNXzS5 pObUFUljQafb8nE1FnsLvX6ov8BQ12VSLbf5HlxFMJvF1qChUNgg2iM4wJyd4QYa HujSu2uLrqr9qbwpvaJR =xDNV -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Feature process improvements
On Thu, 2012-11-29 at 05:38 -0500, Marcela Maslanova wrote: Lacks clarification on what's considered an feature. Arguably it should be mandatory for feature owners to provide or work with the documentation and or marketing communities documenting and publishing what benefits changes their feature brings to users/community/the distribution in whole etc. it's just absurd having us ( QA ) adjusting release criteria while we are trying to follow it so feature that might affect the current release criteria and or critical components will need to be approved by QA before alpha so we can but not be limited to making the necessary changes to the release criteria in due time and make sure proper testing takes place and each approved feature arguably should have associated test day with it ( if relevant ). Will it still be optional to participate in the feature process? JBG The discussion about features on f-d could help QA to focus on important changes, don't you think? Or would you prefer something else what could help QA? I'd rather see feature process for wide system changes mandatory. People are complaining about features, which went terribly wrong. I don't see any other way than control their progress better and help feature owners with stuff around (broken dependencies etc.). Also in the past some features weren't announced at all and than later added because they didn't work well. For example upgrade of Java (I'm not picking on Java, just remember this one, but there were surely more). I'm not sure you two are necessarily disagreeing with each other. Johann's mail implies a distinction between two types of feature, which is a common theme of this discussion, and to an extent encoded in your draft, Marcela: so feature that might affect the current release criteria and or critical components will need to be approved by QA before alpha I think ultimately Johann's mail boils down to a suggestion for how to categorize features - by whether they stand a realistic chance of having an impact on release readiness - and a suggestion that features which fall into this category should require QA signoff. Speaking personally - not for the QA team, we do not have an agreed position on this proposal - I'm always reluctant with the concept of QA 'approval' of a feature, I don't think it's appropriate for QA to have a veto on the approval or rejection of a feature in toto. But I agree with Johann that QA can provide important input about whether a feature will be sensitive from a release readiness point of view, and what needs to be done for such features to try and ensure they don't cause release delays: viable contingency plans, test planning, code completion points, etc etc. I'm not sure I want us to have a no-matter-what line-item-veto on features, but I do think we should be able to set a very high bar for a feature which looks like it could be seriously disruptive to release quality and which does not appear to have a viable contingency plan, or a realistic development schedule, or something like 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: RFC: Feature process improvements
It's not clear where this should be discussed? Editing the wiki talk page? On this list? Anyway, I'll kick this off by saying: * Simplifying the process for self-contained features (e.g. individual package version upgrades) I don't see why these are features at all. Surely it's better towards the end of each release cycle for someone to compare the versions of packages and add something in the release notes for each major GUI / programming language / user application that got a big update. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Feature process improvements
Once upon a time, Richard W.M. Jones rjo...@redhat.com said: * Simplifying the process for self-contained features (e.g. individual package version upgrades) I don't see why these are features at all. Surely it's better towards the end of each release cycle for someone to compare the versions of packages and add something in the release notes for each major GUI / programming language / user application that got a big update. Rather than make someone review a whole bunch of stuff, it would be much easier for maintainers to submit what they are doing. Frankly, if a maintainer doesn't think it is worth their while to announce a major change, then it isn't worth someone else's time to sift through the whole distribution and look for notable changes. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Feature process improvements
I don't see why these are features at all. Surely it's better towards the end of each release cycle for someone to compare the versions of packages and add something in the release notes for each major GUI / programming language / user application that got a big update. Rich. I only have a comment relative to the release notes. I agree that the release notes are the appropriate place to 'feature' changes that might not meet the requirements of a 'Feature' . Comparing the version numbers is even relatively easy - we use a script for the Technical Notes that parses repository sqlite meta data and effectively spits out the fully formed TNs. This doesn't scale well to the verbose content expected in the release notes. A human still needs to identify changes, apply context, interpret scope and write the actual content. Determining what should be included and what changed is labor intensive. There are several mechanisms for a developer to get their work into the release notes. The rel-notes BZ tag was wholly unused during this cycle, to the best of my knowledge. There were no bugs filed against the release-notes bugzilla product to request inclusion. When no emails were sent to the Docs mailing list, we put out a request on devel-announce for developers to get in touch; the only person that responded already had a well composed Feature page for us to work from. So here's my suggestion : The guidelines for Features, however they turn out, should direct developers to contacting the Docs team in some way if the feature requirements are not met. We can still give our hard working contributors the appropriate exposure, but there are *far* more developers than docs maintainers and we need their help. --Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Feature process improvements
On Wed, Nov 28, 2012 at 15:01:21 -0700, There are several mechanisms for a developer to get their work into the release notes. The rel-notes BZ tag was wholly unused during this cycle, to the best of my knowledge. There were no bugs filed against the release-notes bugzilla product to request inclusion. When no emails were sent to the Docs mailing list, we put out a request on devel-announce for developers to get in touch; the only person that responded already had a well composed Feature page for us to work from. There was at least one bug where I suggested getting a release note in. But I didn't know of rel-notes tag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Feature process improvements
On 11/28/2012 08:08 PM, Miloslav Trmač wrote: Hello, this proposal was recently linked in various places, so let's formally introduce it: https://fedoraproject.org/wiki/User:Mmaslano/Feature_process This an incremental change, not a major overhaul designed to solve all problems. The benefits expected from this proposal: * Making proposed features more visible to Fedora contributors, and making it easier for Fedora contributors to discuss the feature before FESCo votes on it. * Simplifying the process for self-contained features (e.g. individual package version upgrades) * Getting FESCo more involved in scheduling and testing of features with large impact on the rest of the distribution or schedule. * Making sure some frequently forgotten-about items, like rel-eng impact, are included in the feature proposal. For details, please see the proposal at the above-mentioned link. Marcela Mašláňová, Tomáš Mráz, Jaroslav Řezník, Miloslav Trmač Lacks clarification on what's considered an feature. Arguably it should be mandatory for feature owners to provide or work with the documentation and or marketing communities documenting and publishing what benefits changes their feature brings to users/community/the distribution in whole etc. it's just absurd having us ( QA ) adjusting release criteria while we are trying to follow it so feature that might affect the current release criteria and or critical components will need to be approved by QA before alpha so we can but not be limited to making the necessary changes to the release criteria in due time and make sure proper testing takes place and each approved feature arguably should have associated test day with it ( if relevant ). Will it still be optional to participate in the feature process? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Feature process improvements
On Wed, Nov 28, 2012 at 09:23:09PM +, Richard W.M. Jones wrote: * Simplifying the process for self-contained features (e.g. individual package version upgrades) I don't see why these are features at all. Surely it's better towards the end of each release cycle for someone to compare the versions of Major package upgrades certainly often represent features in the English-language and common usage sense from an end-user point of view. I think it's perfectly reasonable to leave that in the features process. It's not just the end of the cycle where it's interesting -- people like to look and see what's in progress. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Feature process improvements
On Wed, Nov 28, 2012 at 09:08:59PM +0100, Miloslav Trmač wrote: this proposal was recently linked in various places, so let's formally introduce it: https://fedoraproject.org/wiki/User:Mmaslano/Feature_process As discussed earlier, I liked the three-tier approach better, but I'm in favor of any improvement, which I think this clearly is. I think we do need more clarity on system-wide/defaults changing features or critical path components. What's the threshold for defaults? (LVM, for a specific example.) What's the threshold for a change to a critical path component? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Feature process improvements
I would suggest that we create a clear SOP for fall back planning in case a feature, especially a crit path feature, is not ready for prime time. Obviously, if a feature is not %100 by feature freeze, then it needs to be dropped. I would even venture to suggest that we include in the SOP something along the lines of If feature is not 80% by point X (X being two weeks prior to freeze), then FESCo should at that point evaluate enacting the fall back. John. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
