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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org