[opensuse-factory] SPDX.org/licenses now at 3.0
Hi all, Seems spdx has been busy finalizing the 3.0 draft and made this now the active licenses on spdx.org/licenses (dated Dec 28 2017) This has alraedy led to 'some confusion', because all our tools still expect/validate on SPDX-2.0 only, and the error messages then point to spdx.org/license; so easily to see how somebody can get frustrated there. We should decide how we in openSUSE want to handle that, and how to handle the transition (if at all). I see basically these options: * Stick with SPDX-2.0 * Accept SPDX-2.0 AND SPDX-3.0 identifiers * Move to SPDX-3.0 Not much more choice than that, is there? :) Of course any kind of 'moving away' from spdx will need tooling adjustments, having spdx-3.0 identifier will mean any build for 'non- latest openSUSE releases' will spit warnings, as they would not know about the new license format being valid. If we decide to stick with SPDX-2.0, then at a bare minimum we have to stop pointing to spdx.org/licenses in our warnings, as this can't possible do us any good. Thoughs? Ideas? Volunteers to pick up the needed work? :) Cheers Dominique
Dominique Leuenberger / DimStar píše v Út 13. 02. 2018 v 16:01 +0100:
Hi all,
Seems spdx has been busy finalizing the 3.0 draft and made this now the active licenses on spdx.org/licenses (dated Dec 28 2017)
This has alraedy led to 'some confusion', because all our tools still expect/validate on SPDX-2.0 only, and the error messages then point to spdx.org/license; so easily to see how somebody can get frustrated there.
We should decide how we in openSUSE want to handle that, and how to handle the transition (if at all).
I see basically these options:
* Stick with SPDX-2.0 * Accept SPDX-2.0 AND SPDX-3.0 identifiers * Move to SPDX-3.0
Not much more choice than that, is there? :)
Of course any kind of 'moving away' from spdx will need tooling adjustments, having spdx-3.0 identifier will mean any build for 'non- latest openSUSE releases' will spit warnings, as they would not know about the new license format being valid.
If we decide to stick with SPDX-2.0, then at a bare minimum we have to stop pointing to spdx.org/licenses in our warnings, as this can't possible do us any good.
Thoughs? Ideas? Volunteers to pick up the needed work? :)
Cheers Dominique
We should probably stick to SPDX-3.0 only, most important is rpmlint to be backported to all supported platforms, but that should be doable too... I got bit annoyed week ago+- as I wanted spec-cleaner to be able to parse the web properly... https://github.com/openSUSE/spec-cleaner/commit/5d8397c52b99e6f8beb0f52 a03796dab8a902aff Cheers Tom
On 02/13/2018 10:10 AM, Tomas Chvatal wrote:
Dominique Leuenberger / DimStar píše v Út 13. 02. 2018 v 16:01 +0100:
Hi all,
Seems spdx has been busy finalizing the 3.0 draft and made this now the active licenses on spdx.org/licenses (dated Dec 28 2017)
This has alraedy led to 'some confusion', because all our tools still expect/validate on SPDX-2.0 only, and the error messages then point to spdx.org/license; so easily to see how somebody can get frustrated there.
We should decide how we in openSUSE want to handle that, and how to handle the transition (if at all).
I see basically these options:
* Stick with SPDX-2.0 * Accept SPDX-2.0 AND SPDX-3.0 identifiers * Move to SPDX-3.0
Not much more choice than that, is there? :)
Of course any kind of 'moving away' from spdx will need tooling adjustments, having spdx-3.0 identifier will mean any build for 'non- latest openSUSE releases' will spit warnings, as they would not know about the new license format being valid.
If we decide to stick with SPDX-2.0, then at a bare minimum we have to stop pointing to spdx.org/licenses in our warnings, as this can't possible do us any good.
Thoughs? Ideas? Volunteers to pick up the needed work? :)
Not volunteering for any work ;) but sharing my opinion anyway.
Cheers Dominique
We should probably stick to SPDX-3.0 only,
+1
most important is rpmlint to be backported to all supported platforms, but that should be doable too...
I got bit annoyed week ago+- as I wanted spec-cleaner to be able to parse the web properly... https://github.com/openSUSE/spec-cleaner/commit/5d8397c52b99e6f8beb0f52 a03796dab8a902aff
I think the whole process should be automated. 1. when running osc build locally the license in the spec file should get transformed from spdx_v2 to spdx_v3 name 2. the checker in OBS should always look at spdx.org/licenses to avoid falling out of sync My $0.02 Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Architect LINUX Team Lead Public Cloud rjschwei@suse.com IRC: robjo
On Tue, 2018-02-13 at 10:18 -0500, Robert Schweikert wrote:
2. the checker in OBS should always look at spdx.org/licenses to avoid falling out of sync
Absolutely not. a) the checker has no internet access b) you really want the build result to differ based on any random external website? Thanks, but no thanks. This MUST be a coordinated, decided action into the distro. Cheers Dominique
On 02/13/2018 10:22 AM, Dominique Leuenberger / DimStar wrote:
On Tue, 2018-02-13 at 10:18 -0500, Robert Schweikert wrote:
2. the checker in OBS should always look at spdx.org/licenses to avoid falling out of sync
Absolutely not.
a) the checker has no internet access b) you really want the build result to differ based on any random external website? Thanks, but no thanks. This MUST be a coordinated, decided action into the distro.
Fair, but then we should not imply that we follow spdx and should just state that we name things as we see fit. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Architect LINUX Team Lead Public Cloud rjschwei@suse.com IRC: robjo
Am 13.02.2018 um 16:31 schrieb Robert Schweikert:
On 02/13/2018 10:22 AM, Dominique Leuenberger / DimStar wrote:
On Tue, 2018-02-13 at 10:18 -0500, Robert Schweikert wrote:
2. the checker in OBS should always look at spdx.org/licenses to avoid falling out of sync
Absolutely not.
a) the checker has no internet access b) you really want the build result to differ based on any random external website? Thanks, but no thanks. This MUST be a coordinated, decided action into the distro.
Fair, but then we should not imply that we follow spdx and should just state that we name things as we see fit.
SPDX 3.0 is a given thing - it doesn't change. Greetings, Stephan -- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn.
On 02/13/2018 04:19 PM, Stephan Kulow wrote:
Am 13.02.2018 um 16:31 schrieb Robert Schweikert:
On 02/13/2018 10:22 AM, Dominique Leuenberger / DimStar wrote:
On Tue, 2018-02-13 at 10:18 -0500, Robert Schweikert wrote:
2. the checker in OBS should always look at spdx.org/licenses to avoid falling out of sync
Absolutely not.
a) the checker has no internet access b) you really want the build result to differ based on any random external website? Thanks, but no thanks. This MUST be a coordinated, decided action into the distro.
Fair, but then we should not imply that we follow spdx and should just state that we name things as we see fit.
SPDX 3.0 is a given thing - it doesn't change.
The point is that if we have to make a decision to go with whatever version they come up with next then the decision is more or less arbitrary. Meaning the decision could just as well be made to stay behind or use a "we pull names out of thin air" approach. If we "follow SPDx" then IMHO it is implied that we move along with the standard => auto-generation of the list based on whatever version is current and no recurring decision about version changes are needed going forward. If we "use SPDx" then we use a specific version, that currently happens to be 2.0, and we clearly need to specify the version we are using => an explicit decision every time the standard version changes is needed; this path also clearly indicates that we just as well might change direction at the next decision point to a "we pull names out of thin air" approach At present the check produces the following error message: """ E: invalid-license (Badness: 100000) LGPL-3.0-or-later The specified license string is not recognized. Please refer to https://spdx.org/licenses/ for the list of known licenses and their exact spelling. """ This implies that every time the standard changes the message is wrong and we will have this discussion again. If we "follow SPDx" then the message is correct and the bug is that we have not moved forward in a timely fashion. If we "use SPDx" the the error message is incorrect and should point to license.opensuse.org Last but not least we should take this opportunity to clearly state what the policy is "follow" or "use" and document this on [1]. I think we should follow the standard but do not really have a strong opinion about the matter. I do however feel reasonably strongly that we should resolve the ambiguity and whatever the decision is we should clearly document it. And yes that implies that the contextual difference between "follow SPDx" and "use SPDx" is understood. Later, Robert [1] https://en.opensuse.org/openSUSE:Specfile_guidelines -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Architect LINUX Team Lead Public Cloud rjschwei@suse.com IRC: robjo
Am 13.02.2018 um 22:56 schrieb Robert Schweikert:
On 02/13/2018 04:19 PM, Stephan Kulow wrote:
Am 13.02.2018 um 16:31 schrieb Robert Schweikert:
On 02/13/2018 10:22 AM, Dominique Leuenberger / DimStar wrote:
On Tue, 2018-02-13 at 10:18 -0500, Robert Schweikert wrote:
2. the checker in OBS should always look at spdx.org/licenses to avoid falling out of sync
Absolutely not.
a) the checker has no internet access b) you really want the build result to differ based on any random external website? Thanks, but no thanks. This MUST be a coordinated, decided action into the distro.
Fair, but then we should not imply that we follow spdx and should just state that we name things as we see fit.
SPDX 3.0 is a given thing - it doesn't change.
The point is that if we have to make a decision to go with whatever version they come up with next then the decision is more or less arbitrary. Meaning the decision could just as well be made to stay behind or use a "we pull names out of thin air" approach.
If we "follow SPDx" then IMHO it is implied that we move along with the standard => auto-generation of the list based on whatever version is current and no recurring decision about version changes are needed going forward.
If we "use SPDx" then we use a specific version, that currently happens to be 2.0, and we clearly need to specify the version we are using => an explicit decision every time the standard version changes is needed; this path also clearly indicates that we just as well might change direction at the next decision point to a "we pull names out of thin air" approach
At present the check produces the following error message:
""" E: invalid-license (Badness: 100000) LGPL-3.0-or-later The specified license string is not recognized. Please refer to https://spdx.org/licenses/ for the list of known licenses and their exact spelling. """
This implies that every time the standard changes the message is wrong and we will have this discussion again. If we "follow SPDx" then the
There is always https://github.com/openSUSE/obs-service-format_spec_file/blob/master/README.... to point to. But having a check that 'follows' is not going to work. We can only jump from spdx version to spdx version explicitly - including a conversion of all spec files. Greetings, Stephan -- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 14 Feb 2018 07:43:07 +0100 Stephan Kulow <coolo@suse.de> wrote:
Am 13.02.2018 um 22:56 schrieb Robert Schweikert:
On 02/13/2018 04:19 PM, Stephan Kulow wrote:
Am 13.02.2018 um 16:31 schrieb Robert Schweikert:
On 02/13/2018 10:22 AM, Dominique Leuenberger / DimStar wrote:
On Tue, 2018-02-13 at 10:18 -0500, Robert Schweikert wrote:
2. the checker in OBS should always look at spdx.org/licenses to avoid falling out of sync
Absolutely not.
a) the checker has no internet access b) you really want the build result to differ based on any random external website? Thanks, but no thanks. This MUST be a coordinated, decided action into the distro.
Fair, but then we should not imply that we follow spdx and should just state that we name things as we see fit.
SPDX 3.0 is a given thing - it doesn't change.
The point is that if we have to make a decision to go with whatever version they come up with next then the decision is more or less arbitrary. Meaning the decision could just as well be made to stay behind or use a "we pull names out of thin air" approach.
If we "follow SPDx" then IMHO it is implied that we move along with the standard => auto-generation of the list based on whatever version is current and no recurring decision about version changes are needed going forward.
If we "use SPDx" then we use a specific version, that currently happens to be 2.0, and we clearly need to specify the version we are using => an explicit decision every time the standard version changes is needed; this path also clearly indicates that we just as well might change direction at the next decision point to a "we pull names out of thin air" approach
At present the check produces the following error message:
""" E: invalid-license (Badness: 100000) LGPL-3.0-or-later The specified license string is not recognized. Please refer to https://spdx.org/licenses/ for the list of known licenses and their exact spelling. """
This implies that every time the standard changes the message is wrong and we will have this discussion again. If we "follow SPDx" then the
There is always https://github.com/openSUSE/obs-service-format_spec_file/blob/master/README.... to point to.
But having a check that 'follows' is not going to work. We can only jump from spdx version to spdx version explicitly - including a conversion of all spec files.
Greetings, Stephan
And how to automagically convert > 10k spec files before we release Leap 15? Dave Plater was 100% on the money: "* Accept SPDX-2.0 AND SPDX-3.0 identifiers if we're going to stick with SPDX, we can depreciate SPDX-2.0 at a later stage. This gives a chance to replace "+" with "or later" and add "only" to the GPL license. Has anyone diffed SPDX-2 and 3 a quick glance only appeared to have a difference with GPL and Apache etc seemed the same?" Thanks, Peter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
For what is worth I've created enhancement request in spec-cleaner to automatically convert the 2.0 versions to 3.0: https://github.com/openSUSE/spec-cleaner/issues/218 Note that the script that is used to generate these files is equal among spec-cleaner and format_spec_file tool. Tom
Am 13.02.2018 um 16:01 schrieb Dominique Leuenberger / DimStar:
Thoughs? Ideas? Volunteers to pick up the needed work? :)
My thought: are they nuts to make a fine working standard incompatible without need? How can they on their front page link to Dec 12 news that Linux kernel now has SPDX identifiers to then release on Dec 28 a new license list that makes all these SPDX identifiers outdated? I say we ignore they did this stupid mistake. Can happen to the best - it was Christmas and possibly they had too much wine. Greetings, Stephan -- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn.
On Tue, Feb 13, 2018 at 04:14:50PM +0100, Stephan Kulow wrote:
My thought: are they nuts to make a fine working standard incompatible without need?
How can they on their front page link to Dec 12 news that Linux kernel now has SPDX identifiers to then release on Dec 28 a new license list that makes all these SPDX identifiers outdated?
My thought exactly. Given the "less than friendly" response of some kernel developers to Greg's effort to introduce the SPDX identifiers to kernel source tree, I'm looking forward to the general response when he is going to come with "Sorry, guys, there is a new version of SPDX and those set-to-stone identifiers have to be changed. But don't worry, these are the right ones - as long as they don't come with SPDX 4.0."
I say we ignore they did this stupid mistake. Can happen to the best - it was Christmas and possibly they had too much wine.
How I wish I could believe they will realize it was a mistake and take it back. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Feb 14, 2018 at 3:57 PM, Michal Kubecek <mkubecek@suse.cz> wrote:
On Tue, Feb 13, 2018 at 04:14:50PM +0100, Stephan Kulow wrote:
My thought: are they nuts to make a fine working standard incompatible without need?
How can they on their front page link to Dec 12 news that Linux kernel now has SPDX identifiers to then release on Dec 28 a new license list that makes all these SPDX identifiers outdated?
My thought exactly. Given the "less than friendly" response of some kernel developers to Greg's effort to introduce the SPDX identifiers to kernel source tree, I'm looking forward to the general response when he is going to come with "Sorry, guys, there is a new version of SPDX and those set-to-stone identifiers have to be changed. But don't worry, these are the right ones - as long as they don't come with SPDX 4.0."
I say we ignore they did this stupid mistake. Can happen to the best - it was Christmas and possibly they had too much wine.
How I wish I could believe they will realize it was a mistake and take it back.
I've been personally super cheesed off about this new revision, especially since I was previously advocating for SPDX adoption in Fedora. This kind of crap will only make things harder going forward, and already changing the identifiers is going to be a mess for various reasons (*stares at BSD and MIT licensed software*). I don't even *like* the changes they made in 3.0, because they make it even more verbose than it already was, removed *yet another* set of expressions, and made it even more difficult to rationalize across the board. What's the point of this anymore?! -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 13/02/18 17:01, Dominique Leuenberger / DimStar wrote:
We should decide how we in openSUSE want to handle that, and how to handle the transition (if at all).
I see basically these options:
* Stick with SPDX-2.0 * Accept SPDX-2.0 AND SPDX-3.0 identifiers * Move to SPDX-3.0
Not much more choice than that, is there?:)
* Accept SPDX-2.0 AND SPDX-3.0 identifiers if we're going to stick with SPDX, we can depreciate SPDX-2.0 at a later stage. This gives a chance to replace "+" with "or later" and add "only" to the GPL license. Has anyone diffed SPDX-2 and 3 a quick glance only appeared to have a difference with GPL and Apache etc seemed the same? Dave P -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Feb 13, 2018 at 04:01:02PM +0100, Dominique Leuenberger / DimStar wrote:
I see basically these options:
* Stick with SPDX-2.0 * Accept SPDX-2.0 AND SPDX-3.0 identifiers * Move to SPDX-3.0
I would prefer (2) and I'm strongly against going with (3) right now. We will get there, eventually, I'm sure, but why the rush? One of the big problems of openSUSE from the point of view of people who do not do package maintenance as their everyday job and can give it only limited amount of time is the hobby of some distribution maintainers (or whatever the correct term is) to continuously invent more and more checks forcing said maintainers to rewrite their specfiles all the time (and study how first - which is not trivial in some cases).
Of course any kind of 'moving away' from spdx will need tooling adjustments, having spdx-3.0 identifier will mean any build for 'non- latest openSUSE releases' will spit warnings, as they would not know about the new license format being valid.
...and this is another problem. Unnecessarily strict checks in Factory enforce new constructions which do not work in older (still supported) distributions. Results either in unreadable specfiles full of %if's or in maintainers resigning on building on anything but Factory. Neither should be considered desirable, AFAICS. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, On Feb 14 21:48 Michal Kubecek wrote:
One of the big problems of openSUSE from the point of view of people who do not do package maintenance as their everyday job and can give it only limited amount of time is the hobby of some distribution maintainers (or whatever the correct term is) to continuously invent more and more checks forcing said maintainers to rewrite their specfiles all the time (and study how first - which is not trivial in some cases).
...and this is another problem. Unnecessarily strict checks in Factory enforce new constructions which do not work in older (still supported) distributions. Results either in unreadable specfiles full of %if's or in maintainers resigning on building on anything but Factory. Neither should be considered desirable, AFAICS.
Amen! Cf. https://lists.opensuse.org/opensuse-packaging/2017-07/msg00079.html where I had written (excerpt): -------------------------------------------------------------------- [obs-service-format_spec_file is moving comments around] In general it seems to be good when openSUSE RPM spec files are in compliance with a reasonable openSUSE standard. But on the other hand enforcing it could be a hindrance for openSUSE contributors to use ready-made RPM spec files from whatever upstream projects also for openSUSE RPMs with only some minor openSUSE-specific adaptions to get software easily built also for openSUSE. What is more important for openSUSE: Be open for others (and accept diversity) or be uniform (to make maintenance easier)? -------------------------------------------------------------------- and cf. https://lists.opensuse.org/opensuse-packaging/2017-07/msg00095.html where I had written (excerpt): -------------------------------------------------------------------- [Poll about Url vs URL in RPM preamble] What is the benefit for openSUSE users and contributors to enforce a special openSUSE uniformity for spelling things like "Url vs URL" regardless that both are valid? I need to repeat myself: What is more important for openSUSE: Be open and accept diversity or enforce uniformity? -------------------------------------------------------------------- Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 15/02/18 11:48, Johannes Meixner wrote:
What is the benefit for openSUSE users and contributors to enforce a special openSUSE uniformity for spelling things like "Url vs URL" regardless that both are valid? +1 This URL vs Url operation was the most ridiculous, petty thing that I've ever seen in openSUSE in my 7 or 8 years of maintaining packages. I think that the openSUSE member who implemented this has a case of "power to the head" disease. He also continually overrides maintainer rights on specific packages I maintain, own the bugs and test before submitting to Factory. I appreciate help but not when it puts the integrity of packages at risk. My mission in openSUSE is to make it user friendly and easily installable, I take a pride in this and also give a lot of my valuable time. Accepting a request on my behalf that has only existed for an hour isn't appreciated. Dave Plater -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Feb 15, 2018 at 12:48:34PM +0200, Dave Plater wrote:
This URL vs Url operation was the most ridiculous, petty thing that I've ever seen in openSUSE in my 7 or 8 years of maintaining packages.
All I can say to this is that I'm very sorry for the role I played in this. While writing about the pointless changes done by spec-cleaner, I used the "URL:" -> "Url:" change as a blatant example of a change which is not only completely pointless but also actually wrong. But I swear all I wanted was spec-cleaner to leave the tag untouched and I always suggested to accept both. Alas, I could only watch Tomáš to completely miss my point and replace enforcing one variant with enforcing the other. :-( (and, by that, unconsciously confirming the problem I was talking about in the first place)
My mission in openSUSE is to make it user friendly and easily installable, I take a pride in this and also give a lot of my valuable time. Accepting a request on my behalf that has only existed for an hour isn't appreciated.
Another long term problem of openSUSE maintenance. Fortunately, at least this one (accepting requests before package maintainer has chance to review them) tends to happen less frequently in the last year or so, AFAICS. Or perhaps I'm just lucky. However, the primary problem is still the same: distribution maintainers do not trust package maintainers and do not respect them. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 15/02/18 21:54, Michal Kubecek wrote:
ll I can say to this is that I'm very sorry for the role I played in this. While writing about the pointless changes done by spec-cleaner, I used the "URL:" -> "Url:" change as a blatant example of a change which is not only completely pointless but also actually wrong.
But I swear all I wanted was spec-cleaner to leave the tag untouched and I always suggested to accept both. Alas, I could only watch Tomáš to completely miss my point and replace enforcing one variant with enforcing the other.:-( (and, by that, unconsciously confirming the problem I was talking about in the first place)
I'm currently in a discussion with the board about Tomas's other antics, it wouldn't surprise me if he rigged the online poll that he made about url. I've never had the opportunity to actually meet him but I suspect he has sociopathic tendencies. I was amazed when I found out that he's actually a member of the board. Dave -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 16/02/18 08:24, Dave Plater wrote:
On 15/02/18 21:54, Michal Kubecek wrote:
ll I can say to this is that I'm very sorry for the role I played in this. While writing about the pointless changes done by spec-cleaner, I used the "URL:" -> "Url:" change as a blatant example of a change which is not only completely pointless but also actually wrong.
But I swear all I wanted was spec-cleaner to leave the tag untouched and I always suggested to accept both. Alas, I could only watch Tomáš to completely miss my point and replace enforcing one variant with enforcing the other.:-( (and, by that, unconsciously confirming the problem I was talking about in the first place)
I'm currently in a discussion with the board about Tomas's other antics, it wouldn't surprise me if he rigged the online poll that he made about url. I've never had the opportunity to actually meet him but I suspect he has sociopathic tendencies. I was amazed when I found out that he's actually a member of the board.
Dave
This is very embarrassing, this was supposed to be a private email and not to the list. Dave P -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dne pátek 16. února 2018 8:28:03 CET, Dave Plater napsal(a):
On 16/02/18 08:24, Dave Plater wrote:
I've never had the opportunity to actually meet him but I suspect he has sociopathic tendencies. I was amazed when I found out that he's actually a member of the board.
This is very embarrassing, this was supposed to be a private email and not to the list.
And as I know Tomáš, it is completely wrong... -- Vojtěch Zeisek https://trapa.cz/
On 16/02/18 10:02, Vojtěch Zeisek wrote:
Dne pátek 16. února 2018 8:28:03 CET, Dave Plater napsal(a):
On 16/02/18 08:24, Dave Plater wrote:
I've never had the opportunity to actually meet him but I suspect he has sociopathic tendencies. I was amazed when I found out that he's actually a member of the board.
This is very embarrassing, this was supposed to be a private email and not to the list.
And as I know Tomáš, it is completely wrong...
I appologise again for sending this message, it was completely wrong. Dave Plater -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 2018-02-16 at 08:24 +0200, Dave Plater wrote: ...
I'm currently in a discussion with the board about Tomas's other antics, it wouldn't surprise me if he rigged the online poll that he made about url. I've never had the opportunity to actually meet him but I suspect he has sociopathic tendencies. I can confirm that, Tomas also tortures little animals and regulary attends satanic massed.
M
On 16/02/18 10:17, martin@pluskal.org wrote:
On Fri, 2018-02-16 at 08:24 +0200, Dave Plater wrote: ...
I'm currently in a discussion with the board about Tomas's other antics, it wouldn't surprise me if he rigged the online poll that he made about url. I've never had the opportunity to actually meet him but I suspect he has sociopathic tendencies. I can confirm that, Tomas also tortures little animals and regulary attends satanic massed.
M
I'm actually giving up, read my conversation with Richard Dave -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 14 February 2018 at 21:48, Michal Kubecek <mkubecek@suse.cz> wrote:
One of the big problems of openSUSE from the point of view of people who do not do package maintenance as their everyday job and can give it only limited amount of time is the hobby of some distribution maintainers (or whatever the correct term is) to continuously invent more and more checks forcing said maintainers to rewrite their specfiles all the time (and study how first - which is not trivial in some cases).
...and this is another problem. Unnecessarily strict checks in Factory enforce new constructions which do not work in older (still supported) distributions. Results either in unreadable specfiles full of %if's or in maintainers resigning on building on anything but Factory. Neither should be considered desirable, AFAICS.
And yet, my recent foray into implementing such checks into Factory has given me a very different perspective. Of the 207+ changes needed to get rid of /var/adm/fillup-templates, the _vast_ majority of the changes were accepted without issue, long before any such checks were live in Factory. The rate of acceptance of such changes was much faster than I or anyone I spoke to beforehand had expected. There was some modification of my changes to better suit the personal tastes of how some maintainers wanted their specfiles to look, and that was absolutely fine - the end result was aligned to what we collectively needed in Factory. The _only_ packages which were not modified before the strict checks went live all are firmly maintained by people using @suse.* addresses, who are meant to be doing package maintainer as their everyday job. The _only_ negative feedback I got complaining about the changes or checks at all, were from people with @suse.* addresses, who are meant to be doing package maintainer as their everyday job. Luckily these examples however represented a very tiny handful of the maintainers involved in helping me with that effort.
From that example, I'm left with an impression that our Project at large are quite capable of handling the Factory process and the introduction of new even stricter tests. I never expected Leap 15 to be /var/adm/fillup-templates free with a flat /var btrfs subvolume, but now it will be.
My impression is that if there is a problem anywhere, it is a small subset of professionals doing package maintainer as their everyday job who might need to consider how they could do a better job of keeping up with their peers, including those volunteers doing this in their spare time. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 15.02.2018 um 11:24 schrieb Richard Brown:
The _only_ negative feedback I got complaining about the changes or checks at all, were from people with @suse.* addresses, who are meant to be doing package maintainer as their everyday job.
I do of course not know who complained, but I just wanted to remind that there are people with @suse.* addresses whose everyday job is not package maintainance, but they just do it in their spare time. Their every day job might as well be fixing problems for paying customers. I know because I work with some of them every day (as a customer ;-) Now if we want to discuss overly strict rpmlint checks and the stupid habit of forcing format_spec_file on people via project config, so that I always need to use "osc {build,commit} --noservice", I'm all open for a long weekend of flamewars^Whealthy discussions :-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 15 February 2018 at 18:05, Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
Am 15.02.2018 um 11:24 schrieb Richard Brown:
The _only_ negative feedback I got complaining about the changes or checks at all, were from people with @suse.* addresses, who are meant to be doing package maintainer as their everyday job.
I do of course not know who complained, but I just wanted to remind that there are people with @suse.* addresses whose everyday job is not package maintainance, but they just do it in their spare time. Their every day job might as well be fixing problems for paying customers. I know because I work with some of them every day (as a customer ;-)
Absolutely - I chose my words carefully to try and imply this but to be abundantly clear, among those dozens of volunteers who made the transition easy was dozens of SUSE colleagues acting in either professional, or voluntary capacities. It generally was a very pleasing experience. But, my point there remains, the negative exceptions had the previously stated attributes in common. It's important we reflect on that and consider it when discussing these things.
Now if we want to discuss overly strict rpmlint checks and the stupid habit of forcing format_spec_file on people via project config, so that I always need to use "osc {build,commit} --noservice", I'm all open for a long weekend of flamewars^Whealthy discussions :-)
If only life was so simple. Right now I am having to do significant amounts of extra work precisely because I accept there are people like you doing "osc {foo} --noservice". This won't save you in the long run either, as you can soon example needing to deal a barrage of important SR's with another bulk change in Factory from me. And this bulk change will almost certainly come with additional rpmlint checks also. Given the topic I'm currently investigating is one with legal implications, I imagine we'll have to lean on the very strict side of things there also. All of this would be avoided if everyone was just using spec_cleaner automatically, as that is already able of taking care of the problem I'm addressing. So, ironically we're currently living a situation where your avoidance of spec_cleaner has created both more work for all of us, and more checks for all of us.. I like my job, so I don't think it's worthy of long flamewars^Whealthy discussions, but maybe it's worth thinking over whether your behaviour actually helps with what you're aiming for? - R -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 15.02.2018 19:42, Richard Brown wrote:
All of this would be avoided if everyone was just using spec_cleaner automatically, as that is already able of taking care of the problem I'm addressing.
* format_spec_file reformats my spec file even for local build in ways I don't like * it is probably written in a language I refuse to use and thus I am not able / willing to fix that. * other forced _service runs make it impossible to test build locally without first adding / removing stuff ("foo bar is not mentioned" type errors) * format_spec_file inserts SUSE copyrights for current year for packages, no SUSE employee has touched in a copyright-significant way in almoast decades. And as long as this is the current state of affairs (I only saw the "SUSE Copyright" and the "forced service prevents local build", I'll keep "alias osc='osc --noservice'" in my global exports.
So, ironically we're currently living a situation where your avoidance of spec_cleaner has created both more work for all of us, and more checks for all of us.> I like my job, so I don't think it's worthy of long flamewars^Whealthy discussions, but maybe it's worth thinking over whether your behaviour actually helps with what you're aiming for?
I'm aiming for "maintaining my packages without constant annoyance by tools / policies". I do, for example, deliberately not contribute to projects which have a high paperwork-to-efficiency ratio. FSF owned software for example: last time I looked you needed to sign lots of paperwork with copyright assignment etc. I just don't to this to just contribute a quick fix (for FSF stuff, the work around is usually to just yell "I release this patch into the public domain" and then someone will take it). Or openStack to name a prime example of a project actively trying to scare contributors away with crazy contributor agreements. I like to contribute to the linux kernel for example, where the technical hurdles (the quality bar) is high, but the administrative overhead is low: [x] checkpatch.pl ok [x] signed-off-by added [x] maintainer agrees this is a fix => the patch is in. And if you are a newbie trying to just add the USB ID of your WIFI stick to a driver and are not used to the techy staff at lmkl, there are guys around to help you get your simple patch in (me, sometimes ;-) Until now, openSUSE was below my annoyance threshold, even though rpmlint checks like "FSF ADRESS WRONG IN SOURCE FILE" (something a package maintainer usually has absolutely no way of changing) are trying to push this over the edge. Back to topic: IMHO the only way forward is keeping old SPDX format, at least until the last distributions that have a check for these are out of support (SLES11 currently until 2022-03-31) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 2018-02-16 at 10:31 +0100, Stefan Seyfried wrote:
Back to topic: IMHO the only way forward is keeping old SPDX format, at least until the last distributions that have a check for these are out of support (SLES11 currently until 2022-03-31)
SLE11 is about the worst argument you can bring to keep SPDX-2.0 - as SLE11 did not use SPDX-2.0 at the time. In SLE11, we still have licesnes like "GPL v2 or later" - SPDX-2.x would have bee GPL-2.0+ and SPDX-3.0 would ge GPL-3.0-or-later Anyway, the stones started moving and the current way being worked on is: rpmlint will accept SPDX-3-.0 as the main license strings. The few SPDX-2.0 strings that would be no longer available are added to the list of allowed licenses. So that means a spec file with GPL-3.0+ is as valid as GPL-3.0-or- later. obs-service-format_spec_file will rewrite the license to SPDX-3.0 format. This will result in 'old' distros (anyhting released prior to Leap 15) to 'warn' about invalid licenses, but outside of the openSUSE:* namespace, invalid licenses are a warning only and can be ignored. License strings are only enforced inside the openSUSE:* namespace (this is not new) This is the cleanest solution forward I can think of, allowing TW/{SLE,Leap}15 to move forward, and not breaking every spec file we curretnly have. Over time I expect the spec files in TW to have moved to SPDX-3.0 - that's when I'll revisit rpmlint changes and possibly no longer accepting SPDX-2.0 identifiers. But this is not goint to be int he next few weeks. Cheers Dominique
On Fri, Feb 16, 2018 at 10:41:53AM +0100, Dominique Leuenberger / DimStar wrote:
Anyway, the stones started moving and the current way being worked on is:
rpmlint will accept SPDX-3-.0 as the main license strings. The few SPDX-2.0 strings that would be no longer available are added to the list of allowed licenses.
So that means a spec file with GPL-3.0+ is as valid as GPL-3.0-or- later.
Glad to hear that.
obs-service-format_spec_file will rewrite the license to SPDX-3.0 format.
Very unhappy to hear this, though.
This will result in 'old' distros (anyhting released prior to Leap 15) to 'warn' about invalid licenses, but outside of the openSUSE:* namespace, invalid licenses are a warning only and can be ignored. License strings are only enforced inside the openSUSE:* namespace (this is not new)
What I do quite often is e.g. osc checkout openSUSE:Factory $package cd openSUSE:Factory/${package} osc build ... --alternative-project openSUSE:Leap:42.3:Update Such build would fail when your plan is implemented.
This is the cleanest solution forward I can think of, allowing TW/{SLE,Leap}15 to move forward, and not breaking every spec file we curretnly have. Over time I expect the spec files in TW to have moved to SPDX-3.0 - that's when I'll revisit rpmlint changes and possibly no longer accepting SPDX-2.0 identifiers. But this is not goint to be int he next few weeks.
What I would prefer would be to either stick with 2.0 identifiers in specfiles or make sure 3.0 identifiers would be also accepted when building against those projects which currently enforce SPDX-2.0 identifiers for License tag. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 16/02/18 20:01, Stefan Seyfried wrote:
On 15.02.2018 19:42, Richard Brown wrote:
All of this would be avoided if everyone was just using spec_cleaner automatically, as that is already able of taking care of the problem I'm addressing.
* format_spec_file reformats my spec file even for local build in ways I don't like * it is probably written in a language I refuse to use and thus I am not able / willing to fix that. * other forced _service runs make it impossible to test build locally without first adding / removing stuff ("foo bar is not mentioned" type errors) * format_spec_file inserts SUSE copyrights for current year for packages, no SUSE employee has touched in a copyright-significant way in almoast decades.
And as long as this is the current state of affairs (I only saw the "SUSE Copyright" and the "forced service prevents local build", I'll keep "alias osc='osc --noservice'" in my global exports.
So, ironically we're currently living a situation where your avoidance of spec_cleaner has created both more work for all of us, and more checks for all of us.> I like my job, so I don't think it's worthy of long flamewars^Whealthy discussions, but maybe it's worth thinking over whether your behaviour actually helps with what you're aiming for?
I'm aiming for "maintaining my packages without constant annoyance by tools / policies". I do, for example, deliberately not contribute to projects which have a high paperwork-to-efficiency ratio. FSF owned software for example: last time I looked you needed to sign lots of paperwork with copyright assignment etc. I just don't to this to just contribute a quick fix (for FSF stuff, the work around is usually to just yell "I release this patch into the public domain" and then someone will take it). Or openStack to name a prime example of a project actively trying to scare contributors away with crazy contributor agreements.
I like to contribute to the linux kernel for example, where the technical hurdles (the quality bar) is high, but the administrative overhead is low: [x] checkpatch.pl ok [x] signed-off-by added [x] maintainer agrees this is a fix => the patch is in. And if you are a newbie trying to just add the USB ID of your WIFI stick to a driver and are not used to the techy staff at lmkl, there are guys around to help you get your simple patch in (me, sometimes ;-)
But when you contribute to the kernel you follow any coding style guidelines etc right? This tool is just enforcing openSUSE's coding standards, I don't always agree with the standard (I prefer much more whitespace) but i'm happy to accept its part of the projects coding style guidelines and I have to follow them just like I do contributing to every other project.
Until now, openSUSE was below my annoyance threshold, even though rpmlint checks like "FSF ADRESS WRONG IN SOURCE FILE" (something a package maintainer usually has absolutely no way of changing) are trying to push this over the edge.
That one is on my to fix list. You can -- 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
On Thu, Feb 15, 2018 at 11:24:53AM +0100, Richard Brown wrote:
On 14 February 2018 at 21:48, Michal Kubecek <mkubecek@suse.cz> wrote:
...and this is another problem. Unnecessarily strict checks in Factory enforce new constructions which do not work in older (still supported) distributions. Results either in unreadable specfiles full of %if's or in maintainers resigning on building on anything but Factory. Neither should be considered desirable, AFAICS.
And yet, my recent foray into implementing such checks into Factory has given me a very different perspective.
Of the 207+ changes needed to get rid of /var/adm/fillup-templates, the _vast_ majority of the changes were accepted without issue, long before any such checks were live in Factory. The rate of acceptance of such changes was much faster than I or anyone I spoke to beforehand had expected. There was some modification of my changes to better suit the personal tastes of how some maintainers wanted their specfiles to look, and that was absolutely fine - the end result was aligned to what we collectively needed in Factory.
Alternative explanation: survivorship bias. You chose to only count people who learned to live with previous annoying checks and for whom this is only one nuisance in a long row. You ignore those who already left, you ignore those who might join but won't because of the problem. It's not meant to provoke. I know real flesh-and-bone people who do not want to have anything to do with openSUSE package maintenance because of the problem. I know real people who are happy to polish some package in their home project but have absolutely no intention to suffer the pain of getting it into Factory (some even prefer the pain of getting them into SLE without them being in Factory). And I can't blame them at all. Quite the opposite, my decision to do otherwise with those few packages I care for for various reasons is being challenged way too often.
The _only_ packages which were not modified before the strict checks went live all are firmly maintained by people using @suse.* addresses, who are meant to be doing package maintainer as their everyday job.
The _only_ negative feedback I got complaining about the changes or checks at all, were from people with @suse.* addresses, who are meant to be doing package maintainer as their everyday job.
It's hard to believe, given how few SUSE R&D employees have packaging as their everyday job. (20? Probably not even that.) It seems more likely that you don't realize what people in R&D are actually doing for their job. I, for one, spend perhaps 2-3 per cent of my work time by packaging. (Funny enough, it could be even less if it wasn't for the continuous tightening of the screws and new annoying checks.) Across the kernel teams, I'm pretty sure I'm still safely above average with that. Yes, even most SUSE employees have to do actual packaging only now and then (if at all) and even then, it mostly consists of adding a bug fix or rebasing to a new upstream version which are rather routing tasks. Or rather this is what it would look like if it wasn't for the problem we are discussing.
My impression is that if there is a problem anywhere, it is a small subset of professionals doing package maintainer as their everyday job who might need to consider how they could do a better job of keeping up with their peers, including those volunteers doing this in their spare time.
Alternative explanation: SUSE R&D employees are just more likely to be vocal about the problem. Partly thanks to the fact that for them, you and the distribution maintainers are "just people", partly because some of them also maintain those packages in SLE and it's much harder to get rid of a package there. (Again, I'm assuming, you in fact meant SUSE R&D employees in general, not only those few who actual have packaging as their everyday job.) Please, leave your ivory tower for a moment. Please, stop patting each other's backs and telling each other how great job you are doing in improving the distribution. Please, stop for a moment and try to imagine what it looks like from the point of view of an occasional package maintainer who cannot and/or does not want to spend half of their packaging time by making it compliant to your latest whims. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (14)
-
Dave Plater -
Dominique Leuenberger / DimStar -
Johannes Meixner -
martin＠pluskal.org -
Michal Kubecek -
Neal Gompa -
Peter Linnell -
Richard Brown -
Robert Schweikert -
Simon Lees -
Stefan Seyfried -
Stephan Kulow -
Tomas Chvatal -
Vojtěch Zeisek