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
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
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
nomination process and what the acceptance criteria are. Which should be
more than following the proposed guidelines.
I'm struggling to come up with a good acceptance criteria. Do you have
a good suggestion?
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,
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.
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org