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