Hi,

Hi Christian,

Am 17.04.19 um 22:13 schrieb Christian Boltz:

...

Hello,

thanks for the report.

...

== Foundation/Independence ==

* we need to decide which way (e.V., joining an umbrella foundation) makes sense - topic for the face to face meeting, feedback on opensuse-project@ is of course welcome

I apologize if I missed the note, but can you point me to the vision document of an independent openSUSE? I am sure if you guys discuss such an fundamental move, there is some writeup?

Not really, the only things we officially heard were short blurs in minutes :/ The big discussion about this happened right after the announcement of EQT wanting to buy SUSE last year. It should be somewhere in the archives. (You can blame me for this entire discussion as well :P) The best materials about Foundation talks were the ones from 2010/2011.

...

* Simon will write up a summary of the options of umbrella foundations * in general feedback from SUSE about becoming independent is positive, but we've also heard a concern that independence could be driven by fundamental things, not practical reasons

What else could that be than "fundamental things" that would drive us away? If Mom is doing the laundry and serving lunch on Sundays, why would you ever move out? Not for practical reasons, right?

That obviously depends if your parents don't start asking you for money for services they provide when you start earning some for yourself. A long family tradition here :D

...

* if ever needed, we could ignore whatever SUSE does and go our own way

Sorry to say it that bluntly, but this sounds a bit naive.

What I managed to gather, SUSE has not been against the idea yet.

...

* a foundation / independence would make legal stuff like GDPR our business * Simon will talk to Ciaran how we could handle GDPR and other legal stuff

For sure Ciaran is one of the most friendliest and helpful lawyers this planet has, but he is a SUSE employee. I am sure you want to ask him in his role of a community member, but hey, to me that feels a bit like asking Daddy to organize the moveout. We should not put him in that situation.

Wouldn't it be a good exercise to find an independent lawyer, work the topic through with her, and in the end make sure that costs are handled?

Costs for lawyering would also need to be paid with SUSE money most likely :P Adding to GDPR, there are reasons beyond foundation itself to start thinking about account system for openSUSE services that is not relying on Micro Focus or SUSE. It might be a good idea to start looking into noggin and ipsilon (especially since we need to have a replacement for old Novell OpenID). Help with that required, it's not a one person job. Beyond that, a bunch of other migrations from Micro Focus hosted services, a bunch of servers still rely on old infra there, would be awesome if there were move volounteres helping out with migration (for more details though, ask heroes@opensuse.org)

...

== mail hosting using mailbox.org ==

We have an offer from Heinlein / mailbox org to make @opensuse.org mail addresses real mailboxes.

Do our members want this? (Feedback on opensuse-project and @oSC welcome)

I like the idea.

I don't hate the idea, but it opens up the possibility to integrate too much of openSUSE resources into closed source services (since mailbox.org client is closed sourced). Although I'm using their services, so I probably don't have too much say in this :D LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On czw, Apr 18, 2019 at 9:07 AM, Wolfgang Rosenauer <wolfgang@rosenauer.org> wrote:

Hi,

Am 17.04.19 um 23:54 schrieb Stasiek Michalski:

...

...

...

== mail hosting using mailbox.org ==

We have an offer from Heinlein / mailbox org to make @opensuse.org mail addresses real mailboxes.

Do our members want this? (Feedback on opensuse-project and @oSC welcome)

I like the idea.

I don't hate the idea, but it opens up the possibility to integrate too much of openSUSE resources into closed source services (since mailbox.org client is closed sourced). Although I'm using their services, so I probably don't have too much say in this :D

Not sure what you mean by "integrating" here but primarily there is nothing closed source at mailbox.org. What client or component do you think is?

Isn't the web client closed? I did do some digging to find it, but couldn't. LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On czw, Apr 18, 2019 at 9:20 AM, Vinzenz Vietzke <vinz@vinzv.de> wrote:

Am Donnerstag, 18. April 2019, 09:12:46 CEST schrieb Stasiek Michalski:

...

...

Not sure what you mean by "integrating" here but primarily there is nothing closed source at mailbox.org. What client or component do you think is?

Isn't the web client closed? I did do some digging to find it, but couldn't.

Web client is OpenXchange, therefore open source. But there are some closed source bits:

https://userforum-en.mailbox.org/topic/is-everything-at-mailbox-org-open-sou...

Ok, thanks, that clears up things a bit :D (I mean, as you can imagine, my position changes based on this, I'm fine with the proposal) LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Hello together,

Gesendet: Mittwoch, 17. April 2019 um 22:45 Uhr Von: "Klaas Freitag" <freitag@opensuse.org> An: opensuse-project@opensuse.org Betreff: Re: [opensuse-project] 2019-04-02 board meeting minutes

Hi Christian,

Am 17.04.19 um 22:13 schrieb Christian Boltz:

...

== Foundation/Independence ==

* we need to decide which way (e.V., joining an umbrella foundation) makes sense - topic for the face to face meeting, feedback on opensuse-project@ is of course welcome

I apologize if I missed the note, but can you point me to the vision document of an independent openSUSE? I am sure if you guys discuss such an fundamental move, there is some writeup?

We had long discussions about that in the past. That is documented in most Board meeting minutes.

...

* a foundation / independence would make legal stuff like GDPR our business * Simon will talk to Ciaran how we could handle GDPR and other legal stuff

For sure Ciaran is one of the most friendliest and helpful lawyers this planet has, but he is a SUSE employee. I am sure you want to ask him in his role of a community member, but hey, to me that feels a bit like asking Daddy to organize the moveout. We should not put him in that situation.

Wouldn't it be a good exercise to find an independent lawyer, work the topic through with her, and in the end make sure that costs are handled?

I can offer a discussion with an independent lawyer with a PhD degree on Friday of the oSC. Our working group Open Source has such a lawyer as a Speaker for "Lizenzen freier Software" at the TH Nürnberg. Come at 17:30 to the Faculty of Computer Science. After the presentation he will be open for other open source discussions. This lawyer is Apache Member and his wife is Debian Developer. He knows different communities, their rules and organizations. He is living open source and knows what he is telling. Therefore, he can tell us his opinion, too. Best regards, Sarah -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Am 19.04.19 um 09:21 schrieb Simon Lees:

...

The board is still in the early stages of discussing such a change, at the moment we are still looking at various options, during the board face 2 face the week before oSC we plan to come up with one or several or no concrete proposals that we will present at oSC to start discussing more broadly with the community.

Ok. As we did in the past. All the discussions lacked one thing for me: The vision what openSUSE will do, what it will head for, how it will stay relevant if it loosens the relationship with SUSE. And how that will be beneficial to the project and whole community. As long as that can not be nailed down by somebody and being presented clearly and documented, my feeling is that discussions about the "how" to set up a foundation are pointless. Been there, done that, /me being a mummy of openSUSE.

...

What else could that be than "fundamental things" that would drive us away? If Mom is doing the laundry and serving lunch on Sundays, why would you ever move out? Not for practical reasons, right?

On the other hand given EQT's business model it is almost certain that at some point in the future SUSE will be sold again or publicly listed, and given the current good working relationship between SUSE and openSUSE it is likely easier to have such discussions now vs in the future should someone buy SUSE and install new management that doesn't value openSUSE in the same way the current management does.

Maybe. No change to the past: SUSE was most of the time in the situation of being a good candidate for being sold. But yes, having discussions is good, but I would put the tune carefully. Why not have discussions about real commitments what SUSE does for openSUSE, and have that documented and put in public? Being a more important and officially tighter coupled part of SUSE would put openSUSE in a better position when SUSE again changes the owner in the future, no? There would be topics enough to discuss I think, and to try to get real commitments from SUSE. A few examples: a) Commitment to keep openSUSE as base distro for SUSE's enterprise products. How would openSUSE look like if SUSE suddenly jumps on a deb based distro to ship interesting enterprise applications? What would currently hinder SUSE to do that? b) Lots of infrastructure topics c) Investments of workforce into the build service for example.

We are obviously still working through this and a number of other issues but once we have all the info we need we will present it to the community in a clear way, we are not at that point yet.

When you say "we" here, you mean the board, right? Feels strange to me that this kind of important topic is worked through by the board and later be presented to the community. But maybe that is only me. Klaas -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On 19/04/2019 20:09, Klaas Freitag wrote:

Am 19.04.19 um 09:21 schrieb Simon Lees:

...

...

The board is still in the early stages of discussing such a change, at the moment we are still looking at various options, during the board face 2 face the week before oSC we plan to come up with one or several or no concrete proposals that we will present at oSC to start discussing more broadly with the community.

Ok. As we did in the past. All the discussions lacked one thing for me: The vision what openSUSE will do, what it will head for, how it will stay relevant if it loosens the relationship with SUSE. And how that will be beneficial to the project and whole community.

In some ways it may also strengthen our relationship by better defining who is responsible for what and where,

As long as that can not be nailed down by somebody and being presented clearly and documented, my feeling is that discussions about the "how" to set up a foundation are pointless. Been there, done that, /me being a mummy of openSUSE.

...

...

What else could that be than "fundamental things" that would drive us away? If Mom is doing the laundry and serving lunch on Sundays, why would you ever move out? Not for practical reasons, right?

