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. -- Per Jessen, Zürich (3.9°C) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org