28 Dec
2011
28 Dec
'11
3:03 p.m.
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(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
28 Dec
28 Dec
3:16 p.m.
New subject: [opensuse-project] RFC - opensuse steering committee ?
On Wed, Dec 28, 2011 at 3:03 PM, Per Jessen <per(a)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(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
Can you explain the nature of the debate and what you think the
steering committee should/should not do?
Bryen M Yunashko
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
3:33 p.m.
New subject: [opensuse-project] RFC - opensuse steering committee ?
Bryen Yunashko wrote:
On Wed, Dec 28, 2011 at 3:03 PM, Per Jessen
<per(a)opensuse.org> wrote:
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.
--
Per Jessen, Zürich (1.9°C)
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
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(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
Can you explain the nature of the debate and what you think the
steering committee should/should not do? 
3:58 p.m.
New subject: [opensuse-project] RFC - opensuse steering committee ?
On 28.12.2011 22:33, Per Jessen wrote:
Bryen Yunashko wrote:
So you mean some kind of congress (or Bundestag, or Parliament or
however you want to name it?)
--
kind regards, -o) German Wiki Team
Kim Leyendecker /\\ Documentation& marketing
www.opensuse.org _\_v leyendecker(a)opensuse.org
=====================================================
my GPG Key: 664265369547B825 | IRC: k-d-l
Twitter: kim_d_ley | Wiki-Username: openLHAG
openSUSE - Linux for open minds - get it free today!
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
On Wed, Dec 28, 2011 at 3:03 PM, Per
Jessen<per(a)opensuse.org> wrote:
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.
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(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
Can you explain
the nature of the debate and what you think the
steering committee should/should not do?
4 p.m.
New subject: [opensuse-project] RFC - opensuse steering committee ?
Kim Leyendecker wrote:
On 28.12.2011 22:33, 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.
--
Per Jessen, Zürich (1.7°C)
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
Bryen Yunashko wrote:
So you mean some kind of congress (or Bundestag, or Parliament or
however you want to name it?) On Wed, Dec 28, 2011 at 3:03 PM, Per
Jessen<per(a)opensuse.org>
wrote:
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.
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(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
Can you explain
the nature of the debate and what you think the
steering committee should/should not do? 
1 Jan
1 Jan
7:51 p.m.
New subject: [opensuse-project] RFC - opensuse steering committee ?
-----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))
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
iF4EAREIAAYFAk8BDaIACgkQja8UbcUWM1wqtAD/TE8ChYdLXG7dEruy4d+U1ydw
DhHhVCGwGb3mjOg/xPcA/jE7xI5/Ahw+OROg6X0t/P/PykSb4l7iPH8kY0IC1JoV
=tN8W
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
28 Dec
28 Dec
3:33 p.m.
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.
--
kind regards, -o) German Wiki Team
Kim Leyendecker /\\ Documentation& marketing
www.opensuse.org _\_v leyendecker(a)opensuse.org
=====================================================
my GPG Key: 664265369547B825 | IRC: k-d-l
Twitter: kim_d_ley | Wiki-Username: openLHAG
openSUSE - Linux for open minds - get it free today!
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
3:43 p.m.
Kim Leyendecker wrote:
On 28.12.2011 22:03, Per Jessen wrote:
AFAIK, the board is not tasked with any project _steering_ whatsoever.
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?
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.
--
Per Jessen, Zürich (1.9°C)
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
4:05 p.m.
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
--
kind regards, -o) German Wiki Team
Kim Leyendecker /\\ Documentation& marketing
www.opensuse.org _\_v leyendecker(a)opensuse.org
=====================================================
my GPG Key: 664265369547B825 | IRC: k-d-l
Twitter: kim_d_ley | Wiki-Username: openLHAG
openSUSE - Linux for open minds - get it free today!
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
4:05 p.m.
Le 28/12/2011 23:05, Kim Leyendecker a écrit :
On 28.12.2011 22:43, Per Jessen wrote:
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
--
http://www.dodin.net
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
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
6:06 p.m.
New subject: [opensuse-project] RFC - opensuse steering committee ?
On Wed, Dec 28, 2011 at 5:05 PM, Kim Leyendecker
<leyendecker(a)opensuse.org> wrote:
On 28.12.2011 22:43, Per Jessen wrote:
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(a)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
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
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
29 Dec
29 Dec
1:29 a.m.
New subject: [opensuse-project] RFC - opensuse steering committee ?
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
--
http://www.dodin.net
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
4:16 p.m.
New subject: [opensuse-project] RFC - opensuse steering committee ?
On Thu, Dec 29, 2011 at 2:29 AM, jdd <jdd(a)dodin.org> wrote:
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
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
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.
4:25 p.m.
New subject: [opensuse-project] RFC - opensuse steering committee ?
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
--
http://www.dodin.net
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
6:54 a.m.
New subject: [opensuse-project] RFC - opensuse steering committee ?
On 29.12.2011 01:06, Greg Freemyer wrote:
On Wed, Dec 28, 2011 at 5:05 PM, Kim Leyendecker
<leyendecker(a)opensuse.org> wrote:
I actually thought he´s also some kind of a moderator.
On 28.12.2011 22:43, Per Jessen wrote:
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. 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
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(a)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
--
kind regards, -o) German Wiki Team
Kim Leyendecker /\\ Documentation& marketing
www.opensuse.org _\_v leyendecker(a)opensuse.org
=====================================================
my GPG Key: 664265369547B825 | IRC: k-d-l
Twitter: kim_d_ley | Wiki-Username: openLHAG
openSUSE - Linux for open minds - get it free today!
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
30 Dec
30 Dec
2:49 a.m.
New subject: [opensuse-project] RFC - opensuse steering committee ?
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
--
Per Jessen, Zürich (2.8°C)
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
12:28 p.m.
New subject: [opensuse-project] RFC - opensuse steering committee ?
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
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
2:50 p.m.
New subject: [opensuse-project] RFC - opensuse steering committee ?
Greg Freemyer wrote:
Definitely. Let's see what the uptake is like after the holidays, many
people are busy doing more sensible things :-)
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.
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, Zürich (2.6°C)
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
4:08 p.m.
New subject: [opensuse-project] RFC - opensuse steering committee ?
Per Jessen <per(a)opensuse.org> wrote:
Greg Freemyer wrote:
Definitely. Let's see what the uptake is like after the holidays, many
people are busy doing more sensible things :-)
+1 couldn't agree more
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.
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, Zürich (2.6°C)
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
--kdl
--
sent from Smartphone, sorry for my briefity
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
4:31 p.m.
New subject: [opensuse-project] Re: RFC - opensuse steering committee ?
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
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
4:52 p.m.
New subject: [opensuse-project] Re: RFC - opensuse steering committee ?
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
5:05 p.m.
New subject: [opensuse-project] Re: RFC - opensuse steering committee ?
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(a)gmail.com> schrieb:
listeners
--
Kim Leyendecker
sent from smartphone
sorry for my briefity
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
> 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 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(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
2 Jan
2 Jan
3:31 p.m.
New subject: [opensuse-project] Re: RFC - opensuse steering committee ?
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.
--
Per Jessen, Zürich (6.2°C)
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
30 Dec
30 Dec
5:07 p.m.
New subject: [opensuse-project] Re: RFC - opensuse steering committee ?
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
--
http://www.dodin.net
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
5:28 p.m.
New subject: [opensuse-project] Re: RFC - opensuse steering committee ?
On Fri, Dec 30, 2011 at 6:07 PM, jdd <jdd(a)dodin.org> wrote:
Le 30/12/2011 23:52, Greg Freemyer a écrit :
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
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
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.
5:46 p.m.
New subject: [opensuse-project] Re: RFC - opensuse steering committee ?
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
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
2 Jan
2 Jan
8:10 a.m.
New subject: [opensuse-project] Re: RFC - opensuse steering committee ?
Kim Leyendecker <leyendecker(a)opensuse.org> wrote:
Greg wrote:
My belief is we have a defacto steering committee. If so, simply documenting the current
steering process adds transparency but adds no delays.
Greg
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
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 
10:05 a.m.
New subject: [opensuse-project] Re: RFC - opensuse steering committee ?
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.
--
Regards, Rajko
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
3:26 p.m.
New subject: [opensuse-project] Re: RFC - opensuse steering committee ?
Rajko M. wrote:
On Monday, January 02, 2012 09:10:08 AM Greg Freemyer
wrote:
...
I didn't intend that we _add_ a committee, that would indeed be
pointless.
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 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.
--
Per Jessen, Zürich (6.2°C)
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
9:13 p.m.
New subject: [opensuse-project] Re: RFC - opensuse steering committee ?
On Monday, January 02, 2012 03:26:37 PM Per Jessen wrote:
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.
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?!
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.
--
Regards,
Rajko
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
Rajko M. wrote:
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.
On Monday, January 02, 2012 09:10:08 AM Greg
Freemyer wrote:
...
I didn't intend that we _add_ a committee, that would indeed be
pointless. 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 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.
7 Jan
7 Jan
6:56 a.m.
New subject: [opensuse-project] Re: RFC - opensuse steering committee ?
Rajko M. wrote:
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.
What a words :)
What supports those words?
http://en.wikipedia.org/wiki/Veto
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. 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. 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, Zürich (2.6°C)
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
7:07 a.m.
New subject: [opensuse-project] Re: RFC - opensuse steering committee ?
Per Jessen wrote:
What a words :)
What supports those words?
http://en.wikipedia.org/wiki/Veto
"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."
--
Per Jessen, Zürich (2.6°C)
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
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.
2 Jan
2 Jan
3:16 p.m.
New subject: [opensuse-project] Re: RFC - opensuse steering committee ?
Greg Freemyer wrote:
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).
--
Per Jessen, Zürich (5.9°C)
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
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
3:04 p.m.
New subject: [opensuse-project] Re: RFC - opensuse steering committee ?
jdd wrote:
Le 30/12/2011 21:50, Per Jessen a écrit :
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.
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
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.
--
Per Jessen, Zürich (6.0°C)
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
16 Jan
16 Jan
5:27 a.m.
New subject: [opensuse-project] RFC - opensuse steering committee ?
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
--
Dr. Gerald Pfeifer <gp(a)suse.com> || SUSE || Director Product Management
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
29 Dec
29 Dec
4:15 p.m.
New subject: [opensuse-project] RFC - opensuse steering committee ?
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(a)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.
--
Per Jessen, Zürich (3.9°C)
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
3:51 p.m.
Kim Leyendecker wrote:
On 28.12.2011 22:43, Per Jessen wrote:
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.
--
Per Jessen, Zürich (4.0°C)
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
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? 
9 Jan
9 Jan
6:17 a.m.
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
--
Best Regards / S pozdravom,
Pavol RUSNAK SUSE LINUX, s.r.o
openSUSE Boosters Team Lihovarska 1060/12
PGP 0xA6917144 19000 Praha 9
prusnak[at]opensuse.org Czech Republic
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
6:35 a.m.
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!
[1] http://en.opensuse.org/openSUSE:Release_team
well said, thanks
jdd
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
3288
days inactive
3307
days old
38 comments
9 participants
participants (9)
-
Bryen Yunashko -
Carlos E. R. -
Gerald Pfeifer -
Greg Freemyer -
jdd -
Kim Leyendecker -
Pavol Rusnak -
Per Jessen -
Rajko M.