On Mon, 1 Jul 2019 at 12:28, Michal Suchánek <msuchanek@suse.de> wrote:
On Mon, 1 Jul 2019 11:05:20 +0200 Richard Brown <RBrownCCB@opensuse.org> wrote:
On Mon, 1 Jul 2019 at 10:41, Johannes Meixner <jsmeix@suse.de> wrote:
So by striving to have uniform, easy-to-maintain packages we get less packages. And less packagers, too.
In general uniformity does not make life easier for free openSUSE contributors but perhaps uniformity is mainly useful for some special SUSE maintenance people?
The current processes are open to anyone, and the standards have been established through regular iterations by the the diverse openSUSE community, who are also responsible for their implementation. openSUSE's level of engineering excellence is repeatedly cited as a reason many of our users are drawn to our offerings. We should never put that at risk.
I notice many of the complainants against the status quo in this thread are SUSE employees who are either expressing opinions or relaying the opinions of others that do not comply with SUSE's Open Source Policy.
https://opensource.suse.com/suse-open-source-policy
I would recommend that those employees contact their management to discuss their inability to comply or disinterest in following company policy. The benefit or lack thereof a publicly announced company policy is best not discussed on any mailing-list.
I would also point out that if the openSUSE community reduced its level of quality and uniformity in the codebase, there is a significant chance that openSUSE's usefulness to SUSE would be directly impacted.
I think there is a misrepresentation of SUSE company policy here. Contributions to openSUSE might be desirable but I see no policy that would require that opensource tools used internally by employees should be submitted to openSUSE.
Quoting from the policy: "Our approach to Open Source is “Open Source first, upstream first”. " "We develop in the open and publish our code as Open Source. SUSE products are fully Open Source. There are only rare exceptions where we don’t release code as Open Source. Our development model is designed around Open Source to make it easy for our engineers to produce and contribute to Open Source software." "When SUSE starts new projects we usually publish them as Open Source. The standard place for that is GitHub. We have two principal organizations there: SUSE and openSUSE. For projects which are exclusively maintained by SUSE and where we - as a company - intend to take full responsibility of the project, SUSE is the organization to use. To create new projects under the SUSE organization, contact the administrators of the organization at github-owners@suse.de. For projects which have maintainers or co-maintainers from the community who are not employed by SUSE, or for projects which are open to this model, openSUSE is the organization to use. For openSUSE you can reach the administrators by writing to the public mailing list opensuse-project@opensuse.org." "No matter where the project lives, it will be open for collaboration and contributions from the community under the conditions of the chosen license. The GitHub organization only reflects the model of maintainership." "When packaging new Open Source software or adding changes to existing packages follow the “Factory First” model. “Factory” is the common code stream all our distributions are based on. It is the immediate source for openSUSE Tumbleweed and it eventually ends up in openSUSE Leap and the SUSE Linux Enterprise distributions. This is a continuation of the “Upstream First” principle on the distribution level. It reduces maintenance effort and leverages the community. “Factory First” extends to other SUSE products. Packages for all products should generally come from the common code stream our distributions are based on. So for packages you need in any products contribute them to factory first." or to give a more TL;DR version 1- Almost all code developed by SUSE should be open source 2- All that open source code should be open for collaboration and contributions 3- SUSE-centric locations like github.com/SUSE should only be used when SUSE intends to take full responsibility of the codebase. Else openSUSE-centric locations like github.com/openSUSE should be used. 4- Anything ended up in SLE or SLE based products should be following Factory First I think the vast majority of the internal tools you are discussing currently do not comply with at least one of the four points above, and until those tools are compliant with SUSE's own public policy, I consider that a hindrance to openSUSE. We can split hairs about whether or not SUSE should actively submit the tools to openSUSE - I can agree the policy is not clear on that, but it's debating semantics as long as those tools are not open for collaboration and contribution. If the tools were being handled in compliance with SUSE's Open Source policy then openSUSE could adopt them regardless of what you or I wanted ;) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org