Hello guys,
Just informational mail that we plan to enable bnc# checking in the changelogs to ensure that Factory submissions are in fact only listing visible bugs. [1] [2]
The code is set-up the way it checks the changelog and reports back with all occurances of bugs that were not visible (it ignores the bnc if bugzilla does not respond, so no worries if it is down, everything is approved :P).
Your actions if cases like this happen are quite simple: 1) make the initial bug visible and mark the internal comments as internal. 2) if not sure ask somebody who knows more to do it for you.
As I wrote there in the code [2] it checks the full new changelog in case some bnc should not be there we don't get conflicts when comparing just diff. So you might get request to make really old bugs visible. It is a tiny annoyance but then we ensure that all informations about our fixes can be really read by anybody.
Cheers
Tom
PS: feel free to improv perl in [2] as I am not exactly mage there :)
[1] https://progress.opensuse.org/issues/571 [2] https://github.com/coolo/factory-auto/pull/46
Quoting Tomáš Chvátal tchvatal@suse.cz:
Hello guys,
Just informational mail that we plan to enable bnc# checking in the changelogs to ensure that Factory submissions are in fact only listing visible bugs. [1] [2]
The code is set-up the way it checks the changelog and reports back with all occurances of bugs that were not visible (it ignores the bnc if bugzilla does not respond, so no worries if it is down, everything is approved :P).
Your actions if cases like this happen are quite simple:
- make the initial bug visible and mark the internal comments as internal.
- if not sure ask somebody who knows more to do it for you.
As I wrote there in the code [2] it checks the full new changelog in case some bnc should not be there we don't get conflicts when comparing just diff. So you might get request to make really old bugs visible. It is a tiny annoyance but then we ensure that all informations about our fixes can be really read by anybody.
So as a consequence I can no longer submit a security fix to address a 'non-public vulnurability' before opening the bug and making it public? :)
This is probably about the only case where this makes sense anyway..
and the 'checking full logs' might hit a lot of people... especially 'us' community members.. we are very well capable to forwarding an SR, maintaining a full package, but we are typically also the ones blocked out from the non-visible bugs...
I hope this won't result in a big chain where community packagers have a hard time getting old packages forwarded.
Dominique
Dnia czwartek, 21 listopada 2013 16:12:35 Dominique Leuenberger a.k.a. Dimstar pisze:
So as a consequence I can no longer submit a security fix to address a 'non-public vulnurability' before opening the bug and making it public? :)
Submitting a security fix makes the bug public anyway because the fix tells you where the bug is. This is even true for closed-source binaries.
Chris
On Wed, Nov 27, 2013 at 09:32:20PM +0100, Křištof Želechovski wrote:
Dnia czwartek, 21 listopada 2013 16:12:35 Dominique Leuenberger a.k.a. Dimstar pisze:
So as a consequence I can no longer submit a security fix to address a 'non-public vulnurability' before opening the bug and making it public? :)
Submitting a security fix makes the bug public anyway because the fix tells you where the bug is. This is even true for closed-source binaries.
FWIW, we do not assign embargoed security bugs to non-SUSE packagers, as reporters usually implicitely assume it won't leave SUSE.
After the embargo ends the bugs are opened and community packagers assigned or cced.
Also submitting embargoed fixes is not done on OBS before end of embargo currently.
Ciao, Marcus
On 11/21/2013 03:59 PM, Tomáš Chvátal wrote:
Hello guys,
Just informational mail that we plan to enable bnc# checking in the changelogs to ensure that Factory submissions are in fact only listing visible bugs. [1] [2]
The code is set-up the way it checks the changelog and reports back with all occurances of bugs that were not visible (it ignores the bnc if bugzilla does not respond, so no worries if it is down, everything is approved :P).
Your actions if cases like this happen are quite simple:
- make the initial bug visible and mark the internal comments as internal.
- if not sure ask somebody who knows more to do it for you.
As I wrote there in the code [2] it checks the full new changelog in case some bnc should not be there we don't get conflicts when comparing just diff. So you might get request to make really old bugs visible. It is a tiny annoyance but then we ensure that all informations about our fixes can be really read by anybody.
Tomas, I'm not sure this is the best way forward. There are bugs that contain confidential information and the SUSE developers are not allowed to open them.
What do you propose to do in such situations?
Andreas
On Thu, Nov 21, Tomáš Chvátal wrote:
Hello guys,
Just informational mail that we plan to enable bnc# checking in the changelogs to ensure that Factory submissions are in fact only listing visible bugs. [1] [2]
Ok, and since we are not allowed to make nearly all of this bugs public, it will end in either removing the bnc numbers (not good) or not submitting this fixes to openSUSE at all (very bad for openSUSE).
Please think first about the consequences of such changes, and if this is really what you want to archive. Not everything which sounds good will have a positive effect in the end.
Thorsten
On Thu, Nov 21, 2013 at 12:23 PM, Thorsten Kukuk kukuk@suse.de wrote:
On Thu, Nov 21, Tomáš Chvátal wrote:
Hello guys,
Just informational mail that we plan to enable bnc# checking in the changelogs to ensure that Factory submissions are in fact only listing visible bugs. [1] [2]
Ok, and since we are not allowed to make nearly all of this bugs public, it will end in either removing the bnc numbers (not good) or not submitting this fixes to openSUSE at all (very bad for openSUSE).
No, only sensitive private information should be marked private, and the bug report itself, or at least the non-sensitive bits, should be left open for all to see.
Or... just file a new bnc with the non-sensitive description, a link to the private bnc, and add that to the changelog.
On Thu, Nov 21, Claudio Freire wrote:
On Thu, Nov 21, 2013 at 12:23 PM, Thorsten Kukuk kukuk@suse.de wrote:
On Thu, Nov 21, Tomáš Chvátal wrote:
Hello guys,
Just informational mail that we plan to enable bnc# checking in the changelogs to ensure that Factory submissions are in fact only listing visible bugs. [1] [2]
Ok, and since we are not allowed to make nearly all of this bugs public, it will end in either removing the bnc numbers (not good) or not submitting this fixes to openSUSE at all (very bad for openSUSE).
No, only sensitive private information should be marked private, and the bug report itself, or at least the non-sensitive bits, should be left open for all to see.
Or... just file a new bnc with the non-sensitive description, a link to the private bnc, and add that to the changelog.
I wrote "we are not allowed" and I mean it that way. Even for the openSUSE community we cannot break laws and contracts. Creating dummy bugs without any information doesn't help, this is the same information as without bnc or with one not everybody can read.
Thorsten
Am Donnerstag, 21. November 2013, 13:53:40 schrieb Claudio Freire:
On Thu, Nov 21, 2013 at 12:23 PM, Thorsten Kukuk kukuk@suse.de wrote:
On Thu, Nov 21, Tomáš Chvátal wrote:
Hello guys,
Just informational mail that we plan to enable bnc# checking in the changelogs to ensure that Factory submissions are in fact only listing visible bugs. [1] [2]
Ok, and since we are not allowed to make nearly all of this bugs public, it will end in either removing the bnc numbers (not good) or not submitting this fixes to openSUSE at all (very bad for openSUSE).
No, only sensitive private information should be marked private, and the bug report itself, or at least the non-sensitive bits, should be left open for all to see.
Or... just file a new bnc with the non-sensitive description, a link to the private bnc, and add that to the changelog.
That would still mean that there must be two version of the package source, because in one we need the (at least temporarly) bug entry.
So, it is more likely that there will be no openSUSE version of that package then, because the problem and solution is on the other side.
Hi Claudio,
On Nov 21, 13 13:53:40 -0200, Claudio Freire wrote:
On Thu, Nov 21, 2013 at 12:23 PM, Thorsten Kukuk kukuk@suse.de wrote:
On Thu, Nov 21, Tomáš Chvátal wrote:
Hello guys,
Just informational mail that we plan to enable bnc# checking in the changelogs to ensure that Factory submissions are in fact only listing visible bugs. [1] [2]
Ok, and since we are not allowed to make nearly all of this bugs public, it will end in either removing the bnc numbers (not good) or not submitting this fixes to openSUSE at all (very bad for openSUSE).
No, only sensitive private information should be marked private, and the bug report itself, or at least the non-sensitive bits, should be left open for all to see.
This is not only about private comments. It's about a complete bug that may not be visible as a whole - because they contain sensitive information, NDAed information or are for a product where the bugs are not publicly available by default.
Or... just file a new bnc with the non-sensitive description, a link to the private bnc, and add that to the changelog.
You are aware that we are talking about thousands of bugreports in the worst case?
This would mena that someone has to do this e.g. for all referenced security bugs, all SLES/SLED bugs and much more.
Just to make this clear: Yes, we try to file as many bugs against openSUSE as possible, but there are still a lot left.
I wonder what is planned to achieve with that checking? You are not gaining any more information, as I doubt that a lot of people would really duplicate a (closed) security bug and strip of all related information (which btw makes the duplication worthless).
You are just taking information for some people away.
Stefan
On Thu, Nov 21, 2013 at 1:04 PM, Stefan Behlert behlert@suse.de wrote:
Or... just file a new bnc with the non-sensitive description, a link to the private bnc, and add that to the changelog.
You are aware that we are talking about thousands of bugreports in the worst case?
No, I do not have SUSE stats.
This would mena that someone has to do this e.g. for all referenced security bugs, all SLES/SLED bugs and much more.
Supposedly, the work for extracting a minimal description of the bug into a public source would be small compared to actually fixing the bug.
Just to make this clear: Yes, we try to file as many bugs against openSUSE as possible, but there are still a lot left.
I wonder what is planned to achieve with that checking? You are not gaining any more information, as I doubt that a lot of people would really duplicate a (closed) security bug and strip of all related information (which btw makes the duplication worthless).
You are just taking information for some people away.
It is really really wrong to reference a bnc by number on a changelog when that bnc is private. It adds obscurity into the community and that's bad.
I agree that automatically checking and giving no exception mechanism puts SUSE employees in a position where they will probably choose to not a) push the change into openSuse, or b) reference the bug at all, and that's also bad.
But lets not forget that adding obscure changelogs *is* *quite* *bad* in open source.
So, what do you propose? What *can* SUSE employees do to improve that situation?
Am Donnerstag, 21. November 2013, 14:16:48 schrieb Claudio Freire:
On Thu, Nov 21, 2013 at 1:04 PM, Stefan Behlert behlert@suse.de wrote:
..
This would mena that someone has to do this e.g. for all referenced security bugs, all SLES/SLED bugs and much more.
Supposedly, the work for extracting a minimal description of the bug into a public source would be small compared to actually fixing the bug.
True, but this can be done directly in the .changes file. Some description about the change had to be written there anyway.
If that description is not good enough openSUSE-Factory maintainers can of course reject the package.
But please keep in mind that openSUSE is currently using SUSE bugzilla. I do not think want to double the effort to maintain an own bug system and to sync the data always. So we need some compromise here.
Of course we could also build in some OBS feature to track some data elsewhere and jsut generate it inside when it got built within a different context. But I think it will create too much confusion for most people.
On Thursday 21 November 2013, Adrian Schröter wrote:
Am Donnerstag, 21. November 2013, 14:16:48 schrieb Claudio Freire:
On Thu, Nov 21, 2013 at 1:04 PM, Stefan Behlert behlert@suse.de wrote:
..
This would mena that someone has to do this e.g. for all referenced security bugs, all SLES/SLED bugs and much more.
Supposedly, the work for extracting a minimal description of the bug into a public source would be small compared to actually fixing the bug.
True, but this can be done directly in the .changes file. Some description about the change had to be written there anyway.
If that description is not good enough openSUSE-Factory maintainers can of course reject the package.
Well, IMO the maintainer can only objectively rate the description if he also can't access the bnc.
But please keep in mind that openSUSE is currently using SUSE bugzilla. I do not think want to double the effort to maintain an own bug system and to sync the data always. So we need some compromise here.
Of course we could also build in some OBS feature to track some data elsewhere and jsut generate it inside when it got built within a different context. But I think it will create too much confusion for most people.
Actually I don't understand the problem completely. Are SLES customers able to access all the bugs?
cu, Rudi
On 11/22/2013 03:00 PM, Ruediger Meier wrote:
On Thursday 21 November 2013, Adrian Schröter wrote:
Am Donnerstag, 21. November 2013, 14:16:48 schrieb Claudio Freire:
On Thu, Nov 21, 2013 at 1:04 PM, Stefan Behlert behlert@suse.de wrote:
..
This would mena that someone has to do this e.g. for all referenced security bugs, all SLES/SLED bugs and much more.
Supposedly, the work for extracting a minimal description of the bug into a public source would be small compared to actually fixing the bug.
True, but this can be done directly in the .changes file. Some description about the change had to be written there anyway.
If that description is not good enough openSUSE-Factory maintainers can of course reject the package.
Well, IMO the maintainer can only objectively rate the description if he also can't access the bnc.
But please keep in mind that openSUSE is currently using SUSE bugzilla. I do not think want to double the effort to maintain an own bug system and to sync the data always. So we need some compromise here.
Of course we could also build in some OBS feature to track some data elsewhere and jsut generate it inside when it got built within a different context. But I think it will create too much confusion for most people.
Actually I don't understand the problem completely. Are SLES customers able to access all the bugs?
SLES customers report bugs to NTS which then open bugs - and partners report directly to NTS. Both groups might include private information. Partners for example have only access to the bugs they reported,
Andreas
On Friday 22 November 2013, Andreas Jaeger wrote:
On 11/22/2013 03:00 PM, Ruediger Meier wrote:
On Thursday 21 November 2013, Adrian Schröter wrote:
Am Donnerstag, 21. November 2013, 14:16:48 schrieb Claudio Freire:
On Thu, Nov 21, 2013 at 1:04 PM, Stefan Behlert behlert@suse.de wrote:
..
This would mena that someone has to do this e.g. for all referenced security bugs, all SLES/SLED bugs and much more.
Supposedly, the work for extracting a minimal description of the bug into a public source would be small compared to actually fixing the bug.
True, but this can be done directly in the .changes file. Some description about the change had to be written there anyway.
If that description is not good enough openSUSE-Factory maintainers can of course reject the package.
Well, IMO the maintainer can only objectively rate the description if he also can't access the bnc.
But please keep in mind that openSUSE is currently using SUSE bugzilla. I do not think want to double the effort to maintain an own bug system and to sync the data always. So we need some compromise here.
Of course we could also build in some OBS feature to track some data elsewhere and jsut generate it inside when it got built within a different context. But I think it will create too much confusion for most people.
Actually I don't understand the problem completely. Are SLES customers able to access all the bugs?
SLES customers report bugs to NTS which then open bugs - and partners report directly to NTS. Both groups might include private information. Partners for example have only access to the bugs they reported,
So then it's even annoying for SLES customers to see all these private references. Suse should track their private references elsewhere as you mentioned.
cu, Rudi
Am Freitag, 22. November 2013, 15:14:50 schrieb Ruediger Meier:
On Friday 22 November 2013, Andreas Jaeger wrote:
On 11/22/2013 03:00 PM, Ruediger Meier wrote:
On Thursday 21 November 2013, Adrian Schröter wrote:
Am Donnerstag, 21. November 2013, 14:16:48 schrieb Claudio Freire:
On Thu, Nov 21, 2013 at 1:04 PM, Stefan Behlert behlert@suse.de wrote:
..
This would mena that someone has to do this e.g. for all referenced security bugs, all SLES/SLED bugs and much more.
Supposedly, the work for extracting a minimal description of the bug into a public source would be small compared to actually fixing the bug.
True, but this can be done directly in the .changes file. Some description about the change had to be written there anyway.
If that description is not good enough openSUSE-Factory maintainers can of course reject the package.
Well, IMO the maintainer can only objectively rate the description if he also can't access the bnc.
But please keep in mind that openSUSE is currently using SUSE bugzilla. I do not think want to double the effort to maintain an own bug system and to sync the data always. So we need some compromise here.
Of course we could also build in some OBS feature to track some data elsewhere and jsut generate it inside when it got built within a different context. But I think it will create too much confusion for most people.
Actually I don't understand the problem completely. Are SLES customers able to access all the bugs?
SLES customers report bugs to NTS which then open bugs - and partners report directly to NTS. Both groups might include private information. Partners for example have only access to the bugs they reported,
So then it's even annoying for SLES customers to see all these private references. Suse should track their private references elsewhere as you mentioned.
You forget that openSUSE is using SUSE bugzilla. So openSUSE would need to look for a new bug tracker ...
However, I am actually happy that we have only one. In most cases it makes the collaboration much easier.
bye adrian
On Friday 22 November 2013, Adrian Schröter wrote:
Am Freitag, 22. November 2013, 15:14:50 schrieb Ruediger Meier:
On Friday 22 November 2013, Andreas Jaeger wrote:
On 11/22/2013 03:00 PM, Ruediger Meier wrote:
On Thursday 21 November 2013, Adrian Schröter wrote:
Am Donnerstag, 21. November 2013, 14:16:48 schrieb Claudio
Freire:
On Thu, Nov 21, 2013 at 1:04 PM, Stefan Behlert behlert@suse.de wrote:
..
> This would mena that someone has to do this e.g. for all > referenced security bugs, all SLES/SLED bugs and much more.
Supposedly, the work for extracting a minimal description of the bug into a public source would be small compared to actually fixing the bug.
True, but this can be done directly in the .changes file. Some description about the change had to be written there anyway.
If that description is not good enough openSUSE-Factory maintainers can of course reject the package.
Well, IMO the maintainer can only objectively rate the description if he also can't access the bnc.
But please keep in mind that openSUSE is currently using SUSE bugzilla. I do not think want to double the effort to maintain an own bug system and to sync the data always. So we need some compromise here.
Of course we could also build in some OBS feature to track some data elsewhere and jsut generate it inside when it got built within a different context. But I think it will create too much confusion for most people.
Actually I don't understand the problem completely. Are SLES customers able to access all the bugs?
SLES customers report bugs to NTS which then open bugs - and partners report directly to NTS. Both groups might include private information. Partners for example have only access to the bugs they reported,
So then it's even annoying for SLES customers to see all these private references. Suse should track their private references elsewhere as you mentioned.
You forget that openSUSE is using SUSE bugzilla. So openSUSE would need to look for a new bug tracker ...
No, I don't care about about private bugs in bugzilla. I just don't want to have them in submit messages, changelogs and patchinfo of openSUSE packages.
However, I am actually happy that we have only one. In most cases it makes the collaboration much easier.
One thing would be nice. I'd like to have a blacklist in my bugzilla preferences for all the "uninteresing" Classification, Product, Component drop down lists. Maybe this would be a new bugzilla feature ?!
cu, Rudi
Am Freitag, 22. November 2013, 15:44:59 schrieb Ruediger Meier:
On Friday 22 November 2013, Adrian Schröter wrote:
Am Freitag, 22. November 2013, 15:14:50 schrieb Ruediger Meier:
On Friday 22 November 2013, Andreas Jaeger wrote:
On 11/22/2013 03:00 PM, Ruediger Meier wrote:
On Thursday 21 November 2013, Adrian Schröter wrote:
Am Donnerstag, 21. November 2013, 14:16:48 schrieb Claudio
Freire:
> On Thu, Nov 21, 2013 at 1:04 PM, Stefan Behlert > behlert@suse.de wrote:
..
>> This would mena that someone has to do this e.g. for all >> referenced security bugs, all SLES/SLED bugs and much more. > > Supposedly, the work for extracting a minimal description of > the bug into a public source would be small compared to > actually fixing the bug.
True, but this can be done directly in the .changes file. Some description about the change had to be written there anyway.
If that description is not good enough openSUSE-Factory maintainers can of course reject the package.
Well, IMO the maintainer can only objectively rate the description if he also can't access the bnc.
But please keep in mind that openSUSE is currently using SUSE bugzilla. I do not think want to double the effort to maintain an own bug system and to sync the data always. So we need some compromise here.
Of course we could also build in some OBS feature to track some data elsewhere and jsut generate it inside when it got built within a different context. But I think it will create too much confusion for most people.
Actually I don't understand the problem completely. Are SLES customers able to access all the bugs?
SLES customers report bugs to NTS which then open bugs - and partners report directly to NTS. Both groups might include private information. Partners for example have only access to the bugs they reported,
So then it's even annoying for SLES customers to see all these private references. Suse should track their private references elsewhere as you mentioned.
You forget that openSUSE is using SUSE bugzilla. So openSUSE would need to look for a new bug tracker ...
No, I don't care about about private bugs in bugzilla. I just don't want to have them in submit messages, changelogs and patchinfo of openSUSE packages.
Again, just removing information does not help anyone and will have bad impact on the workforce in openSUSE Factory. Could we agree that we may need to mark them differently, eg. with a different tag so no one is loosing time trying to open it?
However, I am actually happy that we have only one. In most cases it makes the collaboration much easier.
One thing would be nice. I'd like to have a blacklist in my bugzilla preferences for all the "uninteresing" Classification, Product, Component drop down lists. Maybe this would be a new bugzilla feature ?!
well, I dunno in which situation this shall happen. Just because your account is marked that you are an openSUSE use does not say you have not any other product.
Usually a good idea is store specific searches. That is at least what I do when jumping between my different roles.
On Friday 22 November 2013, Adrian Schröter wrote:
Am Freitag, 22. November 2013, 15:44:59 schrieb Ruediger Meier:
On Friday 22 November 2013, Adrian Schröter wrote:
Am Freitag, 22. November 2013, 15:14:50 schrieb Ruediger Meier:
No, I don't care about about private bugs in bugzilla. I just don't want to have them in submit messages, changelogs and patchinfo of openSUSE packages.
Again, just removing information does not help anyone and will have bad impact on the workforce in openSUSE Factory.
Hm, seems you cannot understand this because you _have_ access. From my point of view we wouldn't remove any information if we remove those dead links.
Imagine a wikipedia where companies would add nice informations but references are private links to private sites. This is only no problem if you belong to that company.
BTW how other companies are doing this? Does Oracle also post cryptic/private references on their published Java release notes? I don't think so. But I'm sure that they also track additional private stuff somewhere else. It is possible and should be done that way.
Could we agree that we may need to mark them differently, eg. with a different tag so no one is loosing time trying to open it?
This would be better already but maybe a bit annoying if somebody makes such bugs public later.
However, I am actually happy that we have only one. In most cases it makes the collaboration much easier.
One thing would be nice. I'd like to have a blacklist in my bugzilla preferences for all the "uninteresing" Classification, Product, Component drop down lists. Maybe this would be a new bugzilla feature ?!
well, I dunno in which situation this shall happen. Just because your account is marked that you are an openSUSE use does not say you have not any other product.
Usually a good idea is store specific searches. That is at least what I do when jumping between my different roles.
Yep, I should do this.
cu, Rudi
On 11/22/2013 04:57 PM, Ruediger Meier wrote:
On Friday 22 November 2013, Adrian Schröter wrote:
Am Freitag, 22. November 2013, 15:44:59 schrieb Ruediger Meier:
On Friday 22 November 2013, Adrian Schröter wrote:
> Am Freitag, 22. November 2013, 15:14:50 schrieb Ruediger Meier:
No, I don't care about about private bugs in bugzilla. I just don't want to have them in submit messages, changelogs and patchinfo of openSUSE packages.
Again, just removing information does not help anyone and will have bad impact on the workforce in openSUSE Factory.
Hm, seems you cannot understand this because you _have_ access. From my point of view we wouldn't remove any information if we remove those dead links.
They help you indirectly.
Having them in allows to review whether all patches that were done for SLES are also done for openSUSE. We had a couple of engineers looking especially at this during the last year so that openSUSE does not miss anything important.
Without the bnc numbers it would be really hard to figure out...
Andreas
On Friday 22 November 2013, Andreas Jaeger wrote:
On 11/22/2013 04:57 PM, Ruediger Meier wrote:
On Friday 22 November 2013, Adrian Schröter wrote:
Am Freitag, 22. November 2013, 15:44:59 schrieb Ruediger Meier:
On Friday 22 November 2013, Adrian Schröter wrote: > > Am Freitag, 22. November 2013, 15:14:50 schrieb Ruediger > > Meier:
No, I don't care about about private bugs in bugzilla. I just don't want to have them in submit messages, changelogs and patchinfo of openSUSE packages.
Again, just removing information does not help anyone and will have bad impact on the workforce in openSUSE Factory.
Hm, seems you cannot understand this because you _have_ access. From my point of view we wouldn't remove any information if we remove those dead links.
They help you indirectly.
Having them in allows to review whether all patches that were done for SLES are also done for openSUSE. We had a couple of engineers looking especially at this during the last year so that openSUSE does not miss anything important.
Without the bnc numbers it would be really hard to figure out...
I know this because I cannot figure out already now ...
cu, Rudi
On Fri, Nov 22, 2013 at 1:17 PM, Ruediger Meier sweet_f_a@gmx.de wrote:
> No, I don't care about about private bugs in bugzilla. I just > don't want to have them in submit messages, changelogs and > patchinfo of openSUSE packages.
Again, just removing information does not help anyone and will have bad impact on the workforce in openSUSE Factory.
Hm, seems you cannot understand this because you _have_ access. From my point of view we wouldn't remove any information if we remove those dead links.
They help you indirectly.
Having them in allows to review whether all patches that were done for SLES are also done for openSUSE. We had a couple of engineers looking especially at this during the last year so that openSUSE does not miss anything important.
Without the bnc numbers it would be really hard to figure out...
I know this because I cannot figure out already now ...
You can. You don't know what the patch is about, but you know patch 3824783 is in both at least.
I think an enhancement to the WebUI or OSC that warns about private bnc references on checkin would be best. Something like source validation, but that emits a warning and lets the commit in.
Because I'd bet many of those bugs remain private because SUSE employees don't even notice they're introducing dead links for the rest. If they knew, they'd be able to take care of it.
The review interface could also mark it, and that would help package reviewers. If you see a private bnc reference, you'll know to check extra carefully whether the changelog text is self-sufficient. If not, you can relax.
On Friday 22 November 2013, Claudio Freire wrote:
On Fri, Nov 22, 2013 at 1:17 PM, Ruediger Meier sweet_f_a@gmx.de
wrote:
> > No, I don't care about about private bugs in bugzilla. I > > just don't want to have them in submit messages, > > changelogs and patchinfo of openSUSE packages.
Again, just removing information does not help anyone and will have bad impact on the workforce in openSUSE Factory.
Hm, seems you cannot understand this because you _have_ access. From my point of view we wouldn't remove any information if we remove those dead links.
They help you indirectly.
Having them in allows to review whether all patches that were done for SLES are also done for openSUSE. We had a couple of engineers looking especially at this during the last year so that openSUSE does not miss anything important.
Without the bnc numbers it would be really hard to figure out...
I know this because I cannot figure out already now ...
You can. You don't know what the patch is about, but you know patch 3824783 is in both at least.
I think an enhancement to the WebUI or OSC that warns about private bnc references on checkin would be best. Something like source validation, but that emits a warning and lets the commit in.
BTW it would be really nice if OBS packages would be git repos. Packages in different projects would be just different branches of one "imaginary common repo". This would make life a lot easier and you could add the unique revision numbers to the bug reports to check even automatically whether a fix is already _merged_ or not. Having a mapping into both directions between bugs and fixes (git revs) would make it possible (for everybody) to track all kind of additional private infos wherever.
Moreover we could even locally fetch branches from the Fedora remotes. Just to compare them or just to have even more references to their bugtracker.
Because I'd bet many of those bugs remain private because SUSE employees don't even notice they're introducing dead links for the rest. If they knew, they'd be able to take care of it.
Yep, this seems to be addressed by the original poster.
cu, Rudi
Ruediger Meier (sweet_f_a@gmx.de) wrote:
BTW it would be really nice if OBS packages would be git repos. Packages in different projects would be just different branches of one "imaginary common repo". This would make life a lot easier and you could add the unique revision numbers to the bug reports to check even automatically whether a fix is already _merged_ or not. Having a mapping into both directions between bugs and fixes (git revs) would make it possible (for everybody) to track all kind of additional private infos wherever.
Yes, that would be really great. A while ago I tried to revive Andreas Grünbacher's bsgit work:
https://files.opensuse.org/opensuse/old-en/5/55/Git-in-the-build-service.pdf
but I only got as far as building the packages:
http://software.opensuse.org/package/bsgit
and didn't actually see what it does yet.
Le Friday 22 November 2013 à 16:57 +0100, Ruediger Meier a écrit :
On Friday 22 November 2013, Adrian Schröter wrote:
Again, just removing information does not help anyone and will have bad impact on the workforce in openSUSE Factory.
Hm, seems you cannot understand this because you _have_ access. From my point of view we wouldn't remove any information if we remove those dead links.
Imagine a wikipedia where companies would add nice informations but references are private links to private sites. This is only no problem if you belong to that company.
BTW how other companies are doing this? Does Oracle also post cryptic/private references on their published Java release notes? I don't think so. But I'm sure that they also track additional private stuff somewhere else. It is possible and should be done that way.
Red Hat for example has exactly the same problem, see for example:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/driver...
which references:
https://bugzilla.redhat.com/show_bug.cgi?id=887006
which is private. I asked for access as I was working on the same bug on SLES11 SP2/3 and I was denied access. I was told that access to the bug would not give me any useful information anyway, and the patch description was indeed good enough so I did not really need to access the bug.
In that case I think the error was to mention a private link in a public commit while it was not needed at all. Opening the bug was not an option for Red Hat and creating a public copy of the bug would have been a waste of resources. With a good description, you need no external reference.
On Fri, Nov 22, Ruediger Meier wrote:
BTW how other companies are doing this? Does Oracle also post cryptic/private references on their published Java release notes? I don't think so. But I'm sure that they also track additional private stuff somewhere else. It is possible and should be done that way.
They do the same as we. Because they have the same problem as we with the same legal constraints, same support problems, etc. I can give you a long list of Red Hat bugs mentioned in Fedora packages, too, where you will only get a permission denied. I only need to find the time to search in my mail archive ...
Thorsten
On Nov 22, 13 16:57:46 +0100, Ruediger Meier wrote:
On Friday 22 November 2013, Adrian Schröter wrote:
Am Freitag, 22. November 2013, 15:44:59 schrieb Ruediger Meier:
On Friday 22 November 2013, Adrian Schröter wrote:
[...]
Hm, seems you cannot understand this because you _have_ access. From my point of view we wouldn't remove any information if we remove those dead links.
Just as a comment: Working for SUSE does _not_ mean you have automatically access to all bugs. There are e.g .security-related bugs and NDA-information containing bugs that are only opened for a very limited number of people. And yes, it's also sometimes frustrating to read a bugnumber, and not being able to check what it is about. So even SUSE-employed people know this.
Stefan
On 11/22/2013 03:33 PM, Adrian Schröter wrote:
[...] You forget that openSUSE is using SUSE bugzilla. So openSUSE would need to look for a new bug tracker ...
That's not the problem. The problem is the following workflow:
SUSE developer gets a (private) bugreport and fixed it in package Y for SLES 11. Then s/he fixes the same bug for openSUSE factory and references the private bugzilla number.
If we really want the SUSE developers to fix the bugs, we have to live with some private bugs. Yes, we should ask for clear descriptions and not just "fix bnc#xxxx",
Andreas
Quoting Andreas Jaeger aj@suse.com:
On 11/22/2013 03:33 PM, Adrian Schröter wrote:
If we really want the SUSE developers to fix the bugs, we have to live with some private bugs. Yes, we should ask for clear descriptions and not just "fix bnc#xxxx",
Which is something 'we' devel project maintainers can do (and do!).
Most of the time I run into 'closed' issues when it comes to identify if a patch is still valid; a clear 'bug statement and how to reproduce the bug' is often missing (or references to test documents).
This is not something I'd expect to be all put into the .changes...
but then, honestly, those happened 'once in a while' to me only and either I contacted any of the nice folks I know with a @suse email address and ask them to open it or at least give me a summary and eventual information available to validate it.
Certainly not a good workflow, but probably it also puts more load on @suse folks than it puts on me.
Dominique
PS: At this point, a thanks to all the suse folks that DO help me get to those things in the past! You know who you are...
On Friday 22 November 2013, Dominique Leuenberger a.k.a. Dimstar wrote:
Quoting Andreas Jaeger aj@suse.com:
On 11/22/2013 03:33 PM, Adrian Schröter wrote:
If we really want the SUSE developers to fix the bugs, we have to live with some private bugs. Yes, we should ask for clear descriptions and not just "fix bnc#xxxx",
Which is something 'we' devel project maintainers can do (and do!).
I guess you only do this because you are one of us without @suse.
Just an example what we are talking about. For example emails like this from opensuse-updates@opensuse.org:
------ openSUSE Security Update: kernel: security and bugfix update ______________________________________________________________________________
Announcement ID: openSUSE-SU-2013:0396-1 Rating: important References: #714906 #720226 #733148 #755546 #762693 #765524 #768506 #769784 #769896 #770695 #773406 #773831 #774285 #774523 #774859 #776144 #778630 #779432 #781134 #783515 #784192 #786013 #787168 #792500 #793671 #797175 #799209 #800280 #801178 #801782 #802153 #802642 #804154 #804652 #804738 Cross-References: CVE-2012-0957 CVE-2012-2745 CVE-2012-3412 CVE-2012-4530 CVE-2013-0160 CVE-2013-0216 CVE-2013-0231 CVE-2013-0268 CVE-2013-0309 CVE-2013-0871 Affected Products: openSUSE 12.1 [...] ------
Such emails should be rejected automatically. The plans in Tomáš initial email are a nice first step.
cu, Rudi
Quoting Ruediger Meier sweet_f_a@gmx.de:
On Friday 22 November 2013, Dominique Leuenberger a.k.a. Dimstar wrote:
Quoting Andreas Jaeger aj@suse.com:
On 11/22/2013 03:33 PM, Adrian Schröter wrote:
If we really want the SUSE developers to fix the bugs, we have to live with some private bugs. Yes, we should ask for clear descriptions and not just "fix bnc#xxxx",
Which is something 'we' devel project maintainers can do (and do!).
I guess you only do this because you are one of us without @suse.
Just an example what we are talking about. For example emails like this from opensuse-updates@opensuse.org:
openSUSE Security Update: kernel: security and bugfix update ______________________________________________________________________________
Announcement ID: openSUSE-SU-2013:0396-1 Rating: important References: #714906 #720226 #733148 #755546 #762693 #765524 #768506 #769784 #769896 #770695 #773406 #773831 #774285 #774523 #774859 #776144 #778630 #779432 #781134 #783515 #784192 #786013 #787168 #792500 #793671 #797175 #799209 #800280 #801178 #801782 #802153 #802642 #804154 #804652 #804738 Cross-References: CVE-2012-0957 CVE-2012-2745 CVE-2012-3412 CVE-2012-4530 CVE-2013-0160 CVE-2013-0216 CVE-2013-0231 CVE-2013-0268 CVE-2013-0309 CVE-2013-0871 Affected Products: openSUSE 12.1 [...]
Such emails should be rejected automatically. The plans in Tomáš initial email are a nice first step.
Even there, I'd argue that it must be decided on a case-by-case: even CVE entries are not made public once registered, but only later, after a coordinated could have been sent out. The same is true for bug reports (in fact, for this reason even OBS allows you to create' secret' projects to fix up stuff behind the curtain).
Don't get me wrong: I'm all for opening up bugs (as many as can be). But at the time the commit message to Factory is checked is likely to early. The time when the update ends up in the :Update channel might be the right moment... or should it be a few days later, so that the majority of the userbase has a chance to actually install the update?
This applies to Security bugs only of course.
As for SLE Bugs: they are different in nature; often there are just 'normal' bugs which could as well have been filed against openSUSE x.y. It's been fixed for SLE and one of the nice guys actually THINKS about openSUSE (which is worth an applause on its own!). In line with 'work upstream', the SLE engineer submits the patch to openSUSE (who, essentially IS upstream to SLE).
And from here on it is openSUSE's responsibility to safeguard itself: by either asking for an accessible bug (but then: by far not every bug we have in openSUSE is linked to a bug; and we should surely not ask for that), having a decent description about the implemented fix (sorry, I consider a "Fix build" not a valid description.. it's a useless comment... ).
As I also said in another mail: most often the bug reference becomes interesting later on; when you run over a (well documente) hack in the .spec file that says it fixes this and that bug... before removing the hack, it would be good to validate that it's no longer needed..
I don't argue bugs should be visible / accessible.. but I do argue that it can not be blindly enforced.
Dominique
On Fri, Nov 22, Ruediger Meier wrote:
Just an example what we are talking about. For example emails like this from opensuse-updates@opensuse.org:
openSUSE Security Update: kernel: security and bugfix update ______________________________________________________________________________
Announcement ID: openSUSE-SU-2013:0396-1 Rating: important References: #714906 #720226 #733148 #755546 #762693 #765524 #768506 #769784 #769896 #770695 #773406 #773831 #774285 #774523 #774859 #776144 #778630 #779432 #781134 #783515 #784192 #786013 #787168 #792500 #793671 #797175 #799209 #800280 #801178 #801782 #802153 #802642 #804154 #804652 #804738 Cross-References: CVE-2012-0957 CVE-2012-2745 CVE-2012-3412 CVE-2012-4530 CVE-2013-0160 CVE-2013-0216 CVE-2013-0231 CVE-2013-0268 CVE-2013-0309 CVE-2013-0871 Affected Products: openSUSE 12.1 [...]
Such emails should be rejected automatically. The plans in Tomáš initial email are a nice first step.
And the people who can read that bugs would complain, because they don't know if their bug is fixed with this release or not. Please start thinking about the consequences not only for you personal, but for other people, too. And no, I don't speak here about SUSE employees. Only because you cannot see a bug, this does not mean other external cannot see it, too.
Thorsten
Dnia piątek, 22 listopada 2013 23:05:21 Thorsten Kukuk pisze:
On Fri, Nov 22, Ruediger Meier wrote:
Just an example what we are talking about. For example emails like this from opensuse-updates@opensuse.org:
And the people who can read that bugs would complain, because they don't know if their bug is fixed with this release or not.
They are reading the wrong list then.
Chris
On 11/22/2013 10:07 AM, Dominique Leuenberger a.k.a. Dimstar wrote:
Quoting Andreas Jaeger aj@suse.com:
On 11/22/2013 03:33 PM, Adrian Schröter wrote:
If we really want the SUSE developers to fix the bugs, we have to live with some private bugs. Yes, we should ask for clear descriptions and not just "fix bnc#xxxx",
Which is something 'we' devel project maintainers can do (and do!).
Most of the time I run into 'closed' issues when it comes to identify if a patch is still valid; a clear 'bug statement and how to reproduce the bug' is often missing (or references to test documents).
This is not something I'd expect to be all put into the .changes...
This should be addressed by "No private initial description allowed". We expect information about the bug and reproduction steps in the initial description. None of that should be "private" sensitive data.
Later, Robert
On Fri, Nov 22, 2013 at 1:30 PM, Robert Schweikert rjschwei@suse.com wrote:
On 11/22/2013 10:07 AM, Dominique Leuenberger a.k.a. Dimstar wrote:
Quoting Andreas Jaeger aj@suse.com:
On 11/22/2013 03:33 PM, Adrian Schröter wrote:
If we really want the SUSE developers to fix the bugs, we have to live with some private bugs. Yes, we should ask for clear descriptions and not just "fix bnc#xxxx",
Which is something 'we' devel project maintainers can do (and do!).
Most of the time I run into 'closed' issues when it comes to identify if a patch is still valid; a clear 'bug statement and how to reproduce the bug' is often missing (or references to test documents).
This is not something I'd expect to be all put into the .changes...
This should be addressed by "No private initial description allowed". We expect information about the bug and reproduction steps in the initial description. None of that should be "private" sensitive data.
You never know.
If the bug is about privilege escalation and there's steps to reproduce THAT...
Hello,
On Nov 22 16:00 Andreas Jaeger wrote (excerpt):
Yes, we should ask for clear descriptions and not just "fix bnc#xxxx",
I think a clear description that is comprehensible without reading any additional (external) source is a must.
And then it does not really matter if this or that reference to this or that external source actually works for a particular reader.
Think about all those various kind of issue trackers or whatever else there is out there in the free software word which may or may not change arbitrarily at any time.
Does anyone really think it works reliable for several years when there is only a reference to an external source?
In particular our business customers deserve to get a clear description that is comprehensible without reading any additional external source so that they could still understand it even after several years when this or that external source may be no longer accessible via that reference.
Kind Regards Johannes Meixner
On 11/22/2013 10:00 AM, Andreas Jaeger wrote:
On 11/22/2013 03:33 PM, Adrian Schröter wrote:
[...] You forget that openSUSE is using SUSE bugzilla. So openSUSE would need to look for a new bug tracker ...
That's not the problem. The problem is the following workflow:
SUSE developer gets a (private) bugreport and fixed it in package Y for SLES 11. Then s/he fixes the same bug for openSUSE factory and references the private bugzilla number.
But why does the initial description have to be private. See my proposal earlier in the thread.
We can argue about work flows and commit messages and and and until the cows come home and we'll make little progress. All of this can be avoided with a few minor changes and it addresses the issues going forward.
Later, Robert
On Nov 22, 13 11:28:02 -0500, Robert Schweikert wrote:
On 11/22/2013 10:00 AM, Andreas Jaeger wrote:
On 11/22/2013 03:33 PM, Adrian Schröter wrote:
[...] You forget that openSUSE is using SUSE bugzilla. So openSUSE would need to look for a new bug tracker ...
That's not the problem. The problem is the following workflow:
SUSE developer gets a (private) bugreport and fixed it in package Y for SLES 11. Then s/he fixes the same bug for openSUSE factory and references the private bugzilla number.
But why does the initial description have to be private. See my proposal earlier in the thread.
My fear is, that this would result in some cases in bug descriptions like "see coment 1. closed description due to security/private issues".
Stefan
We can argue about work flows and commit messages and and and until the cows come home and we'll make little progress. All of this can be avoided with a few minor changes and it addresses the issues going forward.
Later, Robert
-- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 11/25/2013 03:16 AM, Stefan Behlert wrote:
On Nov 22, 13 11:28:02 -0500, Robert Schweikert wrote:
On 11/22/2013 10:00 AM, Andreas Jaeger wrote:
On 11/22/2013 03:33 PM, Adrian Schröter wrote:
[...] You forget that openSUSE is using SUSE bugzilla. So openSUSE would need to look for a new bug tracker ...
That's not the problem. The problem is the following workflow:
SUSE developer gets a (private) bugreport and fixed it in package Y for SLES 11. Then s/he fixes the same bug for openSUSE factory and references the private bugzilla number.
But why does the initial description have to be private. See my proposal earlier in the thread.
My fear is, that this would result in some cases in bug descriptions like "see coment 1. closed description due to security/private issues".
Yes, we would get some cases like this. However we would also get plenty of cases where the initial description is public and useful enough to understand the problem even if most or all remaining comments in a bug might be marked as private.
We have to get over the "all or nothing" mentality and we should not let corner cases prevent a solution that might generally present positive change.
Later, Robert
Moin,
On Nov 21, 13 14:16:48 -0200, Claudio Freire wrote:
On Thu, Nov 21, 2013 at 1:04 PM, Stefan Behlert behlert@suse.de wrote:
Or... just file a new bnc with the non-sensitive description, a link to the private bnc, and add that to the changelog.
You are aware that we are talking about thousands of bugreports in the worst case?
No, I do not have SUSE stats.
This would mena that someone has to do this e.g. for all referenced security bugs, all SLES/SLED bugs and much more.
Supposedly, the work for extracting a minimal description of the bug into a public source would be small compared to actually fixing the bug.
Which could (and should) be added to the changelog then - not in a new bug. In my opinion.
Just to make this clear: Yes, we try to file as many bugs against openSUSE as possible, but there are still a lot left.
I wonder what is planned to achieve with that checking? You are not gaining any more information, as I doubt that a lot of people would really duplicate a (closed) security bug and strip of all related information (which btw makes the duplication worthless).
You are just taking information for some people away.
It is really really wrong to reference a bnc by number on a changelog when that bnc is private. It adds obscurity into the community and that's bad.
I agree with you in general, but I think it's worse to NOT have it referenced. And my fear (and from some past experiences I think it's a realistic fear) it will not end with people duplicating bug reports.
I agree that automatically checking and giving no exception mechanism puts SUSE employees in a position where they will probably choose to not a) push the change into openSuse, or b) reference the bug at all, and that's also bad.
But lets not forget that adding obscure changelogs *is* *quite* *bad* in open source.
I think if the short description in the changelog is "obscure", it's not because of the bugnumber ;) Realistically, if the changelog is good, how many people check all the bugnumbers? (Note: In an enterprise world the number here is 100% or close to, but I have my doubts that in openSUSE this is identical. But I have no numbers, so feel free to correct me.)
So, what do you propose? What *can* SUSE employees do to improve that situation?
My suggestion is to NOT change the current behavior, but put more emphasis on good changelog texts. Maybe a warning to the submitter is the best choice, so that he or she can check and (if possible) adjust the state of the bug?
I am not claiming to have a solution, though :( My goal is to avoid disadvantages for openSUSE, as I think that all products will suffer - openSUSE as well as the Enterprise, as it could result in the loss of synergies.
Stefan
Le Friday 22 November 2013 à 09:22 +0100, Stefan Behlert a écrit :
Moin,
On Nov 21, 13 14:16:48 -0200, Claudio Freire wrote:
On Thu, Nov 21, 2013 at 1:04 PM, Stefan Behlert behlert@suse.de wrote:
Or... just file a new bnc with the non-sensitive description, a link to the private bnc, and add that to the changelog.
You are aware that we are talking about thousands of bugreports in the worst case?
No, I do not have SUSE stats.
This would mena that someone has to do this e.g. for all referenced security bugs, all SLES/SLED bugs and much more.
Supposedly, the work for extracting a minimal description of the bug into a public source would be small compared to actually fixing the bug.
Which could (and should) be added to the changelog then - not in a new bug. In my opinion.
+1.
Bugzilla is a tool to work on bugs, not to document their resolution.
On Friday 22 November 2013, Stefan Behlert wrote:
Moin,
On Nov 21, 13 14:16:48 -0200, Claudio Freire wrote:
On Thu, Nov 21, 2013 at 1:04 PM, Stefan Behlert behlert@suse.de
wrote:
Or... just file a new bnc with the non-sensitive description, a link to the private bnc, and add that to the changelog.
You are aware that we are talking about thousands of bugreports in the worst case?
No, I do not have SUSE stats.
This would mena that someone has to do this e.g. for all referenced security bugs, all SLES/SLED bugs and much more.
Supposedly, the work for extracting a minimal description of the bug into a public source would be small compared to actually fixing the bug.
Which could (and should) be added to the changelog then - not in a new bug. In my opinion.
Just to make this clear: Yes, we try to file as many bugs against openSUSE as possible, but there are still a lot left.
I wonder what is planned to achieve with that checking? You are not gaining any more information, as I doubt that a lot of people would really duplicate a (closed) security bug and strip of all related information (which btw makes the duplication worthless).
You are just taking information for some people away.
It is really really wrong to reference a bnc by number on a changelog when that bnc is private. It adds obscurity into the community and that's bad.
I agree with you in general, but I think it's worse to NOT have it referenced. And my fear (and from some past experiences I think it's a realistic fear) it will not end with people duplicating bug reports.
I agree that automatically checking and giving no exception mechanism puts SUSE employees in a position where they will probably choose to not a) push the change into openSuse, or b) reference the bug at all, and that's also bad.
But lets not forget that adding obscure changelogs *is* *quite* *bad* in open source.
I think if the short description in the changelog is "obscure", it's not because of the bugnumber ;) Realistically, if the changelog is good, how many people check all the bugnumbers?
Packagers are doing it. If you read patch-xyz has been added because of bnc1234 then 1234 must be public.
(Note: In an enterprise world the number here is 100% or close to, but I have my doubts that in openSUSE this is identical. But I have no numbers, so feel free to correct me.)
So, what do you propose? What *can* SUSE employees do to improve that situation?
My suggestion is to NOT change the current behavior, but put more emphasis on good changelog texts.
You should log out from bugzilla for one week to get the feeling of us 2nd class packagers. It's not much fun with all these random non-sense bug numbers.
Maybe a warning to the submitter is the best choice, so that he or she can check and (if possible) adjust the state of the bug?
I am not claiming to have a solution, though :( My goal is to avoid disadvantages for openSUSE, as I think that all products will suffer - openSUSE as well as the Enterprise, as it could result in the loss of synergies.
Just kick out that closed bug numbers. It makes no sense that 99% of the ones who read it can't access it. I would rather support to add chinese text to the changelog than keeping these annyoing "dead links".
cu, Rudi
On 11/22/2013 02:43 PM, Ruediger Meier wrote:
[...] You should log out from bugzilla for one week to get the feeling of us 2nd class packagers. It's not much fun with all these random non-sense bug numbers.
I do understand that concern but opening *all* bugreports is not practical. Yes, we can and should open more bugreports...
Andreas
On Nov 22, 13 14:43:20 +0100, Ruediger Meier wrote:
On Friday 22 November 2013, Stefan Behlert wrote:
Moin,
On Nov 21, 13 14:16:48 -0200, Claudio Freire wrote:
On Thu, Nov 21, 2013 at 1:04 PM, Stefan Behlert behlert@suse.de
[...]
I think if the short description in the changelog is "obscure", it's not because of the bugnumber ;) Realistically, if the changelog is good, how many people check all the bugnumbers?
Packagers are doing it. If you read patch-xyz has been added because of bnc1234 then 1234 must be public.
Good point. But I am still thinking that a good changelog helps here more than a bugreport that may have information that is not even understandable (I have seen everything, from spanish to german to something that seemed to be english :) ).
(Note: In an enterprise world the number here is 100% or close to, but I have my doubts that in openSUSE this is identical. But I have no numbers, so feel free to correct me.)
So, what do you propose? What *can* SUSE employees do to improve that situation?
My suggestion is to NOT change the current behavior, but put more emphasis on good changelog texts.
You should log out from bugzilla for one week to get the feeling of us 2nd class packagers. It's not much fun with all these random non-sense bug numbers.
Oh, I know how this feeling is. I am also not allowed to see all bugs, as I am not part of the Security-team.
As said, I inderstand your concern and wishes, I jsut do not think they are practical. But despite pushing internal to get people less restrict (some bugs really could be opened instead of hidden under the table), I see no solution, sorry.
Stefan [...]
On 21.11.2013 16:23, Thorsten Kukuk wrote:
On Thu, Nov 21, Tomáš Chvátal wrote:
Hello guys,
Just informational mail that we plan to enable bnc# checking in the changelogs to ensure that Factory submissions are in fact only listing visible bugs. [1] [2]
Ok, and since we are not allowed to make nearly all of this bugs public, it will end in either removing the bnc numbers (not good) or not submitting this fixes to openSUSE at all (very bad for openSUSE).
Please think first about the consequences of such changes, and if this is really what you want to archive. Not everything which sounds good will have a positive effect in the end.
I rejected the pull request and factory-auto will stay as it is. I think a better approach is if bernhard's SR->bugzilla interface mails the submitter if the bug is not public and then let the submitter decide if it should be opened up, because a lot of bugs *do* make sense to be open and are just not open because e.g. legal-team always opens up closed bugs even if the problem is just a missing COPYING in a GPL package.
Greetings, Stephan
On 11/22/2013 08:40 AM, Stephan Kulow wrote:
I rejected the pull request and factory-auto will stay as it is. I think a better approach is if bernhard's SR->bugzilla interface mails the submitter if the bug is not public and then let the submitter decide if it should be opened up, because a lot of bugs *do* make sense to be open and are just not open because e.g. legal-team always opens up closed bugs even if the problem is just a missing COPYING in a GPL package.
Coolo, I like your idea, this would be good.
Andreas
Hello,
On Nov 22 08:40 Stephan Kulow wrote (excerpt):
I think a better approach is if bernhard's SR->bugzilla interface mails the submitter if the bug is not public and then let the submitter decide if it should be opened up, because a lot of bugs *do* make sense to be open and are just not open because e.g. legal-team always opens up closed bugs even if the problem is just a missing COPYING in a GPL package.
I do not fully understand who "the submitter" is.
If "the submitter" is the one who submitted the fixed package then usually "the submitter" is not the one who can decide if the bug should be made public.
Assume the legal-team had filed a closed bug and assigned it to "the submitter" who then submitted a fixed package, then "the submitter" cannot make the bug public.
How could "the submitter" find out who the right one is who can actually decide and actually make a bug public?
Kind Regards Johannes Meixner
Am 22.11.2013 15:06, schrieb Johannes Meixner:
Hello,
On Nov 22 08:40 Stephan Kulow wrote (excerpt):
I think a better approach is if bernhard's SR->bugzilla interface mails the submitter if the bug is not public and then let the submitter decide if it should be opened up, because a lot of bugs *do* make sense to be open and are just not open because e.g. legal-team always opens up closed bugs even if the problem is just a missing COPYING in a GPL package.
I do not fully understand who "the submitter" is.
If "the submitter" is the one who submitted the fixed package then usually "the submitter" is not the one who can decide if the bug should be made public.
Assume the legal-team had filed a closed bug and assigned it to "the submitter" who then submitted a fixed package, then "the submitter" cannot make the bug public.
How could "the submitter" find out who the right one is who can actually decide and actually make a bug public?
But if you submit a package with a bug fix mentioned, you can actually go into the bug and ask legal-team if they are fine with opening the bug if it appears to be community relevant. Noone else can
Greetings, Stephan
Dnia piątek, 22 listopada 2013 08:40:45 Stephan Kulow pisze:
it should be opened up, because a lot of bugs *do* make sense to be open and are just not open because e.g. legal-team always opens up closed bugs even if the problem is just a missing COPYING in a GPL package.
What do you mean by that? If the legal team opens a closed bug, it is open, isn’t it?
Chris
Am 28.11.2013 00:13, schrieb Křištof Želechovski:
Dnia piątek, 22 listopada 2013 08:40:45 Stephan Kulow pisze:
it should be opened up, because a lot of bugs *do* make sense to be open and are just not open because e.g. legal-team always opens up closed bugs even if the problem is just a missing COPYING in a GPL package.
What do you mean by that? If the legal team opens a closed bug, it is open, isn’t it?
Words... :)
legal-team always _creates_ _private_ bugs. Does this make more sense to you?
Greetings, Stephan
Hi Tomas, I think this is really bad step. It force SUSE developers to have separate changelogs for SLE and openSUSE projects. Consider current work-flow: 1) we get bug report from paying customer who attach confidential data or want to keep problem private as it can indicate his bussiness plans. 2) we found bug and fix it 3) update for SLE is released. Some customers checks BNC in changelog to ensure that their problem is really fixed. 4) current way if we found that problem affect also opensuse, then we fix it there and use same changelog entry, so we can see if problem is fixed also in opensuse. If your proposal start acting then we cannot use same changelog entry and it makes really hard to check if we port fix to openSUSE. Opening separate bug report just for opensuse seems like adding another obstacle for developers.
I see what you want to fix, but this way it is really bad way and probably end up in deleting all BNCs in changelog for factory (so instead of list of bugs we fix it ends up with line like "port fixes from SLE"). Better solution even if it is not so easy to force is to ensure that changelog entry is good enough even without BNC that is not accessible.
Josef
On Thu, 21 Nov 2013 15:59:53 +0100 Tomáš Chvátal tchvatal@suse.cz wrote:
Hello guys,
Just informational mail that we plan to enable bnc# checking in the changelogs to ensure that Factory submissions are in fact only listing visible bugs. [1] [2]
The code is set-up the way it checks the changelog and reports back with all occurances of bugs that were not visible (it ignores the bnc if bugzilla does not respond, so no worries if it is down, everything is approved :P).
Your actions if cases like this happen are quite simple:
- make the initial bug visible and mark the internal comments as
internal. 2) if not sure ask somebody who knows more to do it for you.
As I wrote there in the code [2] it checks the full new changelog in case some bnc should not be there we don't get conflicts when comparing just diff. So you might get request to make really old bugs visible. It is a tiny annoyance but then we ensure that all informations about our fixes can be really read by anybody.
Cheers
Tom
PS: feel free to improv perl in [2] as I am not exactly mage there :)
[1] https://progress.opensuse.org/issues/571 [2] https://github.com/coolo/factory-auto/pull/46
Dne Čt 21. listopadu 2013 15:59:53, Tomáš Chvátal napsal(a):
Just to note I wrote mine concenrs to the issue on progress too. So please respond with your why-is-it-bad there to convince Ludwig.
I really didn't like the idea too :P just look how long it took me to do something about it.
Tom
On Thursday 21 November 2013 15:59:53 Tomáš Chvátal wrote:
[snip]
So first of all I appreciate your goal to automate bug checks. I can only imagine that Ludwigs idea was to avoid any hints to embargoed fixes (for not yet disclosed security issues). That actually makes sense to me and I have to admit that I uploaded such a fix to the OBS once myself (and yes, I discovered it and our awesome admins killed it).
So it could make sense to disallow uploading embargoed fixes to public projects in OBS. But this would have to happen at checkin time.
Another class of non-public bugs are legal issues. For those, I have to regularly call Ciarran myself. Most of the time, there's no need to keep them private and our legal team opens them up. But some have to stay private for a longer period (CC'ing Ciarran therefore).
Closely related, you could definitely check for CVE numbers. But those are more relevant for maintenance updates rather than Factory submissions.
From a Factory reviewers perspective, we also look if the mentioned bug is
actually matching the patch (happens more often than you think) or if the upstream-proposed patch is the same that the packager submits. We also have contributors that haven't yet heard of [0] and provide funky spellings like "bugzilla#123", "bnc 123", "bug 123", "#123", "bnc #123". I would love to see those auto-declined :-)
[0] http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines#Current_set_of_...
On 11/21/2013 09:59 AM, Tomáš Chvátal wrote:
Hello guys,
Just informational mail that we plan to enable bnc# checking in the changelogs to ensure that Factory submissions are in fact only listing visible bugs. [1] [2]
The code is set-up the way it checks the changelog and reports back with all occurances of bugs that were not visible (it ignores the bnc if bugzilla does not respond, so no worries if it is down, everything is approved :P).
Your actions if cases like this happen are quite simple:
- make the initial bug visible and mark the internal comments as internal.
- if not sure ask somebody who knows more to do it for you.
As I wrote there in the code [2] it checks the full new changelog in case some bnc should not be there we don't get conflicts when comparing just diff. So you might get request to make really old bugs visible. It is a tiny annoyance but then we ensure that all informations about our fixes can be really read by anybody.
Replying to the original post, but considering comments made in subsequent posts.
It is very easy to sympathize with and understand the desire to have bug reports accessible by community contributors that do not happen to work for SUSE to understand implemented fixes referenced in changelogs. This should be our premise going forward. However, implementing this retroactively is a problem as this has not been common practice. The problems of applying this wholesale have been outlined by others in this thread.
Also as commented by others this creates a potentially very large work load plus chances where progress may be impeded. For example, a contributor applying an update or a fix to a specific package may be blocked from submitting the changes because the new changelog checks my block the submission based on a referenced bug number that is not accessible to the contributor. Now the contributor has a lot of extra work of chasing down the necessary help.
On the other side having people that work with sensitive data create "sanitized" bug reports for all existing sensitive bugs creates a lot of work that is very unlikely to get done.
However, I believe there is a way forward, and here is my proposal:
1.) Modify bugzilla such that the initial description cannot be marked as "Private". + This ensures, so one would hope, no sensitive data will be posted to the initial description + This also ensures that going forward bugs are public
2.) Modify the check script to take the date of submission into account. + changelog entries are dated and the checker should be able to ignore checks for bnc# referenced prior to a certain date
This proposal provides the information contributors need on a going forward basis. I realize that we are still left with debt based on past practices, but in reality that debt is not going to get cleaned up, thus we might as well ignore it. Additionally the proposal allows things that are in the past, when the practices were different, to remain in the past. Some information is not accessible, that's unfortunate, but again this is very unlikely to change even if we try to enforce openness for the past. Last but not least the proposal establishes a new practice going forward. If followed consistently, the past practice will be less and less relevant in the future.
Later, Robert
On Thu, Nov 21, 2013 at 1:32 PM, Robert Schweikert rjschwei@suse.com wrote:
2.) Modify the check script to take the date of submission into account. + changelog entries are dated and the checker should be able to ignore checks for bnc# referenced prior to a certain date
This proposal provides the information contributors need on a going forward basis. I realize that we are still left with debt based on past practices, but in reality that debt is not going to get cleaned up, thus we might as well ignore it. Additionally the proposal allows things that are in the past, when the practices were different, to remain in the past. Some information is not accessible, that's unfortunate, but again this is very unlikely to change even if we try to enforce openness for the past. Last but not least the proposal establishes a new practice going forward. If followed consistently, the past practice will be less and less relevant in the future.
3.) Allow entries to be marked for exception. Legal bugs may need to stay private, and with a good description at its side that might be a non-issue. The change author should be able to mark its desire for it to be an exception, factory reviewers would verify that the description does indeed substitute the bug report.
On Thu, Nov 21, 2013 at 11:32:54AM -0500, Robert Schweikert wrote:
However, I believe there is a way forward, and here is my proposal:
1.) Modify bugzilla such that the initial description cannot be marked as "Private". + This ensures, so one would hope, no sensitive data will be posted to the initial description + This also ensures that going forward bugs are public
Consider L3 bugs which are private by policy. They are opened by NTS guys who sometimes have no idea about the problem in which case they copy and paste the e-mail they get from the customer - which is in such case much better than trying to rephrase the description.
If we force the "initial comment must be public" policy by technical means, I'm afraid the result may be that we will have a lot of bugs with either public initial comment containing non-public information (so that we can never make the bug public) or just a formal initial comment not describing the problem at all (and the real description in Comment 1).
Another problem are TP-L3 bugs which are opened by people from other companies who now expect their comments to be seen only by us and by them. If your proposition was accepted, we would have to explain to all of them that their initial description would become public one day and that they have to keep that in mind. And hope that all of them will. I don't believe this is going to work.
Yes, I admit that facing the idea of having to go through all the comments (sometimes even few hundred of them) and attachments every time I close a bug and to fix their visibility is not very appealing to me. But I will cope with it if I have to. However, the problem with enforced public initial comment potentially containing non-public information is something we must take into account.
And we should also keep in mind that it's actually neither OpenSuSE bugzilla nor SuSE bugzilla. It's Novell bugzilla we just share with them. So either the feature would have to be limited to (Open)SuSE products (which is not easy because sometimes it's not clear from the start whom does the bug belong to) or Novell would have to agree with it.
Michal Kubeček
Le vendredi 22 novembre 2013, à 18:05 +0100, Michal Kubecek a écrit :
And we should also keep in mind that it's actually neither OpenSuSE bugzilla nor SuSE bugzilla.
s/OpenSuSE/openSUSE/ (and s/SuSE/SUSE/)
It's important that we all write this correctly, so as to not confuse external people.
Cheers,
Vincent
Tomáš Chvátal wrote:
Just informational mail that we plan to enable bnc# checking in the changelogs to ensure that Factory submissions are in fact only listing visible bugs. [1] [2]
Since I was the one asking for that feature but unfortunately was on vacation when the first implementation was proposed. So let me respond to a few concerns brought up in this thread.
- There is no security background on this request. It's just for the sake of allowing people to check the reason of changes, allow them to comment on them in the right place and potentially also allow them to re-open the bug if needed. It's a PITA having to ask people via side channels to open bug reports and then wait days to get a reaction. Anyone who was in the situation of having to deal with e.g. Legal bugs assigned to others knows how it interrupts your workflow and how bad it feels.
- Legal bugs not being public is for legacy reasons and the way bugzilla is currently set up. I've been talking to people about getting openSUSE legal bugs public by default. There seems to be an agreement and a way to achieve that. Implementation pending.
- It is true that the initial description of bugs cannot be modified. So if you accidentally pasted stuff there that shouldn't be public you have to mark it private and provide a better summary in another comment as workaround. That is a limitation of our bugzilla instance and could be fixed.
- Security bugs are not public only when there is an embargo. During that period there are no requests that concern factory-auto. When a security issue becomes public the SUSE Security Team makes the bug public. The security team files bugs already having in mind that the bug will have to be made public at some point exactly because of the aforementioned limitation. Any really sensitive information is kept private of course. Bug comments and attachments are reviewed before actually opening up a bug. Err on the safe side. I've been doing that myself for years, it's not a big deal and worth the extra effort to make the work more transparent.
- If it's technically not possible to make SLE bugs public because the check box is missing then this this can be fixed by changing the product configuration in bugzilla. Wrt sensitive information in there the same process as security follows for years already can be applied. It's just a matter of willingness to do that.
- Wrt the implementation I agree that the checker should only look at the diff and not require changing legacy bugs.
- A rejection by factory-auto is not an ultimate failure. If the submission got rejected because of a non-public bug you are free to re-open the request. If the reviewers are fine that, fine. Still maybe that little extra step helps to raise awareness and reduce the number of actually needlessly private bug reports.
- obviously other distros aren't perfect either. That doesn't mean we should use that as excuse for not improving ourselves.
cu Ludwig
On 27.11.2013 14:41, Ludwig Nussel wrote:
- A rejection by factory-auto is not an ultimate failure. If the submission got rejected because of a non-public bug you are free to re-open the request. If the reviewers are fine that, fine. Still maybe that little extra step helps to raise awareness and reduce the number of actually needlessly private bug reports.
If you reopen the request, factory-auto will reject it again.
Greetings, Stephan
Stephan Kulow wrote:
On 27.11.2013 14:41, Ludwig Nussel wrote:
- A rejection by factory-auto is not an ultimate failure. If the submission got rejected because of a non-public bug you are free to re-open the request. If the reviewers are fine that, fine. Still maybe that little extra step helps to raise awareness and reduce the number of actually needlessly private bug reports.
If you reopen the request, factory-auto will reject it again.
Well, that behavior needs to reconsidered in case of the bug checker then :-)
cu Ludwig
-
Adam Spiers -
Adrian Schröter -
Andreas Jaeger -
Claudio Freire -
Dominique Leuenberger a.k.a. Dimstar -
Jean Delvare -
Johannes Meixner -
Josef Reidinger -
Křištof Želechovski -
Ludwig Nussel -
Marcus Meissner -
Michal Kubecek -
Robert Schweikert -
Ruediger Meier -
Sascha Peilicke -
Stefan Behlert -
Stephan Kulow -
Thorsten Kukuk -
Tomáš Chvátal -
Vincent Untz