Hi Robert,
Basically states that a relatively small group of people gets to decree what I as a maintainer do with my time. I am __not__ OK with that. By example.
Well, I agree there is a trade-off balance in the draft, however I think it's a good one. The prerequisites of becoming a primary architecture have to be met, which means it has to have good (passing) openqa coverage, good build-from-source results and it has to have an active set of maintainers caring about that particular architecture. Under those circumstances, are you still considering this an invasion into your personal freedom of a package maintainer to care or not care about a particular architecture? I think this is the part where a distribution does have to level-set its expectations somewhat, and say what it cares about and what it doesn't care about. This is the core part of the policy.
Let's say that "fancy new chip maker" decides they want openSUSE to run on their "fancy new I promise it's much better" chip. Based on this document all that is needed from "fancy new chip maker" is to put up an architecture team and put it up for discussion.
I find this discussion slightly superficial, so I find it hard to respond constructively. The reason for that is that yes, there is a chance for an abuse here, but if you compare the cost of rolling out a new architecture (which includes but not limited to, designing a new ISA, making it work, building it, convince ecosystem partners to embrace it, build a toolchain, bootstrap it, land support in the various relevant projects upstream (including but not limited to the Linux kernel and the GNU stack of projects)) with the damage produced on the openSUSE package maintainers, those two don't quite compare. We've seen by practical examples that this is an effort of at least 5, probably more like 10 years to introduce a new architecture until it can become a candidate for a primary architecture nomination. And this is a factor of cost of 5+ years for hundreds, probably thousands of engineers, all done on purpose just to make you, Robert, the openSUSE package maintainer, and your life miserable. I have a hard time believing somebody would be willing to fund such an experiment just for that purpose. But to turn it around, what is your suggestion on a better balance on what a primary architecture means ?
architecture team exists and the guidelines are met there is no exit condition and thus if the guidelines are met there is no way, according to the proposal to say "No". What that means is that a small group of 4 or 5 people get to commandeer the time of 100s of volunteers because once the port is primary all package maintainers get committed per the guidelines. I don't think so.
So you're missing one aspect. what is it? adoption of the architecture? user popularity? availability of hardware environments?
So the architecture team from "fancy new chipmaker" simply posts a couple of messages and the ensuing discussions have no influence.
It is more than that, they also have to bootstrap and maintain a port as an additional architecture successfully for a period of time to be able to do the nomination. We can specify the period of time the additional architecture has to be 'following the primary architecture' guidelines already if that's what you're looking for.
not how it should work, IMHO. If the support is not there then the architecture team of "fancy new chipmaker" shouldn't get to claim "we followed the guidelines now we have to be primary".
No, reverse logic does not apply. The answer to the discussion can still be no.
In short I think there needs to be a lot more clarity about the nomination process and what the acceptance criteria are. Which should be more than following the proposed guidelines.
From an informal discussion with a few folks, people rejected the idea of having a vote. There is no benevolent-dictator-for-life in openSUSE, so in lacking of those two options,
I'm struggling to come up with a good acceptance criteria. Do you have a good suggestion? the best process process that I can come up with is the lazy-consensus model ( http://www.apache.org/foundation/glossary.html#LazyConsensus ). This is a popular model under which many open source projects are operating so I was hoping for this to be widely accepted, as it follows 'the one who works decides' mantra. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org