reply to Gerald Pfeifer:
On Sun 2020-04-12, cunix wrote:
For you guys inside SUSE this is probably hard to follow and it might not be very rational:
I think I actually understand where you are coming from. Let me share from my own experience:
Thank you for the answer Gerald!
From the outside these special SLE things are hard to understand and when reading about non disclosure agreements, certifications and special partner handling there might be some sentiment of seeing this as a little black box some users are not able to grant the same level of trust as for obs.
Those "special SLE things" like non disclosure agreements (that may give SUSE earlier access to code from partners while they are in the process of upstreaming, but largely are there for joint planning these days), certifications (which happen after the product is more or less done), and other considerations usually happen "outside" or around the product and its actual development and building.
From an engineering perspective product development (minus the planning and administration) and building are pretty similar to what you see on the openSUSE side. In other words, it's probably okay, if not best, to ignore most references to most of those "enterprise processes". ;-)
I do see your point and thank you for sharing your perspective. Nevertheless some kind of unbalance will probably remain because non-SUSE openSUSE people might only get "second-hand" information from what happens inside SLE/SUSE. As long as both projects don't follow the same rules and are equally open, granting the same level of trust is really hard.
Think of two kitchens (~ build service) sourcing their ingredients from the same markets, shops and farms (~ upstream projects) using the same recipes (~ spec files etc) with qualified cooks (~ packagers, release managers, UX folks, testers,...) served by friendly waiters who are happy to answer any questions (~ supporters, doc folks).
One kitchen guarantees you can have certain menu items for 13+ years and reach them via an 800 number, and they'll serve food 24x7 wearing green polo shirts with a company logo, matching the one on the starched table cloth, whereas the other place may appear a bit more, umm, unorthodox, while both serve comparable food and you don't have to worry about GMO let alone food poisoning in either case.
Nice :)
(Disclaimer: Like most analogies this one is far from perfect and mostly intended for your entertainment. :-)
I'll try to stay with your picture - so the same disclaimer should apply and it should not be considered too serious: While getting hopefully the same lunch from both, I can see through the windows of the later kitchen and even enter it, look over the cook's shoulders, propose to use some more salt, or even decide to step up and take his job, if he has left. In a future with more meals coming from the former kitchen, the later gets somehow reduced to a food delivery service (for the shared packages). Cooks currently working here might loose knowledge how to cook properly because they can only propose changes for the recipes to those working in the company kitchen, but they are not able/allowed to enter it. They can continue to create some ice cream or puddings for the broader audience, but working on the main meal will be done more often at home because this task is done by those with green polo shirts. What I'm asking for with keeping the inclusion of an openSUSE signature is some kind of stamp/attestation/guarantee by the food delivery service, that the meal produced by the company kitchen is indeed the same that would have been created in the community kitchen. This should help to prevent the delivery of rotten food. As consumer I choose and therefore trust the delivery service as the last joint of the food production chain where I'm getting my food from but have only limited influence where and how the food is produced. Each part of this chain chooses its next joint upwards (~ trust) and is responsible downwards (~ signature). So, the relationship between company kitchen owner and consumer is only indirect. If nevertheless some day recipe and meal don't match up or an alien element is found in the food, consumers will raise their complains to the delivery service. The delivery service has to be accountable and should not be able to only advice the consumer to negotiate with the company kitchen owner, because the consumer has lost the receipt (~ no openSUSE signature in rpm) proving where he once got the lunch from. Because of the not existing direct relationship between consumer and company kitchen owner, the later will probably ignore such complains from consumers who can't prove any production failures because they are not allowed to enter and look into the kitchen/factory. They would have to send the remaining food to some special lab that is able to reverse engineer the meal and deduce if there was only added some pepper in the wrong place of the meal or if in the worst case meat from a horse grown up near the Dardanelles was included by farmer or cooks following advice from the kitchen owner (who follows himself some sort of request from a "partner"). Therefore, in my opinion, until the company kitchen can be entered the same way as the community kitchen and all cooks are bound by the same rules, which are enforced by the same entity, consumers need at least more ways (~ multiple signature) to trace the path of the food production and delivery process in order to provide clear accountabilities. To not make false claims, the delivery service (~ obs for openSUSE Leap) has to verify build reproducibility, before adding its signature (not replacing the SUSE sig).
Gerald
cunix -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org