On the other hand given EQT's business model it is almost certain that at some point in the future SUSE will be sold again or publicly listed, and given the current good working relationship between SUSE and openSUSE it is likely easier to have such discussions now vs in the future should someone buy SUSE and install new management that doesn't value openSUSE in the same way the current management does.

Maybe. No change to the past: SUSE was most of the time in the situation of being a good candidate for being sold. But yes, having discussions is good, but I would put the tune carefully. Why not have discussions about real commitments what SUSE does for openSUSE, and have that documented and put in public? Being a more important and officially tighter coupled part of SUSE would put openSUSE in a better position when SUSE again changes the owner in the future, no?

These things are somewhat being discussed at the same time.

There would be topics enough to discuss I think, and to try to get real commitments from SUSE. A few examples:

a) Commitment to keep openSUSE as base distro for SUSE's enterprise products. How would openSUSE look like if SUSE suddenly jumps on a deb based distro to ship interesting enterprise applications? What would currently hinder SUSE to do that? Legacy heaps of legacy, SUSE's enterprise customers do not want to be forced to make more changes then they need, swapping the underlying distro would probably cause most customers to consider other alternative distro's, I really don't see this ever happening.

b) Lots of infrastructure topics c) Investments of workforce into the build service for example.

SUSE is still the main contributor to build service code and I don't see that changing, SUSE has also given a commitment that they will continue to provide openSUSE with all the core infrastructure they need for shipping releases and have reaffirmed this position to the board in recent weeks.

...

We are obviously still working through this and a number of other issues but once we have all the info we need we will present it to the community in a clear way, we are not at that point yet.

When you say "we" here, you mean the board, right? Feels strange to me that this kind of important topic is worked through by the board and later be presented to the community. But maybe that is only me.

The we here is the board, and we as the board feel like we should at least put together a decent starting point for discussion, we are in a better position to come up with for an example a list of things that we think are feesable and unfeasable to help frame the discussion, -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Le 19/04/2019 à 14:34, Klaas Freitag a écrit :

in the base since years. So why not joining the big community of people doing deb based base systems

will this change anything? are rpm so different from deb? Is the reason to have both rpm & deb other than historical? may be making a better "alien" could make the job?

Ok. Is there a public statement from SUSE about that? It's cool that somebody from SUSE told the board something, but how valuable is that in the moment where SUSE is changing owner again? That is why I think the board should try to get SUSE to make public statements about these things.

I didn't follow the subject closely, but is now SUSE an independent company? Some ideas: * There are approximately 3 strong players in (distro) linux professional: Red Hat, Canonical and SUSE. It's a fairly small amount for a growing customer base, not sure grouping them would be a good idea (for the owner) * I see from time to time flame wars that make me feel it wont be so easy for any Big Brother to fire a distro without breaking the hole open source ecosystem, that is openSUSE is a good umbrella for SUSE to attract free developers and customers * The final judge is the fun people find in working for a free distro, else they would do it for money. I see an openSUSE foundation as a way to make this fun bigger, to make openSUSE people happier, still in strong commitment with SUSE and of course as a way to attract third party sponsors. https://lists.opensuse.org/opensuse-foundation/ jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

DISCLAIMER: As Chairman of the Board, there are times I speak on behalf of SUSE or the openSUSE Board. This is not one of those times. This is a topic which cuts right through my formal responsibilities as openSUSEs Chairman and my longer standing personal commitments to the Project. Therefore I ask that everyone considers what I sahare in this thread as my own personal view, and should absolutely not be considered to be an official view of SUSE or the Board. That said, I know what I say is obviously informed by my unique position, so risk being interpreted with extra weight. I want to make sure the parties I work most closely with have an opportunity to correct, elaborate, or respond to anything I say. As I expect the Board are all here I don't have to worry about them, but I'm CCing Thomas Di Giacomo (President of Engineering, Product and Innovation @SUSE) so he knows what's being said here and can either step in to speak on behalf of SUSE or prompt me if I need to speak in a more formal capacity.

...

SUSE has also given a commitment that they will continue to provide openSUSE with all the core infrastructure they need for shipping releases and have reaffirmed this position to the board in recent weeks. Ok. Is there a public statement from SUSE about that? It's cool that somebody from SUSE told the board something, but how valuable is that in the moment where SUSE is changing owner again? That is why I think the board should try to get SUSE to make public statements about these things.

When EQT purchased SUSE, the Board didn't need to do anything to get SUSE to reaffirm that commitment; SUSE's CEO contacted me directly (waking me up early in the morning on a vacation day no less) so I could provide such a statement on SUSE's behalf personally to the community. https://lists.opensuse.org/opensuse-project/2018-07/msg00000.html This commitment has been repeated and reaffirmed at every opportunity, in both formal and informal settings, pretty much whenever anyone from SUSE's executive ever mention the words 'openSUSE'. If I relayed them all to the mailinglists, I expect people would get bored. There are many factors at play here (which I fear I delve into in excessive detail below), but I personally do not have a shred of doubt regarding SUSE's senior management commitment to openSUSE.

...

...

There would be topics enough to discuss I think, and to try to get real commitments from SUSE. A few examples:

a) Commitment to keep openSUSE as base distro for SUSE's enterprise products. How would openSUSE look like if SUSE suddenly jumps on a deb based distro to ship interesting enterprise applications? What would currently hinder SUSE to do that? Legacy heaps of legacy, SUSE's enterprise customers do not want to be forced to make more changes then they need, swapping the underlying distro would probably cause most customers to consider other alternative distro's, I really don't see this ever happening.

Ok. I am not saying it is what will happen, more as an interesting thought. In this sense, let me play the devils advocate: The "underlying distro" is becoming more and more commodity, nothing SUSE can differentiate from others big times any more. Customers loose interest in the base since years. So why not joining the big community of people doing deb based base systems with less people and concentrate with a bigger number of developers on the enterprise apps that do differentiate?

I feel there is nothing wrong with your 'devils advocate' approach. While it stand by my strong belief in SUSE's stated commitment to openSUSE, I am also of the growing opinion that the execution of that commitment is missing the desired mark on some fronts.

From a 'code/product' perspective, the story around SLE/Leap/Tumbleweed is one which both SUSE and openSUSE can be proud of and is a exemplar of a Company working with an empowered community which I honestly believe more Companies and Projects should aspire towards. SUSE has even codified this way of working in it's formal Open Source Policy, which is a key plank of the companies OpenChain certification: https://opensource.suse.com/suse-open-source-policy.html Yast, OBS, SUSE Manager/Uyuni, there are lots of good examples of SUSE doing things right across the company.

But I do not share such positive views regarding all of SUSE's products. Across significant parts of SUSE's portfolio there is a noticeable absence of any effort to foster the same kind of productive Community+Company collaboration that we are used to in openSUSE. It is my strong personal view that SUSE needs execute better in this regard, for its own benefits as much as for assisting the vibrancy and general good health of the openSUSE Project. And then there is the example of openSUSE Kubic & SUSE CaaSP, a situation I am very closely involved in, and yet have very few positive words to share. One good thing I can say is that it all started with the best of intentions to establish the sort of relationship missing with other SUSE products and do things the right way. Sadly, there have been times working on Kubic I have been requested by SUSE to say publicly things & act in a way which I feel would have compromised not only SUSE & openSUSE's best interests, but also my personal responsibility to always act in a truthful manner when interacting with fellow openSUSE contributors and our upstreams. I will not air dirty laundry in detail here, but needless to say, my faith in SUSEs ability to always do the right thing has been shaken. While I do still believe SUSE's commitments from management, I do not believe that it is possible for an organisation as large as SUSE to always execute on those commitments in the way that it wants to. This statement should not be controversial - if there wasn't truth to it, the role of the Board to communicate communities needs to SUSE would not already exist. So even if I do have faith that SUSE will address the internal issues there, I've become acutely aware of the potential damage openSUSE can be exposed to when things don't work according to plan. It has only been through actions of a few good people in and out of SUSE who have largely mitigated the damage, and continued Kubic going forward in an exceptionally healthy direction. I don't want openSUSE to only be dependant on a few good people to always bail it out when things go wrong - the Project should be structured in a way to minimise the need for such exceptional intervention. I believe introducing an element of formal independence (or 'less dependence') is a good step forward for both openSUSE and SUSE.

...

...

b) Lots of infrastructure topics c) Investments of workforce into the build service for example.

