Ticket #1178 (new general)

Opened 7 months ago

Last modified 3 weeks ago

Fedora 21 scheduling strategy

Reported by: jreznik Owned by:
Priority: major Keywords: Jan2014
Cc: tflink, ausil, jdulaney, bochecha, crobinso 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 7 months ago by mitr

  • Keywords meeting added

comment:2 Changed 7 months 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 6 months 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 6 months 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 6 months ago by jdulaney

  • Cc jdulaney added

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

  • Keywords Jan2014 added

comment:16 Changed 3 months ago by mmaslano

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

comment:17 Changed 3 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 3 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 3 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 2 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 2 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 2 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 2 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 2 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 2 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 2 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 7 weeks 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 7 weeks ago by crobinso

  • Cc crobinso added

comment:29 Changed 7 weeks 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 6 weeks 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 6 weeks 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 6 weeks 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 6 weeks 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 6 weeks 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 6 weeks 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 5 weeks 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 5 weeks 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 5 weeks ago by mattdm (previous) (diff)

comment:38 Changed 3 weeks ago by mitr

  • Keywords Meeting removed
Note: See TracTickets for help on using tickets.