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