Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 17:00UTC (1:00pm EDT, 19:00 CEST) in #fedora-meeting on irc.freenode.net.
Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9
= Followups =
#topic #896 Refine Feature process .fesco 896 https://fedorahosted.org/fesco/ticket/896
#topic #960 F18 schedule + the holidays .fesco 960 https://fedorahosted.org/fesco/ticket/960
= New business =
- none -
= Open Floor =
For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9
If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting.
=================================== #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-... .
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) * AGREED: FESCo votes on new features no sooner than a week after the devel-announce announcement. (+:8, -:0, 0:0) (notting, 18:46:03) * AGREED: mitr (and others) will continue to discuss specific improvements (notting, 18:49:18)
* 960 - F18 schedule + the holidays (notting, 18:50:29) * LINK: https://fedoraproject.org/wiki/JaroslavReznik/FedupF18Final - not updated yet (jreznik, 18:58:15) * AGREED: Allow deferment of fedup gui until F19 (+:8, -:0, 0:0) (notting, 19:05:56) * AGREED: Do not block on fedup signature checking (not a regression) (+:7, -:0, 0:0) (notting, 19:08:47) * AGREED: (960) Final change deadline moved from 12/18 to 12/11. Release date remains 01/08. (+:6, -:3 0:0) (notting, 19:50:11)
* 940 - The /tmp-on-tmpfs feature should be disabled by default (notting, 19:51:03) * AGREED: #940 (The tmp-on-tmpfs feature should be disabled by default) does not pass. (+:4, -:4, 0:1) (notting, 20:06:37)
* Open Floor (notting, 20:07:42) * Elections going on now - please vote. (notting, 20:07:52) * Next week's chair is jwb (notting, 20:08:09)
Meeting ended at 20:11:34 UTC.
Action Items ------------
Action Items, by person ----------------------- * **UNASSIGNED** * (none)
People Present (lines said) --------------------------- * notting (106) * jreznik (94) * nirik (84) * mjg59 (75) * jwb (70) * pjones (66) * t8m (62) * mitr (48) * adamw (32) * tflink (23) * mmaslano (20) * limburgher (20) * rbergeron (11) * zodbot (9) * Viking-Ice (3) * mattdm (3) * BobJensen (1) * cwickert (1) * gholms (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
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-... .
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
On Thu, Dec 6, 2012 at 5:42 AM, Vít Ondruch vondruch@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
On Thu, 2012-12-06 at 09:07 -0500, Josh Boyer wrote:
On Thu, Dec 6, 2012 at 5:42 AM, Vít Ondruch vondruch@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.
On Thu, Dec 6, 2012 at 11:02 AM, Tomas Mraz tmraz@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 vondruch@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
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
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.
On Thu, Dec 6, 2012 at 3:18 PM, Matthew Miller mattdm@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
Dne 6.12.2012 21:40, Josh Boyer napsal(a):
On Thu, Dec 6, 2012 at 3:18 PM, Matthew Miller mattdm@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.
Vít
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
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
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
On Fri, Dec 7, 2012 at 11:13 AM, "Jóhann B. Guðmundsson" johannbg@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
On 12/07/2012 04:46 PM, Miloslav Trmač wrote:
On Fri, Dec 7, 2012 at 11:13 AM, "Jóhann B. Guðmundsson" johannbg@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
On Fri, Dec 07, 2012 at 04:51:43PM +0000, "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" johannbg@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??
Pierre
On 12/07/2012 05:22 PM, Pierre-Yves Chibon wrote:
On Fri, Dec 07, 2012 at 04:51:43PM +0000, "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" johannbg@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
Le vendredi 07 décembre 2012 à 18:22 +0100, Pierre-Yves Chibon a écrit :
On Fri, Dec 07, 2012 at 04:51:43PM +0000, "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" johannbg@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.... )
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 ?
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
* 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.
Emmanuel
On Fri, Dec 7, 2012 at 6:22 PM, Emmanuel Seyman emmanuel@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
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 mattdm@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/.
----- 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 mattdm@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
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!
On Fri, Dec 7, 2012 at 4:28 AM, Vít Ondruch vondruch@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
----- 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
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
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 vondruch@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
On Thu, Dec 6, 2012 at 11:54 AM, Vít Ondruch vondruch@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
Dne 6.12.2012 18:23, Josh Boyer napsal(a):
On Thu, Dec 6, 2012 at 11:54 AM, Vít Ondruch vondruch@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
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-Releas...
I am very disappointed about this and I think this this a bad decission. :-(
Regards Till
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.)
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
On Fri, 2012-12-07 at 20:36 +0100, Till Maas wrote:
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.
fedup is supposed to support using a DVD image as a package source, though I'm not sure of the current status of that.
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-Releas...
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.
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:
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-Releas...
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