Johann, would you mind specifying what exactly you are asking for? The summary is unclear.

If you're asking for permission to create a new Product, that's really a Board decision.

This is not a request for a new product per say but rather split relevant part that form the core a.k.a layer zero out of base WG into an separated core WG to maintain, manage and release.

Who does or proposes that split is irrelevant but given that FESCo already is micro managing each WG it's stands within reason it falls under it's responsibility to perform. if they cannot I can just as well do that myself.

The components that make up the core layer will need to be limited to the lowest foreseeable shared core denominator between all available/imaginable products which most likely need to be embedded ( unless cloud is smaller then it will set the tone for that core ) because it's not unlikely that it will emerge within the next years.

Something that should be blatantly obvious for those that are driving the .next and the wg effort and this will need to be split out of the baseWG sooner rather then later when it will be to difficult to do ( unless ofcourse the multiple products effort is nothing but an excuse to mutilate Fedora into RHEL 8 next line of Red Hat products and offerings with relevant theatrics surrounding that).

If you and Matt the masterminds behind this are sincerely serious about multiple products then I strongly suggest both of you get together over beer and bbq and since it's now getting closer to summer and start looking how things are moving after what close to year now.

There are few alarming mistakes within and outside the wg's themselves being made some of which will be difficult and expensive ( in terms of community or contributed corporate resources ) to fix later...

Replying to [comment:2 johannbg]:

This is not a request for a new product per say but rather split relevant part that form the core a.k.a layer zero out of base WG into an separated core WG to maintain, manage and release.

It's unclear to me how your proposal isn't ready what the Base WG is for.

Replying to [comment:3 jwboyer]:

Replying to [comment:2 johannbg]:

This is not a request for a new product per say but rather split relevant part that form the core a.k.a layer zero out of base WG into an separated core WG to maintain, manage and release.

It's unclear to me how your proposal isn't ready what the Base WG is for.

Base is the next "common shared product" layer above the core so it never can be equivalent to core and how it's made up is also limited to the smallest denominator on that layer.

And to answer your next question based on my response, how you are defining WG's is one of the fundamental mistake that are being done as in you seem to be basing it's existence on purpose ( and that purpose somehow cannot be overlapped just look at the workstation WG ) which is not the fundamental requirement for product existence.

Replying to [comment:4 johannbg]:

Base is the next "common shared product" layer above the core

I have no idea what that means.

I'm sure you have a full and consistent idea in mind of what is the current situation, what is wrong with it, and what is your proposal, but ''I'' have no idea what you think about these things, and it seems others may have similar difficulty.

Would you perhaps consider giving specific examples of differences between these things, or using a picture? I'm not sure that it would help but perhaps it would be worth trying; the text so far hasn't been enlightening to my dumb self.

Replying to [comment:4 johannbg]:

Replying to [comment:3 jwboyer]:

Replying to [comment:2 johannbg]:

This is not a request for a new product per say but rather split relevant part that form the core a.k.a layer zero out of base WG into an separated core WG to maintain, manage and release.

It's unclear to me how your proposal isn't ready what the Base WG is for.

Base is the next "common shared product" layer above the core so it never can be equivalent to core and how it's made up is also limited to the smallest denominator on that layer.

Ok. So Core is a subset of Base in your view, got it. Could you elaborate on exactly what that subset might be, and why the existing definition of Base isn't already the minimum set of overlapping things needed for a Product?

Why does that need to be a Product? Do you expect to market Core, which you've said is the absolute minimum, as something useful on it's own? What exactly would you produce? Who would you market it to?

As for a Core WG, what would they do here? What activities do you see them performing in the maintenance of Core?

And to answer your next question based on my response, how you are defining WG's is one of the fundamental mistake that are being done as in you seem to be basing it's existence on purpose ( and that purpose somehow cannot be overlapped just look at the workstation WG ) which is not the fundamental requirement for product existence.

Whether basing a Product based on purpose is a mistake is debatable. I'm also unclear as to what you meant with the Workstation comment, but that's not relevant to the discussion. However, I really don't understand what you envision the Core product being.

Replying to [comment:6 jwboyer]:

Replying to [comment:4 johannbg]:

Replying to [comment:3 jwboyer]:

Replying to [comment:2 johannbg]:

This is not a request for a new product per say but rather split relevant part that form the core a.k.a layer zero out of base WG into an separated core WG to maintain, manage and release.

It's unclear to me how your proposal isn't ready what the Base WG is for.

Base is the next "common shared product" layer above the core so it never can be equivalent to core and how it's made up is also limited to the smallest denominator on that layer.

Ok. So Core is a subset of Base in your view, got it. Could you elaborate on exactly what that subset might be,

