6:51 p.m.
2010/9/21 Toshio Kuratomi <a.badger(a)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.
I'm not a huge fan of huge updates in "stable" Firefox3->Firefox4,
Kde4.5->Kde4.6 etc. In fact I would prefer to avoid them. But
sometimes people want this latest and greatest, shiny :)
Setting up "official" backport repo will avoid repos fragmentation.
Keeping all cool updates in one place appears to be a reasonable idea.
Am I right?
Regards,
Michal
7:08 p.m.
2010/9/20 Michał Piotrowski <mkkp4x4(a)gmail.com>:
Setting up "official" backport repo will avoid repos
fragmentation.
Another repository/branch inside Fedora infrastructure does not
automatically avoid the any of the potential problems that you would
want to lump into "repo fragmentation." You'd have to take great care
in crafting packing policy to prevent any repository interaction
problems concerning dependency chains, conflicts,obsoletes, parallel
installation, upgrade paths, etc.
Keeping all cool updates in one place appears to be a reasonable
idea.
Define cool. Does this mean that uncool updates would be excluded as
a matter of policy?
I'm not sure we all live in a world where a PostgreSQL 9 backport is _cool_.
-jef
7:21 p.m.
2010/9/21 Jeff Spaleta <jspaleta(a)gmail.com>:
2010/9/20 Michał Piotrowski <mkkp4x4(a)gmail.com>:
> Setting up "official" backport repo will avoid repos fragmentation.
Another repository/branch inside Fedora infrastructure does not
automatically avoid the any of the potential problems that you would
want to lump into "repo fragmentation." You'd have to take great care
in crafting packing policy to prevent any repository interaction
problems concerning dependency chains, conflicts,obsoletes, parallel
installation, upgrade paths, etc.
> Keeping all cool updates in one place appears to be a reasonable idea.
Define cool.
Firefox 4, Postgres 9, Cherokee 2, OpenOffice 4, Duke Nukem Forever
Does this mean that uncool updates would be excluded as
a matter of policy?
Yes. Most users don't care about libfoo 1.6.54 -> libfoo 1.7.0 upgrade.
I'm not sure we all live in a world where a PostgreSQL 9 backport
is _cool_.
It's cool if you have strange problems with PgPool
-jef
Regards,
Michal
7:31 p.m.
2010/9/20 Michał Piotrowski <mkkp4x4(a)gmail.com>:
Yes. Most users don't care about libfoo 1.6.54 -> libfoo 1.7.0
upgrade.
It's cool if you have strange problems with PgPool
You understand that what you have just describe is not easily wrapped
into a self-consistent policy right? There are undoubtably "strange
problems" one one sort of another which impact "niche users" across
the existing packagescape and backports to address their problems
would not meet any reasonable definition that relied on the
anticipated desires of "most users." Every conceivable possible
update will most likely solve a problem for someone. You haven't
really sketched out a policy by which any reasonable person or persons
could judge suitability of a particular potential update and exclude
it from such a backports repository.
-jef
7:43 p.m.
On Mon, 2010-09-20 at 16:31 -0800, Jeff Spaleta wrote:
2010/9/20 Michał Piotrowski <mkkp4x4(a)gmail.com>:
> Yes. Most users don't care about libfoo 1.6.54 -> libfoo 1.7.0 upgrade.
> It's cool if you have strange problems with PgPool
You understand that what you have just describe is not easily wrapped
into a self-consistent policy right? There are undoubtably "strange
problems" one one sort of another which impact "niche users" across
the existing packagescape and backports to address their problems
would not meet any reasonable definition that relied on the
anticipated desires of "most users." Every conceivable possible
update will most likely solve a problem for someone. You haven't
really sketched out a policy by which any reasonable person or persons
could judge suitability of a particular potential update and exclude
it from such a backports repository.
The Mandriva policy is a reasonable starting point:
http://wiki.mandriva.com/en/Policies/SoftwareMedia#Backports_policy
it's sketchy and not greatly written, but the basic idea is that
backports should only be 'leaf' packages (things on which nothing else
depends) and libs required _only_ by the packages that are being
backported. Packages on which other, unrelated packages depend shouldn't
be backported.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:49 a.m.
On Tue, 21 Sep 2010 01:43:43 +0100, Adam Williamson wrote:
The Mandriva policy is a reasonable starting point:
http://wiki.mandriva.com/en/Policies/SoftwareMedia#Backports_policy
it's sketchy and not greatly written, but the basic idea is that
backports should only be 'leaf' packages (things on which nothing else
depends) and libs required _only_ by the packages that are being
backported. Packages on which other, unrelated packages depend shouldn't
be backported.
Sounds like the only way to package Firefox under such a backport scheme
would be to bundle Gecko etc.
--
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/
Email: salimma(a)fedoraproject.org | GPG key ID: 78884778
Jabber: hircus(a)jabber.ccc.de | IRC: hircus(a)irc.freenode.net
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
4:11 a.m.
On Tue, 2010-09-21 at 08:49 +0000, Michel Alexandre Salim wrote:
On Tue, 21 Sep 2010 01:43:43 +0100, Adam Williamson wrote:
> The Mandriva policy is a reasonable starting point:
>
> http://wiki.mandriva.com/en/Policies/SoftwareMedia#Backports_policy
>
> it's sketchy and not greatly written, but the basic idea is that
> backports should only be 'leaf' packages (things on which nothing else
> depends) and libs required _only_ by the packages that are being
> backported. Packages on which other, unrelated packages depend shouldn't
> be backported.
Sounds like the only way to package Firefox under such a backport scheme
would be to bundle Gecko etc.
Yup. In MDV, Firefox isn't/wasn't allowed under the backports
guidelines. I think this makes sense given how important it is and how
easy it is to break other stuff by touching Firefox. Some stuff just
isn't right for a backports repo.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
4:30 a.m.
2010/9/21 Adam Williamson <awilliam(a)redhat.com>:
On Tue, 2010-09-21 at 08:49 +0000, Michel Alexandre Salim wrote:
> Sounds like the only way to package Firefox under such a backport scheme
> would be to bundle Gecko etc.
Yup. In MDV, Firefox isn't/wasn't allowed under the backports
guidelines. I think this makes sense given how important it is and how
easy it is to break other stuff by touching Firefox. Some stuff just
isn't right for a backports repo.
It seems to me that backports repo should be treated on a different
basis by developers and users than any other official repos.
I do not expect that it will have the normal technical support. I do
not expect that the installation of package from the will not break
anything. This should be something like "use at your own risk if you
want some newer packages, but do not expect that it will work
completely without any problem with official Fedora repo and other
repos like rpmfusion etc"
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
Regards,
Michal
4:12 a.m.
On 09/21/2010 02:19 PM, Michel Alexandre Salim wrote:
On Tue, 21 Sep 2010 01:43:43 +0100, Adam Williamson wrote:
> The Mandriva policy is a reasonable starting point:
>
> http://wiki.mandriva.com/en/Policies/SoftwareMedia#Backports_policy
>
> it's sketchy and not greatly written, but the basic idea is that
> backports should only be 'leaf' packages (things on which nothing else
> depends) and libs required _only_ by the packages that are being
> backported. Packages on which other, unrelated packages depend shouldn't
> be backported.
Sounds like the only way to package Firefox under such a backport scheme
would be to bundle Gecko etc.
Yep. For a number of important packages, we have to resort to bundling
libraries if we go this route. Other distros like Ubuntu are already
doing this for their main Firefox packages. It might be a trade off
worth considering for backport repo if one exists.
Rahul
7:22 p.m.
New subject: Fedora "backports" repo?
Michał Piotrowski wrote:
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.
I'm not a huge fan of huge updates in "stable" Firefox3->Firefox4,
Kde4.5->Kde4.6 etc. In fact I would prefer to avoid them. But
sometimes people want this latest and greatest, shiny :)
Setting up "official" backport repo will avoid repos fragmentation.
Keeping all cool updates in one place appears to be a reasonable idea.
Am I right?
How hard would it be to "cherry-pick" from this backports repository? To
install a newer Firefox from there for example, but keep the PostgreSQL from
the ordinary Fedora even if there is a newer one in the backports repository,
and with a simple "yum update" receive bugfixes to PostgreSQL from fedora-
updates and new Firefox versions from the backports repository?
If the backports repository would be an "all or nothing" thing, or if cherry-
picking would require special tweaking of Yum, then it's a bad idea.
Björn Persson
7:25 p.m.
New subject: Fedora "backports" repo?
2010/9/21 Björn Persson <bjorn(a)xn--rombobjrn-67a.se>:
Michał Piotrowski wrote:
> 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.
>
> I'm not a huge fan of huge updates in "stable" Firefox3->Firefox4,
> Kde4.5->Kde4.6 etc. In fact I would prefer to avoid them. But
> sometimes people want this latest and greatest, shiny :)
>
> Setting up "official" backport repo will avoid repos fragmentation.
> Keeping all cool updates in one place appears to be a reasonable idea.
> Am I right?
How hard would it be to "cherry-pick" from this backports repository? To
install a newer Firefox from there for example, but keep the PostgreSQL from
the ordinary Fedora even if there is a newer one in the backports repository,
and with a simple "yum update" receive bugfixes to PostgreSQL from fedora-
updates and new Firefox versions from the backports repository?
If the backports repository would be an "all or nothing" thing, or if cherry-
picking would require special tweaking of Yum, then it's a bad idea.
yum-plugin-priorities?
Björn Persson
Regards,
Michal
6:29 p.m.
New subject: Fedora "backports" repo?
Michał Piotrowski wrote:
2010/9/21 Björn Persson <bjorn(a)xn--rombobjrn-67a.se>:
> How hard would it be to "cherry-pick" from this backports repository? To
> install a newer Firefox from there for example, but keep the PostgreSQL
> from the ordinary Fedora even if there is a newer one in the backports
> repository, and with a simple "yum update" receive bugfixes to
> PostgreSQL from fedora-updates and new Firefox versions from the
> backports repository?
>
> If the backports repository would be an "all or nothing" thing, or if
> cherry-picking would require special tweaking of Yum, then it's a bad
> idea.
yum-plugin-priorities?
The first thing I notice is that that plugin comes with exactly zero
documentation. A wiki page from CentOS and two posts on some random blogs give
some configuration examples and also warn about dangers that only a Yum hacker
will fully understand. Neither explains how to install selected packages from
a lower-prioritized repository, but my crystal ball indicates that it would be
troublesome compared to normal Yum usage.
Apparently all repositories have the lowest possible priority by default, so
users would have to edit every single .repo file by hand to give them higher
priorities than the backports repository. In other words, yes, special
tweaking of Yum would be required.
If the default priority were to be changed, and if the backports repository
would depend on yum-plugin-priorities and have a lower priority than the
default, and if it would have detailed usage instructions, and if it would be
carefully managed and tested to avoid the dangers of conflicts and obsoletions,
then an implementation based on the priorities plugin might be workable.
Another solution would be to simply have separate repositories – stored on the
same server and maintained by the same people, but with separately packaged
.repo files. If I can't wait to have the very latest Openoffice, I install the
fedora-backports-openoffice package which contains /etc/yum.repos.d/fedora-
backports-openoffice.repo, and then a simple "yum update" will upgrade all the
Openoffice packages. If I don't want sudden changes to PostgreSQL, then I
refrain from installing fedora-backports-postgresql. Mission accomplished.
Björn Persson
8:15 a.m.
New subject: Fedora "backports" repo?
On Thu, 2010-09-23 at 01:29 +0200, Björn Persson wrote:
Michał Piotrowski wrote:
> 2010/9/21 Björn Persson <bjorn(a)xn--rombobjrn-67a.se>:
> > How hard would it be to "cherry-pick" from this backports repository?
To
> > install a newer Firefox from there for example, but keep the PostgreSQL
> > from the ordinary Fedora even if there is a newer one in the backports
> > repository, and with a simple "yum update" receive bugfixes to
> > PostgreSQL from fedora-updates and new Firefox versions from the
> > backports repository?
> >
> > If the backports repository would be an "all or nothing" thing, or
if
> > cherry-picking would require special tweaking of Yum, then it's a bad
> > idea.
>
> yum-plugin-priorities?
The first thing I notice is that that plugin comes with exactly zero
documentation. A wiki page from CentOS and two posts on some random blogs give
some configuration examples and also warn about dangers that only a Yum hacker
will fully understand. Neither explains how to install selected packages from
a lower-prioritized repository, but my crystal ball indicates that it would be
troublesome compared to normal Yum usage.
Apparently all repositories have the lowest possible priority by default, so
users would have to edit every single .repo file by hand to give them higher
priorities than the backports repository. In other words, yes, special
tweaking of Yum would be required.
There's:
http://yum.baseurl.org/gitweb?p=yum-utils.git;a=blob_plain;f=plugins/prio...
...but generally I don't recommend using priorities, as it's a big
hammer to solve a problem that shouldn't exist:
http://yum.baseurl.org/wiki/ConflictingRepos
...or to put it another way, putting a new firefox and PostgreSQL in the
same repo. is a really bad idea.
Another solution would be to simply have separate repositories –
stored on the
same server and maintained by the same people, but with separately packaged
.repo files. If I can't wait to have the very latest Openoffice, I install the
fedora-backports-openoffice package which contains /etc/yum.repos.d/fedora-
backports-openoffice.repo, and then a simple "yum update" will upgrade all the
Openoffice packages. If I don't want sudden changes to PostgreSQL, then I
refrain from installing fedora-backports-postgresql. Mission accomplished.
That's basically what we have now with repos.fedorapeople.org ... the
next thing from there is if we could trust those packages the same as
the ones from Fedora itself (and maybe get some mirroring). But that
will require a lot more resources.
4:34 p.m.
New subject: Fedora "backports" repo?
James Antill wrote:
There's:
http://yum.baseurl.org/gitweb?p=yum-utils.git;a=blob_plain;f=plugins/priori
ties/README;hb=90ea69cc7589160735fc67f341db210403bc7f6f
Why isn't that file in the package? It leaves many questions unanswered but
it's better than nothing.
Björn Persson
8:58 p.m.
2010/9/20 Michał Piotrowski <mkkp4x4(a)gmail.com>:
2010/9/21 Toshio Kuratomi <a.badger(a)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?
--
Fedora 13
(www.pembo13.com)
11:03 p.m.
On Mon, 2010-09-20 at 21:58 -0400, Arthur Pemberton wrote:
2010/9/20 Michał Piotrowski <mkkp4x4(a)gmail.com>:
> 2010/9/21 Toshio Kuratomi <a.badger(a)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?
That they sometimes horribly break, change behavior (in any way), or
otherwise affect the smooth consistency of using a system and upgrading
daily, without actively discouraging upgrades for fear of breakage
(which is what Fedora has been doing for me, as an example). The fear is
also that people are not comprehending the difference between a released
Operating System Platform and a random collection of moving targets.
Are there many
desktop users who do NOT want the latest released Firefox?
Yup. I don't want it. I don't care about it and I'm uninterested in
having the latest version. I'd like the version I have currently
installed to get security fixes, but I don't want Firefox 4 on my
desktop system right now. I'll leave it on my development box running
rawhide and poke at it for testing, but I *DO NOT* want it released.
Are there
many people using Fedora as their OS for their database server?
If you mean does postgres matter, I've got an old non-Fedora box I'd
love to replace with Fedora, and it runs MySQL (amongst other things). I
can't replace it (using either database) until such time as Fedora has a
decent update policy though. So saying "nobody uses Fedora on the
server" is a sure fire way of perpetuating that sad reality.
I also care far more about server bits than I care about Firefox or my
desktop in general. I want a web browser, but I'll take any web browser
that works reasonably well enough. Similarly, I want a GUI of some kind,
but I don't care if it's enlightenment 0.17 if need be so long as it
doesn't ever change from one day to the next. I love the backports repo
idea. Ubuntu has been doing this for ages with their LTS releases, and
it's a nice way to pull in stuff like a more recent spamassassin without
having to upgrade the rest of the operating system, or change what works
out of the box in the default install path. So +1 to the idea in Fedora.
Jon.
11:29 p.m.
On Mon, 20 Sep 2010 21:58:53 -0400, you wrote:
2010/9/20 Micha? Piotrowski <mkkp4x4(a)gmail.com>:
> 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?
What if you are using a Firefox extension that hasn't been ported to
the latest release yet?
What if you have decided that Fedora is an easier path to a server
rather than attempting to backport a lot of packages because the
current release of RHEL/CentOS is 3 years old and doesn't have what
you need in term of framework or language?
What if you are a college that has deployed Fedora to use for your
students coursework, and an upgrade to a language/database/etc breaks
things mid-semester?
Fedora is used in a lot of different ways.
Gerald
11:36 p.m.
On Tue, Sep 21, 2010 at 12:29 AM, Gerald Henriksen <ghenriks(a)gmail.com> wrote:
On Mon, 20 Sep 2010 21:58:53 -0400, you wrote:
>2010/9/20 Micha? Piotrowski <mkkp4x4(a)gmail.com>:
>> 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?
What if you are using a Firefox extension that hasn't been ported to
the latest release yet?
You don't update Firefox till the extension comes out.
What if you have decided that Fedora is an easier path to a server
rather than attempting to backport a lot of packages because the
current release of RHEL/CentOS is 3 years old and doesn't have what
you need in term of framework or language?
The same thing suggested here for new packages.
What if you are a college that has deployed Fedora to use for your
students coursework, and an upgrade to a language/database/etc breaks
things mid-semester?
You test updates before you deploy them.
Fedora is used in a lot of different ways.
Sure, but I thought Fedora was all about pushing new, free software.
--
Fedora 13
(www.pembo13.com)
9:30 a.m.
On Tue, 21 Sep 2010 00:36:46 -0400, you wrote:
On Tue, Sep 21, 2010 at 12:29 AM, Gerald Henriksen
<ghenriks(a)gmail.com> wrote:
> On Mon, 20 Sep 2010 21:58:53 -0400, you wrote:
>
>>2010/9/20 Micha? Piotrowski <mkkp4x4(a)gmail.com>:
>>> 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?
>
> What if you are using a Firefox extension that hasn't been ported to
> the latest release yet?
You don't update Firefox till the extension comes out.
And if there is a security update required that makes updating Firefox
mandatory, what then? Fedora wouldn't be packaging the latest Firefox
3.* because under you scenario Firefox is at version 4.
Sure, but I thought Fedora was all about pushing new, free software.
It is, in two ways. One, Fedora makes releases every 6 months where
new software can debut without worrrying about backwards
compatibility. Secondly, for those more adventurous, you can run
Rawhide which (subject to the packagers) can always have the just
released versions.
11:38 p.m.
On Tue, 2010-09-21 at 00:29 -0400, Gerald Henriksen wrote:
On Mon, 20 Sep 2010 21:58:53 -0400, you wrote:
>2010/9/20 Micha? Piotrowski <mkkp4x4(a)gmail.com>:
>> 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?
What if you are using a Firefox extension that hasn't been ported to
the latest release yet?
What if you have decided that Fedora is an easier path to a server
rather than attempting to backport a lot of packages because the
current release of RHEL/CentOS is 3 years old and doesn't have what
you need in term of framework or language?
What if you are a college that has deployed Fedora to use for your
students coursework, and an upgrade to a language/database/etc breaks
things mid-semester?
Also...
What if you have a life outside computing and would like to run Fedora
at home but don't want to fix breakage on the weekend (because that
ceased to be fun after ten years, and once college was over with)?
Fedora is used in a lot of different ways.
Yes, it is, and it should be. Fixing updates is the number one problem,
right behind having a long term strategy.
Jon.
4:24 a.m.
On Mon, Sep 20, 2010 at 09:58:53PM -0400, Arthur Pemberton wrote:
2010/9/20 Michał Piotrowski <mkkp4x4(a)gmail.com>:
> 2010/9/21 Toshio Kuratomi <a.badger(a)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.
I use Rawhide on my laptop and one of my servers, so I'll tell you the
answer to this: because critical components such as the kernel are
often broken. IME this is because there is no testing of these
components before they get pushed out, and also the kernel developers
ignore bug reports.
This is reasonably easy to fix: we should do some testing and withhold
packages from Rawhide if they don't pass some basic sanity checks
(eg. does it boot, can an X server be started).
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
4:34 a.m.
2010/9/22 Richard W.M. Jones <rjones(a)redhat.com>:
Maybe we should turn this around and ask why more people don't
use Rawhide.
Maybe because when I installed rawhide I lost my desktop icons? :)
IMHO rawhide isn't the right answer for most users who wants just one new app.
Rich.
Regards,
Michal
6:07 a.m.
On Wed, 2010-09-22 at 10:24 +0100, Richard W.M. Jones wrote:
This is reasonably easy to fix: we should do some testing and
withhold
packages from Rawhide if they don't pass some basic sanity checks
(eg. does it boot, can an X server be started).
That's basically the proven testers process, which at present is running
around capacity trying to cover three releases (two current stable, plus
Branched). I'm really not sure we could manage another release,
especially one like Rawhide where people have a right to expect updates
to land quickly.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
8:29 a.m.
On Wed, Sep 22, 2010 at 12:07:24PM +0100, Adam Williamson wrote:
On Wed, 2010-09-22 at 10:24 +0100, Richard W.M. Jones wrote:
> This is reasonably easy to fix: we should do some testing and withhold
> packages from Rawhide if they don't pass some basic sanity checks
> (eg. does it boot, can an X server be started).
That's basically the proven testers process, which at present is running
around capacity trying to cover three releases (two current stable, plus
Branched). I'm really not sure we could manage another release,
especially one like Rawhide where people have a right to expect updates
to land quickly.
I really meant automated tests.
At the moment when I build libguestfs is when I find many kernel and
qemu bugs, because that is the first time that anyone has tried to
actually run the things. (Unfortunately at the moment I have had to
turn this testing off for Rawhide because of a fatal kernel bug that
no one has acknowleged -- 630777).
This testing is completely automatic and happens in Koji as part of
the %check section of the build. We run the kernel/qemu/userspace
combination together and subject them to about an hour of
stress-testing.
All I'm saying is, run these automated tests and fail the build if the
%check section fails. For extra marks, fix the bugs that are found.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
8:33 a.m.
I should add that whether this testing happens in Koji or in AutoQA
isn't material. AutoQA is probably better. *Provided* that if the
basic sanity tests fail they must prevent the packages from going into
the Rawhide compose.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
8:53 a.m.
On Wed, Sep 22, 2010 at 9:33 AM, Richard W.M. Jones <rjones(a)redhat.com> wrote:
I should add that whether this testing happens in Koji or in AutoQA
isn't material. AutoQA is probably better. *Provided* that if the
basic sanity tests fail they must prevent the packages from going into
the Rawhide compose.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Having an rpm add a repo file doesn't automatically solve the problem
for 100% of the repos out there. That leaves delegates the repo work
to the package maintainer. All because we don't want to copy Ubuntu's
GOOD ideas, just their BAD ones (like stale software updates vision).
As I said I'm not a programmer or I would do this myself. I don't want
Fedora to keep being behind openSUSE. Worst case scenario we'll see a
fork over the updates vision.
8:54 a.m.
something like sidux, but fedora based im thinking
stable f14 with the goodies stable vision blocks because people want
stale software, and i'd rather not use rawhide or opensuse
On Wed, Sep 22, 2010 at 9:53 AM, Brandon Lozza <brandon(a)pwnage.ca> wrote:
On Wed, Sep 22, 2010 at 9:33 AM, Richard W.M. Jones
<rjones(a)redhat.com> wrote:
> I should add that whether this testing happens in Koji or in AutoQA
> isn't material. AutoQA is probably better. *Provided* that if the
> basic sanity tests fail they must prevent the packages from going into
> the Rawhide compose.
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming blog: http://rwmj.wordpress.com
> Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
> http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
Having an rpm add a repo file doesn't automatically solve the problem
for 100% of the repos out there. That leaves delegates the repo work
to the package maintainer. All because we don't want to copy Ubuntu's
GOOD ideas, just their BAD ones (like stale software updates vision).
As I said I'm not a programmer or I would do this myself. I don't want
Fedora to keep being behind openSUSE. Worst case scenario we'll see a
fork over the updates vision.
5:19 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/22/2010 04:07 AM, Adam Williamson wrote:
On Wed, 2010-09-22 at 10:24 +0100, Richard W.M. Jones wrote:
> This is reasonably easy to fix: we should do some testing and withhold
> packages from Rawhide if they don't pass some basic sanity checks
> (eg. does it boot, can an X server be started).
That's basically the proven testers process, which at present is running
around capacity trying to cover three releases (two current stable, plus
Branched). I'm really not sure we could manage another release,
especially one like Rawhide where people have a right to expect updates
to land quickly.
I think the idea is to apply an AutoQA filter between the builds and
showing up in rawhide, not applying a bunch of human tester filters and
bodhi.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkyagPAACgkQ4v2HLvE71NUqsQCeI2Txx7Xfd8X7PmbdKJVEUakd
KaEAni/nSvaBFQfqVXST+wv6WhOyb7aI
=3BxD
-----END PGP SIGNATURE-----
9:14 a.m.
On Wednesday, September 22, 2010, 6:19:28 PM, Jesse wrote:
On 09/22/2010 04:07 AM, Adam Williamson wrote:
> On Wed, 2010-09-22 at 10:24 +0100, Richard W.M. Jones wrote:
>
>> This is reasonably easy to fix: we should do some testing and withhold
>> packages from Rawhide if they don't pass some basic sanity checks
>> (eg. does it boot, can an X server be started).
>
> That's basically the proven testers process, which at present is running
> around capacity trying to cover three releases (two current stable, plus
> Branched). I'm really not sure we could manage another release,
> especially one like Rawhide where people have a right to expect updates
> to land quickly.
I think the idea is to apply an AutoQA filter between the builds and
showing up in rawhide, not applying a bunch of human tester filters and
bodhi.
Add a separate rawhide-testing repo as a staging area for changes
(equivalent to updates-testing in a branched release).
- Use autoqu to run basic tests and dependency checks.
- Use a subset of the controls for branched releases.
The focus should be that once dependencies and any package-provide
tests are good things can quickly and automatically move into
rawhide.
Suggestions re controls:
Make the delay for automatic promotion short (say 2 days delay instead
of a week). Let bad karma hold back bad updates, but make promotion
easier than for a branched release. Don't tie up proventester
resources. Allow developers to push directly to rawhide if the autoqa
tests pass - require FES override otherwise.
In other words, create a sane system that parallels that used by
branched releases.
Al
9:57 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/22/2010 04:14 PM, Al Dunsmuir wrote:
On Wednesday, September 22, 2010, 6:19:28 PM, Jesse wrote:
> On 09/22/2010 04:07 AM, Adam Williamson wrote:
>> On Wed, 2010-09-22 at 10:24 +0100, Richard W.M. Jones wrote:
>>
>>> This is reasonably easy to fix: we should do some testing and withhold
>>> packages from Rawhide if they don't pass some basic sanity checks
>>> (eg. does it boot, can an X server be started).
>>
>> That's basically the proven testers process, which at present is running
>> around capacity trying to cover three releases (two current stable, plus
>> Branched). I'm really not sure we could manage another release,
>> especially one like Rawhide where people have a right to expect updates
>> to land quickly.
> I think the idea is to apply an AutoQA filter between the builds and
> showing up in rawhide, not applying a bunch of human tester filters and
> bodhi.
Add a separate rawhide-testing repo as a staging area for changes
(equivalent to updates-testing in a branched release).
- Use autoqu to run basic tests and dependency checks.
- Use a subset of the controls for branched releases.
The focus should be that once dependencies and any package-provide
tests are good things can quickly and automatically move into
rawhide.
Suggestions re controls:
Make the delay for automatic promotion short (say 2 days delay instead
of a week). Let bad karma hold back bad updates, but make promotion
easier than for a branched release. Don't tie up proventester
resources. Allow developers to push directly to rawhide if the autoqa
tests pass - require FES override otherwise.
In other words, create a sane system that parallels that used by
branched releases.
Al
I don't see the need to actually publish a "rawhide-testing" repo. Just
rawhide. If a package passes autoqa, let it in. If a maintainer waives
the autoqa failure, let it in. I really don't want to run bodhi on rawhide.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkyaGWsACgkQ4v2HLvE71NWqjgCgpn0wX6QcKFjGliKuHkLOwj6Z
scAAoJuqQolUnAPXNMvOlOugpafYu2gr
=wBqL
-----END PGP SIGNATURE-----
7:06 a.m.
On Wed, Sep 22, 2010 at 11:24 AM, Richard W.M. Jones <rjones(a)redhat.com> wrote:
On Mon, Sep 20, 2010 at 09:58:53PM -0400, Arthur Pemberton wrote:
> 2010/9/20 Michał Piotrowski <mkkp4x4(a)gmail.com>:
> > 2010/9/21 Toshio Kuratomi <a.badger(a)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
2) No signed packages
3) Slower kernel
4) To much of "manual fixing" required
5) To many broken deps, which might prevent applying updates and security fixes
6) Some others that I can't think of right now might be a consequence
of the above or something else
So please stop proposing rawhide for productive systems (or even
database servers *shrug*).
7:20 a.m.
On Wed, Sep 22, 2010 at 8:06 AM, drago01 <drago01(a)gmail.com> wrote:
On Wed, Sep 22, 2010 at 11:24 AM, Richard W.M. Jones
<rjones(a)redhat.com> wrote:
> On Mon, Sep 20, 2010 at 09:58:53PM -0400, Arthur Pemberton wrote:
>> 2010/9/20 Michał Piotrowski <mkkp4x4(a)gmail.com>:
>> > 2010/9/21 Toshio Kuratomi <a.badger(a)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
2) No signed packages
3) Slower kernel
4) To much of "manual fixing" required
5) To many broken deps, which might prevent applying updates and security fixes
6) Some others that I can't think of right now might be a consequence
of the above or something else
So please stop proposing rawhide for productive systems (or even
database servers *shrug*).
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
That's why I propose an easy way to install additional repos. I can't
see a non tech savvy user installing the chromium browser on fedora,
to be brutally honest. It's annoying having to hold their hand and
walk them through it. I don't see why the user can't double click the
repo file and have some application do the work for them. Or even have
a place where they can input a URL for the repo and some program adds
it to the database. Expecting the user to copy the .repo file into the
yum repos directory is extremely non intuitive and to be perfectly
honest I'm tech savvy and I can't be bothered to remember the path
name for that directory.
If people want Fedbuntu, at least copy this feature. Every other
distro has an easy way for the user to add third party repositories
using a tool. Perhaps an add button inside kpackagekit? It does have
the ability to disable and enable repos.
7:57 a.m.
On Wed, 2010-09-22 at 08:20 -0400, Brandon Lozza wrote:
That's why I propose an easy way to install additional repos. I
can't
see a non tech savvy user installing the chromium browser on fedora,
to be brutally honest. It's annoying having to hold their hand and
walk them through it. I don't see why the user can't double click the
repo file and have some application do the work for them.
It's already possible, the chromium repo just isn't set up this way
(it's a bit of work). See the rpmfusion repo setup process for an
example. It's basically just an RPM which contains the repo definitions;
you double-click the RPM, PackageKit pops up and installs it, and hey
presto, you have a new repo.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:29 p.m.
On Wed, 22 Sep 2010 13:57:49 +0100, Adam Williamson wrote:
On Wed, 2010-09-22 at 08:20 -0400, Brandon Lozza wrote:
> That's why I propose an easy way to install additional repos. I can't
> see a non tech savvy user installing the chromium browser on fedora, to
> be brutally honest. It's annoying having to hold their hand and walk
> them through it. I don't see why the user can't double click the repo
> file and have some application do the work for them.
It's already possible, the chromium repo just isn't set up this way
(it's a bit of work). See the rpmfusion repo setup process for an
example. It's basically just an RPM which contains the repo definitions;
you double-click the RPM, PackageKit pops up and installs it, and hey
presto, you have a new repo.
I believe Brandon want something that openSUSE already does with it's
"One Click Install" -- a small script that drops a new repo file, *then*
issue an install instruction for one of the packages from that repo.
I'm traveling right now, but depending on how good the Internet
connection is, I might be able to work on Fedora-izing the one-click
system. Hopefully not much needs changing to adapt it to Yum instead of
whatever openSUSE uses right now (is it still Zypper? My workplace is
still on openSUSE 11.1 and I don't have a newer version installed
elsewhere)
Cheers,
--
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/
Email: salimma(a)fedoraproject.org | GPG key ID: 78884778
Jabber: hircus(a)jabber.ccc.de | IRC: hircus(a)irc.freenode.net
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
8:31 a.m.
On Wed, Sep 22, 2010 at 02:06:12PM +0200, drago01 wrote:
On Wed, Sep 22, 2010 at 11:24 AM, Richard W.M. Jones
<rjones(a)redhat.com> wrote:
> On Mon, Sep 20, 2010 at 09:58:53PM -0400, Arthur Pemberton wrote:
>> 2010/9/20 Michał Piotrowski <mkkp4x4(a)gmail.com>:
>> > 2010/9/21 Toshio Kuratomi <a.badger(a)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.
If you read the second part of what I said, you'll see that I
proposed a way to address some of these issues.
Some of the reasons I can think of:
1) To high rate of changes / breakage
2) No signed packages
3) Slower kernel
4) To much of "manual fixing" required
5) To many broken deps, which might prevent applying updates and security fixes
6) Some others that I can't think of right now might be a consequence
of the above or something else
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
8:59 a.m.
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(a)redhat.com> wrote:
> On Mon, Sep 20, 2010 at 09:58:53PM -0400, Arthur Pemberton wrote:
>> 2010/9/20 Michał Piotrowski <mkkp4x4(a)gmail.com>:
>> > 2010/9/21 Toshio Kuratomi <a.badger(a)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
9:33 a.m.
On Wed, Sep 22, 2010 at 09:59:51 -0400,
Al Dunsmuir <al.dunsmuir(a)sympatico.ca> wrote:
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.
That is what branched releases have. Running one of these still gets you
pretty up to date stuff, but a bit more protection from breakage.
2:33 p.m.
On Wed, 22 Sep 2010 09:33:47 -0500, Bruno Wolff III wrote:
On Wed, Sep 22, 2010 at 09:59:51 -0400,
Al Dunsmuir <al.dunsmuir(a)sympatico.ca> wrote:
>
> 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.
That is what branched releases have. Running one of these still gets you
pretty up to date stuff, but a bit more protection from breakage.
But branched releases stabilize sometime before the beta point is
reached, which triggered off this huge discussion in the first place,
because Postgresql 9.0 came out too late for inclusion.
--
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/
Email: salimma(a)fedoraproject.org | GPG key ID: 78884778
Jabber: hircus(a)jabber.ccc.de | IRC: hircus(a)irc.freenode.net
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
2:44 p.m.
On Wed, Sep 22, 2010 at 19:33:22 +0000,
Michel Alexandre Salim <fedora(a)michelsylvain.info> wrote:
But branched releases stabilize sometime before the beta point is
reached, which triggered off this huge discussion in the first place,
because Postgresql 9.0 came out too late for inclusion.
But if you are tracking branch releases you still need to wait less time.
I don't have the planned date, but I think the F15 branch will occur in
December which cuts the waiting time down to a about 3 months instead of
about 7 months.
8:30 p.m.
On Wed, 22 Sep 2010 19:33:22 +0000 (UTC), you wrote:
On Wed, 22 Sep 2010 09:33:47 -0500, Bruno Wolff III wrote:
> That is what branched releases have. Running one of these still gets you
> pretty up to date stuff, but a bit more protection from breakage.
But branched releases stabilize sometime before the beta point is
reached, which triggered off this huge discussion in the first place,
because Postgresql 9.0 came out too late for inclusion.
But did Postgresql 9 come out too late?
PostgreSQL had a 2nd beta release on June 4th, which could have gone
into Rawhide, and hence allowed PostgreSQL 9 to be in Fedora 14
(assuming that the packager had time to do it, and confidence that the
PostgreSQL final release would have been in time).
After all Gnome 2.32 isn't released until later this month, and the
beta releases have been included in Fedora 14 up to now.
1:34 a.m.
Le mercredi 22 septembre 2010 à 21:30 -0400, Gerald Henriksen a écrit :
After all Gnome 2.32 isn't released until later this month, and
the
beta releases have been included in Fedora 14 up to now.
Is that a good example ? Gnome has been broken one way or another in
Fedora 14 since branching point (I'm missing the *stable* GNOME
experience I had in rawhide). The desktop team usually handles
alpha/beta well, but this time they've overshot imho.
--
Nicolas Mailhot
2:37 a.m.
On Thu, Sep 23, 2010 at 8:34 AM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net> wrote:
Le mercredi 22 septembre 2010 à 21:30 -0400, Gerald Henriksen a écrit
:
> After all Gnome 2.32 isn't released until later this month, and the
> beta releases have been included in Fedora 14 up to now.
Is that a good example ? Gnome has been broken one way or another in
Fedora 14 since branching point (I'm missing the *stable* GNOME
experience I had in rawhide). The desktop team usually handles
alpha/beta well, but this time they've overshot imho.
Well this cycle there was "on the way to gnome3 and back" situation,
which caused a lot of churn (even upstream).
2:59 a.m.
On 23 September 2010 08:37, drago01 <drago01(a)gmail.com> wrote:
Well this cycle there was "on the way to gnome3 and back"
situation,
which caused a lot of churn (even upstream).
For what it's worth, the GNOME "will we, won't we" on a few different
issues (GApplication, GTK3, etc) has cost a lot of developer time, and
from an upstream perspective was a royal pain in the behind. I think
Matthias has done a wonderful job keeping F14 in some sort of
semblance, even with all this upstream turmoil.
I think 2.32 is going to be a pretty good, stable release, but a lot
of people (myself included) are saving the new bells and whistles for
GNOME 3.0. Expect the Fedora 15 feature page for GNOME to read a
little more interesting, for sure.
Richard.
3:24 a.m.
Le jeudi 23 septembre 2010 à 08:59 +0100, Richard Hughes a écrit :
On 23 September 2010 08:37, drago01 <drago01(a)gmail.com> wrote:
> Well this cycle there was "on the way to gnome3 and back" situation,
> which caused a lot of churn (even upstream).
For what it's worth, the GNOME "will we, won't we" on a few different
issues (GApplication, GTK3, etc) has cost a lot of developer time, and
from an upstream perspective was a royal pain in the behind. I think
Matthias has done a wonderful job keeping F14 in some sort of
semblance, even with all this upstream turmoil.
I agree completely.
My point was that it is *hard* to push new major versions reliably
just-before-freeze, that even big stable paid teams with lots of
experience like the desktop team do not always manage it well, and
people should stop claiming this kind of update is suitable for a stable
release just because they'd like it to happen.
Major updates require lots of testing to limit harmful side-effects.
People have the choice of waiting for the next stable release, while
this testing occurs in rawhide and alpha/beta/etc, or provide this
testing live in rawhide. Direct dump in stable with minimal testing and
no problems, is a nice fantasy, but it's just that, a *fantasy*. Facts
do not agree with this idea.
Upstream projects that claim it can be done usually define "working" as
"my stuff works, if I broke something in other apps it's not my
problem" (netscape projects like mozilla, firefox & nss are a case in
point: they are pathologically unable to provide updates that work well
with the rest of the ecosystem. It only works on windows because there
the rest of the ecosystem is so foreign it shares nothing with them)
--
Nicolas Mailhot
3:25 a.m.
On Thu, Sep 23, 2010 at 9:59 AM, Richard Hughes <hughsient(a)gmail.com> wrote:
On 23 September 2010 08:37, drago01 <drago01(a)gmail.com> wrote:
> Well this cycle there was "on the way to gnome3 and back" situation,
> which caused a lot of churn (even upstream).
For what it's worth, the GNOME "will we, won't we" on a few different
issues (GApplication, GTK3, etc) has cost a lot of developer time, and
from an upstream perspective was a royal pain in the behind.
That's what I meant with "even upstream".
I think
Matthias has done a wonderful job keeping F14 in some sort of
semblance, even with all this upstream turmoil.
No disagreement here.
I think 2.32 is going to be a pretty good, stable release, but a lot
of people (myself included) are saving the new bells and whistles for
GNOME 3.0. Expect the Fedora 15 feature page for GNOME to read a
little more interesting, for sure.
Neither here ;)
2:29 p.m.
On Thu, 23 Sep 2010 08:34:06 +0200, you wrote:
Le mercredi 22 septembre 2010 à 21:30 -0400, Gerald Henriksen a écrit
:
> After all Gnome 2.32 isn't released until later this month, and the
> beta releases have been included in Fedora 14 up to now.
Is that a good example ? Gnome has been broken one way or another in
Fedora 14 since branching point (I'm missing the *stable* GNOME
experience I had in rawhide). The desktop team usually handles
alpha/beta well, but this time they've overshot imho.
Well, Gnome has a proven track record and this release seems to be the
exception. In fairness to the desktop team, who seem to have been
given a mess with the delay of Gnome 3, I think Gnome should have
skpped the 2.32 release rather than this attempt to get something
newish just to meet a schedule. It's unfortunate that the desktop
team will get blamed for what is a Gnome mistake.
But the broader point is what criteria is used to determine what
software gets included in a given release of Fedora. A key point in
the drive to have stable releases is that it is only a "6 month" wait
to get a newer version of something into Fedora. But there is a
danger that this can go too far and end up being 9 or 10 months if a
project must have a final release before Fedora branches.
Someone wanting the latest PostgreSQL is looking at an 8 month wait
(assuming a May Fedora 15), and anything that was released in August
but not included in the Fedora 14 branch has 9 months if we don't
allow pre-releases.
10:22 a.m.
On Wed, Sep 22, 2010 at 3:59 PM, Al Dunsmuir <al.dunsmuir(a)sympatico.ca> wrote:
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(a)redhat.com>
wrote:
>> On Mon, Sep 20, 2010 at 09:58:53PM -0400, Arthur Pemberton wrote:
>>> 2010/9/20 Michał Piotrowski <mkkp4x4(a)gmail.com>:
>>> > 2010/9/21 Toshio Kuratomi <a.badger(a)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.
You missed the point.
> 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 missed the point.
You want to benchmark something? Build a no-debug kernel.
You missed the point.
> 4) To much of "manual fixing" required
Maybe reduced with a bit of focus, but likely also part of the nature
of the beast.
You missed the point.
> 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.
You missed the point.
But not
gratuitously - that's not being nice to your fellow Fedora team
members.
Again, you missed the point.
I did not say "rawhide SUCKS!!!!!1111!!!"" I said that rawhide's
purpose is for development and testing but NOT for general use.
9:29 a.m.
On Wed, Sep 22, 2010 at 14:06:12 +0200,
drago01 <drago01(a)gmail.com> wrote:
Some of the reasons I can think of:
2) No signed packages
There is a plan to deal with that, but I am not sure what its current
status is.
5) To many broken deps, which might prevent applying updates and
security fixes
Hopefully autoqa will deal with this. My opinion is broken deps shouldn't
be allowed except in updates-testing repos. Not even in rawhide.
5:18 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/22/2010 05:06 AM, drago01 wrote:
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
Not much one can do on this one, other than choose when to apply their
updates.
2) No signed packages
We will be fixing that, so that anything that falls out of koji will get
signed (except scratch builds)
3) Slower kernel
Not much I can do about that.
4) To much of "manual fixing" required
5) To many broken deps, which might prevent applying updates and security fixes
6) Some others that I can't think of right now might be a consequence
of the above or something else
I think those can be addressed by placing an AutoQA filter between a
build from master and the build showing up in rawhide.
So please stop proposing rawhide for productive systems (or even
database servers *shrug*).
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkyagM0ACgkQ4v2HLvE71NUmWwCgxETatIEx39lknPjpOMk1aIFH
LFMAni7OnWZD/TigvHv2dnEqkXJoqiYE
=Y1mY
-----END PGP SIGNATURE-----
9:14 a.m.
On Wed, 2010-09-22 at 15:18 -0700, Jesse Keating wrote:
> 4) To much of "manual fixing" required
> 5) To many broken deps, which might prevent applying updates and security fixes
> 6) Some others that I can't think of right now might be a consequence
> of the above or something else
I think those can be addressed by placing an AutoQA filter between a
build from master and the build showing up in rawhide.
That would likely be an improvement, but have you thought through the
interaction issues? Builds are rarely standalone, so we need to figure
out which builds go with which other builds so they can be tested
together. Or we can test an entire Rawhide push at one time, but in that
case, which package do you block if the automated test fails? All of
them? Pick one at random? Try and write heuristics so AutoQA can figure
out which package to block?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
10:05 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/22/2010 04:14 PM, Adam Williamson wrote:
That would likely be an improvement, but have you thought through
the
interaction issues? Builds are rarely standalone, so we need to figure
out which builds go with which other builds so they can be tested
together. Or we can test an entire Rawhide push at one time, but in that
case, which package do you block if the automated test fails? All of
them? Pick one at random? Try and write heuristics so AutoQA can figure
out which package to block?
The way I was thinking is this.
There would be two tags, rawhide and rawhide-pending. the rawhide tag
(or whatever it is an alias for) is where things go that have passed
autoqa. rawhide-pending is where things go that have not yet passed
auto-qa, and is the first stop after a build.
When things land in rawhide-pending an autotest run is ran in two
stages. One stage just uses what's currently in rawhide. If it passes,
let it through. If it fails, do another stage that includes all the
packages in rawhide /and/ rawhide-pending for it's repodata. If the
package passes it will have to be marked as requiring something that is
in -pending and not in rawhide yet. Insert some magic here.
It isn't going to be perfect, but it'll definitely be better than what
we have now.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkyaGzoACgkQ4v2HLvE71NUaiACggUis0yoy8WIUeN5m1XkAjMX1
raUAn30Tx48M8pY2BGtc+XE6FFBQcQbh
=6zdx
-----END PGP SIGNATURE-----
10:07 a.m.
On Wed, Sep 22, 2010 at 17:05:30 +0200,
Jesse Keating <jkeating(a)redhat.com> wrote:
It isn't going to be perfect, but it'll definitely be better than what
we have now.
The other case to consider is two updates in rawhide-pending that each
are OK with rawhide, but which together have dependency issues.
10:13 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/22/2010 05:07 PM, Bruno Wolff III wrote:
On Wed, Sep 22, 2010 at 17:05:30 +0200,
Jesse Keating <jkeating(a)redhat.com> wrote:
>
> It isn't going to be perfect, but it'll definitely be better than what
> we have now.
The other case to consider is two updates in rawhide-pending that each
are OK with rawhide, but which together have dependency issues.
In this case, the first one tested will get in, the second one will not.
Most likely we will need to lock autoqa down to testing one package at
a time and not move on to the next build until after the first test/move
is done to avoid races, if they are common. Stuff to explore.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkyaHQAACgkQ4v2HLvE71NXclACgrCRnMsmUysJDKz7LqkU77MM1
nXYAnA/Z68opRU28IaoPL+yNbk5mf6UA
=nnuL
-----END PGP SIGNATURE-----
10:13 a.m.
Jesse Keating wrote:
It isn't going to be perfect, but it'll definitely be better
than what
we have now.
I'm still not going to use rawhide. There would have to be a kernel
without debugging before I would even think of using it for my home or
work systems. I have a need for speed. :P
10:22 a.m.
On Wed, 2010-09-22 at 10:13 -0500, Michael Cronenworth wrote:
Jesse Keating wrote:
> It isn't going to be perfect, but it'll definitely be better than what
> we have now.
I'm still not going to use rawhide. There would have to be a kernel
without debugging before I would even think of using it for my home or
work systems. I have a need for speed. :P
I've honestly never noticed the difference between a debug and a
non-debug kernel.
I guess I spend too much money on CPUs. Or don't work 'em hard
enough. :P
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
11:55 a.m.
On Wed, Sep 22, 2010 at 04:22:45PM +0100, Adam Williamson wrote:
On Wed, 2010-09-22 at 10:13 -0500, Michael Cronenworth wrote:
> Jesse Keating wrote:
> > It isn't going to be perfect, but it'll definitely be better than what
> > we have now.
>
> I'm still not going to use rawhide. There would have to be a kernel
> without debugging before I would even think of using it for my home or
> work systems. I have a need for speed. :P
I've honestly never noticed the difference between a debug and a
non-debug kernel.
I guess I spend too much money on CPUs. Or don't work 'em hard
enough. :P
I've not noticed it either, and that is with running Rawhide on my two
most-used systems. And I'm not exactly using leading-edge hardware
either.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html
noon
On Wed, Sep 22, 2010 at 6:55 PM, Richard W.M. Jones <rjones(a)redhat.com> wrote:
On Wed, Sep 22, 2010 at 04:22:45PM +0100, Adam Williamson wrote:
> On Wed, 2010-09-22 at 10:13 -0500, Michael Cronenworth wrote:
> > Jesse Keating wrote:
> > > It isn't going to be perfect, but it'll definitely be better than
what
> > > we have now.
> >
> > I'm still not going to use rawhide. There would have to be a kernel
> > without debugging before I would even think of using it for my home or
> > work systems. I have a need for speed. :P
>
> I've honestly never noticed the difference between a debug and a
> non-debug kernel.
>
> I guess I spend too much money on CPUs. Or don't work 'em hard
> enough. :P
I've not noticed it either, and that is with running Rawhide on my two
most-used systems. And I'm not exactly using leading-edge hardware
either.
You both don't use GPUs are lot aren't you? ;)
While working on gnome-shell we noticed a ~30-40% performance drop by
running a debugging kernel compared to a non debug build (on both
intel and radeon).
2:38 p.m.
On Wed, 22 Sep 2010 19:00:25 +0200, drago01 wrote:
On Wed, Sep 22, 2010 at 6:55 PM, Richard W.M. Jones
<rjones(a)redhat.com>
wrote:
> On Wed, Sep 22, 2010 at 04:22:45PM +0100, Adam Williamson wrote:
>> I guess I spend too much money on CPUs. Or don't work 'em hard enough.
>> :P
>
> I've not noticed it either, and that is with running Rawhide on my two
> most-used systems. And I'm not exactly using leading-edge hardware
> either.
You both don't use GPUs are lot aren't you? ;)
While working on gnome-shell we noticed a ~30-40% performance drop by
running a debugging kernel compared to a non debug build (on both intel
and radeon).
One could always use a stable kernel in conjunction with Rawhide.
Speaking of debugging info, are they still turned on for branched
releases like F-14?
--
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/
Email: salimma(a)fedoraproject.org | GPG key ID: 78884778
Jabber: hircus(a)jabber.ccc.de | IRC: hircus(a)irc.freenode.net
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
2:45 p.m.
Michel Alexandre Salim wrote:
One could always use a stable kernel in conjunction with Rawhide.
Speaking of debugging info, are they still turned on for branched
releases like F-14?
Yes. Not until the Final RC builds is debugging switched off. (IIRC)
Rawhide kernels or using a stable kernel w/ Rawhide are not valid
options. Rawhide is rawhide - development of Fedora, not for production
use. Period. You can't jazz it up no matter how hard you try (Looking at
you Jesse, Adam, and Bruno).
P.S. Can't use proprietary kernel modules (which some people have to
use) with debugging kernels. The world isn't perfect and neither is Fedora.
I can see a big increase in boot time with my desktop setup when using a
debugging kernel among other slow-downs. From 8 seconds (non-debug) at
least double that. I use modern CPUs (quad core a minimum) with SSDs and
fast GPUs. Speed is very important to me.
2:50 p.m.
On Wed, Sep 22, 2010 at 14:45:03 -0500,
Michael Cronenworth <mike(a)cchtml.com> wrote:
Rawhide kernels or using a stable kernel w/ Rawhide are not valid
options. Rawhide is rawhide - development of Fedora, not for production
use. Period. You can't jazz it up no matter how hard you try (Looking at
you Jesse, Adam, and Bruno).
Well that depends on what you mean by production and what your needs are.
The people that running rawhide or branched are suggested to are generally
asking about using it to run the very latest of something (without having
to go through the trouble of packaging it themselves). That sounds like
testing to me, not production. People that try to both at the same time
(like I do for my personal systems) have to balance both uses.
P.S. Can't use proprietary kernel modules (which some people have
to
use) with debugging kernels. The world isn't perfect and neither is Fedora.
The earlier message about debugging kernels has prompted a message to the
Fedora kernel list about that topic. If you are interested in this, you might
want to comment in that discussion. (All of one message so far.)
http://lists.fedoraproject.org/pipermail/kernel/2010-September/002682.html
5:54 p.m.
On Wed, 2010-09-22 at 14:45 -0500, Michael Cronenworth wrote:
Michel Alexandre Salim wrote:
> One could always use a stable kernel in conjunction with Rawhide.
> Speaking of debugging info, are they still turned on for branched
> releases like F-14?
Yes. Not until the Final RC builds is debugging switched off. (IIRC)
Rawhide kernels or using a stable kernel w/ Rawhide are not valid
options. Rawhide is rawhide - development of Fedora, not for production
use. Period. You can't jazz it up no matter how hard you try (Looking at
you Jesse, Adam, and Bruno).
Er, whut? I didn't post anything advocating people use Rawhide for
day-to-day purposes. I wouldn't suggest such a thing. All I said was
that I haven't noticed the speed difference between debug and non-debug
kernels, because I haven't. I know it's measurably present, but it
doesn't affect any of my typical usage visibly.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
8:34 a.m.
Er, whut? I didn't post anything advocating people use Rawhide
for
day-to-day purposes. I wouldn't suggest such a thing. All I said was
that I haven't noticed the speed difference between debug and non-debug
kernels, because I haven't. I know it's measurably present, but it
doesn't affect any of my typical usage visibly.
People are recommending it for people who want the latest software.
Which isn't what Rawhide is for (based on all information I've read
and know about it).
We seem to have users who want less updates and no changes. We also
have users who want to be on the forefront of change. I think everyone
could be helped by making it easier to use repos for non savvy users.
It would keep the main repo focused on stable software for users who
are afraid of change. The alternate repos would be available for the
more adventurous users or developers. Rawhide is for testers and
developers. I don't think anyone sane uses Rawhide for 'production
use' or even 'general purpose use' unless testing.
Some people also pointed out another interesting tidbit and that is
proprietary video drivers. Some of us use them and want to be able to
use them. We wouldn't be using a rawhide kernel if it won't load the
modules. I assume users of proprietary kernel drivers would have to
set it up in f13 with rpmfusion and nvidia-akmod first before
upgrading to rawhide.
10:57 a.m.
On Thu, Sep 23, 2010 at 09:34:12 -0400,
Brandon Lozza <brandon(a)pwnage.ca> wrote:
Some people also pointed out another interesting tidbit and that is
proprietary video drivers. Some of us use them and want to be able to
use them. We wouldn't be using a rawhide kernel if it won't load the
modules. I assume users of proprietary kernel drivers would have to
set it up in f13 with rpmfusion and nvidia-akmod first before
upgrading to rawhide.
The kmod rpms for rawhide are already provided by rpmfusion. I don't know
how often they do them nor how often new kernel releases just plain
break the proprietary drivers. But it sure likes look at least some of
the time you should be able to use them.
11:23 a.m.
Bruno Wolff III wrote:
The kmod rpms for rawhide are already provided by rpmfusion. I
don't know
how often they do them nor how often new kernel releases just plain
break the proprietary drivers. But it sure likes look at least some of
the time you should be able to use them.
Bruno, you can't use certain proprietary modules with debugging kernels.
GPL symbols prevent you. In particular, the LOCKDEP stuff.
Frank mentioned[1] a viable option for Rawhide, but with Rawhide broken
more often then not, it still isn't a viable option to use every day. I
can't recommend it to Joe Schmoe if he wants Firefox 4.0 and he runs
into broken deps or broken apps and goes off and uses Ubuntu or SuSE
because of it.
[1]
http://lists.fedoraproject.org/pipermail/kernel/2010-September/002688.html
3:10 p.m.
On Thu, Sep 23, 2010 at 11:23:25 -0500,
Michael Cronenworth <mike(a)cchtml.com> wrote:
Bruno Wolff III wrote:
> The kmod rpms for rawhide are already provided by rpmfusion. I don't know
> how often they do them nor how often new kernel releases just plain
> break the proprietary drivers. But it sure likes look at least some of
> the time you should be able to use them.
Bruno, you can't use certain proprietary modules with debugging kernels.
GPL symbols prevent you. In particular, the LOCKDEP stuff.
That's interesting, because rpmfusion has nvidia modules in their
development repo. It could be that they were for older kernels or
something, I didn't look at the versions too closely.
Frank mentioned[1] a viable option for Rawhide, but with Rawhide
broken
more often then not, it still isn't a viable option to use every day. I
can't recommend it to Joe Schmoe if he wants Firefox 4.0 and he runs
into broken deps or broken apps and goes off and uses Ubuntu or SuSE
because of it.
To use rawhide you really need to be able to fix things; so you need to
be an advanced user. There is also the branched release. It should be
a bit better than rawhide, but does seem to get broken on occasion.
Builds go through testing, so there is a chance to catch a lot of the
bad stuff there before it gets to people not using testing. This would
still be for advanced linux users.
6:25 p.m.
On Wed, Sep 22, 2010 at 02:45:03PM -0500, Michael Cronenworth wrote:
I can see a big increase in boot time with my desktop setup when
using a
debugging kernel among other slow-downs. From 8 seconds (non-debug) at
least double that. I use modern CPUs (quad core a minimum) with SSDs and
fast GPUs. Speed is very important to me.
booting with slab_debug=- should mitigate one of the more expensive options.
Dave
9:22 a.m.
On Wed, Sep 22, 2010 at 10:24:38 +0100,
"Richard W.M. Jones" <rjones(a)redhat.com> wrote:
I use Rawhide on my laptop and one of my servers, so I'll tell you the
answer to this: because critical components such as the kernel are
often broken. IME this is because there is no testing of these
components before they get pushed out, and also the kernel developers
ignore bug reports.
The kernel isn't that big of a deal unless there is a bug tied to your
specific hardware. You can make the default the old kernel on updates
and upgrade the kernel at a convenient time. If one breaks things for
everyone, that will get fixed pretty quick. If there is a bug tied to specific
hardware, affecting a small number people, it can take a long time to fixed
in some cases.
I find it's more just random stuff breaks and I need to work around something
at a bad time. This is more likely to happen when some big change first
lands. Or when the thunderbird guys update thunderbird and sunbird, but don't
care if sunbird even works.
If we were better about getting big changes in before the branch, running
branched versions would probably be reasonable for people that want something
close to a rolling update.
9:34 a.m.
On Wed, Sep 22, 2010 at 09:22:21AM -0500, Bruno Wolff III wrote:
On Wed, Sep 22, 2010 at 10:24:38 +0100,
"Richard W.M. Jones" <rjones(a)redhat.com> wrote:
>
> I use Rawhide on my laptop and one of my servers, so I'll tell you the
> answer to this: because critical components such as the kernel are
> often broken. IME this is because there is no testing of these
> components before they get pushed out, and also the kernel developers
> ignore bug reports.
The kernel isn't that big of a deal unless there is a bug tied to your
specific hardware. You can make the default the old kernel on updates
and upgrade the kernel at a convenient time. If one breaks things for
everyone, that will get fixed pretty quick. If there is a bug tied to specific
hardware, affecting a small number people, it can take a long time to fixed
in some cases.
I find it's more just random stuff breaks and I need to work around something
at a bad time. This is more likely to happen when some big change first
lands. Or when the thunderbird guys update thunderbird and sunbird, but don't
care if sunbird even works.
If we were better about getting big changes in before the branch, running
branched versions would probably be reasonable for people that want something
close to a rolling update.
No, I think you are wrong.
First of all, I can see no benefit in pushing a package that cannot do
its basic function to Rawhide. Even in Rawhide, no one wants a kernel
that doesn't boot, even if in some circumstances they could go to the
trouble of downgrading their kernel. If we can test these situations
easily and reject these packages, we should just do it. (libguestfs
%check is a proof by example that such a thing is possible and easy in
Koji).
Secondly, it does matter that in Rawhide you can at least get to the
login prompt, log in, and get a shell. AIUI this was the basic idea
behind the critical path packages. From the shell you have a hope of
fixing things. Your browser not working is a problem you might be
able to fix with a shell. Your kernel hanging under disk load or
hanging in init scripts (both actual problems with the current Rawhide
kernel) is a good deal more complex to fix.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html
9:38 a.m.
On Wed, Sep 22, 2010 at 15:34:34 +0100,
"Richard W.M. Jones" <rjones(a)redhat.com> wrote:
No, I think you are wrong.
First of all, I can see no benefit in pushing a package that cannot do
its basic function to Rawhide. Even in Rawhide, no one wants a kernel
that doesn't boot, even if in some circumstances they could go to the
trouble of downgrading their kernel. If we can test these situations
easily and reject these packages, we should just do it. (libguestfs
%check is a proof by example that such a thing is possible and easy in
Koji).
My issue was with how much of a problem broken kernels in rawhide are.
It's still a problem, but not as big of a problem as other random
breakage when trying to run rawhide as your desktop.
Secondly, it does matter that in Rawhide you can at least get to the
login prompt, log in, and get a shell. AIUI this was the basic idea
behind the critical path packages. From the shell you have a hope of
fixing things. Your browser not working is a problem you might be
able to fix with a shell. Your kernel hanging under disk load or
hanging in init scripts (both actual problems with the current Rawhide
kernel) is a good deal more complex to fix.
Sure, but if you don't automatically switch to the new kernel on every
update (there's a setting to control this), you won't likely run into
that because of a kernel update. You might have something else cause that
though. The downside is that at some point you need to manually go in
and switch kernels.
3:38 p.m.
New subject: Fedora "backports" repo?
Arthur Pemberton <pemboa(a)gmail.com> writes:
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?
I don't know about "many", but there is at least one organisation
which runs production databases on Postgres on Fedora. People keep
saying that "Fedora isn't for servers", but I just don't see why not.
Getting stuck with years-old software in RHEL is no fun at all...
Neither is self-compiling or third-party repositories.
Anyway, it is unfortunate that the timing is such that Postgres 9 can't
make it in time for Fedora 14. Please don't put Postgres 9 into Fedora
14 if it doesn't make it from the start. Major upgrades to Postgres are
not something you want to happen during normal maintenance.
/Benny
9:36 p.m.
New subject: Fedora "backports" repo?
On Wed, Sep 22, 2010 at 22:38:21 +0200,
Benny Amorsen <benny+usenet(a)amorsen.dk> wrote:
I don't know about "many", but there is at least one organisation
which runs production databases on Postgres on Fedora. People keep
saying that "Fedora isn't for servers", but I just don't see why not.
Because it is more work. If one is managing lots of systems as part of a
job, you want to be efficient in how your time is used. Fedora systems
change to fast for that.
If you are running a server for a hobby and have some reason for running
Fedora, then it is a reasonable choice.
12:11 p.m.
New subject: Fedora "backports" repo?
Bruno Wolff III <bruno(a)wolff.to> writes:
Because it is more work. If one is managing lots of systems as part
of a
job, you want to be efficient in how your time is used. Fedora systems
change to fast for that.
On the other hand, Fedora saves a lot of time by not having to maintain
reasonably new versions of the server software you actually want to run
- be it Postgres, BIND, Apache, DHCPD or something else. Maintaining
those packages yourself is hard work, especially because you need to
stay up-to-date on security updates.
For me, Fedora definitely saves work over CentOS. The things that could
change this:
1) If Postgres 9 was released in the middle of a cycle so a security
upgrade ended up with forcing a full dump/reload of databases. I can't
see that happening.
2) If Ruby keeps falling behind. (I'm sure others feel the same about
Python...)
3) If Fedora ended up too broken to use for more than one release, so I
couldn't just skip a cycle.
Fixing the upgrade script every 6 months is a small price to pay for
up-to-date software.
/Benny
10:35 p.m.
On Tue, Sep 21, 2010 at 01:51:03 +0200,
Michał Piotrowski <mkkp4x4(a)gmail.com> wrote:
Setting up "official" backport repo will avoid repos fragmentation.
Keeping all cool updates in one place appears to be a reasonable idea.
Am I right?
If we had infinite manpower this might be doable on request. As things are,
the people that want to do this need to volunteer to do work to make it
happen. A good start would be setting up external repos and try to
maintain some group of rawhide packages for the in support releases.
If this was succesful, I expect getting Fedora infrastructure to make it
more official would be possible.
10:48 p.m.
On Mon, Sep 20, 2010 at 10:35:47PM -0500, Bruno Wolff III wrote:
On Tue, Sep 21, 2010 at 01:51:03 +0200,
Michał Piotrowski <mkkp4x4(a)gmail.com> wrote:
>
> Setting up "official" backport repo will avoid repos fragmentation.
> Keeping all cool updates in one place appears to be a reasonable idea.
> Am I right?
If we had infinite manpower this might be doable on request. As things are,
the people that want to do this need to volunteer to do work to make it
happen. A good start would be setting up external repos and try to
maintain some group of rawhide packages for the in support releases.
If this was succesful, I expect getting Fedora infrastructure to make it
more official would be possible.
Yeah, I'd leverage this:
https://fedoraproject.org/wiki/Fedorapeople_Repos
set up a repo; use fs acls to let a group of people manage it together. See
how it goes.
-Toshio
6:49 a.m.
On Tue, 21 Sep 2010 01:51:03 +0200, Michał wrote:
Setting up "official" backport repo will avoid repos
fragmentation.
Keeping all cool updates in one place appears to be a reasonable idea.
Am I right?
Wait a minute! You need to define "fragmentation" here. It seems you refer
to the geographical location of repos only. More important is the
fragmentation caused by increasing the number of repos, especially if they
create additional targets to build for. Considering how APIs/ABIs and
stable packages are broken regularly, I don't think Fedora Packagers
could handle the increased maintenance requirements added by a backports
repo. Whether "official" or not, just imagine what can happen
if repo 1 upgrades repo 2, or vice versa, and unexpectedly. Better
attempt at making the current dist release usable/deployable in
production environments, and encourage more users to take a look at
Rawhide and Alpha/Beta releases earlier.
7:01 a.m.
On Tue, 2010-09-21 at 13:49 +0200, Michael Schwendt wrote:
On Tue, 21 Sep 2010 01:51:03 +0200, Michał wrote:
> Setting up "official" backport repo will avoid repos fragmentation.
> Keeping all cool updates in one place appears to be a reasonable idea.
> Am I right?
Wait a minute! You need to define "fragmentation" here. It seems you refer
to the geographical location of repos only. More important is the
fragmentation caused by increasing the number of repos, especially if they
create additional targets to build for. Considering how APIs/ABIs and
stable packages are broken regularly, I don't think Fedora Packagers
could handle the increased maintenance requirements added by a backports
repo. Whether "official" or not, just imagine what can happen
if repo 1 upgrades repo 2, or vice versa, and unexpectedly. Better
attempt at making the current dist release usable/deployable in
production environments, and encourage more users to take a look at
Rawhide and Alpha/Beta releases earlier.
I think he meant the same thing as you. He wasn't using 'place'
literally.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
9:20 a.m.
One thing I wanted to point out. Windows users get to install the
latest Firefox, KDE, and other apps without having to wait for a new
Windows release. If users had to wait for Windows 8 to get the latest
Firefox, things would be messy. I don't understand what the fear is of
doing this on GNU/Linux.
On Tue, Sep 21, 2010 at 8:01 AM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Tue, 2010-09-21 at 13:49 +0200, Michael Schwendt wrote:
> On Tue, 21 Sep 2010 01:51:03 +0200, Michał wrote:
>
> > Setting up "official" backport repo will avoid repos fragmentation.
> > Keeping all cool updates in one place appears to be a reasonable idea.
> > Am I right?
>
> Wait a minute! You need to define "fragmentation" here. It seems you refer
> to the geographical location of repos only. More important is the
> fragmentation caused by increasing the number of repos, especially if they
> create additional targets to build for. Considering how APIs/ABIs and
> stable packages are broken regularly, I don't think Fedora Packagers
> could handle the increased maintenance requirements added by a backports
> repo. Whether "official" or not, just imagine what can happen
> if repo 1 upgrades repo 2, or vice versa, and unexpectedly. Better
> attempt at making the current dist release usable/deployable in
> production environments, and encourage more users to take a look at
> Rawhide and Alpha/Beta releases earlier.
I think he meant the same thing as you. He wasn't using 'place'
literally.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
9:20 a.m.
Is GNU/Linux supposed to be a mirror into software's past?
On Tue, Sep 21, 2010 at 10:20 AM, Brandon Lozza <brandon(a)pwnage.ca> wrote:
One thing I wanted to point out. Windows users get to install the
latest Firefox, KDE, and other apps without having to wait for a new
Windows release. If users had to wait for Windows 8 to get the latest
Firefox, things would be messy. I don't understand what the fear is of
doing this on GNU/Linux.
On Tue, Sep 21, 2010 at 8:01 AM, Adam Williamson <awilliam(a)redhat.com> wrote:
> On Tue, 2010-09-21 at 13:49 +0200, Michael Schwendt wrote:
>> On Tue, 21 Sep 2010 01:51:03 +0200, Michał wrote:
>>
>> > Setting up "official" backport repo will avoid repos
fragmentation.
>> > Keeping all cool updates in one place appears to be a reasonable idea.
>> > Am I right?
>>
>> Wait a minute! You need to define "fragmentation" here. It seems you
refer
>> to the geographical location of repos only. More important is the
>> fragmentation caused by increasing the number of repos, especially if they
>> create additional targets to build for. Considering how APIs/ABIs and
>> stable packages are broken regularly, I don't think Fedora Packagers
>> could handle the increased maintenance requirements added by a backports
>> repo. Whether "official" or not, just imagine what can happen
>> if repo 1 upgrades repo 2, or vice versa, and unexpectedly. Better
>> attempt at making the current dist release usable/deployable in
>> production environments, and encourage more users to take a look at
>> Rawhide and Alpha/Beta releases earlier.
>
> I think he meant the same thing as you. He wasn't using 'place'
> literally.
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
> http://www.happyassassin.net
>
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
4:01 p.m.
On Tue, 21 Sep 2010 10:20:05 -0400, you wrote:
One thing I wanted to point out. Windows users get to install the
latest Firefox, KDE, and other apps without having to wait for a new
Windows release. If users had to wait for Windows 8 to get the latest
Firefox, things would be messy. I don't understand what the fear is of
doing this on GNU/Linux.
The key point of your example is that they have to actually make the
effort to go to the appropriate website (or store to buy a physical
disc), and specifically install what they want. It doesn't magically
appear when they allow Windows to do an update.
You can do the same thing on Fedora, you can if you so wish go to the
mozilla website and download the latest Firefox.
The problem facing Fedora, and Linux in general, is the distributions
blur the difference between the OS and apps by providing both. But
unless you want to encourage users to not apply security updates or
bug fixes you can't combine doing updates with upgrades.
6:40 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/21/2010 07:20 AM, Brandon Lozza wrote:
One thing I wanted to point out. Windows users get to install the
latest Firefox, KDE, and other apps without having to wait for a new
Windows release. If users had to wait for Windows 8 to get the latest
Firefox, things would be messy. I don't understand what the fear is of
doing this on GNU/Linux.
Windows releases are years apart, not even close to comparable. Also
Firefox updates are provided to the user via mozilla, not Microsoft.
The same can be done on Fedora, if you really wanted to you could go get
the new firefox from Mozilla (or somebody else who builds a more Fedora
suitable version for you).
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkyZQlcACgkQ4v2HLvE71NVvnACgmXQHpE/VAN9fEu2uqsvShmlu
tP0AoJRSFDlmK8dg5tzVqDTsXz4Kv1tp
=us5B
-----END PGP SIGNATURE-----
9:59 a.m.
On Tue, Sep 21, 2010 at 7:40 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/21/2010 07:20 AM, Brandon Lozza wrote:
> One thing I wanted to point out. Windows users get to install the
> latest Firefox, KDE, and other apps without having to wait for a new
> Windows release. If users had to wait for Windows 8 to get the latest
> Firefox, things would be messy. I don't understand what the fear is of
> doing this on GNU/Linux.
However, if for example Microsoft had a similar system and did package
software for it. Their users would be up in arms for the latest
firefox too and Microsoft wouldn't keep them on an old firefox
version. Where is the logic in NOT having the latest software as long
as it doesn't break file format compatibility? On windows the user can
also install software without having to follow a complex procedure.
They can try to grab the firefox source code, manually compile it in a
few hours and install it. They can also grab a precompiled binary that
may or may not be optimized for their distribution. On Windows its
just double click, and on Linux with package management its only a few
clicks away too.
Look at openSUSE, GCC 4.5, came out before F13, no banning of LTO. If
you want something better than stable for KDE you can one click
install the factory KDE repo. You can one click install the trunk repo
too. They even have two Chromium branches available for single click
install (version 6 and 7). Perhaps a single click or easy method of
installing a yum repo could be invented that is similar to the one in
openSUSE. That would be a good start.
I would personally rather use Fedora and not openSUSE too. Before I
receive the cop out one liner 'just use suse then'.
10:22 a.m.
On Tue, Sep 21, 2010 at 10:59:06 -0400,
Brandon Lozza <brandon(a)pwnage.ca> wrote:
However, if for example Microsoft had a similar system and did
package
software for it. Their users would be up in arms for the latest
firefox too and Microsoft wouldn't keep them on an old firefox
version. Where is the logic in NOT having the latest software as long
as it doesn't break file format compatibility? On windows the user can
Unexpectedly changing the UI is also bad.
Look at openSUSE, GCC 4.5, came out before F13, no banning of LTO.
If
you want something better than stable for KDE you can one click
install the factory KDE repo. You can one click install the trunk repo
too. They even have two Chromium branches available for single click
install (version 6 and 7). Perhaps a single click or easy method of
installing a yum repo could be invented that is similar to the one in
openSUSE. That would be a good start.
Alternate repos are possible, but take work. Fedora doesn't have spare
capacity to be doing this sort of thing right now. If you want to make it
happen, you can by leading and working on a project to do that. As long
as you are willing to work and can get a at least a few like minded
volunteers also willing to work you should have at least some success.
People here aren't against having a way to install alternate versions of
packagers per se, but are noting that there is a significant amount of
work needed. And many of us think there are better ways to be spending
our limited time helping Fedora. But if it is a high priority for other
people willing to do the work, it's something that could be done.
2:07 p.m.
If someone has enough interest in backporting something from a newer
release, we can set up a personal repo on the repos.fedorapeople.org. Just
like firefox4 and yum-rawhide repo.
Maybe we wait for Copr. Seth Vidal is working on it. We can easily set up
and manage a backport or testing repo on Copr.
But I have another question. As we know, Fedora is a fast-upgrade Linux
distribution. Many new features will be added in every release. If we
backport the most desirable features, how should we attract users to upgrade
to the latest one? Do we hope that Fedora becomes a rolling upgrade
distribution?
On Tue, Sep 21, 2010 at 11:22 PM, Bruno Wolff III <bruno(a)wolff.to> wrote:
On Tue, Sep 21, 2010 at 10:59:06 -0400,
Brandon Lozza <brandon(a)pwnage.ca> wrote:
> However, if for example Microsoft had a similar system and did package
> software for it. Their users would be up in arms for the latest
> firefox too and Microsoft wouldn't keep them on an old firefox
> version. Where is the logic in NOT having the latest software as long
> as it doesn't break file format compatibility? On windows the user can
Unexpectedly changing the UI is also bad.
> Look at openSUSE, GCC 4.5, came out before F13, no banning of LTO. If
> you want something better than stable for KDE you can one click
> install the factory KDE repo. You can one click install the trunk repo
> too. They even have two Chromium branches available for single click
> install (version 6 and 7). Perhaps a single click or easy method of
> installing a yum repo could be invented that is similar to the one in
> openSUSE. That would be a good start.
Alternate repos are possible, but take work. Fedora doesn't have spare
capacity to be doing this sort of thing right now. If you want to make it
happen, you can by leading and working on a project to do that. As long
as you are willing to work and can get a at least a few like minded
volunteers also willing to work you should have at least some success.
People here aren't against having a way to install alternate versions of
packagers per se, but are noting that there is a significant amount of
work needed. And many of us think there are better ways to be spending
our limited time helping Fedora. But if it is a high priority for other
people willing to do the work, it's something that could be done.
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Fedora && Debian User, former Ubuntu User
My Page: http://www.liangsuilong.info
Fedora Project Contributor -- Packager && Ambassador
https://fedoraproject.org/wiki/User:Liangsuilong
2:10 p.m.
On Wed, 2010-09-22 at 03:07 +0800, Liang Suilong wrote:
If someone has enough interest in backporting something from a newer
release, we can set up a personal repo on the repos.fedorapeople.org.
Just like firefox4 and yum-rawhide repo.
Maybe we wait for Copr. Seth Vidal is working on it. We can easily set
up and manage a backport or testing repo on Copr.
I'm not alone. Toshio, mapleoin are doing the heavy lifting
http://mapleoin.bluepink.ro/tag/copr.html
for lots of info.
-sv
4:45 p.m.
On Tue, 21 Sep 2010 10:59:06 -0400, you wrote:
However, if for example Microsoft had a similar system and did
package
software for it. Their users would be up in arms for the latest
firefox too and Microsoft wouldn't keep them on an old firefox
version.
You are ignoring the troubles Microsoft has had in trying to get its
users to update IE.
Where is the logic in NOT having the latest software as long
as it doesn't break file format compatibility? On windows the user can
I think it wonderful that you always want the latest software, but
just ask that you consider the view of other people who are trying to
get their job done.
Many of the people using Fedora are using it as a tool to get their
normal work done. While file format compatibility is one issue,
anything that disrupts their ability to get their job done should be
avoided mid-release. This can be a changing in the GUI layout, the
ability of plugins to work, or a new version having more bugs.
Look at openSUSE, GCC 4.5, came out before F13, no banning of LTO. If
The decision on gcc would have to have been made around January, to
allow time for any bugs to be worked out both in gcc and in any
software included in Fedora 13. I would assume that the gcc
maintainers felt it wasn't ready at that time, plus most of the useful
stuff had already been backported by them into the Fedora version of
gcc 4.4.
As far as LTO, the Fedora gcc maintainers have decided that it is not
yet stable and ready to be used. The fact that you don't believe the
issues with LTO are important, or that openSUSE doesn't, isn't
relevant to Fedora. What is relevant is that the Fedora expert(s) on
gcc have decided that it isn't ready for use yet.
you want something better than stable for KDE you can one click
install the factory KDE repo. You can one click install the trunk repo
too. They even have two Chromium branches available for single click
install (version 6 and 7). Perhaps a single click or easy method of
installing a yum repo could be invented that is similar to the one in
openSUSE. That would be a good start.
Like anything else, if it is important to you then you can work on
implementing it. Fedora is limited in what can be done by what the
volunteers doing the work actually do.
4:57 p.m.
On Tue, Sep 21, 2010 at 15:45, Gerald Henriksen <ghenriks(a)gmail.com> wrote:
>you want something better than stable for KDE you can one click
>install the factory KDE repo. You can one click install the trunk repo
>too. They even have two Chromium branches available for single click
>install (version 6 and 7). Perhaps a single click or easy method of
>installing a yum repo could be invented that is similar to the one in
>openSUSE. That would be a good start.
Like anything else, if it is important to you then you can work on
implementing it. Fedora is limited in what can be done by what the
volunteers doing the work actually do.
I think that is a key element here that people should remember: When
someone says "I want X" it can sound a lot like "You must do X" which
always sounds like make-work and demanding another volunteer to do
something.
--
Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
— Herb Kelleher, founder Southwest Airlines
11:34 p.m.
On Tue, 2010-09-21 at 10:59 -0400, Brandon Lozza wrote:
On Tue, Sep 21, 2010 at 7:40 PM, Jesse Keating
<jkeating(a)redhat.com> wrote:
> On 09/21/2010 07:20 AM, Brandon Lozza wrote:
>> One thing I wanted to point out. Windows users get to install the
>> latest Firefox, KDE, and other apps without having to wait for a new
>> Windows release. If users had to wait for Windows 8 to get the latest
>> Firefox, things would be messy. I don't understand what the fear is of
>> doing this on GNU/Linux.
In my personal opinion, Windows makes mistakes, but is more enlightened
when it comes to embracing users installing stuff they did not get from
Microsoft. On non-enterprise Linux systems, the libraries and userland
change so often you really do need to either have a third party building
for every release, or getting it in the distro (which isn't always
practical or possible). I'm sure I'll be told how "wrong" I am.
However, if for example Microsoft had a similar system and did
package
software for it. Their users would be up in arms for the latest
firefox too and Microsoft wouldn't keep them on an old firefox
version. Where is the logic in NOT having the latest software as long
as it doesn't break file format compatibility?
You know what's kinda cool about some other Operating Systems? (Linux,
non-Linux, etc.) You install them, then they always work the same way
until you decide to upgrade them one day (when you set aside time to fix
all the "this shouldn't be a problem, but oh yea, there's that corner
case that..." issues). All the bugs are consistent, if you plug in a
gizmo it works or doesn't, but there are few random surprises. I love
lack of random surprises. It's not just file formats and the innards.
I'd rather see either a backports repo with all the junk, or just no
junk and only have new stuff land in the next release. That changes
nothing about Fedora releases, other than adding predictability.
Jon.
4:19 a.m.
On Tue, Sep 21, 2010 at 01:51:03AM +0200, Michał Piotrowski wrote:
2010/9/21 Toshio Kuratomi <a.badger(a)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.
We already do this for virtualization features:
http://fedoraproject.org/wiki/Virtualization_Preview_Repository
It's a fair amount of work for Justin.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html
4963
days inactive
4966
days old
88 comments
26 participants
participants (26)
-
Adam Williamson -
Al Dunsmuir -
Arthur Pemberton -
Benny Amorsen -
Björn Persson -
Brandon Lozza -
Bruno Wolff III -
Dave Jones -
drago01 -
Gerald Henriksen -
James Antill -
Jef Spaleta -
Jesse Keating -
Jon Masters -
Liang Suilong -
Michael Cronenworth -
Michael Schwendt -
Michał Piotrowski -
Michel Alexandre Salim -
Nicolas Mailhot -
Rahul Sundaram -
Richard Hughes -
Richard W.M. Jones -
Seth Vidal -
Stephen John Smoogen -
Toshio Kuratomi