Ticket #1178 (closed general: fixed)

Opened 2 years ago

Last modified 12 months ago

Fedora 21 scheduling strategy

Reported by: jreznik Owned by:
Priority: major Keywords: meeting
Cc: tflink, ausil, jdulaney, bochecha, crobinso, petersen Blocked By:
Blocking:

Description

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.

Change History

comment:1 Changed 2 years ago by mitr

  • Keywords meeting added

comment:2 Changed 2 years ago by mitr

  • Cc tflink, dgilmore added

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.)

comment:3 follow-ups: ↓ 7 ↓ 9 Changed 2 years ago by ausil

  • Cc ausil added; dgilmore removed

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.

comment:4 Changed 2 years ago by tflink

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)?

comment:5 Changed 2 years ago by jdulaney

  • Cc jdulaney added

comment:6 follow-up: ↓ 8 Changed 23 months ago by 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

comment:7 in reply to: ↑ 3 Changed 23 months ago by mattdm

Replying to 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 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.

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.

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.

That sounds awesome and concrete. Can you develop/explain this idea a little bit more? How would it relate to, say, taskbot?

comment:8 in reply to: ↑ 6 Changed 23 months ago by mattdm

Replying to 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.

comment:9 in reply to: ↑ 3 Changed 23 months ago by bochecha

  • Cc bochecha added

Replying to ausil:

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:

So at least there's a small part of the releng needs that is moving forward. :)

comment:10 follow-up: ↓ 11 Changed 23 months ago by mmaslano

  • Keywords meeting removed

AGREED: schedule on hold by January, then no earlier than August (+5,-1,0) (mmaslano, 18:29:36)

comment:11 in reply to: ↑ 10 ; follow-ups: ↓ 13 ↓ 14 Changed 23 months ago by tflink

Replying to 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.

  1. 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
  1. 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

comment:12 Changed 23 months ago by mmaslano

We didn't vote on it as formal proposal, but I agree with your summary.

comment:13 in reply to: ↑ 11 Changed 23 months ago by sgallagh

Replying to tflink:

Replying to 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.

  1. 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
  1. 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.

comment:14 in reply to: ↑ 11 Changed 23 months ago by jreznik

Replying to tflink:

Replying to 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.

  1. 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.

comment:15 Changed 21 months ago by toshio

  • Keywords Jan2014 added

comment:16 Changed 20 months ago by mmaslano

I guess we will speak about it after approval of PRDs.

comment:17 Changed 20 months ago by jreznik

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.

comment:18 Changed 20 months ago by jreznik

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.

comment:19 Changed 19 months ago by sgallagh

We're still finalizing the edits for the ENV/Stacks and Workstation PRDs. Let's defer this discussion one more week.

comment:20 Changed 19 months ago by toshio

  • Keywords Meeting added

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.

comment:21 Changed 19 months ago by mattdm

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.

comment:22 Changed 19 months ago by jreznik

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?.

comment:23 Changed 19 months ago by toshio

  • FESCo needs the list of necessary changes from existing Fedora procedures needed to release the products. (abadger1999, 18:14:25)
  • ACTION: sgallagh to send message to devel-announe that talks about where to discuss the initial list of changes to existing Fedora procedures (abadger1999, 18:20:01)
  • ACTION: sgallagh to send what we need next from WGs message to liasons to bring to the next WG meeting (abadger1999, 18:21:51)
  • ACTION: mattdm to help coordinate the engagement of talking with other teams once we get the list of changes. (abadger1999, 18:15:09)

comment:24 Changed 19 months ago by jdulaney

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.

comment:25 Changed 19 months ago by kevin

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...

comment:26 Changed 19 months ago by tmraz

  • AGREED: Defer the ticket for a week to gather info from WGs (+6, -0, 0:0) (t8m, 18:10:05)

comment:27 Changed 18 months ago by kevin

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...

comment:28 Changed 18 months ago by crobinso

  • Cc crobinso added

comment:29 Changed 18 months ago by sgallagh

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.

comment:30 Changed 18 months ago by notting

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)

comment:31 Changed 18 months ago by jreznik

