FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Advisory Board

 
 
LinkBack Thread Tools
 
Old 11-12-2008, 08:29 PM
Jeremy Katz
 
Default Fedora 11 schedule proposal

On Wed, 2008-11-12 at 16:10 -0500, Paul W. Frields wrote:
> On Wed, Nov 12, 2008 at 02:25:18PM -0500, Jeremy Katz wrote:
> > On Wed, 2008-11-12 at 14:22 -0500, Bill Nottingham wrote:
> > > Jeremy Katz (katzj@redhat.com) said:
> > > > > So, given that you already say we historically make up the slippage
> > > > > over two release cycles, you're violently objecting over.... a week?
> > > >
> > > > We make it up over two release cycles because we targeted to get back on
> > > > track for the first one and then slip for it and then get kind of close
> > > > for the second one
> > >
> > > Sure, but I'm not sure pretending we won't slip is viable. If we do
> > > take the 'attempt to make it up over two cycles' method, then this proposed
> > > schedule is only a 1-1/2 to 2 week adjustment to that. So I don't think
> > > it's that far out of line.
> >
> > Until we slip from the schedule, at which point it's more like 4-5
> > weeks.
>
> I think this assertion assumes the more granular revision in freeze
> periods is not going to have any effect on slippage.

That's true, it does. But that's because in the land of risk
management, you want to err on the side of what has happened in the
past[1] as opposed to what you hope will be the outcome of a new process
or change to an existing one.

Jeremy

[1] Well, there are tools that let you do probabilistic estimation based
on optimistic estimates of the future. But you still have to take into
account the past norms and outliers when doing so.

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 11-12-2008, 11:01 PM
Brian Pepple
 
Default Fedora 11 schedule proposal

On Wed, 2008-11-12 at 11:51 -0900, Jeff Spaleta wrote:
> On Wed, Nov 12, 2008 at 11:20 AM, Josh Boyer <jwboyer@gmail.com> wrote:
> > FESCo, then the Board? Or the Board can delegate to FESCo? One of the
> > two.
>
> Is this really Board fodder at all? I'm of the opinion that RelEng
> oversight is completely and utterly FESCo's jurisdiction. If FESCo
> wants to punt to the Board, okay I guess...but if FESCo can't come to
> a decision on this... is the Board better equipped to do it? I really
> really doubt we'd overrule FESCo's decision given the same public
> discussion as context .

No, this is a FESCo decision, just like in past releases. It would only
be escalated to the Board, if for some unforeseeable reason FESCo
couldn't come to a resolution.

Later,
/B
--
Brian Pepple <bpepple@fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 11-13-2008, 01:02 AM
"Paul W. Frields"
 
Default Fedora 11 schedule proposal

On Wed, Nov 12, 2008 at 03:15:47PM -0500, Josh Boyer wrote:
> On Wed, Nov 12, 2008 at 12:00:08PM -0800, Jesse Keating wrote:
> >On Wed, 2008-11-12 at 20:44 +0100, Thorsten Leemhuis wrote:
> >> Fedora is a Red Hat sponsored project and a lot of Fedora developers are
> >> payed by Red Hat. Nevertheless: What really irritates and annoys me is
> >> that it at least *looks like* the idea to delay Fedora 11 a bit to help
> >> RHEL 6 seems to come from *within* the project.
> >>
> >> That's IMHO totally wrong way around and IMHO should not have happened.
> >>
> >> Fedora IMHO should try to more act like a independent project if Fedora
> >> wants to get taken serious; otherwise Fedora will always stay a RH pet
> >> project that is unattractive to other medium or big sized Linux
> >> companies that might want to get involved in Fedora as well.
> >>
> >> Things like that also won't help to get rid of the "Fedora is just a
> >> RHEL beta" fame most of us dislike.
> >>
> >> Note that I have *no* problem with the idea itself that RH might want us
> >> to delay F11 (apart from the fact that I belive that predictable release
> >> dates are quite important). But RH should clearly have asked the project
> >> in a kind of official way "Can you please consider a one month delay for
> >> F11 as it would suite us very well".
> >
> >That's just it. "Red Hat" isn't asking us to delay. They're asking us
> >to pick a schedule and they'll deal. Knowing what "Red Hat" is going to
> >do in the next year or so as RHEL 6 gets under way, I wanted to give
> >Fedora the biggest benefit to that extra attention as possible, and to
> >me that meant giving F11 a full 6 month cycle. After F11 is out, I
> >can't guess when RHEL will import Fedora sources and "branch" CVS. At
> >that time, it would be harder to get RHEL resources looking at Fedora
> >things, and harder to get RHEL fixes done in Fedora.
>
> Not just Red Hat resources either. There are business partners that
> track RHEL releases. Who knows, maybe they are willing to focus on
> a Fedora release in order to make sure what they care about is in good
> shape for RHEL. That means more people testing and using.

