Mailinglist Archive: opensuse-factory (435 mails)

< Previous Next >
Re: [opensuse-factory] Re: [RFC] OpenSUSE Distribution Tiers Policy
Hi Robert

On 7/6/20 11:44 AM, Robert Schweikert wrote:
Hi,

On 7/3/20 1:11 PM, Dirk Müller wrote:
Hi all,

I would like to get your input and start a discussion around :

https://en.opensuse.org/openSUSE:OpenSUSE_Distribution_Tiers_Policy

Thanks to all who provided feedback. I've incorporated all of it and
updated it to 20200703 now:

https://en.opensuse.org/openSUSE:OpenSUSE_Distribution_Tiers_Policy

I consider this the final draft.

Please provide any feedback you might have until July 10th.

Well,

"""
The distribution maintainers are filing bugreports on
https://bugzilla.opensuse.org/ for package maintainers if there are
issues identified in the architecture port. The package maintainers
commit to handle primary architectures with care and test-build them in
the development projects before submitting changes. The package
maintainers commit to handle regressions quickly and in general accept
bugreports for that platform and work on a resolution.
"""

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.

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. As long as the
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.

As a package maintainer I either get a say in the work I am committing
to or I will simply flip those that think they can commandeer my time
the bird.

So I think we need an exit condition. I realize that consensus is
extremely hard to gauge in an ML discussion, but we have to try. The
current guideline states nothing about any type of influence of the ML
discussion, it simply states that

"""
Any nomination for a primary architecture should be brought up for
discussion on the respective openSUSE distribution mailing list and also
announced on the opensuse-project@ mailing list.
"""

So the architecture team from "fancy new chipmaker" simply posts a
couple of messages and the ensuing discussions have no influence. That's
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".

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.

I think you may have missed one of the more major requirements, which is
a significant percentage of the distro needs to be building and passing
QA under these guidelines. That really means a team can't just show up
out of know where, they have to put in the effort fix any of the major
issues etc and have everything working. Presumably if you have an arch
dependent bug that you can't fix they would also be willing to help
because if enough people didn't have time and the percentage of packages
building dropped significantly.

So I don't really think its possible under these rules for a chip
manufacturer to come in create a team then expect you to do all the work
or even most of it, Beyond accepting the occasional request and then
maybe handling the occasional architecture specific bug atleast to the
point of asking for help.

--
Simon Lees (Simotek) http://simotek.net

Emergency Update Team keybase.io/simotek
SUSE Linux Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

< Previous Next >