And this is a similar situation, where commitment has not been met by execution. openSUSE is in continual need of investment in terms of both hardware and manpower to "keep the lights on" with it's current infrastructure. openSUSE's guiding principles state SUSE will provide such infrastructure: https://en.opensuse.org/openSUSE:Guiding_principles#Governance I think it is safe to say that SUSE has been unsuccessful in providing openSUSE with sufficient quantities of both. openSUSE suffers from an increasing age and fragility of its infrastructure, and an increased reliance again on the exceptional actions of a few good people, diving in when things go wrong to save the day. Again, I don't want openSUSE to be dependant on such exceptionalism - we need the Project to be able to stand on it's own two feet. In this area openSUSE is even more hamstrung than when looking at the 'code' perspective. With code our contributors have the power to commit what they like and steer openSUSE regardless of SUSE's contributions (or lack thereof). With infra, as openSUSE currently has no legal entity, we are wholly and utterly dependant on SUSE to take legal ownership of any hardware donated to openSUSE. This can complicate any donation of hardware or services to openSUSE, not just in a practical sense (more people to talk to), but in a financial one also. I believe many companies would be far more comfortable donating to an independent charitable body than having to sign over their hardware or services to a commercial entity such as SUSE. In other words, whereas with code openSUSE already enjoys a significant amount of the autonomy it needs in a practical sense, from an infrastructure perspective openSUSE is entirely dependant on SUSE and SUSEs execution is not meeting its stated commitments here. So here, I also feel an element of independence/less dependence on SUSE is best for openSUSE. There is an argument to be made that this will make things 'easier' for SUSE also, a situation I am personally uncomfortable about, because I do not think SUSE's failure to fulfil its commitments in this area should be rewarded by openSUSE making steps to reduce SUSEs needs to fulfil it's commitments. I do have hope that SUSE will be stepping up to address these issues regardless of what openSUSE decides to do regarding independence. I think that is something SUSE should take care of. All of the people involved in the discussions so far are showing a pragmatism which I trust will cut through any emotion which would otherwise risk the best outcomes for all involved. I think that's essential - this shouldn't be an effort driven by emotion, but by pragmatism, seeking to find the best way forward for openSUSE & SUSE. In an ideal world these circumstances should not have arisen, but the Board, the Project, and SUSE, need to act on the realities we live in, not the ideals we hope to reach. Even with that hope, there still "what's best for openSUSE?" echoing in my mind. As openSUSE's patron, SUSE has been owned by many companies before reaching it's current state of independence. While each of those transitions in recent years have been beneficial to openSUSE, and there are no SUSE 'stage changes' on the horizon, the future is unwritten and always brings with it risk that 'next time' might not be so fortuitous. With openSUSE in an imperfect, but healthy and productive relationship with SUSE, now is a better time to structure openSUSE in a way to potentially mitigate any risks the future may hold, rather than waiting for things to be in a state where there is no good way forward.

The vision what openSUSE will do, what it will head for, how it will stay relevant if it loosens the relationship with SUSE

My personal vision is simple. I want both openSUSE and SUSE to be able to have their own cakes and to eat each others. Put bluntly, I want openSUSE to have the legal structures and entities it needs to be able to do it's own things, have it's own infrastructure, run it's own services, raising it's own money. At the same time, I want SUSE to be contributing to openSUSE more heavily than it already does, with more of it's products more engaged with openSUSE's codebases and tooling, with SUSE funding openSUSE at least as much as it does now. Sure, I realise this is a lot to ask, but I not only believe this is possible, but it's best for all involved. A more independent openSUSE with it own money, infrastructure (including some donated by SUSE), should find itself more easily doing what we already do. This will benefit SUSE as long as openSUSE does it right and SUSE continues to work closely and collaborate with openSUSE. In other words - if openSUSE is able to do more on its own, how is that anything but a benefit to SUSE as long as SUSE is still able to take what openSUSE is doing and turn it into something commercially viable? There is nothing that says SUSE needs to formally own openSUSE to productively work with openSUSE. SUSE is "the open open source company" - it should be able to handle it's partner community having a more open relationship than our peers in the Red Hat/Ubuntu worlds.

When you say "we" here, you mean the board, right? Feels strange to me that this kind of important topic is worked through by the board and later be presented to the community. But maybe that is only me.

There is absolutely no way this topic will see any conclusion of any form without significant involvement from the community and (if it comes to it), binding votes from the membership regarding any constitutional change to the Project. At these early stages, I think it's best the Board acts under its "Communicate community interests to SUSE" charter while scoping out the scale, plausibility, and practicality of the options, before presenting them to the community in a more cohesive way for serious consideration. I have trust, faith, and confidence in my board colleagues desires to accurately reflect the needs and desires of the community at large, as they understand them. Meanwhile the Board has been minuting these efforts in it's meetings, and sharing those publicly with the expectation that it _would_ cause discussions like this. Every post in this thread is welcome and helpful, both to inform the discussions, but to help everyone understand where this is coming from so, I hope, we can all find the best solutions going forward. IOW - If you agree or disagree with anything I say in this mail, good, please add your feelings to this debate. That's the best way you can contribute to this part of the Project right now. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Hi, On pią, Apr 19, 2019 at 5:14 PM, Richard Brown <RBrownCCB@opensuse.org> wrote:

DISCLAIMER: As Chairman of the Board, there are times I speak on behalf of SUSE or the openSUSE Board. This is not one of those times. This is a topic which cuts right through my formal responsibilities as openSUSEs Chairman and my longer standing personal commitments to the Project. Therefore I ask that everyone considers what I sahare in this thread as my own personal view, and should absolutely not be considered to be an official view of SUSE or the Board. That said, I know what I say is obviously informed by my unique position, so risk being interpreted with extra weight. I want to make sure the parties I work most closely with have an opportunity to correct, elaborate, or respond to anything I say. As I expect the Board are all here I don't have to worry about them, but I'm CCing Thomas Di Giacomo (President of Engineering, Product and Innovation @SUSE) so he knows what's being said here and can either step in to speak on behalf of SUSE or prompt me if I need to speak in a more formal capacity.

...

...

SUSE has also given a commitment that they will continue to provide openSUSE with all the core infrastructure they need for shipping releases and have reaffirmed this position to the board in recent weeks. Ok. Is there a public statement from SUSE about that? It's cool that somebody from SUSE told the board something, but how valuable is that in the moment where SUSE is changing owner again? That is why I think the board should try to get SUSE to make public statements about these things.

When EQT purchased SUSE, the Board didn't need to do anything to get SUSE to reaffirm that commitment; SUSE's CEO contacted me directly (waking me up early in the morning on a vacation day no less) so I could provide such a statement on SUSE's behalf personally to the community.

https://lists.opensuse.org/opensuse-project/2018-07/msg00000.html

This commitment has been repeated and reaffirmed at every opportunity, in both formal and informal settings, pretty much whenever anyone from SUSE's executive ever mention the words 'openSUSE'. If I relayed them all to the mailinglists, I expect people would get bored.

There are many factors at play here (which I fear I delve into in excessive detail below), but I personally do not have a shred of doubt regarding SUSE's senior management commitment to openSUSE.

Let's go back in time, far far before all this happened, and explore the darkest scenario. Novell's commitment to openSUSE didn't stop them from signing agreement with Microsoft, which was not well recieved in the community. There are some decisions which might seem like a good idea from "this will benefit openSUSE" PoV, but at the same time are "this will hurt other communities about which we care". Community after all are not just openSUSE evangelists, they are people, which contribute to stuff not only within the project, but also to the entire ecosystem of communicating vessels of open source software. I would like to understand, because I know it's impossible to go out into community and ask about an agreements before they are finalized, openSUSE elects a board, is there a policy to talk about such potential topic with them?

...

...

...

There would be topics enough to discuss I think, and to try to get real commitments from SUSE. A few examples:

a) Commitment to keep openSUSE as base distro for SUSE's enterprise products. How would openSUSE look like if SUSE suddenly jumps on a deb based distro to ship interesting enterprise applications? What would currently hinder SUSE to do that? Legacy heaps of legacy, SUSE's enterprise customers do not want to be forced to make more changes then they need, swapping the underlying distro would probably cause most customers to consider other alternative distro's, I really don't see this ever happening.

Ok. I am not saying it is what will happen, more as an interesting thought. In this sense, let me play the devils advocate: The "underlying distro" is becoming more and more commodity, nothing SUSE can differentiate from others big times any more. Customers loose interest in the base since years. So why not joining the big community of people doing deb based base systems with less people and concentrate with a bigger number of developers on the enterprise apps that do differentiate?

I feel there is nothing wrong with your 'devils advocate' approach. While it stand by my strong belief in SUSE's stated commitment to openSUSE, I am also of the growing opinion that the execution of that commitment is missing the desired mark on some fronts.

From a 'code/product' perspective, the story around SLE/Leap/Tumbleweed is one which both SUSE and openSUSE can be proud of and is a exemplar of a Company working with an empowered community which I honestly believe more Companies and Projects should aspire towards. SUSE has even codified this way of working in it's formal Open Source Policy, which is a key plank of the companies OpenChain certification: https://opensource.suse.com/suse-open-source-policy.html Yast, OBS, SUSE Manager/Uyuni, there are lots of good examples of SUSE doing things right across the company.

But I do not share such positive views regarding all of SUSE's products. Across significant parts of SUSE's portfolio there is a noticeable absence of any effort to foster the same kind of productive Community+Company collaboration that we are used to in openSUSE. It is my strong personal view that SUSE needs execute better in this regard, for its own benefits as much as for assisting the vibrancy and general good health of the openSUSE Project.

Studio is calling, it would like its code open :P

And then there is the example of openSUSE Kubic & SUSE CaaSP, a situation I am very closely involved in, and yet have very few positive words to share. One good thing I can say is that it all started with the best of intentions to establish the sort of relationship missing with other SUSE products and do things the right way. Sadly, there have been times working on Kubic I have been requested by SUSE to say publicly things & act in a way which I feel would have compromised not only SUSE & openSUSE's best interests, but also my personal responsibility to always act in a truthful manner when interacting with fellow openSUSE contributors and our upstreams. I will not air dirty laundry in detail here, but needless to say, my faith in SUSEs ability to always do the right thing has been shaken.