Red Hat Engineering has been working on a set of features for Fedora
10 and 11 that will be substantially important for future Red Hat
Enterprise Linux (RHEL) products. These ambitious efforts span
multiple releases, and include code development, debugging, testing,
and so on.

In a few cases having two entire six-month release cycles is going to
be crucial. Fedora's roughly six-month release calendar provides some
reasonably good expectations for timing in that regard. Our
time-based releases allow Red Hat teams to coordinate with Fedora and
the upstream communities where they participate, to ensure these
features are worthwhile not just when they're completed for RHEL, but
along the way in Fedora as well. Naturally there are cases where the
upstream roadmap spans several Fedora releases as well, and must be
taken into account.

I don't feel some of the proposal's detractors are giving due
consideration to the effects of the intrusion earlier this summer,
which had a substantial effect on that work. In the context of where
much of our community does so much important work, delays were
unfortunate, but we overcame them without too much struggle.
Certainly the infrastructure effort didn't just jump back into place;
I gratefully acknowledge it required a lot of work to rebuild. In
large part work like packaging, ambassadors, translation, art, and
many other efforts were able to continue relatively unabated once our
infrastructure was back in place.

Recall, though, that Red Hat engineering teams across the board spend
a significant amount of their time developing in (and on) Fedora. In
terms of the larger-scale software engineering efforts at Red Hat,
making Fedora inflexible on its release date would essentially cut
those lost weeks out of Red Hat's development time. Now I have yet to
meet anyone in Red Hat, in Engineering or elsewhere, who doesn't
realize that the Fedora community is its own vital organism, and that
we set schedules like any other upstream. Red Hat continues to be a
participant in this community and not a dictatorial force. So
although it's completely within Fedora's purview to not budge, I feel
our schedule can and should take into account its effects on the whole
community.

We aren't being asked for an "indefinite stay" for Fedora 11, but
rather a very clear target date. Jesse brought this proposal to the
community in everyone's mutual interest, and was very open about the
importance and impact of the Fedora schedule on RHEL. Perhaps there
is confusion because he happens to be part of release engineering,
which usually develops and publishes the Fedora schedule, as well as a
Red Hat employee. But Red Hat managers did not internally dictate
this schedule. Jesse put a proposal on the table the same way we ask
of anyone in the community who wants a deviation from a process we
feel works well.

The cost to Fedora for these few weeks is relatively minimal, and
retains the spirit of our project as an advocate of free software
advancement, and as a partner, not a subordinate, in Red Hat's
engineering initiatives.

--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 11-13-2008, 04:11 PM
John Poelstra
 
Default Fedora 11 schedule proposal

Jeremy Katz wrote:

On Tue, 2008-11-11 at 16:11 -0800, Jesse Keating wrote:

Fedora releases typically have a 6 month development cycle. We target
specific dates for the release to give developers, end users, and
upstreams a target to shoot for. Typically any slipping of a release we
do, we just shorten the next release to make up for it. However a
month's time is quite a lot to shrink. Especially because of the
significance of F11.


