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