Hello, let me play devil's advocate ;-) Am Donnerstag, 9. April 2020, schrieb Matthias G. Eckermann:
On 2020-04-09 T 15:30 +0200 Stefan Seyfried wrote:
Now if the first step would just be to open all bugzilla entries that are mentioned in openSUSE package change logs... ;-)
the need for this and the use case are understood, indeed, and this aspect is on our list to be evaluated in the next months.
SLE bugreports are a topic that is much older than this discussion, even older than Leap. IIRC I already talked to AJ about it at the first (!) openSUSE Conference years ago, and repeated it in more than once, including several (typically face2face) board meetings - basically whenever someone who looked important enough ;-) was there. The answer was always that "the problem is understood, it isn't easy to fix, and it will be evaluated and improved". I'm sorry to say that, but I've heard this long and often enough, and will only believe you once I see lots of public SLE bugreports ;-) The only improvement so far is bugshare - which means sending a mail to ask for details of a specific bugreport, and if you are lucky, you get a reply with a rough (more or less useful) summary of the bugreport. If you are less lucky, the people reading the bugshare requests don't even answer - maybe they are busy with other stuff, maybe for other reasons. (Just wondering - Simon, how many bugshare requests do you/the bugshare team receive per month, and how many of them get answered?) While bugshare is at least an improvement, IMHO it is best described as "nice try". Getting a rough summary of a bugreport isn't too helpful, and the whole bugshare approach doesn't scale well because it involves lots of manual work - someone has to read the bugreport and to write the rough summary. IIRC bugshare was meant as a quick-to-implement workaround until we get the real problem fixed - but I haven't seen progress on the "make (most) SLE bugs public" topic since then. In the meantime, I stopped trying bugshare after getting some not-too- useful summaries and sometimes not always getting an answer at all. Instead, I switched to reading the added patches when seeing a non- public boo/bsc number in a changelog. That's faster (no need to wait/ hope for a bugshare reply) and more helpful - the patch shows what was done, and often allows to understand the underlying bug better than a rough summary of the bugreport. Sadly, this "reverse engeneering" method takes much more time than reading a bugreport, and requires at least some basic knownledge of coding and reading patches.
As you can imagine, though, the devil is in the detail, as in many cases, bugs are filed on behalf of customers or partners, where SUSE needs to protect customer/partner specific information.
But you are aware of that challenge anyways, aren't you?
Yes, I'm aware of these challenges - I've heard about them often enough ;-) OTOH, non-public SLE bugs are a known problem since years (typically becoming more painful before Leap major releases), and quite some people had enough time to think about solutions for these challenges. AFAIK there's a bunch of bugs which get filed by SUSE employees (for example during testing and QA) that don't involve any customer information. Making these bugs public by default shouldn't be too hard. Even worse (and more interesting[tm]) - sometimes Leap bugs get moved to SLE, and at the same time become non-public. To start with - actually making/keeping these bugs public might indeed be a problem. AFAIK the bugzilla config doesn't allow to make SLE bugs public, no matter how hard you try. If this is still true, it should be obvious that this needs to be changed first. (A quick bugzilla report query indicates that there are ~500 public bugs for _Beta_ SLE 15 and SLE 15 SP1, which is not very much [1]. For the final releases, I only found a few bugs - all reported by me, then moved from Leap to SLE and therefore non-public now (I can access them because I'm the reporter). I'll take this as an indication that making SLE bugs public is still not possible.) The bugs with customers or partners involved are indeed the most difficult ones - but even for them, I've heard about methods that would allow to make many of them public. For example, bugzilla allows to mark individual comments as private, so you could have a somewhat generic public bugreport, and then a private comment that includes the customer- specific data. And yes, there might also be some bugs that have to be completely non- public (for example security issues[2] or bugs discussing things that are under NDA). That's completely understandable, and as long as this is only the minority of bugs, it's not a serious problem. I'll end this rant with some proposals how we could get more (most?) SLE bugs public - and some people will notice that there isn't too much new stuff in this list: - change the bugzilla config to make it technically possible to mark SLE bugs as public - when moving a bug from Leap to SLE, keep it public (and/or stop moving bugs from Leap to SLE, see the bonus rant below) - change the bugzilla config so that SLE bugs are public by default - unless the reporter marks them as private. (Of course you'll need to tell that to everybody in advance to avoid unpleasant surprises.) - educate everybody to split bugreports and comments into a) a public generic bugreport/comment, and b) a private comment with customer- specific details so that at least part a) can be public - encourage SLE maintainers to CC the openSUSE maintainers of the affected package in bugreports (AFAIK there are even some AppArmor bugs that I can't access) Oh, and as a somewhat unrelated recommendation: I've heard more than once that moving a bug to SLE helps to get it fixed because "it's important for SLE". While this is a nice trick to convince $manager, I'd recommend to get rid of the need for it, and handle Leap bugs on the same level as SLE bugs ;-) Needless to say that what I wrote above also applies to feature requests in FATE or nowadays Jira. Regards, Christian Boltz [1] ... says someone who - starting with SUSE Linux 9.2 beta - reported a total of 1342 bugs ;-) [2] actually the security team is quite good at making bugs public once the fix is released and the embargo is lifted -- The clean solution would be to kick out the whole freedesktop crap. At least would be nice if freedesktop would only break desktop related stuff instead of whole systems. [Ruediger Meier in opensuse-factory] -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org