Apologies for the continued abuse of a much abused acronym, but a recent long-winded debate on opensuse-factory made me think that perhaps the opensuse project could do with a steering committee? I have not thought much about it, I would appreciate any and all opinions.
On Wed, Dec 28, 2011 at 3:03 PM, Per Jessen per@opensuse.org wrote:
Apologies for the continued abuse of a much abused acronym, but a recent long-winded debate on opensuse-factory made me think that perhaps the opensuse project could do with a steering committee? I have not thought much about it, I would appreciate any and all opinions.
-- Per Jessen, Zürich (1.1°C)
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Can you explain the nature of the debate and what you think the steering committee should/should not do?
Bryen M Yunashko
Bryen Yunashko wrote:
On Wed, Dec 28, 2011 at 3:03 PM, Per Jessen per@opensuse.org wrote:
Apologies for the continued abuse of a much abused acronym, but a recent long-winded debate on opensuse-factory made me think that perhaps the opensuse project could do with a steering committee? I have not thought much about it, I would appreciate any and all opinions.
-- Per Jessen, Zürich (1.1°C)
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Can you explain the nature of the debate and what you think the steering committee should/should not do?
Hi Bryen
that debate, hijacked a number times, is found under the heading
"Re: Human readable, what is that? (was [12.1] massive data loss in /var/tmp/)".
The heading is not very reresentative wrt this topic, but one of the later branches reminded me of the gcc and egcs situation in the late 90s.
Conservative vs. progressive.
When reading up on the gcc/egcs history, I saw the following on wikipedia:
"The steering committee was founded in 1998 with the intent of preventing any particular individual, group or organization from getting control over the project. Its primary purpose is to make major decisions in the best interests of the GCC project and to ensure that the project adheres to its fundamental principles found in the project's mission statement."
(http://gcc.gnu.org/steering.html)
I'm not trying to make any sort of comparison, openSUSE is clearly not gcc, but the above sounds like something we could do with too. Please don't get sidetracked on any gcc/egcs comparison, gcc was merely what prompted the idea.
On 28.12.2011 22:33, Per Jessen wrote:
Bryen Yunashko wrote:
On Wed, Dec 28, 2011 at 3:03 PM, Per Jessenper@opensuse.org wrote:
Apologies for the continued abuse of a much abused acronym, but a recent long-winded debate on opensuse-factory made me think that perhaps the opensuse project could do with a steering committee? I have not thought much about it, I would appreciate any and all opinions.
-- Per Jessen, Zürich (1.1°C)
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Can you explain the nature of the debate and what you think the steering committee should/should not do?
Hi Bryen
that debate, hijacked a number times, is found under the heading
"Re: Human readable, what is that? (was [12.1] massive data loss in /var/tmp/)".
The heading is not very reresentative wrt this topic, but one of the later branches reminded me of the gcc and egcs situation in the late 90s.
Conservative vs. progressive.
When reading up on the gcc/egcs history, I saw the following on wikipedia:
"The steering committee was founded in 1998 with the intent of preventing any particular individual, group or organization from getting control over the project. Its primary purpose is to make major decisions in the best interests of the GCC project and to ensure that the project adheres to its fundamental principles found in the project's mission statement."
(http://gcc.gnu.org/steering.html)
I'm not trying to make any sort of comparison, openSUSE is clearly not gcc, but the above sounds like something we could do with too. Please don't get sidetracked on any gcc/egcs comparison, gcc was merely what prompted the idea.
So you mean some kind of congress (or Bundestag, or Parliament or however you want to name it?)
Kim Leyendecker wrote:
On 28.12.2011 22:33, Per Jessen wrote:
Bryen Yunashko wrote:
On Wed, Dec 28, 2011 at 3:03 PM, Per Jessenper@opensuse.org wrote:
Apologies for the continued abuse of a much abused acronym, but a recent long-winded debate on opensuse-factory made me think that perhaps the opensuse project could do with a steering committee? I have not thought much about it, I would appreciate any and all opinions.
-- Per Jessen, Zürich (1.1°C)
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Can you explain the nature of the debate and what you think the steering committee should/should not do?
Hi Bryen
that debate, hijacked a number times, is found under the heading
"Re: Human readable, what is that? (was [12.1] massive data loss in /var/tmp/)".
The heading is not very reresentative wrt this topic, but one of the later branches reminded me of the gcc and egcs situation in the late 90s.
Conservative vs. progressive.
When reading up on the gcc/egcs history, I saw the following on wikipedia:
"The steering committee was founded in 1998 with the intent of preventing any particular individual, group or organization from getting control over the project. Its primary purpose is to make major decisions in the best interests of the GCC project and to ensure that the project adheres to its fundamental principles found in the project's mission statement."
(http://gcc.gnu.org/steering.html)
I'm not trying to make any sort of comparison, openSUSE is clearly not gcc, but the above sounds like something we could do with too. Please don't get sidetracked on any gcc/egcs comparison, gcc was merely what prompted the idea.
So you mean some kind of congress (or Bundestag, or Parliament or however you want to name it?)
I mean an entity that determines where openSUSE goes. For instance, <something> that enforces our strategy as decided by the members. I think "steering committee" is a useful tag to use in that context.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2011-12-28 23:00, Per Jessen wrote:
I mean an entity that determines where openSUSE goes. For instance, <something> that enforces our strategy as decided by the members. I think "steering committee" is a useful tag to use in that context.
I like the idea.
- -- Cheers / Saludos,
Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Minas Tirith))
On 28.12.2011 22:03, Per Jessen wrote:
Apologies for the continued abuse of a much abused acronym, but a recent long-winded debate on opensuse-factory made me think that perhaps the opensuse project could do with a steering committee? I have not thought much about it, I would appreciate any and all opinions.
maybe I completely misunderstood you...
*but*
isn´t there such a committee already? What about the board?
I´m sure you mean something more technical, right? Why we should intervene into developer-related things? If I were in the position to build a distro I wouldn´t accept any kind of intervention by a committee, I guess others are thinking the same way.
Kim Leyendecker wrote:
On 28.12.2011 22:03, Per Jessen wrote:
Apologies for the continued abuse of a much abused acronym, but a recent long-winded debate on opensuse-factory made me think that perhaps the opensuse project could do with a steering committee? I have not thought much about it, I would appreciate any and all opinions.
maybe I completely misunderstood you...
*but*
isn´t there such a committee already? What about the board?
AFAIK, the board is not tasked with any project _steering_ whatsoever.
I´m sure you mean something more technical, right?
Absolutely.
Why we should intervene into developer-related things? If I were in the position to build a distro I wouldn´t accept any kind of intervention by a committee, I guess others are thinking the same way.
I submit that none of our developers (I hesitantly include myself here) are in a position to build the entire distro by themselves.
Furthermore, my reasoning wrt a steering committee is that we (the project) might want to intervene if or when the developer(s) neglect to consider what the user(s) want. See e.g. the gcc/egcs story I have referred to in another posting.
On 28.12.2011 22:43, Per Jessen wrote:
Furthermore, my reasoning wrt a steering committee is that we (the project) might want to intervene if or when the developer(s) neglect to consider what the user(s) want. See e.g. the gcc/egcs story I have referred to in another posting.
Ok, completely agree to this, but how you want to do this? openFATE is right on the floor, and it doesn´t need an additional committee, maybe just give that task to the board? And, just to get clear, isn´t that also a task of a community manager?
--kdl
Le 28/12/2011 23:05, Kim Leyendecker a écrit :
On 28.12.2011 22:43, Per Jessen wrote:
Furthermore, my reasoning wrt a steering committee is that we (the project) might want to intervene if or when the developer(s) neglect to consider what the user(s) want. See e.g. the gcc/egcs story I have referred to in another posting.
Ok, completely agree to this, but how you want to do this? openFATE is right on the floor, and it doesn´t need an additional committee, maybe just give that task to the board? And, just to get clear, isn´t that also a task of a community manager?
--kdl
It's a bit more difficult than that...
We have only two way of having things developped:
* make benevolent developper happy developping what we need. This is certainly not the case here. I feel pretty bad reading this discussion :-( - don't forget "have fun!" - so many people here work against they case...
* pay to have some developper do the job. It's the case of paid developpers from SUSE, for example. As far as know there are some SUSE developpers working on systemd on duty. I beg if it's so it's because SUSE (and didn't I read also Red Hat) wants systemd now. Do somebody think SUSE or Red Hat are not server oriented? If so we just have to find money to support SystenV inits, because soon they won't have many people to do.
It's a open source world thing that old stable system is boring. Why do anybody need more than Debian 3.0??
So, soon or later nobody have anymore fun working on it, and kde3 stops, Gnome 2 stops, SystemV init stops... and user do not like it (me the first didn't like the move kde3->kde4), but till now the competition (W or Mac) is not that apealing, so...
jdd
On Wed, Dec 28, 2011 at 5:05 PM, Kim Leyendecker leyendecker@opensuse.org wrote:
On 28.12.2011 22:43, Per Jessen wrote:
Furthermore, my reasoning wrt a steering committee is that we (the project) might want to intervene if or when the developer(s) neglect to consider what the user(s) want. See e.g. the gcc/egcs story I have referred to in another posting.
Ok, completely agree to this, but how you want to do this? openFATE is right on the floor, and it doesn´t need an additional committee, maybe just give that task to the board? And, just to get clear, isn´t that also a task of a community manager?
--kdl
You mean Jos Poortvliet? I don't think he acts as a steering committee for the technical side of the project nor does his role call for it I don't think. I assume he impacts the marketing team as a steering leader.
I suspect Coolo (release manager) and Andreas Jaeger (openSUSE Program Manager) have far more influence on fundamental technical decisions.
I think a lot of it actually falls on squarely Coolo (release manager) now (or at least that is my assumption.). But I also suspect there is at least an informal steering committee somewhere already. The steering committee may change from item to item as Coolo looks for advice.
The reality is a lot of the project "decisions" are enforced by tools like rpmlint and other OBS configuration checking tools.
I agree with Per that the management and functionality changes to those tools should be made more transparent. As it currently is, the vast majority of packagers find out about changes to the policies (or whatever they are) when one of the tools is rolled into production with the new function/feature in place.
They are certainly not handled by openfate from what I've seen.
So my impression of the current state is:
Attachmate/SUSE names the release manager, project manager, and community manager: They in turn are the current effective steering committee with Coolo and Andreas acting as the technical leaders that I believe Per is talking about.
So my question back to Per is, "assuming I'm accurate and Coolo, Andreas, and Jos currently act as a steering committee designated by Attachmate/SLED, what is your proposal?"
=== One possibly trivial recent example of openSUSE already having a steering committee is the move from the old license tokens to the new ones from SPDX.
Old: http://en.opensuse.org/openSUSE:Accepted_licences#Good_Licenses
New: http://spdx.org/licenses/
ie. Old: GPLv2+ New: GPL-2+
I just searched openfate for SPDX I get zero hits, so that was not the source of this change.
I think it is great that license tokens be agreed on between multiple distros, so I see this as step forward, but it is not something individual maintainers can make happen. It has to happen at the overall project level.
But I doubt the board had any say in this change nor am I aware of it being discussed anywhere in particular. (but since the board doesn't use opensuse-board@opensuse.org there is no way I can confirm that theory.)
Certainly it wasn't voted on by the members and it should not be. It is not something we need a full community vote for.
I assume it would be Per's steering committee that he would envision making the decision of if the license tokens should be changed from the old values to the new values. And if so what enforcement tool would be used to ensure that only openSUSE approved license tokens are used in the specfiles.
Greg
Le 29/12/2011 01:06, Greg Freemyer a écrit :
I suspect Coolo (release manager) and Andreas Jaeger (openSUSE Program Manager) have far more influence on fundamental technical decisions.
certainly, and we have to thank them for the overall quality openSUSE have.
I also read sometime ago that if anybody want to share the release manager task, it's an open choice... but I didn't step in :-(
The reality is a lot of the project "decisions" are enforced by tools like rpmlint and other OBS configuration checking tools.
among other things.
How do you figure the release manager can act? I'm pretty sure moving a full time developper to an other task is something that is carefully checked by SUSE beforehand, specially when it's not about the direct money catching tasks. Else the release manager can just choose between what already exist. And openSUSE is not the only involved here, other distros are also
When and how to make such important decision as changing the boot system is a really difficult choice. Syatemd could have been choosen since 11.4 at least as Fedora did.
One possibly trivial recent example of openSUSE already having a steering committee is the move from the old license tokens to the new ones from SPDX.
what move? what spdx do is not openSUSE. I was the origin of the openSUSE page and carefully noted on the top of this one the controversial status (it's still there). This is not something we can solve by a decision.
I think it is great that license tokens be agreed on between multiple distros, so I see this as step forward, but it is not something individual maintainers can make happen. It has to happen at the overall project level.
I was made aware of the fedora page and the fact openSUSE didn't have one, and I copied simply the fedora page to our wiki to allow discussing
Certainly it wasn't voted on by the members and it should not be. It is not something we need a full community vote for.
I see lot of licences approved there. May be less in a list than in the other and (not aving yet time tp read this carefully) it's probably a good thing.
jdd
On Thu, Dec 29, 2011 at 2:29 AM, jdd jdd@dodin.org wrote:
Le 29/12/2011 01:06, Greg Freemyer a écrit :
<snip>
One possibly trivial recent example of openSUSE already having a steering committee is the move from the old license tokens to the new ones from SPDX.
what move? what spdx do is not openSUSE. I was the origin of the openSUSE page and carefully noted on the top of this one the controversial status (it's still there). This is not something we can solve by a decision.
I repeat this is a trivial situation and I agree with the actions taken, but:
==== As I understand it:
- prior to you(jdd) creating that page, openSUSE allowed license tokens in specfiles haphazardly. In particular I don't think rpmlint used to check license tokens against a list (but I could be wrong.)
- When you created the page it was used as a guideline of what was acceptable, but the list was still not enforced technically I don't think. ie. A human may have complained if it wasn't in the list, but there was not a automated check that the license field in the specfile contained a valid token.
As of roughly a month ago, the SPDX licenses were adopted by Coolo as the basis of a opensuse acceptable tokens to use in the license field of specfiles.
Now rpm lint looks for license tokins to be valid. Here's and example where I forced the token to the old value in a small package I maintain:
RPMLINT report: =============== mac-robber.x86_64: W: invalid-license GPLv2+ mac-robber.src: W: invalid-license GPLv2+ The specified license string is not recognized. Please refer to http://license.opensuse.org/ for the list of known licences and their exact spelling.
And if you go to the link, and enter GPLv2+ in the text entry field, it comes back with GPL-2+ which is from the SPDX list.
So the entire openSUSE project was impacted by that change. And as is now obvious, it was done without updating the wiki entry discussing acceptable openSUSE licenses.
Greg
Le 29/12/2011 23:16, Greg Freemyer a écrit :
As of roughly a month ago, the SPDX licenses were adopted by Coolo as the basis of a opensuse acceptable tokens to use in the license field of specfiles.
Now rpm lint looks for license tokins to be valid. Here's and example where I forced the token to the old value in a small package I maintain:
OK, I see your point
thanks jdd
On 29.12.2011 01:06, Greg Freemyer wrote:
On Wed, Dec 28, 2011 at 5:05 PM, Kim Leyendecker leyendecker@opensuse.org wrote:
On 28.12.2011 22:43, Per Jessen wrote:
Furthermore, my reasoning wrt a steering committee is that we (the project) might want to intervene if or when the developer(s) neglect to consider what the user(s) want. See e.g. the gcc/egcs story I have referred to in another posting.
Ok, completely agree to this, but how you want to do this? openFATE is right on the floor, and it doesn´t need an additional committee, maybe just give that task to the board? And, just to get clear, isn´t that also a task of a community manager?
--kdlYou mean Jos Poortvliet? I don't think he acts as a steering committee for the technical side of the project nor does his role call for it I don't think. I assume he impacts the marketing team as a steering leader.
I actually thought he´s also some kind of a moderator.
I suspect Coolo (release manager) and Andreas Jaeger (openSUSE Program Manager) have far more influence on fundamental technical decisions.
correct. (as far as I can say...)
I think a lot of it actually falls on squarely Coolo (release manager) now (or at least that is my assumption.). But I also suspect there is at least an informal steering committee somewhere already. The steering committee may change from item to item as Coolo looks for advice.
The reality is a lot of the project "decisions" are enforced by tools like rpmlint and other OBS configuration checking tools.
I agree with Per that the management and functionality changes to those tools should be made more transparent. As it currently is, the vast majority of packagers find out about changes to the policies (or whatever they are) when one of the tools is rolled into production with the new function/feature in place.
They are certainly not handled by openfate from what I've seen.
So my impression of the current state is:
Attachmate/SUSE names the release manager, project manager, and community manager: They in turn are the current effective steering committee with Coolo and Andreas acting as the technical leaders that I believe Per is talking about.
So my question back to Per is, "assuming I'm accurate and Coolo, Andreas, and Jos currently act as a steering committee designated by Attachmate/SLED, what is your proposal?"
=== One possibly trivial recent example of openSUSE already having a steering committee is the move from the old license tokens to the new ones from SPDX.
Old: http://en.opensuse.org/openSUSE:Accepted_licences#Good_Licenses
New: http://spdx.org/licenses/
ie. Old: GPLv2+ New: GPL-2+
I just searched openfate for SPDX I get zero hits, so that was not the source of this change.
I think it is great that license tokens be agreed on between multiple distros, so I see this as step forward, but it is not something individual maintainers can make happen. It has to happen at the overall project level.
But I doubt the board had any say in this change nor am I aware of it being discussed anywhere in particular. (but since the board doesn't use opensuse-board@opensuse.org there is no way I can confirm that theory.)
Certainly it wasn't voted on by the members and it should not be. It is not something we need a full community vote for.
I assume it would be Per's steering committee that he would envision making the decision of if the license tokens should be changed from the old values to the new values. And if so what enforcement tool would be used to ensure that only openSUSE approved license tokens are used in the specfiles.
Greg
So, I´d like to see openFATE more used for community decisions.
Like:
1.) A proposal goes through openFATE first. 2.) After an achieved number of "okays" it goes through a steering committee 3.) If the steering committee approves, it will be applied by the distro, project etc.
advantages:
the whole community can decide where the distro and the project is going (democracy as it should be)
disadvantages:
It´ll take a lot of time, which we might not have.
On the other hand, if a steering committee will be established, you also have to find people who act as it. Now, AJ and Coolo would be fine for that job, because they have big influence on the project and also have the necessary knowledge to do that.
Now, whereas I´d be okay with them others may not. So, elections will be necessary. And here you have to define the committee.
I would suggest the following:
SUSE is naming three persons, and the community will elect other three persons so that no party will have a majority.
"Kim, SUSE´s also a part of the community!"
Yes, but it still pays for most of the marketing materials and still maintains our server infrastructure, not to forget who holds the copyright etc.
Once a foundation is established, SUSE could give the right to name three persons up to the foundation.
That´s only my version how to establish and use such a committee, it´s also not tested anywhere, so it might would fail.
--kdl
Kim Leyendecker wrote:
So, I´d like to see openFATE more used for community decisions.
Like:
1.) A proposal goes through openFATE first. 2.) After an achieved number of "okays" it goes through a steering committee 3.) If the steering committee approves, it will be applied by the distro, project etc.
advantages:
the whole community can decide where the distro and the project is going (democracy as it should be)
disadvantages:
It´ll take a lot of time, which we might not have.
Today openFATE is, as far as I can see, really just a wishlist. The community can vote any which way they want, but if someone wants to develop a proposed feature despite 60 negative votes, noone can stop him. More importantly, we don't have a team of developers employed just to work off the openFATE list. Volunteers tend to do what they think is fun or cool, and SUSEs paid developers probably have other things to do.
Besides - in my mind, a steering committe should not be micro managing anything, that'll only make things stop completely. An ST should concern itself with decisions/impact of overall aspects critical to openSUSE - YaST, GUIs, AppArmor, systemd, licensing, release dates, our strategy, quality management etc.
On the other hand, if a steering committee will be established, you also have to find people who act as it.
You're right, but you're going a little fast. I'd like to consider what an ST should/could do before we move to appointing one.
/Per
You're right, but you're going a little fast. I'd like to consider what an ST should/could do before we move to appointing one.
My initial list. If this discussion gets real, this needs to go to the Wiki.
All of the below currently happens, but I don't know how or specifically who.
=========== The steering committee is responsible for approving technical changes which impact multiple project teams. Thus changes internal to KDE or Gnome as an example would not need steering committee approval.
The below areas are examples that would require steering committee action:
1) Approve any changes to rpmlint which impact "badness".
2) Approve any functional changes to specfile auto-formater tools that the individual packagers can't control.
3) Approve any behind the scenes sweep of the specfiles to clean things up a specific way.
4) Approve any changes to defaults that are distro defaults as opposed to system defaults. (ie. grub2 vs. grub, systemd vs. sysvinit, the KDE checkbox default instead of gnome)
5) Approve structural changes such as the recent proposal to move libraries from /lib to /usr/lib (If I recall correctly). Another example is the change to have /usr mounted inside initrd so that other projects can assume /usr is available at boot time.
6) Decide on "supported" questions. I'm less sure of this, but there has been recent discussion of if opensuse supports /usr on a NFS mount point. That seems to me to impact multiple projects.
7) Approve establishment of naming conventions. ie. A new fonts naming convention was just established and a new fonts repo was also just established.
8) Approve changes to the packaging guidelines.
Greg
Greg Freemyer wrote:
You're right, but you're going a little fast. I'd like to consider what an ST should/could do before we move to appointing one.
My initial list. If this discussion gets real, this needs to go to the Wiki.
Definitely. Let's see what the uptake is like after the holidays, many people are busy doing more sensible things :-)
All of the below currently happens, but I don't know how or specifically who.
=========== The steering committee is responsible for approving technical changes which impact multiple project teams. Thus changes internal to KDE or Gnome as an example would not need steering committee approval.
The below areas are examples that would require steering committee action:
Approve any changes to rpmlint which impact "badness".
Approve any functional changes to specfile auto-formater tools that
the individual packagers can't control.
- Approve any behind the scenes sweep of the specfiles to clean
things up a specific way.
- Approve any changes to defaults that are distro defaults as opposed
to system defaults. (ie. grub2 vs. grub, systemd vs. sysvinit, the KDE checkbox default instead of gnome)
- Approve structural changes such as the recent proposal to move
libraries from /lib to /usr/lib (If I recall correctly). Another example is the change to have /usr mounted inside initrd so that other projects can assume /usr is available at boot time.
- Decide on "supported" questions. I'm less sure of this, but there
has been recent discussion of if opensuse supports /usr on a NFS mount point. That seems to me to impact multiple projects.
- Approve establishment of naming conventions. ie. A new fonts
naming convention was just established and a new fonts repo was also just established.
- Approve changes to the packaging guidelines.
It looks like you have two-three angles here - one towards the developer/packager side, one towards the end-user, one towards the system. I'm wondering if it might be useful to define areas of responsibility for the ST rather than be too specific. (completely agree with your examples though).
I also think it might be better to give the ST a right of veto (ultimately) rather than ask them to explicitly approve things. When fundamental or controversial changes are being planned/discussed, the ST should take an interest. I think it's important that a) the ST has the right to veto (or to ask for reconsideration, extended testing, documentation etc) and b) is generally not directly involved other than by way of the individual members' contribution or position.
For instance, a change to using plymouth (a alternative bootsplash thingie) is currently being discussed (as an RFC) on opensuse-factory. This is clearly a fundamental change as it has a lot of potential to affect the looks of openSUSE as seen by the average or new user. I could imagine the ST asking for more testing, more documentation or more reasoning to ensure that this has been thoroughly thought through.
Wrt "supported" functionality, I could imagine such issues eventually becoming a topic for the ST. The ST could veto planned changes in order to maintain functionality (e.g. /usr as NFS-mount) deemed to be essential to openSUSE.
Per Jessen per@opensuse.org wrote:
Greg Freemyer wrote:
You're right, but you're going a little fast. I'd like to consider what an ST should/could do before we move to appointing one.
My initial list. If this discussion gets real, this needs to go to the Wiki.
Definitely. Let's see what the uptake is like after the holidays, many people are busy doing more sensible things :-)
All of the below currently happens, but I don't know how or specifically who.
=========== The steering committee is responsible for approving technical changes which impact multiple project teams. Thus changes internal to KDE or Gnome as an example would not need steering committee approval.
The below areas are examples that would require steering committee action:
Approve any changes to rpmlint which impact "badness".
Approve any functional changes to specfile auto-formater tools
that
the individual packagers can't control.
- Approve any behind the scenes sweep of the specfiles to clean
things up a specific way.
- Approve any changes to defaults that are distro defaults as
opposed
to system defaults. (ie. grub2 vs. grub, systemd vs. sysvinit, the KDE checkbox default instead of gnome)
- Approve structural changes such as the recent proposal to move
libraries from /lib to /usr/lib (If I recall correctly). Another example is the change to have /usr mounted inside initrd so that
other
projects can assume /usr is available at boot time.
- Decide on "supported" questions. I'm less sure of this, but there
has been recent discussion of if opensuse supports /usr on a NFS
mount
point. That seems to me to impact multiple projects.
- Approve establishment of naming conventions. ie. A new fonts
naming convention was just established and a new fonts repo was also just established.
- Approve changes to the packaging guidelines.
It looks like you have two-three angles here - one towards the developer/packager side, one towards the end-user, one towards the system. I'm wondering if it might be useful to define areas of responsibility for the ST rather than be too specific. (completely agree with your examples though).
I also think it might be better to give the ST a right of veto (ultimately) rather than ask them to explicitly approve things. When fundamental or controversial changes are being planned/discussed, the ST should take an interest. I think it's important that a) the ST has the right to veto (or to ask for reconsideration, extended testing, documentation etc) and b) is generally not directly involved other than by way of the individual members' contribution or position.
For instance, a change to using plymouth (a alternative bootsplash thingie) is currently being discussed (as an RFC) on opensuse-factory. This is clearly a fundamental change as it has a lot of potential to affect the looks of openSUSE as seen by the average or new user. I could imagine the ST asking for more testing, more documentation or more reasoning to ensure that this has been thoroughly thought through.
Wrt "supported" functionality, I could imagine such issues eventually becoming a topic for the ST. The ST could veto planned changes in order to maintain functionality (e.g. /usr as NFS-mount) deemed to be essential to openSUSE.
+1 couldn't agree more
-- Per Jessen, Zürich (2.6°C)
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
--kdl
-- sent from Smartphone, sorry for my briefity
Le 30/12/2011 21:50, Per Jessen a écrit :
For instance, a change to using plymouth (a alternative bootsplash thingie) is currently being discussed (as an RFC)
did you notice there are now RFC? same for systemd.
this mean user advices are better considered
ST (if any) can only arbiter from the various point of view. I mean make a recollection of the various point of view and make a synthesis
In the Linux Documentation Project, as "leader" or (I like better) "coordinator", I do such thing: after the discussion somebody have to say what the discussion gives as result there, it's me.
That said, on the LDP, it's all a consensus way, I'm not paid, have no action else than moral, but most of the time it works.
Wrt "supported" functionality, I could imagine such issues eventually becoming a topic for the ST. The ST could veto planned changes in order to maintain functionality (e.g. /usr as NFS-mount) deemed to be essential to openSUSE.
Veto if much too hard a word. Any ST can only try to make the listeners aware of the problem and try to convince them to change they mind.
Only ther boss can have a veto or give orders. Ir once we have a Fondation, *and* if this fondation is appointing programmers (a la mozilla), then may be, and this have to be very carefully done
jdd
Wrt "supported" functionality, I could imagine such issues eventually becoming a topic for the ST. The ST could veto planned changes in order to maintain functionality (e.g. /usr as NFS-mount) deemed to be essential to openSUSE.
Veto if much too hard a word. Any ST can only try to make the listeners aware of the problem and try to convince them to change they mind.
Only ther boss can have a veto or give orders. Ir once we have a Fondation, *and* if this fondation is appointing programmers (a la mozilla), then may be, and this have to be very carefully done
jdd
RE: vetos
On the technical side, vetos definitely exist, and they exist now.
The Release Manager (Coolo) ultimately decides what goes into openSUSE. ie. The Release Manager has veto power.
eg. If I decided I wanted to submit a patch to change grub to grub2, it has to be accepted. And in the current setup that basically means Coolo has to accept it. (or veto it).
I have no issue with that reality. Coolo does a great job from what I can tell. But to claim he doesn't have that power is to be blind to reality.
I assume Per's desire is to make this reality more transparent. ie. I suspect many users, non-developer contributors don't know how broad the Release Manager's responsibilities are.
Once it is understood that we have to have a SC (and in fact we have one now), then the community can come to a community agreement as to how the process works going forward.
I see this a maturing of the community. For now I am very happy with the way things work, but what if one of the other sponsors wanted to have more say so at the steering committee level. How would that be addressed?
etc. etc.
Greg
Howdy y'all
First, sorry for Top posting but k9 Mail isn't such great to answer Mail correctly....
Anyway, the First thing i thought after i'd read your Post was velocity.
How fast will the sc react? Coolo can make a decision very fast by just saying yes or no (okay, it's more complicated, i Know)
But i really want to know how fast a reaction will be. It wouldn't make sense if the sc reacts slow, because then everybody get bored and isn't interested anymore
--kdl
Greg Freemyer greg.freemyer@gmail.com schrieb:
Wrt "supported" functionality, I could imagine such issues
eventually
becoming a topic for the ST. The ST could veto planned changes in order to maintain functionality (e.g. /usr as NFS-mount) deemed to
be
essential to openSUSE.
Veto if much too hard a word. Any ST can only try to make the
listeners
aware of the problem and try to convince them to change they mind.
Only ther boss can have a veto or give orders. Ir once we have a
Fondation,
*and* if this fondation is appointing programmers (a la mozilla),
then may
be, and this have to be very carefully done
jdd
RE: vetos
On the technical side, vetos definitely exist, and they exist now.
The Release Manager (Coolo) ultimately decides what goes into openSUSE. ie. The Release Manager has veto power.
eg. If I decided I wanted to submit a patch to change grub to grub2, it has to be accepted. And in the current setup that basically means Coolo has to accept it. (or veto it).
I have no issue with that reality. Coolo does a great job from what I can tell. But to claim he doesn't have that power is to be blind to reality.
I assume Per's desire is to make this reality more transparent. ie. I suspect many users, non-developer contributors don't know how broad the Release Manager's responsibilities are.
Once it is understood that we have to have a SC (and in fact we have one now), then the community can come to a community agreement as to how the process works going forward.
I see this a maturing of the community. For now I am very happy with the way things work, but what if one of the other sponsors wanted to have more say so at the steering committee level. How would that be addressed?
etc. etc.
Greg
To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
-- Kim Leyendecker sent from smartphone sorry for my briefity
Kim Leyendecker wrote:
Howdy y'all
First, sorry for Top posting but k9 Mail isn't such great to answer Mail correctly....
Anyway, the First thing i thought after i'd read your Post was velocity.
How fast will the sc react? Coolo can make a decision very fast by just saying yes or no (okay, it's more complicated, i Know)
The SC does not need to react fast - we don't have such significant and/or revolutionary changes happening every day.
But i really want to know how fast a reaction will be.
Why do you feel that is important? I suspect you may have misunderstood what the SC is intended to do. The SC should not be bogged down with trivia, so reaction could be perhaps be measured in weeks or more.
Le 30/12/2011 23:52, Greg Freemyer a écrit :
On the technical side, vetos definitely exist, and they exist now.
The Release Manager (Coolo) ultimately decides what goes into openSUSE. ie. The Release Manager has veto power.
I challenge this. yet Coolo have some power on paid suse people.
eg. If I decided I wanted to submit a patch to change grub to grub2, it has to be accepted. And in the current setup that basically means Coolo has to accept it. (or veto it).
if you where the only maintainer of grub and decided to stop it, I don't see what coolo could do.
I have no issue with that reality. Coolo does a great job from what I can tell. But to claim he doesn't have that power is to be blind to reality.
your overestimate his power. I'm pretty sure one of his higher quality is diplomacy :-). I'm very admirative about him :-! Of course His advice have weight.
I see this a maturing of the community. For now I am very happy with the way things work, but what if one of the other sponsors wanted to have more say so at the steering committee level. How would that be addressed?
hiring developpers. Even users can do that if they are enough
The release manager have power when he have a real choice, yes, and it's important. But real choice is not that often in the opensource world
jdd
On Fri, Dec 30, 2011 at 6:07 PM, jdd jdd@dodin.org wrote:
Le 30/12/2011 23:52, Greg Freemyer a écrit :
On the technical side, vetos definitely exist, and they exist now.
The Release Manager (Coolo) ultimately decides what goes into openSUSE. ie. The Release Manager has veto power.
I challenge this. yet Coolo have some power on paid suse people.
eg. If I decided I wanted to submit a patch to change grub to grub2, it has to be accepted. And in the current setup that basically means Coolo has to accept it. (or veto it).
if you where the only maintainer of grub and decided to stop it, I don't see what coolo could do.
Let me switch to an area I know more about, filesystems.
At some point I assume btrfs will be the default filesystem on a new opensuse install.
ext4, xfs, etc. will still be supported at that point. ie. There will not be a shortage of choices nor a shortage of maintainers for the options.
I don't know exactly how the decision to make btrfs the default will be made. But it should not be made by only the btrfs maintainers, nor should it be made only by the ext4 maintainers.
It is a project decision. With the current setup Coolo and/or Andreas I assume would come up with an adhoc method for making that decision. Probably they would talk to the SUSE filesystems experts, etc. Once a decision along those lines is made, the project will be steered in that direction.
But if today, I apply to be a zypper maintainer, then I submit changes to make btrfs be the default there is no guarantee those SRs will be accepted. And they shouldn't be until there is a "project" decision that we are ready for btrfs to be the default.
ie. Coolo can simply reject SRs that implement changes for direction he does not want to see happen. I call that veto power.
Greg
Greg wrote:
ie. Coolo can simply reject SRs that implement changes for direction he does not want to see happen. I call that veto power.
But on the other Hand, if there are enough sane reasons to critical coolo's decisions, he'll start to rethink it, i'm pretty sure.
If not, people will be smart enough to Protest against it and find a solution.
Of course, a sc would make the whole thing more transparant but also slower (worst case)
--kdl -- Kim Leyendecker sent from smartphone sorry for my briefity
Kim Leyendecker leyendecker@opensuse.org wrote:
Greg wrote:
ie. Coolo can simply reject SRs that implement changes for direction he does not want to see happen. I call that veto power.
But on the other Hand, if there are enough sane reasons to critical coolo's decisions, he'll start to rethink it, i'm pretty sure.
If not, people will be smart enough to Protest against it and find a solution.
Of course, a sc would make the whole thing more transparant but also slower (worst case)
--kdl
Kim Leyendecker
My belief is we have a defacto steering committee. If so, simply documenting the current steering process adds transparency but adds no delays.
Greg
On Monday, January 02, 2012 09:10:08 AM Greg Freemyer wrote: ...
My belief is we have a defacto steering committee. If so, simply documenting the current steering process adds transparency but adds no delays.
It is obvious that steering power exists, although it doesn't show stability, nor complete transparency. Here is my two cents about how it works, and why adding committee is pointless.
Release and platform managers are people that we see and they have power to accept or reject software which as end effect will influence distro direction. They both are directly responsible to their company, and indirectly, over the company, to the community. They are also not top execs, so they have to respect general direction those above give. This part is not and never will be transparent as competition would like.
We can see many SUSE employees giving their opinions in communication media dedicated to community. They have steering power as they are specialists for subsystems and managers will ask them for recommendation in any non-trivial case.
Status and activity of upstream projects has steering power, specially of large, complex subsystems. There is no distro that can steer kernel, Xorg, KDE, Gnome, direction as that would mean it has to create branch and take care of the development and maintenance. That is not going to happen. Even smaller projects have power to steer distro direction if they are unique and important.
Active part of community that maintains or brings add on value in a distro and supporting service is one of steering powers. Company will not try to upset them as it will mean giving up on added values or hiring replacement.
Passive part of community has some power to steer direction by expressing their opinion, although that is just as much as any source of feedback and ideas can influence things in a real world. The best ideas may be intriguing enough for someone to abandon their current activity and take a shot on a new idea, but in general only ideas and no motion will result in no change.
After all above, I'm sure that some steering committee, (board, commission: name it to your liking) will not change landscape unless it controls manpower able to take over existing tasks.
Rajko M. wrote:
On Monday, January 02, 2012 09:10:08 AM Greg Freemyer wrote: ...
My belief is we have a defacto steering committee. If so, simply documenting the current steering process adds transparency but adds no delays.
It is obvious that steering power exists, although it doesn't show stability, nor complete transparency. Here is my two cents about how it works, and why adding committee is pointless.
I didn't intend that we _add_ a committee, that would indeed be pointless.
Release and platform managers are people that we see and they have power to accept or reject software which as end effect will influence distro direction. They both are directly responsible to their company, and indirectly, over the company, to the community. They are also not top execs, so they have to respect general direction those above give. This part is not and never will be transparent as competition would like.
We have been told often enough that there is e.g. no openSUSE organigramm, yet here you are suggesting a entire hidden hierarchy? Surely you are mistaken, but it sounds like a really good argument for introducing an (elected or appointed) SC with the right to veto.
Status and activity of upstream projects has steering power, specially of large, complex subsystems. There is no distro that can steer kernel, Xorg, KDE, Gnome, direction as that would mean it has to create branch and take care of the development and maintenance. That is not going to happen. Even smaller projects have power to steer distro direction if they are unique and important.
This is the problem I suggest we try to solve with a SC.
After all above, I'm sure that some steering committee, (board, commission: name it to your liking) will not change landscape unless it controls manpower able to take over existing tasks.
The right to veto is an impressive amount of power.
On Monday, January 02, 2012 03:26:37 PM Per Jessen wrote:
Rajko M. wrote:
On Monday, January 02, 2012 09:10:08 AM Greg Freemyer wrote: ...
My belief is we have a defacto steering committee. If so, simply documenting the current steering process adds transparency but adds no delays.
It is obvious that steering power exists, although it doesn't show stability, nor complete transparency. Here is my two cents about how it works, and why adding committee is pointless.
I didn't intend that we _add_ a committee, that would indeed be pointless.
There is difference in steering committee that is either appointed or elected, and always internal to organization that created it and steering power that is combination of internal and external elements that have power to steer you.
Release and platform managers are people that we see and they have power to accept or reject software which as end effect will influence distro direction. They both are directly responsible to their company, and indirectly, over the company, to the community. They are also not top execs, so they have to respect general direction those above give. This part is not and never will be transparent as competition would like.
We have been told often enough that there is e.g. no openSUSE organigramm, yet here you are suggesting a entire hidden hierarchy? Surely you are mistaken, but it sounds like a really good argument for introducing an (elected or appointed) SC with the right to veto.
Funny.
If you are able to see hidden hierarchy in a public information that you can read in every email by AJ, then I'm not surprised with your proposal about "steering committee". One has to be fairly out of this place not to notice large signature blocks with couple of names and associated functions.
The rest of the sentence is just stating obvious for everyone that can read, which I would skip in normal circumstances, but this thread needs closing. It is nothing more then extended fantasy.
Status and activity of upstream projects has steering power, specially of large, complex subsystems. There is no distro that can steer kernel, Xorg, KDE, Gnome, direction as that would mean it has to create branch and take care of the development and maintenance. That is not going to happen. Even smaller projects have power to steer distro direction if they are unique and important.
This is the problem I suggest we try to solve with a SC.
And how would you do that. SC will tell kernel devs what they have to develop, or openSUSE will not use kernel anymore.
Well, it will not work.
Let we try with something smaller?!
After all above, I'm sure that some steering committee, (board, commission: name it to your liking) will not change landscape unless it controls manpower able to take over existing tasks.
The right to veto is an impressive amount of power.
What a words :)
What supports those words? Did you secretly bought out SUSE? That will give you impressive amount of power, at least within SUSE.
Rajko M. wrote:
The rest of the sentence is just stating obvious for everyone that can read, which I would skip in normal circumstances, but this thread needs closing. It is nothing more then extended fantasy.
Thank you for your well thought through comments.
Status and activity of upstream projects has steering power, specially of large, complex subsystems. There is no distro that can steer kernel, Xorg, KDE, Gnome, direction as that would mean it has to create branch and take care of the development and maintenance. That is not going to happen. Even smaller projects have power to steer distro direction if they are unique and important.
This is the problem I suggest we try to solve with a SC.
And how would you do that. SC will tell kernel devs what they have to develop, or openSUSE will not use kernel anymore.
No, I don't foresee the SC telling anyone what to develop. A SC should obviously work with the structure we already have.
After all above, I'm sure that some steering committee, (board, commission: name it to your liking) will not change landscape unless it controls manpower able to take over existing tasks.
The right to veto is an impressive amount of power.
What a words :)
What supports those words?
http://en.wikipedia.org/wiki/Veto
Did you secretly bought out SUSE? That will give you impressive amount of power, at least within SUSE.
Rajko, I'm making a suggestion, I'm certainly not pretending I myself have got or should be given any such powers. Perhaps you've misunderstood this RFC.
Per Jessen wrote:
After all above, I'm sure that some steering committee, (board, commission: name it to your liking) will not change landscape unless it controls manpower able to take over existing tasks.
The right to veto is an impressive amount of power.
What a words :)
What supports those words?
"The institution of the veto, known as the intercessio, was adopted by the Roman Republic in the 6th century BC as a way of enabling the tribunes to protect the interests of the plebs (common citizenry) from the encroachments of the patricians, who dominated the Senate."
Greg Freemyer wrote:
Wrt "supported" functionality, I could imagine such issues eventually becoming a topic for the ST. The ST could veto planned changes in order to maintain functionality (e.g. /usr as NFS-mount) deemed to be essential to openSUSE.
Veto if much too hard a word. Any ST can only try to make the listeners aware of the problem and try to convince them to change they mind.
Only ther boss can have a veto or give orders. Ir once we have a Fondation, *and* if this fondation is appointing programmers (a la mozilla), then may be, and this have to be very carefully done
jdd
RE: vetos
On the technical side, vetos definitely exist, and they exist now.
The Release Manager (Coolo) ultimately decides what goes into openSUSE. ie. The Release Manager has veto power.
eg. If I decided I wanted to submit a patch to change grub to grub2, it has to be accepted. And in the current setup that basically means Coolo has to accept it. (or veto it).
I have no issue with that reality. Coolo does a great job from what I can tell. But to claim he doesn't have that power is to be blind to reality.
I assume Per's desire is to make this reality more transparent. ie. I suspect many users, non-developer contributors don't know how broad the Release Manager's responsibilities are.
Just as you are, I am also perfectly happy with the job that Coolo does - more transparency would be good, I agree, but I see that as a side effect (perhaps). My thought is to have an SC that is charged with looking after the users' demands/needs/wishes and hopefully thus steer/help the project towards a larger user base. We, the openSUSE community, produce/collaborate to produce a distro for the users. Earlier when SuSE Linux was sold as DVDs in boxes, there was a clear and constant focus on producing something that could be sold to the user. We no longer do that, and afaict, noone is looking after the user. (I have been in software engineering much too long to trust any engineer to know what the user wants).
jdd wrote:
Le 30/12/2011 21:50, Per Jessen a écrit :
For instance, a change to using plymouth (a alternative bootsplash thingie) is currently being discussed (as an RFC)
did you notice there are now RFC? same for systemd.
this mean user advices are better considered
Hmm, "RFC" is unfortunately a much abused acronym I'm afraid. Far from every poster of an RFC is interested in the actual C's.
ST (if any) can only arbiter from the various point of view. I mean make a recollection of the various point of view and make a synthesis
That's not what I had in mind - the ST should be there to steer, not just to act as an umpire.
In the Linux Documentation Project, as "leader" or (I like better) "coordinator", I do such thing: after the discussion somebody have to say what the discussion gives as result there, it's me.
That is definitely not the role of an ST.
On Fri, 30 Dec 2011, Per Jessen wrote:
I also think it might be better to give the ST a right of veto (ultimately) rather than ask them to explicitly approve things.
I believe this is an important point. Sometimes there are choices to make, but in a volunteer project like SUSE any such body mostly has the power to prevent/block things rather than to prescribe them.
Greg's example with grub and grub2 is a good one: In the current setup, Coolo or others doing check ins for Factory can decline an SR making grub2 the new default. They cannot mandate that anyone fixes any issues with the existing grub.
Gerald
Greg Freemyer wrote:
I suspect Coolo (release manager) and Andreas Jaeger (openSUSE Program Manager) have far more influence on fundamental technical decisions.
I think a lot of it actually falls on squarely Coolo (release manager) now (or at least that is my assumption.). But I also suspect there is at least an informal steering committee somewhere already. The steering committee may change from item to item as Coolo looks for advice.
Agree.
I agree with Per that the management and functionality changes to those tools should be made more transparent. As it currently is, the vast majority of packagers find out about changes to the policies (or whatever they are) when one of the tools is rolled into production with the new function/feature in place.
They are certainly not handled by openfate from what I've seen.
So my impression of the current state is:
Attachmate/SUSE names the release manager, project manager, and community manager: They in turn are the current effective steering committee with Coolo and Andreas acting as the technical leaders that I believe Per is talking about.
Apologies for the late response, life&work took all day.
I didn't actually intend this RFC to attempt to address or to identify any de-facto steering committee, but in retrospect that is pretty much how I see things too.
So my question back to Per is, "assuming I'm accurate and Coolo, Andreas, and Jos currently act as a steering committee designated by Attachmate/SLED, what is your proposal?"
Thanks for the cue, Greg.
a) the immediate step would have to be to publicly acknowledge the existence of such a (even if informal) steering committee. I don't think anyone would have a problem with it at all, I certainly don't, but I would have a problem with it being hidden behind the scenes.
b) the community would have to consider if this steering committee, as appointed, is acceptable.
c) the community would have to consider if it is happy with the current procedure for appointing the steering committee.
d) whether or not a steering committe does already exist, de-facto or otherwise, the community should be able to review and agree to whatever such an SC is tasked with.
=== One possibly trivial recent example of openSUSE already having a steering committee is the move from the old license tokens to the new ones from SPDX.
Old: http://en.opensuse.org/openSUSE:Accepted_licences#Good_Licenses
New: http://spdx.org/licenses/
ie. Old: GPLv2+ New: GPL-2+
I just searched openfate for SPDX I get zero hits, so that was not the source of this change.
I think it is great that license tokens be agreed on between multiple distros, so I see this as step forward, but it is not something individual maintainers can make happen. It has to happen at the overall project level.
Good point. Very much topical for a steering committee.
But I doubt the board had any say in this change nor am I aware of it being discussed anywhere in particular. (but since the board doesn't use opensuse-board@opensuse.org there is no way I can confirm that theory.)
Is there such a mailing list? I'll have to subscribe.
I assume it would be Per's steering committee that he would envision making the decision of if the license tokens should be changed from the old values to the new values. And if so what enforcement tool would be used to ensure that only openSUSE approved license tokens are used in the specfiles.
Exactly. Many thanks for clarifying my ramblings.
Kim Leyendecker wrote:
On 28.12.2011 22:43, Per Jessen wrote:
Furthermore, my reasoning wrt a steering committee is that we (the project) might want to intervene if or when the developer(s) neglect to consider what the user(s) want. See e.g. the gcc/egcs story I have referred to in another posting.
Ok, completely agree to this, but how you want to do this? openFATE is right on the floor, and it doesn´t need an additional committee, maybe just give that task to the board? And, just to get clear, isn´t that also a task of a community manager?
Apologies for the late response, I've had a rather busy day. openFATE does not apply here, in my opinion. Wrt a steering committee, I would prefer not giving it to the board in its current state/role. For the time being, the board has been charged with fairly innocous tasks - trying to steer openSUSE is not one of those. Thinking out loud - the current board is the board of the yet-to-be-established foundation/organization. A steering committee is much, much more than that.
On 12/28/2011 10:03 PM, Per Jessen wrote:
Apologies for the continued abuse of a much abused acronym, but a recent long-winded debate on opensuse-factory made me think that perhaps the opensuse project could do with a steering committee? I have not thought much about it, I would appreciate any and all opinions.
Sorry, I'm not going to read all thread, so something I write here might already been said, but because you want all opinions, here I go:
I agree we need some kind of Steering Committee, Release Team, however we'll call it.
Board is not a SC/RT, because it deals with non-technical decisions and obviously we need different type of people in Board and in SC/RT.
In the past (immediately after 11.4 release) we tried to estabilish something like that, because lot of people screamed that release process of 11.4 was not ideal. We started a wiki page[1] and encouraged people to step up and plan the next release together with Coolo and Darix. Sadly no one did, so 12.1 was again planned and released mostly by Coolo.
We are again in the similar period (shortly after the release) and people are again asking about the Release team. I hope someone will step up this time and help the guys with planning.
So my take is that we don't have to discuss if we need this or not (36 emails?!), but just step up, contact Coolo and do it together!
[1] http://en.opensuse.org/openSUSE:Release_team
Le 09/01/2012 13:17, Pavol Rusnak a écrit :
So my take is that we don't have to discuss if we need this or not (36 emails?!), but just step up, contact Coolo and do it together!
well said, thanks jdd
-
Bryen Yunashko -
Carlos E. R. -
Gerald Pfeifer -
Greg Freemyer -
jdd -
Kim Leyendecker -
Pavol Rusnak -
Per Jessen -
Rajko M.