On Saturday 30 November 2013 23:46:37 Wolfgang Rosenauer wrote:
Am 30.11.2013 22:22, schrieb Robert Schweikert:
I would like openSUSE to stay relevant. For example relevant to stay (or get) supported from third party (yes, even closed source) software vendors.
This is extremely difficult.SUSE has a whole team dedicated to get support for SLES from ISVs. Every time an ISVs states supprt for a distribution it costs the ISV a large chunk of money. I am not certain that we can pedal fast and hard enough to make it worth the while of an ISV to state support for openSUSE. There is not necessarily a direct correlation to relevance.
hmm, some examples I have in mind: SpiderOak Spotify Crossover Office
That's not the sort of ISV you are used to probably but none of them has packages for openSUSE but they have for Fedora and Ubuntu at least. And there are probably many more similar to those. And yes I'm pretty sure that the size of the user base is relevant to get their attention.
As we're about 2-3 times larger than Fedora, the size of the userbase seems not to be the reason - or we advertise our user base not very well. And I think it is that: we are not good at marketing and it has gotten much worse over the last year.
I would really prefer someone to be able to make technical decisions if needed. The status quo seems to be that coolo is the one because someone needs to keep Factory working. So we will always need someone to decide and even when I basically trust coolo I think this is not the right approach.
Well, coolo is not the only one making the decisions. We do have a process of getting stuff into factory. This is mostly being followed I think. The process includes publicly proclaiming the intentions of getting a package into factory. When this happens everyone has the opportunity to pipe up and state their case why a given package should or should not be in factory. Not responding as is the case in most cases is also a decision and indicates that people are OK with the submission.
The process is only for new additions to Factory. I'm thinking more about changes done to components already in openSUSE. I'm not aware there is a process (and I couldn't imagine a process for it anyway).
How about we adopt the type of process being used by Debian, Python, Gentoo and others. Example: http://www.python.org/dev/peps/pep-0001/ It is a sensible way of working: proposals have to be put in a document with a defined structure (so you don't forget anything) and then checked before put up for discussion. We don't need committees or dictators, it all still goes via opensuse-factory or opensuse-project, it's just that the discussion gets started with a 'proper' and clear proposal and there's a clear decision path.
I understand the philosophy for Technical Governance to date has largely been 'those who do, decide'. If changes are made in this area, I'd like to think they can keep that spirit, the idea anyone can get involved and that changes are made on their technical merits, not political ones (eg. does the submitter sit on the right steering group? who is their employer?)
Yes, no politics please. Just technical decisions to the best of the project.
Is this a vote/argument for a technical steering committee?
Yes. In some situations in the past I would have liked a group of persons to take technical decisions (based on different input) if there are conflicts in the community about certain things.
See above. I don't think we need it. Right now, Coolo comes to a decision after seeking consensus. We can formalize that and split coolo into a release team or such :D
As mentioned above, I think the way things work right now we make technical decisions, maybe they are not explicit, but they do get made.
Yes, they get made. Often enough not transparent enough in my opinion and not explicit enough but just by ignoring things and let contributors do whatever they like. Yes, that is a decision but not the sort of decisions I like to see. And please don't ask for examples. There are probably not many but it's my feeling and that is enough in the end.
I also don't think that this task should be done by the board but by a different group of people. The 'those who do, decide' is basically something I support to an extend. But we had examples in the past that people who decided only "did it" halfway and put the burden onto the rest of of the community to fix their mess
Yes, that has happened and is definitely not nice behavior to the rest of the community. However I am not certain that a different decision making process would help here, it maybe that a few tweaks to the development model maybe better suited to address these cases.
I'm still concerned that we have no "legitimized" board for escalated technical decisions. For non-critical things the community approach probably is enough but there might be situations where a formal transparent traceable process leading to a decision is needed. Which instance in the community is supposed to decide in such situations today? The board is explicitely (as I understood) not meant to do that.
I think that would all be solved by using the process these other communities use. Want me to whip up a more proper proposal? ;-) /J
Wolfgang