Mailinglist Archive: opensuse-factory (443 mails)

< Previous Next >
Re: [opensuse-factory] Re: please someone help with SR#711379
On Mon, 1 Jul 2019 at 12:28, Michal Suchánek <msuchanek@xxxxxxx> wrote:

On Mon, 1 Jul 2019 11:05:20 +0200
Richard Brown <RBrownCCB@xxxxxxxxxxxx> wrote:

On Mon, 1 Jul 2019 at 10:41, Johannes Meixner <jsmeix@xxxxxxx> 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.

I would recommend that those employees contact their management to
discuss their inability to comply or disinterest in following company
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
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
"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
"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 should only be used
when SUSE intends to take full responsibility of the codebase. Else
openSUSE-centric locations like 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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >