[opensuse-factory] About Leap maintenance : bsc not authorized
![](https://seccdn.libravatar.org/avatar/482b6c0369f4709de8faa6843cd6b347.jpg?s=120&d=mm&r=g)
There's an increase in the number of bsc bnc boo related to Maintenance import from SLE on Leap. Most of the ticket, which would be the source of informations are hidden (even after a login as normal openSUSE user). So we forbid users to have a look at the changes, which is not in favor of chain of trust and openess attitude. So would it be possible to have a damn bot, with simple rights which should reject any submission to Leap if issues are not opened ? Back in time, there was discussion, that lead to if a bsc is closed for good reason (customer data in), a new duplicate issue has to be opened and all anonymous should goes there. See last squid maintenance for example https://lists.opensuse.org/opensuse-updates/2017-09/msg00064.html -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/3e71adf7cf8e5a57599ba54f5ef98c7d.jpg?s=120&d=mm&r=g)
Hello Bruno, On 09/15/2017 12:38 PM, Bruno Friedmann wrote:
There's an increase in the number of bsc bnc boo related to Maintenance import from SLE on Leap.
Most of the ticket, which would be the source of informations are hidden (even after a login as normal openSUSE user).
That'll be items in SLE development, support/L3 and partner reported bugs.
So we forbid users to have a look at the changes, which is not in favor of chain of trust and openess attitude.
You make it sound more closed than it really is. The source changes are public in the build service: https://build.opensuse.org/project/show/openSUSE:Maintenance:7263 osc rdiff openSUSE:Leap:42.3/squid openSUSE:Leap:42.3:Update/squid.7263 https://build.opensuse.org/package/rdiff/openSUSE:Maintenance:7263/squid.ope... All running incidents: https://build.opensuse.org/project/maintenance_incidents/openSUSE:Maintenanc... All binaries and sources: http://download.opensuse.org/update/leap/42.3-test/
So would it be possible to have a damn bot, with simple rights which should reject any submission to Leap if issues are not opened ?
Solution before problem? You seem to drastically underestimate the level of automation involved when importing updated sources from SUSE:SLE-12*:Update into openSUSE:Maintenance incidents. That was a major point of Leap, by the way. Re-arranging the references in the spec files, patch comments, changelogs and update descriptions to refer to a cloned bug is unfeasible. The import is source diff based, so is the harmonization effort between SLE and openSUSE. The alternative, opening all bugs by default, including pre-release and enterprise product areas, would be a massive change to processes. I am not sure that this will be answered in favor. Having meaningful package changelog entries and maintenance update descriptions is a good compromise, beyond the available sources and review team inclusion. Andreas -- Andreas Stieger <astieger@suse.de> Project Manager Security SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/482b6c0369f4709de8faa6843cd6b347.jpg?s=120&d=mm&r=g)
On vendredi, 15 septembre 2017 13.20:52 h CEST Andreas Stieger wrote:
Hello Bruno,
Hi Andreas, thanks for your awnsers.
On 09/15/2017 12:38 PM, Bruno Friedmann wrote:
There's an increase in the number of bsc bnc boo related to Maintenance import from SLE on Leap.
Most of the ticket, which would be the source of informations are hidden (even after a login as normal openSUSE user).
That'll be items in SLE development, support/L3 and partner reported bugs.
So we forbid users to have a look at the changes, which is not in favor of chain of trust and openess attitude.
You make it sound more closed than it really is. The source changes are public in the build service: https://build.opensuse.org/project/show/openSUSE:Maintenance:7263 osc rdiff openSUSE:Leap:42.3/squid openSUSE:Leap:42.3:Update/squid.7263 https://build.opensuse.org/package/rdiff/openSUSE:Maintenance:7263/squid.ope nSUSE_Leap_42.3_Update?linkrev=base&rev=2
Yes I made it, on a non offensive way, the information and links you give can really make a difference between damn I can't know state to ok I can preview (means before installing patch or update) and know what it will imply. Let keep osc rdiff as a more hackish tool or advanced admin, I would like to have anwser to legitimate end-users, who ask why they can't know before installing. So we're not so far to have a working solution. If you pick any security,maintenance email, beside the link to bsc,bnc,boo, WE should find a way to give this maintenance link back to the mail. For example I do the dumb test of picking with the iproute2 announcement Announcement ID: openSUSE-RU-2017:2492-1 Rating: low References: #1034855 #1045399 #1056261 #990635 Affected Products: openSUSE Leap 42.3 openSUSE Leap 42.2 zypper in -t patch openSUSE-2017-1052=1 There's no direct link between the maintenance incidents and number present here, that I was able to find. So to make happy everybody, and keep the process as it is, will we able to create (automagically in some sort of) this back link in the annonce email ? Afterward, the information is here, not hidden ;-)
All running incidents: https://build.opensuse.org/project/maintenance_incidents/openSUSE:Maintenanc e
Yeha another link that merit more advertisement.
All binaries and sources: http://download.opensuse.org/update/leap/42.3-test/
So would it be possible to have a damn bot, with simple rights which should reject any submission to Leap if issues are not opened ?
Solution before problem? You seem to drastically underestimate the level of automation involved when importing updated sources from SUSE:SLE-12*:Update into openSUSE:Maintenance incidents. That was a major point of Leap, by the way.
Re-arranging the references in the spec files, patch comments, changelogs and update descriptions to refer to a cloned bug is unfeasible. The import is source diff based, so is the harmonization effort between SLE and openSUSE. The alternative, opening all bugs by default, including pre-release and enterprise product areas, would be a massive change to processes. I am not sure that this will be answered in favor.
Having meaningful package changelog entries and maintenance update descriptions is a good compromise, beyond the available sources and review team inclusion.
Andreas I would like again to thank you about bringing this part from the inside. All your arguments make sense, and are good to keep Leap shaped as it is. So I killed a second time my stupid idea of bots. I would also like to shutdown my frustration when people ask me why, and have a nice way to answer them. Because we're the best distribution, project around ;-)
-- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (2)
-
Andreas Stieger
-
Bruno Friedmann