10:27 a.m.
Hi everybody,
I tried to merge together all the changes we were facing during the
last time with regards to Changes Policy & Fedora Release Life Cycle.
The outcome is available in [1] and [2]. Before I will ask FESCo for a
review, I would like to ask anyone who is interested for a review and
comments.
Basically the changes I did are related to the following topics:
* No More Alphas Change [3]
* Discussion about String Freeze [4]
* Rain dates and such [5]
* Removal of description how to build schedule on your own as this
paragraph was not already valid. I might add some description of this
later, however I do not think that this belongs to Life Cycle policy
anyway.
[1] https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle
[2] https://fedoraproject.org/wiki/User:Jkurik/Changes.Policy
[3] https://fedoraproject.org/wiki/Changes/NoMoreAlpha
[4]
https://lists.fedoraproject.org/archives/list/trans@lists.fedoraproject.o...
[5]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
Thanks,
Jan
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
11:18 a.m.
On Fri, Nov 10, 2017 at 05:27:25PM +0100, Jan Kurik wrote:
This looks generally good to me. The one change I would make is to
add to "Tue: Primary date from which rest of schedule derives". Make
that:
Tue: Primary date from which rest of schedule derives
This date is either the Tuesday before May 1st or October 31st.
Upcoming potential target dates are: 2018-04-24, 2018-10-30,
2019-04-30, and 2019-10-29.
Can you draw up how exactly any changes would affect:
https://fedoraproject.org/wiki/Releases/28/Schedule (FESCo approved)
https://fedoraproject.org/wiki/Releases/29/Schedule (still a draft)
I think offhand that they're basically the same (and that this change
basically brings the policy in line with the praxis), but I may have
missed something.
On a bigger note: Do we really want to have a window after branch where
Bodhi isn't active? Might it be better to put that as part of the
Branch step? I don't think we want a longer freeze period (especially
during beta) but we
And, on a even bigger note, the F27 July-to-October experiment worked
reasonably well (with the large remainer of the still-outstanding
Modular Server) but I don't think we want to do that again. I'd like to
suggest that if the April/May release slips into July, or the
October/November release slips into January, we *automatically* skip
the next target date for a _longer_ cycle to bring us back to schedule
rather than a short one.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
11:48 a.m.
On Fri, Nov 10, 2017 at 11:18 AM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
And, on a even bigger note, the F27 July-to-October experiment worked
reasonably well (with the large remainer of the still-outstanding
Modular Server) but I don't think we want to do that again. I'd like
to suggest that if the April/May release slips into July, or the
October/November release slips into January, we *automatically* skip
the next target date for a _longer_ cycle to bring us back to
schedule rather than a short one.
I thought it worked quite well. If a release gets delayed to July and
we completely skip the October release, so that the next release is in
April/May, then we need to be willing to push out major version
upgrades to the current stable release, and accept any accompanying
breakage. And that really blows up the entire concept of having stable
releases. A 10 month release cycle seems like a much bigger change to
me than a four month cycle. Fedora can't be a year behind and remain
relevant.
Michael
12:09 p.m.
On 11/10/2017 09:18 AM, Matthew Miller wrote:
...snip...
On a bigger note: Do we really want to have a window after branch where
Bodhi isn't active? Might it be better to put that as part of the
Branch step? I don't think we want a longer freeze period (especially
during beta) but we
You got cut off there?
The reason in the past for the window after branching, but before bodhi
enablement was because it allowed for a small window to fix up fallout
from branching, but if everyone is ok with just doing it at the same
time I suppose it should be possible.
And, on a even bigger note, the F27 July-to-October experiment
worked
reasonably well (with the large remainer of the still-outstanding
Modular Server) but I don't think we want to do that again. I'd like to
suggest that if the April/May release slips into July, or the
October/November release slips into January, we *automatically* skip
the next target date for a _longer_ cycle to bring us back to schedule
rather than a short one.
Sounds somewhat reasonable, but might get us behind on 'first'
kevin
4:21 a.m.
Dne 10.11.2017 v 18:18 Matthew Miller napsal(a):
On Fri, Nov 10, 2017 at 05:27:25PM +0100, Jan Kurik wrote:
> [1] https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle
Do we really want to have a window after branch where
Bodhi isn't active?
Bit of OT, but I'd appreciate if Bodhi was enabled even for Rawhide ;)
(Sorry, couldn't help myself)
And, on a even bigger note, the F27 July-to-October experiment worked
reasonably well (with the large remainer of the still-outstanding
Modular Server) but I don't think we want to do that again. I'd like to
suggest that if the April/May release slips into July, or the
October/November release slips into January, we *automatically* skip
the next target date for a _longer_ cycle to bring us back to schedule
rather than a short one.
I like this idea.
V.
6:08 a.m.
On Fri, Nov 10, 2017 at 6:18 PM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
On Fri, Nov 10, 2017 at 05:27:25PM +0100, Jan Kurik wrote:
> [1] https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle
This looks generally good to me. The one change I would make is to
add to "Tue: Primary date from which rest of schedule derives". Make
that:
Tue: Primary date from which rest of schedule derives
This date is either the Tuesday before May 1st or October 31st.
Upcoming potential target dates are: 2018-04-24, 2018-10-30,
2019-04-30, and 2019-10-29.
I added the "This date is either the Tuesday before May 1st or October
31st." sentence which makes sense to me. However I would not be happy
to add exact dates in a policy. A policy should be a general document.
Having exact dates can make it obsolete in case of any action we might
take in a future with a schedule for a particular release.
Can you draw up how exactly any changes would affect:
https://fedoraproject.org/wiki/Releases/28/Schedule (FESCo approved)
https://fedoraproject.org/wiki/Releases/29/Schedule (still a draft)
I think offhand that they're basically the same (and that this change
basically brings the policy in line with the praxis), but I may have
missed something.
There should be no major changes in the 28 and 29 schedules. Except
naming of some milestones (replacement of the Rain date) the only
milestone which is going to change is "String freeze".
On a bigger note: Do we really want to have a window after branch
where
Bodhi isn't active? Might it be better to put that as part of the
Branch step? I don't think we want a longer freeze period (especially
during beta) but we
I am adding Mohan (release engineering) on CC to answer this question.
And, on a even bigger note, the F27 July-to-October experiment
worked
reasonably well (with the large remainer of the still-outstanding
Modular Server) but I don't think we want to do that again. I'd like to
suggest that if the April/May release slips into July, or the
October/November release slips into January, we *automatically* skip
the next target date for a _longer_ cycle to bring us back to schedule
rather than a short one.
In my opinion, having a shorter cycle is better option than completely
skip one release. A shorter cycle puts us under stress, but we still
have things under control. Skipping a release might have many
consequences we might not even think of, like issues with branching
etc. I would be quite conservative here.
Jan
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
12:41 p.m.
On Fri, 2017-11-10 at 17:27 +0100, Jan Kurik wrote:
Hi everybody,
I tried to merge together all the changes we were facing during the
last time with regards to Changes Policy & Fedora Release Life Cycle.
The outcome is available in [1] and [2]. Before I will ask FESCo for a
review, I would like to ask anyone who is interested for a review and
comments.
It would be much easier to review if we could see a diff to the current
contents of the pages. When doing drafts like this, I usually copy the
original page *without* changes first, *then* make my changes, so the
'history' tab can be used to view the changes from the original
content.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
4:41 p.m.
On Tue, 2017-11-14 at 10:41 -0800, Adam Williamson wrote:
On Fri, 2017-11-10 at 17:27 +0100, Jan Kurik wrote:
> Hi everybody,
>
> I tried to merge together all the changes we were facing during the
> last time with regards to Changes Policy & Fedora Release Life Cycle.
> The outcome is available in [1] and [2]. Before I will ask FESCo for a
> review, I would like to ask anyone who is interested for a review and
> comments.
It would be much easier to review if we could see a diff to the current
contents of the pages. When doing drafts like this, I usually copy the
original page *without* changes first, *then* make my changes, so the
'history' tab can be used to view the changes from the original
content.
I realized I could just do this for you, so I did:
https://fedoraproject.org/wiki/User:Jkurik/Changes.Policy.diff
https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle.diff
For both pages, I first created them with the current content of the
original pages, then edited them to contain the same content as your
most recent drafts. So on the history tab, you can easily diff the
proposed changes.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
4:46 p.m.
On Fri, 2017-11-10 at 17:27 +0100, Jan Kurik wrote:
Hi everybody,
I tried to merge together all the changes we were facing during the
last time with regards to Changes Policy & Fedora Release Life Cycle.
The outcome is available in [1] and [2]. Before I will ask FESCo for a
review, I would like to ask anyone who is interested for a review and
comments.
Basically the changes I did are related to the following topics:
* No More Alphas Change [3]
* Discussion about String Freeze [4]
* Rain dates and such [5]
* Removal of description how to build schedule on your own as this
paragraph was not already valid. I might add some description of this
later, however I do not think that this belongs to Life Cycle policy
anyway.
Changes look fine to me, having looked at them quickly. There's a few
very minor changes from my Fedora Release Life Cycle draft which don't
seem to be in yours, but nothing too important; I can just wait until
you changes are made then check if any of mine are still needed.
Thanks.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
6:47 p.m.
Adam Williamson <adamwill(a)fedoraproject.org> wrote:
> I tried to merge together all the changes we were facing during
the
> last time with regards to Changes Policy & Fedora Release Life Cycle.
> The outcome is available in [1] and [2]. Before I will ask FESCo for a
> review, I would like to ask anyone who is interested for a review and
> comments.
It would be much easier to review if we could see a diff to the
current
contents of the pages. When doing drafts like this, I usually copy the
original page *without* changes first, *then* make my changes, so the
'history' tab can be used to view the changes from the original
content.
In MediaWiki, revisions compared in a diff do not need to
belong to the same article. So for example, to compare the
current revision of
https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle
(488139) to the current revision of
https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle
(505754), you can use the URL
https://fedoraproject.org/w/index.php?diff=505754&oldid=488139.
This is not as convenient (or obvious :-)) as your approach,
but it does not depend on a) somebody copying the original
first and b) not making a mistake when copying & pasting.
Tim
9:58 a.m.
On 11/14/2017 07:47 PM, Tim Landscheidt wrote:
In MediaWiki, revisions compared in a diff do not need to
belong to the same article. So for example, to compare the
current revision of...(488139) to the current revision of
...(505754), you can use the URL
https://fedoraproject.org/w/index.php?diff=505754&oldid=488139
This is not as convenient (or obvious :-)) as your approach,
Is there a way to click into that, or do you just know the URL and
substituted the IDs by hand? How did you get the IDs of the two pages in
the first place?
2:31 p.m.
Przemek Klosowski <przemek.klosowski(a)nist.gov> wrote:
In MediaWiki, revisions compared in a diff do not need to
belong to the same article. So for example, to compare the
current revision of...(488139) to the current revision of
...(505754), you can use the URL
https://fedoraproject.org/w/index.php?diff=505754&oldid=488139
This is not as convenient (or obvious :-)) as your approach,
Is there a way to click into that, or do you just know the URL and
substituted the IDs by hand? How did you get the IDs of the two pages in the first place?
This kind of URL is not exposed by the UI (AFAIAA). I as-
sembled the URL by:
1. Going to
https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle,
"history", "Compare selected revisions" which gives
https://fedoraproject.org/w/index.php?title=Fedora_Release_Life_Cycle&...
(which means 488140 is the current revision (on the right
side of the diff)),
2. doing the same for
https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle
which gives
https://fedoraproject.org/w/index.php?title=User%3AJkurik%2FFedora_Releas...,
and
3. assembling the URL by removing the "title" parameter
(just for cosmetics), setting the "oldid" parameter to
the revision to appear on the left side and the "diff"
parameter to the revision to appear on the right side.
(Cf. https://www.mediawiki.org/wiki/Manual:Parameters_to_index.php#View_and_re...
for documentation.)
Tim
3:52 p.m.
I dont want to reduce the time between branching and bodhi enablement. The gap is for any
short comings from branching, but if you guys think it is absolutely necessary then I am
okay with reducing it to a week.
Also, I want to point out that traditionally Alpha freeze and Bodhi enablement will happen
on the same day. With no alpha from F27 I think Bodhi enablement should happen along with
Beta Freeze. Probably that will help in reducing the timeline.
https://pagure.io/fesco/issue/1792
4:50 p.m.
On Wed, 2017-11-15 at 00:47 +0000, Tim Landscheidt wrote:
Adam Williamson <adamwill(a)fedoraproject.org> wrote:
> > I tried to merge together all the changes we were facing during the
> > last time with regards to Changes Policy & Fedora Release Life Cycle.
> > The outcome is available in [1] and [2]. Before I will ask FESCo for a
> > review, I would like to ask anyone who is interested for a review and
> > comments.
> It would be much easier to review if we could see a diff to the current
> contents of the pages. When doing drafts like this, I usually copy the
> original page *without* changes first, *then* make my changes, so the
> 'history' tab can be used to view the changes from the original
> content.
In MediaWiki, revisions compared in a diff do not need to
belong to the same article. So for example, to compare the
current revision of
https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle
(488139) to the current revision of
https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle
(505754), you can use the URL
https://fedoraproject.org/w/index.php?diff=505754&oldid=488139.
This is not as convenient (or obvious :-)) as your approach,
but it does not depend on a) somebody copying the original
first and b) not making a mistake when copying & pasting.
Oooh, handy. I never knew that. Thanks.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2347
days inactive
2352
days old
13 comments
9 participants
participants (9)
-
Adam Williamson -
Jan Kurik -
Kevin Fenzi -
Matthew Miller -
Michael Catanzaro -
Mohan Boddu -
Przemek Klosowski -
Tim Landscheidt -
Vít Ondruch