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:
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@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org