[opensuse-packaging] Packagers - please check your "Url:"s
Hi fellow packagers, as part of a broader https support, many projects have changed there homepages from plain http to https. Some notable mentions: - github.com/* - sourceforge.net/projects/* - *.kde.org - *.gnome.org So the next time you do some package work, check if your Url: tag is now a redirect: $> curl -I http://amarok.kde.org HTTP/1.1 301 Moved Permanently Location: https://amarok.kde.org/ Currently, there are ~2000 (sub-)packages [1] which have a permanent redirect [2]. Kind regards, Stefan [1] https://repology.org/repository/opensuse_tumbleweed [2] https://repology.org/repository/opensuse_tumbleweed/problems -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 3/15/19 11:20 PM, Brüns, Stefan wrote:
Hi fellow packagers,
as part of a broader https support, many projects have changed there homepages from plain http to https.
Some notable mentions:
- github.com/* - sourceforge.net/projects/* - *.kde.org - *.gnome.org
*.gnu.org Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Saturday 2019-03-16 11:11, Bernhard Voelker wrote:
On 3/15/19 11:20 PM, Brüns, Stefan wrote:
Hi fellow packagers,
as part of a broader https support, many projects have changed there homepages from plain http to https.
Some notable mentions:
- github.com/* - sourceforge.net/projects/* - *.kde.org - *.gnome.org
*.gnu.org
Waiting for people to scream "we need a {rpmlint/post-build-check} tool for that" -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 3/16/19 12:06 PM, Jan Engelhardt wrote:
On Saturday 2019-03-16 11:11, Bernhard Voelker wrote:
On 3/15/19 11:20 PM, Brüns, Stefan wrote:
Hi fellow packagers,
as part of a broader https support, many projects have changed there homepages from plain http to https.
Some notable mentions:
- github.com/* - sourceforge.net/projects/* - *.kde.org - *.gnome.org
*.gnu.org
Waiting for people to scream "we need a {rpmlint/post-build-check} tool for that"
Sometimes there's too much automation in this world instead of simply using this ancient tool which works since thousands of years ... it's called "brain". ;-) Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On sob, mar 16, 2019 at 12:06 PM, Jan Engelhardt
On Saturday 2019-03-16 11:11, Bernhard Voelker wrote:
On 3/15/19 11:20 PM, Brüns, Stefan wrote:
Hi fellow packagers,
as part of a broader https support, many projects have changed there homepages from plain http to https.
Some notable mentions:
- github.com/* - sourceforge.net/projects/* - *.kde.org - *.gnome.org
*.gnu.org
Waiting for people to scream "we need a {rpmlint/post-build-check} tool for that"
Nah, that's not a good solution, our packaging is done without an internet connection, so we couldn't check that on the fly. Instead it could be done through spec-cleaner though :P LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am 16.03.19 um 12:06 schrieb Jan Engelhardt:
Waiting for people to scream "we need a {rpmlint/post-build-check} tool for that"
If anyone changes one of "my" packages (with no other, useful change), I'll delete and drop that package immediately. -- 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-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 17/03/2019 06:34, Stefan Seyfried wrote:
Am 16.03.19 um 12:06 schrieb Jan Engelhardt:
Waiting for people to scream "we need a {rpmlint/post-build-check} tool for that"
If anyone changes one of "my" packages (with no other, useful change), I'll delete and drop that package immediately.
Why, there not "your" packages once they leave your home repo, if someone feels like going to the effort of making the distro better by finding and tidying up packages with redirects (or any other minor cleanup) why as packagers is there a good reason for us to stop them? -- 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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tuesday 2019-03-19 02:34, Simon Lees wrote:
On 17/03/2019 06:34, Stefan Seyfried wrote:
Am 16.03.19 um 12:06 schrieb Jan Engelhardt:
Waiting for people to scream "we need a {rpmlint/post-build-check} tool for that"
If anyone changes one of "my" packages (with no other, useful change), I'll delete and drop that package immediately.
Why, there not "your" packages once they leave your home repo
there / they're / their - choose wisely There is a certain ownership being practised in openSUSE, and that is not even a bad thing. The topic of ownership had previously surfaced in Fedora circles that I remember seeing. (My take away of the threads I read once upon a time: some form of ownership is needed if you want to retain people.) https://www.mail-archive.com/devel@lists.fedoraproject.org/msg98245.html
if someone feels like going to the effort of making the distro better by finding and tidying up packages with redirects (or any other minor cleanup) why as packagers is there a good reason for us to stop them?
It depends on whether a compelling or mildly reasonable case can be made for the submission. Loosely speaking, there are three main difficulty levels in that regard on the "number line": objective changes, subjective changes, and bikeshedding. The bikeshed certainly warrants new paint at times, but it's the hardest category to convince of, and so, that's where stops/rejection would be very probable. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am 19.03.19 um 02:34 schrieb Simon Lees:
On 17/03/2019 06:34, Stefan Seyfried wrote:
Am 16.03.19 um 12:06 schrieb Jan Engelhardt:
Waiting for people to scream "we need a {rpmlint/post-build-check} tool for that"
If anyone changes one of "my" packages (with no other, useful change), I'll delete and drop that package immediately.
Why, there not "your" packages once they leave your home repo, if someone feels like going to the effort of making the distro better
...then he can, in the future, do all the work on these packages. -- 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-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 3/21/19 8:01 PM, Stefan Seyfried wrote:
Why, there not "your" packages once they leave your home repo, if someone feels like going to the effort of making the distro better
...then he can, in the future, do all the work on these packages.
I have to admit that this is an issue that is annoying me in openSUSE as well. In any other open source project I have worked so far, it's common that you wait for feedback from the actual maintainer of a package or a piece of code before moving forward with changes. Not in openSUSE as there are multiple project maintainers which can accept submit requests and if you're lucky, the original maintainer is currently unreachable (vacation etc) and you can sneak in some changes without approval from the maintainer. The problem here is that it's not always obvious at first glance which things need to be taken into consideration when making changes to a package. For example, I am maintaining the Python Azure SDK for the Public Cloud Team at SUSE. For the second time now, someone has sent in requests to update just two out of over 100 packages that make up the Python Azure SDK. This broke the installation of the Azure SDK in Factory as the update of all these 100+ needs to be coordinated and there was also recently a disruptive upstream change to the namespace packages which needed some additional work which delayed my update. Since the Public Cloud Team is using packages from Factory for certain tasks, the broken Azure SDK is now causing headache for us. I missed the two submit request mails as there are currently dozens of these mails per day for the devel:languages:python project. I was also quite busy moving apartments during that week so I could not read mail all the time, I would have rejected those requests. Now they were accepted by another d:l:p maintainer and eventually successfully accepted into Factory despite making the Python Azure SDK uninstallable. I'm also surprised that these changes were not blocked by the Factory maintainers despite the fact they introduced breakage. I don't know what I can do to prevent this in the future, but I really wish the communication would work better and people wouldn't just randomly push submit requests to packages without having at least talked to the maintainer of the packages in question first. Good communication is a key point when collaborating in open source projects. I understand and know that no one contributing changes wants to do any harm, but if you are updating random packages that aren't yours without understanding the peculiarities concerning certain packages, you are making the lives of maintainers harder, not easier. Adrian
On 3/21/19 8:27 PM, John Paul Adrian Glaubitz wrote:
[..] but I really wish the communication would work better and people wouldn't just randomly push submit requests to packages without having at least talked to the maintainer of the packages in question first. Good communication is a key point when collaborating in open source projects.
I understand and know that no one contributing changes wants to do any harm, but if you are updating random packages that aren't yours without understanding the peculiarities concerning certain packages, you are making the lives of maintainers harder, not easier.
I think you should coordinate with the other maintainer who acked the broken submit requests how to improve the situation. Is it possible to roll-back the changes? Personally I directly submit requests without contacting the maintainers first. IMHO this would slow down things too much. But I'm locally testing the updates whether stuff still works. Of course this cannot always cover everything. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 3/21/19 8:43 PM, Michael Ströder wrote:
I think you should coordinate with the other maintainer who acked the broken submit requests how to improve the situation. Is it possible to roll-back the changes?
The problem here is that there is only a handful project maintainers for the d:l:p project given the huge number of packages. I have made the experience that in many cases the maintainers seem to be in auto-accept mode which defeats the whole purpose of the review process.
Personally I directly submit requests without contacting the maintainers first. IMHO this would slow down things too much. But I'm locally testing the updates whether stuff still works. Of course this cannot always cover everything.
I think that's okay for packages that have no fixed maintainer. But in my case, the packages are maintained by me through my position in the Public Cloud Team. There is absolutely no need for anyone to step in and send changes, especially since they do not know what the requirements of the Public Cloud Team are. It also applies to important packages such as the kernel, the toolchain, the bootloader and so on. Adrian
On 3/22/19 6:11 AM, John Paul Adrian Glaubitz wrote:
On 3/21/19 8:43 PM, Michael Ströder wrote:
Personally I directly submit requests without contacting the maintainers first. IMHO this would slow down things too much. But I'm locally testing the updates whether stuff still works. Of course this cannot always cover everything.
I think that's okay for packages that have no fixed maintainer. But in my case, the packages are maintained by me through my position in the Public Cloud Team. There is absolutely no need for anyone to step in and send changes, especially since they do not know what the requirements of the Public Cloud Team are.
Well, this reads like SUSE employees always know better than anyone else. I have made opposite experience in some cases.
It also applies to important packages such as the kernel, the toolchain, the bootloader and so on.
Most of the packages I'm contributing to are maintained in SLE. Based on recent experience I'm not confident that SLE packagers always know better what's right. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Friday 2019-03-22 06:11, John Paul Adrian Glaubitz wrote:
On 3/21/19 8:43 PM, Michael Ströder wrote:
I think you should coordinate with the other maintainer who acked the broken submit requests how to improve the situation. Is it possible to roll-back the changes?
The problem here is that [...] d:l:p[ython] [has a] huge number of packages.
1494 devel:languages:python 2085 openSUSE:Factory | grep ^python- 1899 devel:languages:ruby:extensions 2283 devel:languages:haskell:lts:13 3024 devel:languages:perl Package counts are not everything. (Or perhaps they are...) The fact that software, both upstream and in openSUSE, was split over the years suggests that developers felt it made less work for them. There is of course the other extremes, which is micromanage every single line of code (think of the npm-left-pad debacle). It ought to be the duty of software authors not to let that happen. Maybe the maintainers of the other projects are actually robots ;-) (or they just have optimized workflows). We could also throw out some modules :-p -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Friday, March 22, 2019 11:38:37 AM CET Jan Engelhardt wrote:
On Friday 2019-03-22 06:11, John Paul Adrian Glaubitz wrote:
On 3/21/19 8:43 PM, Michael Ströder wrote:
I think you should coordinate with the other maintainer who acked the broken submit requests how to improve the situation. Is it possible to roll-back the changes?
The problem here is that [...] d:l:p[ython] [has a] huge number of packages.
1494 devel:languages:python
You need to add the subprojects: https://build.opensuse.org/project/subprojects/devel:languages:python
3024 devel:languages:perl
This is not even close to the real number: https://build.opensuse.org/project/subprojects/devel:languages:perl But the because of the magic of automating CPAN. The bad side is: * succeeded: 1605 * failed: 741 * unresolvable: 1631 -- SUSE Linux GmbH Maxfeldstrasse 5 90409 Nuernberg Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Friday, March 22, 2019 11:38:37 AM CET Jan Engelhardt wrote:
On Friday 2019-03-22 06:11, John Paul Adrian Glaubitz wrote:
On 3/21/19 8:43 PM, Michael Ströder wrote:
I think you should coordinate with the other maintainer who acked the broken submit requests how to improve the situation. Is it possible to roll-back the changes?
The problem here is that [...] d:l:p[ython] [has a] huge number of packages.
1494 devel:languages:python
You need to add the subprojects: https://build.opensuse.org/project/subprojects/devel:languages:python
3024 devel:languages:perl
This is not even close to the real number: https://build.opensuse.org/project/subprojects/devel:languages:perl But the because of the magic of automating CPAN. The bad side is: * succeeded: 1605 * failed: 741 * unresolvable: 1631 -- SUSE Linux GmbH Maxfeldstrasse 5 90409 Nuernberg Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 3/22/19 11:45 AM, Alberto Planas Dominguez wrote:
3024 devel:languages:perl
This is not even close to the real number:
https://build.opensuse.org/project/subprojects/devel:languages:perl
But the because of the magic of automating CPAN. The bad side is:
* succeeded: 1605 * failed: 741 * unresolvable: 1631
And this exactly my point. If half of the packages in a project are broken, you are not maintaining them. A human maintainer can just only maintain so many packages. Adrian
On 3/22/19 1:01 PM, John Paul Adrian Glaubitz wrote:
On 3/22/19 11:45 AM, Alberto Planas Dominguez wrote:
https://build.opensuse.org/project/subprojects/devel:languages:perl
But the because of the magic of automating CPAN. The bad side is:
* succeeded: 1605 * failed: 741 * unresolvable: 1631
And this exactly my point. If half of the packages in a project are broken, you are not maintaining them. A human maintainer can just only maintain so many packages.
Sorry, I'm lost - probably I didn't follow close enough: if such a little change in 2 packages made so much broken packages, then why not simply revert these 2 SRs? Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Saturday 2019-03-23 18:44, Bernhard Voelker wrote:
On 3/22/19 1:01 PM, John Paul Adrian Glaubitz wrote:
On 3/22/19 11:45 AM, Alberto Planas Dominguez wrote:
https://build.opensuse.org/project/subprojects/devel:languages:perl
But the because of the magic of automating CPAN. The bad side is:
* succeeded: 1605 * failed: 741 * unresolvable: 1631
And this exactly my point. If half of the packages in a project are broken, you are not maintaining them. A human maintainer can just only maintain so many packages.
Sorry, I'm lost - probably I didn't follow close enough:
That. These perl modules were broken beforehand, and can't be broken if *python* ones are added *elsewhere*. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 3/24/19 11:03 AM, Jan Engelhardt wrote:
On Saturday 2019-03-23 18:44, Bernhard Voelker wrote:
Sorry, I'm lost - probably I didn't follow close enough:
That. These perl modules were broken beforehand, and can't be broken if *python* ones are added *elsewhere*.
Ah, thanks. Sorry for the noise. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 3/22/19 11:45 AM, Alberto Planas Dominguez wrote:
On Friday, March 22, 2019 11:38:37 AM CET Jan Engelhardt wrote:
On Friday 2019-03-22 06:11, John Paul Adrian Glaubitz wrote:
On 3/21/19 8:43 PM, Michael Ströder wrote:
I think you should coordinate with the other maintainer who acked the broken submit requests how to improve the situation. Is it possible to roll-back the changes?
The problem here is that [...] d:l:p[ython] [has a] huge number of packages.
1494 devel:languages:python
You need to add the subprojects: https://build.opensuse.org/project/subprojects/devel:languages:python
3024 devel:languages:perl
This is not even close to the real number:
https://build.opensuse.org/project/subprojects/devel:languages:perl
But the because of the magic of automating CPAN. The bad side is:
* succeeded: 1605 * failed: 741 * unresolvable: 1631
But these are just CPAN dumps - and there is a lot of garbage on CPAN. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thursday 2019-03-21 20:27, John Paul Adrian Glaubitz wrote:
On 3/21/19 8:01 PM, Stefan Seyfried wrote:
Why, there not "your" packages once they leave your home repo, if someone feels like going to the effort of making the distro better
...then he can, in the future, do all the work on these packages.
In any other open source project I have worked so far, it's common that you wait for feedback from the actual maintainer of a package [...] of code before moving forward with changes. Not in openSUSE as there are multiple project maintainers which can accept submit requests
.. and requests to add more fine-grained user roles in OBS have gone unheard in the past. On the other hand, the absence of a maintainer (especially if prolonged) should not be able to cause a stall.
For example, I am maintaining the Python Azure SDK for the Public Cloud Team at SUSE. For the second time now, someone has sent in requests to update just two out of over 100 packages that make up the Python Azure SDK. [...]
There are only three maintainers in that project, yourself included, and they all work for SUSE. If it's impossible to coordinate with the two other maintainers, I just wonder how we ever managed to survive the ridiculous amount of 30 listed maintainers with a good mix of non-SUSE poeple in devel:libraries:c_c++ so far.
I missed the two submit request mails as there are currently dozens of these mails per day for the devel:languages:python project. I was also quite busy moving apartments during that week so I could not read mail all the time, I would have rejected those requests. Now they were accepted by another d:l:p maintainer and eventually successfully accepted into Factory despite making the Python Azure SDK uninstallable. I'm also surprised that these changes were not blocked by the Factory maintainers despite the fact they introduced breakage.
Likely because they did not introduce breakage as far as OBS is concerned - are you sure there is a Azure SDK test job in OpenQA?
I don't know what I can do to prevent this in the future, but I really wish the communication would work better and people wouldn't just randomly push submit requests to packages without having at least talked to the maintainer of the packages in question first. Good communication is a key point when collaborating in open source projects.
SRs are a form of communication. It might be a somewhat clunky one due to OBS's implementation (messages and comments are separate entities for example), but they still have fields for messages, comments, and a patch, similar to Github PRs or git-send-email'ed mails. I really wish maintainers would calm down and not interpret the presence of a patch fragment (in SRs, GH PRs, or whatever) as an "uncommunicated attack" on their package and authority, but to interpret such requests as "this is my idea, and this is how it could look in program code". -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 3/21/19 9:10 PM, Jan Engelhardt wrote:
.. and requests to add more fine-grained user roles in OBS have gone unheard in the past.
On the other hand, the absence of a maintainer (especially if prolonged) should not be able to cause a stall.
No, but that also doesn't mean you get to make changes immediately without talking to someone in charge of the package if a package is actively maintained. Not everyone is sitting in front of their computers 24/7, people can become sick or go on vacation. So, a little more patience is not too much to ask for.
For example, I am maintaining the Python Azure SDK for the Public Cloud Team at SUSE. For the second time now, someone has sent in requests to update just two out of over 100 packages that make up the Python Azure SDK. [...]
There are only three maintainers in that project, yourself included, and they all work for SUSE. If it's impossible to coordinate with the two other maintainers, I just wonder how we ever managed to survive the ridiculous amount of 30 listed maintainers with a good mix of non-SUSE poeple in devel:libraries:c_c++ so far.
The problem is the ridiculous amount of submit requests pouring in, especially with changes like "Change phrasing in Summary". This produces a lot of noise and important things fall off the table. This is why I'm not a fan of these micro changes.
I missed the two submit request mails as there are currently dozens of these mails per day for the devel:languages:python project. I was also quite busy moving apartments during that week so I could not read mail all the time, I would have rejected those requests. Now they were accepted by another d:l:p maintainer and eventually successfully accepted into Factory despite making the Python Azure SDK uninstallable. I'm also surprised that these changes were not blocked by the Factory maintainers despite the fact they introduced breakage.
Likely because they did not introduce breakage as far as OBS is concerned - are you sure there is a Azure SDK test job in OpenQA?
The package is uninstallable. I'm pretty sure OBS should catch that on its own and Stephan Kulow already commented that the issue was known and they hoped for a rebuild to fix the issue. The problem is though that the dependencies are hardwired for good reasons and thus a rebuild won't fix them.
I don't know what I can do to prevent this in the future, but I really wish the communication would work better and people wouldn't just randomly push submit requests to packages without having at least talked to the maintainer of the packages in question first. Good communication is a key point when collaborating in open source projects.
SRs are a form of communication. It might be a somewhat clunky one due to OBS's implementation (messages and comments are separate entities for example), but they still have fields for messages, comments, and a patch, similar to Github PRs or git-send-email'ed mails.
Not if I am drowning in submit requests for d:l:p. I'm a human, not a robot. If I receive 150+ mails per day, I can only process that many.
I really wish maintainers would calm down and not interpret the presence of a patch fragment (in SRs, GH PRs, or whatever) as an "uncommunicated attack" on their package and authority, but to interpret such requests as "this is my idea, and this is how it could look in program code".
Look, the problem here is that these packages are primarily for the Public Cloud Team. This means that these packages are of strategic relevance for SUSE and their paying customers. And unless you are willing to take care of all 112+ packages of the Azure SDK, you are not helping me but make my life harder. Thanks, Adrian N�����r��y隊Z)z{.��ZrF��x>�{.n�+������Ǩ��r��i�m��0��ޙ������� ��$j���0�����Ǩ�
On 22/03/2019 15:51, John Paul Adrian Glaubitz wrote:
On 3/21/19 9:10 PM, Jan Engelhardt wrote:
.. and requests to add more fine-grained user roles in OBS have gone unheard in the past.
On the other hand, the absence of a maintainer (especially if prolonged) should not be able to cause a stall.
No, but that also doesn't mean you get to make changes immediately without talking to someone in charge of the package if a package is actively maintained.
Not everyone is sitting in front of their computers 24/7, people can become sick or go on vacation. So, a little more patience is not too much to ask for.
For example, I am maintaining the Python Azure SDK for the Public Cloud Team at SUSE. For the second time now, someone has sent in requests to update just two out of over 100 packages that make up the Python Azure SDK. [...]
There are only three maintainers in that project, yourself included, and they all work for SUSE. If it's impossible to coordinate with the two other maintainers, I just wonder how we ever managed to survive the ridiculous amount of 30 listed maintainers with a good mix of non-SUSE poeple in devel:libraries:c_c++ so far.
The problem is the ridiculous amount of submit requests pouring in, especially with changes like "Change phrasing in Summary". This produces a lot of noise and important things fall off the table. This is why I'm not a fan of these micro changes.
I missed the two submit request mails as there are currently dozens of these mails per day for the devel:languages:python project. I was also quite busy moving apartments during that week so I could not read mail all the time, I would have rejected those requests. Now they were accepted by another d:l:p maintainer and eventually successfully accepted into Factory despite making the Python Azure SDK uninstallable. I'm also surprised that these changes were not blocked by the Factory maintainers despite the fact they introduced breakage.
Likely because they did not introduce breakage as far as OBS is concerned - are you sure there is a Azure SDK test job in OpenQA?
The package is uninstallable. I'm pretty sure OBS should catch that on its own and Stephan Kulow already commented that the issue was known and they hoped for a rebuild to fix the issue. The problem is though that the dependencies are hardwired for good reasons and thus a rebuild won't fix them.
I don't know what I can do to prevent this in the future, but I really wish the communication would work better and people wouldn't just randomly push submit requests to packages without having at least talked to the maintainer of the packages in question first. Good communication is a key point when collaborating in open source projects.
SRs are a form of communication. It might be a somewhat clunky one due to OBS's implementation (messages and comments are separate entities for example), but they still have fields for messages, comments, and a patch, similar to Github PRs or git-send-email'ed mails.
Not if I am drowning in submit requests for d:l:p. I'm a human, not a robot. If I receive 150+ mails per day, I can only process that many.
I really wish maintainers would calm down and not interpret the presence of a patch fragment (in SRs, GH PRs, or whatever) as an "uncommunicated attack" on their package and authority, but to interpret such requests as "this is my idea, and this is how it could look in program code".
Look, the problem here is that these packages are primarily for the Public Cloud Team. This means that these packages are of strategic relevance for SUSE and their paying customers. And unless you are willing to take care of all 112+ packages of the Azure SDK, you are not helping me but make my life harder.
If you are struggling to manage to maintain all these packages then you likely should be talking to your Manager / Team Lead to look at getting extra resources. At the same time the project maintainers of d:l:p should probably be giving atleast 2-3 days for actual maintainers to accept requests before they do, there are plenty of other devel repo's where the maintainers do a much better job of this. -- 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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, On Mar 22 18:08 Simon Lees wrote (excerpt):
If you are struggling to manage to maintain all these packages then you likely should be talking to your Manager / Team Lead to look at getting extra resources.
could you do us a favour and don't treat others as idiots (or perhaps even treat others as inferior) and just leave out any unhelpful smart-alec patronizing know-it-all attitude? I could also show such an attitude for example like: "If you are not struggling to manage to maintain all your packages then you likely should be talking to your Manager / Team Lead to look at getting extra packages to make you more producitve for your salary." Would you like to read that? Would it help you? Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 22/03/2019 18:55, Johannes Meixner wrote:
Hello,
On Mar 22 18:08 Simon Lees wrote (excerpt):
If you are struggling to manage to maintain all these packages then you likely should be talking to your Manager / Team Lead to look at getting extra resources.
could you do us a favour and don't treat others as idiots (or perhaps even treat others as inferior) and just leave out any unhelpful smart-alec patronizing know-it-all attitude?
I could also show such an attitude for example like: "If you are not struggling to manage to maintain all your packages then you likely should be talking to your Manager / Team Lead to look at getting extra packages to make you more producitve for your salary." Would you like to read that? Would it help you?
Well I say this because I know of a number of packages are poorly assigned, unassigned or assigned to someone who doesn't have time to take care of them and its in everyone's best interest that packages are assigned to people who actually have the time to take care of them properly. Hopefully the more this gets passed up the management chain the sooner it will be fixed. If I thought this was an isolated issue I wouldn't have mentioned it. One of the next things on my todo list is to fix the fact that there are a significant number of packages inside Leap that are inherited from SLE that either have no maintainer or no maintainer inside SLE which essentially means there is no easy way to get maintenance updates into Leap. -- 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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, On Mar 22 19:11 Simon Lees wrote (excerpt):
... I know of a number of packages are poorly assigned, unassigned or assigned to someone who doesn't have time to take care of them and its in everyone's best interest that packages are assigned to people who actually have the time to take care of them properly. Hopefully the more this gets passed up the management chain the sooner it will be fixed.
hope dies last... Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Friday 2019-03-22 10:42, Johannes Meixner wrote:
On Mar 22 19:11 Simon Lees wrote (excerpt):
... I know of a number of packages are poorly assigned, unassigned or assigned to someone who doesn't have time to take care of them and its in everyone's best interest that packages are assigned to people who actually have the time to take care of them properly. Hopefully the more this gets passed up the management chain the sooner it will be fixed.
hope dies last...
... but (ultimately) it dies! —N.Semsrott (https://youtu.be/sOLY8-nJBh8?t=374) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 3/22/19 9:41 AM, Simon Lees wrote:
Well I say this because I know of a number of packages are poorly assigned, unassigned or assigned to someone who doesn't have time to take care of them and its in everyone's best interest that packages are assigned to people who actually have the time to take care of them properly. Hopefully the more this gets passed up the management chain the sooner it will be fixed.
I don't know how often I need to repeat this, but: Those packages are mainly used by the Public Cloud Team and we need them to be working and installable for our daily routine. If someone else messes with them without understanding the ramifications, you are hurting us. I just kindly ask people outside the Public Cloud Team not to touch the packages without talking to us.
If I thought this was an isolated issue I wouldn't have mentioned it. One of the next things on my todo list is to fix the fact that there are a significant number of packages inside Leap that are inherited from SLE that either have no maintainer or no maintainer inside SLE which essentially means there is no easy way to get maintenance updates into Leap.
Except that I don't have an issue with the maintenance at all. The reason the update to the Azure package stack was a bit stalled was because upstream made changes to the namespace packages which broke my packaging workflow so I had to made some changes while also spotting some bugs upstream and reporting them. Please don't automatically assume incompetence. And I'm certainly not overwhelmed by the load, I am doing way more than just maintaining these packages. Thanks, Adrian
On 22/03/2019 20:19, John Paul Adrian Glaubitz wrote:
On 3/22/19 9:41 AM, Simon Lees wrote:
Well I say this because I know of a number of packages are poorly assigned, unassigned or assigned to someone who doesn't have time to take care of them and its in everyone's best interest that packages are assigned to people who actually have the time to take care of them properly. Hopefully the more this gets passed up the management chain the sooner it will be fixed.
I don't know how often I need to repeat this, but: Those packages are mainly used by the Public Cloud Team and we need them to be working and installable for our daily routine. If someone else messes with them without understanding the ramifications, you are hurting us. I just kindly ask people outside the Public Cloud Team not to touch the packages without talking to us.
Unfortunately that's not how the openSUSE project works, we welcome contributions from anyone who feels interested enough in creating them, if the contributions break something or don't meet standards maintainers are more then welcome to reject the changes and give feedback as to what changes need to be made in order for the change to be acceptable. In openSUSE creating a submit request is a perfectly valid form of "talking to us"
If I thought this was an isolated issue I wouldn't have mentioned it. One of the next things on my todo list is to fix the fact that there are a significant number of packages inside Leap that are inherited from SLE that either have no maintainer or no maintainer inside SLE which essentially means there is no easy way to get maintenance updates into Leap.
Except that I don't have an issue with the maintenance at all. The reason the update to the Azure package stack was a bit stalled was because upstream made changes to the namespace packages which broke my packaging workflow so I had to made some changes while also spotting some bugs upstream and reporting them.
Yep and in this case the d:l:p maintainers should have given you reasonable time to add a comment in the SR explaining why you couldn't accept those changes at the moment.
Please don't automatically assume incompetence. And I'm certainly not overwhelmed by the load, I am doing way more than just maintaining these packages.
I'm not assuming incompetence, but you were complaining about the amount of emails and not being able to respond to them which tends to suggest a problem with workload.But I kinda understand this, I feel like I have a billion mail filters so that I only read the obs emails I care about and not the 10,000 a month that I don't. -- 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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Friday 2019-03-22 11:20, Simon Lees wrote:
On 22/03/2019 20:19, John Paul Adrian Glaubitz wrote:
I just kindly ask people outside the Public Cloud Team not to touch the packages without talking to us.
Unfortunately that's not how the openSUSE project works, we welcome contributions from anyone [...]. In openSUSE creating a submit request is a perfectly valid form of "talking to us"
Indeed; the only alternative I see here is not to ship Public Cloud in openSUSE Tumbleweed(*). Then the develprj need not fear submissions. (*) There might be room to create another openSUSE subproject that is a sibling to Tumbleweed and Leap. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 22/03/2019 21:31, Jan Engelhardt wrote:
On Friday 2019-03-22 11:20, Simon Lees wrote:
On 22/03/2019 20:19, John Paul Adrian Glaubitz wrote:
I just kindly ask people outside the Public Cloud Team not to touch the packages without talking to us.
Unfortunately that's not how the openSUSE project works, we welcome contributions from anyone [...]. In openSUSE creating a submit request is a perfectly valid form of "talking to us"
Indeed; the only alternative I see here is not to ship Public Cloud in openSUSE Tumbleweed(*). Then the develprj need not fear submissions.
Unfortunately doing so would violate SUSE's open source policy so its not really an option. -- 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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Friday 2019-03-22 12:05, Simon Lees wrote:
On 22/03/2019 21:31, Jan Engelhardt wrote:
On Friday 2019-03-22 11:20, Simon Lees wrote:
On 22/03/2019 20:19, John Paul Adrian Glaubitz wrote:
I just kindly ask people outside the Public Cloud Team not to touch the packages without talking to us.
Unfortunately that's not how the openSUSE project works, we welcome contributions from anyone [...]. In openSUSE creating a submit request is a perfectly valid form of "talking to us"
Indeed; the only alternative I see here is not to ship Public Cloud in openSUSE Tumbleweed(*). Then the develprj need not fear submissions.
Unfortunately doing so would violate SUSE's open source policy so its not really an option.
Is that available for reading anywhere (or I be privately sent a copy)? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 22/03/2019 22:20, Jan Engelhardt wrote:
On Friday 2019-03-22 12:05, Simon Lees wrote:
On 22/03/2019 21:31, Jan Engelhardt wrote:
On Friday 2019-03-22 11:20, Simon Lees wrote:
On 22/03/2019 20:19, John Paul Adrian Glaubitz wrote:
I just kindly ask people outside the Public Cloud Team not to touch the packages without talking to us.
Unfortunately that's not how the openSUSE project works, we welcome contributions from anyone [...]. In openSUSE creating a submit request is a perfectly valid form of "talking to us"
Indeed; the only alternative I see here is not to ship Public Cloud in openSUSE Tumbleweed(*). Then the develprj need not fear submissions.
Unfortunately doing so would violate SUSE's open source policy so its not really an option.
Is that available for reading anywhere (or I be privately sent a copy)?
Sure it was in Richards reply, but in case you missed it https://opensource.suse.com/suse-open-source-policy -- 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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On pią, mar 22, 2019 at 12:01 PM, Jan Engelhardt
On Friday 2019-03-22 11:20, Simon Lees wrote:
On 22/03/2019 20:19, John Paul Adrian Glaubitz wrote:
I just kindly ask people outside the Public Cloud Team not to touch the packages without talking to us.
Unfortunately that's not how the openSUSE project works, we welcome contributions from anyone [...]. In openSUSE creating a submit request is a perfectly valid form of "talking to us"
Indeed; the only alternative I see here is not to ship Public Cloud in openSUSE Tumbleweed(*). Then the develprj need not fear submissions.
(*) There might be room to create another openSUSE subproject that is a sibling to Tumbleweed and Leap.
Don't forget about Kubic and MicroOS, that would be the 5th openSUSE distro ;) LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 3/22/19 12:01 PM, Jan Engelhardt wrote:
Unfortunately that's not how the openSUSE project works, we welcome contributions from anyone [...]. In openSUSE creating a submit request is a perfectly valid form of "talking to us"
Indeed; the only alternative I see here is not to ship Public Cloud in openSUSE Tumbleweed(*). Then the develprj need not fear submissions.
No, I will just lock the project against such requests now. Thanks, Adrian
Am 23.03.19 um 08:57 schrieb John Paul Adrian Glaubitz:
On 3/22/19 12:01 PM, Jan Engelhardt wrote:
Unfortunately that's not how the openSUSE project works, we welcome contributions from anyone [...]. In openSUSE creating a submit request is a perfectly valid form of "talking to us"
Indeed; the only alternative I see here is not to ship Public Cloud in openSUSE Tumbleweed(*). Then the develprj need not fear submissions.
No, I will just lock the project against such requests now.
Maybe just asking Dirk to not do anything on this project or at least not immediately forward things to factory would be enough. I mean -- you are 3 (in words: THREE(!)) maintainers in d-l-p-azure. If you three cannot get your act together... Then it does not really solve the problem if you forbid anyone to try to help you. And the time it took you to write all these mails in this thread... two simple SRs to Factory reverting the changes and everyone would be happy since.... long. -- 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-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 3/25/19 3:53 PM, Stefan Seyfried wrote:
Maybe just asking Dirk to not do anything on this project or at least not immediately forward things to factory would be enough.
Already done.
I mean -- you are 3 (in words: THREE(!)) maintainers in d-l-p-azure. If you three cannot get your act together... Then it does not really solve the problem if you forbid anyone to try to help you.
You are blaming me for something which took place when I wasn't there.
And the time it took you to write all these mails in this thread... two simple SRs to Factory reverting the changes and everyone would be happy since.... long.
Guess what I am doing. Luckily only one of the two packages ended up in Factory. And these discussions are always useful, because in the end, you learn something from it. At least I learned a few things I didn't know before. If you are annoyed by these mails, why do you bother answering them? Just ignore them. Adrian
On Fri, 22 Mar 2019 at 11:20, Simon Lees
On 22/03/2019 20:19, John Paul Adrian Glaubitz wrote:
I don't know how often I need to repeat this, but: Those packages are mainly used by the Public Cloud Team and we need them to be working and installable for our daily routine. If someone else messes with them without understanding the ramifications, you are hurting us. I just kindly ask people outside the Public Cloud Team not to touch the packages without talking to us.
Unfortunately that's not how the openSUSE project works, we welcome contributions from anyone who feels interested enough in creating them, if the contributions break something or don't meet standards maintainers are more then welcome to reject the changes and give feedback as to what changes need to be made in order for the change to be acceptable. In openSUSE creating a submit request is a perfectly valid form of "talking to us"
As this discussion includes a number of SUSE employees on both sides of the debate, I feel it appropriate to remind all involved that they are expected to follow _SUSEs_ Open Source Policy, which clearly lays out the companies expectations for it's employees on the topics of Open Source contributions, Upstream First, Factory First, openSUSE, etc. https://opensource.suse.com/suse-open-source-policy I'd recommend all read it and ensure that they are acting consistently with that policy. Regards, Richard -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 3/22/19 12:05 PM, Richard Brown wrote:
As this discussion includes a number of SUSE employees on both sides of the debate, I feel it appropriate to remind all involved that they are expected to follow _SUSEs_ Open Source Policy, which clearly lays out the companies expectations for it's employees on the topics of Open Source contributions, Upstream First, Factory First, openSUSE, etc.
I'm always following the open source policy and I always upstream everything which means that almost all the bugs I have fixed in Debian packages are also now fixed in openSUSE. In fact, the reason why the Azure SDK updates were delayed is because I found issues with the SDK and got in touch with upstream to resolve them upstream. This is why I am particularly annoyed about this whole story. I'm trying to make sure that changes are properly tested, necessary bugs reported upstream or patches sent upstream and then someone else disturbs my maintenance work by updating random, individual packages of the Azure stack. Adrian
On 23/03/2019 18:36, John Paul Adrian Glaubitz wrote:
On 3/22/19 12:05 PM, Richard Brown wrote:
As this discussion includes a number of SUSE employees on both sides of the debate, I feel it appropriate to remind all involved that they are expected to follow _SUSEs_ Open Source Policy, which clearly lays out the companies expectations for it's employees on the topics of Open Source contributions, Upstream First, Factory First, openSUSE, etc.
I'm always following the open source policy and I always upstream everything which means that almost all the bugs I have fixed in Debian packages are also now fixed in openSUSE.
In fact, the reason why the Azure SDK updates were delayed is because I found issues with the SDK and got in touch with upstream to resolve them upstream.
This is why I am particularly annoyed about this whole story. I'm trying to make sure that changes are properly tested, necessary bugs reported upstream or patches sent upstream and then someone else disturbs my maintenance work by updating random, individual packages of the Azure stack.
But part of the open source policy also means working productively with other people in the community especially those who may also want to contribute to the packages you are working on. I guess in this case whoever sent the update for 2 packages is mostly only interested in those two packages for whatever reason. So working productively with the open source community is far more then just "upstreaming everything" its explaining to people why you can't accept there requests right now, and working with the d:l:p maintainers to make sure you have fair time to explain that before they accept / reject requests. But certainly blocking all incoming SR's (or ignoring them or suggesting that people shouldn't make them) is not working as a cooperative member of an open source project. -- 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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 3/22/19 11:20 AM, Simon Lees wrote:
Unfortunately that's not how the openSUSE project works, we welcome contributions from anyone who feels interested enough in creating them, if the contributions break something or don't meet standards maintainers are more then welcome to reject the changes and give feedback as to what changes need to be made in order for the change to be acceptable. In openSUSE creating a submit request is a perfectly valid form of "talking to us"
And you think that the default answer should be "If no one is saying something, I just accept it and don't care if things break"? I disagree with this stance. Blindly following policies is always stupid. It is stupid in Debian and it is stupid in openSUSE.
Yep and in this case the d:l:p maintainers should have given you reasonable time to add a comment in the SR explaining why you couldn't accept those changes at the moment.
I am the project maintainer. It's just the other guy that accepted the changes without talking back to me.
Please don't automatically assume incompetence. And I'm certainly not overwhelmed by the load, I am doing way more than just maintaining these packages.
I'm not assuming incompetence, but you were complaining about the amount of emails and not being able to respond to them which tends to suggest a problem with workload.But I kinda understand this, I feel like I have a billion mail filters so that I only read the obs emails I care about and not the 10,000 a month that I don't.
The amount of mails is also pouring in because of tons of micro changes, each of them generating a mail. And I was in an exceptional situation with moving apartments and being on vacation and then also SUSE switching my email server to a new infrastructure cutting me off from any communication. Again, what is the point of updating just two out of 112 packages of an SDK where the packages need to be in sync for the SDK to work? This is just a means of annoying people. Adrian
On 22/03/2019 22:22, John Paul Adrian Glaubitz wrote:
On 3/22/19 11:20 AM, Simon Lees wrote:
Unfortunately that's not how the openSUSE project works, we welcome contributions from anyone who feels interested enough in creating them, if the contributions break something or don't meet standards maintainers are more then welcome to reject the changes and give feedback as to what changes need to be made in order for the change to be acceptable. In openSUSE creating a submit request is a perfectly valid form of "talking to us"
And you think that the default answer should be "If no one is saying something, I just accept it and don't care if things break"?
Well generally I trust that people will submit things that as far as they are aware won't break, and personally I only accept requests into packages that I have some idea about and am reasonably sure that the change being made are sane. But yes in general if someone goes to the effort of making changes to a package that they believe will make the project better i'll accept it. I am even lucky enough to maintain some packages where generally someone in the community will get to updating them before I do this makes my life easier and gives me more time to work on other things, if i'm working on something urgent and won't have time to do a version update for a few days its always awesome to get a SR with the update from someone in the community within 24hrs, when this happens I always take the time to stop what i'm doing and review the request as quick as possible, generally I can approve it straight away although sometimes I need to leave feedback like you accidentally lost some changes made the other day and occasionally i'll leave a message saying I can't accept it at this time because of reason X. But generally the more time the community puts into doing things that i'm ultimately responsible for the more time I have to work on other things to help the community.
Yep and in this case the d:l:p maintainers should have given you reasonable time to add a comment in the SR explaining why you couldn't accept those changes at the moment.
I am the project maintainer. It's just the other guy that accepted the changes without talking back to me.
Your not the project maintainer, your one of the maintainers, and maybe raising it with them is a better starting point. We expect project maintainers to work together as a team to decide how things like this are handled in individual devel repo's
Please don't automatically assume incompetence. And I'm certainly not overwhelmed by the load, I am doing way more than just maintaining these packages.
I'm not assuming incompetence, but you were complaining about the amount of emails and not being able to respond to them which tends to suggest a problem with workload.But I kinda understand this, I feel like I have a billion mail filters so that I only read the obs emails I care about and not the 10,000 a month that I don't.
The amount of mails is also pouring in because of tons of micro changes, each of them generating a mail. And I was in an exceptional situation with moving apartments and being on vacation and then also SUSE switching my email server to a new infrastructure cutting me off from any communication.
Again, what is the point of updating just two out of 112 packages of an SDK where the packages need to be in sync for the SDK to work? This is just a means of annoying people.
That I do not know, but then again I neither wrote or accepted the changes. -- 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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Friday 2019-03-22 13:43, Simon Lees wrote:
Again, what is the point of updating just two out of 112 packages of an SDK where the packages need to be in sync for the SDK to work? This is just a means of annoying people.
That I do not know, but then again I neither wrote or accepted the changes.
It can be a sign of "here are two requests to showcase how $idea could look like, please consider if the approach makes sense, and I may send more as I go through more". -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 3/22/19 8:38 AM, Simon Lees wrote:
If you are struggling to manage to maintain all these packages then you likely should be talking to your Manager / Team Lead to look at getting extra resources.
I'm not struggling, I'm just asking people not to touch these packages.
At the same time the project maintainers of d:l:p should probably be giving atleast 2-3 days for actual maintainers to accept requests before they do, there are plenty of other devel repo's where the maintainers do a much better job of this.
That's not reasonable, no. People can go on vacation, be sick or busy with other stuff. Don't assume that just because someone isn't responding on the spot they are missing in action. Again, no other FOSS project that I have worked with handles it like this and that number is very high. There is no need to be chasing upstream 24/7. Adrian
On 22/03/2019 20:13, John Paul Adrian Glaubitz wrote:
On 3/22/19 8:38 AM, Simon Lees wrote:
If you are struggling to manage to maintain all these packages then you likely should be talking to your Manager / Team Lead to look at getting extra resources.
I'm not struggling, I'm just asking people not to touch these packages.
At the same time the project maintainers of d:l:p should probably be giving atleast 2-3 days for actual maintainers to accept requests before they do, there are plenty of other devel repo's where the maintainers do a much better job of this.
That's not reasonable, no. People can go on vacation, be sick or busy with other stuff. Don't assume that just because someone isn't responding on the spot they are missing in action.
Again, no other FOSS project that I have worked with handles it like this and that number is very high. There is no need to be chasing upstream 24/7.
In the past the openSUSE project has generally considered a few days to a week to be reasonable, if you are going to be away for longer then that its probably worth letting the project maintainers know your going to be away. This policy has come from complaints from contributors that they submitted a request a month ago and no one has done anything with it. So in the past the decision has been made to try and find a happy medium between the two sides. -- 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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 3/22/19 11:04 AM, Simon Lees wrote:
In the past the openSUSE project has generally considered a few days to a week to be reasonable, if you are going to be away for longer then that its probably worth letting the project maintainers know your going to be away. This policy has come from complaints from contributors that they submitted a request a month ago and no one has done anything with it. So in the past the decision has been made to try and find a happy medium between the two sides.
I am project maintainer of devel:languages:python:azure and of devel:languages:python:azure, so I'm not sure what you mean. My team and supervisors knew about my absence. Adrian N�����r��y隊Z)z{.��ZrF��x>�{.n�+������Ǩ��r��i�m��0��ޙ������� ��$j���0�����Ǩ�
On 22/03/2019 22:14, John Paul Adrian Glaubitz wrote:
On 3/22/19 11:04 AM, Simon Lees wrote:
In the past the openSUSE project has generally considered a few days to a week to be reasonable, if you are going to be away for longer then that its probably worth letting the project maintainers know your going to be away. This policy has come from complaints from contributors that they submitted a request a month ago and no one has done anything with it. So in the past the decision has been made to try and find a happy medium between the two sides.
I am project maintainer of devel:languages:python:azure and of devel:languages:python:azure, so I'm not sure what you mean. My team and supervisors knew about my absence.
I'm not talking about any specific devel repo's but rather how it works in general across all devel repo's. -- 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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 3/22/19 10:43 AM, John Paul Adrian Glaubitz wrote:
I'm not struggling, I'm just asking people not to touch these packages.
I wouldn't go that far. My understanding is that: * anyone - can branch a package to home:*, - make some changes there, - and create a request back to the main project. * any of the package maintainers - checks the change, and - accepts/declines the request. Am I right? In one of the packages I'm maintaining, I've even agreed with the other maintainer on a 4-eyes principle, i.e., even if I'm a maintainer, I will do the change in my home project, and the other maintainer will check and accept the change. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 22/03/2019 21:41, Bernhard Voelker wrote:
On 3/22/19 10:43 AM, John Paul Adrian Glaubitz wrote:
I'm not struggling, I'm just asking people not to touch these packages.
I wouldn't go that far.
My understanding is that:
* anyone - can branch a package to home:*, - make some changes there, - and create a request back to the main project.
* any of the package maintainers - checks the change, and - accepts/declines the request.
Am I right?
Yep
In one of the packages I'm maintaining, I've even agreed with the other maintainer on a 4-eyes principle, i.e., even if I'm a maintainer, I will do the change in my home project, and the other maintainer will check and accept the change.
I don't always go that far but for most packages I maintain that have 1 or more other maintainers i'll always wait a day or 2 to let the others read over before self accepting. -- 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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 3/22/19 12:11 PM, Bernhard Voelker wrote:
In one of the packages I'm maintaining, I've even agreed with the other maintainer on a 4-eyes principle, i.e., even if I'm a maintainer, I will do the change in my home project, and the other maintainer will check and accept the change.
That's generally a good practice I also follow. We're all humans after all. Sometimes I accept an own submission myself, e.g. in case of urgent security fixes and after testing the branched update locally. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 2019-03-22 09:43:49 +0000, John Paul Adrian Glaubitz wrote:
On 3/22/19 8:38 AM, Simon Lees wrote:
If you are struggling to manage to maintain all these packages then you likely should be talking to your Manager / Team Lead to look at getting extra resources.
I'm not struggling, I'm just asking people not to touch these packages.
You could also enforce this technically via the OBS:RejectRequests attribute (on a per project or per package basis). If this attribute is set, it is not possible anymore to submit a SR to the project/package. Marcus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 3/22/19 3:18 PM, Marcus Hüwe wrote:
You could also enforce this technically via the OBS:RejectRequests attribute (on a per project or per package basis). If this attribute is set, it is not possible anymore to submit a SR to the project/package.
Thanks. This is what I was looking for. I will use that flag to avoid these issues in the future. Adrian
On 23/03/2019 18:25, John Paul Adrian Glaubitz wrote:
On 3/22/19 3:18 PM, Marcus Hüwe wrote:
You could also enforce this technically via the OBS:RejectRequests attribute (on a per project or per package basis). If this attribute is set, it is not possible anymore to submit a SR to the project/package.
Thanks. This is what I was looking for. I will use that flag to avoid these issues in the future.
This is not acceptable for openSUSE devel projects. -- 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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On samedi, 23 mars 2019 08.55:52 h CET John Paul Adrian Glaubitz wrote:
On 3/22/19 3:18 PM, Marcus Hüwe wrote:
You could also enforce this technically via the OBS:RejectRequests attribute (on a per project or per package basis). If this attribute is set, it is not possible anymore to submit a SR to the project/package.
Thanks. This is what I was looking for. I will use that flag to avoid these issues in the future.
Adrian
Hello, I've now finished to read the thread, and without having the precise detail I'm asking myself, why they don't use comment ? Perhaps specifing the needs in the project description and one line in all package that explain the problem of whole stack update and not one package can wake (shake) up the attention of future participant. If comment are good for code, I don't see any good reason to not be good for spec. btw using the bco -> ci -> sr circle is on my opinion the best, it allow every maintainer to see changes and so, if in your devel prj, you can work like peer review it minimize risk of errors. And could be a way to gain contributors. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe supporter GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 22/03/2019 05:57, John Paul Adrian Glaubitz wrote:
On 3/21/19 8:01 PM, Stefan Seyfried wrote:
Why, there not "your" packages once they leave your home repo, if someone feels like going to the effort of making the distro better
...then he can, in the future, do all the work on these packages.
I have to admit that this is an issue that is annoying me in openSUSE as well.
In any other open source project I have worked so far, it's common that you wait for feedback from the actual maintainer of a package or a piece of code before moving forward with changes. Not in openSUSE as there are multiple project maintainers which can accept submit requests and if you're lucky, the original maintainer is currently unreachable (vacation etc) and you can sneak in some changes without approval from the maintainer.
The problem here is that it's not always obvious at first glance which things need to be taken into consideration when making changes to a package.
For example, I am maintaining the Python Azure SDK for the Public Cloud Team at SUSE. For the second time now, someone has sent in requests to update just two out of over 100 packages that make up the Python Azure SDK. This broke the installation of the Azure SDK in Factory as the update of all these 100+ needs to be coordinated and there was also recently a disruptive upstream change to the namespace packages which needed some additional work which delayed my update. Since the Public Cloud Team is using packages from Factory for certain tasks, the broken Azure SDK is now causing headache for us.
I missed the two submit request mails as there are currently dozens of these mails per day for the devel:languages:python project. I was also quite busy moving apartments during that week so I could not read mail all the time, I would have rejected those requests. Now they were accepted by another d:l:p maintainer and eventually successfully accepted into Factory despite making the Python Azure SDK uninstallable. I'm also surprised that these changes were not blocked by the Factory maintainers despite the fact they introduced breakage.
I don't know what I can do to prevent this in the future, but I really wish the communication would work better and people wouldn't just randomly push submit requests to packages without having at least talked to the maintainer of the packages in question first. Good communication is a key point when collaborating in open source projects.
I understand and know that no one contributing changes wants to do any harm, but if you are updating random packages that aren't yours without understanding the peculiarities concerning certain packages, you are making the lives of maintainers harder, not easier.
This is probably something that can be improved but would be better discussed on the opensuse-factory mailing list, given that a large percentage of the community isn't here. -- 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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
John Paul Adrian Glaubitz schrieb:
On 3/21/19 8:01 PM, Stefan Seyfried wrote:
Why, there not "your" packages once they leave your home repo, if someone feels like going to the effort of making the distro better
...then he can, in the future, do all the work on these packages.
I have to admit that this is an issue that is annoying me in openSUSE as well.
In any other open source project I have worked so far, it's common that you wait for feedback from the actual maintainer of a package or a piece of code before moving forward with changes. Not in openSUSE as there are multiple project maintainers which can accept submit requests and if you're lucky, the original maintainer is currently unreachable (vacation etc) and you can sneak in some changes without approval from the maintainer.
If you are set as maintainer in the package, project maintainers are expected to only step in if really needed. That's not something new but sometimes reminding every once in a while helps: https://en.opensuse.org/openSUSE:Package_maintainership_guide#Devel_project_...
For example, I am maintaining the Python Azure SDK for the Public Cloud Team at SUSE. For the second time now, someone has sent in requests to update just two out of over 100 packages that make up the Python Azure
IIUC the two packages in question were in devel:languages:python wheras all the rest has a devel project of it's own? If those two packages are mostly only relevant to your other packages then maybe it would make sense to move them over to the other devel project? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 3/25/19 1:39 PM, Ludwig Nussel wrote:
If you are set as maintainer in the package, project maintainers are expected to only step in if really needed. That's not something new but sometimes reminding every once in a while helps: https://en.opensuse.org/openSUSE:Package_maintainership_guide#Devel_project_...
Thanks. I'll take a note.
For example, I am maintaining the Python Azure SDK for the Public Cloud Team at SUSE. For the second time now, someone has sent in requests to update just two out of over 100 packages that make up the Python Azure
IIUC the two packages in question were in devel:languages:python wheras all the rest has a devel project of it's own? If those two packages are mostly only relevant to your other packages then maybe it would make sense to move them over to the other devel project?
No, both packages are part of the d:l:p:azure project:
https://build.opensuse.org/package/show/devel:languages:python:azure/python-... https://build.opensuse.org/package/show/devel:languages:python:azure/python-...
So this point doesn't hold. I also haven't heard back from John why he updated those packages after sending him two mails regarding the question. I don't find this situation optimal. Communication is a key point of any open source project and is exactly what helps avoiding mishaps. Adrian
On Monday 2019-03-25 14:45, John Paul Adrian Glaubitz wrote:
IIUC the two packages in question were in devel:languages:python wheras all the rest has a devel project of it's own? If those two packages are mostly only relevant to your other packages then maybe it would make sense to move them over to the other devel project?
No, both packages are part of the d:l:p:azure project:
https://build.opensuse.org/package/show/devel:languages:python:azure/python-... https://build.opensuse.org/package/show/devel:languages:python:azure/python-...
So this point doesn't hold. I also haven't heard back from John why he updated those packages after sending him two mails regarding the question.
If it's still timely relevant, maybe ask again (- and again). The user seems active in that there is a steady influx of new Python packages bearing his mark showing up in the Factory review queue. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 3/25/19 3:27 PM, Jan Engelhardt wrote:
So this point doesn't hold. I also haven't heard back from John why he updated those packages after sending him two mails regarding the question.
If it's still timely relevant, maybe ask again (- and again). The user seems active in that there is a steady influx of new Python packages bearing his mark showing up in the Factory review queue.
Yes, I'm seeing his requests. But if someone doesn't reply even after two mails, I guess they're not really interested in a dialogue. I have locked the project for the time being now and I'm working on updating all packages and finally submit the whole SDK as a whole. Thanks, Adrian
Am 15.03.19 um 23:20 schrieb Brüns, Stefan:
Hi fellow packagers,
as part of a broader https support, many projects have changed there homepages from plain http to https.
Some notable mentions:
- github.com/* - sourceforge.net/projects/* - *.kde.org - *.gnome.org
So the next time you do some package work, check if your Url: tag is now a redirect:
$> curl -I http://amarok.kde.org HTTP/1.1 301 Moved Permanently Location: https://amarok.kde.org/
What's the problem? The link still works. -- 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-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (16)
-
Alberto Planas Dominguez -
Alberto Planas Dominguez -
Bernhard Voelker -
Bruno Friedmann -
Brüns, Stefan -
Jan Engelhardt -
Johannes Meixner -
John Paul Adrian Glaubitz -
Ludwig Nussel -
Marcus Hüwe -
Michael Ströder -
Richard Brown -
Simon Lees -
Stasiek Michalski -
Stefan Seyfried -
Stephan Kulow