As requested on the last FESCo meeting, F21 schedule draft follows (all dates after Change Submission deadline are still labelled as "no earlier than").

  • Tue 2014-04-08 Change Proposals Submission Deadline
  • Tue 2014-07-08 Change Proposals Freeze (Testable|Complete) - no earlier than
  • Tue 2014-07-08 Branch Fedora 21 from Rawhide - no earlier than
  • Tue 2014-07-22 Alpha Change Deadline - no earlier than
  • Tue 2014-08-05 Alpha Release Public Availability - no earlier than
  • Tue 2014-08-26 Accepted Changes 100% Complete Deadline - no earlier than
  • Tue 2014-08-26 Beta Change Deadline - no earlier than
  • Tue 2014-09-09 Beta Release Public Availability - no earlier than
  • Tue 2014-09-30 Final Change Deadline - no earlier than
  • Tue 2014-10-14 Final Release Public Availability (GA) - 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).

comment:32 follow-ups: ↓ 33 ↓ 34 Changed 18 months ago by crobinso

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.

comment:33 in reply to: ↑ 32 Changed 18 months ago by sgallagh

Replying to crobinso:

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.

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.

comment:34 in reply to: ↑ 32 Changed 18 months ago by jreznik

Replying to crobinso:

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.

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.

comment:35 Changed 18 months ago by jreznik

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

comment:36 Changed 18 months ago by sgallagh

I'm going to miss the FESCo meeting, so voting here.

This proposed schedule looks good to me: +1

comment:37 Changed 18 months ago by mattdm

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

Last edited 18 months ago by mattdm (previous) (diff)

comment:38 Changed 17 months ago by mitr

  • Keywords Meeting removed

comment:39 Changed 16 months ago by jreznik

  • Keywords meeting added; Jan2014 removed

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.

comment:40 Changed 16 months ago by jreznik

Schedule and coordinate mass rebuild for F21: https://fedorahosted.org/rel-eng/ticket/5877

comment:41 Changed 16 months ago by sgallagh

  • AGREED: Side tags must complete their builds by May 26th. The mass rebuild will take place on June 6th. (+7, 0, -0) (sgallagh, 17:50:39)

comment:42 Changed 16 months ago by tmraz

  • Keywords meeting removed

comment:43 Changed 15 months ago by petersen

  • Cc petersen added

comment:44 Changed 14 months ago by jreznik

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 :).

comment:45 Changed 14 months ago by tflink

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.

comment:46 Changed 14 months ago by jreznik

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.

comment:47 Changed 14 months ago by kevin

  • Keywords meeting added

Adding meeting keyword to discuss tomorrow.

comment:48 Changed 14 months ago by kevin

  • Resolution set to fixed
  • Status changed from new to closed

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

comment:49 Changed 14 months ago by jreznik

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:50 Changed 14 months ago by kevin

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.

comment:51 Changed 14 months ago by mattdm

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. :)

comment:52 Changed 14 months ago by tflink

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.

comment:53 Changed 14 months ago by mitr

  • Keywords meeting removed

Agreed on today’s FESCo meeting:

  • Slip the schedule 3 weeks (+7)
  • jreznik will update the schedule and announce the slip

comment:54 Changed 13 months ago by kevin

  • Resolution set to fixed
  • Status changed from reopened to closed

comment:55 follow-up: ↓ 57 Changed 13 months ago by jreznik

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:56 Changed 13 months ago by mitr

  • Keywords meeting added

comment:57 in reply to: ↑ 55 Changed 13 months ago by mitr

Replying to jreznik:

…. we need to do another mass rebuild due to the gcc bug.

This is https://fedorahosted.org/rel-eng/ticket/5962 .

comment:58 Changed 13 months ago by mitr

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.

comment:59 Changed 13 months ago by thozza

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.

comment:60 Changed 12 months ago by sgallagh

  • Keywords meeting removed

comment:61 Changed 12 months ago by sgallagh

  • Keywords meeting added

Removed from the wrong ticket

comment:62 Changed 12 months ago by jwboyer

  • Resolution set to fixed
  • Status changed from reopened to closed

Closing this out. Exceptions will be handled on a case by case basis at this point.

Note: See TracTickets for help on using tickets.