FWIW, the past slippage of a month that we had, we made up the month
over the course of 2 release cycles to help reduce the impact to each
individual release.



I think the schedules and processes have matured a lot from the release
before Fedora 8 and I'm not sure they are as valid for comparison now.


* Fedora 8 slipped overall by approximately one week. We still set a
~5/1 GA date for F9

* Fedora 9 slipped two weeks total. We set an F10 GA date of ~ Oct 31.
* So far Fedora 10 has slipped by four weeks. After the infrastructure
incident we slipped by three weeks. Another week was added when we
missed the beta freeze.


John

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 11-13-2008, 08:47 PM
"Karsten 'quaid' Wade"
 
Default Fedora 11 schedule proposal

On Wed, Nov 12, 2008 at 03:15:47PM -0500, Josh Boyer wrote:
>
> Not just Red Hat resources either. There are business partners that
> track RHEL releases. Who knows, maybe they are willing to focus on
> a Fedora release in order to make sure what they care about is in good
> shape for RHEL. That means more people testing and using.

We have had significant pick-up in interest in Fedora from various
software vendors (ISVs). I am pushing them to use F11 as the sync clock for
getting their packages in to Fedora following a feature lifecycle.

Knowing the trouble many of them are having ("Can anyone say
'packaging common Java libraries"?), I'm reckoning that the more time
they have, the better.

Unlike RHEL engineering, these ISVs do not get to pick when Fedora is
branched for RHEL 6.

- Karsten
--
Karsten 'quaid' Wade, Community Gardener
http://quaid.fedorapeople.org
AD0E0C41
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 11-14-2008, 05:13 PM
"Karsten 'quaid' Wade"
 
Default Fedora 11 schedule proposal

On Thu, Nov 13, 2008 at 01:47:16PM -0800, Karsten 'quaid' Wade wrote:
>
> Unlike RHEL engineering, these ISVs do not get to pick when Fedora is
> branched for RHEL 6.

I had a short sidebar where I revealed a bit more of my thinking, and
I thought it would help if I shared it back here.

## BEGIN

My thinking is fairly simple. FWIW, I'm still contemplating, having
come to the thread a day late; I don't have a full opinion, but was
just speaking to a partner viewpoint that matters to Fedora (v. RHEL
partners.)

Six months is a proven clock to run against. However, we "always
slip a few weeks" and we also have discovered some of the reasons
why in our scheduling. I _know_ from this round of scheduling about
10 more reasons why Docs misses certain L10n deadlines, and we are
going to have those improved for F11.

It is a reasonable expectation that we can set a six month schedule
and actually keep it. I know there is no proof here, but it really
isn't viable to continue with the expectation that we always slip.
That is even more of a fallacy than making an occasional bump like
this.

The ISVs wouldn't really care about a longer window, but they are
going to feel a shorter window. I can beat the six month drum much
better than the May Day/Halloween drum, in terms of explaining to
them why we follow that proven clock.

OK, let me see if I can distill some concrete from that:

* Our original premise is "six months is the right rhythm", then we
attached that to a fixed calendar for various conveniences. There
is more value in the original premise than in the conveniences
that followed from it. In this case, the goal is to _not_ change
what is concretely working.

* We better enable new contributors who have not already begun on
F11; that is, the people who are stuck in the here-and-now and
haven't begun to plan roadmaps and activate them in to rawhide.

Anyway, still thinking ...

## END

In follow-up, it's clear we pick our calendar-tie for good and not
arbitrary reasons, but I maintain that it is the six-month rythym that
is primary, with "sync to upstreams and downstreams" as secondary. I
also don't see how the change in schedule this time negatively affects
the reasons we picked May/Oct. In other words, it's not like we are
going to miss the GNOME and KDE releases.

- Karsten
--
Karsten 'quaid' Wade, Community Gardener
http://quaid.fedorapeople.org
AD0E0C41
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 

Thread Tools




All times are GMT. The time now is 08:14 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org