Mailinglist Archive: opensuse-packaging (174 mails)

< Previous Next >
Re: [opensuse-packaging] factory-auto will start checking bnc# visibility
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:
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.


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

--
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Tech Lead
Public Cloud Architect
rjschwei@xxxxxxxx
rschweik@xxxxxxxxxx
781-464-8147
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >
References