reviving Fedora Legacy

[Patrice Dumas]

On Wed, Oct 15, 2008 at 11:25:18AM -0600, Stephen John Smoogen wrote:
> On Wed, Oct 15, 2008 at 11:08 AM, Patrice Dumas <pertusus at free.fr> wrote:
> 
> I think its this which is causing people to react in fear to the
> proposal. The large amount of uncertainty ( how long, what to do with
> bad vulnerabilities not getting fixed, no knowledge of the quality of
> the package, etc) is causing doubt. And this is the sort of FUD that
> comes about because something is too amorphous and isn't getting
> fleshed out.

There are 2 reasons why I don't want to flesh it too much. One is
because I think it is an iterative process, we don't need much to start
and we'll see how it goes, and in the start it won't be public, only
something experimental. The other reason is that I see a lot of over
confidence in fedora releases although fedora cannot promise 
anything: some guarantes that Fedora releases cannot make are asked for
for that project, I really can't understand why.

> 1) Dealing with the fear of hurting the Fedora brand. Come up with a
> new brand for this: Long Term Blue Shoes (or something).

I proposed UAEL. Update After End of Life. But I don't care a bit about
the name, as long as there is one and that it is clear that it is not
under the fedora brand.

> 2) Dealing with the various uncertainties:
>   A. Get a list of people dedicated to this

I want to do this as soon as possible, but not before there is a formal
agreement that it will be possible to use fedora infrastructure and
rules, because it completly determines if people are interested. I won't
be, for example, if I have to set up a new infrastructure.

>   B. Put out how long you are extending it:  1 extra year.

In my opinion, in the first experimental phase this is not very
important. After some thinking I think that 3 years for selected
releases and no more than 1 year for others may be right, but I think
that this should better be determined by discussing within the SIG and
with FESCo for advice and guidance and with infras for the available 
resources.

>   C. How to vet package quality/deal with bad trees.

Package quality will be checked using the current fedora QA practices
(well the practices at the time a branch is EOLed).
What do you mean with 'bad tree'? A whole release? For a whole release,
I think that first it should be possible to see if there is somebody
interested in a given branch for a given package, and if there is a
package of @core or @base that is not maintained the branch should be
shut (that was basically the UAEL proposal).

>   D. What stuff is staying 'static/slow-moving' and what gets whatever
> is in the latest Fedora?

For this one my opinion is that the whole project should be on the side
of the stability. However if the packager thinks that there won't be
major disruptions by using what is in the oldest fedora, and it lowers
his workload he can do it. In fact I think that something that should be
discussed within the SIG is how hard we try to keep a possible upgrade
path toward the next RHEL/EPEL. If there is a majority to think that it
is important, I think that we should try (without impairing the project)
to do that. Also if it fixes grave bugs and back porting is no easy.

> 3) Dealing with the Doubt.
>   A. Get the SIG organized

That's th efirst thing to do if the basics are agreed.

>   B. Build a test project of supporting Fedora 9 for 6 extra months.
>         This allows you time to get procedures, infrastructure, and
> whatever else needed.

The current plan is more for F8. But indeed this is the plan, begin
first with one branch, see if it works both on the infrastructure and 
packaging side, and stop if not (maybe before 6 months...).

>   C. Follow your plans
>   D. Report how it worked.
>   E. Fix what didn't work and repeat.

That's the plan.

> [And yes, you are going to need to deal with infrastructure. Disk
> space, cpu cycles, memory and power is not 'cheap' as much as people
> think it is. Extra build boxes will be needed, extra disk space to

I am not sure that cpu cycles, memory and power will be very
problematic, since we really should be on the side of stability and, in
contrary to EPEL the pacakges are already built. Moreover this is a one
time cost. Bandwidth and disk cost is another story, especially since it
is replicated in mirrors.

> store stuff, and extra cpu cycles as Fedora's current infrastructure
> is built on the assumption that it only needs to deal with X releases
> for Y time. Adding to X and Y means more equipment needed. It will
> also mean that someone's on the team are going ot have to focus on the
> infrastructure problems as that addition also increases the number of
> people needed to watch builds, etc.

Indeed. I am ready to face that the project uses too much resources, but
without trying one cannot know.

--
Pat