Already said what controls what it eventual has to be, same thing with the base layer itself.

and why the existing definition of Base isn't already the minimum set of overlapping things needed for a Product?

Look again at what I'm proposing in it you will find the answer to that question or ask yourself this why do you think I'm asking to split out core parts from the base...

Why does that need to be a Product?

More of a platform then a product so it does not have to be but it can be

Do you expect to market Core,

I would not marked core outside the project even thou it could be.

which you've said is the absolute minimum, as something useful on it's own? What exactly would you produce?

It's the zero layer that every other layer is build upon.

Who would you market it to?

see above

As for a Core WG, what would they do here? What activities do you see them performing in the maintenance of Core?

Same as the other since each layer or each product if you prefer to look at it that way, requires the same fundamental requirement to be able to work.

And to answer your next question based on my response, how you are defining WG's is one of the fundamental mistake that are being done as in you seem to be basing it's existence on purpose ( and that purpose somehow cannot be overlapped just look at the workstation WG ) which is not the fundamental requirement for product existence.

Whether basing a Product based on purpose is a mistake is debatable.

I'm all ears and open for your explanation how you intent to make product based on purpose work in the entire distribution in the long run in fact I'm eager to listening to it, I dont mind a fresh angle to think through since what is being done now wont work as a process that claims to be releasing multiple products.

I'm also unclear as to what you meant with the Workstation comment, but that's not relevant to the discussion.

Yes it is very much relevant but your lack of understanding that indicates a bigger problem.

However, I really don't understand what you envision the Core product being.

My envision does not extend beyond the logical needs of us releasing multiple products and implement it in a clear cut efficient manner with as little resource leakage and disruption as possible even thou it will be difficult to achieve since we lack proper distribution tools to be able to do so as I had explained to Stephen at one time but perhaps Bill Notting can explain better to you the problems he has been dealing with all these years in the comps group which should shed some light, to certain extent on the problem we are faced with multiple products since they are similar in nature but ultimately you failing to understand me is irrelevant since it wont change the outcome since the last time I checked you are not part of FESCo which is a bit unfortunate since we as an distribution were better off with you in FESCo than outside it since you and Miloslav Trmač seem to be the only one that have done your FESCo obligation by integrity and honour and came prepared for meetings and asked questions features and such.

So, as usual, I'm kind of guessing at what Jóhann means. But I think that this is at least partly based on the idea of a "ring 0" from my Flock presentation last year (see this slide http://mattdm.org/fedora/next/#27), and possibly a reaction to Phil's comments in http://fedoramagazine.org/fedora-present-and-future-a-fedora-next-2014-update-part-iv-a-base-design/, where he says that the Base Design group is not aiming to make a product.

But mostly, I think this is a case of overreacting to things not going exactly in a certain very specific envisioned way, and yelling that the sky is falling when things just aren't moving fast as desired. As Phil explains in the article I linked, Base Design '''''is''''' set up to cover all of the concerns of both the "Ring 1" ''and'' also includes work on the minimal "ring 0" -- what I think Jóhann is calling "Core OS" here. Overall, I don't think there's anything that a proposed new group would add except confusion. If you (the general "you", to anyone reading!) is interested on improving the minimal core, the Base Design group is a great place to advance that agenda. It's completely in scope, and also clearly something we need.

As an aside, it's really not helpful to continually talk about "alarming mistakes" without articulating exactly what you think those are. (Especially because when actually stated, I suspect that the degree of alarm they're worthy of will be... debatable.) If you have actual specifics, we can work on those.

And, Jóhann: you have a disturbing trend over the past year of claiming to start initiatives, but then demonstrating no ability to follow through. Given that, it's pretty hard to take this seriously.

Yelling the sky is failing just look at what has taken place in the BaseWG, they started within a logical and within reason ( not something I would have approach things but it was valid ) which got thwarted with the other WG's and Phils inability to say no, we have our package set, we have our targets anything that falls outside that scope and you are on your own when they started to do that.

And care to explain in detail between backstabbing and hijackings which disturbing trend over past year to start initiatives have I shown?

This is not something that needs to be discussed on account of me since I'm leaving the project and taking my "disturbing trend" along with it since I'm more of a burden then a benefit to the project once I have gotten hold on Jaroslav and we work out a official announcement of retraction of both the legacy sysv migration and the cron to timer migration features so others can formally file another feature request for those two features and migrate what those 150 components and cleanup the entire 600 - 700 components service units once that is done.

Just keep in the back of your head what I said in comment 5 as well as you should be able to spot quite easily when an layer stops being common or usefully shared immediately when an WG needs to excludes components from it to be able to make up it's product.

Closing based on Jóhann’s request in today’s FESCo meeting.