Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
On Fri, 2012-12-07 at 20:11 +0100, Till Maas wrote: On Wed, Dec 05, 2012 at 03:20:14PM -0500, Bill Nottingham wrote: * 960 - F18 schedule + the holidays (notting, 18:50:29) * LINK: https://fedoraproject.org/wiki/JaroslavReznik/FedupF18Final - not updated yet (jreznik, 18:58:15) * AGREED: Do not block on fedup signature checking (not a regression) (+:7, -:0, 0:0) (notting, 19:08:47) how is not providing a supported way to do secure upgrade of Fedora not a regression? If you read the IRC logs and not just the summary, this was all laid out there. It is part of the background in the bug: https://bugzilla.redhat.com/show_bug.cgi?id=877623#c13 And what is even worse, the whole problem of not verifying packages on upgrade or the upgrade image itself is not even prominently communicated. There is nothing in the release notes about this: http://docs.fedoraproject.org/en-US/Fedora/18/html/Release_Notes/sect-Release_Notes-Changes_for_Sysadmin.html#idm32350976 It would have been premature to put it in the release notes before this decision was made, obviously. What would've been the point of writing it into the release notes if FESCo had said 'this has to be fixed before we release F18'? You nominated the bug as requiring a release note on 29th November, then complained that it wasn't in the release notes on 7th December - basically you gave the docs team about a week of turnaround time, which isn't a heck of a lot with a release with as many changes as F18. -- 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: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
On Sat, Dec 08, 2012 at 12:10:36AM -0800, Adam Williamson wrote: On Fri, 2012-12-07 at 20:11 +0100, Till Maas wrote: On Wed, Dec 05, 2012 at 03:20:14PM -0500, Bill Nottingham wrote: * 960 - F18 schedule + the holidays (notting, 18:50:29) * LINK: https://fedoraproject.org/wiki/JaroslavReznik/FedupF18Final - not updated yet (jreznik, 18:58:15) * AGREED: Do not block on fedup signature checking (not a regression) (+:7, -:0, 0:0) (notting, 19:08:47) how is not providing a supported way to do secure upgrade of Fedora not a regression? If you read the IRC logs and not just the summary, this was all laid out there. It is part of the background in the bug: https://bugzilla.redhat.com/show_bug.cgi?id=877623#c13 There it is only mentioned, that there were possibilities to do insecure updates. The big change is, that now only insecure updates are possible. And what is even worse, the whole problem of not verifying packages on upgrade or the upgrade image itself is not even prominently communicated. There is nothing in the release notes about this: http://docs.fedoraproject.org/en-US/Fedora/18/html/Release_Notes/sect-Release_Notes-Changes_for_Sysadmin.html#idm32350976 It would have been premature to put it in the release notes before this decision was made, obviously. What would've been the point of writing it into the release notes if FESCo had said 'this has to be fixed before we release F18'? Since the release notes for the Beta release point to the final release notes (as of yesterday they did actually point to the release notes for Fedora 13 in the wiki), it should be mentioned there already. It can still be removed if it is to be fixed. You nominated the bug as requiring a release note on 29th November, then complained that it wasn't in the release notes on 7th December - basically you gave the docs team about a week of turnaround time, which isn't a heck of a lot with a release with as many changes as F18. The whole update process and procedure using fedup is afaik not even properly designed or communicated. If I remember correctly for a long time only vague information about a new update tool to be written were posted to the devel list. And even now it is totally unclear how it will work. On the other hand the Beta should be used for upgrade testing. Publishing it before it is ready and all information is available is the problem. If more time is needed to properly document it, then the time should be taken instead of releasing the Beta without proper documentation. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
Dne 6.12.2012 18:23, Josh Boyer napsal(a): On Thu, Dec 6, 2012 at 11:54 AM, Vít Ondruch vondr...@redhat.com wrote: Also, there was dissent already in the auto-approving of leaf-features during the meeting discussion so I am not sure that auto-accepting of Features in general given a lack of response is ever going to actually happen. I personally wouldn't vote for it. This proposal entirely avoids discussion of leaf-features, self contained features or complex features with system-wide impact since there will never by any reasonable metrics you can apply to decide. If you can't decide what feature you are dealing with, how you want to judge if FESCo should be approving it or not. If some FESCo member thinks that is should be approved by FESCo, s/he still has the power to open ticket for FESCo meeting. The same power as other Fedora community members. Actually I would be very interested to hear why there should not be auto-approving. Please enlighten me. I explained my reasoning in the part of the email you cut off in your reply. josh Sorry Josh, but I can't find any reasons in your quote: Also, there was dissent already in the auto-approving of leaf-features during the meeting discussion so I am not sure that auto-accepting of Features in general given a lack of response is ever going to actually happen. I personally wouldn't vote for it. Only reason I see is there was dissent. So based on some dissent, you are against auto-approving? I'd love to hear why there is dissent. What is the reason for dissent. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
On 12/07/2012 09:28 AM, Vít Ondruch wrote: Feature is something somebody considers important enough to create feature page for it. Period. That describes the current state and is your point of view. To me an Feature is a completely different thing. I am not sure why do you want to categorize it by size and impact, when it will be autocategorized by feedback on ML. It's common knowledge that you cant autocategorized by feedback on Mailing list regardless what's it's for. ( For obvious reasons ) The only think matters is that the Feature is widely advertised and that the community can provide early feedback. No that is not enough because in the end you will only get feedback from users of those feature not necessary from developers of other components that might get affected by that feature. Please avoid bureaucracy. I would realy hate to see something like FFCo (Fedora Feature Committee), which would decided if feature is feature, major change, alteration, evolution or disruption, since it really doesn't matter. FESCO is for that, as in to accept,decide and determine the wider impact an feature might have to the whole projects eco system and arguably the entity that's responsible for it to be integrated into the distribution in as painless manner for users and developers alike. ( from my pov ). JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
On Fri, 2012-12-07 at 10:28 +0100, Vít Ondruch wrote: Dne 6.12.2012 21:40, Josh Boyer napsal(a): On Thu, Dec 6, 2012 at 3:18 PM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Dec 06, 2012 at 11:20:22AM -0500, Josh Boyer wrote: As I said in the meeting yesterday, I think the definition of a Feature needs to be cleared up before we can really tackle this one. Feature to me is something important enough that it shouldn't be auto-accepted. If there is some other class of thing people submit that isn't a Feature, then I might be for auto-accepting of those. Alternately, Feature could be the term for the any small or big thing which is useful to track and tout for marketing purposes, and big technical changes could be, I dunno... Major Changes. The meeting minutes showed that Fedora Marketing is already filtering the current Feature list and picking the important ones to highlight, so I don't think continuing to call the small ones Features is accurate. I mean, sure it could be done but it seems to make more sense to change the name of the small ones instead. Or just have them go to release notes. The main point is, calling them all the same thing is confusing and leads to a basically useless Feature list. josh Feature is something somebody considers important enough to create feature page for it. Period. I am not sure why do you want to categorize it by size and impact, when it will be autocategorized by feedback on ML. The only think matters is that the Feature is widely advertised and that the community can provide early feedback. Please avoid bureaucracy. I would realy hate to see something like FFCo (Fedora Feature Committee), which would decided if feature is feature, major change, alteration, evolution or disruption, since it really doesn't matter. Maybe we can persuade Josh if we do s/Feature/A change that is worth announcing and potentially also tracking or advertising/. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
- Original Message - On Fri, 2012-12-07 at 10:28 +0100, Vít Ondruch wrote: Dne 6.12.2012 21:40, Josh Boyer napsal(a): On Thu, Dec 6, 2012 at 3:18 PM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Dec 06, 2012 at 11:20:22AM -0500, Josh Boyer wrote: As I said in the meeting yesterday, I think the definition of a Feature needs to be cleared up before we can really tackle this one. Feature to me is something important enough that it shouldn't be auto-accepted. If there is some other class of thing people submit that isn't a Feature, then I might be for auto-accepting of those. Alternately, Feature could be the term for the any small or big thing which is useful to track and tout for marketing purposes, and big technical changes could be, I dunno... Major Changes. The meeting minutes showed that Fedora Marketing is already filtering the current Feature list and picking the important ones to highlight, so I don't think continuing to call the small ones Features is accurate. I mean, sure it could be done but it seems to make more sense to change the name of the small ones instead. Or just have them go to release notes. The main point is, calling them all the same thing is confusing and leads to a basically useless Feature list. josh Feature is something somebody considers important enough to create feature page for it. Period. I am not sure why do you want to categorize it by size and impact, when it will be autocategorized by feedback on ML. The only think matters is that the Feature is widely advertised and that the community can provide early feedback. Please avoid bureaucracy. I would realy hate to see something like FFCo (Fedora Feature Committee), which would decided if feature is feature, major change, alteration, evolution or disruption, since it really doesn't matter. Maybe we can persuade Josh if we do s/Feature/A change that is worth announcing and potentially also tracking or advertising/. Yep, as the main idea is to collect as much ideas/changes to be publicly announced and if we say only part of these are Features AFTER discussion/review - I'm ok with that. As it's the goal - to know about changes people do not consider features but definitely could be raised to the feature status. The common example I see as a wrangler - hey, I'm not sure this functionality is worth creating feature, and you know, the process, and nobody would care... But once the feature is accepted - wow, I got so much response, from all people from different projects that touch the area and we're now working on integration etc. - *VISIBILITY*. Do not call it Feature Process but Planning process - as it fits the decision to create F19 schedule after we know the scope of it based on proposals. And then - I'm ok with even more terms - Feature for something we really want to feature and make Marketing's life easier - so not based on scope, but marketing and define more boxes... Jaroslav -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- 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: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
Dne 7.12.2012 11:13, Jóhann B. Guðmundsson napsal(a): On 12/07/2012 09:28 AM, Vít Ondruch wrote: Feature is something somebody considers important enough to create feature page for it. Period. That describes the current state and is your point of view. To me an Feature is a completely different thing. Could you be more specific please? I am not sure why do you want to categorize it by size and impact, when it will be autocategorized by feedback on ML. It's common knowledge that you cant autocategorized by feedback on Mailing list regardless what's it's for. ( For obvious reasons ) They are probably not so obvious to me. But I can imagine several types of responses on ML: 1) No response at all. This is positive, since the feature was probably discussed on different places previously, such as SIG ML or is non-controversial. 2) Positive response. Everybody probably agrees that Gnome 3 should be updated in next release. 3) Controversial feature, such as /tmp on tmpfs 4) Only negative feedback. E.g. lets move to yet another init system. 5) WTF feedback. Why are you even proposing this minor update of this unknown library as a feature (but this is non-category, since it will be probably rejected by Package Wrangler already)? These are 5 categories of features I can imagine. Now please tell me if the categorization is not clear and if that is not obvious how to proceed with these. The only think matters is that the Feature is widely advertised and that the community can provide early feedback. No that is not enough because in the end you will only get feedback from users of those feature not necessary from developers of other components that might get affected by that feature. Yes, nobody never cares until it is not late. I can't change that. But I'm trying. Announcing features in devel/devel-announce is definitely step in good direction. Please avoid bureaucracy. I would realy hate to see something like FFCo (Fedora Feature Committee), which would decided if feature is feature, major change, alteration, evolution or disruption, since it really doesn't matter. FESCO is for that, as in to accept,decide and determine the wider impact an feature might have to the whole projects eco system and arguably the entity that's responsible for it to be integrated into the distribution in as painless manner for users and developers alike. ( from my pov ). FESCo's responsibilities does not change at all. The benefit will be that FESCo will be able to spent more time paying attention to features that are worth of attention. Don't forget that this discussion is initiative of FESCo members, who feels to be overwhelmed by non-important features, not mine. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
On 12/07/2012 11:13 AM, Vít Ondruch wrote: Dne 7.12.2012 11:13, Jóhann B. Guðmundsson napsal(a): On 12/07/2012 09:28 AM, Vít Ondruch wrote: Feature is something somebody considers important enough to create feature page for it. Period. That describes the current state and is your point of view. To me an Feature is a completely different thing. Could you be more specific please? For example major release for a component or a group of components I am not sure why do you want to categorize it by size and impact, when it will be autocategorized by feedback on ML. It's common knowledge that you cant autocategorized by feedback on Mailing list regardless what's it's for. ( For obvious reasons ) You have to be subscribed to d the relevant mailing list and not ignoring the individual(s) responsible for the feature etc.. They are probably not so obvious to me. But I can imagine several types of responses on ML: And what I'm pointing on are using mailing list for that. The only think matters is that the Feature is widely advertised and that the community can provide early feedback. No that is not enough because in the end you will only get feedback from users of those feature not necessary from developers of other components that might get affected by that feature. Yes, nobody never cares until it is not late. I can't change that. But I'm trying. Announcing features in devel/devel-announce is definitely step in good direction. What about all the other communities the feature might affect and the relevant party that is not subscribed devel/devel-announce in those communites? Please avoid bureaucracy. I would realy hate to see something like FFCo (Fedora Feature Committee), which would decided if feature is feature, major change, alteration, evolution or disruption, since it really doesn't matter. FESCO is for that, as in to accept,decide and determine the wider impact an feature might have to the whole projects eco system and arguably the entity that's responsible for it to be integrated into the distribution in as painless manner for users and developers alike. ( from my pov ). FESCo's responsibilities does not change at all. The benefit will be that FESCo will be able to spent more time paying attention to features that are worth of attention. Don't forget that this discussion is initiative of FESCo members, who feels to be overwhelmed by non-important features, not mine. Yes and to do so you need to first and foremost know what is considered an feature and what you mentioned Feature is something somebody considers important enough to create feature page for it. Period. leaves them in the exactly same place as it is now. As I have said before we cant fix the feature process until we have determined what's considered an feature in the first place and if the feature process is mandatory or not. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
On Fri, Dec 7, 2012 at 4:28 AM, Vít Ondruch vondr...@redhat.com wrote: Alternately, Feature could be the term for the any small or big thing which is useful to track and tout for marketing purposes, and big technical changes could be, I dunno... Major Changes. The meeting minutes showed that Fedora Marketing is already filtering the current Feature list and picking the important ones to highlight, so I don't think continuing to call the small ones Features is accurate. I mean, sure it could be done but it seems to make more sense to change the name of the small ones instead. Or just have them go to release notes. The main point is, calling them all the same thing is confusing and leads to a basically useless Feature list. Feature is something somebody considers important enough to create feature page for it. Period. We're going to disagree on this point. It's OK that we disagree. I am not sure why do you want to categorize it by size and impact, when it will be autocategorized by feedback on ML. The only think matters is that the Feature is widely advertised and that the community can provide early feedback. Please avoid bureaucracy. I would realy hate to see something like FFCo (Fedora Feature Committee), which would decided if feature is feature, major change, alteration, evolution or disruption, since it really doesn't matter. It doesn't matter from a get this thing into Fedora standpoint. It very much matters from a marketing/communication standpoint. If it didn't matter, Fedora Marketing wouldn't be picking specific items out of the overall Feature list. The example I used in the meeting (which btw you should really go read the full logs at this point because all I'm doing is repeating myself) is that if you give a tech journalist a list of 10 Features, they can write a pretty decent article about what is coming in the next Fedora release. If you give them a list of 20-30 Features, they're either going to ignore you entirely or pick 10 Features they think are worth writing about. Some Features are more important than others. I want FESCo involved in reviwing the ones that are big, have an impact across the distro, are somewhat controversial, and have the potential to require a lot of coordination. Whatever we call those, that is what I want reviewed. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
- Original Message - It doesn't matter from a get this thing into Fedora standpoint. It very much matters from a marketing/communication standpoint. If it didn't matter, Fedora Marketing wouldn't be picking specific items out of the overall Feature list. The example I used in the meeting (which btw you should really go read the full logs at this point because all I'm doing is repeating myself) is that if you give a tech journalist a list of 10 Features, they can write a pretty decent article about what is coming in the next Fedora release. If you give them a list of 20-30 Features, they're either going to ignore you entirely or pick 10 Features they think are worth writing about. That's the problem - FeatureList should not be used tech journalists at all! It's internal tracking tool. For journalists, we have Talking Points [1] - originally written for Ambassadors! (And yep, good time to spin it up). We have Beats... Announcements based on these with picked up the most important features without going into too much details - easier for journalist to create a good article. Feature list changes too often, it could be out of sync, feature pages are written for technical people, usually hard to understand etc... And yeah, as I understand - Features were created for marketing purposes. So let's not call that internal list features list but use some other term and then with cooperation with marketing and docs pick up let say ten most important things that happened in recent release and feature them as The Features. But marketing POV should not limit our development tracking ;-) [1] http://fedoraproject.org/wiki/Fedora_18_talking_points Jaroslav Some Features are more important than others. I want FESCo involved in reviwing the ones that are big, have an impact across the distro, are somewhat controversial, and have the potential to require a lot of coordination. Whatever we call those, that is what I want reviewed. josh -- 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: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
Dne 7.12.2012 15:06, Jaroslav Reznik napsal(a): - Original Message - It doesn't matter from a get this thing into Fedora standpoint. It very much matters from a marketing/communication standpoint. If it didn't matter, Fedora Marketing wouldn't be picking specific items out of the overall Feature list. The example I used in the meeting (which btw you should really go read the full logs at this point because all I'm doing is repeating myself) is that if you give a tech journalist a list of 10 Features, they can write a pretty decent article about what is coming in the next Fedora release. If you give them a list of 20-30 Features, they're either going to ignore you entirely or pick 10 Features they think are worth writing about. That's the problem - FeatureList should not be used tech journalists at all! It's internal tracking tool. For journalists, we have Talking Points [1] - originally written for Ambassadors! (And yep, good time to spin it up). We have Beats... Announcements based on these with picked up the most important features without going into too much details - easier for journalist to create a good article. Feature list changes too often, it could be out of sync, feature pages are written for technical people, usually hard to understand etc... And yeah, as I understand - Features were created for marketing purposes. So let's not call that internal list features list but use some other term and then with cooperation with marketing and docs pick up let say ten most important things that happened in recent release and feature them as The Features. But marketing POV should not limit our development tracking ;-) [1] http://fedoraproject.org/wiki/Fedora_18_talking_points Jaroslav Agree. Some Features are more important than others. I want FESCo involved in reviwing the ones that are big, have an impact across the distro, are somewhat controversial, and have the potential to require a lot of coordination. Whatever we call those, that is what I want reviewed. There is no reason why FESCo couldn't pick such important features by themselves and review them. And keep the rest auto-approved. I guess our views are not that different. You just try to apply some measure to categorize features (or whatever we call those) where I say it is not possible. The amount of response of ML might be good guide for that, since we don't have any better. Vít josh -- 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: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
On Fri, Dec 7, 2012 at 11:13 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: I am not sure why do you want to categorize it by size and impact, when it will be autocategorized by feedback on ML. It's common knowledge that you cant autocategorized by feedback on Mailing list regardless what's it's for. ( For obvious reasons ) The only think matters is that the Feature is widely advertised and that the community can provide early feedback. No that is not enough because in the end you will only get feedback from users of those feature not necessary from developers of other components that might get affected by that feature. Advertising the feature on the _devel_ list is intended precisely to get feedback from developers of other possibly affected components. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
On 12/07/2012 04:46 PM, Miloslav Trmač wrote: On Fri, Dec 7, 2012 at 11:13 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: I am not sure why do you want to categorize it by size and impact, when it will be autocategorized by feedback on ML. It's common knowledge that you cant autocategorized by feedback on Mailing list regardless what's it's for. ( For obvious reasons ) The only think matters is that the Feature is widely advertised and that the community can provide early feedback. No that is not enough because in the end you will only get feedback from users of those feature not necessary from developers of other components that might get affected by that feature. Advertising the feature on the _devel_ list is intended precisely to get feedback from developers of other possibly affected components. Think broader than single announcment to an single mailing list since features more often enough touch more then one part of the community... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
On Fri, Dec 7, 2012 at 6:22 PM, Emmanuel Seyman emman...@seyman.fr wrote: * Miloslav Trmač [07/12/2012 18:07] : Advertising the feature on the _devel_ list is intended precisely to get feedback from developers of other possibly affected components. IIRC, being subscribed to devel@ is not mandatory. I was imprecise - the meeting minutes show that the announcement goes to devel-announce. (In any case, responding to an e-mail is not mandatory, so... :) ) Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
On Fri, Dec 07, 2012 at 06:06:24AM -0500, Jaroslav Reznik wrote: Do not call it Feature Process but Planning process - as it fits the decision to create F19 schedule after we know the scope +1 to that! -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
On 12/07/2012 05:22 PM, Pierre-Yves Chibon wrote: On Fri, Dec 07, 2012 at 04:51:43PM +, Jóhann B. Guðmundsson wrote: On 12/07/2012 04:46 PM, Miloslav Trmač wrote: On Fri, Dec 7, 2012 at 11:13 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: I am not sure why do you want to categorize it by size and impact, when it will be autocategorized by feedback on ML. It's common knowledge that you cant autocategorized by feedback on Mailing list regardless what's it's for. ( For obvious reasons ) The only think matters is that the Feature is widely advertised and that the community can provide early feedback. No that is not enough because in the end you will only get feedback from users of those feature not necessary from developers of other components that might get affected by that feature. Advertising the feature on the _devel_ list is intended precisely to get feedback from developers of other possibly affected components. Think broader than single announcment to an single mailing list since features more often enough touch more then one part of the community... So your proposition is?? For example using the official distribution announce mailing list which should reach broader audience then just -devel if people are inclined to go down this path. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
Le vendredi 07 décembre 2012 à 18:22 +0100, Pierre-Yves Chibon a écrit : On Fri, Dec 07, 2012 at 04:51:43PM +, Jóhann B. Guðmundsson wrote: On 12/07/2012 04:46 PM, Miloslav Trmač wrote: On Fri, Dec 7, 2012 at 11:13 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: I am not sure why do you want to categorize it by size and impact, when it will be autocategorized by feedback on ML. It's common knowledge that you cant autocategorized by feedback on Mailing list regardless what's it's for. ( For obvious reasons ) The only think matters is that the Feature is widely advertised and that the community can provide early feedback. No that is not enough because in the end you will only get feedback from users of those feature not necessary from developers of other components that might get affected by that feature. Advertising the feature on the _devel_ list is intended precisely to get feedback from developers of other possibly affected components. Think broader than single announcment to an single mailing list since features more often enough touch more then one part of the community... So your proposition is?? While I cannot answer for Jóhann, I think a proposal could be to contact for example QA, as some features will have a huge impact for them. Contact irc support, as they may have some insight on the common issue reported by people, etc. Forcing everybody to be on -devel doesn't scale, that's why there is SIG and specialized lists. I remember having seen several people being annoyed of the high volume of list like debian-devel, cooker@mandriva, and in the end, this didn't helped much the communication. Christophe Wickert spoke last year about the idea of having a common gathering ( ie, some kind of inter team council ) for having such discussion, dubbed the fedora council. ( http://meetbot.fedoraproject.org/fedora-townhall/2011-11-17/fedora_townhall.2011-11-17-23.13.log.html ) Maybe that could be explored ( ie, that would just be a extension of the go/no go meeting from a organisational point of view ). The way this is done for Mageia is to have a weekly irc meeting to talk about various subjects, but I am not fond of adding more irc meeting. A feature SIG ? -- Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
On 12/07/2012 06:37 PM, Michael Scherer wrote: While I cannot answer for Jóhann, I think a proposal could be to contact for example QA, as some features will have a huge impact for them. Contact irc support, as they may have some insight on the common issue reported by people, etc. We have a track instance in QA to use for these things no need tie that to single individual sitting on some feature council... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
On Wed, Dec 05, 2012 at 03:20:14PM -0500, Bill Nottingham wrote: * 960 - F18 schedule + the holidays (notting, 18:50:29) * LINK: https://fedoraproject.org/wiki/JaroslavReznik/FedupF18Final - not updated yet (jreznik, 18:58:15) * AGREED: Do not block on fedup signature checking (not a regression) (+:7, -:0, 0:0) (notting, 19:08:47) how is not providing a supported way to do secure upgrade of Fedora not a regression? It is a big disappointment that Fedora is more and more turning its back on security. If I remember correctly, Fedora was one of the leading distributions providing and using signed packages. But with time this is more and more invalidated and people are more and more expected to install unsigned packages or not to verify them. At least back in 2010 malicious mirrors were still acknowledged as a security risk for Fedora users and signed packages were mentioned as a counter measure: https://fedoraproject.org/wiki/Mirror_manager_security_risks How come it became less important now? Actually it is even easier to attack users as more and more mobile devices are used. And what is even worse, the whole problem of not verifying packages on upgrade or the upgrade image itself is not even prominently communicated. There is nothing in the release notes about this: http://docs.fedoraproject.org/en-US/Fedora/18/html/Release_Notes/sect-Release_Notes-Changes_for_Sysadmin.html#idm32350976 I am very disappointed about this and I think this this a bad decission. :-( Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
On Fri, Dec 07, 2012 at 08:11:08PM +0100, Till Maas wrote: * 960 - F18 schedule + the holidays (notting, 18:50:29) * LINK: https://fedoraproject.org/wiki/JaroslavReznik/FedupF18Final - not updated yet (jreznik, 18:58:15) * AGREED: Do not block on fedup signature checking (not a regression) (+:7, -:0, 0:0) (notting, 19:08:47) how is not providing a supported way to do secure upgrade of Fedora not a regression? It is a big disappointment that Fedora is more and more I assume because Anaconda has never done this. (Our dear old friend bug #998.) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
On Fri, Dec 07, 2012 at 02:28:16PM -0500, Matthew Miller wrote: On Fri, Dec 07, 2012 at 08:11:08PM +0100, Till Maas wrote: * 960 - F18 schedule + the holidays (notting, 18:50:29) * LINK: https://fedoraproject.org/wiki/JaroslavReznik/FedupF18Final - not updated yet (jreznik, 18:58:15) * AGREED: Do not block on fedup signature checking (not a regression) (+:7, -:0, 0:0) (notting, 19:08:47) how is not providing a supported way to do secure upgrade of Fedora not a regression? It is a big disappointment that Fedora is more and more I assume because Anaconda has never done this. (Our dear old friend bug #998.) Anaconda only needs to do this, if it is used for network installs. But it was always possible to verify the DVD image and use the verified packages from there: https://fedoraproject.org/verify Some people even bothered to change the process from using MD5 or SHA1 to using SHA256 in the past. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
Dne 5.12.2012 21:20, Bill Nottingham napsal(a): === #fedora-meeting: FESCO (2012-12-05) === Meeting started by notting at 18:07:27 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2012-12-05/fesco.2012-12-05-18.07.log.html . Meeting summary --- * 896 - Refine Feature Process (notting, 18:07:50) * AGREED: Feature process modification: features are announced on devel-announce by feature wrangler once wrangler verifies feature page content (+:9, -:0) (notting, 18:34:51) Well done! Thank you. * AGREED: FESCo votes on new features no sooner than a week after the devel-announce announcement. (+:8, -:0, 0:0) (notting, 18:46:03) Now the rest of the change: The feature is automatically accepted (no FESCo involved at all) after one week if there is no negative feedback on ML. Otherwise it must be evaluated by FESCo. * AGREED: mitr (and others) will continue to discuss specific improvements (notting, 18:49:18) Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
On Thu, Dec 6, 2012 at 5:42 AM, Vít Ondruch vondr...@redhat.com wrote: * 896 - Refine Feature Process (notting, 18:07:50) * AGREED: Feature process modification: features are announced on devel-announce by feature wrangler once wrangler verifies feature page content (+:9, -:0) (notting, 18:34:51) Well done! Thank you. * AGREED: FESCo votes on new features no sooner than a week after the devel-announce announcement. (+:8, -:0, 0:0) (notting, 18:46:03) Now the rest of the change: The feature is automatically accepted (no FESCo involved at all) after one week if there is no negative feedback on ML. Otherwise it must be evaluated by FESCo. At the least, that should be rephrased. Negative feedback isn't the thing you really want to trigger off of. It's more if there is no significant discussion or something similar. You can have something with a lot of positive discussion that is still a large and invasive Feature that should be reviewed by FESCo. Also, there was dissent already in the auto-approving of leaf-features during the meeting discussion so I am not sure that auto-accepting of Features in general given a lack of response is ever going to actually happen. I personally wouldn't vote for it. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
On Thu, 2012-12-06 at 09:07 -0500, Josh Boyer wrote: On Thu, Dec 6, 2012 at 5:42 AM, Vít Ondruch vondr...@redhat.com wrote: * 896 - Refine Feature Process (notting, 18:07:50) * AGREED: Feature process modification: features are announced on devel-announce by feature wrangler once wrangler verifies feature page content (+:9, -:0) (notting, 18:34:51) Well done! Thank you. * AGREED: FESCo votes on new features no sooner than a week after the devel-announce announcement. (+:8, -:0, 0:0) (notting, 18:46:03) Now the rest of the change: The feature is automatically accepted (no FESCo involved at all) after one week if there is no negative feedback on ML. Otherwise it must be evaluated by FESCo. At the least, that should be rephrased. Negative feedback isn't the thing you really want to trigger off of. It's more if there is no significant discussion or something similar. You can have something with a lot of positive discussion that is still a large and invasive Feature that should be reviewed by FESCo. Let's rephrase it: The feature is automatically accepted (no FESCo involved at all) after one week if the submitter of feature or anybody else explicitly does not ask for FESCo review and approval. Also, there was dissent already in the auto-approving of leaf-features during the meeting discussion so I am not sure that auto-accepting of Features in general given a lack of response is ever going to actually happen. I personally wouldn't vote for it. I still hope that some kind of auto-accepting of features will be approved by FESCo. I personally would vote for it if it is reasonably worded. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
On Thu, Dec 6, 2012 at 11:02 AM, Tomas Mraz tm...@redhat.com wrote: On Thu, 2012-12-06 at 09:07 -0500, Josh Boyer wrote: On Thu, Dec 6, 2012 at 5:42 AM, Vít Ondruch vondr...@redhat.com wrote: * 896 - Refine Feature Process (notting, 18:07:50) * AGREED: Feature process modification: features are announced on devel-announce by feature wrangler once wrangler verifies feature page content (+:9, -:0) (notting, 18:34:51) Well done! Thank you. * AGREED: FESCo votes on new features no sooner than a week after the devel-announce announcement. (+:8, -:0, 0:0) (notting, 18:46:03) Now the rest of the change: The feature is automatically accepted (no FESCo involved at all) after one week if there is no negative feedback on ML. Otherwise it must be evaluated by FESCo. At the least, that should be rephrased. Negative feedback isn't the thing you really want to trigger off of. It's more if there is no significant discussion or something similar. You can have something with a lot of positive discussion that is still a large and invasive Feature that should be reviewed by FESCo. Let's rephrase it: The feature is automatically accepted (no FESCo involved at all) after one week if the submitter of feature or anybody else explicitly does not ask for FESCo review and approval. Sure, better at least from a starting point. Also, there was dissent already in the auto-approving of leaf-features during the meeting discussion so I am not sure that auto-accepting of Features in general given a lack of response is ever going to actually happen. I personally wouldn't vote for it. I still hope that some kind of auto-accepting of features will be approved by FESCo. I personally would vote for it if it is reasonably worded. As I said in the meeting yesterday, I think the definition of a Feature needs to be cleared up before we can really tackle this one. Feature to me is something important enough that it shouldn't be auto-accepted. If there is some other class of thing people submit that isn't a Feature, then I might be for auto-accepting of those. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
Dne 6.12.2012 17:02, Tomas Mraz napsal(a): On Thu, 2012-12-06 at 09:07 -0500, Josh Boyer wrote: On Thu, Dec 6, 2012 at 5:42 AM, Vít Ondruch vondr...@redhat.com wrote: * 896 - Refine Feature Process (notting, 18:07:50) * AGREED: Feature process modification: features are announced on devel-announce by feature wrangler once wrangler verifies feature page content (+:9, -:0) (notting, 18:34:51) Well done! Thank you. * AGREED: FESCo votes on new features no sooner than a week after the devel-announce announcement. (+:8, -:0, 0:0) (notting, 18:46:03) Now the rest of the change: The feature is automatically accepted (no FESCo involved at all) after one week if there is no negative feedback on ML. Otherwise it must be evaluated by FESCo. At the least, that should be rephrased. Negative feedback isn't the thing you really want to trigger off of. It's more if there is no significant discussion or something similar. You can have something with a lot of positive discussion that is still a large and invasive Feature that should be reviewed by FESCo. Let's rephrase it: The feature is automatically accepted (no FESCo involved at all) after one week if the submitter of feature or anybody else explicitly does not ask for FESCo review and approval. This is definitely better wording. Also, there was dissent already in the auto-approving of leaf-features during the meeting discussion so I am not sure that auto-accepting of Features in general given a lack of response is ever going to actually happen. I personally wouldn't vote for it. This proposal entirely avoids discussion of leaf-features, self contained features or complex features with system-wide impact since there will never by any reasonable metrics you can apply to decide. If you can't decide what feature you are dealing with, how you want to judge if FESCo should be approving it or not. If some FESCo member thinks that is should be approved by FESCo, s/he still has the power to open ticket for FESCo meeting. The same power as other Fedora community members. Actually I would be very interested to hear why there should not be auto-approving. Please enlighten me. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
On Thu, Dec 6, 2012 at 11:54 AM, Vít Ondruch vondr...@redhat.com wrote: Also, there was dissent already in the auto-approving of leaf-features during the meeting discussion so I am not sure that auto-accepting of Features in general given a lack of response is ever going to actually happen. I personally wouldn't vote for it. This proposal entirely avoids discussion of leaf-features, self contained features or complex features with system-wide impact since there will never by any reasonable metrics you can apply to decide. If you can't decide what feature you are dealing with, how you want to judge if FESCo should be approving it or not. If some FESCo member thinks that is should be approved by FESCo, s/he still has the power to open ticket for FESCo meeting. The same power as other Fedora community members. Actually I would be very interested to hear why there should not be auto-approving. Please enlighten me. I explained my reasoning in the part of the email you cut off in your reply. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
On 12/06/2012 04:20 PM, Josh Boyer wrote: As I said in the meeting yesterday, I think the definition of a Feature needs to be cleared up before we can really tackle this one. Feature to me is something important enough that it shouldn't be auto-accepted. If there is some other class of thing people submit that isn't a Feature, then I might be for auto-accepting of those. Agreed JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
On Thu, Dec 06, 2012 at 11:20:22AM -0500, Josh Boyer wrote: As I said in the meeting yesterday, I think the definition of a Feature needs to be cleared up before we can really tackle this one. Feature to me is something important enough that it shouldn't be auto-accepted. If there is some other class of thing people submit that isn't a Feature, then I might be for auto-accepting of those. Alternately, Feature could be the term for the any small or big thing which is useful to track and tout for marketing purposes, and big technical changes could be, I dunno... Major Changes. Or Alterations or Evolutions or Disruptions (well, that's a little negative so not that). For example adding systemd is a feature, while making it the default is a big change. Same with firewalld. UsrMove wasn't really a feature *at all*, but definitely a big change. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