While I do still believe SUSE's commitments from management, I do not believe that it is possible for an organisation as large as SUSE to always execute on those commitments in the way that it wants to. This statement should not be controversial - if there wasn't truth to it, the role of the Board to communicate communities needs to SUSE would not already exist.

So even if I do have faith that SUSE will address the internal issues there, I've become acutely aware of the potential damage openSUSE can be exposed to when things don't work according to plan. It has only been through actions of a few good people in and out of SUSE who have largely mitigated the damage, and continued Kubic going forward in an exceptionally healthy direction. I don't want openSUSE to only be dependant on a few good people to always bail it out when things go wrong - the Project should be structured in a way to minimise the need for such exceptional intervention.

I believe introducing an element of formal independence (or 'less dependence') is a good step forward for both openSUSE and SUSE.

...

...

...

b) Lots of infrastructure topics c) Investments of workforce into the build service for example.

And this is a similar situation, where commitment has not been met by execution. openSUSE is in continual need of investment in terms of both hardware and manpower to "keep the lights on" with it's current infrastructure. openSUSE's guiding principles state SUSE will provide such infrastructure: https://en.opensuse.org/openSUSE:Guiding_principles#Governance I think it is safe to say that SUSE has been unsuccessful in providing openSUSE with sufficient quantities of both. openSUSE suffers from an increasing age and fragility of its infrastructure, and an increased reliance again on the exceptional actions of a few good people, diving in when things go wrong to save the day. Again, I don't want openSUSE to be dependant on such exceptionalism - we need the Project to be able to stand on it's own two feet.

Heroes are doing what they can to improve the state, but that's absolutely true, worst of all, they don't have access to some critical stuff, like bugzilla-o-o, forums-o-o, www-o-o, instead relying on Micro Focus to manage that properly.

In this area openSUSE is even more hamstrung than when looking at the 'code' perspective. With code our contributors have the power to commit what they like and steer openSUSE regardless of SUSE's contributions (or lack thereof). With infra, as openSUSE currently has no legal entity, we are wholly and utterly dependant on SUSE to take legal ownership of any hardware donated to openSUSE. This can complicate any donation of hardware or services to openSUSE, not just in a practical sense (more people to talk to), but in a financial one also. I believe many companies would be far more comfortable donating to an independent charitable body than having to sign over their hardware or services to a commercial entity such as SUSE. In other words, whereas with code openSUSE already enjoys a significant amount of the autonomy it needs in a practical sense, from an infrastructure perspective openSUSE is entirely dependant on SUSE and SUSEs execution is not meeting its stated commitments here.

So here, I also feel an element of independence/less dependence on SUSE is best for openSUSE. There is an argument to be made that this will make things 'easier' for SUSE also, a situation I am personally uncomfortable about, because I do not think SUSE's failure to fulfil its commitments in this area should be rewarded by openSUSE making steps to reduce SUSEs needs to fulfil it's commitments.

I do have hope that SUSE will be stepping up to address these issues regardless of what openSUSE decides to do regarding independence. I think that is something SUSE should take care of. All of the people involved in the discussions so far are showing a pragmatism which I trust will cut through any emotion which would otherwise risk the best outcomes for all involved. I think that's essential - this shouldn't be an effort driven by emotion, but by pragmatism, seeking to find the best way forward for openSUSE & SUSE. In an ideal world these circumstances should not have arisen, but the Board, the Project, and SUSE, need to act on the realities we live in, not the ideals we hope to reach.

Even with that hope, there still "what's best for openSUSE?" echoing in my mind. As openSUSE's patron, SUSE has been owned by many companies before reaching it's current state of independence. While each of those transitions in recent years have been beneficial to openSUSE, and there are no SUSE 'stage changes' on the horizon, the future is unwritten and always brings with it risk that 'next time' might not be so fortuitous. With openSUSE in an imperfect, but healthy and productive relationship with SUSE, now is a better time to structure openSUSE in a way to potentially mitigate any risks the future may hold, rather than waiting for things to be in a state where there is no good way forward.

I see you finally read my initial email starting this whole thing, nice :P

...

The vision what openSUSE will do, what it will head for, how it will stay relevant if it loosens the relationship with SUSE

My personal vision is simple. I want both openSUSE and SUSE to be able to have their own cakes and to eat each others. Put bluntly, I want openSUSE to have the legal structures and entities it needs to be able to do it's own things, have it's own infrastructure, run it's own services, raising it's own money. At the same time, I want SUSE to be contributing to openSUSE more heavily than it already does, with more of it's products more engaged with openSUSE's codebases and tooling, with SUSE funding openSUSE at least as much as it does now. Sure, I realise this is a lot to ask, but I not only believe this is possible, but it's best for all involved.

A more independent openSUSE with it own money, infrastructure (including some donated by SUSE), should find itself more easily doing what we already do. This will benefit SUSE as long as openSUSE does it right and SUSE continues to work closely and collaborate with openSUSE. In other words - if openSUSE is able to do more on its own, how is that anything but a benefit to SUSE as long as SUSE is still able to take what openSUSE is doing and turn it into something commercially viable?

There is nothing that says SUSE needs to formally own openSUSE to productively work with openSUSE. SUSE is "the open open source company" - it should be able to handle it's partner community having a more open relationship than our peers in the Red Hat/Ubuntu worlds.

Let's rag on openSUSE for a second here. YaST on Fedora/Ubuntu when? In all seriousness, there is a fair share of software, developed by openSUSE has not been fully beneficial to other distributions, which is a shame. There is a visible group of people that would be happy to be able to run OBS on Fedora or Debian, but they can't do that with latest version, because it requires heavy patch work. Solution to that is *fairly* easy, copy openQA packaging: * put OBS in %_datadir and %_libexecdir (this differs for Fedora in this case, to be /usr/libexec and not Debian's/openSUSE's /usr/lib), allow to change all of this at build time * have a working rpmspec for Fedora as well as openSUSE (alright, this is harder, especially since SUSE/openSUSE specs have some obsession with backwards compat with sysv macros, and ends up defining own macro in the spec, instead of using systemd one, which is way more cross distro) * allow ruby packaging to not be that version precise, because Fedora packages gems and openSUSE bundles gems for OBS specifically * test other distros while developing OBS But why? It encourages to contribute to the software which you can run on you favourite distro afterwards :D Then there is a topic of YaST, which I feel like I should just leave for another time, too much stuff. In both cases only fragments of openSUSE software have been somewhat useful to other distros, libyui to Manatools and obsbuild to Fedora (and OBS 2.7 as a whole to Debian, but that required quite a bit of work to get there, and was dropped rather quickly when it didn't prove useful enough with their process).

...

When you say "we" here, you mean the board, right? Feels strange to me that this kind of important topic is worked through by the board and later be presented to the community. But maybe that is only me.

There is absolutely no way this topic will see any conclusion of any form without significant involvement from the community and (if it comes to it), binding votes from the membership regarding any constitutional change to the Project.

I feel like everybody should just read documentation on Foundation from back in the day. There are a bunch of drawbacks, which will most likely come up as we go along with all this. And keep in mind openSUSE contains a trademark inside of its name, I wonder how that will go :/

At these early stages, I think it's best the Board acts under its "Communicate community interests to SUSE" charter while scoping out the scale, plausibility, and practicality of the options, before presenting them to the community in a more cohesive way for serious consideration. I have trust, faith, and confidence in my board colleagues desires to accurately reflect the needs and desires of the community at large, as they understand them. Meanwhile the Board has been minuting these efforts in it's meetings, and sharing those publicly with the expectation that it _would_ cause discussions like this. Every post in this thread is welcome and helpful, both to inform the discussions, but to help everyone understand where this is coming from so, I hope, we can all find the best solutions going forward.

IOW - If you agree or disagree with anything I say in this mail, good, please add your feelings to this debate. That's the best way you can contribute to this part of the Project right now.

LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On sob, Apr 20, 2019 at 8:30 PM, Richard Brown <RBrownCCB@opensuse.org> wrote:

On Sat, 20 Apr 2019 at 00:24, Stasiek Michalski <hellcp@opensuse.org> wrote:

...

Let's go back in time, far far before all this happened, and explore the darkest scenario.

Let's not - 2011 was not a happy time, 2019 is.

https://www.youtube.com/watch?v=MvTm3FG_vKs

...

Novell's commitment to openSUSE didn't stop them from signing agreement with Microsoft, which was not well recieved in the community. There are some decisions which might seem like a good idea from "this will benefit openSUSE" PoV, but at the same time are "this will hurt other communities about which we care". Community after all are not just openSUSE evangelists, they are people, which contribute to stuff not only within the project, but also to the entire ecosystem of communicating vessels of open source software. I would like to understand, because I know it's impossible to go out into community and ask about an agreements before they are finalized, openSUSE elects a board, is there a policy to talk about such potential topic with them?

There is no formal policy, nor do I think it would be nice if we had one.

SUSE should not need to "seek permission" from openSUSE to conduct it's business. Inversely, openSUSE should not need to "seek permission" from SUSE to conduct it's business.

The status quo that we live in today is that neither SUSE nor openSUSE has any formal need to inform the other of any new activities. Obviously, we're partners and we act as such, and so there is an expectation that if there is any action, on either side, which risks impacting the other, such talks are had.

eg. SUSE contacting openSUSE to assuage concerns when the EQT deal was announced (and the HPE deal, and the Micro Focus deal..) openSUSE did the same when the Project merged Tumbleweed/Factory. And you can see the coming together of efforts that launched Leap as both an example of SUSE informing openSUSE, or openSUSE informing SUSE, depending on your point of view (both are equally valid).

Yes, but majority of SUSE business doesn't (and shouldn't) affect openSUSE directly, except the obvious, openSUSE relying on SUSE's business performance with founding events and infrastructure. My worry is that back in the days a lot of moves, which affected openSUSE Project directly, were done without openSUSE's best interest (or with projected best interest turning into quite the opposite). I'm glad we are able to work together, but working together is not the entire story. It is the consideration of the darkest timeline, not the current timeline.

