In the new fedora.next world, several working groups have been considering the idea that they may have different release or support cycles. FESCo should gather input from working groups and decide:
We may want to defer this ticket until we hear more from working groups.
At the moment, I would actually like to say No to the first two of those for at least the first two releases producing the three products. Releng, infra, qa, design, docs, marketing etc are going to have a whole lot of adjustment and ironing out to deal with in that time period.
However, we should start collecting information about what release and support cycles the working groups would like to try out and then collect information from releng, infra, etc about (1) whether it would be impossible and (2) assuming that it's not impossible, what they'd need in order to make it managable on their end. I anticipate that a large part of what they would need would be reliable additional manpower working under their direction. However, there's probably other, process concerns that they'd raise as well (for instance, infrastructure freezes before alpha, beta, and final release so that nothing from their end interferes with fixing blocker bugs or delivering the product on release day. Those freezes may no longer be possible if releases by the various products became staggered to one per month. Similarly, mass rebuilds, incompatible package updates, mass branching, string freeze, and the FESCo Change Deadlines would need to be reworked, abandoned, or declared as insurmountable blockers to supporting different release cycles).
I'm definitely more than happy to help with redefinition of release schedules/life-cycles, as a current schedule owner.
As different products aims different target audience and different usecases, some sort of flexibility should be granted for them but with a common denominator - preferably coming from the Base WG. Also resources should be considered - from tooling (for example on releng/QA sides) to actual man power.
The first step should be to gather the requirements on the release schedules and lifecycles from the Server/Cloud/Workstation (probably EnvStacks too) WGs and share these requirements with the Base WG.
And at least in the beginning, there should be more extensive communication between WGs and other relevant teams. We already touched it on the Base WG meeting - maybe setting up one meeting, where representatives of WGs and other teams could share their opinions on one place and summ up what they are working on as it's nearly impossible that everyone is able to follow everything. I know, another meeting - we already have too many ;-) - but after January, frequency of these meeting could be approx. once per month to sync. Going back to the idea of Fedora Council?
My suggestion for the Base release schedule and life-cycle https://fedoraproject.org/wiki/User:Harald/base-schedule
IMHO, I think we should not allow different cycles (at least at first). We already have tons of work and different cycles would be vastly more. Any proposal for differing release cycles would need to take into account at least (just off the top of my head):
(infra) we would need to figure out how to do freezes before releases. If we are doing one a month, we would pretty much be frozen the entire time, slowing down things a great deal. If we don't freeze we could risk changes destablizing things for some products release.
(infra) If we are releasing from different collections of packages we would need a bunch more hardware to compose and store those collections.
(maintainers) we freeze updates before releases to stablize things and only allow blockers/fe packages in. If we did that before every product release and they happened often, it would slow down things for maintainers.
(marketing) if we release 'fedora' at once we can get press coverage and reviews and 'buzz' in social media. If we release a different product every month I suspect many outlets will start pushing that to a back page and it will be hard to sustain 'buzz' (oh, fedora released another thing this month, ho hum).
(qa) qa would need to rework blocker/fe process to handle blockers/fe for each different product.
(qa) qa would never get time to work on automation and frameworks if they were sprinting toward a release every month.
(releng) If we composed from different streams we would need to sign and compose a bunch more/different packages.
(mirrors) If we pushed a bunch of different content to mirrors we might go past our promise of keeping current Fedora releases under 1TB, making some of them drop Fedora or some subsets there of.
and there's tons more.
In any case I think we should decide on a release/support cycle for "Fedora" for now for all products and then in a year or so after we have released something we can revisit decoupling.
Replying to [comment:5 kevin]:
IMHO, I think we should not allow different cycles (at least at first). We already have tons of work and different cycles would be vastly more. Any proposal for differing release cycles would need to take into account at least (just off the top of my head): ''[ ...snip... ]'' In any case I think we should decide on a release/support cycle for "Fedora" for now for all products and then in a year or so after we have released something we can revisit decoupling.
We should also consider the possibility of Fedora.next product release cycles that are different but whose timing coincides. For example -- and this is just for sake of argument -- a Server and Cloud product that lands yearly, but Workstation lands each six months, with every other Workstation landing at the same time as Server + Cloud. This seems worth considering beyond the case of completely disjoint schedules.
Replying to [comment:7 pfrields]:
Replying to [comment:5 kevin]: IMHO, I think we should not allow different cycles (at least at first). We already have tons of work and different cycles would be vastly more. Any proposal for differing release cycles would need to take into account at least (just off the top of my head): ''[ ...snip... ]'' In any case I think we should decide on a release/support cycle for "Fedora" for now for all products and then in a year or so after we have released something we can revisit decoupling. We should also consider the possibility of Fedora.next product release cycles that are different but whose timing coincides. For example -- and this is just for sake of argument -- a Server and Cloud product that lands yearly, but Workstation lands each six months, with every other Workstation landing at the same time as Server + Cloud. This seems worth considering beyond the case of completely disjoint schedules.
I agree with Paul. But at first every WG should say what they want to achieve, then we can cut down features, which can't be done because we are missing resources.
I meant to respond to this on Monday but have not been able to work propperly with very limied power and network this week.
My thoughts are that all products must be released on the same day and supported for the same time period.
The reasons are:
1) If we don't ship all products at the same time, we get into a very messy situation with publishing sources and defining what is Fedora.
I see the tree as being {{{ /<release>/Everything/ /Cloud/ /Server/ /Workstation/ /updates/<release>/ /testing/<release>/ }}}
Each of the product release trees would have at a boot.iso, pxe tree and a dvd iso as well. As soon as you try to differ the products ship schedules we fork the distro and we really can not afford that.
2) as soon as we try to EOL a product sooner we will confuse the users is fedora 21 supported or not?
3) we have an agreement to not go over 1T on the mirrors for fedora. right now we are using {{{ du -hs /pub/fedora/ 884G /pub/fedora/ }}}
What i think we can do is support a release for 18-24 months, we can make clear guidelines that state that a product will get new versions of things in the first 6-12 months where the second 6-12 months there will only be fixes for known security updates.
To even think about breaking products into different lifecycles means we need to have different updates streams. which means lots of work in bodhi (which gets next to no support) it also likely means different git branches and build targets. Everything needs a lot more resources.
I think FESCo needs look at the supported life a the products, additionaly they need to make it clear that products can not diverge from it. I am probably forgetting some of my thoughts right now.
I am all for us changing how we support and manage releases, however I do not want us to do it by forking the distribution or causing confusion for users or developers.
Note: I've no thoughts on solving the other issues at this time. Just trying to chip away at blockers to see how close we can come and at what price:
Replying to [comment:13 ausil]:
2) as soon as we try to EOL a product sooner we will confuse the users is fedora 21 supported or not? This could probably be solved by differentiating the brand for each product enough. As very tongue-in-cheek examples we could have: Fuji by Fedora (workstation) OpenQueue Linux (cloud) Sol OS (Server) Nada (Base's Minimal if they decide to produce that)
This could probably be solved by differentiating the brand for each product enough. As very tongue-in-cheek examples we could have: Fuji by Fedora (workstation) OpenQueue Linux (cloud) Sol OS (Server) Nada (Base's Minimal if they decide to produce that)
This is similar to what companies do when they produce several different products... each product gets their own public identity no matter what processes are shared internally to create them. If we went this route, we'd need to involve design, marketing, legal, websites, docs, and infrastructure to determine what to name each of the products, how to create the individual end-user facing identities for them, and what resources they'd need to pull that off.
Since the WG that's specifically asked about different release cycles is the Base Design group, another option might exist where only Base Design's release cycle differs. We make sure that Base Design doesn't produce anything that we consider end-user facing. What Base Design is "producing" is the platform for the other Products to build on. The packages and policies that Base Design cares about would have features coordinated on a certain cycle and the products would be built on that base.
Base Design would probably be fairly free to select their own, consistent release schedule[*] in this plan but the support/maintenance cycle would depend heavily on the schedules of the end-user facing products. The support cycle would have to be such that the platform was supported for as long as the Products built on top of it were supported.
[*]: There would be occasional conflicts where a Product needed a new Feature in Base but the release schedule for Base meant it would be far in the future but that seems like a problem we have even now.
Replying to [comment:14 toshio]:
Note: I've no thoughts on solving the other issues at this time. Just trying to chip away at blockers to see how close we can come and at what price: Replying to [comment:13 ausil]: 2) as soon as we try to EOL a product sooner we will confuse the users is fedora 21 supported or not? This could probably be solved by differentiating the brand for each product enough. As very tongue-in-cheek examples we could have: Fuji by Fedora (workstation) OpenQueue Linux (cloud) Sol OS (Server) Nada (Base's Minimal if they decide to produce that)
which then means we ahve forked the distribution and that is something I am trying to avoid. Im not sure who on the Base WG wants a different schedule, I clearly missed it in the communications so far. As one of the members of the Base WG i really do not want to go down that road.
Time to go back and re read everything.
Replying to [comment:15 ausil]:
It wasn't Base WG specifically but at the first BWG meeting, we tried to identify the needs of other WGs and this was one of the questions as other WGs touched it too. We really have to collect at least the initial requirement and rationales for WGs release cycles as written in the FESCo decision and make sure everyone is on the same page. I'm going to ask WGs to sum it up for Base/FESCo.
Log in to comment on this ticket.