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