...

...

But I do not share such positive views regarding all of SUSE's products. Across significant parts of SUSE's portfolio there is a noticeable absence of any effort to foster the same kind of productive Community+Company collaboration that we are used to in openSUSE. It is my strong personal view that SUSE needs execute better in this regard, for its own benefits as much as for assisting the vibrancy and general good health of the openSUSE Project.

Studio is calling, it would like its code open :P

Studio is no longer sold commercially by SUSE, with customers directed towards using the same OBS w. Studio Express we are lucky to have on https://build.opensuse.org

I'm doing what I can to get old Studio opened; it requires a lot of work to clean up the code suitably for release - and it's not easy to get volunteers for that effort when the pool of people who know the code is tiny, and understandably they'd rather people know and use their fresh open code in Studio Express instead of the old stuff.

And while SUSE of course has it's heart in the right place, it's hard to justify spending actual person-hours on something which has and will never again have any commercial benefit what-so-ever.

I was joking there, I understand open sourcing code that has been abused for years won't be easy, and that nobody really cares about it. While Studio Express in OBS has been improving, it will never be able to be a 1:1 to what Studio was, because it's, quite rightfully, not the goal of the team.

...

...

Again, I don't want openSUSE to be dependant on such exceptionalism - we need the Project to be able to stand on it's own two feet.

Heroes are doing what they can to improve the state, but that's absolutely true

The Heroes are a few, and exceptionally good at what they do, working in difficult circumstances. I said, I don't want openSUSE to be dependant on such exceptional few.

...

worst of all, they don't have access to some critical stuff, like bugzilla-o-o, forums-o-o, www-o-o, instead relying on Micro Focus to manage that properly.

Indeed, but all the incidents tracked since at least December on status.opensuse.org involve systems that don't rely on MicroFocus. I know it's always tempting to point fingers at a more distant, less communicative, less involved supporter than SUSE who we all work with closer, but MicroFocus have done a very good job of keeping openSUSE's lights on. We suffered next to no disruption during the transition of SUSE's ownership from MF, which really should be considered positively.

That was not my point, I just wanted to point out that even if they wanted to, Heroes are not capable of doing everything in the openSUSE infra.

...

Let's rag on openSUSE for a second here. <snip: lots of suggestions>

...

But why? It encourages to contribute to the software which you can run on you favourite distro afterwards :D

No it doesn't - something built in OBS for Fedora or Ubuntu isn't magically suddenly available for openSUSE. Other distributions have other standards (I would argue lesser ones), and we shouldn't compromise openSUSE's quality needlessly.

I mean, that's a fair point, but what if Fedora had an official instance interconnected with openSUSE instance. New Fedora releases could be available quicker in our OBS, and vice versa. It would relieve some load off of openSUSE instance, but would cause more software to pop up for Fedora in their instance. The structure of OBS is quite literally made to span across a few projects. Federating software-o-o between a few (interconnected) instances is an idea I have already tried exploring, and I am still heavily considering adding support for it. About openSUSE quality, I would on the other hand argue that applications should go to /usr directory and not /srv, which should be reserved for user's websites instead. It's a neat structure, which this packaging (of OBS, Nextcloud etc.) needlessly complicates. I understand packaging of openQA for other distros was a pain in the ass, but it shows a good example of possible portability and usefullness of (open)SUSE solutions in those distros. I feel like the bigger issue here is that there were trials of making OBS work on other distros, but were never considered beyond that. It's almost as if people doing that hard work on porting are afraid of the reaction of OBS team to this kind of submission, even though it would not hurt openSUSE packaging in any way. There is a huge __**BUT**__ here though, it would make SLE11 (general support just ended, still on LTSS support for 3 years) incapable of running OBS due to lack of systemd, and incompatibility of sysv scripts between SLE and RHEL just makes this harder to support fully. But it's impossible to fix the mistakes of the past here...

...

And keep in mind openSUSE contains a trademark inside of its name, I wonder how that will go :/

The people involved in the discussions at this early date have started exploring this issue, and suggestions of some form of legal agreement between SUSE and whatever-form-openSUSE-takes seem to be a possible solution to that problem.

Early days yet though - a lot of the details depend on what the community wants - hence the need to refine the options iteratively.

I'm glad it's being discussed. LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Sun, 21 Apr 2019 01:02:09 +0200 Stasiek Michalski <hellcp@opensuse.org> wrote:

...

...

But why? It encourages to contribute to the software which you can run on your favourite distro afterwards :D

No it doesn't - something built in OBS for Fedora or Ubuntu isn't magically suddenly available for openSUSE. Other distributions have other standards (I would argue lesser ones), and we shouldn't compromise openSUSE's quality needlessly.

I mean, that's a fair point, but what if Fedora had an official instance interconnected with openSUSE instance.

This would - at least for me - impli that Fedora will shut down (or at least use less) their own build system. If you have any contacts to developers/decision makers on Fedora site, I'm happy to jump into the discussion with them.

I feel like the bigger issue here is that there were trials of making OBS work on other distros, but were never considered beyond that.

Let's discuss/see if those trials came from openSUSE people, who tried to convince other distributions from OBS - or real decision makers from other distributions, who tried to get it to work on their distributions?

It's almost as if people doing that hard work on porting are afraid of the reaction of OBS team to this kind of submission, even though it would not hurt openSUSE packaging in any way. There is a huge __**BUT**__ here though, it would make SLE11 (general support just ended, still on LTSS support for 3 years) incapable of running OBS due to lack of systemd, and incompatibility of sysv scripts between SLE and RHEL just makes this harder to support fully.

I guess we have some misunderstanding here. 1) OBS is not an official product While SUSE is using OBS to build his packages and products, OBS is not selled to customers as product on its own. So there is no need for SUSE to do nasty stuff or support OBS to run on old distributions. JFYI: all OBS instances run either on SLE15 or even SLE15-SP1. The worker images run even sometimes Tumbleweed or the latest Leap (15.1 in this regard). This depends more on the reliability (kernel, toolchain) of the distro on different architectures and the needs of the to build packages than anything else. 2) Support for SysVinit is still there for a reason We still have some glitches, if the services are managed via systemd. Especially the "reload" or "restart" handling might be easy for generic services, but sadly not many of the OBS services are generic. Just have a look at the OBS sources and issues in Github - we have some open issues there and working since a while on fixes for them. Feel free to join the discussions there and drive the porting from systemd to sysvinit to a success. 3) Time - the ugly enemy If we had enough time, I'm sure that some of my team members whould try a lot of things. Even to get OBS working on all possible distributions. But I have to admit that the BuildOPS team (FYI: we are responsible for package reviews, help with product building, the SUSE maintenance chain, OBS backend development, PackageHUB, OBS operations and other, non-OBS related stuff) has not enough manpower to spent this time during working hours. So - for me - it is just logical that the SUSE team behind OBS concentrates on the deliverables they have towards their sponsor SUSE. That does not mean that we as developers would not accept merge requests or patches (and indeed, I can show you a lot of patches from other distributions that went into OBS code) - that just means that our focus is not on this task. I have to admit that I did not see a concrete point in your blaming of OBS developers for not being supportive enough (I guess you did not want to blame anyone personally, but please accept that your claims could be interpreted in this way). But I offer my help (and I'm up for personal discussions, if you like) here to clarify any misunderstandings. With kind regards, Lars -- Lars Vogdt <Lars.Vogdt@suse.com> - BuildOPS Engineering Team Lead - SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Sun, Apr 21, 2019 at 12:06 PM Stasiek Michalski <hellcp@opensuse.org> wrote:

On nie, Apr 21, 2019 at 5:11 PM, Lars Vogdt <lrupp@suse.de> wrote:

...

On Sun, 21 Apr 2019 01:02:09 +0200 Stasiek Michalski <hellcp@opensuse.org> wrote:

...

...

...

But why? It encourages to contribute to the software which you can run on your favourite distro afterwards :D

No it doesn't - something built in OBS for Fedora or Ubuntu isn't magically suddenly available for openSUSE. Other distributions have other standards (I would argue lesser ones), and we shouldn't compromise openSUSE's quality needlessly.

I mean, that's a fair point, but what if Fedora had an official instance interconnected with openSUSE instance.

This would - at least for me - impli that Fedora will shut down (or at least use less) their own build system. If you have any contacts to developers/decision makers on Fedora site, I'm happy to jump into the discussion with them.

...

I feel like the bigger issue here is that there were trials of making OBS work on other distros, but were never considered beyond that.

Let's discuss/see if those trials came from openSUSE people, who tried to convince other distributions from OBS - or real decision makers from other distributions, who tried to get it to work on their distributions?

Debian jumped onto OBS train because of clang rebuilds back in the days, although they ultimately decided to keep using their long trusted system of doing everything on developers machines. The old instance that was made for this purpose was since abandoned [1]. Trials of porting didn't come "officially" from distributions, people porting OBS were doing it in their own private time for own purposes of running OBS on their distro, with Fedora those hopes amounted to actual code though [2,3], with GPL's hopes of being useful, without any warranty :P

I've been working on this off and on for the past three years myself. I was inspired by Josef Stribny's work[1] and his effort to get OBS 2.5.0 working on Fedora. Unfortunately, his effort stalled out due to dependency issues and difficulties in adjusting the file paths to be compliant with Fedora FHS (mainly no package content in /srv[2]). I've taken a more gradual approach and started from the bottom of OBS up, so I've packaged and maintain obs-build[3], osc[4], and a number of OBS source services[5][6][7][8]. I'm working on more pieces as I go along, including writing a new spec file OBS itself that is much cleaner and coherent. One of the things on my TODO is to write an OBS source service to work with various Dist-Git servers, including Fedora's[9] and CentOS'[10]. Some of the other required source services for the main OBS are missing licensing content that is required per Fedora packaging guidelines[11], but I hope that situation will eventually resolve itself... I have, in the past, contributed small things to make OBS more palatable within the greater Fedora and CentOS communities, such as the full author identities in changes files, swapping RabbitMQ Perl modules in the backend, and assisting with supporting Fedora in the openSUSE Build Service. I still want to do it, but it's very hard, and it's difficult to get support or assistance from the OBS developers to make this work. I was hoping to be able to make a push for this for OBS 2.10, but I think I won't be able to make it. :( [1]: https://is.muni.cz/th/kq9bs/thesis.pdf [2]: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_no_files_or_dire... [3]: https://apps.fedoraproject.org/packages/obs-build [4]: https://apps.fedoraproject.org/packages/osc [5]: https://apps.fedoraproject.org/packages/osc-source_validator [6]: https://apps.fedoraproject.org/packages/obs-service-download_files [7]: https://apps.fedoraproject.org/packages/obs-service-set_version [8]: https://apps.fedoraproject.org/packages/obs-service-extract_file [9]: https://src.fedoraproject.org/ [10]: https://git.centos.org/ [11]: https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuideline...

...

...

It's almost as if people doing that hard work on porting are afraid of the reaction of OBS team to this kind of submission, even though it would not hurt openSUSE packaging in any way. There is a huge __**BUT**__ here though, it would make SLE11 (general support just ended, still on LTSS support for 3 years) incapable of running OBS due to lack of systemd, and incompatibility of sysv scripts between SLE and RHEL just makes this harder to support fully.

I guess we have some misunderstanding here.

1) OBS is not an official product

While SUSE is using OBS to build his packages and products, OBS is not selled to customers as product on its own. So there is no need for SUSE to do nasty stuff or support OBS to run on old distributions.

JFYI: all OBS instances run either on SLE15 or even SLE15-SP1.

That's a relief to say the least.

...

The worker images run even sometimes Tumbleweed or the latest Leap (15.1 in this regard). This depends more on the reliability (kernel, toolchain) of the distro on different architectures and the needs of the to build packages than anything else.

2) Support for SysVinit is still there for a reason

We still have some glitches, if the services are managed via systemd. Especially the "reload" or "restart" handling might be easy for generic services, but sadly not many of the OBS services are generic. Just have a look at the OBS sources and issues in Github - we have some open issues there and working since a while on fixes for them. Feel free to join the discussions there and drive the porting from systemd to sysvinit to a success.

*sysvinit to systemd

I will gladly take a look, although assuming that it's related to a bunch of perl, I will just end up looking at it for hours without doing much progress.

There have been multiple attempts to port to systemd units. Josef's work is the starting point for the stuff that's in current git master, I believe. Currently, there are issues with how OBS would configure bs_worker services for each architecture, as it can't create/delete the systemd unit and activate it.

...

3) Time - the ugly enemy

If we had enough time, I'm sure that some of my team members whould try a lot of things. Even to get OBS working on all possible distributions.

But I have to admit that the BuildOPS team (FYI: we are responsible for package reviews, help with product building, the SUSE maintenance chain, OBS backend development, PackageHUB, OBS operations and other, non-OBS related stuff) has not enough manpower to spent this time during working hours.

So - for me - it is just logical that the SUSE team behind OBS concentrates on the deliverables they have towards their sponsor SUSE. That does not mean that we as developers would not accept merge requests or patches (and indeed, I can show you a lot of patches from other distributions that went into OBS code) - that just means that our focus is not on this task.

Then again, I am not expecting SUSE to stop doing everything for a month and collectively make everything compatible with every distro out there, because it's unreasonable. Realistically a decision to support another distros should be decided in early stages of development of any code, but I do not think that anybody could have expected OBS to prove itself to be as useful as it currently is.

It kind of is in the hands of the community (not just openSUSE community) to do something about this though.

...

I have to admit that I did not see a concrete point in your blaming of OBS developers for not being supportive enough (I guess you did not want to blame anyone personally, but please accept that your claims could be interpreted in this way). But I offer my help (and I'm up for personal discussions, if you like) here to clarify any misunderstandings.

Because they are not to blame, historically (open)SUSE has not been excellent at sharing technologies. At least not in cases where the work is done in non-standardized environments (like filesystem standards, system inits before systemd etc). This is obviously complaining about ideology, not about actual development or developers of the products, because from where I'm standing, they are doing more than an excellent job.

[1] https://irill8.siege.inria.fr/project/show/Debian:Unstable:Clang [2] https://github.com/OlegGirko/open-build-service/tree/fedora-2.9.5 [3] https://github.com/strzibny/obs-for-fedora

I hold out hope that one day I'd be able to make it happen, but it's hard to do alone... -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Tue, Apr 23, 2019 at 10:46 AM Henne Vogelsang <hvogel@opensuse.org> wrote:

Hey,

On 21.04.19 18:37, Neal Gompa wrote:

...

I still want to do it, but it's very hard, and it's difficult to get support or assistance from the OBS developers to make this work.

What would you say was difficult about it? What stopped you from doing it?

So there are a few major issues that block me from progressing (even with my slow-and-steady bottom up approach): * A good chunk of the OBS source services are missing the appropriate licensing data. I've filed issues on all the ones that are "necessary" for the basic OBS functionality to work. This makes it very difficult to ship in Fedora due to being unable to fulfill the compliance requirements. * OBS sysvinit scripts are not Red Hat/Fedora compatible. Full stop. This means that even though the systemd services don't quite work correctly, they are the only way I can do this. Which is fine, except... * OBS makefiles, packaging, and ruby code are tricky to fix to avoid requiring installing into /srv. This is not allowed in Fedora. Historically, I've received complete apathy over this issue and this is not easily fixable without support from OBS developers. There's also the small matter of different users for web content, but that's not so bad. * The OBS packaging is insane. This part I'm slowly working on fixing by completely rewriting the spec. I will probably contribute a variant of this upstream once it is done, because hopefully it'll be cleaner and saner to maintain. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On wto, Apr 30, 2019 at 1:43 PM, Neal Gompa <ngompa13@gmail.com> wrote:

On Tue, Apr 30, 2019 at 7:02 AM Neal Gompa <ngompa13@gmail.com> wrote:

...

On Tue, Apr 23, 2019 at 10:46 AM Henne Vogelsang <hvogel@opensuse.org> wrote:

...

Hey,

On 21.04.19 18:37, Neal Gompa wrote:

...

I still want to do it, but it's very hard, and it's difficult

to get

...

...

support or assistance from the OBS developers to make this work.

What would you say was difficult about it? What stopped you from doing it?

So there are a few major issues that block me from progressing (even with my slow-and-steady bottom up approach):

* A good chunk of the OBS source services are missing the appropriate licensing data. I've filed issues on all the ones that are "necessary" for the basic OBS functionality to work. This makes it very difficult to ship in Fedora due to being unable to fulfill the compliance requirements.

* OBS sysvinit scripts are not Red Hat/Fedora compatible. Full stop. This means that even though the systemd services don't quite work correctly, they are the only way I can do this. Which is fine, except...

* OBS makefiles, packaging, and ruby code are tricky to fix to avoid requiring installing into /srv. This is not allowed in Fedora. Historically, I've received complete apathy over this issue and this is not easily fixable without support from OBS developers. There's also the small matter of different users for web content, but that's not so bad.

* The OBS packaging is insane. This part I'm slowly working on fixing by completely rewriting the spec. I will probably contribute a variant of this upstream once it is done, because hopefully it'll be cleaner and saner to maintain.

I also forgot to point out an issue that puts a damper on Fedora community usage: the OBS API isn't good enough for me to write a DNF plugin for enabling, disabling, or searching for compatible repositories to use on a build service instance (like the dnf COPR plugin does).

I have two issues open for this: * https://github.com/openSUSE/open-build-service/issues/3153 * https://github.com/openSUSE/open-build-service/issues/3154

And for actually building Fedora packages, this is an important issue: https://github.com/openSUSE/open-build-service/issues/1935

I would go as far as to say that current API overall blocks any usage of OBS for user facing application interactions, every call to API requires authentication by username and password without an option to have a developer API tokens. That has already been an issue for zyp [1] and software-o-o ships with prebaked username and password in the code, which sure seems like a good idea ;) [1] https://github.com/simoniz0r/zyp LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On 19/04/2019 17.14, Richard Brown wrote: ...

IOW - If you agree or disagree with anything I say in this mail, good, please add your feelings to this debate. That's the best way you can contribute to this part of the Project right now.

I agree. -- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.1 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Am 18.04.19 um 09:44 schrieb Vinzenz Vietzke:

Am Mittwoch, 17. April 2019, 22:13:50 CEST schrieb Christian Boltz:

...

== mail hosting using mailbox.org ==

We have an offer from Heinlein / mailbox org to make @opensuse.org mail addresses real mailboxes.

Do our members want this? (Feedback on opensuse-project and @oSC welcome)

First of all: it's a very nice offer from Heinlein!

Nevertheless as a new member I would not use it but prefer the current mail alias pointing to my mailbox. I got two mailboxes (work / personal) and to get yet another one to keep an eye on is just an additional task without benefit for me.

You can still just forward it from there I would expect. So this is not really a blocker (unless there are any privacy concerns about the mail being routed through them before. Wolfgang -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On 18/04/2019 10.33, Vinzenz Vietzke wrote:

Am Donnerstag, 18. April 2019, 09:47:32 CEST schrieb Wolfgang Rosenauer:

...

You can still just forward it from there I would expect. So this is not really a blocker (unless there are any privacy concerns about the mail being routed through them before.

Of course, though this makes their offer a bit pointless.

Don't get me wrong: I'm in no way objecting against mail boxes instead of aliases. I just wanted to give feedback from my personal use case.

Just now I tried to send with my @opensuse.org alias, and apparently it failed. My ISP refuses to send aliased mail, so I had to setup a gmail account to do the sending, and that one is also apparently failing. On the receiving side, on occasion people had to contact me on another address because email sent direct to my opensuse.org address would sometimes bounce because it failed some check or other (aliasing mail breaks some of the antispam methods). These are known issues. The ieee also had an email alias service for members. Not many years ago they converted it to a real mail service hosted by gmail. -- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.1 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Hello, On Fri, 19 Apr 2019 at 08:18, Amey Abhyankar <sco1984@gmail.com> wrote:

Hello,

On Thu, 18 Apr 2019 at 01:44, Christian Boltz <opensuse@cboltz.de> wrote:

...

Hello,

here are the meeting minutes of the 2019-04-02 board meeting. If you prefer the wiki formatting, you can also read them on https://en.opensuse.org/Archive:Board_meeting_2019-04-02

snipped< == mail hosting using mailbox.org ==

We have an offer from Heinlein / mailbox org to make @opensuse.org mail addresses real mailboxes.

Do our members want this? (Feedback on opensuse-project and @oSC welcome)

Yes pls. That will be very useful. Thanks Heinlein for the offer.

I am eager to know the decision/verdict thanks :-)

Regards, Amey.

-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Hello, Am Freitag, 19. April 2019, 15:53:17 CEST schrieb Lars Vogdt:

Am 2019-04-17 22:13, schrieb Christian Boltz:

...

We have an offer from Heinlein / mailbox org to make @opensuse.org mail addresses real mailboxes.

Do our members want this? (Feedback on opensuse-project and @oSC welcome)

So someone will do real paperwork and count all the feedback? - Why is it necessary to collect feedback in this form of the 70's?

I'd be happy to get feedback from _all_ our members ;-) - but in practise I expected to get maybe 10 or 20 answers, and reality in this discussion seems to confirm it ;-)

Sorry for the sarcasm (and thanks that at least the members get asked and someone took the hard work on him), but this sounds too scary for an IT community to ignore. ;-)

;-)

But back to the question: you currently have a 'no' from me.

Not because I don't support the idea in general, but your question is way to general for me to support it without further information.

* What does a mailbox cost? - Who pays for it and what does this person/company get in return? * What is included in the concrete offer? * What does this mean in regards to GDPR? - What data is synced between openSUSE and the Heinlein company? * What happens, if a user don't want an Email? Can he get an alias (or even nothing) instead? * Who is responsible for security (alone this simple question includes a lot of areas)? * Will the board be able to block the user from using his Email (as some users were IMHO blocked in the past from other openSUSE resources like mailing lists or OBS)? * What happens, if a member wants to get deleted? - Or only wants his Email setup deleted? Who is the contact in this case? * What happens, if a member violates rules from mailbox.org? * What happens, if a user dies / does not react any longer? * Who is the technical contact? - An openSUSE Hero or someone from Heinlein? * How long is this offer from Heinlein provided? * What happens, if Heinlein switches their mind and want to get paid? * ... (I've of course more questions, but I guess you understand that most of them have to do with the relationships between an openSUSE member, the openSUSE community/board/heroes and Heinlein as sponsor)

Answering all these questions might be a lot of work - and you might end up with not implementing it at all if the majority of your users is either against it or abstain from it.

Thanks for playing [1] devil's advocate ;-) and all these questions. I'll give you a collective answer: We have this offer since quite a while (you probably remember it), but for various reasons working on it was delayed. Now we wanted to tell our members about it before we spend (or possibly waste, if nobody wants it) time on it. This also means that there are still some open questions we'll have to check and answer. To name a few things (note that this reflects my personal opinion because we didn't discuss these details in the board or heroes yet) - aliases will stay the default, the mailbox should be opt-in (everything else would lead to "dead mailboxes" with unread-forever mails) - Heinlein / mailbox.org should become the primary mail server for opensuse.org (= DNS MX entry) because that would give us better spam filtering/blocking (sorry to say that, but the spam filter on mx*.suse.de is far from perfect) - obviously, this also means Heinlein will need/get a list of all @opensuse.org mail addresses and their alias target. (In theory we could avoid giving them the alias targets, but that would mean to a) not have their spam filter or b) to continue to have the aliases on mx*.suse.de and relaying the mails over it or c) setting up a mailserver in the openSUSE infrastructure that does the alias forwarding. I have to admit that I dislike all of these options because they add an additional and IMHO superfluous step.) I know this doesn't answer all your questions - which isn't surprising because we still have to discuss and decide about them ;-)

With that last sentence in mind, I like to get the following four answers first, before starting to discuss the other questions above:

1) What is the concrete benefit of providing a (free?) mailbox for every openSUSE member?

- aliases / forwarding can break thanks to SPF, leading to mail loss (SPF is broken by design, but sadly even some big mail providers use it.) - all members can finally _send_ mails using their o.o mail address, not only the lucky ones with own servers or providers that allow sending with "foreign" sender addresses

(Do we get more members? Does Heinlein get more users/user data for marketing?)

I know Per Heinlein personally, and I'm quite sure he or his company does not look for new "marketing victims" ;-) And no, I don't really expect that we get more members just because we start to offer mailboxes.

2) How many members currently complain about "missing mailboxes" at all? (all that paperwork for just one member?)

I remember several people asked for real mailboxes and/or being able to send mails using the o.o address and/or reported problems with the alias like SPF fun. (Sorry, no exact numbers. There's clearly more than one, but I'm too lazy to go through the ticket archive to count them ;-)

3) And what would this member offer in return if she gets such a mailbox? (not really fair, as members normally did already enough for openSUSE, but if she wants it, what in turn would she offer for all this extra work?)

We won't put that as a "price tag" on the mailboxes or any other membership perks because they are a "thank you" for the contributions. Of course - and independent from mailboxes, IRC cloak etc. - additional contributions are always welcome ;-) (Speaking of IRC cloaks: whoever is a member and didn't get his/her IRC cloak yet, please send a mail with your IRC nickname and openSUSE username to admin (at) opensuse.org.)

4) Who will implement the needed scripts or do the manual work to manage the members mailboxes? (and does this lucky guy already know about this?)

Another "detail" we didn't discuss yet - but if needed, I'm willing to help with it. Having better spam blocking (in my case I'm especially interested in admin@o.o) is more than worth it, and more fun than deleting ticket spam all the time ;-) Regards, Christian Boltz [1] I know you - and wonder if I should say "being devil's advocate" instead ;-) --

Isn't suse moving to systemd? There is very little ascii text about that, Yes, it's completely irrelevant, because systemd does not read mail (yet). [> Linda Walsh and Jan Engelhardt in opensuse-factory]

-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Gesendet: Sonntag, 21. April 2019 um 12:33 Uhr Von: "Christian Boltz" <opensuse@cboltz.de> An: opensuse-project@opensuse.org Betreff: Re: [opensuse-project] 2019-04-02 board meeting minutes

Hello,

Am Freitag, 19. April 2019, 15:53:17 CEST schrieb Lars Vogdt:

...

Am 2019-04-17 22:13, schrieb Christian Boltz:

...

We have an offer from Heinlein / mailbox org to make @opensuse.org mail addresses real mailboxes.

Do our members want this? (Feedback on opensuse-project and @oSC welcome)

So someone will do real paperwork and count all the feedback? - Why is it necessary to collect feedback in this form of the 70's?

I'd be happy to get feedback from _all_ our members ;-) - but in practise I expected to get maybe 10 or 20 answers, and reality in this discussion seems to confirm it ;-)

Then 1++ :-) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Le dimanche 21 avril 2019 à 05:56:29, Lars Vogdt a écrit :

On Sun, 21 Apr 2019 12:33:21 +0200 Christian Boltz <opensuse@cboltz.de> wrote:

...

This also means that there are still some open questions we'll have to check and answer.

Absolutely understandable - and I just wanted to add the basic questions above for some "impressions" about what needs to be clarified.

Especially with GDPR and all latest changes, I salute you to your courage to open this can of worms! :-)

About GDPR itself, I guess that in such case, the email provider is responsible for providing a GDPR compliant service. So would not this option put a lesser burden on openSUSE if the project don't have to deal with it ?

...

- obviously, this also means Heinlein will need/get a list of all @opensuse.org mail addresses and their alias target.

Why does this need to happen?

If I remember correctly, Heroes complaint about the complexity of the openSUSE mail system already (because it is connected to the SUSE development/testing mailsystem) - now you want to move it to another company. How does this make things easier?

Does "reaching independence from SUSE" means being independent from any help ?

I would in turn recommend to start with the final separation of the openSUSE infrastructure from SUSE: 1) setup/register your own offical DNS servers (as you have the internal ones already, this should not be that complicated) 2) setup own MX server (you can clone the mx.suse.de ones, if you like) 3) speak with MF-IT about the forums, blogs and authentication stuff

=> each of these steps is independent. But with 1 & 2 the openSUSE heroes would have the full flexibility to look at the Mailsystem or any other new service in their timeframe and with their power.

I share the views espressed above as I see the benefits of being fully self hosted and have the full control of our infrastructure. On the other hand, it will a) require a lot of manpower which is a limited ressource, b) seems a bit like reinventing the wheel when we have someone (that apparently some members here seems to trust) that is willing to help. -- Sébastien 'sogal' Poher -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Hello, Am Sonntag, 21. April 2019, 17:56:29 CEST schrieb Lars Vogdt:

On Sun, 21 Apr 2019 12:33:21 +0200 Christian Boltz wrote: ...

...

To name a few things (note that this reflects my personal opinion because we didn't discuss these details in the board or heroes yet) - aliases will stay the default, the mailbox should be opt-in (everything else would lead to "dead mailboxes" with unread-forever mails)

- Heinlein / mailbox.org should become the primary mail server for opensuse.org (= DNS MX entry) because that would give us better spam filtering/blocking (sorry to say that, but the spam filter on mx*.suse.de is far from perfect)

Do you have some comparable numbers? How much spam is detected in a better way by Heinlein than by mx.suse.de? Could it be that mx.suse.de is only tagging spam and not deleting it because of legal rules?

Last time I asked (maybe a year ago), the answer was that mx.suse.de only filters out viruses, but doesn't block spam (or maybe "tags" it, but that's useless, especially for the @o.o aliases). Regarding the legal rules - there is exactly one sane way: the mailserver has to _reject_ mails at the front door (instead of accepting and then maybe tagging them). Such a reject means the sending server can (and has to) send a non-delivery notice to the sender. Most important: the sending server stays responsible because mx.suse.de never accepted the mail. (In case of a false positive, the sender can try to re-send the mail or reach out in other ways, maybe even phone or fax if it's about something really important.) Once you accept a mail, you are legally "lost". The sender has a confirmation that the mail was accepted, and of course you are not allowed to delete it. The only remaining option is to deliver it to the recipient. Tagging is possible, but typical users never look into their spam folder, so tagging and moving to the spam folder is not too different from deleting the mail. (Imagine what happens if an important and urgent mail bitrots in the spam folder. The sender will happily show you the mail log that says "250 accepted for delivery"...) I never used mailbox.org myself (I have my own server), but I'm quite sure Heinlein does reject spam mails.

...could it be that admin@o.o gets some special handling because of some historic settings?

Some people on opensuse-de complained about spam relayed via their o.o address recently, so I'd say it's unlikely that only admin@ lacks spam protection.

...

- obviously, this also means Heinlein will need/get a list of all @opensuse.org mail addresses and their alias target.

Why does this need to happen?

If I remember correctly, Heroes complaint about the complexity of the openSUSE mail system already (because it is connected to the SUSE development/testing mailsystem) - now you want to move it to another company. How does this make things easier?

It won't change much regarding complexity, but we'd have a better mail service (mailboxes, better spam filtering) for our members.

I would in turn recommend to start with the final separation of the openSUSE infrastructure from SUSE: 1) setup/register your own offical DNS servers (as you have the internal ones already, this should not be that complicated) 2) setup own MX server (you can clone the mx.suse.de ones, if you like) 3) speak with MF-IT about the forums, blogs and authentication stuff

=> each of these steps is independent. But with 1 & 2 the openSUSE heroes would have the full flexibility to look at the Mailsystem or any other new service in their timeframe and with their power.

I run a few mailservers, and know the work that needs to be done. That also means I'm not too keen to run another one ;-) 1) probably isn't too hard, but still needs someone to do the work. (Luckily we already have full control about what the nameservers deliver, we "just" don't run the public nameservers ourself.) 3) is a _big_ can of worms. I'll be very happy when it is done, but also know it won't be easy.

...

(In theory we could avoid giving them the alias targets, but that would mean to a) not have their spam filter or b) to continue to

have the aliases on mx*.suse.de and relaying the mails over it or

c) setting up a mailserver in the openSUSE infrastructure that does the alias forwarding. I have to admit that I dislike all of these options because they add an additional and IMHO superfluous step.)

Well, with aliases as default, mailing lists and administrative accounts (like {post,web,mail}master@o.o, admin-auto@o.o, ...) and all the different (sub-)domains (like opensuse.de for example), I'm really not sure if your solution is really the more easy one to implement.

I instead would vote for c, as my former comment already implied. And I guess I'm not alone with these "independence" ambitions, if I read the other mails in this thread.

In turn, I'm wondering how this matches: while some board members want more independence from SUSE, you try to push an important communication channel under a new umbrella - to a company that has not much to do with openSUSE at all.

Independence doesn't necessarily mean not to depend on anybody (that's probably impossible). IMHO spreading across multiple sponsors already is better than having one "big" sponsor.

I do the same. But what happens if Heinlein get's aquired by another company or Peer (yes: two 'e') steps back from his position?

In worst case, we have to find another sponsor for a mailserver, or to setup an own server.

...

...

2) How many members currently complain about "missing mailboxes" at all? (all that paperwork for just one member?)

I remember several people asked for real mailboxes and/or being able to send mails using the o.o address and/or reported problems with the alias like SPF fun. (Sorry, no exact numbers. There's clearly more than one, but I'm too lazy to go through the ticket archive to count them ;-)

So let's wait for the amount of feedback to your request and wait with further discussions until we reached a deadline (that you should still define)?

The initial mail already mentioned oSC, so I'd say that will be the deadline - but that shouldn't stop anybody from speaking up on the mailinglist ;-)

...

...

4) Who will implement the needed scripts or do the manual work to manage the members mailboxes? (and does this lucky guy already know about this?)

Another "detail" we didn't discuss yet - but if needed, I'm willing to help with it. Having better spam blocking (in my case I'm especially interested in admin@o.o) is more than worth it, and more fun than deleting ticket spam all the time ;-)

What I take from this: From your point of view, the main reason to move all member Email accounts (as this is what you told earlier with "Heinlein will manage the aliases) to Heinlein is a better spam filtering for one Email address named admin@o.o. Right?

That's the devil's advocate summary ;-) and at the same time my personal motivation, probably shared by all Heroes who have to delete several spam tickets a day. (Since I run my own server, I don't care too much about having a mailbox ;-) I also see the benefit for several members because they'll get real mailboxes and can finally send mails using their @o.o address.

Trying to summarize

Benefits when moving from SUSE to Heinlein: * better spam tagging, done by Heinlein who get all @o.o Emails

s/tagging/rejecting/, see above

* possibility to sent with an <alias>@o.o Email address * openSUSE could blame Heinlein if something is broken * Heinlein could blame the Heroes if something is broken (heya: ping pong)

;-)

Benefits when providing an own MX: * spam tagging can be done with openSUSE packages on openSUSE machines

and again - s/tagging/rejecting/

* everything else can be done with openSUSE packages on openSUSE machines (someone might even create some docu around it?) * members could be able to use their account data to sent with <alias>@o.o via the new MX after authentication * openSUSE could only blame the overloaded Heroes (or packagers) if something is broken

;-)

In any of the two options, the current setup (including connect.o.o) needs to be adjusted.

Right.

...

[1] I know you - and wonder if I should say "being devil's advocate" instead ;-)

I hope I did my job right with my answers above ;-))

Yes ;-) Regards, Christian Boltz -- Ich sehe schon, die meiste manpower des Projektes fließt derzeit in die Gestaltung der "--help"-Option. Ich glaube, wir greifen den Vorschlag von Christian auf und richten mehrere Hilfsseiten ein. Gleicher Inhalt, andere Formatierung. :-))) [Ratti in fontlinge-devel] -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org