Mailinglist Archive: opensuse-packaging (174 mails)

< Previous Next >
Re: [opensuse-packaging] factory-auto will start checking bnc# visibility

Quoting Ruediger Meier <sweet_f_a@xxxxxx>:

On Friday 22 November 2013, Dominique Leuenberger a.k.a. Dimstar wrote:
Quoting Andreas Jaeger <aj@xxxxxxxx>:
> 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@xxxxxxxxxxxx:

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
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.

To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >