It's time to take a look on F21 schedule, we discussed it a bit today on #fedora-devel and we agreed to bring it to FESCo meeting. F21 is a bit complicated - there's an on going effort for the 3 products offering and also there was a call to delayed F21. But I have two concerns: one is that the output from WGs is expected in January, so pretty late to be part of even delayed F21 schedule, other is that we did not hear any real proposal why to delay F21 and what would be achieved in that period of time (except QA automation and a few generic todos I'd say).
One option would be to schedule F21 as standard release, normal or bit shorter again and based on the output from WGs, plan F22+ releases the new way. It gives us possibility to have Flock synced with it (it is already under discussion on flock-planning list) before 3-products are started.
Another options is - if we still want to have delayed F21, we can try to have a formal call for proposals to know what we would be able to achieve and for how long it makes sense to prolong the release, based on Changes process for example, I'm willing to help with running it.
Deferred for a week, pending input from tflink and dgilmore.
(Looking for information of specifically how much to delay F21 and specifically what would be the expected outcome.)
There is a few things that I really need to work on.
The biggest is redoing how we compose fedora, It needs to be more streamlined, integrated and simple. I have serious concerns over my ability to deliver everything if and when fedora.next lands. let alone the need to be involved in the development ogf the plans for it so that we can be sure to come up with something that can actually be delivered.
I really want to have a composedb for Fedora to give greater transparency into Releng. I feel that currently it is seen as a black box, requests go in and things come out.
a big part of making things more transparent i want to do all of the releng tasks inside of koji. that is going to take a lot of effort that has not had the time in the last few releases due to zero down time between releases. Id like to work with QA to define APIS for requests.
I'm trying to figure out when this delay might start. Are you looking for a proposal starting as soon as F20 is released or after the fedora.next WG output is expected (january or february)?
I have put together a proposal for what qa automation work we'd be able to accomplish if Fedora 21 is delayed.
https://fedoraproject.org/wiki/User:Tflink/f21_delay_taskbot_development_proposal
Please let me know if you have questions. I plan to be present for tomorrow's meeting
Replying to [comment:3 ausil]:
The biggest is redoing how we compose fedora, It needs to be more streamlined, integrated and simple.
+1 !
I have serious concerns over my ability to deliver everything if and when fedora.next lands.
Fortunately, it doesn't come down to that. It comes down to ''all'' of ''our'' ability together. If you can help define what the needs will be, we can figure out how to meet them.
I have a picture of you sitting, very cramped, inside a very little box. :)
But yes. This needs to change, and I think it's key to the above. It is a black box, but it's human powered, and there's only so much any human can do without burning out. We need to transform the box into a machine -- a well-documented self-powered machine which any number of people can work on.
That sounds awesome and concrete. Can you develop/explain this idea a little bit more? How would it relate to, say, taskbot?
Replying to [comment:6 tflink]:
I have put together a proposal for what qa automation work we'd be able to accomplish if Fedora 21 is delayed. https://fedoraproject.org/wiki/User:Tflink/f21_delay_taskbot_development_proposal Please let me know if you have questions. I plan to be present for tomorrow's meeting
I'm very excited about Phase Y -- I think this is basically a prerequisite.
a big part of making things more transparent i want to do all of the releng tasks inside of koji.
For the record, I have started working on a part of this: running mash in koji.
Discussion for inclusion upstream is still ongoing: https://lists.fedoraproject.org/pipermail/buildsys/2013-September/004158.html https://lists.fedoraproject.org/pipermail/buildsys/2013-October/004164.html
So at least there's a small part of the releng needs that is moving forward. :)
AGREED: schedule on hold by January, then no earlier than August (+5,-1,0) (mmaslano, 18:29:36)
Replying to [comment:10 mmaslano]:
To make sure that I am both understanding correctly and communicating clearly, I want to restate this agreement and the implications it has for my part of the proposal.
F21 will branch on March 1, 2014 at the earliest and fesco will be re-visiting a farther delay in f21 branch in January once the WG output is available
Unless there is farther delay, we are planning to have Taskbot phase 1 (replacing AutoQA) by March 1, 2014 and the timeline for later phases will be determined once a decision on the F21 schedule has been made
We didn't vote on it as formal proposal, but I agree with your summary.
Replying to [comment:11 tflink]:
Replying to [comment:10 mmaslano]: AGREED: schedule on hold by January, then no earlier than August (+5,-1,0) (mmaslano, 18:29:36) To make sure that I am both understanding correctly and communicating clearly, I want to restate this agreement and the implications it has for my part of the proposal. F21 will branch on March 1, 2014 at the earliest and fesco will be re-visiting a farther delay in f21 branch in January once the WG output is available Unless there is farther delay, we are planning to have Taskbot phase 1 (replacing AutoQA) by March 1, 2014 and the timeline for later phases will be determined once a decision on the F21 schedule has been made
This was my understanding of our decision, yes.
Replying to [comment:10 mmaslano]: AGREED: schedule on hold by January, then no earlier than August (+5,-1,0) (mmaslano, 18:29:36) To make sure that I am both understanding correctly and communicating clearly, I want to restate this agreement and the implications it has for my part of the proposal. F21 will branch on March 1, 2014 at the earliest and fesco will be re-visiting a farther delay in f21 branch in January once the WG output is available
No, if we aim "no earlier than August GA", branch date would be in late April/beginning of May, depends when we start the schedule. But I'd expect the end of January/beginning of February after WGs provide theirs input to FESCo and FESCo will process it.
I guess we will speak about it after approval of PRDs.
One thing I'm trying now is to collect teams requirements on time/resources needed to implement Fedora.next - to get reasonable time estimate for next Fedora schedule.
First reply from docs team - with current release estimate (August), Docs team is ok with releasing both traditional Fedora or next Fedora (if decided in timely manner). They already have process for targeted and general things.
We're still finalizing the edits for the ENV/Stacks and Workstation PRDs. Let's defer this discussion one more week.
PRDs are in, time to put this back on the agenda. However, I haven't gotten the impression that we've collected much information about what the WGs need. So perhaps this week is primarily to ask that the WGs feed us that information for next week.
I think we may need to provide a little more guidance to the WGs on what exactly we would like from them by next week's requirements/changes deadline.
One note - it's not only about WGs but other teams too. And I expect it would be based on the results of WGs scoping, that's scheduled for the next Monday. But I agree, more guidance is definitely desired.
Another note - with in-sync product release for F21 and August as current target date, we're getting close to a few important milestones. Quick look on schedule points out that F21 branching would be late April/May.
Quick concern:
It would be nice for QA to have a week or so after all the WGs have their estimages on time needed and changes to current process in place so that we can plan for it.
There should definitely be time for groups (qa, releng, infra, marketing, etc) to provide feedback after working groups say what they want to produce. Additionally, this feedback should decide what we think we actually can produce...
AGREED: Fedora Changes Process submission deadline for system-wide changes is April 7th. Deadline for true standalone changes will be sometime later than that. Changes to how fedora is produced for fedora.next are still due on March 3rd. (+7,0,0) (nirik, 18:29:42)
I guess we keep this open for further scheduling related coordination...
The Fedora Server Working Group presents its Technical Specification: https://fedoraproject.org/wiki/Server/Technical_Specification
This document is fairly high-level; there are several points around firewall, filesystem and Roles that are still being worked out on the various lists, but this should suffice to express our intent for Fedora 21.
From the 2014-03-05 FESCo meeting:
ACTION: jreznik to work up and provide a schedule proposal for Oct 14 target date for next week. (sgallagh, 18:26:43)
As requested on the last FESCo meeting, F21 schedule draft follows (all dates after Change Submission deadline are still labelled as "no earlier than").
Mid October gives us pretty a lot of time for real work to be done before branching (in the beginning of July). I'm going to share this draft with other teams (websites guys asked for). It's based on current schedule structure, adjusted to earlier change process but I don't expect (at least for F21) we want to diverge from what we used to do in pre-next releases. Unless needed of course. One question to discuss is spins process and dates for it - I skipped it for now intentionally. Exact GNOME schedule for 3.14 is not yet available (to put this release into the context of F21 release).
jreznik, have you considered having a later submission deadline for self contained changes ? Since often those are just advertising work that's being done upstream and outside the specific context of fedora, moving the submission deadline closer to the change freeze gives more opportunity to see what cool things are landing upstream which might warrant a change page.
Replying to [comment:32 crobinso]:
The risk there (as identified in an earlier FESCo meeting) is that not all Self-Contained Changes really are. Sometimes they are miscategorized (mostly unintentionally) because the submitter doesn't fully understand the scope of their change. We need to balance this risk carefully.
I'm definitely for later Self Contained Changes submission deadline and actually, for F21 we go this path - see my announcement on the -devel list. But as Stephen pointed out, it has to be balanced. So I still prefer most of Self Contained Changes to be proposed within month but be more flexible after. I was thinking if I should rename this milestone and I probably should do it.
From today's Fedora QA meeting: #info adamw, cmurf and handsome_pirate thought the schedule looked good - plenty of time before Alpha, but still a decent Alpha->Beta gap
I'm going to miss the FESCo meeting, so voting here.
This proposed schedule looks good to me: +1
AGREED: accept provisional schedule with "no earlier than" labels; will make firm after change submission deadline. (+8,0,0) proposed schedule does cut things close with expected new upstream kernel release FESCo is fine with shipping at-the-time current kernel, which will be then updated as normal
Adding back to meetings as majority of System Wide Changes were already approved/deferred by FESCo and we should reflect it in F21 planning, especially with mass rebuild planning and required next changes.
Schedule and coordinate mass rebuild for F21: https://fedorahosted.org/rel-eng/ticket/5877
We should decide on the final schedule asap to remove "no earlier than" note as I'm being asked at least twice a day what's the F21 schedule status :).
I wish I had noticed this before, but I question the wisdom of having alpha release the day before Flock (first go/no-go on the thursday before Flock). If we do release alpha 100% on schedule, we're not likely to have many issues but what's the contingency plan if we do slip - make Flock a massive testing/fixing gathering instead of focusing on planning and collaboration? Do we really want to have a decent chance of folks distracted by testing/fixing blockers for F21 alpha in the middle of Flock?
This may come across as pessimistic, but given the scale of the changes that are going into F21, I think that it's reasonably likely that alpha will slip at least one week.
If moving things back a couple of weeks isn't an option, moving the alpha freeze up a week might be a possibility. I'm not a huge fan of moving things up but it seems like a better option than the potential conflict with release-time-craziness and Flock.
I know Flock is an issue, but moving alpha freeze up a week would lead to slip either as it's still pretty tight for many stuff (and server roles got an exception to develop by the Alpha freeze). I'd say there's no commitment if we slip, we have to release next week. And yes, I understand with the scale of changes, it's probably going to happen :(.
Btw. the "no early than" is already removed.
Adding meeting keyword to discuss tomorrow.
agreed if f21 alpha slips, we will slip 2 weeks to not conflict with flock. (+8,0,0)
will keep to the schedule for now, please revisit with additional concerns
Reopening this ticket as we are going to miss Alpha Freeze due to many unresolved issues (issues with test composes especially) to avoid long freeze without reason (and hope to release before Flock).
With proposed Flock slip of two weeks, Alpha would be 2014-08-19 with Alpha Freeze on 2014-08-05.
I'll probibly miss the meeting tomorrow, but based on what I know (no complete tc compose, lots of things still be sorted out) I'd be +1 to enacting the 2 week slip and move alpha change freeze out to 2014-08-05.
So, that would make the schedule from here out
{{{ 2014-08-05 Alpha Change Deadline / Software String Freeze 2014-08-19 Alpha Release 2014-09-09 Beta Change Deadline / Accepted Changes 100% Complete / Software Translation Deadline 2014-09-23 Beta Release 2014-10-14 Final Change Deadline 2014-10-28 Fedora 21 Final Release }}}
Right?
I double-checked this, but please triple check. :)
While better, that still seems overly optimistic. That means that freeze would start the day before Flock and unless the people at Flock are working on getting Alpha done instead of participating in the conference, we have a week of actual work during freeze before Alpha is supposed to be released. I don't know about other groups but a decent number of the QA folks will be at Flock and won't have much access to hardware for testing.
At a minimum, I think that doing a 3 week slip so that freeze starts after Flock would be better because it takes Flock into account. I'm sure this wouldn't be popular but extending that farther to 3.5 or 4 weeks in order to account for travel time after Flock may end up being a better choice.
Agreed on today’s FESCo meeting:
Reopening for another schedule update. I talked to Dennis and we need to do another mass rebuild due to the gcc bug. After TC is done but it has to happen before freeze (not to use Bodhi for several thousands packages). Estimate is one week. This will move Alpha Change Deadline to 2014-08-19 and release to 2014-11-11.
Replying to [comment:55 jreznik]:
…. we need to do another mass rebuild due to the gcc bug. This is https://fedorahosted.org/rel-eng/ticket/5962 .
FESCo agreed today to slip freeze to next Tuesday at least (+5), and to move all future milestones as well.
Keeping the meeting keyword to track mass rebuild status; note that jreznik will not be able to track this for us this week.
FESCo agreed today to go into freeze the day after we have a usable TC. FESCo will revisit schedule next meeting to see if we need to adjust/delay/change anything. (+6)
dgilmore will send the heads-up on devel list once we have a working TC (day before freeze).
Keeping the meeting keyword to discuss the progress next week.
Removed from the wrong ticket
Closing this out. Exceptions will be handled on a case by case basis at this point.
Log in to comment on this ticket.