Fedora "backports" repo? (Was Re: PostgreSQL 9 for F14?)

[Al Dunsmuir]

On Wednesday, September 22, 2010, 8:06:12 AM, drag01 wrote:
> On Wed, Sep 22, 2010 at 11:24 AM, Richard W.M. Jones <rjones at redhat.com> wrote:
>> On Mon, Sep 20, 2010 at 09:58:53PM -0400, Arthur Pemberton wrote:
>>> 2010/9/20 Michał Piotrowski <mkkp4x4 at gmail.com>:
>>> > 2010/9/21 Toshio Kuratomi <a.badger at gmail.com>:
>>> >> As the concept of using third party repositories (both as packagers and as
>>> >> users) grows, this interdependence will grow.
>>> >
>>> > Ok, so maybe it's time to setup Fedora "backports" repo for these that
>>> > wants new and shiny Firefox 4, PostgreSQL 9 or whatever with big
>>> > number.
>>>
>>>
>>> What exactly is the fear here with these updates? Are there many
>>> desktop users who do NOT want the latest released Firefox? Are there
>>> many people using Fedora as their OS for their database server?
>>
>> Maybe we should turn this around and ask why more people don't
>> use Rawhide.

> Well "use rawhide" for anything else than testing and/or developing
> the new release just do not fly.

> Some of the reasons I can think of:

> 1) To high rate of changes / breakage

These are two separate issues.

Change:
Without  change in Fedora,  we  might  as well turn off the lights.

Keeping the change rate high in Rawhide is the whole point. After all,
we  are  trying  to  keep the other releases more stable by minimizing
unnecessary  or incompatible changes there - E.G. the branched release
that  is  being packaged, stabilized and validated for formal release,
and  especially  the  stable  releases  that  folks  need  for  normal
day-to-day usage.

Breakage:
The  problem you are describing in rawhide is partly due to your other
points.

"Np  Frozen  Rawhide" was introduced to try to make it so that given a
functional  Rawhide, the branching off of a new periodic release would
become easier.

One  issue  is that while the other releases have a base, updates and
updates  testing  repository  that  is  supposed to allow change to be
introduced in a controlled manner, rawhide is basically the other side
of the wall (as in, "throw the update over the wall" after it builds).
This  means  rawhide  tends  to  be  broken  because  of incomplete or
untested changes, rather than change in general.

If   a  second  rawhide-specific  staging  repository  (equivalent  to
updates-testing,  so  call  it  rawhide-testing)  was  added with some
autoqa  automation  to  prevent  gratuitous  problems  (such as broken
dependencies  in  core  components),  I  suspect  the  situation would
improve.

Migration of updated packages from rawhide-testing to rawhide would be
controlled  by  the  same koji mechanisms that control updating of the
other  fedora  release,  but  with  less  restrictions  (some  wait by
default, but not a week), support for karma (negative karma to require
override   to   migrate).   I suspect that proventester approval would
not  be  required  (aside from there not being enough proventesters to
also handle rawhide).

> 2) No signed packages

There  has  been  discussion  of  the signing to be there, marking the
package as being built by the Fedora buildsystem.

> 3) Slower kernel

On purpose - first you get things right, then you get them fast. Those
additional  checks  are important so that any issues are identified as
soon as possible.

You want to benchmark something?  Build a no-debug kernel.

> 4) To much of "manual fixing" required

Maybe  reduced with a bit of focus, but likely also part of the nature
of the beast.

> 5) To many broken deps, which might prevent applying updates and security fixes

This one autoqa should be able to solve.  Reduces breakage in general,
and  helps  ensure  that  breakage  in branched releases is identified
sooner.

> 6) Some others that I can't think of right now might be a consequence
> of the above or something else

Stuff  happens,  but  Rawhide  is the place for it to happen.  But not
gratuitously  -  that's  not  being  nice  to  your fellow Fedora team
members.

> So please stop proposing rawhide for productive systems (or even
> database servers *shrug*).

I  think  that  Rawhide  is  being proposed for testing those types of
systems,  so  that  folks  help  ensure  new  features  reach branched
releases  ASAP...  and  in  some  cases,  that might mean an exception
granted to update a stable release.

Anyone  using  Rawhide for actual production either knows exactly what
they  are  doing,  and  is  cherry-picking  updates once they are done
initial setup... or is irretrievably insane (in which case, they won't
listen to any advise other than the voices in their heads).

Al