[Fwd: Wikipidia - Goodbye Red Hat and Fedora]

[itamar]

forwarding message from Rodrigo Padula

any chance to increase the life of fedora releases ?

or fedora will be only blending edge ?

In my opinion fedora is losing space from centos and ubuntu


-------- Original Message --------
Subject: 	Wikipidia - Goodbye Red Hat and Fedora
Date: 	Fri, 10 Oct 2008 09:42:55 -0300
From: 	Rodrigo Padula de Oliveira <rodrigopadula(a)projetofedora.org&gt;
Reply-To: 	For discussions about marketing and expanding the Fedora user 
base <fedora-marketing-list(a)redhat.com&gt;
To: 	For discussions about marketing and expanding the Fedora user base 
<fedora-marketing-list(a)redhat.com&gt;



Hello Guys!

Read this bad news:

http://www.linuxworld.com.au/index.php/id;1474805050;fp;16;fpid;1

This is happening frequently. I think we will have to revise some things
within the project, particularly the creation of a Legacy project or a
Fedora LTS.

The brazilian government, one of the biggest Fedora Case of the world is
changing from Fedora/ Red Hat to Ubuntu/Debian.

We need to think and create a solution to give support by a long time or
the fedora user will decrease!

My 0,02

-- 

Rodrigo Padula de Oliveira
M.Sc. Student - COPPE/UFRJ
Fedora Community Manager - Latin America
http://www.proyectofedora.org



-- 
Fedora-marketing-list mailing list
Fedora-marketing-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-marketing-list

[Mark Bidewell]

I would have to reply that rapid development is one of the reasons I love
Fedora.  Fedora fill a specific niche that fall between a Gentoo/LFS
mentality (although in the past I have seen Fedora RPMs more up to date than
Gentoo Ebuilds) and the superstable world of Debian and RHEL/CentOS.
Ubuntu releases, also fit into this category although they do not move as
rapidly as Fedora.  I would submit that CentOS/RHEL IS the equivalent of
Fedora LTS.  Also, personally I have found Fedora to be more stable than
Ubuntu.  IMOFedora needs to stay true to its purpose, and let the users
choose if that is appropriate for them.

Mark Bidewell

On Fri, Oct 10, 2008 at 8:53 AM, Itamar - IspBrasil <itamar(a)ispbrasil.com.br
>  wrote: 
>  forwarding message from Rodrigo Padula
>
>  any chance to increase the life of fedora releases ?
>
>  or fedora will be only blending edge ?
>
>  In my opinion fedora is losing space from centos and ubuntu
>
>
>  -------- Original Message --------
>  Subject:        Wikipidia - Goodbye Red Hat and Fedora
>  Date:   Fri, 10 Oct 2008 09:42:55 -0300
>  From:   Rodrigo Padula de Oliveira <rodrigopadula(a)projetofedora.org&gt;
>  Reply-To:       For discussions about marketing and expanding the Fedora
>  user base <fedora-marketing-list(a)redhat.com&gt;
>  To:     For discussions about marketing and expanding the Fedora user base
>  <fedora-marketing-list(a)redhat.com&gt;
>
>
>
>  Hello Guys!
>
>  Read this bad news:
>
>  http://www.linuxworld.com.au/index.php/id;1474805050;fp;16;fpid;1
>
>  This is happening frequently. I think we will have to revise some things
>  within the project, particularly the creation of a Legacy project or a
>  Fedora LTS.
>
>  The brazilian government, one of the biggest Fedora Case of the world is
>  changing from Fedora/ Red Hat to Ubuntu/Debian.
>
>  We need to think and create a solution to give support by a long time or
>  the fedora user will decrease!
>
>  My 0,02
>
>  --
>
>  Rodrigo Padula de Oliveira
>  M.Sc. Student - COPPE/UFRJ
>  Fedora Community Manager - Latin America
>  http://www.proyectofedora.org
>
>
>
>  --
>  Fedora-marketing-list mailing list
>  Fedora-marketing-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-marketing-list
>
>
>
>
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

[Matej Cepl]

On 2008-10-10, 13:13 GMT, Mark Bidewell wrote:
>  I would submit that CentOS/RHEL IS the equivalent of
>  Fedora LTS. 
I would venture even to say that CentOS *is* Fedora LTS, and (I 
am not sure whether they would agree, having apparently some bad 
experience with PNALD) that they are part of the "Fedora family 
of distributions" as its long-term-supported member.

Matej

[Pavel Alexeev (aka Pahan-Hubbitus)]

Matej Cepl пишет:
>  On 2008-10-10, 13:13 GMT, Mark Bidewell wrote:
> > I would submit that CentOS/RHEL IS the equivalent of
> > Fedora LTS.
>  
>  I would venture even to say that CentOS *is* Fedora LTS 
I agree what CentOS is more
stable and has more time support, but it is 
totally not equivalent of Fedora. Just see CVS branches of programs for 
Fedora and RHEL. So, many (notably new and not highly famous) programs 
is not present in RHEL and CentOS.

[Rahul Sundaram]

Pavel Alexeev (aka Pahan-Hubbitus) wrote:
>  Matej Cepl пишет:
> > On 2008-10-10, 13:13 GMT, Mark Bidewell wrote:
> >> I would submit that CentOS/RHEL IS the equivalent of
> >> Fedora LTS.
> >
> > I would venture even to say that CentOS *is* Fedora LTS
>  I agree what CentOS is more stable and has more time support, but it is 
>  totally not equivalent of Fedora. Just see CVS branches of programs for 
>  Fedora and RHEL. So, many (notably new and not highly famous) programs 
>  is not present in RHEL and CentOS. 
About 2000 more in EPEL. http://fedoraproject.org/wiki/EPEL. 
Participate, if you would like to see your (missing) favourites as well.

Rahul

[Pavel Alexeev (aka Pahan-Hubbitus)]

Rahul Sundaram пишет:
>  Pavel Alexeev (aka Pahan-Hubbitus) wrote:
> > Matej Cepl пишет:
> >> On 2008-10-10, 13:13 GMT, Mark Bidewell wrote:
> >>> I would submit that CentOS/RHEL IS the equivalent of
> >>> Fedora LTS.
> >>
> >> I would venture even to say that CentOS *is* Fedora LTS
> > I agree what CentOS is more stable and has more time support, but it 
> > is totally not equivalent of Fedora. Just see CVS branches of programs 
> > for Fedora and RHEL. So, many (notably new and not highly famous) 
> > programs is not present in RHEL and CentOS.
>  
>  About 2000 more in EPEL. http://fedoraproject.org/wiki/EPEL. 
>  Participate, if you would like to see your (missing) favourites as well.
>  
>  Rahul
>   
Off course. This is not reproach. I'm only constant fact - CentOS is far 
  from "Fedora LTS" equivalent. So, I'm choose Fedora and participate in 
it. And, with think what Fedora no needed LTS, any similar it is highly 
needed for servers, I thought sometimes.

[Patrice Dumas]

On Fri, Oct 10, 2008 at 09:13:44AM -0400, Mark Bidewell wrote:
>  I would have to reply that rapid development is one of the reasons I
> love
>  Fedora.  Fedora fill a specific niche that fall between a Gentoo/LFS
>  mentality (although in the past I have seen Fedora RPMs more up to date than
>  Gentoo Ebuilds) and the superstable world of Debian and RHEL/CentOS.
>  Ubuntu releases, also fit into this category although they do not move as
>  rapidly as Fedora.  I would submit that CentOS/RHEL IS the equivalent of
>  Fedora LTS.  Also, personally I have found Fedora to be more stable than
>  Ubuntu.  IMOFedora needs to stay true to its purpose, and let the users
>  choose if that is appropriate for them. 
I mostly agree, however it seems to me that a true Fedora LTS is
missing, that would allow those who want things that are new, including 
for testing but cannot afford changing everything each year (servers for 
example or user desktops). It seems to me that fedora ends up being used
almost exclusively as single user desktop, so that testing of other
functionalities is likely to be less widespread. Fortunately, those
functionnalities certainly need less integration and so less testing in
fedora before they go to RHEL/CENTOS + EPEL, but still it would
certainly have some relevance, in my opinion.

--
Pat

[Jesse Keating]

On Fri, 2008-10-10 at 16:31 +0200, Patrice Dumas wrote:
>  I mostly agree, however it seems to me that a true Fedora LTS is
>  missing, that would allow those who want things that are new, including 
>  for testing but cannot afford changing everything each year (servers for 
>  example or user desktops). It seems to me that fedora ends up being used
>  almost exclusively as single user desktop, so that testing of other
>  functionalities is likely to be less widespread. Fortunately, those
>  functionnalities certainly need less integration and so less testing in
>  fedora before they go to RHEL/CENTOS + EPEL, but still it would
>  certainly have some relevance, in my opinion. 
Given the amount of churn we allow maintainers to introduce into our
"stable" releases, I highly doubt Fedora would be suitable for any
situation where a "LTS" was desired.  There is just too much major
version upgrading, behavioral changes, massive amounts of updates,
rapidly invalid documentation, and high chance of regression in the
"stable" updates.  We should address *that* problem before ever thinking
about extending the life.

-- 
Jesse Keating RHCE      (http://jkeating.livejournal.com)
Fedora Project          (http://fedoraproject.org/wiki/JesseKeating)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
identi.ca               (http://identi.ca/jkeating)

[casimiro barreto]

Itamar - IspBrasil escreveu:
>  forwarding message from Rodrigo Padula
>
>  any chance to increase the life of fedora releases ?
>
>  or fedora will be only blending edge ?
>
>  In my opinion fedora is losing space from centos and ubuntu
>
>
>  -------- Original Message -------- 
But that's not all. Besides increasing life
of releases it is important
to keep things working between updates (currently that's not the case)
and taking care of reported bugs before introducing new features and/or
advancing versions. Few examples:

    * GDM: the "bleeding edge" version was adopted in Rel 9. But there
      is no documentation on how to properly configure it. So, it you
      want to allow remote  applications to open windows in your desktop
      you have to migrate to KDM (no way to get rid of the -nolisten in
      GDM).
    * RHGB  that is scheduled to disappear stop working after I updated
      system 1 1/2 month ago.
    * pam_mount stop working properly about 2 months ago.
    * ...

Obviously this kind of situation prevents the use of Fedora in critical
mission environments and makes the distribution more attractive to geeks
that can expend unpayed hours bringing back to life things that were
already working.

CdAB

[Rui Miguel Silva Seabra]

>      * GDM: the "bleeding edge" version was adopted in Rel
> 9. But there
>        is no documentation on how to properly configure it. So, it you
>        want to allow remote  applications to open windows in your desktop
>        you have to migrate to KDM (no way to get rid of the -nolisten in
>        GDM). 
Using "-nolisten tcp" by default Is Good.

Yes you can get it back if you have a strong reason (like you seem to
have) for it :)

If you have a strong reason for it, then you're in a very small minority
of more advanced users :)

Rui

-- 
Fnord.
Today is Pungenday, the 64th day of Bureaucracy in the YOLD 3174
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

[casimiro barreto]

Rui Miguel Silva Seabra escreveu:
>  Using "-nolisten tcp" by default Is Good.
>  Yes you can get it back if you have a strong reason (like you seem to
>  have) for it :)
>
>  If you have a strong reason for it, then you're in a very small minority
>  of more advanced users :)
>
>  Rui
>
>     
I agree about the security issue. That's not the point. The point is
that something documented was changed by something undocumented that
just doesn't work like the previous version.

Besides, I think that the discussion about "real environments" and
"development environments" is merely academic. I think that for unstable
and undocumented features the right place is the rawhide repository.
When something migrates from rawhide to the mainstream release/update
repositories then it should provide a nice migration.

I agree that Fedora is aimed to development. But not everybody is
developing everything and having to stop what you're doing (especially
if you have only a limited amount of time available) to
reconfigure/retrofit something that was previously working is annoying
and counterproductive.

[Dmitry Butskoy]

Itamar - IspBrasil wrote:
>  any chance to increase the life of fedora releases ?
>
>  or fedora will be only blending edge ?
>
>  In my opinion fedora is losing space from centos and ubuntu 
...

>  The brazilian government, one of the biggest Fedora Case of the world
> is
>  changing from Fedora/ Red Hat to Ubuntu/Debian. 
The problem was at an initial point, when Fedora was considered "for 
enthusiasts only". A lot of previous "RedHat Linux enthusiasts" just 
switch to CentOS (and similar RHEL-based systems), no more using Fedora, 
because "it is marked as a non-for-production system even by its creators".

As a result, the amount of Fedora-testers in real production 
environments significantly decreases. Fedora development seems to be 
focused on Desktop and some conseptual things now, rather than a real 
"production" life. Perhaps some marketing people assume that 
"production" implies the purchase of RHEL and commercial support, rather 
than trying to use some free-of-charge system, because such a system 
should be unstable for production environment. But people do not want to 
pay and they use CentOS instead...

This situation seems to be reflected in the Fedora project itself. 
Guess, how many Fedora infrastructure servers are run under the latest 
"stable" Fedora release? Maybe some previois release? How many key 
people work under Fedora Desktop "all the time"? (Maybe RedHat employees 
of them are compelled to use RHEL Desktop in basic working hours?)

And finally, when you will discover the actual situation, ask yourself 
-- why Brasilian should use Fedora (and Fedora-based RHEL), when even 
Fedora's fathers do not use it for anything real?


Sorry for a little bit sarcasm though...

~buc

[Jeffrey Ollie]

On Fri, Oct 10, 2008 at 8:33 AM, Dmitry Butskoy <buc(a)odusz.so-cdu.ru&gt; wrote:
>  This situation seems to be reflected in the Fedora project itself. Guess,
>  how many Fedora infrastructure servers are run under the latest "stable"
>  Fedora release? 
Almost none.  The reason is simple - the Fedora project does not have
infinite resources, the most important of which is time.  As can be
seen from the recent intrusion, completely rebuilding the
infrastructure takes a lot of time and causes a lot of pain.  It's a
better use of human resources to use RHEL in the Fedora Infrastructure
so we don't have to be continually rebuilding systems and we can focus
our time on other things.

>  And finally, when you will discover the actual situation, ask
> yourself --
>  why Brasilian should use Fedora (and Fedora-based RHEL),
>  when even Fedora's fathers do not use it for anything real? 
What do you mean by "real" - I sit in front of Fedora systems almost
all day long.  Why doesn't that count as "real"?

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"

[Dmitry Butskoy]

Jeffrey Ollie wrote:
>  On Fri, Oct 10, 2008 at 8:33 AM, Dmitry Butskoy
> <buc(a)odusz.so-cdu.ru&gt; wrote:
>    
> > This situation seems to be reflected in the Fedora project itself. Guess,
> > how many Fedora infrastructure servers are run under the latest "stable"
> > Fedora release?
> >     
>
>  Almost none.  The reason is simple - the Fedora project does not have
>  infinite resources, the most important of which is time.  As can be
>  seen from the recent intrusion, completely rebuilding the
>  infrastructure takes a lot of time and causes a lot of pain.  It's a
>  better use of human resources to use RHEL in the Fedora Infrastructure
>  so we don't have to be continually rebuilding systems  
I would prefer that Fedora would be stable enough, thus does not require 
"continually rebuilding systems" ;)

When the infrastructure of some distribution use this distribution 
immediately, the quality of the distribution is compelled to be much 
higher. In other words, when you create a bug, it is much better when 
this bug strikes your head at the same time, rather than someone will 
report it in bugzilla, where it will be delayed for a long time...


~buc

[Chris Adams]

Once upon a time, Dmitry Butskoy <buc(a)odusz.so-cdu.ru&gt; said:
>  I would prefer that Fedora would be stable enough, thus does not
> require 
>  "continually rebuilding systems" ;) 
It isn't just an issue of stability; it is an issue of long-term
support.  Fedora does not have the manpower and/or interest to support
releases for a long time (as seen by the failure of the Fedora Legacy
project).  The goal of Fedora is to get new features and technology in
the hands of developers as fast as practical, so there are two releases
a year.  There are people interested in long-term support, but not
enough to make it happen.

If Fedora tried to support a release for even 3 years, that would be 6
different releases to support, which would require a large investment in
time, additional infrastructure (to handle up to 3 times as many active
packages), etc.  Would it be nice if that happened?  Sure, but the
demand does not magically produce the manpower to make it so.

That's part of why people pay Red Hat for RHEL: Red Hat does support a
release for years (7 or 8 IIRC now).  Basically, Red Hat takes a
snapshot of Fedora, reduces it to a core set of packages they think they
can support (both now and long-term), runs it through some additional
QA, and produces a RHEL release.  CentOS then takes the source to that
RHEL release and rebuilds it to produce a compatible free release.  Red
Hat does much of the "heavy lifting" involved in supporting a release
for a long time and CentOS has their own infrastructure to support it
for free uses.

Since Fedora releases are only supported for about 1 year, servers on
the Internet running Fedora need to upgraded at least that often.  There
are a lot of servers supporting the Fedora infrastructure, and it would
be a significant amount of work to upgrade them all every year.  So it
makes sense to use RHEL and/or CentOS (which are after all derived from
Fedora) on the infrastructure servers, so the limited support manpower
can spend time doing more productive things than just upgrading servers.

-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Ralf Corsepius]

On Fri, 2008-10-10 at 09:08 -0500, Jeffrey Ollie wrote:
>  On Fri, Oct 10, 2008 at 8:33 AM, Dmitry Butskoy
> <buc(a)odusz.so-cdu.ru&gt; wrote:
>  >
>  > This situation seems to be reflected in the Fedora project itself. Guess,
>  > how many Fedora infrastructure servers are run under the latest "stable"
>  > Fedora release?
>  
>  Almost none.  The reason is simple - the Fedora project does not have
>  infinite resources, the most important of which is time. 
Yes, the reasons are simple, but I see different reasons than you:
* Fedora has focused too much on Desktops.
* The Fedora project works inefficiently (too much bureaucracy, too many
"closed circles", too little cooperation, too much egoism ...)

=> Result: Lack of people.

Ralf

[Jon Stanley]

On Fri, Oct 10, 2008 at 9:33 AM, Dmitry Butskoy <buc(a)odusz.so-cdu.ru&gt; wrote:

>  The problem was at an initial point, when Fedora was considered
> "for
>  enthusiasts only". A lot of previous "RedHat Linux enthusiasts" just
> switch
>  to CentOS (and similar RHEL-based systems), no more using Fedora, because
>  "it is marked as a non-for-production system even by its creators". 
Well, in all fairness, Fedora's stated goal is to advance the state of
free software. You get that by being bleeding-edge. Unfortunately,
being bleeding edge also means not being suitable for production
environments - these are two fundamentally incompatible goals. This is
why Red Hat Linux split into two - Fedora and RHEL. RHEL is a
derivative distribution of Fedora.

>  As a result, the amount of Fedora-testers in real production
> environments
>  significantly decreases. Fedora development seems to be focused on Desktop
>  and some conseptual things now, rather than a real "production" life. 
There's plenty of stuff going into Fedora aimed at production systems.
Take for example FreeIPA for one. It started life in Fedora quite a
while back, and is now Red Hat Enterprise IPA. That's just one
example. Others are:

SELinux
LVM2
Xen
Tickless kernel (I'd bet good money we'll be seeing it in RHEL6)

We're also working on getting Spacewalk into Fedora, which is neither
aimed at desktop users nor a "conceptual" thing. Fedora exists to
foster innovation, with this mission sometimes comes breakage. We
simply want to prepare folks for that.;

>  Perhaps some marketing people assume that "production"
> implies the purchase
>  of RHEL and commercial support, rather than trying to use some
>  free-of-charge system, because such a system should be unstable for
>  production environment. But people do not want to pay and they use CentOS
>  instead.. 
That's fine.  The problem is not "marketing" that Fedora is viewed as
unstable for production use (and let me clarify the word production
here - something that you need up 24/7/365), it's technical. As I
stated before, the stated goals of Fedora are incompatible with
production use as I have defined it.
.
>  This situation seems to be reflected in the Fedora project itself.
> Guess,
>  how many Fedora infrastructure servers are run under the latest "stable"
>  Fedora release? Maybe some previois release? How many key people work under 
Not many, they are mostly RHEL (actually none that I personally know
of, but I think that the systems that create livecd's have to be if
I'm not mistaken), for exactly the reasons stated before.

>  Fedora Desktop "all the time"? (Maybe RedHat employees of
> them are compelled
>  to use RHEL Desktop in basic working hours?) 
I'm not a Red Hat employee, but I'm pretty sure that they aren't
"compelled" to do anything. And lots of developers that I know run
rawhide all the time. A quick rundown of my machines at home:

Main desktop: Fedora 8

Main laptop: Fedora 9

Testing laptop: rawhide du jour

VM server: RHEL5.2 (may change this to F9 and kvm in the near future),
experiencing some weird Xen issues relating to Fedora testing.

DNS/DHCP: CentOS 4.6

VM's - depends on what they do :)

>  And finally, when you will discover the actual situation, ask
> yourself --
>  why Brasilian should use Fedora (and Fedora-based RHEL), when even Fedora's
>  fathers do not use it for anything real? 
Define "anything real". Of course it's used for real stuff. I'm
writing this on my F9 laptop right now.

[Jarod Wilson]

On Friday 10 October 2008 10:13:57 Jon Stanley wrote:
>  On Fri, Oct 10, 2008 at 9:33 AM, Dmitry Butskoy
> <buc(a)odusz.so-cdu.ru&gt; wrote: 
[...]
>  > Fedora Desktop "all the time"? (Maybe RedHat employees
> of them are
>  > compelled to use RHEL Desktop in basic working hours?)
>
>  I'm not a Red Hat employee, but I'm pretty sure that they aren't
>  "compelled" to do anything. 
That would be correct.

>  And lots of developers that I know run
>  rawhide all the time. 
Yep. My IBM ThinkPad T61 laptop, which I use for 99% of my $dayjob desktop use 
(docked on a ThinkPad Advanced Dock) is running rawhide. I've got several 
development boxes here in the office that are a mix of the latest RHEL and 
latest rawhide, as I have both package and kernel work to do on both. Some of 
'em have both rawhide and RHEL installs too.

On the home front, my personal web and mail server is still lagging behind on 
Fedora 9, but will get upgraded soon (yes, I consider running Fedora 9 to be 
lagging behind ;). My mythtv boxes, my tinkering desktop system at home, my 
Acer Aspire One netbook and my AppleTV, all running rawhide as well.

Also, taking off my Red Hat hat and speaking purely from a personal point of 
view, I'd echo the sentiment that CentOS pretty much *is* Fedora LTS for those 
that want such a thing.

-- 
Jarod Wilson
jarod(a)redhat.com

[Pavel Alexeev (aka Pahan-Hubbitus)]

Jon Stanley пишет:
>  Well, in all fairness, Fedora's stated goal is to advance the
> state of
>  free software. You get that by being bleeding-edge. Unfortunately,
>  being bleeding edge also means not being suitable for production
>  environments - these are two fundamentally incompatible goals. This is
>  why Red Hat Linux split into two - Fedora and RHEL. RHEL is a
>  derivative distribution of Fedora. 
All sounds good, by RHEL is not free. So, in
this case many people 
pointed to CentOS, and I agree with it, but it is even not RedHat or 
Fedora initiative.

[Nicu Buculei]

Pavel Alexeev (aka Pahan-Hubbitus) wrote:
>  Jon Stanley пишет:
>   > Well, in all fairness, Fedora's stated goal is to advance the state of
> > free software. You get that by being bleeding-edge. Unfortunately,
> > being bleeding edge also means not being suitable for production
> > environments - these are two fundamentally incompatible goals. This is
> > why Red Hat Linux split into two - Fedora and RHEL. RHEL is a
> > derivative distribution of Fedora.
>  All sounds good, by RHEL is not free. So, in this case many people  
It may not be free but id Free.

>  pointed to CentOS, and I agree with it, but it is even not RedHat or
>
>  Fedora initiative. 
Does it matter who's the initiative from? if the bits, the license and 
the price are right...

-- 
nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com
Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/
Open Clip Art Library: http://www.openclipart.org
my Fedora stuff: http://fedora.nicubunu.ro

[Richard Hughes]

On Fri, 2008-10-10 at 17:33 +0400, Dmitry Butskoy wrote:
>  Maybe RedHat employees of them are compelled to use RHEL Desktop in
>  basic working hours? 
No. I spend 99% of my time in F9 or rawhide.

Richard.

[Toshio Kuratomi]

Dmitry Butskoy wrote:
>  Itamar - IspBrasil wrote:
> >
> > any chance to increase the life of fedora releases ?
> >
> > or fedora will be only blending edge ?
> >
> > In my opinion fedora is losing space from centos and ubuntu
>  
>  ...
>  
> > The brazilian government, one of the biggest Fedora Case of the world is
> > changing from Fedora/ Red Hat to Ubuntu/Debian.
>  
>  The problem was at an initial point, when Fedora was considered "for
>  enthusiasts only". A lot of previous "RedHat Linux enthusiasts" just
>  switch to CentOS (and similar RHEL-based systems), no more using Fedora,
>  because "it is marked as a non-for-production system even by its creators".
>   
The fact that they switched to CentOS is *good* for Fedora.  CentOS's
goals are better oriented to the needs of someone that wants to deploy a
system and run it for years.  Fedora is good for people who want to get
the latest technologies from upstream as soon as they're stable enough
to integrate into a running system.  At the same time, CentOS is a
derivative distro of Fedora.  That means that the things you learn in
CentOS will have some bearing on Fedora; the things you learn in Fedora
will have some bearing on CentOS; and if you want to affect the packages
and decisions that go into the next version of CentOS, you can have a
great deal of impact by working on those changes within Fedora.

>  
>  This situation seems to be reflected in the Fedora project itself.
>  Guess, how many Fedora infrastructure servers are run under the latest
>  "stable" Fedora release? 
As few as possible.  The reason is not about stability.  It is about
updates.  Once Fedora stops getting updates we'd have to upgrade to the
next Fedora release with all of the churn that causes for vastly
unrelated pieces of the OS.  We'd much rather spend our time developing
new features of the infrastructure and fixing bugs in our software and
deployments than updating the OS every six months and figuring out what
caused our current services to break when we do.

>  Maybe some previois release? How many key
>  people work under Fedora Desktop "all the time"? 
I'll also add my voice here as someone who runs Fedora on all his
machines.  But I have a question of my own: is this a question intended
to inform you of the true facts of what percent of key contributors run
Fedora?  Or leading question intended to make people think that Red Hat
employees do not run Fedora without any prior research into the matter?

>  (Maybe RedHat employees
>  of them are compelled to use RHEL Desktop in basic working hours?)
>   
Untrue.

>  And finally, when you will discover the actual situation, ask
> yourself
>  -- why Brasilian should use Fedora (and Fedora-based RHEL), when even
>  Fedora's fathers do not use it for anything real?
>   
So on the one hand, since your base assumptions about usage of Fedora by
key people is not based in fact, I probably shouldn't answer this.  On the
other, I'd like to say that there are different distributions for
different purposes.  CentOS and RHEL fill one important niche that
Fedora is unsuited for due to its fast pace.  Fedora, in turn, is going
to be the place where people who want to get their hands on new
technology sooner are going to want to be.

As for your particular use-case, mentioned in another message, it sounds
like you want to be using CentOS/RHEL and backporting the services you
need (as you say you do now).  A distribution is going to be hard
pressed to do what you want in all cases because they have to keep
sanity for all their different customers.  If you need a new version of
libxml2 to get a hot new feature, will that cause problems for other
customers?  If they need a new version of apache because the modules
they're developing requires it will that cause problems for you?

-Toshio

[Arthur Pemberton]

2008/10/10 Toshio Kuratomi <a.badger(a)gmail.com&gt;:
>  Dmitry Butskoy wrote:
> > Itamar - IspBrasil wrote:
> >>
> >> any chance to increase the life of fedora releases ?
> >>
> >> or fedora will be only blending edge ?
> >>
> >> In my opinion fedora is losing space from centos and ubuntu
> >
> > ...
> >
> >> The brazilian government, one of the biggest Fedora Case of the world is
> >> changing from Fedora/ Red Hat to Ubuntu/Debian.
> >
> > The problem was at an initial point, when Fedora was considered "for
> > enthusiasts only". A lot of previous "RedHat Linux enthusiasts" just
> > switch to CentOS (and similar RHEL-based systems), no more using Fedora,
> > because "it is marked as a non-for-production system even by its
> creators".
> >
>  The fact that they switched to CentOS is *good* for Fedora.  CentOS's
>  goals are better oriented to the needs of someone that wants to deploy a
>  system and run it for years. 

They switched to Debian and Ubuntu. There is no evidence that they
considered Centos.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )

[Mike McGrath]

On Fri, 10 Oct 2008, Arthur Pemberton wrote:

>  2008/10/10 Toshio Kuratomi <a.badger(a)gmail.com&gt;:
>  > Dmitry Butskoy wrote:
>  >> Itamar - IspBrasil wrote:
>  >>>
>  >>> any chance to increase the life of fedora releases ?
>  >>>
>  >>> or fedora will be only blending edge ?
>  >>>
>  >>> In my opinion fedora is losing space from centos and ubuntu
>  >>
>  >> ...
>  >>
>  >>> The brazilian government, one of the biggest Fedora Case of the world is
>  >>> changing from Fedora/ Red Hat to Ubuntu/Debian.
>  >>
>  >> The problem was at an initial point, when Fedora was considered "for
>  >> enthusiasts only". A lot of previous "RedHat Linux enthusiasts"
> just
>  >> switch to CentOS (and similar RHEL-based systems), no more using Fedora,
>  >> because "it is marked as a non-for-production system even by its
> creators".
>  >>
>  > The fact that they switched to CentOS is *good* for Fedora.  CentOS's
>  > goals are better oriented to the needs of someone that wants to deploy a
>  > system and run it for years.
>
>
>  They switched to Debian and Ubuntu. There is no evidence that they
>  considered Centos.
>
>  
According to the CentOS guys, they used CentOS at some point in time.

	-Mike

[Toshio Kuratomi]

Arthur Pemberton wrote:
>  2008/10/10 Toshio Kuratomi <a.badger(a)gmail.com&gt;:
> > Dmitry Butskoy wrote:
> >>
> >>> The brazilian government, one of the biggest Fedora Case of the world is
> >>> changing from Fedora/ Red Hat to Ubuntu/Debian.
> >> The problem was at an initial point, when Fedora was considered "for
> >> enthusiasts only". A lot of previous "RedHat Linux enthusiasts"
> just
> >> switch to CentOS (and similar RHEL-based systems), no more using Fedora,
> >> because "it is marked as a non-for-production system even by its
> creators".
> >>
> > The fact that they switched to CentOS is *good* for Fedora.  CentOS's
> > goals are better oriented to the needs of someone that wants to deploy a
> > system and run it for years.
>  
>  
>  They switched to Debian and Ubuntu. There is no evidence that they
>  considered Centos.
>   
Clarification: Wikipedia switched to Debian/Ubuntu.  Dmitry is talking
about the amorphous mass of "RedHat Linux enthusiasts" during the early
Fedora days.

-Toshio

[Pavel Alexeev (aka Pahan-Hubbitus)]

Arthur Pemberton пишет:
>  2008/10/10 Toshio Kuratomi <a.badger(a)gmail.com&gt;:
> > Dmitry Butskoy wrote:
> >> Itamar - IspBrasil wrote:
> >>> any chance to increase the life of fedora releases ?
> >>>
> >>> or fedora will be only blending edge ?
> >>>
> >>> In my opinion fedora is losing space from centos and ubuntu
> >> ...
> >>
> >>> The brazilian government, one of the biggest Fedora Case of the world is
> >>> changing from Fedora/ Red Hat to Ubuntu/Debian.
> >> The problem was at an initial point, when Fedora was considered "for
> >> enthusiasts only". A lot of previous "RedHat Linux enthusiasts"
> just
> >> switch to CentOS (and similar RHEL-based systems), no more using Fedora,
> >> because "it is marked as a non-for-production system even by its
> creators".
> >>
> > The fact that they switched to CentOS is *good* for Fedora.  CentOS's
> > goals are better oriented to the needs of someone that wants to deploy a
> > system and run it for years.
>  
>  
>  They switched to Debian and Ubuntu. There is no evidence that they
>  considered Centos.
>   
Apropos, is it very interesting - why?? Why Wikipedia was not considered 
Centos to migrate?. I'm not found any thinks about it in article.

[Christof Damian]

2008/10/13 Pavel Alexeev (aka Pahan-Hubbitus) <forum(a)ru.bir.ru&gt;:
>  Arthur Pemberton пишет:
> > They switched to Debian and Ubuntu. There is no evidence that they
> > considered Centos.
> >
>  Apropos, is it very interesting - why?? Why Wikipedia was not considered
>  Centos to migrate?. I'm not found any thinks about it in article. 
I think they just wanted to switch to Ubuntu, probably some personal
preference of some of the administrators. Maybe also some pushing from
the Ubuntu "sales" guys.

Using Fedora for web servers was in my opinion always a bad choice.
You just don't want to upgrade your servers that often.

And nowadays I wouldn't even use Fedora for a desktop which I
need/expect for work and expect working after every update. It just
happens too often that my mouse, keyboard, audio, wireless and now X
stopped working and I have to go browsing bugzilla and fedoraforum. By
now I changed my firewall and backup server to CentOS, because I
couldn't be bothered with keeping those updated with Fedora any more.
I used Fedora Legacy for a short while, but the community was just to
small to provide the updates in time. At work we just have RHEL &
CentOS.

I think the target audience for Fedora are Linux developers or fan
boys (that would be me) who want to be at the bleeding edge of
development and don't mind debugging and reporting bugs. Most of these
are probably even using rawhide instead of the release installs.

Maybe this should be made a bit clearer to users who install it, as I
expect it to get worse and not better.

None of this is meant negative by the way. I got exactly what I wanted
and don't want to change.

--
Christof Damian

[Ralf Corsepius]

On Fri, 2008-10-10 at 12:38 -0700, Toshio Kuratomi wrote:
>  Dmitry Butskoy wrote:
>  > Itamar - IspBrasil wrote:
>  >>
>  >> any chance to increase the life of fedora releases ?
>  >>
>  >> or fedora will be only blending edge ?
>  >>
>  >> In my opinion fedora is losing space from centos and ubuntu
>  > 
>  > ...
>  > 
>  >> The brazilian government, one of the biggest Fedora Case of the world is
>  >> changing from Fedora/ Red Hat to Ubuntu/Debian.
>  > 
>  > The problem was at an initial point, when Fedora was considered "for
>  > enthusiasts only". A lot of previous "RedHat Linux enthusiasts" just
>  > switch to CentOS (and similar RHEL-based systems), no more using Fedora,
>  > because "it is marked as a non-for-production system even by its
> creators".
>  > 
>  The fact that they switched to CentOS is *good* for Fedora.  
I can not disagree
more - To me, it's yet another evidence of Fedora
being on the loose.

>   CentOS's
>  goals are better oriented to the needs of someone that wants to deploy a
>  system and run it for years.  Fedora is good for people who want to get
>  the latest technologies from upstream as soon as they're stable enough
>  to integrate into a running system. 
Right. But why can't Fedora do better? I
feel Fedora could do better.

>  > This situation seems to be reflected in the Fedora project
> itself.
>  > Guess, how many Fedora infrastructure servers are run under the latest
>  > "stable" Fedora release?
>  
>  As few as possible. 
IMO, a fundamental management/infrastructure mistake - If these
people
were using Fedora, they would be facing the issues Fedora users are
facing everyday and likely would being to understand why people complain
about Fedora.

>    The reason is not about stability.  It is about
>  updates.  Once Fedora stops getting updates we'd have to upgrade to the
>  next Fedora release with all of the churn that causes for vastly
>  unrelated pieces of the OS.  
Gotcha! If not even the Fedora project can handle the
issues, why do you
expect users to be able to solve them? I think technically the issues
can be overcome. It's a matter of will.

Ralf

[Arthur Pemberton]

On Fri, Oct 10, 2008 at 4:35 PM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  On Fri, 2008-10-10 at 12:38 -0700, Toshio Kuratomi wrote:
> > Dmitry Butskoy wrote:
> > > Itamar - IspBrasil wrote: 
[snip]
> > The fact that they switched to CentOS is *good* for Fedora.
>  I can not disagree more - To me, it's yet another evidence of Fedora
>  being on the loose. 
You're going to have to expound on that. I do not see Centos in any
way as in competition with Fedora. Centos is something everyone should
be proud of.


> >  CentOS's
> > goals are better oriented to the needs of someone that wants to deploy a
> > system and run it for years.  Fedora is good for people who want to get
> > the latest technologies from upstream as soon as they're stable enough
> > to integrate into a running system.
>  Right. But why can't Fedora do better? I feel Fedora could do better. 
Sure. With more devs, servers, time, etc. But baring a sudden increase
in those, I would much prefer to see Fedora focus on dev and testing,
let other distros pretty things up.


> > > This situation seems to be reflected in the Fedora project
> itself.
> > > Guess, how many Fedora infrastructure servers are run under the latest
> > > "stable" Fedora release?
> >
> > As few as possible.
>  IMO, a fundamental management/infrastructure mistake - If these people
>  were using Fedora, they would be facing the issues Fedora users are
>  facing everyday and likely would being to understand why people complain
>  about Fedora. 
Why would they, after often suggesting that Fedora _not_ be used on
production servers, use Fedora on their production servers?


> >   The reason is not about stability.  It is about
> > updates.  Once Fedora stops getting updates we'd have to upgrade to the
> > next Fedora release with all of the churn that causes for vastly
> > unrelated pieces of the OS.
>  Gotcha! If not even the Fedora project can handle the issues, why do you
>  expect users to be able to solve them? I think technically the issues
>  can be overcome. It's a matter of will. 
Well, it's not really an issue. It's only an issue if you run Fedora
on your production servers. Which, again is up to you, not
recommended, and as such no one expects users to "solve" this problem
either.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )

[Ralf Corsepius]

On Fri, 2008-10-10 at 16:53 -0500, Arthur Pemberton wrote:
>  On Fri, Oct 10, 2008 at 4:35 PM, Ralf Corsepius
> <rc040203(a)freenet.de&gt; wrote:
>  > On Fri, 2008-10-10 at 12:38 -0700, Toshio Kuratomi wrote:
>  >> Dmitry Butskoy wrote:
>  >> > Itamar - IspBrasil wrote:
>  [snip]
>  >> The fact that they switched to CentOS is *good* for Fedora.
>  > I can not disagree more - To me, it's yet another evidence of Fedora
>  > being on the loose.
>  
>  You're going to have to expound on that. I do not see Centos in any
>  way as in competition with Fedora. 
EPEL drains away resources from Fedora.

If people were investing the time they (as I feel waste) on supporting
EPEL into Fedora, Fedora would be better.

>   Centos is something everyone should
>  be proud of. 
Well, to me CentOS is as important as any other arbitrary Linux
distro.
I am glad they are around, but not more and not less.

>  >>  CentOS's
>  >> goals are better oriented to the needs of someone that wants to deploy a
>  >> system and run it for years.  Fedora is good for people who want to get
>  >> the latest technologies from upstream as soon as they're stable enough
>  >> to integrate into a running system.
>  > Right. But why can't Fedora do better? I feel Fedora could do better.
>  
>  Sure. With more devs, servers, time, etc. 
... less bureaucracy, less
committees/less chiefs/more Indians,
different people, different strategies.

>   But baring a sudden increase
>  in those, I would much prefer to see Fedora focus on dev and testing,
>  let other distros pretty things up. 
ACK. Unfortunately, Fedora is drifting away
from this group towards
single-user desktops (e.g. OLPC).

>  >> > This situation seems to be reflected in the Fedora
> project itself.
>  >> > Guess, how many Fedora infrastructure servers are run under the latest
>  >> > "stable" Fedora release?
>  >>
>  >> As few as possible.
>  > IMO, a fundamental management/infrastructure mistake - If these people
>  > were using Fedora, they would be facing the issues Fedora users are
>  > facing everyday and likely would being to understand why people complain
>  > about Fedora.
>  
>  Why would they, after often suggesting that Fedora _not_ be used on
>  production servers, use Fedora on their production servers? 
Depends on how they
mean it:
- if they are referring to "long term maintained/everlasting support"
servers, they are right.
- if they mean it as "Fedora is technically too unstable", then this
people should start working on improving the situation or (better) quit
Fedora.

>  >>   The reason is not about stability.  It is about
>  >> updates.  Once Fedora stops getting updates we'd have to upgrade to the
>  >> next Fedora release with all of the churn that causes for vastly
>  >> unrelated pieces of the OS.
>  > Gotcha! If not even the Fedora project can handle the issues, why do you
>  > expect users to be able to solve them? I think technically the issues
>  > can be overcome. It's a matter of will.
>  
>  Well, it's not really an issue. It's only an issue if you run Fedora
>  on your production servers. 
They would be less issues, if Fedora was using Fedora
for its servers.

More bluntly: The fact Fedora is not using Fedora for its servers is a
shame for Fedora.

Ralf

[Stephen John Smoogen]

On Fri, Oct 10, 2008 at 4:23 PM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  On Fri, 2008-10-10 at 16:53 -0500, Arthur Pemberton wrote:
> > On Fri, Oct 10, 2008 at 4:35 PM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
> > > On Fri, 2008-10-10 at 12:38 -0700, Toshio Kuratomi wrote:
> > >> Dmitry Butskoy wrote:
> > >> > Itamar - IspBrasil wrote:
> > [snip]
> > >> The fact that they switched to CentOS is *good* for Fedora.
> > > I can not disagree more - To me, it's yet another evidence of Fedora
> > > being on the loose.
> >
> > You're going to have to expound on that. I do not see Centos in any
> > way as in competition with Fedora.
>  EPEL drains away resources from Fedora.
>
>  If people were investing the time they (as I feel waste) on supporting
>  EPEL into Fedora, Fedora would be better.
>  
Ok. Ralf.. if you hate Fedora and all its projects so much, why do you
fricking stay around. Every fricking thread its "Fedora has too much
bueracracy. Fedora has a broken build system. EPEL steals resources..
" What are you doing?



> > Sure. With more devs, servers, time, etc.
>  ... less bureaucracy, less committees/less chiefs/more Indians,
>  different people, different strategies.
>  
Then DO SOMETHING. Get your indians together and make your camp
somewhere and show us chiefs how it is supposed to be done.




-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

[Ralf Corsepius]

On Fri, 2008-10-10 at 17:08 -0600, Stephen John Smoogen wrote:
>  On Fri, Oct 10, 2008 at 4:23 PM, Ralf Corsepius
> <rc040203(a)freenet.de&gt; wrote:
>  > On Fri, 2008-10-10 at 16:53 -0500, Arthur Pemberton wrote:
>  >> On Fri, Oct 10, 2008 at 4:35 PM, Ralf Corsepius <rc040203(a)freenet.de&gt;
> wrote:
>  >> > On Fri, 2008-10-10 at 12:38 -0700, Toshio Kuratomi wrote:
>  >> >> Dmitry Butskoy wrote:
>  >> >> > Itamar - IspBrasil wrote:
>  >> [snip]
>  >> >> The fact that they switched to CentOS is *good* for Fedora.
>  >> > I can not disagree more - To me, it's yet another evidence of Fedora
>  >> > being on the loose.
>  >>
>  >> You're going to have to expound on that. I do not see Centos in any
>  >> way as in competition with Fedora.
>  > EPEL drains away resources from Fedora.
>  >
>  > If people were investing the time they (as I feel waste) on supporting
>  > EPEL into Fedora, Fedora would be better.
>  >
>  
>  Ok. Ralf.. if you hate Fedora  
Absolutely not.

>  and all its projects so much, why do you
>  fricking stay around. Every fricking thread its "Fedora has too much
>  bueracracy. Fedora has a broken build system. EPEL steals resources..
>  " What are you doing? 
I am complaining about a _few_ people having run down a
once fascinating
project, with the very same people closing their eyes in front this, of
what I consider to be an inconvenient truth.

Wrt. EPEL, I have always had the same opinion on it, since the very
beginning.

>  >> Sure. With more devs, servers, time, etc.
>  > ... less bureaucracy, less committees/less chiefs/more Indians,
>  > different people, different strategies. 
>  Then DO SOMETHING. 
Sigh, I repeatedly have been trying to do
something, but always the same
"Fedora chiefs" had machine-gunned almost each and every proposal.

You know, you have been one of these - Do I really have to be more
direct?

Ralf

[Christopher Brown]

2008/10/11 Ralf Corsepius <rc040203(a)freenet.de&gt;:
>  On Fri, 2008-10-10 at 17:08 -0600, Stephen John Smoogen wrote:
> > On Fri, Oct 10, 2008 at 4:23 PM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
> > > On Fri, 2008-10-10 at 16:53 -0500, Arthur Pemberton wrote:
> > >> On Fri, Oct 10, 2008 at 4:35 PM, Ralf Corsepius <rc040203(a)freenet.de&gt;
> wrote:
> > >> > On Fri, 2008-10-10 at 12:38 -0700, Toshio Kuratomi wrote:
> > >> >> Dmitry Butskoy wrote:
> > >> >> > Itamar - IspBrasil wrote:
> > >> [snip]
> > >> >> The fact that they switched to CentOS is *good* for Fedora.
> > >> > I can not disagree more - To me, it's yet another evidence of
> Fedora
> > >> > being on the loose.
> > >>
> > >> You're going to have to expound on that. I do not see Centos in any
> > >> way as in competition with Fedora.
> > > EPEL drains away resources from Fedora.
> > >
> > > If people were investing the time they (as I feel waste) on supporting
> > > EPEL into Fedora, Fedora would be better.
> > >
> >
> > Ok. Ralf.. if you hate Fedora
>  Absolutely not.
>
> > and all its projects so much, why do you
> > fricking stay around. Every fricking thread its "Fedora has too much
> > bueracracy. Fedora has a broken build system. EPEL steals resources..
> > " What are you doing?
>  I am complaining about a _few_ people having run down a once fascinating
>  project, with the very same people closing their eyes in front this, of
>  what I consider to be an inconvenient truth.
>
>  Wrt. EPEL, I have always had the same opinion on it, since the very
>  beginning.
>
> > >> Sure. With more devs, servers, time, etc.
> > > ... less bureaucracy, less committees/less chiefs/more Indians,
> > > different people, different strategies.
>
> > Then DO SOMETHING.
>  Sigh, I repeatedly have been trying to do something, but always the same
>  "Fedora chiefs" had machine-gunned almost each and every proposal.
>
>  You know, you have been one of these - Do I really have to be more
>  direct? 
No, you just have to be less of an ass. As a casual observer, all you
seem to do is throw rocks. Your only sanctuary lies in the totally
open nature of the project and that it's pretty much impossible to
boot you off it. In fact, your occasional tantrums bears all the
hallmarks of ESR before he happily departed these shores - any chance
you'll be doing the same soon and leave people to get on with the task
in hand?

If not then please remember that good manners cost nothing.

Regards

-- 
Christopher Brown

http://www.chruz.com

[Bruno Wolff III]

On Sat, Oct 11, 2008 at 10:28:40 +0100,
  Christopher Brown <snecklifter(a)gmail.com&gt; wrote:
>  
>  No, you just have to be less of an ass. As a casual observer, all you
>  seem to do is throw rocks. Your only sanctuary lies in the totally
>  open nature of the project and that it's pretty much impossible to
>  boot you off it. In fact, your occasional tantrums bears all the
>  hallmarks of ESR before he happily departed these shores - any chance
>  you'll be doing the same soon and leave people to get on with the task
>  in hand?
>  
>  If not then please remember that good manners cost nothing. 
In that vein there was no reason to gratuitously dis ESR. He had a legitmate
difference of opinion and for a while tried to convince people that Fedora
should go in a different direction. He still contributes indirectly to
Fedora through the Wesnoth project.

[Rahul Sundaram]

Bruno Wolff III wrote:
>  In that vein there was no reason to gratuitously dis ESR. He had a
> legitmate
>  difference of opinion and for a while tried to convince people that Fedora
>  should go in a different direction 
Does legitimate difference of opinion involve making false claims about 
the impact of patents and trolling?

http://lwn.net/Articles/257586/

Are you actually defending this kind of behaviour?

Rahul

[Bruno Wolff III]

On Sun, Oct 12, 2008 at 04:03:11 +0530,
  Rahul Sundaram <sundaram(a)fedoraproject.org&gt; wrote:
>  Bruno Wolff III wrote:
> > In that vein there was no reason to gratuitously dis ESR. He had a legitmate
> > difference of opinion and for a while tried to convince people that Fedora
> > should go in a different direction
>
>  Does legitimate difference of opinion involve making false claims about  
>  the impact of patents and trolling? 
They are independent.

>  http://lwn.net/Articles/257586/
>
>  Are you actually defending this kind of behaviour? 
In my opinion ESR's comment there was in poor taste.

Difference of opinions

[Rahul Sundaram]

Bruno Wolff III wrote:
>  On Sun, Oct 12, 2008 at 04:03:11 +0530,
>    Rahul Sundaram wrote:
> > Bruno Wolff III wrote:
> >> In that vein there was no reason to gratuitously dis ESR. He had a legitmate
> >> difference of opinion and for a while tried to convince people that Fedora
> >> should go in a different direction
> > Does legitimate difference of opinion involve making false claims about  
> > the impact of patents and trolling?
>  
>  They are independent. 
How are they independent? If you want to express a difference of 
opinion, there are much better ways to do it than the approach he 
choose. Besides, if you start out with false assumptions or claims, how 
are your arguments going to be taken seriously?

> > http://lwn.net/Articles/257586/
> >
> > Are you actually defending this kind of behaviour?
>  
>  In my opinion ESR's comment there was in poor taste. 
Poor taste is very much a understatement. The reaction is not surprising 
at all.

Rahul

[Ralf Corsepius]

On Sat, 2008-10-11 at 10:28 +0100, Christopher Brown wrote:
>  2008/10/11 Ralf Corsepius <rc040203(a)freenet.de&gt;:
>  > On Fri, 2008-10-10 at 17:08 -0600, Stephen John Smoogen wrote:
>  >> On Fri, Oct 10, 2008 at 4:23 PM, Ralf Corsepius <rc040203(a)freenet.de&gt;
> wrote:
>  >> > On Fri, 2008-10-10 at 16:53 -0500, Arthur Pemberton wrote:
>  >> >> On Fri, Oct 10, 2008 at 4:35 PM, Ralf Corsepius
> <rc040203(a)freenet.de&gt; wrote:
>  >> >> > On Fri, 2008-10-10 at 12:38 -0700, Toshio Kuratomi wrote:
>  >> >> >> Dmitry Butskoy wrote:
>  >> >> >> > Itamar - IspBrasil wrote:
>  >> >> [snip]
>  >> >> >> The fact that they switched to CentOS is *good* for Fedora.
>  >> >> > I can not disagree more - To me, it's yet another evidence of
> Fedora
>  >> >> > being on the loose.
>  >> >>
>  >> >> You're going to have to expound on that. I do not see Centos in
> any
>  >> >> way as in competition with Fedora.
>  >> > EPEL drains away resources from Fedora.
>  >> >
>  >> > If people were investing the time they (as I feel waste) on supporting
>  >> > EPEL into Fedora, Fedora would be better.
>  >> >
>  >>
>  >> Ok. Ralf.. if you hate Fedora
>  > Absolutely not.
>  >
>  >> and all its projects so much, why do you
>  >> fricking stay around. Every fricking thread its "Fedora has too much
>  >> bueracracy. Fedora has a broken build system. EPEL steals resources..
>  >> " What are you doing?
>  > I am complaining about a _few_ people having run down a once fascinating
>  > project, with the very same people closing their eyes in front this, of
>  > what I consider to be an inconvenient truth.
>  >
>  > Wrt. EPEL, I have always had the same opinion on it, since the very
>  > beginning.
>  >
>  >> >> Sure. With more devs, servers, time, etc.
>  >> > ... less bureaucracy, less committees/less chiefs/more Indians,
>  >> > different people, different strategies.
>  >
>  >> Then DO SOMETHING.
>  > Sigh, I repeatedly have been trying to do something, but always the same
>  > "Fedora chiefs" had machine-gunned almost each and every proposal.
>  >
>  > You know, you have been one of these - Do I really have to be more
>  > direct?
>  
>  No, you just have to be less of an ass. As a casual observer, all you
>  seem to do is throw rocks. 
Thanks for throwing rocks at a Fedora contributor who is
maintaining
many packages in Fedora, whos had performed and contributed to many
reviews, who is actively involved into the FPC and is contributing to
many upstream projects.

[Stephen John Smoogen]

On Fri, Oct 10, 2008 at 11:53 PM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  On Fri, 2008-10-10 at 17:08 -0600, Stephen John Smoogen wrote:
>  Sigh, I repeatedly have been trying to do something, but always the
> same
>  "Fedora chiefs" had machine-gunned almost each and every proposal.
>  
If I am somehow a chief.. no-one has ever told me. On the other hand,
I do have a lack of patience and a lack of trying to see if there is a
way to work towards Win/Win.

>  You know, you have been one of these - Do I really have to be more
>  direct?
>  
Actually I think you are too direct. You seem to have been
disappointed with how Fedora's leadership has gone, and never seem to
avoid a situation to remind people that. You complain about too much
bueracracy and lack of democracy, but your alternatives seem to be
communicated always as "do as a I say"  without compromise.

I know there is a void between us because English and email is not the
easiest language to communicate ideas with. How can we bridge it?

-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

[Ralf Corsepius]

On Sat, 2008-10-11 at 14:13 -0600, Stephen John Smoogen wrote:
>  On Fri, Oct 10, 2008 at 11:53 PM, Ralf Corsepius
> <rc040203(a)freenet.de&gt; wrote:
>  > On Fri, 2008-10-10 at 17:08 -0600, Stephen John Smoogen wrote: 
>  > You know, you have been one of these - Do I really have to be
> more
>  > direct?
>  >
>  
>  Actually I think you are too direct. You seem to have been
>  disappointed with how Fedora's leadership has gone, and never seem to
>  avoid a situation to remind people that. You complain about too much
>  bueracracy and lack of democracy, but your alternatives seem to be
>  communicated always as "do as a I say"  without compromise. 
Absolutely
not. 

Compromising would require general agreement on "presence of a problem"
and "willingness to develop solutions". Unfortunately, I don't see them
in Fedora. To the contrary, I observe Fedora people celebrating things I
consider to be regressions/problems as "great achievements and
progress".

[Michael Schwendt]

On Fri, 10 Oct 2008 17:08:53 -0600, Stephen John Smoogen wrote:

>  Ok. Ralf.. if you hate Fedora and all its projects so much, why do
> you
>  fricking stay around. Every fricking thread its "Fedora has too much
>  bueracracy. Fedora has a broken build system. EPEL steals resources..
>  " What are you doing? 
>  Then DO SOMETHING. Get your indians together and make your camp
>  somewhere and show us chiefs how it is supposed to be done. 
A "put up or shut up" attitude has only been harmful in several occasions
before. You cannot win volunteers with remarks like that.

[Arthur Pemberton]

On Tue, Oct 21, 2008 at 12:37 PM, Michael Schwendt <mschwendt(a)gmail.com&gt; wrote:
>  On Fri, 10 Oct 2008 17:08:53 -0600, Stephen John Smoogen wrote:
>
> > Ok. Ralf.. if you hate Fedora and all its projects so much, why do you
> > fricking stay around. Every fricking thread its "Fedora has too much
> > bueracracy. Fedora has a broken build system. EPEL steals resources..
> > " What are you doing?
>
> > Then DO SOMETHING. Get your indians together and make your camp
> > somewhere and show us chiefs how it is supposed to be done.
>
>  A "put up or shut up" attitude has only been harmful in several occasions
>  before. You cannot win volunteers with remarks like that. 

Well, seems like the community is being solely gobbled up by
individuals who are both negative and non constructive.

The Fedora community faces criticism and lack of assistance from
without and within. Is it time to just terminate things? Or is there a
way forward?

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )

[Les Mikesell]

Arthur Pemberton wrote:
>  
> > A "put up or shut up" attitude has only been harmful in several occasions
> > before. You cannot win volunteers with remarks like that.
>  
>  
>  Well, seems like the community is being solely gobbled up by
>  individuals who are both negative and non constructive. 
That shouldn't be surprising for a project that doesn't value backwards 
compatibility, stability, or interoperability with any third party 
components.

>  The Fedora community faces criticism and lack of assistance from
>  without and within. Is it time to just terminate things? Or is there a
>  way forward? 
Either maintain compatible interfaces or don't be so sensitive to 
criticism from your existing users whose work and learning you just 
threw away.

-- 
    Les Mikesell
     lesmikesell(a)gmail.com

[Rex Dieter]

Les Mikesell wrote:

>  Arthur Pemberton wrote:
> > 
> >> A "put up or shut up" attitude has only been harmful in several
> >> occasions before. You cannot win volunteers with remarks like that.
> > 
> > 
> > Well, seems like the community is being solely gobbled up by
> > individuals who are both negative and non constructive.
>  
>  That shouldn't be surprising for a project that doesn't value backwards
>  compatibility, stability, or interoperability with any third party
>  components. 
Blame too those upstream projects who introduce these changes, fedora is
just a collection of all those items.  

Is there similar outrage against them as well?  Where is it?

-- Rex

[Patrice Dumas]

On Wed, Oct 22, 2008 at 07:53:35AM -0500, Rex Dieter wrote:
>  
>  Blame too those upstream projects who introduce these changes, fedora is
>  just a collection of all those items.   
It is not that simple. The distinction between fedora and upstream in
many cases is rather fuzzy. For example the hal/dbus/consoleKit/*Kit is
put in fedora when it is at early development stages, and many of the
developpers involved in these are also involved in fedora. And the
changes are pushed in fedora without taking seriously the backward
compatibility issues. For example wdm and xdm (and slim) are broken
since consolekit replaced pam_console, and although there is a rather
simple solution to integrate those dm it has never been planned and it
is still not fixed, though a fix exist for months. As long as it worked
in gdm it was fine for fedora. You can tell, hey, xdm, wdm and slim can
copy what gdm does, but when the solution implemented in gdm is specific
and not consistent with the previous designs, it is not so easy. Fedora
controls some upstream so can do anything in these, but doesn't control
all of them.

I am not saying that it is a wrong approach, being able to have a
platform for experimentation is indeed valuable, but you cannot charge
upstream for all regressions in fedora, especially when improper or
unplanned integration is linked with the regression, or the unstability
is linked with different features being proposed in packages controlled
by people in fedora and packages with an independent upstream.

In comparison, the transition to upstart was smooth, and a reason may be
that fedora wasn't the testing ground for that feature that originated
from ubuntu (though fedora people helped upstream at the time it was
integrated in fedora).

--
Pat

[Les Mikesell]

Rex Dieter wrote:
>  Les Mikesell wrote:
>  
> > Arthur Pemberton wrote:
> >>> A "put up or shut up" attitude has only been harmful in several
> >>> occasions before. You cannot win volunteers with remarks like that.
> >>
> >> Well, seems like the community is being solely gobbled up by
> >> individuals who are both negative and non constructive.
> > That shouldn't be surprising for a project that doesn't value backwards
> > compatibility, stability, or interoperability with any third party
> > components.
>  
>  Blame too those upstream projects who introduce these changes, fedora is
>  just a collection of all those items.   
So you'll ship any sort of breakage with no regard to the interfaces you 
promoted last month?

>  Is there similar outrage against them as well?  Where is it? 
There are reasons that people run distributions instead of compiling the 
head of every upstream source themselves.  Consider the contrast between 
RHEL's shielding users from incompatible upstream changes for many years 
at a time to what fedora ships.   I realize that it isn't easy or even 
always possible to add new features without breaking old ones or 
interfaces, but that's what people want.  And it is what they are used 
to from commercial OS's.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

[David Woodhouse]

On Wed, 2008-10-22 at 08:16 -0500, Les Mikesell wrote:
>  Rex Dieter wrote:
>  > Les Mikesell wrote:
>  > 
>  >> Arthur Pemberton wrote:
>  >>>> A "put up or shut up" attitude has only been harmful in
> several
>  >>>> occasions before. You cannot win volunteers with remarks like that.
>  >>>
>  >>> Well, seems like the community is being solely gobbled up by
>  >>> individuals who are both negative and non constructive.
>  >> That shouldn't be surprising for a project that doesn't value backwards
>  >> compatibility, stability, or interoperability with any third party
>  >> components.
>  > 
>  > Blame too those upstream projects who introduce these changes, fedora is
>  > just a collection of all those items.  
>  
>  So you'll ship any sort of breakage with no regard to the interfaces you 
>  promoted last month? 
Of course not. We take care to ensure that when interfaces change, every
Fedora package is updated to cope.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse(a)intel.com                              Intel Corporation

[Les Mikesell]

David Woodhouse wrote:
>  
> >>>>> A "put up or shut up" attitude has only been harmful in
> several
> >>>>> occasions before. You cannot win volunteers with remarks like that.
> >>>> Well, seems like the community is being solely gobbled up by
> >>>> individuals who are both negative and non constructive.
> >>> That shouldn't be surprising for a project that doesn't value
> backwards
> >>> compatibility, stability, or interoperability with any third party
> >>> components.
> >> Blame too those upstream projects who introduce these changes, fedora is
> >> just a collection of all those items.  
> > So you'll ship any sort of breakage with no regard to the interfaces you 
> > promoted last month?
>  
>  Of course not. We take care to ensure that when interfaces change, every
>  Fedora package is updated to cope. 
Leaving everything all 3rd party work that tries to cooperate and a 
user's own previous work useless.  If a commercial system did that, 
they'd be out of business in a heartbeat.  A free distribution doesn't 
have the same reasons to care about cooperation, but from the user's 
perspective its all the same - if you can't count on interfaces being 
maintained, a platform simply isn't worth the effort.

Whatever happened to the concept of an LSB definition that was complete 
enough to permit apps to run unchanged across distributions?  We need 
something like that spanning at least 3 concurrent versions of fedora.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

[David Woodhouse]

On Wed, 2008-10-22 at 08:57 -0500, Les Mikesell wrote:
>  >> So you'll ship any sort of breakage with no regard to
> the
>  >> interfaces you promoted last month?
>  > 
>  > Of course not. We take care to ensure that when interfaces change, 
>  > every Fedora package is updated to cope.
>  
>  Leaving everything all 3rd party work that tries to cooperate and a 
>  user's own previous work useless.  
I've never found that to be the case, no. Any third party work that
"tried to co-operate" would be packaged as a Fedora package, and would
be included in my above statement.

And even my own personal hacks -- if it's a project of any significance
at all, then it's probably worth packaging. As much as I like to think
I'm unique (and I know others like to tell themselves that too), I'm
not. So if there's any piece of software which is _so_ useful to me that
I actually get off my lazy arse and _write_ it, then it's a fairly safe
bet it's going to be useful to someone else too.

>   If a commercial system did that, they'd be out of business in a
>  heartbeat.  
The ability to cope with change is _precisely_ what distinguishes free
software from the commercial systems that it is slowly, but surely,
replacing.

The only people who really have a problem with it are those who fail to
work properly with whatever they call their 'upstream' project(s).

>   A free distribution doesn't have the same reasons to care about
>  cooperation, but from the user's perspective its all the same - if you
>  can't count on interfaces being maintained, a platform simply isn't
>  worth the effort. 
There is a difference between internal and external APIs. Basic stuff
like GTK and glibc _don't_ break in incompatible ways very often. Those
are the kinds of things that external software uses.

If you're involved in the horrid details of the latest PackageKit API
change, then you really have no business being an _external_ piece of
software anyway. Whatever it is, it should be packaged and included in
the Fedora repository, and then we'll be able to take care of it when we
break it.

To be honest, Les, I think you're just spouting crap again. It's an
unfortunate habit with you, isn't it?

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse(a)intel.com                              Intel Corporation

[Les Mikesell]

David Woodhouse wrote:
>  
> >>> So you'll ship any sort of breakage with no regard to the
> >>> interfaces you promoted last month?
> >> Of course not. We take care to ensure that when interfaces change, 
> >> every Fedora package is updated to cope.
> > Leaving everything all 3rd party work that tries to cooperate and a 
> > user's own previous work useless. 
>  
>  I've never found that to be the case, no. Any third party work that
>  "tried to co-operate" would be packaged as a Fedora package, and would
>  be included in my above statement. 
Give me a break... Nvidia, VMware, Sun Java, java apps, and on and on. 
If something _has_ to be included as a Fedora package to work from one 
release to the next, Fedora has failed for me.

> >  If a commercial system did that, they'd be out of business
> in a
> > heartbeat. 
>  
>  The ability to cope with change is _precisely_ what distinguishes free
>  software from the commercial systems that it is slowly, but surely,
>  replacing. 
How is having to modify and recompile every package every few months 
'coping' with change?  It is fairly rare to ever have to replace a 
binary on a windows or mac due to an OS update.  The mac even maintains 
backwards compatibility across an update to a different CPU and wildly 
different OS - and includes tools to migrate your settings and apps. 
Without the stability factor that enterprise and long-term distributions 
contribute, free software wouldn't be replacing anything.

>  The only people who really have a problem with it are those who fail
> to
>  work properly with whatever they call their 'upstream' project(s). 
What should that mean to the user of the third party products that don't 
'work properly' with fedora?  Why would anyone need to 'work properly' 
as opposed to following standard interfaces to interoperate correctly?

> >  A free distribution doesn't have the same reasons to care
> about
> > cooperation, but from the user's perspective its all the same - if you
> > can't count on interfaces being maintained, a platform simply isn't
> > worth the effort.
>  
>  There is a difference between internal and external APIs. Basic stuff
>  like GTK and glibc _don't_ break in incompatible ways very often. Those
>  are the kinds of things that external software uses. 
What does mean in terms of being able to install vendor drivers, VMware, 
Sun's Java with integration into the system path scheme, or something 
from a random 3rd party repo?

>  If you're involved in the horrid details of the latest PackageKit
> API
>  change, then you really have no business being an _external_ piece of
>  software anyway.   Whatever it is, it should be packaged and included in
>  the Fedora repository, and then we'll be able to take care of it when we
>  break it. 
That is completely unrealistic, given a Fedora policy that excludes 
things from the repository for various reasons, and just wrong to 
require the system to be self-contained on general principles.

>  To be honest, Les, I think you're just spouting crap again.
> It's an
>  unfortunate habit with you, isn't it? 
Its only crap if you believe that a distribution should require every 
piece of software that it will run to 'work properly' with the 
distribution provider according to the distribution provider's 
definition.  I don't - I believe interfaces are what makes software work.

-- 
   Les Mikesell
     lesmikesell(a)gmail.com

[Patrice Dumas]

On Wed, Oct 22, 2008 at 03:42:08PM +0100, David Woodhouse wrote:
>  
>  I've never found that to be the case, no. Any third party work that
>  "tried to co-operate" would be packaged as a Fedora package, and would
>  be included in my above statement. 
Packages included in fedora have been broken for months or years now.
You may think that these are not important packages, but still they are
in fedora. Now as I told already fixing these packages or coming up with
a design more backward compatible may entail some costs too, but
having packages in fedora isn't a insurance against breakage. Gnome
packages and major desktop package, sure will get a lot of love, but
packages that are not 'mainstream' fedora won't be taken in
consideration that much.

--
Pat

[Rex Dieter]

Patrice Dumas wrote:

>  On Wed, Oct 22, 2008 at 03:42:08PM +0100, David Woodhouse wrote:
> > 
> > I've never found that to be the case, no. Any third party work that
> > "tried to co-operate" would be packaged as a Fedora package, and would
> > be included in my above statement.
>  
>  Packages included in fedora have been broken for months or years now. 
Keep in mind that this discussion (imo) is more about general intentions,
not specific cases.

-- Rex

[David Woodhouse]

On Wed, 2008-10-22 at 12:07 -0500, Rex Dieter wrote:
>  Patrice Dumas wrote:
>  
>  > On Wed, Oct 22, 2008 at 03:42:08PM +0100, David Woodhouse wrote:
>  >> 
>  >> I've never found that to be the case, no. Any third party work that
>  >> "tried to co-operate" would be packaged as a Fedora package, and
> would
>  >> be included in my above statement.
>  > 
>  > Packages included in fedora have been broken for months or years now.
>  
>  Keep in mind that this discussion (imo) is more about general
>  intentions, not specific cases. 
Of _course_ it's not about specific cases. That would require actual
substantiated facts which can be verified or disproved; not just
handwaving and ranting.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse(a)intel.com                              Intel Corporation

[Patrice Dumas]

On Wed, Oct 22, 2008 at 06:25:11PM +0100, David Woodhouse wrote:
>  
>  Of _course_ it's not about specific cases. That would require actual
>  substantiated facts which can be verified or disproved; not just
>  handwaving and ranting. 
I answered to Rex giving a specific case, regarding ConsoleKit and
various dm breakage. You want the bugzilla entries or you trust me?

--
Pat

[David Woodhouse]

On Wed, 2008-10-22 at 20:46 +0200, Patrice Dumas wrote:
>  On Wed, Oct 22, 2008 at 06:25:11PM +0100, David Woodhouse wrote:
>  > 
>  > Of _course_ it's not about specific cases. That would require actual
>  > substantiated facts which can be verified or disproved; not just
>  > handwaving and ranting.
>  
>  I answered to Rex giving a specific case, regarding ConsoleKit and
>  various dm breakage. You want the bugzilla entries or you trust me? 
/me looks back...

On Wed, 2008-10-22 at 15:06 +0200, Patrice Dumas wrote:
>  It is not that simple. The distinction between fedora and upstream
> in
>  many cases is rather fuzzy. For example the hal/dbus/consoleKit/*Kit is
>  put in fedora when it is at early development stages, and many of the
>  developpers involved in these are also involved in fedora. And the
>  changes are pushed in fedora without taking seriously the backward
>  compatibility issues. For example wdm and xdm (and slim) are broken
>  since consolekit replaced pam_console, and although there is a rather
>  simple solution to integrate those dm it has never been planned and it
>  is still not fixed, though a fix exist for months. As long as it worked
>  in gdm it was fine for fedora. You can tell, hey, xdm, wdm and slim can
>  copy what gdm does, but when the solution implemented in gdm is specific
>  and not consistent with the previous designs, it is not so easy. Fedora
>  controls some upstream so can do anything in these, but doesn't control
>  all of them. 
Yeah, that sucks. We should do better than that.

Although I've always been a little dubious about our 'Feature Process',
it does seem that it addresses this kind of problem. For the feature to
reach 100% completion, it should obviously involve fixes for the other
display managers. And there is a 'reversion plan' in case we don't
manage to complete the feature in time for the release. 

> From what you say above, it sounds like the ConsoleKit feature should
> be 
declared incomplete, and we should be reverting it unless the feature
owners finish the job.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse(a)intel.com                              Intel Corporation

[Patrice Dumas]

On Thu, Oct 23, 2008 at 09:30:57AM +0100, David Woodhouse wrote:
>  
>  Yeah, that sucks. We should do better than that.
>  
>  Although I've always been a little dubious about our 'Feature Process',
>  it does seem that it addresses this kind of problem. For the feature to
>  reach 100% completion, it should obviously involve fixes for the other
>  display managers. And there is a 'reversion plan' in case we don't
>  manage to complete the feature in time for the release.  
Here, simply keeping up using pam_console would have worked. But lead to
much less testing of fast user switching. The whole story can be tracked
down from this bug, from 2007-02-09:
https://bugzilla.redhat.com/show_bug.cgi?id=228110

Later a pam module was added for login. And even later a solution has
been found for dm, building on what was done for xinit, that plays 
well with wdm/xdm/slim, though it is still not applied:
https://bugzilla.redhat.com/show_bug.cgi?id=452156

> From my point of view, this comment (certainly biased, it is a comment
from me) summary the situation, and it is really a fedora issue,
not only an upstream issue:
https://bugzilla.redhat.com/show_bug.cgi?id=452156#c15

>  From what you say above, it sounds like the ConsoleKit feature should
> be
>  declared incomplete, and we should be reverting it unless the feature
>  owners finish the job. 
If this is the case, then we would only have had ConsoleKit in F-11...

At the time the issue happened, there was no feature process, but I
can't see how it would have changed anything. A feature process cannot
prevent lack of planning, focus on gnome, lack of integration with
existing frameworks and lack of consideration for alternative setups, if
this attitude is endorsed by the project on a whole, which is the case
for fedora, see for example
https://bugzilla.redhat.com/show_bug.cgi?id=228110#c19
and look at all the conversations on this mailing list or fesco
decisions.

A FESCo vote (at least of today FESCo) would certainly be to let the
minor dm be broken (hopefully they will be fixed for the RHEL release),
so even if a Feature was not considered finished I doubt the changes
would have been reversed. Once again, I don't think that such an
attitude is fundamentaly problematic, this allowed to have much more
testing for gdm, kdm and fast user switching, which is good. But this is
also, in my opinion, a good example of what fedora really is, and my
personnal point of view is that it is becoming even more so.

As a side note I thought that having more packages, and packages that
are not mainstream, with the corresponding packagers being part of the
community would lead to a push to another direction, but for
good or bad, this didn't happened -- and I think that in the fedora
community, those, like me, not in complete agreement with the 
'mainstream' fedora (more testing than planning, innovation breaking 
old frameworks, focus on major desktop components) are, in my opinion,
getting less and less consideration. The corresponding packages are 
simply broken intermitently, always on the struggle to catch up with 
the constant changes.

--
Pat

[David Woodhouse]

On Thu, 2008-10-23 at 11:20 +0200, Patrice Dumas wrote:
>  > From what you say above, it sounds like the ConsoleKit feature
> should be
>  > declared incomplete, and we should be reverting it unless the feature
>  > owners finish the job.
>  
>  If this is the case, then we would only have had ConsoleKit in F-11...
>  
>  At the time the issue happened, there was no feature process, but I
>  can't see how it would have changed anything. A feature process cannot
>  prevent lack of planning, focus on gnome, lack of integration with
>  existing frameworks and lack of consideration for alternative setups, 
I think that's a fundamental part of what the feature process _should_
be doing. The whole point of the feature process, as I see it, is about
precisely the _planning_ you say we lack. Otherwise, we're just be
throwing new stuff in willy-nilly and just writing it up in the release
notes after the fact.

In this case, there seems to have been a disagreement about _how_ the
other display managers should be fixed. Regardless of that, I think it's
clear that they _SHOULD_ have been fixed...

>   if this attitude is endorsed by the project on a whole, which is the
> case
>  for fedora, see for example
>  https://bugzilla.redhat.com/show_bug.cgi?id=228110#c19
>  and look at all the conversations on this mailing list or fesco
>  decisions. 
... but I also think Jeremy was right in the above-mentioned #c19, where
he dropped the bug status to 'tracker'. That's 'SHOULD', not
'MUST'.

>  A FESCo vote (at least of today FESCo) would certainly be to let the
>  minor dm be broken  
Maybe. I, for one, would vote against it -- I'd expect those responsible
for the PackageKit 'feature' to fix it _somehow_, rather than just
leaving it broken. Even if there is some argument that the fix could be
done a better way.
 
>  (hopefully they will be fixed for the RHEL release), 
I hope that's not an issue for FESCo members -- although it _should_ be
a factor in the decision-making process of @redhat.com folks working on
stuff. "We're going to have to do the sensible thing in RHEL in the end
anyway; let's do it right away and not screw Fedora over".

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse(a)intel.com                              Intel Corporation

[Patrice Dumas]

On Thu, Oct 23, 2008 at 12:38:20PM +0100, David Woodhouse wrote:
>  
>  I think that's a fundamental part of what the feature process _should_
>  be doing. The whole point of the feature process, as I see it, is about
>  precisely the _planning_ you say we lack. Otherwise, we're just be 
This is partly that kind of planning, but the planning I am referring to
is more about upstream planning integration within the existing
frameworks.

In this precise case, there was a single point of control, the bug
report, and there was some kind of planning regarding the inclusion in
fedora.

But in any case, most of the changes don't fall under the feature
process, because they are upstream changes, so I can't see how this
could be controlled in Fedora, if the package maintainers are not
willing to be controlled.

>  throwing new stuff in willy-nilly and just writing it up in the
> release
>  notes after the fact.
>  
>  In this case, there seems to have been a disagreement about _how_ the
>  other display managers should be fixed. Regardless of that, I think it's
>  clear that they _SHOULD_ have been fixed... 
That's not obvious to me that the main issue is how this should have
been fixed in fedora. ConsoleKit could also have been planned from 
the beginning with a consideration to how dm worked, for pam support, and
with a proposal for dm maintainers (or the packagers in fedora) for an
implementation. Instead we were pointed to a gdm patch after the fact.

>  >  if this attitude is endorsed by the project on a whole, which
> is the case
>  > for fedora, see for example
>  > https://bugzilla.redhat.com/show_bug.cgi?id=228110#c19
>  > and look at all the conversations on this mailing list or fesco
>  > decisions.
>  
>  ... but I also think Jeremy was right in the above-mentioned #c19, where
>  he dropped the bug status to 'tracker'. That's 'SHOULD', not
> 'MUST'. 
Note that I didn't said that he was wrong.

>  > A FESCo vote (at least of today FESCo) would certainly be to let
> the
>  > minor dm be broken 
>  
>  Maybe. I, for one, would vote against it -- I'd expect those responsible
>  for the PackageKit 'feature' to fix it _somehow_, rather than just
>  leaving it broken. Even if there is some argument that the fix could be
>  done a better way. 
But this is not that easy, especially in that case. I think that the kdm
patch, although functional is not right, because it hardcodes the
device path. As a package maintainer I would have preferred a broken wdm
rather than this patch. And I talked with the xdm upstream maintainer
and he was not going to accept such patch either.

That being said, I agree that people bringing forward the feature could
have been of more help and should have taken more attention to the help
I was asking for and the stuff I proposed. But they seem to be very
busy, so it is not easy.

>  > (hopefully they will be fixed for the RHEL release),
>  
>  I hope that's not an issue for FESCo members -- although it _should_ be
>  a factor in the decision-making process of @redhat.com folks working on
>  stuff. "We're going to have to do the sensible thing in RHEL in the end
>  anyway; let's do it right away and not screw Fedora over". 
I think that many people in the fedora community, especially @RH people
and people in the board prefer a fast moving fedora, even if some 
packages considered of less importance (like xdm) are screwed, 
that give some testing for RHEL rather than a careful avoidance of 
regressions. This is not the same thing, but quite consistent with 
the opposition toward leaving infra open after EOL, with the argument 
being 'Fedora is fast moving and RHEL/EPEL is stable, choose one of 
the two, another way is chimeric'. I don't want to start a flamewar
about RH hidden agendas and so on and so forth, it is just how I
personnally feel. And to repeat myself once again this may be a very
good path, though it is certainly not the one I would have followed if
I was in the position of deciding.

I also think in the today's fedora community, be it from @RH or not,
(except from some reactionary people like me who come from a past 
fedora and still haven't given up) there are a lot of people who 
want something fast moving even if some packages considered of 
less importance are screwed, without any reference to RHEL, but 
because they are enthousiast desktop people, the way fedora is 
fast moving suit them.

--
Pat

[Rex Dieter]

Les Mikesell wrote:

>  Rex Dieter wrote: 
> > Blame too those upstream projects who introduce these changes,
> fedora is
> > just a collection of all those items.
>  
>  So you'll ship any sort of breakage with no regard to the interfaces you
>  promoted last month? 
Thanks for putting words into my and fedora's mouth.  OK, I'll bite a bit...
when it's the choice of shipping an older unsupported version of software
vs. latest/supported, sometimes, yeah.  It's a tough choice to have to
make.

Unanswered:
>  Is there similar outrage against upstreams as well?  Where is it?
-- Rex

[Les Mikesell]

Rex Dieter wrote:
> >> Blame too those upstream projects who introduce these changes, fedora is
> >> just a collection of all those items.
> > So you'll ship any sort of breakage with no regard to the interfaces you
> > promoted last month?
>  
>  Thanks for putting words into my and fedora's mouth. 
Actually I'm trying to give a user's perspective.  As a closed black 
box, fedora might work.  I want to use 3rd party drivers, components, 
apps, etc. but can't deal with them breaking every few months.

>  OK, I'll bite a bit...
>  when it's the choice of shipping an older unsupported version of software
>  vs. latest/supported, sometimes, yeah.  It's a tough choice to have to
>  make. 
Older/newer isn't quite the point here - it is more about why it is 
necessary to break old functionality to add new or improved.  Start with 
the premise that fedora repositories don't and cannot contain all the 
software that I want to run and perhaps you can see why interface change 
is painful.

>  Unanswered:
> > Is there similar outrage against upstreams as well?  Where is it? 
Yes, to whatever extent upstream refuses to respect their own interfaces 
as contracts with other programmers they deserve outrage as well.  But, 
you don't have to ship that stuff.  Maybe if no one did, they'd decide 
it was worth stabilizing interfaces to a point where others could cooperate.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

[Jesse Keating]

On Wed, 2008-10-22 at 10:01 -0500, Les Mikesell wrote:
>  Yes, to whatever extent upstream refuses to respect their own
> interfaces 
>  as contracts with other programmers they deserve outrage as well.  But, 
>  you don't have to ship that stuff.  Maybe if no one did, they'd decide 
>  it was worth stabilizing interfaces to a point where others could cooperate. 
Or more likely, everybody /but/ Fedora would ship it and then Fedora
would be laughed at for being too old and slow to adopt new upstream
releases.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[David G. Mackay]

On Wed, 2008-10-22 at 08:39 -0500, Rex Dieter wrote:
>  Unanswered:
>  > Is there similar outrage against upstreams as well?  Where is it? 
On this list, it's shouted down.  I commented some time ago about the
rather toxic behavior of the python developers vis-a-vis breaking
compatibility at virtually every release.  You would have thought that I
had urinated in the holy water.

It's an ugly little wart on the free software movement.  There's nowhere
near the incentive to take care of your user base without a direct
financial gain.  Not, mind you, that commercial ventures haven't done
the same, but the consequences to them are more severe and direct.

Dave

[Daniel P. Berrange]

On Wed, Oct 22, 2008 at 11:03:07AM -0500, David G. Mackay wrote:
>  
>  On Wed, 2008-10-22 at 08:39 -0500, Rex Dieter wrote:
>  > Unanswered:
>  > > Is there similar outrage against upstreams as well?  Where is it?
>  
>  On this list, it's shouted down.  I commented some time ago about the
>  rather toxic behavior of the python developers vis-a-vis breaking
>  compatibility at virtually every release.  You would have thought that I
>  had urinated in the holy water.
>  
>  It's an ugly little wart on the free software movement.  There's nowhere
>  near the incentive to take care of your user base without a direct
>  financial gain.  Not, mind you, that commercial ventures haven't done
>  the same, but the consequences to them are more severe and direct. 
You don't get to dictate what the upstream project's priorities are.
If you don't like the fact that apps break with every new python
release (I don't like it either), then pick a different programming
language with an upstream whose priorities better align with your
needs. eg, Perl or Java or OCaml or any number of other languages.
Open source is about freedom of choice & that applies to everyone,
users, developers, packagers alike. The python developers/community
have decided the level of stability they want between each of their
releases - they decided to accept a certain level of breakage. You
have the freedom to decide whether this matches your needs and if 
not, no one is forcing you to use python.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

[Les Mikesell]

Daniel P. Berrange wrote:
>  
> >>> Is there similar outrage against upstreams as well?  Where is it?
> > On this list, it's shouted down.  I commented some time ago about the
> > rather toxic behavior of the python developers vis-a-vis breaking
> > compatibility at virtually every release.  You would have thought that I
> > had urinated in the holy water.
> >
> > It's an ugly little wart on the free software movement.  There's nowhere
> > near the incentive to take care of your user base without a direct
> > financial gain.  Not, mind you, that commercial ventures haven't done
> > the same, but the consequences to them are more severe and direct.
>  
>  You don't get to dictate what the upstream project's priorities are. 
But it should be something open for discussion, and something considered 
when integrating a package into a distribution and when/if the 
incompatible changes should be propagated.

>  If you don't like the fact that apps break with every new python
>  release (I don't like it either), then pick a different programming
>  language with an upstream whose priorities better align with your
>  needs. eg, Perl or Java or OCaml or any number of other languages. 
That decision would be a lot more obvious if the history of backwards 
compatibility of a project was tracked publicly, perhaps with the 
packagers of affected apps keeping track of the time they spend just to 
maintain functionality.  That would help a new user decide where to 
invest his own time.

>  Open source is about freedom of choice & that applies to
> everyone,
>  users, developers, packagers alike. The python developers/community
>  have decided the level of stability they want between each of their
>  releases - they decided to accept a certain level of breakage. You
>  have the freedom to decide whether this matches your needs and if 
>  not, no one is forcing you to use python. 
It is pretty hard not to use python in a fedora or RH-based distro.   Or 
to use any other version than what the distro updates to internally - 
which means that any 3rd party or local additions will take extra work 
to keep precisely in step.

-- 
   Les Mikesell
     lesmikesell(a)gmail.com

[Arthur Pemberton]

On Wed, Oct 22, 2008 at 12:16 PM, Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:
>  Daniel P. Berrange wrote:
> >
> >>>> Is there similar outrage against upstreams as well?  Where is it?
> >>
> >> On this list, it's shouted down.  I commented some time ago about the
> >> rather toxic behavior of the python developers vis-a-vis breaking
> >> compatibility at virtually every release.  You would have thought that I
> >> had urinated in the holy water.
> >>
> >> It's an ugly little wart on the free software movement.  There's nowhere
> >> near the incentive to take care of your user base without a direct
> >> financial gain.  Not, mind you, that commercial ventures haven't done
> >> the same, but the consequences to them are more severe and direct.
> >
> > You don't get to dictate what the upstream project's priorities are.
>
>  But it should be something open for discussion, and something considered
>  when integrating a package into a distribution and when/if the incompatible
>  changes should be propagated. 

Have any of your discussions of this nature yielded fruitful results?
If not, your approach is failed, even if the intent is good. In which
case you need to come up with a more productive approach.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )

[Horst H. von Brand]

Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  On Fri, 2008-10-10 at 16:53 -0500, Arthur Pemberton wrote:
>  > On Fri, Oct 10, 2008 at 4:35 PM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  > > On Fri, 2008-10-10 at 12:38 -0700, Toshio Kuratomi wrote:
>  > >> Dmitry Butskoy wrote:
>  > >> > Itamar - IspBrasil wrote:
>  > [snip]
>  > >> The fact that they switched to CentOS is *good* for Fedora.
>  > > I can not disagree more - To me, it's yet another evidence of Fedora
>  > > being on the loose.
>  > 
>  > You're going to have to expound on that. I do not see Centos in any
>  > way as in competition with Fedora. 
>  EPEL drains away resources from Fedora. 
Proof?

[People working on EPEL do so because they are interested in EPEL, which
 clearly isn't the same as being interested in Fedora... if EPEL went away,
 probably most of them would leave too.]

>  If people were investing the time they (as I feel waste) on
> supporting
>  EPEL into Fedora, Fedora would be better. 
How true. But see above...

>  >  Centos is something everyone should
>  > be proud of. 
>  Well, to me CentOS is as important as any other arbitrary Linux
> distro.
>  I am glad they are around, but not more and not less. 
It is around becase RHEL is popular, and open source. A clone is
wellcome. And RHEL is popular in part because it works together with
Fedora.

>  > >>  CentOS's
>  > >> goals are better oriented to the needs of someone that wants to deploy a
>  > >> system and run it for years.  Fedora is good for people who want to get
>  > >> the latest technologies from upstream as soon as they're stable enough
>  > >> to integrate into a running system. 
>  > > Right. But why can't Fedora do better? I feel Fedora
> could do better. 
>  > Sure. With more devs, servers, time, etc. 
>  ... less bureaucracy, less committees/less chiefs/more Indians,
>  different people, different strategies. 
Show how! Telling everybody here how awful things are going isn't helping
an iota. Everything has its limits, and for every desirable quality (newest
shiny toys, support for the newest fad in hardware in software) there is a
cost (can't be supported in the long range, fast turnaround, set procedures
to handle a huge stream of new stuff)

>  >  But baring a sudden increase
>  > in those, I would much prefer to see Fedora focus on dev and testing,
>  > let other distros pretty things up. 
>  ACK. Unfortunately, Fedora is drifting away from this group towards
>  single-user desktops (e.g. OLPC). 
Then work towards drifting the opposite direction...

Fedora (or any other large group of people) will move where the majority
wants to go... 

>  > >> > This situation seems to be reflected in the Fedora
> project itself.
>  > >> > Guess, how many Fedora infrastructure servers are run under the
> latest
>  > >> > "stable" Fedora release? 
>  > >> As few as possible. 
>  > > IMO, a fundamental management/infrastructure mistake - If
> these people
>  > > were using Fedora, they would be facing the issues Fedora users are
>  > > facing everyday and likely would being to understand why people complain
>  > > about Fedora. 
>  > Why would they, after often suggesting that Fedora _not_ be used
> on
>  > production servers, use Fedora on their production servers? 
>  Depends on how they mean it:
>  - if they are referring to "long term maintained/everlasting support"
>  servers, they are right. 
"Servers" are "long-time maintained" by definition...

>  - if they mean it as "Fedora is technically too unstable",
Because there is no "long term maintenance"...

>                                                             then this
>  people should start working on improving the situation 
Which one? Fedora is about /not/ "long term" but "bleeding edge"...

>                                                         or (better)
> quit
>  Fedora. 
Do so, then.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

[Ralf Corsepius]

On Sun, 2008-10-12 at 16:48 -0300, Horst H. von Brand wrote:
>  Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  > On Fri, 2008-10-10 at 16:53 -0500, Arthur Pemberton wrote:
>  > > On Fri, Oct 10, 2008 at 4:35 PM, Ralf Corsepius <rc040203(a)freenet.de&gt;
> wrote:
>  > > > On Fri, 2008-10-10 at 12:38 -0700, Toshio Kuratomi wrote:
>  > > >> Dmitry Butskoy wrote:
>  > > >> > Itamar - IspBrasil wrote:
>  > > [snip]
>  > > >> The fact that they switched to CentOS is *good* for Fedora.
>  > > > I can not disagree more - To me, it's yet another evidence of Fedora
>  > > > being on the loose.
>  > > 
>  > > You're going to have to expound on that. I do not see Centos in any
>  > > way as in competition with Fedora.
>  
>  > EPEL drains away resources from Fedora.
>  
>  Proof? 
Urgh, isn't that obvious?

E.g.:
- Build server resources, mirror resources.
- People are using/testing EPEL instead of Fedora.
- Fedora infrastructure, e.g. EPEL enlarges the packagedb by almost
factor 2.
- EPEL would force Fedora contributors to test on both RHEL and Fedora.

>  > >  Centos is something everyone should
>  > > be proud of.
>  
>  > Well, to me CentOS is as important as any other arbitrary Linux distro.
>  > I am glad they are around, but not more and not less.
>  
>  It is around becase RHEL is popular, and open source. 
And non-free - If it was
free, the CentOS folks could start directly
contribute to Fedora or RHEL. Right now, it's them wasting time to
workaround on RHEL being non-free.

>  > > >>  CentOS's
>  > > >> goals are better oriented to the needs of someone that wants to deploy
> a
>  > > >> system and run it for years.  Fedora is good for people who want to
> get
>  > > >> the latest technologies from upstream as soon as they're stable
> enough
>  > > >> to integrate into a running system.
>  
>  > > > Right. But why can't Fedora do better? I feel Fedora could do better.
>  
>  > > Sure. With more devs, servers, time, etc.
>  
>  > ... less bureaucracy, less committees/less chiefs/more Indians,
>  > different people, different strategies.
>  
>  Show how! 
Ease reviews, bodhi, packagedb, koji, bugzilla, track, re-consider FTBS,
work-flow, trademark policy. 

E.g. right now, the tools being in use are a heterogenious mixture of
separate tools, are often broken, are far from easy to use and aim at
implementing a highly bureaucratic process/work-flow.

>   Telling everybody here how awful things are going isn't helping
>  an iota. Everything has its limits, and for every desirable quality (newest
>  shiny toys, support for the newest fad in hardware in software) there is a
>  cost (can't be supported in the long range, fast turnaround, set procedures
>  to handle a huge stream of new stuff)
>  
>  > >  But baring a sudden increase
>  > > in those, I would much prefer to see Fedora focus on dev and testing,
>  > > let other distros pretty things up.
>  
>  > ACK. Unfortunately, Fedora is drifting away from this group towards
>  > single-user desktops (e.g. OLPC).
>  
>  Then work towards drifting the opposite direction... 
One reason why I am agitating
...

>  Fedora (or any other large group of people) will move where the
> majority
>  wants to go...  
Well, deployment of an OS to servers, will always be a
"minority use
case" and will always collide somewhere with mere desktop oriented
developments.

>  > > >> > This situation seems to be reflected in the
> Fedora project itself.
>  > > >> > Guess, how many Fedora infrastructure servers are run under the
> latest
>  > > >> > "stable" Fedora release?
>  
>  > > >> As few as possible.
>  
>  > > > IMO, a fundamental management/infrastructure mistake - If these people
>  > > > were using Fedora, they would be facing the issues Fedora users are
>  > > > facing everyday and likely would being to understand why people complain
>  > > > about Fedora.
>  
>  > > Why would they, after often suggesting that Fedora _not_ be used on
>  > > production servers, use Fedora on their production servers?
>  
>  > Depends on how they mean it:
>  > - if they are referring to "long term maintained/everlasting support"
>  > servers, they are right.
>  
>  "Servers" are "long-time maintained" by definition... 
To me,
"server" is a "use-case of an OS" and is not at all connected to
running the same OS for many years. 

Yes, no doubt, running the same OS on a larger number of machines for a
longer time helps maintenance, but I do not see how this is connected to
a particular machine serving as "clients" or "servers".

Yes, no doubt, there are use-cases where "long-term API" stability is
important, but this applies to client use-cases as well as to server
use-cases.

...

Finally, yes, no doubt, Fedora is not the "shoe that fits all sizes" nor
are CentOS or RHEL, but ... this doesn't mean that Fedora may not be
applicable to server scenarios.

>  > - if they mean it as "Fedora is technically too
> unstable",
>  
>  Because there is no "long term maintenance"... 
Again, I don't see how
"lack of stability" and "no long term
maintenance" are linked together at all, nor how server and client
use-cases matter.

What matters in use-cases of short lived-distros such as Fedora is:
Upgrades "must simply work" and (admin-) personnel must be able to
handle them in a particular scenario.

>  >                                                            then
> this
>  > people should start working on improving the situation
>  
>  Which one? 
Lack of stability, lack of usability, deficiencies of the
infrastructure, bureaucracy, short-livedness ... tools

The lack of people to me is not a cause, it's a consequence of mistakes
in Fedora's history.

>   Fedora is about /not/ "long term" but "bleeding
> edge"... 
"Leading edge" doesn't necessarily have to be linked to
"bleeding" nor
"unstable". It's sad, the latter is true wrt. Fedora.

>  >                                                        or
> (better) quit
>  > Fedora.
>  
>  Do so, then. 
I haven't given in, yet. 

The cause for my current dissatisfaction is Fedora's infrastructure and
Fedora's leadership. They have driven Fedora/have allowed Fedora to move
into what I consider to be an unhealthy direction.

[Horst H. von Brand]

Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  On Sun, 2008-10-12 at 16:48 -0300, Horst H. von Brand wrote:
>  > Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  > > On Fri, 2008-10-10 at 16:53 -0500, Arthur Pemberton wrote:
>  > > > On Fri, Oct 10, 2008 at 4:35 PM, Ralf Corsepius
> <rc040203(a)freenet.de&gt; wrote:
>  > > > > On Fri, 2008-10-10 at 12:38 -0700, Toshio Kuratomi wrote:
>  > > > >> Dmitry Butskoy wrote:
>  > > > >> > Itamar - IspBrasil wrote:
>  > > > [snip]
>  > > > >> The fact that they switched to CentOS is *good* for Fedora.
>  > > > > I can not disagree more - To me, it's yet another evidence of
> Fedora
>  > > > > being on the loose.
>  > > > 
>  > > > You're going to have to expound on that. I do not see Centos in any
>  > > > way as in competition with Fedora.
>  > 
>  > > EPEL drains away resources from Fedora.
>  > 
>  > Proof? 
>  Urgh, isn't that obvious? 
No, it isn't.

Note: In my experience, getting hardware and such is cheap/easy, getting
people willing (and capable, and dependable) of doing the job is hard.

>  E.g.:
>  - Build server resources, mirror resources. 
I don't see a great drain in build servers, and mirrors are voluntary.

>  - People are using/testing EPEL instead of Fedora. 
Either I run RHEL/CentOS + EPEL or Fedora. No loss at all, more of a win
(EPEL users /also/ test Fedora stuff).

>  - Fedora infrastructure, e.g. EPEL enlarges the packagedb by almost
>  factor 2. 
Not that important, IMHO.

>  - EPEL would force Fedora contributors to test on both RHEL and
> Fedora. 
You sure? In any case, extra burden on contributors is a real drain... but
then again, EPEL and Fedora contributors aren't the same bunch, so...

>  > > >  Centos is something everyone should be proud of.
>  > > Well, to me CentOS is as important as any other arbitrary
> Linux distro.
>  > > I am glad they are around, but not more and not less. 
>  > It is around becase RHEL is popular, and open source. 
>  And non-free 
It /is/ free... you pay for support only.

>               - If it was free, the CentOS folks could start directly
>  contribute to Fedora 
No...

>                       or RHEL. 
They do (funnelling bug reports and patches upstream to RH).

>                                Right now, it's them wasting time
> to
>  workaround on RHEL being non-free. 
As I told earlier, RH is going out of their way to make CentOS /easy/, not
hard. 

>  > > > >> CentOS's goals are better oriented to the
> needs of someone 
>  > > > >> that wants to deploy a system and run it for years. Fedora is
>  > > > >> good for people who want to get the latest technologies from
>  > > > >> upstream as soon as they're stable enough to integrate into
> a
>  > > > >> running system. 
>  > > > > Right. But why can't Fedora do better?
Define "better"... "Good Fedora" is bleeding edge, not fully
stabilized
software, experimental stuff that may pan out (or it might not, being
replaced by something else), changing APIs (literally and sysadmin-wise),
fast turnaround. "Good RHEL" is rock stable, unchanging (even in details)
for years. What is good for one is terrible for the other.

>  > > > >                                        I feel
> Fedora could do better. 
>  > > > Sure. With more devs, servers, time, etc. 
>  > > ... less bureaucracy, less committees/less chiefs/more
> Indians,
>  > > different people, different strategies. 
>  > Show how! 
>  Ease reviews, bodhi, packagedb, koji, bugzilla, track, re-consider
> FTBS,
>  work-flow, trademark policy.  
Definite proposals that can be discussed?

What does "trademark policy" have to do with anything, BTW?

>  E.g. right now, the tools being in use are a heterogenious mixture
> of
>  separate tools, 
Unix...

>                  are often broken, 
Fixing hands are presumably wellcome...

>                                    are far from easy to use 
Concrete proposals on what to change how?

>                                                             and aim
> at
>  implementing a highly bureaucratic process/work-flow. 
Again, proposals, please?

>  >  Telling everybody here how awful things are going isn't
> helping
>  > an iota. Everything has its limits, and for every desirable quality (newest
>  > shiny toys, support for the newest fad in hardware in software) there is a
>  > cost (can't be supported in the long range, fast turnaround, set procedures
>  > to handle a huge stream of new stuff)
>  > 
>  > > >  But baring a sudden increase
>  > > > in those, I would much prefer to see Fedora focus on dev and testing,
>  > > > let other distros pretty things up.
>  > 
>  > > ACK. Unfortunately, Fedora is drifting away from this group towards
>  > > single-user desktops (e.g. OLPC).
>  > 
>  > Then work towards drifting the opposite direction... 
>  One reason why I am agitating ... 
"Agitating" doesn't help much.

>  > Fedora (or any other large group of people) will move where the
> majority
>  > wants to go...  
>  Well, deployment of an OS to servers, will always be a "minority
> use
>  case" and will always collide somewhere with mere desktop oriented
>  developments. 
So?

[...]

>  > > > Why would they, after often suggesting that Fedora
> _not_ be used on
>  > > > production servers, use Fedora on their production servers? 
>  > > Depends on how they mean it:
>  > > - if they are referring to "long term maintained/everlasting
> support"
>  > > servers, they are right. 
>  > "Servers" are "long-time maintained" by
> definition... 
>  To me, "server" is a "use-case of an OS" and is
> not at all connected to
>  running the same OS for many years.  
That is "testing an OS with server workload", something different entirely.

>  Yes, no doubt, running the same OS on a larger number of machines for
> a
>  longer time helps maintenance, but I do not see how this is connected to
>  a particular machine serving as "clients" or "servers".
>  
>  Yes, no doubt, there are use-cases where "long-term API" stability is
>  important, but this applies to client use-cases as well as to server
>  use-cases. 
Those /are/ the "server" use cases you want so badly! And that is at
fundamental odds with Fedora's goals, so it won't happen.

>  ... 
>  Finally, yes, no doubt, Fedora is not the "shoe that fits all
> sizes" nor
>  are CentOS or RHEL, but ... this doesn't mean that Fedora may not be
>  applicable to server scenarios.
>  
>  > > - if they mean it as "Fedora is technically too unstable",
>  > 
>  > Because there is no "long term maintenance"... 
>  Again, I don't see how "lack of stability" and "no
> long term
>  maintenance" are linked together at all, nor how server and client
>  use-cases matter. 
Again: "stability" is /not/ "when run on 10 thousand machines only one
crashes a day", it is "runs for thousands of days before crashing", and
/that/ is as un-Fedora as it gets.

>  What matters in use-cases of short lived-distros such as Fedora is:
>  Upgrades "must simply work" and (admin-) personnel must be able to
>  handle them in a particular scenario. 
Sure. Test upgrading for a few months until everything is A-OK, and here
comes the next release, before we finished testing the last one. Nice idea.

>  > >                                                           
> then this
>  > > people should start working on improving the situation 
>  > Which one? 
>  Lack of stability, 
Design objective.

>                     lack of usability, 
Do the work of usability testing, feed it back. Many thanks will flow back.

>                                        deficiencies of the
>  infrastructure, 
Ditto.

>                  bureaucracy, 
Ditto.

>                               short-livedness 
Design objective, won't change.

>                                               ... tools 
Huh?

>  The lack of people to me is not a cause, it's a consequence of
> mistakes
>  in Fedora's history. 
Is there /really/ a lack of people? Are any statistics of contributors (and
contributions) at hand?

>  >  Fedora is about /not/ "long term" but "bleeding
> edge"... 
>  "Leading edge" doesn't necessarily have to be linked to
> "bleeding" nor
>  "unstable". It's sad, the latter is true wrt. Fedora. 
It is true (sad or not) for /all/ "leading edge" endeavors, the more
"leading" the more "bleeding". Live with it, as you can't do
without.

>  > >                                                        or
> (better) quit
>  > > Fedora. 
>  > Do so, then. 
>  I haven't given in, yet.  
Great!

>  The cause for my current dissatisfaction is Fedora's
> infrastructure and
>  Fedora's leadership. They have driven Fedora/have allowed Fedora to move
>  into what I consider to be an unhealthy direction. 
Just whining that everything is wrong and in bad shape doesn't help, does
it. Come back with concrete proposals of what to fix how, and volunteer
doing the work. Run for office in Fedora on your proposals.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

[Ralf Corsepius]

On Mon, 2008-10-13 at 17:42 -0300, Horst H. von Brand wrote:
>  Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  > On Sun, 2008-10-12 at 16:48 -0300, Horst H. von Brand wrote:
>  > > Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  > > > On Fri, 2008-10-10 at 16:53 -0500, Arthur Pemberton wrote:
>  > > > > On Fri, Oct 10, 2008 at 4:35 PM, Ralf Corsepius
> <rc040203(a)freenet.de&gt; wrote:
>  > > > > > On Fri, 2008-10-10 at 12:38 -0700, Toshio Kuratomi wrote:
>  > > > > >> Dmitry Butskoy wrote:
>  > > > > >> > Itamar - IspBrasil wrote:
>  > > > > [snip]
>  > > > > >> The fact that they switched to CentOS is *good* for Fedora.
>  > > > > > I can not disagree more - To me, it's yet another evidence
> of Fedora
>  > > > > > being on the loose.
>  > > > > 
>  > > > > You're going to have to expound on that. I do not see Centos in
> any
>  > > > > way as in competition with Fedora.
>  > > 
>  > > > EPEL drains away resources from Fedora. 
>  > > > >  Centos is something everyone should be proud
> of.
>  
>  > > > Well, to me CentOS is as important as any other arbitrary Linux distro.
>  > > > I am glad they are around, but not more and not less.
>  
>  > > It is around becase RHEL is popular, and open source.
>  
>  > And non-free
>  
>  It /is/ free... you pay for support only. 
Wrong. RHEL is opensource, but it is not
free. You can't get RHEL
binaries anywhere.

>  
>  >              - If it was free, the CentOS folks could start directly
>  > contribute to Fedora
>  
>  No... 
Why not? CentOS would go out of business, because RH binaries could be
used instead => their resources would be freed.

>  > > > > >> CentOS's goals are better oriented
> to the needs of someone 
>  > > > > >> that wants to deploy a system and run it for years. Fedora
> is
>  > > > > >> good for people who want to get the latest technologies
> from
>  > > > > >> upstream as soon as they're stable enough to integrate
> into a
>  > > > > >> running system.
>  
>  > > > > > Right. But why can't Fedora do better?
>  
>  Define "better"... "Good Fedora" is bleeding edge, not fully
> stabilized
>  software, experimental stuff that may pan out (or it might not, being
>  replaced by something else), changing APIs (literally and sysadmin-wise),
>  fast turnaround. 
Yes, this is what it is supposed to be. Unfortunately this
doesn't
apply. 

Current Fedora isn't much more than a single-user desktop-focused RH
development/rawhide snapshot.

>  > > > > >                                        I
> feel Fedora could do better.
>  
>  > > > > Sure. With more devs, servers, time, etc.
>  
>  > > > ... less bureaucracy, less committees/less chiefs/more Indians,
>  > > > different people, different strategies.
>  
>  > > Show how!
>  
>  > Ease reviews, bodhi, packagedb, koji, bugzilla, track, re-consider FTBS,
>  > work-flow, trademark policy. 
>  
>  Definite proposals that can be discussed?
>  
>  What does "trademark policy" have to do with anything, BTW? 
A lot.

>  > E.g. right now, the tools being in use are a heterogenious
> mixture of
>  > separate tools,
>  
>  Unix... 
My point is: Lack of integration and them being over-loaded with
features.

>  >                 are often broken,
>  
>  Fixing hands are presumably wellcome... 
Well, ...

>  >                                   are far from easy to use
>  
>  Concrete proposals on what to change how? 
Many, many tiny details. In fact, there
are tons of usability issues
with all of them.

One pretty obvious example: bugzilla. 
IMO, it has never been less usable than it is now. It isn't possible
anymore to reopen bugs, automatic CC:-adding when commenting to BZs,
many lists are hidden in dropdowns, tags have changes (assignee), FTBS
activities have rendered bugzilla "unsearchable", flagged review stuff,
etc.

>  >                                                            and
> aim at
>  > implementing a highly bureaucratic process/work-flow.
>  
>  Again, proposals, please? 
E.g.: Work-flow: branch fc11 early (discussed and shot
down last week).

>  > >  Telling everybody here how awful things are going
> isn't helping
>  > > an iota. Everything has its limits, and for every desirable quality (newest
>  > > shiny toys, support for the newest fad in hardware in software) there is a
>  > > cost (can't be supported in the long range, fast turnaround, set
> procedures
>  > > to handle a huge stream of new stuff)
>  > > 
>  > > > >  But baring a sudden increase
>  > > > > in those, I would much prefer to see Fedora focus on dev and
> testing,
>  > > > > let other distros pretty things up.
>  > > 
>  > > > ACK. Unfortunately, Fedora is drifting away from this group towards
>  > > > single-user desktops (e.g. OLPC).
>  > > 
>  > > Then work towards drifting the opposite direction...
>  
>  > One reason why I am agitating ...
>  
>  "Agitating" doesn't help much. 
Of cause it does. It help making
people aware about problems.

>  > > Fedora (or any other large group of people) will move where
> the majority
>  > > wants to go... 
>  
>  > Well, deployment of an OS to servers, will always be a "minority use
>  > case" and will always collide somewhere with mere desktop oriented
>  > developments.
>  
>  So? 
Examples: NetworkManager, PulseAudio, setroubleshoot, SELinux-policies,
PackageKit, defaults ...

>  > > > > Why would they, after often suggesting that
> Fedora _not_ be used on
>  > > > > production servers, use Fedora on their production servers?
>  
>  > > > Depends on how they mean it:
>  > > > - if they are referring to "long term maintained/everlasting
> support"
>  > > > servers, they are right.
>  
>  > > "Servers" are "long-time maintained" by definition...
>  
>  > To me, "server" is a "use-case of an OS" and is not at all
> connected to
>  > running the same OS for many years. 
>  
>  That is "testing an OS with server workload", something different entirely.
Just because some piece of hardware is labeled "server" or caged into a
rack, doesn't make it a "server".

A server is a use-case of software, the hardware doesn't actually
matter.

>  > Yes, no doubt, running the same OS on a larger number of
> machines for a
>  > longer time helps maintenance, but I do not see how this is connected to
>  > a particular machine serving as "clients" or "servers".
>  > 
>  > Yes, no doubt, there are use-cases where "long-term API" stability is
>  > important, but this applies to client use-cases as well as to server
>  > use-cases.
>  
>  Those /are/ the "server" use cases you want so badly! 
NO! I am talking
about file-, yp/ldap-, nfs-, print-, streaming-, audio
(mpd etc.)-, video-, VCS (CVS, svn, git, etc.)-, http-, SQL (postgres,
mysql, etc.)- servers and similar.

>  > Finally, yes, no doubt, Fedora is not the "shoe that fits
> all sizes" nor
>  > are CentOS or RHEL, but ... this doesn't mean that Fedora may not be
>  > applicable to server scenarios.
>  > 
>  > > > - if they mean it as "Fedora is technically too unstable",
>  > > 
>  > > Because there is no "long term maintenance"...
>  
>  > Again, I don't see how "lack of stability" and "no long term
>  > maintenance" are linked together at all, nor how server and client
>  > use-cases matter.
>  
>  Again: "stability" is /not/ "when run on 10 thousand machines only one
>  crashes a day", it is "runs for thousands of days before crashing", and
>  /that/ is as un-Fedora as it gets. 
Again: server is a use-case of SW. Like on
desktops, I can live with
rebooting once a week due to kernel updates and don't need 1000hrs of
uptimes nor do I have 1000s of users nor machines.


>  > What matters in use-cases of short lived-distros such as Fedora
> is:
>  > Upgrades "must simply work" and (admin-) personnel must be able to
>  > handle them in a particular scenario.
>  
>  Sure. Test upgrading for a few months until everything is A-OK, 
No, rolling
release, respun distros. 


>  > Lack of stability,
>  
>  Design objective. 
No, mismanagement, lack of QA

>  >                                              ... tools
>  
>  Huh? 
koji, bodhi, bugzilla, packagedb ...

One detail: The amount of administration emails I am receiving from
koji, bodhi, packagedb: Often, several 1000s per month.

>  > The lack of people to me is not a cause, it's a consequence
> of mistakes
>  > in Fedora's history.
>  
>  Is there /really/ a lack of people? 
Yes, all over the place.

Examples:
* reviews
* Fedora infrastructure "wining" on "lack of people"
* Fedora infrastructure "signing" issues.

>   Are any statistics of contributors (and
>  contributions) at hand? 
None that I am aware about. 

Ralf

[Kevin Kofler]

Ralf Corsepius <rc040203 <at> freenet.de> writes:
>  It isn't possible anymore to reopen bugs 
It is. Just set the status dropdown from CLOSED back to ASSIGNED.

        Kevin Kofler

[Rahul Sundaram]

Ralf Corsepius wrote:
>  On Mon, 2008-10-13 at 17:42 -0300, Horst H. von Brand wrote:
> > Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
> >> On Sun, 2008-10-12 at 16:48 -0300, Horst H. von Brand wrote:
> >>> Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
> >>>> I am glad they are around, but not more and not less.
> >>> It is around becase RHEL is popular, and open source.
> >> And non-free
> > It /is/ free... you pay for support only.
>  Wrong. RHEL is opensource, but it is not free. You can't get RHEL
>  binaries anywhere. 
You are confusing non-free and commercial. They are not the same. 
Non-free is a well established term for proprietary software. FSF, 
Debian and even RPMFusion is using that term as such.

RHEL is commercial but not, non-free. The complete source in the form of 
SRPMs is available in the Red Hat public ftp server. The free 
availability of binaries is never a requirement for any of the free and 
open source licenses.

Rahul

[Ralf Corsepius]

On Tue, 2008-10-14 at 11:09 +0530, Rahul Sundaram wrote:
>  Ralf Corsepius wrote:
>  > On Mon, 2008-10-13 at 17:42 -0300, Horst H. von Brand wrote:
>  >> Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  >>> On Sun, 2008-10-12 at 16:48 -0300, Horst H. von Brand wrote:
>  >>>> Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  >>>>> I am glad they are around, but not more and not less.
>  >>>> It is around becase RHEL is popular, and open source.
>  >>> And non-free
>  >> It /is/ free... you pay for support only.
>  > Wrong. RHEL is opensource, but it is not free. You can't get RHEL
>  > binaries anywhere. 
>   The complete source in the form of 
>  SRPMs is available in the Red Hat public ftp server.  
Did I say something else?

>  The free 
>  availability of binaries is never a requirement for any of the free and 
>  open source licenses. 
This is what RedHat propaganda is telling you.

[Martin Langhoff]

On Tue, Oct 14, 2008 at 7:09 PM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
> > The free
> > availability of binaries is never a requirement for any of the free and
> > open source licenses.
>  This is what RedHat propaganda is telling you. 
I've done several papers in Law School specifically on software
licensing and analysis of GPL and related licenses. Rahul's statement
is correct -- no licenses require availability of binaries.

Might be awkward or less than helpful, but it's comfortably within the
rules of the license.

cheers,



m
-- 
 martin.langhoff(a)gmail.com
 martin(a)laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff

[Ralf Corsepius]

On Tue, 2008-10-14 at 19:43 +1300, Martin Langhoff wrote:
>  On Tue, Oct 14, 2008 at 7:09 PM, Ralf Corsepius
> <rc040203(a)freenet.de&gt; wrote:
>  >> The free
>  >> availability of binaries is never a requirement for any of the free and
>  >> open source licenses.
>  > This is what RedHat propaganda is telling you.
>  
>  I've done several papers in Law School specifically on software
>  licensing and analysis of GPL and related licenses. Rahul's statement
>  is correct -- no licenses require availability of binaries.
>
>  Might be awkward or less than helpful, but it's comfortably within the
>  rules of the license. 
I am not doubting this: It's a different definition of
free. It's one
case of the usual word-games with "freedom"-related words.

To me, a product you can not get without having to pay for, doesn't
qualify as free - It's may be free in the sense of "intellectual
property", but this doesn't make it free in the "common man's
sense".

Ask your neighbor, if he would pay USD600 for a barrel of "free beer".

Ralf

non-free software

[Rahul Sundaram]

Ralf Corsepius wrote:
>  On Tue, 2008-10-14 at 19:43 +1300, Martin Langhoff wrote:
> > On Tue, Oct 14, 2008 at 7:09 PM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
> >>> The free
> >>> availability of binaries is never a requirement for any of the free and
> >>> open source licenses.
> >> This is what RedHat propaganda is telling you.
> > I've done several papers in Law School specifically on software
> > licensing and analysis of GPL and related licenses. Rahul's statement
> > is correct -- no licenses require availability of binaries.
> >
> > Might be awkward or less than helpful, but it's comfortably within the
> > rules of the license.
>  I am not doubting this: It's a different definition of free. 
It is the most commonly accepted definition and well established within 
the free and open source software community. Free software and non-free 
software have a very specific meaning in this context. You are well 
aware of that. Using it in another way deliberately is just misleading. 
If you try to redefine it to mean commercial instead of proprietary, 
then, that would lead to the interpretation, that say Debian or 
RPMFusion non-free repository packages are only available for a fee 
which is clearly not true. Confusing betwen proprietary and commercial 
is a classic mistake we shouldn't be propagating.

Rahul

[Martin Langhoff]

On Tue, Oct 14, 2008 at 8:01 PM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  I am not doubting this: It's a different definition of free.
> It's one
>  case of the usual word-games with "freedom"-related words. 
Then you are equivocating around with the 2 meanings of free, which is
a royal waste of time.



m
-- 
 martin.langhoff(a)gmail.com
 martin(a)laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff

[Alan Cox]

On Tue, Oct 14, 2008 at 09:01:53AM +0200, Ralf Corsepius wrote:
>  Ask your neighbor, if he would pay USD600 for a barrel of "free
> beer". 
I think you fundamentally miss the entire point of free software here.

Lots of people will pay for "free" beer in the sense that free means the
recipe is published and you could go make your own. They don't want to make
their own beer at the moment and they understand either intuitively or directly
the most basic concepts of economics like specialisation.

Alan

[Ralf Corsepius]

On Tue, 2008-10-14 at 04:24 -0400, Alan Cox wrote:
>  On Tue, Oct 14, 2008 at 09:01:53AM +0200, Ralf Corsepius wrote:
>  > Ask your neighbor, if he would pay USD600 for a barrel of "free beer".
>  
>  I think you fundamentally miss the entire point of free software here. 
I don't
think so. 

I simply decided not to contribute to software products, which are not
freely (cost-free) available nor cost-freely redistributable and to
brand them as "non-free".

Ralf

[Nicu Buculei]

Ralf Corsepius wrote:
>  On Tue, 2008-10-14 at 04:24 -0400, Alan Cox wrote:
> > On Tue, Oct 14, 2008 at 09:01:53AM +0200, Ralf Corsepius wrote:
> >> Ask your neighbor, if he would pay USD600 for a barrel of "free beer".
> > I think you fundamentally miss the entire point of free software here.
>  I don't think so. 
>  
>  I simply decided not to contribute to software products, which are not
>  freely (cost-free) available nor cost-freely redistributable and to
>  brand them as "non-free". 
I tried to stay away from this flame but... I also can decide to call 
"non-free" software that does not help me getting laid, how is that 
relevant?

-- 
nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com
Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/
Open Clip Art Library: http://www.openclipart.org
my Fedora stuff: http://fedora.nicubunu.ro

[Ralf Corsepius]

On Tue, 2008-10-14 at 14:48 +0300, Nicu Buculei wrote:
>  Ralf Corsepius wrote:
>  > On Tue, 2008-10-14 at 04:24 -0400, Alan Cox wrote:
>  >> On Tue, Oct 14, 2008 at 09:01:53AM +0200, Ralf Corsepius wrote:
>  >>> Ask your neighbor, if he would pay USD600 for a barrel of "free
> beer".
>  >> I think you fundamentally miss the entire point of free software here.
>  > I don't think so. 
>  > 
>  > I simply decided not to contribute to software products, which are not
>  > freely (cost-free) available nor cost-freely redistributable and to
>  > brand them as "non-free".
>  
>  I tried to stay away from this flame but... I also can decide to call 
>  "non-free" software that does not help me getting laid, how is that 
>  relevant? 
This rationale contributes to me not to consider RHEL and CentOS, which
is the rationale why I don't consider them to be replacements for a
"Fedora LTS".

Or differently: It doesn't matter what people sell as "free", it matters
what people accept as "free".

[Tim Lauridsen]

Ralf Corsepius wrote:
>  On Tue, 2008-10-14 at 14:48 +0300, Nicu Buculei wrote:
>    
> > Ralf Corsepius wrote:
> >     
> >> On Tue, 2008-10-14 at 04:24 -0400, Alan Cox wrote:
> >>       
> >>> On Tue, Oct 14, 2008 at 09:01:53AM +0200, Ralf Corsepius wrote:
> >>>         
> >>>> Ask your neighbor, if he would pay USD600 for a barrel of "free
> beer".
> >>>>           
> >>> I think you fundamentally miss the entire point of free software here.
> >>>         
> >> I don't think so. 
> >>
> >> I simply decided not to contribute to software products, which are not
> >> freely (cost-free) available nor cost-freely redistributable and to
> >> brand them as "non-free".
> >>       
> > I tried to stay away from this flame but... I also can decide to call 
> > "non-free" software that does not help me getting laid, how is that 
> > relevant?
> >     
>  This rationale contributes to me not to consider RHEL and CentOS, which
>  is the rationale why I don't consider them to be replacements for a
>  "Fedora LTS".
>
>  Or differently: It doesn't matter what people sell as "free", it matters
>  what people accept as "free". 
>
>     
I don't accept the earth is round, so it must be flat !

Tim

[Ralf Corsepius]

On Tue, 2008-10-14 at 14:55 +0200, Tim Lauridsen wrote:

>  I don't accept the earth is round, so it must be flat ! 
The GDR was democratic, was it?

[Ralph angenendt]

Ralf Corsepius wrote:
>  This rationale contributes to me not to consider RHEL and CentOS,
> which
>  is the rationale why I don't consider them to be replacements for a
>  "Fedora LTS". 
So CentOS is non-free? 

Ralph

[Ralf Corsepius]

On Tue, 2008-10-14 at 15:25 +0200, Ralph Angenendt wrote:
>  Ralf Corsepius wrote:
>  > This rationale contributes to me not to consider RHEL and CentOS, which
>  > is the rationale why I don't consider them to be replacements for a
>  > "Fedora LTS".
>  
>  So CentOS is non-free? 
CentOS is free as "free-beer", but CentOS is not
free to take decisions
on their own, because they depend on RHEL's sources.

[Paul Black]

2008/10/14 Ralf Corsepius <rc040203(a)freenet.de&gt;
>  CentOS is free as "free-beer", but CentOS is not free to take decisions
>  on their own, because they depend on RHEL's sources. 
Centos is free to do what they like. With that freedom, they've chosen
to try to be "100% binary compatible" with with RHEL:
http://www.centos.org/modules/tinycontent/index.php?id=3

--
Paul

[Jeffrey Ollie]

On Tue, Oct 14, 2008 at 8:42 AM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  CentOS is free as "free-beer", but CentOS is not free to take decisions
>  on their own, because they depend on RHEL's sources. 
Which is a choice CentOS has made deliberately.  Were CentOS to choose
differently CentOS would be much less valuable to me.

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"

[Stephen John Smoogen]

On Tue, Oct 14, 2008 at 7:42 AM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  On Tue, 2008-10-14 at 15:25 +0200, Ralph Angenendt wrote:
> > Ralf Corsepius wrote:
> > > This rationale contributes to me not to consider RHEL and CentOS, which
> > > is the rationale why I don't consider them to be replacements for a
> > > "Fedora LTS".
> >
> > So CentOS is non-free?
>  CentOS is free as "free-beer", but CentOS is not free to take decisions
>  on their own, because they depend on RHEL's sources. 
Lets count how many angels dance on a pinhead...

Can I put any package into Fedora then? I mean if I wanted to put in a
package with EPOCH:MAXINT, provides: kernel, glibc, etc and just has a
%post rm -rf / I can add that into Fedora? Or would I be dependant on
Fedora packaging guidelines and packages?




-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

[Ralf Corsepius]

On Tue, 2008-10-14 at 10:19 -0600, Stephen John Smoogen wrote:
>  On Tue, Oct 14, 2008 at 7:42 AM, Ralf Corsepius
> <rc040203(a)freenet.de&gt; wrote:
>  > On Tue, 2008-10-14 at 15:25 +0200, Ralph Angenendt wrote:
>  >> Ralf Corsepius wrote:
>  >> > This rationale contributes to me not to consider RHEL and CentOS, which
>  >> > is the rationale why I don't consider them to be replacements for a
>  >> > "Fedora LTS".
>  >>
>  >> So CentOS is non-free?
>  > CentOS is free as "free-beer", but CentOS is not free to take decisions
>  > on their own, because they depend on RHEL's sources. 
>  Can I put any package into Fedora then? 
Yes, but you can't
modify packages in CentOS, which would break
RHEL-compatibility, nor will you be able to add any package to EPEL, if
a release of CentOS doesn't meet this package's demands.

[Stephen John Smoogen]

On Tue, Oct 14, 2008 at 1:01 AM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  On Tue, 2008-10-14 at 19:43 +1300, Martin Langhoff wrote:
> > On Tue, Oct 14, 2008 at 7:09 PM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
> > >> The free
> > >> availability of binaries is never a requirement for any of the free and
> > >> open source licenses.
> > > This is what RedHat propaganda is telling you.
> >
> > I've done several papers in Law School specifically on software
> > licensing and analysis of GPL and related licenses. Rahul's statement
> > is correct -- no licenses require availability of binaries.
> >
> > Might be awkward or less than helpful, but it's comfortably within the
> > rules of the license.
>  I am not doubting this: It's a different definition of free. It's one
>  case of the usual word-games with "freedom"-related words.
>
>  To me, a product you can not get without having to pay for, doesn't
>  qualify as free - It's may be free in the sense of "intellectual
>  property", but this doesn't make it free in the "common man's
> sense".
>  
I think common man's sense is not a logical item to deal with. The
common man does not speak English but most likely a SouthEast Asian
language, and they would probably use a word that means one of the 20
definitions of Free. The problem with the word Free as the was pointed
out since its inception and the FSF acknowledged after a while was
that it is an overloaded construct and has too many definitions. They
should have gone  with Libre or something as the French and other
languages have words that mean exactly what they were wanting.. but
English does not.

>  Ask your neighbor, if he would pay USD600 for a barrel of "free
> beer".
>  
Actually I know people who do. They spend over 600 for the ingredients
and brew their own in large vats.  But my neighbors would not fall
under the common man.

>  Ralf
>
>
>
>
>
>
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list
>  


-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

[Les Mikesell]

Martin Langhoff wrote:
>  On Tue, Oct 14, 2008 at 7:09 PM, Ralf Corsepius
> <rc040203(a)freenet.de&gt; wrote:
> >> The free
> >> availability of binaries is never a requirement for any of the free and
> >> open source licenses.
> > This is what RedHat propaganda is telling you.
>  
>  I've done several papers in Law School specifically on software
>  licensing and analysis of GPL and related licenses. Rahul's statement
>  is correct -- no licenses require availability of binaries.
>  
>  Might be awkward or less than helpful, but it's comfortably within the
>  rules of the license. 
How does that clause "You may not impose any further restrictions on the 
recipients' exercise of the rights granted herein." mesh with the 
further restrictions that Red Hat imposes?  The GPL does not distinguish 
between binaries and source in the required terms.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

[Jeffrey Ollie]

On Tue, Oct 14, 2008 at 7:54 AM, Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:
>  How does that clause "You may not impose any further restrictions on the
>  recipients' exercise of the rights granted herein." mesh with the further
>  restrictions that Red Hat imposes?  The GPL does not distinguish between
>  binaries and source in the required terms. 
To which additional restrictions do you refer?

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"

[Les Mikesell]

Jeffrey Ollie wrote:
>  On Tue, Oct 14, 2008 at 7:54 AM, Les Mikesell
> <lesmikesell(a)gmail.com&gt; wrote:
> > How does that clause "You may not impose any further restrictions on the
> > recipients' exercise of the rights granted herein." mesh with the further
> > restrictions that Red Hat imposes?  The GPL does not distinguish between
> > binaries and source in the required terms.
>  
>  To which additional restrictions do you refer? 
Can I buy one copy of a Red Hat package and redistribute it as the GPL 
permits for any GPL covered portion?  Or install on as many machines as 
I want?  Does every part that has any GPL component permit 
redistribution of the work-as-a-whole?

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

[Jeffrey Ollie]

On Tue, Oct 14, 2008 at 8:17 AM, Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:
>  Jeffrey Ollie wrote:
> >
> > On Tue, Oct 14, 2008 at 7:54 AM, Les Mikesell <lesmikesell(a)gmail.com&gt;
> > wrote:
> >>
> >> How does that clause "You may not impose any further restrictions on the
> >> recipients' exercise of the rights granted herein." mesh with the
> further
> >> restrictions that Red Hat imposes?  The GPL does not distinguish between
> >> binaries and source in the required terms.
> >
> > To which additional restrictions do you refer? 
OK, so I'm not a lawyer, and I've never purchased a copy of RHEL, and
I don't work for Red Hat but:

>  Can I buy one copy of a Red Hat package and redistribute it as the
> GPL
>  permits for any GPL covered portion? 
For certain you can redistribute the source for the GPL and other OSS
bits.  I'm less clear on whether the GPL allows you to redistribute
the binary code.  A quick re-reading of the GPLv2 left me confused as
to whether it was always talking about source code or it was talking
about source code + binaries.

>  Or install on as many machines as I want? 
I would say yes.  What you won't get is updates (at least not directly).

>  Does every part that has any GPL component permit redistribution of
>  the work-as-a-whole? 
On that I have no idea.

Anyway, if all you want is RHEL without having to pay for support, why
not go for CentOS (or one of the other rebuilds)?

One thing to note is that Red Hat has some very F/OSS-savvy lawyers
around.  I would be very surprised to find out that Red Hat was
deliberately trying to "get around" the GPL.

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"

[Jesse Keating]

On Tue, 2008-10-14 at 08:17 -0500, Les Mikesell wrote:
>  
>  Can I buy one copy of a Red Hat package and redistribute it as the GPL 
>  permits for any GPL covered portion?  Or install on as many machines as 
>  I want?  Does every part that has any GPL component permit 
>  redistribution of the work-as-a-whole? 
You can, however you would be violating the terms of your Red Hat
Network service, and Red Hat would be in their rights to terminate your
service.

Common misconception.  You don't buy RHEL.  You buy a subscription to
the Red Hat Network service.  Via the RHN service you can obtain further
subscriptions to Red Hat Enterprise Linux, and note there is no version
there.  One RHEL entitlement would work for RHEL2.1 on up to RHEL5,
whichever one you choose.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Les Mikesell]

Jesse Keating wrote:
>  On Tue, 2008-10-14 at 08:17 -0500, Les Mikesell wrote:
> > Can I buy one copy of a Red Hat package and redistribute it as the GPL 
> > permits for any GPL covered portion?  Or install on as many machines as 
> > I want?  Does every part that has any GPL component permit 
> > redistribution of the work-as-a-whole?
>  
>  You can, however you would be violating the terms of your Red Hat
>  Network service, and Red Hat would be in their rights to terminate your
>  service. 
So there is a penalty for violating the restriction.  Can you still 
claim there is no restriction?

>  Common misconception.  You don't buy RHEL.  You buy a
> subscription to
>  the Red Hat Network service.  
The question wasn't about buying it.  It was about the redistribution 
restriction attached that the GPL does not permit.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

[Gregory Maxwell]

On Tue, Oct 14, 2008 at 1:31 PM, Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:
>  So there is a penalty for violating the restriction.  Can you still
> claim
>  there is no restriction? 
I will no longer make you new copies of Linux CDs (or work on your bug
reports) if you allow your dog to dig up my tulip bed.

Have I placed a restriction on the free software that I've previously
given you?  Why would the situation change if I warned you about this
reality in advance?

On way of looking at free software licenses is:  Free software
licenses assure for the users of the software certain specific rights
with the FSF believes are both necessary and sufficient for software
to be considered free software.  Additional powers, like the ability
to get a software developer to listen to your bug reports, or a get
distributor to print more disks for you, are external to those rights.
These things are external to the license agreement, an necessarily so
since no one would accept a license which make them unbounded slaves
to all downstream recipients.


... such a stupid thread ...

GPL Licensing

[Rahul Sundaram]

Les Mikesell wrote:

>  The question wasn't about buying it.  It was about the
> redistribution 
>  restriction attached that the GPL does not permit. 
GPL requires that you will get the source if you get the binary but 
there is no requirement that forces anybody to give you the binaries in 
the first place including updates. So the subscriptions requirement are 
in compliance. Again, there is zero requirements in any free and open 
source license to give binaries for free to anybody because there is a 
limit to which copyright laws can extend itself.

You have to be pretty naive to think that Red Hat would build a business 
model without checking basic details like these. You might also want to 
note that Red Hat counsel involved is now a associate at the Software 
Freedom Law Center with Eben Moglen who wrote the license in the first 
place and Red Hat employs lawyers who participated in GPLv3 changes. If 
you actually believe that there is a license violation, feel free to 
convince any of the developers of GPL licensed code that Red Hat 
includes in RHEL or FSF itself. I am sure they would happy to tell you 
exactly why you are wrong in detail if necessary.

http://www.fsf.org/licensing/licenses/gpl-violation.html

Rahul

GPL Licensing

[Les Mikesell]

Rahul Sundaram wrote:
>  Les Mikesell wrote:
>  
> > The question wasn't about buying it.  It was about the redistribution 
> > restriction attached that the GPL does not permit.
>  
>  GPL requires that you will get the source if you get the binary but 
>  there is no requirement that forces anybody to give you the binaries in 
>  the first place including updates. So the subscriptions requirement are 
>  in compliance. Again, there is zero requirements in any free and open 
>  source license to give binaries for free to anybody because there is a 
>  limit to which copyright laws can extend itself. 
I didn't say anything about getting the first copy.  What I am saying is 
that the GPL forbids restrictions that could keep someone from 
redistributing their copy after they get it and there is no distinction 
in that regard whether the binary or source is involved.

>  If 
>  you actually believe that there is a license violation, feel free to 
>  convince any of the developers of GPL licensed code that Red Hat 
>  includes in RHEL or FSF itself. I am sure they would happy to tell you 
>  exactly why you are wrong in detail if necessary. 
I do think that if there is a penalty involved for redistributing copies 
of GPL'd code, binary or not, it conflicts with the 'no additional 
restrictions' clause of the GPL.  If they apply this restriction only to 
the non-GPL components, that would be different, but I don't know if 
that is the case.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

GPL Licensing

[Rahul Sundaram]

Les Mikesell wrote:

>  I didn't say anything about getting the first copy.  What I am
> saying is 
>  that the GPL forbids restrictions that could keep someone from 
>  redistributing their copy after they get it and there is no distinction 
>  in that regard whether the binary or source is involved. 
Copy of the entire product is not bound by a single license. You are 
conflating two different things. Let's assume that what you claim is 
true. Even then, GPL is only a copyright license and applies only to 
selective components within the product. Red Hat still has its own 
trademarks on the product and Red Hat decides (within free use 
limitations) how that trademarks should be used. It is not free for all.

>  I do think that if there is a penalty involved for redistributing
> copies 
>  of GPL'd code, binary or not, it conflicts with the 'no additional 
>  restrictions' clause of the GPL.  If they apply this restriction only to 
>  the non-GPL components, that would be different, but I don't know if 
>  that is the case. 
The conflict in only in your mind. Without the subscription agreement, 
you don't get the initial binaries and you are only guaranteed ongoing 
updates from Red Hat if you agree to it. The requirements of GPL is 
orthogonal to this since this is a additional service as Gregory Maxwell 
has indicated to you as well with other examples. If you still have 
trouble understanding this, feel free to consult with FSF and ask them 
to explain it to you. It is a waste of time and off topic to continue 
discussing it here.

Rahul

GPL Licensing

[Les Mikesell]

Rahul Sundaram wrote:
>  Les Mikesell wrote:
>  
> > I didn't say anything about getting the first copy.  What I am saying 
> > is that the GPL forbids restrictions that could keep someone from 
> > redistributing their copy after they get it and there is no 
> > distinction in that regard whether the binary or source is involved.
>  
>  Copy of the entire product is not bound by a single license. You are 
>  conflating two different things. Let's assume that what you claim is 
>  true. Even then, GPL is only a copyright license and applies only to 
>  selective components within the product. Red Hat still has its own 
>  trademarks on the product and Red Hat decides (within free use 
>  limitations) how that trademarks should be used. It is not free for all. 
So if I'd like to circumvent GPL requirements, all I have to do is add a 
trademarked item to it?

> > I do think that if there is a penalty involved for redistributing
>
> > copies of GPL'd code, binary or not, it conflicts with the 'no 
> > additional restrictions' clause of the GPL.  If they apply this 
> > restriction only to the non-GPL components, that would be different, 
> > but I don't know if that is the case.
>  
>  The conflict in only in your mind. Without the subscription agreement, 
>  you don't get the initial binaries and you are only guaranteed ongoing 
>  updates from Red Hat if you agree to it. The requirements of GPL is 
>  orthogonal to this since this is a additional service as Gregory Maxwell 
>  has indicated to you as well with other examples. 
The GPL says 'any further restrictions'.  It doesn't say some kinds of 
restrictions are OK and some not.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

GPL Licensing

[Rahul Sundaram]

Les Mikesell wrote:

>  So if I'd like to circumvent GPL requirements, all I have to do
> is add a 
>  trademarked item to it? 
Don't confuse trademark and copyright requirements. They are different.

>  The GPL says 'any further restrictions'.  It doesn't say
> some kinds of 
>  restrictions are OK and some not. 
It is not so simple as you claim. Read carefully FSF's response on 
export requirements. Many such requirements are outside the purview of GPL.

http://fedoraproject.org/wiki/FreeSoftwareAnalysis/FSF

"The GPL has no problem with you being picky about who you give the 
software to: if you want, you can decide that you'll only distribute to 
paying customers, or people with blue hair."

It appears you still have trouble understanding that GPL can only say no 
further restrictions on what it covers or you just don't want to 
understand. So go talk to someone who can explain it better if they can. 
Don't waste time on this off-topic conversation here. We are done with 
this.

Rahul

GPL Licensing

[Alan Cox]

On Tue, Oct 14, 2008 at 02:03:53PM -0500, Les Mikesell wrote:
>  I do think that if there is a penalty involved for redistributing
> copies 
>  of GPL'd code, binary or not, it conflicts with the 'no additional 
>  restrictions' clause of the GPL.  If they apply this restriction only to 
>  the non-GPL components, that would be different, but I don't know if 
>  that is the case. 
To start at the beginning of your confusion - it isn't a penalty. I'm entitled
not to distribute anything to you. I'm entitled to exclude aol.com from my
download site.

So its an additional service with conditions. That is quite different. Your
GPL rights are the same before or after.

GPL Licensing

[Les Mikesell]

Alan Cox wrote:
>  On Tue, Oct 14, 2008 at 02:03:53PM -0500, Les Mikesell wrote:
> > I do think that if there is a penalty involved for redistributing copies 
> > of GPL'd code, binary or not, it conflicts with the 'no additional 
> > restrictions' clause of the GPL.  If they apply this restriction only to 
> > the non-GPL components, that would be different, but I don't know if 
> > that is the case.
>  
>  To start at the beginning of your confusion - it isn't a penalty. I'm entitled
>  not to distribute anything to you. I'm entitled to exclude aol.com from my
>  download site.
>  
>  So its an additional service with conditions. 
Yes, conditions that are an additional restriction of what I can do with 
a GPL-covered work.

>  That is quite different. Your
>  GPL rights are the same before or after. 
No they aren't if I lose something I've paid for.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

GPL Licensing

[Alan Cox]

On Tue, Oct 14, 2008 at 04:14:24PM -0500, Les Mikesell wrote:
>  >not to distribute anything to you. I'm entitled to exclude
> aol.com from my
>  >download site.
>  >
>  >So its an additional service with conditions.
>  
>  Yes, conditions that are an additional restriction of what I can do with 
>  a GPL-covered work. 
Its an additional service. It doesn't change your GPL rights. If you can't grasp
that basic concept then I think you have a problem.

GPL Licensing

[Les Mikesell]

Alan Cox wrote:
>  On Tue, Oct 14, 2008 at 04:14:24PM -0500, Les Mikesell wrote:
> >> not to distribute anything to you. I'm entitled to exclude aol.com from my
> >> download site.
> >>
> >> So its an additional service with conditions.
> > Yes, conditions that are an additional restriction of what I can do with 
> > a GPL-covered work.
>  
>  Its an additional service. 
And taking it away or making it conditional based on giving up your GPL 
right is a restriction.

>  It doesn't change your GPL rights. If you can't grasp
>  that basic concept then I think you have a problem. 
No, I can't grasp the concept that a restriction that involves a penalty 
is not a restriction.

-- 
   Les Mikesell
     lesmikesell(a)gmail.com

GPL Licensing

[Stephen John Smoogen]

On Tue, Oct 14, 2008 at 5:06 PM, Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:
>  Alan Cox wrote:
> >
> > On Tue, Oct 14, 2008 at 04:14:24PM -0500, Les Mikesell wrote:
> >>>
> >>> not to distribute anything to you. I'm entitled to exclude aol.com from
> >>> my
> >>> download site.
> >>>
> >>> So its an additional service with conditions.
> >>
> >> Yes, conditions that are an additional restriction of what I can do with
> >> a GPL-covered work.
> >
> > Its an additional service.
>
>  And taking it away or making it conditional based on giving up your GPL
>  right is a restriction.
>
> > It doesn't change your GPL rights. If you can't grasp
> > that basic concept then I think you have a problem.
>
>  No, I can't grasp the concept that a restriction that involves a penalty is
>  not a restriction.
>  
And as long you keep insisting that your definition of how the law is
versus how the legal system sees it.. I don't see this changing. You
might as well say the GPL isn't valid because it doesn't use ALL
CAPITAL LETTERS IN ALL PARTS or some other nutter idea.


-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

[Paul Black]

2008/10/14 Ralf Corsepius <rc040203(a)freenet.de&gt;

>  > The free
>  > availability of binaries is never a requirement for any of the free and
>  > open source licenses.
>  This is what RedHat propaganda is telling you. 

Software isn't truly free until someone else builds it for you?

-- 
Paul

[Alan Cox]

On Tue, Oct 14, 2008 at 08:09:15AM +0200, Ralf Corsepius wrote:
>  > availability of binaries is never a requirement for any of the
> free and 
>  > open source licenses.
>  This is what RedHat propaganda is telling you. 
Red Hat, two words please. If you are going to pointless and pedantic you
could at least get trademarks correct even if you can't get the FSF definition
of free software right

Alan

[Alan Cox]

On Tue, Oct 14, 2008 at 05:39:11AM +0200, Ralf Corsepius wrote:
>  > It /is/ free... you pay for support only.
>  Wrong. RHEL is opensource, but it is not free. You can't get RHEL
>  binaries anywhere. 
I would suggest you re-read the FSF definition of free.

[Ralf Corsepius]

On Tue, 2008-10-14 at 04:18 -0400, Alan Cox wrote:
>  On Tue, Oct 14, 2008 at 05:39:11AM +0200, Ralf Corsepius wrote:
>  > > It /is/ free... you pay for support only.
>  > Wrong. RHEL is opensource, but it is not free. You can't get RHEL
>  > binaries anywhere.
>  
>  I would suggest you re-read the FSF definition of free.
>   
I know the FSF-definition very well. They are defining free in the sense
of "open source" - RHEL is opensource, nevertheless, there are no freely
available binaries.

[Alan Cox]

On Tue, Oct 14, 2008 at 01:38:44PM +0200, Ralf Corsepius wrote:
>  I know the FSF-definition very well. They are defining free in the
> sense
>  of "open source" 
I don't think they agree with you there, in fact Richard would probably be most
upset at such a claim...

Alan
--
	"That was said by Eric Raymond who belongs to another movement" 
			- Richard Stallman

[Les Mikesell]

Alan Cox wrote:
>  On Tue, Oct 14, 2008 at 01:38:44PM +0200, Ralf Corsepius wrote:
> > I know the FSF-definition very well. They are defining free in the sense
> > of "open source"
>  
>  I don't think they agree with you there, in fact Richard would probably be most
>  upset at such a claim... 
Yes, the term "open source" came about to correct the FSF fanaticism and 
mean something useful...

-- 
   Les Mikesell
     lesmikesell(a)gmail.com

[Ralf Corsepius]

On Tue, 2008-10-14 at 10:50 -0400, Alan Cox wrote:
>  On Tue, Oct 14, 2008 at 01:38:44PM +0200, Ralf Corsepius wrote:
>  > I know the FSF-definition very well. They are defining free in the sense
>  > of "open source"
>  
>  I don't think they agree with you there, in fact Richard would probably be most
>  upset at such a claim... 
May-be, may-be not.

Fact is: The GPL's notion of freedom is essentially covering freedom on
"source code". It's "viral" nature has has some implications on
binaries
("make source code available to customers"), but it nowhere states that
binaries having been built from GPL'ed sources must be "free-beer".

This notion actually is the door, which opens enterprises opportunities
to ship their binaries for money. Another door, enterprises use is
bundling trademarked packages next to GPL'ed packages or to claim
restrictive copyrights on the "collection" their product consists of.

[Les Mikesell]

Ralf Corsepius wrote:
>  On Tue, 2008-10-14 at 10:50 -0400, Alan Cox wrote:
> > On Tue, Oct 14, 2008 at 01:38:44PM +0200, Ralf Corsepius wrote:
> >> I know the FSF-definition very well. They are defining free in the sense
> >> of "open source"
> > I don't think they agree with you there, in fact Richard would probably be most
> > upset at such a claim...
>  May-be, may-be not.
>  
>  Fact is: The GPL's notion of freedom is essentially covering freedom on
>  "source code". It's "viral" nature has has some implications on
> binaries
>  ("make source code available to customers"), but it nowhere states that
>  binaries having been built from GPL'ed sources must be "free-beer". 
There is no distinction between binaries and source in regard to the 
rights recipients have to redistribute them, except for the point that 
if you distribute binaries at all you must also make the corresponding 
source available to the recipeints.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

[Stephen John Smoogen]

On Tue, Oct 14, 2008 at 11:23 AM, Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:
>  Ralf Corsepius wrote:
> >
> > On Tue, 2008-10-14 at 10:50 -0400, Alan Cox wrote:
> >>
> >> On Tue, Oct 14, 2008 at 01:38:44PM +0200, Ralf Corsepius wrote:
> >>>
> >>> I know the FSF-definition very well. They are defining free in the sense
> >>> of "open source"
> >>
> >> I don't think they agree with you there, in fact Richard would probably
> >> be most
> >> upset at such a claim...
> >
> > May-be, may-be not.
> >
> > Fact is: The GPL's notion of freedom is essentially covering freedom on
> > "source code". It's "viral" nature has has some implications
> on binaries
> > ("make source code available to customers"), but it nowhere states that
> > binaries having been built from GPL'ed sources must be "free-beer".
>
>  There is no distinction between binaries and source in regard to the rights
>  recipients have to redistribute them, except for the point that if you
>  distribute binaries at all you must also make the corresponding source
>  available to the recipeints.
>  
Do you have a lawyers advice on that? A courts decision on that? I ask
because I have yet to see legal advice that says that versus common
"well if I were the law, this is what I would interpret it to be."






-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

[Ralf Corsepius]

On Tue, 2008-10-14 at 11:27 -0600, Stephen John Smoogen wrote:
>  On Tue, Oct 14, 2008 at 11:23 AM, Les Mikesell
> <lesmikesell(a)gmail.com&gt; wrote:
>  > Ralf Corsepius wrote:
>  >>
>  >> On Tue, 2008-10-14 at 10:50 -0400, Alan Cox wrote:
>  >>>
>  >>> On Tue, Oct 14, 2008 at 01:38:44PM +0200, Ralf Corsepius wrote:
>  >>>>
>  >>>> I know the FSF-definition very well. They are defining free in the
> sense
>  >>>> of "open source"
>  >>>
>  >>> I don't think they agree with you there, in fact Richard would probably
>  >>> be most
>  >>> upset at such a claim...
>  >>
>  >> May-be, may-be not.
>  >>
>  >> Fact is: The GPL's notion of freedom is essentially covering freedom on
>  >> "source code". It's "viral" nature has has some
> implications on binaries
>  >> ("make source code available to customers"), but it nowhere states
> that
>  >> binaries having been built from GPL'ed sources must be
> "free-beer".
>  >
>  > There is no distinction between binaries and source in regard to the rights
>  > recipients have to redistribute them, except for the point that if you
>  > distribute binaries at all you must also make the corresponding source
>  > available to the recipeints.
>  >
>  
>  Do you have a lawyers advice on that? A courts decision on that? 
Yes, there have
been cases in front of courts, where enterprises using
"binaries having been built from GPL'ed sources" without offering their
sources had been sued.

c.f. http://gpl-violations.org/

Check their "news".

Ralf

[Les Mikesell]

Ralf Corsepius wrote:
> >> There is no distinction between binaries and source in regard to the rights
> >> recipients have to redistribute them, except for the point that if you
> >> distribute binaries at all you must also make the corresponding source
> >> available to the recipeints.
> >>
> > Do you have a lawyers advice on that? A courts decision on that?
>  Yes, there have been cases in front of courts, where enterprises using
>  "binaries having been built from GPL'ed sources" without offering their
>  sources had been sued. 
I think the question was aimed at my implication that the redistribution 
  of GPL'd binaries could not have additional restrictions applied 
(beyond the GPL itself).  Have there been any actual cases where this 
requirement was challenged one way or another?  I think it is pretty 
clear from any reading of the license but most people focus on the source.

-- 
  Les Mikesell
    lesmikesell(a)gmail.com

[James Hubbard]

On Tue, Oct 14, 2008 at 1:50 PM, Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:
>  Ralf Corsepius wrote:
> >
> >>> There is no distinction between binaries and source in regard to the
> >>> rights
> >>> recipients have to redistribute them, except for the point that if you
> >>> distribute binaries at all you must also make the corresponding source
> >>> available to the recipeints.
> >>>
> >> Do you have a lawyers advice on that? A courts decision on that?
> >
> > Yes, there have been cases in front of courts, where enterprises using
> > "binaries having been built from GPL'ed sources" without offering
> their
> > sources had been sued.
>
>  I think the question was aimed at my implication that the redistribution  of
>  GPL'd binaries could not have additional restrictions applied (beyond the
>  GPL itself).  Have there been any actual cases where this requirement was
>  challenged one way or another?  I think it is pretty clear from any reading
>  of the license but most people focus on the source. 
Sveasoft required compliance with its policies if you wished to
continue to receive updates. The FSF looked into it.  See link and
quote below.

Sveasoft and the GPL: http://lwn.net/Articles/178550/
...
To some, it looks very much like Sveasoft is attempting to add
restrictions to the GPL-licensed software it uses for its products. It
is, in essence, imposing a penalty on anyone who redistributes its
products. In the end, however, challenges to this model have not
gotten far, and the Free Software Foundation has stated that Sveasoft
is in compliance with the GPL - at least, with regard to its support
agreements.
...

[Stephen John Smoogen]

On Tue, Oct 14, 2008 at 11:37 AM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  On Tue, 2008-10-14 at 11:27 -0600, Stephen John Smoogen wrote:
> > On Tue, Oct 14, 2008 at 11:23 AM, Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:
> > > Ralf Corsepius wrote:
> > >>
> > >> On Tue, 2008-10-14 at 10:50 -0400, Alan Cox wrote:
> > >>>
> > >>> On Tue, Oct 14, 2008 at 01:38:44PM +0200, Ralf Corsepius wrote:
> > >>>>
> > >>>> I know the FSF-definition very well. They are defining free in the
> sense
> > >>>> of "open source"
> > >>>
> > >>> I don't think they agree with you there, in fact Richard would
> probably
> > >>> be most
> > >>> upset at such a claim...
> > >>
> > >> May-be, may-be not.
> > >>
> > >> Fact is: The GPL's notion of freedom is essentially covering freedom on
> > >> "source code". It's "viral" nature has has some
> implications on binaries
> > >> ("make source code available to customers"), but it nowhere states
> that
> > >> binaries having been built from GPL'ed sources must be
> "free-beer".
> > >
> > > There is no distinction between binaries and source in regard to the rights
> > > recipients have to redistribute them, except for the point that if you
> > > distribute binaries at all you must also make the corresponding source
> > > available to the recipeints.
> > >
> >
> > Do you have a lawyers advice on that? A courts decision on that?
>  Yes, there have been cases in front of courts, where enterprises using
>  "binaries having been built from GPL'ed sources" without offering their
>  sources had been sued.
>  
That is a completely different problem space. We aren't even talking
apples and oranges but apples and orangutans.

Red Hat gives out the source to its customers.. which it is legally
obligated to. AND gives the source to us freeloaders, which it is not
legally obligated to.

Red Hat gives out its binaries to its customers but does not give it
out to us freeloaders which it is not legally obligated to.. any more
than you are legally obligated to give me a peanut and butter sandwich
that you just made if I came to your door.

Red Hat makes an agreement with you that you will get their compiled
binaries from them for X dollars and a stipulation that says "if you
share the binaries, we will not give you updates anymore." Companies
from the beginning of the GPL have done this and have been told by the
authors of the GPL that this was well within the intent of the license
as it does not restrict the usage of the source code in any way.


-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

[Les Mikesell]

Stephen John Smoogen wrote:
>  On Tue, Oct 14, 2008 at 11:23 AM, Les Mikesell
> <lesmikesell(a)gmail.com&gt; wrote:
> > Ralf Corsepius wrote:
> >> On Tue, 2008-10-14 at 10:50 -0400, Alan Cox wrote:
> >>> On Tue, Oct 14, 2008 at 01:38:44PM +0200, Ralf Corsepius wrote:
> >>>> I know the FSF-definition very well. They are defining free in the sense
> >>>> of "open source"
> >>> I don't think they agree with you there, in fact Richard would probably
> >>> be most
> >>> upset at such a claim...
> >> May-be, may-be not.
> >>
> >> Fact is: The GPL's notion of freedom is essentially covering freedom on
> >> "source code". It's "viral" nature has has some
> implications on binaries
> >> ("make source code available to customers"), but it nowhere states
> that
> >> binaries having been built from GPL'ed sources must be
> "free-beer".
> > There is no distinction between binaries and source in regard to the rights
> > recipients have to redistribute them, except for the point that if you
> > distribute binaries at all you must also make the corresponding source
> > available to the recipeints.
> >
>  
>  Do you have a lawyers advice on that? A courts decision on that? I ask
>  because I have yet to see legal advice that says that versus common
>  "well if I were the law, this is what I would interpret it to be." 
I'm sure you could pay a lawyer to argue either side for you if you 
wanted, but I don't see any possible way to avoid the conclusion that a 
binary is a derivative of the original source and the license explicitly 
states that it applies to all derivative works.

-- 
    Les Mikesell
      lesmikesell(a)gmail.com

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 14 October 2008 at 05:39, Ralf Corsepius wrote:
>  On Mon, 2008-10-13 at 17:42 -0300, Horst H. von Brand wrote:
>  > Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  > > On Sun, 2008-10-12 at 16:48 -0300, Horst H. von Brand wrote: 
[...]
>  > > > Fedora (or any other large group of people) will move
> where the majority
>  > > > wants to go... 
>  > 
>  > > Well, deployment of an OS to servers, will always be a "minority use
>  > > case" and will always collide somewhere with mere desktop oriented
>  > > developments.
>  > 
>  > So?
>  Examples: NetworkManager, PulseAudio, setroubleshoot, SELinux-policies,
>  PackageKit, defaults ... 
I have to agree here. NM maintainer keeps pushing it on people who don't
want it. There is a bug[1] filed, which was fixed and then reverted and now
yum update wants to install NM on my system again, which drags in other
packages which I don't want on my system either.
Another example of its brokenness is this: if you log out of the X session,
you lose your (wireless) network connection.

SELinux is another subject for a good rant. Example: I created /var/log/dovecot,
chowned it to dovecot user and configured it to put its logs there. Bang!
SELinux denial. There's no easy way to fix it permanently either and SELinux
tools documentation is akin to arcane knowledge. Unless you're familiar with
all the terminology, you won't understand it.

PulseAudio is another mess. Three Fedora releases down the road and it still
doesn't work right. It's another of the things I turn off and uninstall after
installing a new Fedora box.

I could go on, but that's enough for now.

[...]
>  > >                                              ... tools
>  > 
>  > Huh?
>  koji, bodhi, bugzilla, packagedb ...
>  
>  One detail: The amount of administration emails I am receiving from
>  koji, bodhi, packagedb: Often, several 1000s per month. 
Yeah. Why would I want to receive notification that I requested an update
to be pushed to testing or stable? I already know that, I just did it!

Regards,
R.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=351101

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

[Kevin Kofler]

Dominik 'Rathann' Mierzejewski <dominik <at> greysector.net> writes:
>  Another example of its brokenness is this: if you log out of the X
> session,
>  you lose your (wireless) network connection. 
Well, if you could help me fix the bugs in this patch:
http://mail.gnome.org/archives/networkmanager-list/2008-September/msg0028...
so it can get merged, that would solve this problem. :-)

>  SELinux is another subject for a good rant. Example: I
>  created /var/log/dovecot,
>  chowned it to dovecot user and configured it to put its logs there. Bang!
>  SELinux denial. There's no easy way to fix it permanently either and SELinux
>  tools documentation is akin to arcane knowledge. Unless you're familiar with
>  all the terminology, you won't understand it. 
I also consider SELinux to be a useless PITA and I turn it off on all my 
machines (completely, not just permissive).

>  PulseAudio is another mess. Three Fedora releases down the road and
> it still
>  doesn't work right. It's another of the things I turn off and uninstall after
>  installing a new Fedora box. 
PulseAudio works for me.

        Kevin Kofler

[David P. Quigley]

On Tue, 2008-10-14 at 11:32 +0200, Dominik 'Rathann' Mierzejewski wrote:
>  SELinux is another subject for a good rant. Example: I created
> /var/log/dovecot,
>  chowned it to dovecot user and configured it to put its logs there. Bang!
>  SELinux denial. There's no easy way to fix it permanently either and SELinux
>  tools documentation is akin to arcane knowledge. Unless you're familiar with
>  all the terminology, you won't understand it.
>   
[snip]

Permanent fix which survives relabels.

/usr/sbin/semanage fcontext -a -t dovecot_var_log_t /var/log/dovecot
/sbin/restorecon -v /var/log/dovecot

SELinux documentation has been lacking in the past but Red Hat has hired
someone to write proper documentation for SELinux and it is getting
better every day. In an article on LWN I answered this question[1]. In
addition to this someone also linked the page below which contains quite
a bit of information that this person gathered when learning about
SELinux[2]. If you are willing to take the time to go through some of
his stuff you will realize SELinux really isn't as difficult as people
make it out to be, it's just that its not what they are use to. You
already know to set one set of permissions on the file when you create
it you just have to realize there is a type that needs to be set as
well.

[1]http://lwn.net/Articles/290168/
[2]http://equivocation.org/selinux

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 15 October 2008 at 00:36, David P. Quigley wrote:
>  On Tue, 2008-10-14 at 11:32 +0200, Dominik 'Rathann'
> Mierzejewski wrote:
>  > SELinux is another subject for a good rant. Example: I created /var/log/dovecot,
>  > chowned it to dovecot user and configured it to put its logs there. Bang!
>  > SELinux denial. There's no easy way to fix it permanently either and SELinux
>  > tools documentation is akin to arcane knowledge. Unless you're familiar with
>  > all the terminology, you won't understand it.
>  > 
>  [snip]
>  
>  Permanent fix which survives relabels. 
And how do you know that? I can't find anything about it in man semanage.

>  /usr/sbin/semanage fcontext -a -t dovecot_var_log_t /var/log/dovecot
>  /sbin/restorecon -v /var/log/dovecot 
You mean there's no generic "allow-owner-to-write-in-their-own-directory"
setting? That's just great. So how do I find out the magic incantation
for another application?

>  SELinux documentation has been lacking in the past but Red Hat has
> hired
>  someone to write proper documentation for SELinux and it is getting
>  better every day. In an article on LWN I answered this question[1]. In
>  addition to this someone also linked the page below which contains quite
>  a bit of information that this person gathered when learning about
>  SELinux[2]. If you are willing to take the time to go through some of
>  his stuff you will realize SELinux really isn't as difficult as people
>  make it out to be, it's just that its not what they are use to. You
>  already know to set one set of permissions on the file when you create
>  it you just have to realize there is a type that needs to be set as
>  well.
>  
>  [1]http://lwn.net/Articles/290168/
>  [2]http://equivocation.org/selinux 
Ah. Isn't that obvious? An LWN article and some random website as the canonical
source of SELinux documentation. Of course that's the first place anyone will
look.

At least put it in policycoreutils package docs. There's nothing apart from
manpages there and these are quite uninformative. Or put those articles (or
link to them) on Fedora wiki. Please.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

[David P. Quigley]

On Wed, 2008-10-15 at 12:45 +0200, Dominik 'Rathann' Mierzejewski wrote:
>  On Wednesday, 15 October 2008 at 00:36, David P. Quigley wrote:
>  > On Tue, 2008-10-14 at 11:32 +0200, Dominik 'Rathann' Mierzejewski wrote:
>  > > SELinux is another subject for a good rant. Example: I created
> /var/log/dovecot,
>  > > chowned it to dovecot user and configured it to put its logs there. Bang!
>  > > SELinux denial. There's no easy way to fix it permanently either and
> SELinux
>  > > tools documentation is akin to arcane knowledge. Unless you're familiar
> with
>  > > all the terminology, you won't understand it.
>  > > 
>  > [snip]
>  > 
>  > Permanent fix which survives relabels.
>  
>  And how do you know that? I can't find anything about it in man semanage. 
The new documentation being written addresses this. Also I think Dan
rewrote the man pages recently so you will probably see changes to them
in the next version of Fedora.

>  
>  > /usr/sbin/semanage fcontext -a -t dovecot_var_log_t /var/log/dovecot
>  > /sbin/restorecon -v /var/log/dovecot
>  
>  You mean there's no generic "allow-owner-to-write-in-their-own-directory"
>  setting? That's just great. So how do I find out the magic incantation
>  for another application? 
There is no concept of "owner" in SELinux. The permission checks aren't
based on the identity of the user but rather the program that is being
executed. Trying to find out the correct type of a file is something
that is a little difficult at the moment. Once again this comes down to
documentation. It would be nice to have a list of each of the
applications covered by the policy, their types (listed by application)
and what their purposes is. If we had a document that said the targeted
policy covers dovecot and here are the types for it and their meaning it
would make life easier for people. This way you could have lookedup
dovecot and its logfile type and seen it was dovecot_var_log_t. I will
add this onto the list of things for the documentation writer to look
into but you are right as of the moment it is a little difficult to
figure it out.

However since that list doesn't currently exist (at least not that I
know of) the way I found the correct type for you was to load up the
loaded policy in apol and look for all the types that started with
dovecot. 

>  
>  > SELinux documentation has been lacking in the past but Red Hat has hired
>  > someone to write proper documentation for SELinux and it is getting
>  > better every day. In an article on LWN I answered this question[1]. In
>  > addition to this someone also linked the page below which contains quite
>  > a bit of information that this person gathered when learning about
>  > SELinux[2]. If you are willing to take the time to go through some of
>  > his stuff you will realize SELinux really isn't as difficult as people
>  > make it out to be, it's just that its not what they are use to. You
>  > already know to set one set of permissions on the file when you create
>  > it you just have to realize there is a type that needs to be set as
>  > well.
>  > 
>  > [1]http://lwn.net/Articles/290168/
>  > [2]http://equivocation.org/selinux
>  
>  Ah. Isn't that obvious? An LWN article and some random website as the canonical
>  source of SELinux documentation. Of course that's the first place anyone will
>  look.
>  
>  At least put it in policycoreutils package docs. There's nothing apart from
>  manpages there and these are quite uninformative. Or put those articles (or
>  link to them) on Fedora wiki. Please. 
Well there is also SELinux by Example by the Tresys folks. That is
considered one of the canonical sources of information about SELinux.
Also there are the foundation papers on the NSA website you can read as
well. I may sound like a broken record with this but a lot of this stuff
will be addressed once the documentation writer releases the new
documentation.  The current state of documentation isn't really well
organized but its out there and hopefully once all the new docs are
released it will provide all the information people need in a
centralized place. If documentation is the main hurdle for people using
SELinux we hope that the new docs will make understanding SELinux easier
for all those who want to learn it. 

If there are any topics you would like to see in the documentation feel
free to send them to me and Ill add them onto the list for the
documentation writer. The current list can be seen at the URL below[1].
If you are interested in the current state of the documentation work you
can look at the SELinux mailing list archives for messages from Murray
McAllister[2]. He posted the initial drafts of the documentation and
there are numerous responses to his postings with addition information.
It's worth noting that these documents are still drafts so they might
not be 100% correct at the moment and will probably contain more
information in their finished form. 

Dave

[1]http://selinuxproject.org/page/Documentation_TODO
[2]http://marc.info/?l=selinux&w=2&r=1&s=McAllister&q=b

[Michael Schwendt]

On Sat, 11 Oct 2008 00:23:48 +0200, Ralf Corsepius wrote:

>  > You're going to have to expound on that. I do not see Centos
> in any
>  > way as in competition with Fedora.
>
>  EPEL drains away resources from Fedora. 
I wish it were like that. EPEL is just another build target. It's a
dumping-ground for Fedora pkg spec files. It's getting filled with
trial-and-error builds. Just observe how many build deps are missing, the
build jobs fail, and the packager strips a spec till it builds. With no
evidence that the packagers spend much time on EPEL that is missing
elsewhere -- it's not as if they do back-porting or similar work where
Fedora Legacy failed due to lack of man-power/volunteers. Version upgrades
are done in EPEL in the same careless way as in Fedora, except that this
road will lead to a dead end somewhere, because EPEL and RHEL are
separately controlled and developed. [We've had similar cases with Fedora
Extras before, where upgrades in Core became necessary.]

[Les Mikesell]

Arthur Pemberton wrote:
> > Right. But why can't Fedora do better? I feel Fedora could do better.
>  
>  Sure. With more devs, servers, time, etc. But baring a sudden increase
>  in those, I would much prefer to see Fedora focus on dev and testing,
>  let other distros pretty things up. 
The way to get more devs is to make developing on Fedora useful. 
Currently it's a dead end and not a path towards something running in 
production.

> > IMO, a fundamental management/infrastructure mistake - If these
> people
> > were using Fedora, they would be facing the issues Fedora users are
> > facing everyday and likely would being to understand why people complain
> > about Fedora.
>  
>  Why would they, after often suggesting that Fedora _not_ be used on
>  production servers, use Fedora on their production servers? 
Likewise, why develop for/on it?  Just so you can hope that a 
similar-enough-to-maybe-work enterprise platform will eventually appear?

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

[Toshio Kuratomi]

Ralf Corsepius wrote:
>  On Fri, 2008-10-10 at 12:38 -0700, Toshio Kuratomi wrote: 
> >   The reason is not about stability.  It is about
> > updates.  Once Fedora stops getting updates we'd have to upgrade to the
> > next Fedora release with all of the churn that causes for vastly
> > unrelated pieces of the OS. 
>  Gotcha! If not even the Fedora project can handle the issues, why do you
>  expect users to be able to solve them? I think technically the issues
>  can be overcome. It's a matter of will.
>   
No gotcha here.  I don't expect users to handle the issues.  Either the
users in question want the opportunity to run the latest software in an
integrated distro and so choose to run Fedora or they want to have a
stable platform on which to deploy their own work and therefore they use
CentOS/RHEL/Debian Stable.

There's a right tool for any job and a wrong tool.  Using your crescent
wrench to hammer nails is possible but not very satisfying.

-Toshio

[Les Mikesell]

Toshio Kuratomi wrote:
>  
>  No gotcha here.  I don't expect users to handle the issues.  Either the
>  users in question want the opportunity to run the latest software in an
>  integrated distro and so choose to run Fedora or they want to have a
>  stable platform on which to deploy their own work and therefore they use
>  CentOS/RHEL/Debian Stable. 
No, it's not an either/or scenario. Users may way to develop something 
new and be willing to put up with unstable fedora to get current tools 
for that, but there is no clear transition plan to put what they have 
built into production.  In the old RH X.0 -> X.1 -> X.2 days the 
transition from a new release to a stable OS usable in production 
happened through updates - now it doesn't happen at all.  Support is 
simply dropped for the platform you started on and there is no reason to 
expect anywhere near the same library versions and environment as you 
migrate to a stable platform.

>  There's a right tool for any job and a wrong tool.  Using your
> crescent
>  wrench to hammer nails is possible but not very satisfying. 
What's the 'right' tool to develop for the next version of Centos?

-- 
    Les Mikesell
      lesmikesell(a)gmail.com

[Toshio Kuratomi]

Les Mikesell wrote:
>  Toshio Kuratomi wrote:
> >
> > No gotcha here.  I don't expect users to handle the issues.  Either the
> > users in question want the opportunity to run the latest software in an
> > integrated distro and so choose to run Fedora or they want to have a
> > stable platform on which to deploy their own work and therefore they use
> > CentOS/RHEL/Debian Stable.
>  
>  No, it's not an either/or scenario.  
You're confusing what you want with what is.  What is *is* an either/or
scenario as there is no definite path from starting with Fedora to
getting to a long term OS.  What could be is a long term release for
certain releases if you and other like minded people do the work to
offer security updates and major bugfixes beyond the current EOL.

>  Users may way to develop something
>  new and be willing to put up with unstable fedora to get current tools
>  for that, but there is no clear transition plan to put what they have
>  built into production.  In the old RH X.0 -> X.1 -> X.2 days the
>  transition from a new release to a stable OS usable in production
>  happened through updates - now it doesn't happen at all.  Support is
>  simply dropped for the platform you started on and there is no reason to
>  expect anywhere near the same library versions and environment as you
>  migrate to a stable platform.
>  
> > There's a right tool for any job and a wrong tool.  Using your crescent
> > wrench to hammer nails is possible but not very satisfying.
>  
>  What's the 'right' tool to develop for the next version of Centos?
>   
Why, the initial release of the Fedora version that the next version of
CentOS is going to be based on, of course! :-)

And if you want to ask which version of Fedora that is, I'd like to ask
you how you knew there was going to be a RHL 6.2 but not a RHL 6.3; a
RHL 7.3, but not a RHL 8.1....

-Toshio

[Les Mikesell]

Toshio Kuratomi wrote:
>  
> >> No gotcha here.  I don't expect users to handle the issues.  Either the
> >> users in question want the opportunity to run the latest software in an
> >> integrated distro and so choose to run Fedora or they want to have a
> >> stable platform on which to deploy their own work and therefore they use
> >> CentOS/RHEL/Debian Stable.
> > No, it's not an either/or scenario. 
>  
>  You're confusing what you want with what is. 
No, I was responding to your misconception of what users want as stated 
above.  What you said is not what I want.

>  What is *is* an either/or
>  scenario as there is no definite path from starting with Fedora to
>  getting to a long term OS. 
Agreed, hence this thread of complaints.

>   What could be is a long term release for
>  certain releases if you and other like minded people do the work to
>  offer security updates and major bugfixes beyond the current EOL. 
That doesn't make a lot of sense.  Why would you want to commit to long 
term support of some otherwise orphaned variant when all that is needed 
is a smooth, planned transition to a version designed for stability with 
existing long term support?

> >> There's a right tool for any job and a wrong tool.  Using
> your crescent
> >> wrench to hammer nails is possible but not very satisfying.
> > What's the 'right' tool to develop for the next version of Centos?
> >
>  Why, the initial release of the Fedora version that the next version of
>  CentOS is going to be based on, of course! :-) 
Maybe - if the users that reported the bugs that permitted the 
improvements in stability through the fedora cycles weren't abandoned 
and left on their own to figure out the departure point and what the 
differences will be.

>  And if you want to ask which version of Fedora that is, I'd like
> to ask
>  you how you knew there was going to be a RHL 6.2 but not a RHL 6.3; a
>  RHL 7.3, but not a RHL 8.1.... 
The version numbers aren't particularly relevant there (and by 8.x the 
process was so badly broken that no one would have wanted an 8.1).  The 
point is that from the early versions through 7.3 a user could start 
from the original release, report bugs while doing his own local 
development and testing, and end up with both the system and local work 
stabilizing and being usable in production together.  With fedora you 
get the bugs and can report them, but you never end up with a usable 
platform in the end.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

[Michael Schwendt]

On Fri, 10 Oct 2008 23:35:36 +0200, Ralf Corsepius wrote:

>  >  CentOS's
>  > goals are better oriented to the needs of someone that wants to deploy a
>  > system and run it for years.  Fedora is good for people who want to get
>  > the latest technologies from upstream as soon as they're stable enough
>  > to integrate into a running system.
>  Right. But why can't Fedora do better? I feel Fedora could do better.
>  
>  > > This situation seems to be reflected in the Fedora project itself.
>  > > Guess, how many Fedora infrastructure servers are run under the latest
>  > > "stable" Fedora release?
>  > 
>  > As few as possible.
>  IMO, a fundamental management/infrastructure mistake - If these people
>  were using Fedora, they would be facing the issues Fedora users are
>  facing everyday and likely would being to understand why people complain
>  about Fedora. 
How many of the packagers run Rawhide?
How often do they run it compared with other Fedora/CentOS/RHEL releases?

How many don't try Rawhide until one of the test releases?

How many skip even the test releases and only try FN+1 after its
final release?

How many use multi-boot machines where they switch between FN-1, FN
and FN+1 as is necessary for testing and also for testing updates?

How many publish untested mass-builds of updates (as aided by
%{dist}-madness)?

>  >   The reason is not about stability.  It is about
>  > updates.  Once Fedora stops getting updates we'd have to upgrade to the
>  > next Fedora release with all of the churn that causes for vastly
>  > unrelated pieces of the OS. 
>  Gotcha! If not even the Fedora project can handle the issues, why do you
>  expect users to be able to solve them? I think technically the issues
>  can be overcome. It's a matter of will.

[Matej Cepl]

On 2008-10-10, 12:53 GMT, Itamar - IspBrasil wrote:
>  In my opinion fedora is losing space from centos and ubuntu 
a) If we are loosing to CentOS (which is a derivative of RHEL) 
   then there is no loss to our community.
b) If anybody is running production servers on Fedora, then worse 
   for him -- Fedora is a developers' distro and that's the 
   reason why it has limited support. If you think you want to 
   revive Fedora Legacy project (which died for disinterest of 
   its users), then I would suggest that you join CentOS -- I am 
   quite certain they can use as many people helping as possible.
c) Concerning Ubuntu. I am a Red Hat employee so I shouldn't talk 
   lightly about our competition, so let me add only this 
   thought.  If you compare current Ubuntu with current Fedora 
   (or maybe previous version of Fedora, because we tend to be 
   slightly ahead -- which is both good and bad) then difference 
   is only minimal.  What I would be much more interested is 
   difference between support for six years old distro (RHEL 
   2.1AS was released on 2002-03-26) on RHEL and Ubuntu. Yes, 
   I know, there is no six-years old Ubuntu, and there never will 
   be (LTS support is only five years on servers).
       However, still I would be interested in the level of 
   support for Dapper Drake (6.06) now comparing with the level 
   of support we provide for RHEL5 (that's roughly the same age, 
   right?). How many patches in the last six months went to 
   Dapper? I see on packages.ubuntu.com/firefox they still have 
   firefox 1.5 (we have 3.* even for RHEL3). Supporting old 
   distro is a huge undertaking (what about fixing bugs in kernel 
   2.4.9? That's is what we have in RHEL 2.1 -- and yes I see in
   our internal systems build from the last month, so it is still
   maintained) and jury is still out, whether Canonical will be 
   able to do it.

Best,

Matej

[Dmitry Butskoy]

Matej Cepl wrote:
>  b) If anybody is running production servers on Fedora, then worse 
>     for him  
Well, how about enthusiasm here?

What should do some previously RedHat-oriented enthusiast, when all the 
area for application of his enthusiasm is some "production environment"? 
Use RHEL/CentOS anywhere and Fedora on his laptop only? But RHEL/CentOS 
is far from the "bleeding edge", hence his enthusiasm just disappear...


~buc

[Arthur Pemberton]

On Fri, Oct 10, 2008 at 9:36 AM, Dmitry Butskoy <buc(a)odusz.so-cdu.ru&gt; wrote:
>  Matej Cepl wrote:
> >
> > b) If anybody is running production servers on Fedora, then worse   for
> > him
>
>  Well, how about enthusiasm here?
>
>  What should do some previously RedHat-oriented enthusiast, when all the area
>  for application of his enthusiasm is some "production environment"? Use
>  RHEL/CentOS anywhere and Fedora on his laptop only? But RHEL/CentOS is far
>  from the "bleeding edge", hence his enthusiasm just disappear... 


I don't understand what you're saying. Why do you need to be
bleeding-edge in your stable environments?



-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )

[Dmitry Butskoy]

Arthur Pemberton wrote:
>  On Fri, Oct 10, 2008 at 9:36 AM, Dmitry Butskoy
> <buc(a)odusz.so-cdu.ru&gt; wrote:
>    
> > Matej Cepl wrote:
> >     
> >> b) If anybody is running production servers on Fedora, then worse   for
> >> him
> >>       
> > Well, how about enthusiasm here?
> >
> > What should do some previously RedHat-oriented enthusiast, when all the area
> > for application of his enthusiasm is some "production environment"? Use
> > RHEL/CentOS anywhere and Fedora on his laptop only? But RHEL/CentOS is far
> > from the "bleeding edge", hence his enthusiasm just disappear...
> >     
>
>
>
>  I don't understand what you're saying. Why do you need to be
>  bleeding-edge in your stable environments?
>     
Well, not the "bleeding-edge" literally.

An environment, which is considered stable, can be "untypical". Ie. 
"untypical production stable environment".

All the years RHL/Fedora is used at my work, we was compelled (from time 
to time) to even port some future versions/features of N+1 distro to the 
current N distro. Because the features required for our "untypical" 
environment have appeared somewhere closer to the bleeding-edge...


~buc

[Arthur Pemberton]

On Fri, Oct 10, 2008 at 9:52 AM, Dmitry Butskoy <buc(a)odusz.so-cdu.ru&gt; wrote:
>  Arthur Pemberton wrote:
> >
> > On Fri, Oct 10, 2008 at 9:36 AM, Dmitry Butskoy <buc(a)odusz.so-cdu.ru&gt;
> > wrote:
> >
> >>
> >> Matej Cepl wrote:
> >>
> >>>
> >>> b) If anybody is running production servers on Fedora, then worse   for
> >>> him
> >>>
> >>
> >> Well, how about enthusiasm here?
> >>
> >> What should do some previously RedHat-oriented enthusiast, when all the
> >> area
> >> for application of his enthusiasm is some "production environment"?
> Use
> >> RHEL/CentOS anywhere and Fedora on his laptop only? But RHEL/CentOS is
> >> far
> >> from the "bleeding edge", hence his enthusiasm just disappear...
> >>
> >
> >
> >
> > I don't understand what you're saying. Why do you need to be
> > bleeding-edge in your stable environments?
> >
>
>  Well, not the "bleeding-edge" literally.
>
>  An environment, which is considered stable, can be "untypical". Ie.
>  "untypical production stable environment".
>
>  All the years RHL/Fedora is used at my work, we was compelled (from time to
>  time) to even port some future versions/features of N+1 distro to the
>  current N distro. Because the features required for our "untypical"
>  environment have appeared somewhere closer to the bleeding-edge... 

Sounds like you want Centos + Extras then. Or maybe Extras isn't up to
date enough, and some people may need to create a new 'Current' repo
for Centos.

The closest I've come to wanting something "new" in Centos was wanting
a 2.4.3 (or so) Python instead of the 2.4.2 (or so) that comes with
RHEL/Centos. And that was easily avoided.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )

[Patrice Dumas]

On Fri, Oct 10, 2008 at 10:13:14AM -0500, Arthur Pemberton wrote:
>  
>  Sounds like you want Centos + Extras then. Or maybe Extras isn't up to
>  date enough, and some people may need to create a new 'Current' repo
>  for Centos. 
If you are referring to EPEL with Extras, EPEL should not move faster
than RHEL, and, as far as I can tell, a 'Current' repo for Centos
doesn't exist.

--
Pat

[Arthur Pemberton]

On Fri, Oct 10, 2008 at 10:17 AM, Patrice Dumas <pertusus(a)free.fr&gt; wrote:
>  On Fri, Oct 10, 2008 at 10:13:14AM -0500, Arthur Pemberton wrote:
> >
> > Sounds like you want Centos + Extras then. Or maybe Extras isn't up to
> > date enough, and some people may need to create a new 'Current' repo
> > for Centos.
>
>  If you are referring to EPEL with Extras, EPEL should not move faster
>  than RHEL, and, as far as I can tell, a 'Current' repo for Centos
>  doesn't exist. 

Well I suspected from my usage that EPEL with Extras does not move
faster. Hence why I suggested that those interested may want to create
a 'Current' repo. To pull in newer packages that they feel are stable.
I am aware that such doesn't exist, and 'Current' is just a
placeholder for the idea. I myself see little value in it, but some
seem to.

Are there any distros which are very current, stable _and_ source of a
lot of development in the Linux/FOSS community? Seems to me, that once
can any given distro can only have two out of three of those
properties.

IMHO: If dropping any idea of stability meant a 50% (just an arbitrary
positive number) increase in dev productivity, I'm all for it.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )

[Jesse Keating]

On Fri, 2008-10-10 at 11:16 -0500, Arthur Pemberton wrote:
>  Are there any distros which are very current, stable _and_ source of
> a
>  lot of development in the Linux/FOSS community? Seems to me, that once
>  can any given distro can only have two out of three of those
>  properties. 
It's like the old good, fast, cheap adage.  Pick two of those because
that's all you'll ever get.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Matthew Miller]

On Fri, Oct 10, 2008 at 09:21:42AM -0700, Jesse Keating wrote:
>  It's like the old good, fast, cheap adage.  Pick two of those
> because
>  that's all you'll ever get. 
And in this case "good + fast" is so non-cheap that no one in the world does
it. (Given the proper long-term-support context for "good" -- I certainly
don't mean that Fedora isn't good.)

-- 
Matthew Miller <mattdm(a)mattdm.org&gt;
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences

[Les Mikesell]

Arthur Pemberton wrote:

>  
>  Well I suspected from my usage that EPEL with Extras does not move
>  faster. Hence why I suggested that those interested may want to create
>  a 'Current' repo. To pull in newer packages that they feel are stable.
>  I am aware that such doesn't exist, and 'Current' is just a
>  placeholder for the idea. I myself see little value in it, but some
>  seem to. 
Now that RHEL apparently realizes that they don't have to stick to a 
years-behind firefox and openoffice, there's a little less value in 3rd 
party maintainers for those updates...

-- 
   Les Mikesell
     lesmikesell(a)gmail.com

[Matej Cepl]

On 2008-10-10, 16:16 GMT, Arthur Pemberton wrote:
>  Are there any distros which are very current, stable _and_ 
>  source of a lot of development in the Linux/FOSS community?  
>  Seems to me, that once can any given distro can only have two 
>  out of three of those properties. 
Two? Which one is "very current and stable"?

Matěj

[Dmitry Butskoy]

Arthur Pemberton wrote:
>  On Fri, Oct 10, 2008 at 9:52 AM, Dmitry Butskoy
> <buc(a)odusz.so-cdu.ru&gt; wrote:
> >
> >
> > An environment, which is considered stable, can be "untypical". Ie.
> > "untypical production stable environment".
> >
> > All the years RHL/Fedora is used at my work, we was compelled (from time to
> > time) to even port some future versions/features of N+1 distro to the
> > current N distro. Because the features required for our "untypical"
> > environment have appeared somewhere closer to the bleeding-edge...
> >     
>
>
>  Sounds like you want Centos + Extras then. 
No.

EPEL (Extras) is not bleeding-edge (AFAIK its policy).  And often enough 
we need a new version of some non-Extras package (ie. samba, openldap etc.)


~buc

[Matej Cepl]

On 2008-10-10, 14:36 GMT, Dmitry Butskoy wrote:
>  What should do some previously RedHat-oriented enthusiast, when 
>  all the area for application of his enthusiasm is some 
>  "production environment"?  Use RHEL/CentOS anywhere and Fedora 
>  on his laptop only? But RHEL/CentOS is far from the "bleeding 
>  edge", hence his enthusiasm just disappear... 
Think about that and repeat until you get it -- "distro is either 
bleeding-edge or stable; tercium non datur".

Matej

[Dmitry Butskoy]

Matej Cepl wrote:
>  On 2008-10-10, 14:36 GMT, Dmitry Butskoy wrote:
>    
> > What should do some previously RedHat-oriented enthusiast, when 
> > all the area for application of his enthusiasm is some 
> > "production environment"?  Use RHEL/CentOS anywhere and Fedora 
> > on his laptop only? But RHEL/CentOS is far from the "bleeding 
> > edge", hence his enthusiasm just disappear...
> >     
>
>  Think about that and repeat until you get it -- "distro is either 
>  bleeding-edge or stable; tercium non datur".
>     
Kinda black-white mentality?  ;)


~buc

[Matej Cepl]

On 2008-10-10, 15:22 GMT, Dmitry Butskoy wrote:
>  Kinda black-white mentality?  ;) 
I have spent a lot of time with RH Linux, 
Debian/{stable,testing,unstable} and now two years with Fedora -- 
I think I have some idea what I am talking about.

And you know, I know it is not fashionable, it is worthy to 
remember that sometimes there is black and white, and not 
everything is grey (thanks God!).

Matěj

[Patrice Dumas]

On Fri, Oct 10, 2008 at 05:10:29PM +0200, Matej Cepl wrote:
>  On 2008-10-10, 14:36 GMT, Dmitry Butskoy wrote:
>  > What should do some previously RedHat-oriented enthusiast, when 
>  > all the area for application of his enthusiasm is some 
>  > "production environment"?  Use RHEL/CentOS anywhere and Fedora 
>  > on his laptop only? But RHEL/CentOS is far from the "bleeding 
>  > edge", hence his enthusiasm just disappear...
>  
>  Think about that and repeat until you get it -- "distro is either 
>  bleeding-edge or stable; tercium non datur". 
It is a bit more complicated. A distro may begin its life bleeding edge
and become stable as time goes by, if it is still maintained. And a
stable distro may have parts that are bleeding-edge. This is not
necessarily easy to implement, but these scenarios certainly have
merits.

--
Pat

[Les Mikesell]

Patrice Dumas wrote:
>  On Fri, Oct 10, 2008 at 05:10:29PM +0200, Matej Cepl wrote:
> > On 2008-10-10, 14:36 GMT, Dmitry Butskoy wrote:
> >> What should do some previously RedHat-oriented enthusiast, when 
> >> all the area for application of his enthusiasm is some 
> >> "production environment"?  Use RHEL/CentOS anywhere and Fedora 
> >> on his laptop only? But RHEL/CentOS is far from the "bleeding 
> >> edge", hence his enthusiasm just disappear...
> > Think about that and repeat until you get it -- "distro is either 
> > bleeding-edge or stable; tercium non datur".
>  
>  It is a bit more complicated. A distro may begin its life bleeding edge
>  and become stable as time goes by, if it is still maintained. And a
>  stable distro may have parts that are bleeding-edge. This is not
>  necessarily easy to implement, but these scenarios certainly have
>  merits. 
That was the way things worked when redhat developed its popularity.  An 
  X.0 release was approximately as unstable as a fedora, but as it 
updated to X.2 or X.3 it would have become very stable and people who 
started a development cycle with the early versions could keep the same 
OS in production as it matured.  What we need for the same effect now is 
for the versions of fedora that provide the initial RHEL cuts to offer a 
seamless update to the subsequent matching CentOS, repointing to its 
update repositories for continued support.

-- 
   Les Mikesell
     lesmikesell(a)gmail.com

[Kevin Kofler]

Les Mikesell <lesmikesell <at> gmail.com> writes:
>  What we need for the same effect now is for the versions of fedora
> that
>  provide the initial RHEL cuts to offer a seamless update to the subsequent
>  matching CentOS, repointing to its update repositories for continued support. 
I'm afraid that's not possible, because Fedora (even the previous version of 
it!) keeps getting version updates after RHEL gets branched and RHEL doesn't 
get most of them, so even the upgrade path from Fedora n-1 to a RHEL based on 
Fedora n can't be guaranteed, not even at the very moment RHEL gets released, 
and thus not at any point in time.

The development branch for RHEL would have to be opened up (and EPEL maintained 
against it, too) for a proposal like yours to work, and I don't think Red Hat 
is prepared to do that; additionally, you'd also have to hop off Fedora to 
there exactly at the right point in time, because Fedora would continue getting 
updates, not all of which will end up in RHEL.

        Kevin Kofler

[Les Mikesell]

Kevin Kofler wrote:
>  Les Mikesell <lesmikesell <at> gmail.com> writes:
> > What we need for the same effect now is for the versions of fedora that
> > provide the initial RHEL cuts to offer a seamless update to the subsequent
> > matching CentOS, repointing to its update repositories for continued support.
>  
>  I'm afraid that's not possible, because Fedora (even the previous version of 
>  it!) keeps getting version updates after RHEL gets branched and RHEL doesn't 
>  get most of them, so even the upgrade path from Fedora n-1 to a RHEL based on 
>  Fedora n can't be guaranteed, not even at the very moment RHEL gets released, 
>  and thus not at any point in time.
>  
>  The development branch for RHEL would have to be opened up (and EPEL maintained 
>  against it, too) for a proposal like yours to work, and I don't think Red Hat 
>  is prepared to do that; additionally, you'd also have to hop off Fedora to 
>  there exactly at the right point in time, because Fedora would continue getting 
>  updates, not all of which will end up in RHEL. 
I know it doesn't work that way now - hence the complaints.

Fedora could make it's next release somewhere around the point where the 
paths start to diverge so people who wanted the fast-track unstable 
flavor could re-install as they apparently love to do, and the rest of 
us could just drift into stability.

-- 
    Les Mikesell
     lesmikesell(a)gmail.com

[Horst H. von Brand]

Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:

[...]

>  Fedora could make it's next release somewhere around the point
> where
>  the paths start to diverge so people who wanted the fast-track
>  unstable flavor could re-install as they apparently love to do, and
>  the rest of us could just drift into stability. 
Why would any Fedoran want to "drift into stability"? That is a
contradiction in terms... If it was /so/ badly wanted as you claim, Fedora
Legacy would be alive and well, don't you think?
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

[Patrice Dumas]

On Sun, Oct 12, 2008 at 07:40:59PM -0300, Horst H. von Brand wrote:
>  Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:
>  
>  [...]
>  
>  > Fedora could make it's next release somewhere around the point where
>  > the paths start to diverge so people who wanted the fast-track
>  > unstable flavor could re-install as they apparently love to do, and
>  > the rest of us could just drift into stability.
>  
>  Why would any Fedoran want to "drift into stability"? That is a
>  contradiction in terms... If it was /so/ badly wanted as you claim, Fedora
>  Legacy would be alive and well, don't you think? 
Things have changed since Fedora Legacy. Core has opened and 
infrastructure has seen many improvements. What was not practical in the
old days is, in my opinion, possible now.

--
Pat

[Les Mikesell]

Horst H. von Brand wrote:
>  Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:
>  
>  [...]
>  
> > Fedora could make it's next release somewhere around the point where
> > the paths start to diverge so people who wanted the fast-track
> > unstable flavor could re-install as they apparently love to do, and
> > the rest of us could just drift into stability.
>  
>  Why would any Fedoran want to "drift into stability"? That is a
>  contradiction in terms... If it was /so/ badly wanted as you claim, Fedora
>  Legacy would be alive and well, don't you think? 
No, Fedora, legacy or not, is not good at maintaining stability. I'm not 
surprised it didn't work and wouldn't expect it to work if revived. 
What people actually do is run RHEL or Centos for their actual work. 
Which leaves the question of how to get from one to the other as you 
develop something new, then want to run it.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

[Horst H. von Brand]

Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:
>  Horst H. von Brand wrote:
>  > Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:
>  > [...]
>  >
>  >> Fedora could make it's next release somewhere around the point where
>  >> the paths start to diverge so people who wanted the fast-track
>  >> unstable flavor could re-install as they apparently love to do, and
>  >> the rest of us could just drift into stability.
>  > Why would any Fedoran want to "drift into stability"? That is a
>  > contradiction in terms... If it was /so/ badly wanted as you claim, Fedora
>  > Legacy would be alive and well, don't you think? 
>  No, Fedora, legacy or not, is not good at maintaining stability.
> I'm
>  not surprised it didn't work and wouldn't expect it to work if
>  revived. 
My impression too, but experimental data trumps that.

>           What people actually do is run RHEL or Centos for their
>  actual work. 
Depends on what "actual work" means...

>               Which leaves the question of how to get from one to the
>  other as you develop something new, then want to run it. 
Move the SRPM over, rebuild on the target? Have done so several times, with
minimal fuss. Also moved SRPMs to Aurora (on SPARC64, Fedora-based), and
even ported SRPMs for stuff I couldn't find on Fedora from a variety of
other distributions. I also maintained locally old packages for stuff where
the newer one didn't work.

I'd expect anybody who used Red Hat/CentOS/Fedora for any length of time
have done so too...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

[Les Mikesell]

Horst H. von Brand wrote:
> > No, Fedora, legacy or not, is not good at maintaining stability. I'm
> > not surprised it didn't work and wouldn't expect it to work if
> > revived.
>  
>  My impression too, but experimental data trumps that. 
Do you have numbers for the bugs shipped in Fedora?  Even the ones fixed 
in subsequent updates?  I've had too many update kernels that wouldn't 
boot on hardware where the previous one ran fine.

> >          What people actually do is run RHEL or Centos for their
> > actual work.
>  
>  Depends on what "actual work" means... 
My experience is with things like http://www.quote.com or 
http://www.futuresource.com and their backend systems handling financial 
data, but I mean anything that is expected to be up 24x7 for years.

> >              Which leaves the question of how to get from one to
> the
> > other as you develop something new, then want to run it.
>  
>  Move the SRPM over, rebuild on the target? Have done so several times, with
>  minimal fuss. Also moved SRPMs to Aurora (on SPARC64, Fedora-based), and
>  even ported SRPMs for stuff I couldn't find on Fedora from a variety of
>  other distributions. I also maintained locally old packages for stuff where
>  the newer one didn't work.
>  
>  I'd expect anybody who used Red Hat/CentOS/Fedora for any length of time
>  have done so too... 
Yes, that sometimes works, but if it is as easy as you say, why not just 
do that with _everything_ on Fedora as its last update when the 
corresponding enterprise version has been released?

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

[Emmanuel Seyman]

* Les Mikesell [10/10/2008 19:45] :
>                                   What we need for the same effect now is  
>  for the versions of fedora that provide the initial RHEL cuts to offer a  
>  seamless update to the subsequent matching CentOS, repointing to its  
>  update repositories for continued support. 
I'ld expect migration guides and packages from Fedora to $DISTRIBUTION
to be written by the $DISTRIBUTION community, not Fedora's.

Emmanuel

[Les Mikesell]

Emmanuel Seyman wrote:
>  * Les Mikesell [10/10/2008 19:45] :
> >                                  What we need for the same effect now is  
> > for the versions of fedora that provide the initial RHEL cuts to offer a  
> > seamless update to the subsequent matching CentOS, repointing to its  
> > update repositories for continued support.
>  
>  I'ld expect migration guides and packages from Fedora to $DISTRIBUTION
>  to be written by the $DISTRIBUTION community, not Fedora's. 
Why, when Fedora is the one stopping support for the users that adapted 
to a particular Fedora version?  I'm suggestion this migration as a 
substitute for the  ongoing support that is lacking.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

[Emmanuel Seyman]

* Les Mikesell [13/10/2008 09:57] :
>  Why, when Fedora is the one stopping support for the users that adapted  
>  to a particular Fedora version?  I'm suggestion this migration as a  
>  substitute for the  ongoing support that is lacking. 
We do not stop support.
At any one time, two versions of Fedora are maintained.

Emmanuel

[Les Mikesell]

Emmanuel Seyman wrote:
>  * Les Mikesell [13/10/2008 09:57] :
> > Why, when Fedora is the one stopping support for the users that adapted  
> > to a particular Fedora version?  I'm suggestion this migration as a  
> > substitute for the  ongoing support that is lacking.
>  
>  We do not stop support.
>  At any one time, two versions of Fedora are maintained. 
How does that amount to not stopping support for a particular version?

The supported versions may be wildly different at any time and the next 
version may not be suitable for what you want to keep running.  For a 
simple example, what would you have done if your production environment 
involved packages from the jpackage repository through the time that the 
changes in fedora made it incompatible?

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

[Emmanuel Seyman]

* Les Mikesell [13/10/2008 15:31] :
>  The supported versions may be wildly different at any time and the next  
>  version may not be suitable for what you want to keep running. 
Sounds like you should be using a distribution that offers a longer
support time than the Fedora offers.

Emmanuel

[Patrice Dumas]

On Mon, Oct 13, 2008 at 03:38:03PM +0200, Emmanuel Seyman wrote:
>  * Les Mikesell [13/10/2008 15:31] :
>  >
>  > The supported versions may be wildly different at any time and the next  
>  > version may not be suitable for what you want to keep running.
>  
>  Sounds like you should be using a distribution that offers a longer
>  support time than the Fedora offers. 
Sounds like you don't want fedora packagers to volunteer for a longer 
(support) time in fedora (not necessarily under the fedora name but in 
the fedora infrastructure).

--
Pat

[Emmanuel Seyman]

* Patrice Dumas [13/10/2008 15:52] :
>  Sounds like you don't want fedora packagers to volunteer for a longer 
>  (support) time in fedora (not necessarily under the fedora name but in 
>  the fedora infrastructure). 
Oh, I don't mind that Fedora packagers start an LTS project.

I do get annoyed that they keep claiming that Fedora infrastructure is
necessary when, in fact, it isn't and I find it surprising that they
keep coming up with excuse after excuse for not actually doing anything
instead of just starting their project.

You're free to work on whatever project you want. If the board feels it
isn't appropriate for you to work under the Fedora brand, you can just
do it somewhere else. They, like I, lack the magic powers necessary to
stop you from doing whatever you feel like doing.

Emmanuel

[Horst H. von Brand]

Patrice Dumas <pertusus(a)free.fr&gt; wrote:
>  On Mon, Oct 13, 2008 at 03:38:03PM +0200, Emmanuel Seyman wrote:
>  > * Les Mikesell [13/10/2008 15:31] :
>  > >
>  > > The supported versions may be wildly different at any time and the next  
>  > > version may not be suitable for what you want to keep running.
>  > 
>  > Sounds like you should be using a distribution that offers a longer
>  > support time than the Fedora offers. 
>  Sounds like you don't want fedora packagers to volunteer for a
> longer 
>  (support) time in fedora (not necessarily under the fedora name but in 
>  the fedora infrastructure). 
Show me the developers who are _commited_ on making it happen, then we can
talk. The infrastructure is in place.

Fedora Legacy foundered because everybody said they wanted it, almost
nobody was willing to do the (hard!) work, and in the end the "many users"
didn't materialize either.

[No, I'm not talking in any official Fedora position, but I think the above
 sort of sums it up.]
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

[Patrice Dumas]

On Tue, Oct 14, 2008 at 10:46:40AM -0300, Horst H. von Brand wrote:
>  
>  Show me the developers who are _commited_ on making it happen, then we can
>  talk. The infrastructure is in place. 
I am, and a few others. But the infrastructure is still not in place. I
mean it may be physically, but there hasn't been an agreement from
fedora leadership. But I'll propose something for th enext FESCo, we'll
see how it turns out.

>  Fedora Legacy foundered because everybody said they wanted it,
> almost
>  nobody was willing to do the (hard!) work, and in the end the "many users"
>  didn't materialize either. 
The work in the scope of this project will be less hard than what was
done in the scope of legacy, since there will be less QA, in fact the
same amount than in fedora.

I wanted to help fedora legacy, and I wasn't deterred by the packaging
work, but by the amount of QA compared with fedora extras, the processes
were much more complicated for me. I think that the quality was higher, 
too. I don't think that we need that quality right now. Legacy continued 
the Red Hat releases that were quite stable. Here the aim is to continue
fedora release that are very unstable. The aim is to try to be as stable
as possible, but with the same processes than in fedora.

--
Pat

[Josh Boyer]

On Tue, Oct 14, 2008 at 04:56:50PM +0200, Patrice Dumas wrote:
> On Tue, Oct 14, 2008 at 10:46:40AM -0300, Horst H. von Brand wrote:
> > 
> > Show me the developers who are _commited_ on making it happen, then we can
> > talk. The infrastructure is in place.
>
> I am, and a few others. But the infrastructure is still not in place. I
> mean it may be physically, but there hasn't been an agreement from
> fedora leadership. But I'll propose something for th enext FESCo, we'll
> see how it turns out. 
As a suggestion, create your proposal focusing around opening the ACLs
on the older package branches, and keeping the build infrastructure in
place for them.  Don't mention "LTS" and take baby steps.

FESCo will likely ask for input from Infrastructure and Rel-Eng as well,
given that Rel-Eng would be required to push updates, and Infrastructure
will have to allocate storage for this.  Getting the conversation
started with those groups now would be advised.  Infrastructure has been
moving EOL releases to archives, so other changes would be needed to
point repos to the right locations would be needed also.

josh

[Patrice Dumas]

On Tue, Oct 14, 2008 at 11:06:32AM -0400, Josh Boyer wrote:
>  
>  As a suggestion, create your proposal focusing around opening the ACLs
>  on the older package branches, and keeping the build infrastructure in
>  place for them.  Don't mention "LTS" and take baby steps. 
Agreed.

>  FESCo will likely ask for input from Infrastructure and Rel-Eng as
> well,
>  given that Rel-Eng would be required to push updates, and Infrastructure
>  will have to allocate storage for this.  Getting the conversation
>  started with those groups now would be advised.  Infrastructure has been
>  moving EOL releases to archives, so other changes would be needed to
>  point repos to the right locations would be needed also. 
Yes. I have begun to read in the wiki how to contact infrastructure
people and things like that, I will certainly begin asking questions on
the relevant mailing lists soon.

--
Pat

[Horst H. von Brand]

Patrice Dumas <pertusus(a)free.fr&gt; wrote:
>  On Tue, Oct 14, 2008 at 10:46:40AM -0300, Horst H. von Brand wrote:
[...]

>  > Fedora Legacy foundered because everybody said they wanted it,
> almost
>  > nobody was willing to do the (hard!) work, and in the end the "many
> users"
>  > didn't materialize either. 
>  The work in the scope of this project will be less hard than what
> was
>  done in the scope of legacy, 
I just can't imagine why it would be less; if anything, much more (there
are more packages today, and the "basic stuff that must work" is getting
more and more).

>                               since there will be less QA, in fact
> the
>  same amount than in fedora. 
Right. And everybody complaints that Fedora isn't doing enough here, and
discussions on how to make it work better are common...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

[Patrice Dumas]

On Wed, Oct 15, 2008 at 04:29:07PM -0300, Horst H. von Brand wrote:
>  Patrice Dumas <pertusus(a)free.fr&gt; wrote:
>  > On Tue, Oct 14, 2008 at 10:46:40AM -0300, Horst H. von Brand wrote:
>  
>  > The work in the scope of this project will be less hard than what was
>  > done in the scope of legacy,
>  
>  I just can't imagine why it would be less; if anything, much more (there
>  are more packages today, and the "basic stuff that must work" is getting
>  more and more). 
Maybe on the packaging side, that is more packages to maintain (the
minimal target being @code + @base in my opinion, but this can be
discussed), but less on the QA and process side. Moreover now that core
is opened it means that contributors may be more involved in core
packages and may have done merge reviews (at least it is my case) 
while for legacy people started with packages they had no
reason to know.

>  >                              since there will be less QA, in
> fact the
>  > same amount than in fedora.
>  
>  Right. And everybody complaints that Fedora isn't doing enough here, and
>  discussions on how to make it work better are common... 
We'll follow. But I don't think that fedora will ever get near what had
to be done in legacy.

--
Pat

[Horst H. von Brand]

Patrice Dumas <pertusus(a)free.fr&gt; wrote:
>  On Wed, Oct 15, 2008 at 04:29:07PM -0300, Horst H. von Brand wrote:
>  > Patrice Dumas <pertusus(a)free.fr&gt; wrote:
>  > > On Tue, Oct 14, 2008 at 10:46:40AM -0300, Horst H. von Brand wrote: 
>  > > The work in the scope of this project will be less hard
> than what was
>  > > done in the scope of legacy, 
>  > I just can't imagine why it would be less; if anything, much
> more (there
>  > are more packages today, and the "basic stuff that must work" is getting
>  > more and more). 
>  Maybe on the packaging side, that is more packages to maintain (the
>  minimal target being @code + @base in my opinion, but this can be
>  discussed), but less on the QA and process side. Moreover now that core
>  is opened it means that contributors may be more involved in core
>  packages and may have done merge reviews (at least it is my case) 
>  while for legacy people started with packages they had no
>  reason to know. 
If all that is "maintained" is a skeleton system, that won't do much good
(how often was a /@core/ or /@base/ packages that can't be upgraded the
cause of not moving to the next Fedora?)
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

[Patrice Dumas]

On Wed, Oct 15, 2008 at 08:30:34PM -0300, Horst H. von Brand wrote:
>  
>  If all that is "maintained" is a skeleton system, that won't do much good
>  (how often was a /@core/ or /@base/ packages that can't be upgraded the
>  cause of not moving to the next Fedora?) 
This is not the goal. Hopefully there will be much more maintained
packages (and given that some people seem to be interested and they
maintain or co-maintain a large number of packages) but this is to
define a minimal set of packages that are mandatorily actively 
maintained.

--
Pat

[Matej Cepl]

On 2008-10-10, 15:49 GMT, Les Mikesell wrote:
>  What we need for the same effect now is for the versions of 
>  fedora that provide the initial RHEL cuts to offer a seamless 
>  update to the subsequent matching CentOS, repointing to its 
>  update repositories for continued support. 
How is it different from just using CentOS?

Matěj

[Les Mikesell]

Matej Cepl wrote:
>  On 2008-10-10, 15:49 GMT, Les Mikesell wrote:
> > What we need for the same effect now is for the versions of 
> > fedora that provide the initial RHEL cuts to offer a seamless 
> > update to the subsequent matching CentOS, repointing to its 
> > update repositories for continued support.
>  
>  How is it different from just using CentOS? 
There's no lead time for your own local development and testing.  You 
would never expect one of the old RH X.0 releases to be production-ready 
but the new releases would have new kernels, libraries, and utilities so 
you could incorporate their features in your own work, which was likely 
to proceed at approximately the same rate as the distro evolved toward 
stability.  With Centos you don't get anything to work with and test 
ahead of time, and if you'd tested on an earlier Fedora there may or may 
not be any relationship.  A side effect was that the community of RH 
users that reported/fixed bugs in the X.0 got something for their effort 
in being able to continue using the updated release instead of being 
abandoned as a wildly new X.0 came out.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

[Jesse Keating]

On Sat, 2008-10-11 at 04:06 -0500, Les Mikesell wrote:
>  
>  There's no lead time for your own local development and testing.  You 
>  would never expect one of the old RH X.0 releases to be production-ready 
>  but the new releases would have new kernels, libraries, and utilities so 
>  you could incorporate their features in your own work, which was likely 
>  to proceed at approximately the same rate as the distro evolved toward 
>  stability.  With Centos you don't get anything to work with and test 
>  ahead of time, and if you'd tested on an earlier Fedora there may or may 
>  not be any relationship.  A side effect was that the community of RH 
>  users that reported/fixed bugs in the X.0 got something for their effort 
>  in being able to continue using the updated release instead of being 
>  abandoned as a wildly new X.0 came out. 
CentOS should be putting out betas that match the RHEL betas so that you
can get access to it before the release.  Use Fedora as the technology
driver, use Betas as the bugfix cleanup for platform issues, and
eventually you get the "Enterprise" release.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Stephen John Smoogen]

2008/10/11 Jesse Keating <jkeating(a)redhat.com&gt;:
>  On Sat, 2008-10-11 at 04:06 -0500, Les Mikesell wrote:
> >
> > There's no lead time for your own local development and testing.  You
> > would never expect one of the old RH X.0 releases to be production-ready
> > but the new releases would have new kernels, libraries, and utilities so
> > you could incorporate their features in your own work, which was likely
> > to proceed at approximately the same rate as the distro evolved toward
> > stability.  With Centos you don't get anything to work with and test
> > ahead of time, and if you'd tested on an earlier Fedora there may or may
> > not be any relationship.  A side effect was that the community of RH
> > users that reported/fixed bugs in the X.0 got something for their effort
> > in being able to continue using the updated release instead of being
> > abandoned as a wildly new X.0 came out.
>
>  CentOS should be putting out betas that match the RHEL betas so that you
>  can get access to it before the release.  Use Fedora as the technology
>  driver, use Betas as the bugfix cleanup for platform issues, and
>  eventually you get the "Enterprise" release.
>  
I think the major problem with CentOS putting out beta's in a timely
basis is that a large amount of time is getting the build resources
together AND then deciphering various build variables that RHEL uses
so that the CentOS binaries 'match' close enough to be bug for bug
compatible. The time to do that basically had a CentOS-5beta out at
the time that RHEL-5 is finalized.





-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

[Luya Tshimbalanga]

Comment,
Wikipedia - Goodbye Red Hat and Fedora -> At least it is not a farewell

Moving to Ubuntu LTS  might not be helpful at long term. The big issue is Ubuntu
LTS was created by Canonical for making money as aiming by Mark Shuttleworth
himself. Canonical as company is not profitable yet since its inception. It
appears more a publicity stunt rather than technical issue because CentOS fill
the gap between Red Hat and Fedora. My main corner is how much Canonical is
giving back to the community, most of time, they try to credit themselves on
something they improve from others.

This is only my opinion which does not necessarily represents the whole
community view.

-- 
Luya Tshimbalanga
Fedora Project contributor
http://www.fedoraproject.org/wiki/LuyaTshimbalanga

[Ralph angenendt]

Stephen John Smoogen wrote:
>  2008/10/11 Jesse Keating <jkeating(a)redhat.com&gt;:
> > CentOS should be putting out betas that match the RHEL betas so that you
> > can get access to it before the release.  Use Fedora as the technology
> > driver, use Betas as the bugfix cleanup for platform issues, and
> > eventually you get the "Enterprise" release.
>  
>  I think the major problem with CentOS putting out beta's in a timely
>  basis is that a large amount of time is getting the build resources
>  together AND then deciphering various build variables that RHEL uses
>  so that the CentOS binaries 'match' close enough to be bug for bug
>  compatible. The time to do that basically had a CentOS-5beta out at
>  the time that RHEL-5 is finalized. 
Not having publicly available SRPMs for the beta versions (meaning 
available via public ftp) might be another reason. 

Ralph

[Stephen John Smoogen]

2008/10/11 Ralph Angenendt <ralph+fedora(a)strg-alt-entf.org&gt;:
>  Stephen John Smoogen wrote:
> > 2008/10/11 Jesse Keating <jkeating(a)redhat.com&gt;:
> >> CentOS should be putting out betas that match the RHEL betas so that you
> >> can get access to it before the release.  Use Fedora as the technology
> >> driver, use Betas as the bugfix cleanup for platform issues, and
> >> eventually you get the "Enterprise" release.
> >
> > I think the major problem with CentOS putting out beta's in a timely
> > basis is that a large amount of time is getting the build resources
> > together AND then deciphering various build variables that RHEL uses
> > so that the CentOS binaries 'match' close enough to be bug for bug
> > compatible. The time to do that basically had a CentOS-5beta out at
> > the time that RHEL-5 is finalized.
>
>  Not having publicly available SRPMs for the beta versions (meaning
>  available via public ftp) might be another reason. 
I thought the SRPMS were available, as Scientific Linux uses the
public ones to build their Betas.

I thought it was more a level of priority. CentOS is a volunteer
project with a lot of costs shouldered by the developers. There is
usually a shortage of diskspace, slow net links to various build
machines spread around the world, the fact that various devs have full
time jobs (there is no full-time build manager like Fedora and SciLin
have), and various other items. Any of which puts making betas a lower
priority than dealing with current issues.

-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

[Arthur Pemberton]

On Sat, Oct 11, 2008 at 3:40 PM, Stephen John Smoogen <smooge(a)gmail.com&gt; wrote:
>  2008/10/11 Ralph Angenendt <ralph+fedora(a)strg-alt-entf.org&gt;:
> > Stephen John Smoogen wrote:
> >> 2008/10/11 Jesse Keating <jkeating(a)redhat.com&gt;:
> >>> CentOS should be putting out betas that match the RHEL betas so that you
> >>> can get access to it before the release.  Use Fedora as the technology
> >>> driver, use Betas as the bugfix cleanup for platform issues, and
> >>> eventually you get the "Enterprise" release.
> >>
> >> I think the major problem with CentOS putting out beta's in a timely
> >> basis is that a large amount of time is getting the build resources
> >> together AND then deciphering various build variables that RHEL uses
> >> so that the CentOS binaries 'match' close enough to be bug for bug
> >> compatible. The time to do that basically had a CentOS-5beta out at
> >> the time that RHEL-5 is finalized.
> >
> > Not having publicly available SRPMs for the beta versions (meaning
> > available via public ftp) might be another reason.
>
>  I thought the SRPMS were available, as Scientific Linux uses the
>  public ones to build their Betas.
>
>  I thought it was more a level of priority. CentOS is a volunteer
>  project with a lot of costs shouldered by the developers. There is
>  usually a shortage of diskspace, slow net links to various build
>  machines spread around the world, the fact that various devs have full
>  time jobs (there is no full-time build manager like Fedora and SciLin
>  have), and various other items. Any of which puts making betas a lower
>  priority than dealing with current issues. 

For those who can and may have not noticed the link before:
http://www.centos.org/modules/tinycontent/index.php?id=23


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )

[Ralph angenendt]

Stephen John Smoogen wrote:
>  2008/10/11 Ralph Angenendt <ralph+fedora(a)strg-alt-entf.org&gt;:
>  > Not having publicly available SRPMs for the beta versions (meaning
>  > available via public ftp) might be another reason.
>  
>  I thought the SRPMS were available, as Scientific Linux uses the
>  public ones to build their Betas. 
Scientific builds Betas from the *released* version, not from the RHEL beta
versions. So maybe we should come to terms with "what does Beta mean" ...

>  I thought it was more a level of priority. CentOS is a volunteer
>  project with a lot of costs shouldered by the developers. There is
>  usually a shortage of diskspace, slow net links to various build
>  machines spread around the world, the fact that various devs have full
>  time jobs (there is no full-time build manager like Fedora and SciLin
>  have), and various other items. Any of which puts making betas a lower
>  priority than dealing with current issues. 
Sure, that also comes into play.

Ralph

[Stephen John Smoogen]

2008/10/11 Ralph Angenendt <ralph+fedora(a)strg-alt-entf.org&gt;:
>  Stephen John Smoogen wrote:
> > 2008/10/11 Ralph Angenendt <ralph+fedora(a)strg-alt-entf.org&gt;:
> > > Not having publicly available SRPMs for the beta versions (meaning
> > > available via public ftp) might be another reason.
> >
> > I thought the SRPMS were available, as Scientific Linux uses the
> > public ones to build their Betas.
>
>  Scientific builds Betas from the *released* version, not from the RHEL beta
>  versions. So maybe we should come to terms with "what does Beta mean" ...
>  
My mistake.. reading through some of the alpha release notes from
SciLin4 that I was looking at indicated it was compiled from the beta.



-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

[Stephen John Smoogen]

2008/10/11 Jesse Keating <jkeating(a)redhat.com&gt;:
>  On Sat, 2008-10-11 at 04:06 -0500, Les Mikesell wrote:
> >
> > There's no lead time for your own local development and testing.  You
> > would never expect one of the old RH X.0 releases to be production-ready
> > but the new releases would have new kernels, libraries, and utilities so
> > you could incorporate their features in your own work, which was likely
> > to proceed at approximately the same rate as the distro evolved toward
> > stability.  With Centos you don't get anything to work with and test
> > ahead of time, and if you'd tested on an earlier Fedora there may or may
> > not be any relationship.  A side effect was that the community of RH
> > users that reported/fixed bugs in the X.0 got something for their effort
> > in being able to continue using the updated release instead of being
> > abandoned as a wildly new X.0 came out.
>
>  CentOS should be putting out betas that match the RHEL betas so that you
>  can get access to it before the release.  Use Fedora as the technology
>  driver, use Betas as the bugfix cleanup for platform issues, and
>  eventually you get the "Enterprise" release.
>  
I was wrong about why CentOS has not done Beta's in the past. So what
can be done about getting the src.rpms for the next set of beta's
(4.8/5.3) on the ftp servers when they are ready to be previewed?



-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

[Horst H. von Brand]

Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:
>  Patrice Dumas wrote: 
[...]

>  > It is a bit more complicated. A distro may begin its life
> bleeding
>  > edge and become stable as time goes by, if it is still maintained. And
>  > a stable distro may have parts that are bleeding-edge. This is not
>  > necessarily easy to implement, but these scenarios certainly have
>  > merits. 
I don't see any... Sure, it might be nice for the (tiny minority) who wants
e.g. bleeding edge compiler (because they are hacking on it?) with a very
stable everything else.

>  That was the way things worked when redhat developed its popularity.

No...

>  An X.0 release was approximately as unstable as a fedora, 
Not really.

>                                                            but as it
>  updated to X.2 or X.3 it would have become very stable and people who
>  started a development cycle with the early versions could keep the
>  same OS in production as it matured. 
But there was no guarantee whatsoever of a .1, a .2 or even a .3 would ever
materialize.

>                                       What we need 
Who is the "we" here?

>                                                    for the same
> effect
>  now is for the versions of fedora that provide the initial RHEL cuts
>  to offer a seamless update to the subsequent matching CentOS,
>  repointing to its update repositories for continued support. 
If a majority of Fedora folks wanted that, Fedora would move like
that. Fedora Legacy wouldn't have gone belly up for lack of hands. And Red
Hat would have gone on doing .0, .1 and so on forever.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

[Stephen John Smoogen]

On Fri, Oct 10, 2008 at 9:35 AM, Patrice Dumas <pertusus(a)free.fr&gt; wrote:
>  On Fri, Oct 10, 2008 at 05:10:29PM +0200, Matej Cepl wrote:
> > On 2008-10-10, 14:36 GMT, Dmitry Butskoy wrote:
> > > What should do some previously RedHat-oriented enthusiast, when
> > > all the area for application of his enthusiasm is some
> > > "production environment"?  Use RHEL/CentOS anywhere and Fedora
> > > on his laptop only? But RHEL/CentOS is far from the "bleeding
> > > edge", hence his enthusiasm just disappear...
> >
> > Think about that and repeat until you get it -- "distro is either
> > bleeding-edge or stable; tercium non datur".
>
>  It is a bit more complicated. A distro may begin its life bleeding edge
>  and become stable as time goes by, if it is still maintained. And a
>  stable distro may have parts that are bleeding-edge. This is not
>  necessarily easy to implement, but these scenarios certainly have
>  merits.
>  
It can only become stable if you have people focus on things and not
look at new stuff. And usually it requires resources that are
expensive.



-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

[Patrice Dumas]

On Fri, Oct 10, 2008 at 04:11:12PM +0200, Matej Cepl wrote:
>  On 2008-10-10, 12:53 GMT, Itamar - IspBrasil wrote:
>  > In my opinion fedora is losing space from centos and ubuntu
>  
>  b) If anybody is running production servers on Fedora, then worse 
>     for him -- Fedora is a developers' distro and that's the 
>     reason why it has limited support. If you think you want to 
>     revive Fedora Legacy project (which died for disinterest of 
>     its users), then I would suggest that you join CentOS -- I am 
>     quite certain they can use as many people helping as possible. 
Fedora legacy (or fedora lts) would not be the same than centos. Maybe a
Centos + repository with more recent stuff would be, but currently I
think that there is something in the middle between fedora and centos
that is missing. Now it may very well be possible that there is not
enough interested users to make that distro, but there is also a lack of
support from the boards. Some months ago I proposed something for a
fedora lts that was brought down, maybe for good reasons, but the tone
of the discussions really showed very few support, and I'd even say some
antagonism.

--
Pat

[Emmanuel Seyman]

* Patrice Dumas [10/10/2008 17:39] :
>                   Now it may very well be possible that there is not
>  enough interested users to make that distro, but there is also a lack of
>  support from the boards. 
You don't actually need support from the boards to do something.

If you believe something is worth doing, start it outside the Fedora
project and see if it catches on. If it does, you can consider making
a pitch to the board to bring it under the Fedora umbrella.

ISn't this how the KDE SIG got started ?

Emmanuel

[Patrice Dumas]

On Fri, Oct 10, 2008 at 06:09:23PM +0200, Emmanuel Seyman wrote:
>  * Patrice Dumas [10/10/2008 17:39] :
>  >
>  >                  Now it may very well be possible that there is not
>  > enough interested users to make that distro, but there is also a lack of
>  > support from the boards.
>  
>  You don't actually need support from the boards to do something. 
When it requires cooperation with the infrastructure, it does. It is
also possible to start something external like rpmfusion, but the amount
of work is very big. My proposal only made sense if the economies of
scale realized by working inside the fedora project were realized.

Still, if somebody provides the infrastructure, sure I'll try to help
with a project similar than the one I proposed, but I cannot myself do
anything for the infrastructure part.

--
Pat

[Kevin Kofler]

Patrice Dumas <pertusus <at> free.fr> writes:
>  Still, if somebody provides the infrastructure, sure I'll try to
> help
>  with a project similar than the one I proposed, but I cannot myself do
>  anything for the infrastructure part. 
All those "we want KDE 3" whiners should be providing the infrastructure for 
prolungating Fedora 8 support, they could make it happen. But something tells 
me they won't...

        Kevin Kofler

[Emmanuel Seyman]

* Patrice Dumas [10/10/2008 19:45] :
>  When it requires cooperation with the infrastructure, it does. 
How so ?

Reading through the archives, your project was to extend support
for Fedora releases past EOL on a volunteer basis. That doesn't
require cooperation from the Fedora Powers That Be, nor does it
require the Fedora infrastructure.

Emmanuel

[Patrice Dumas]

On Fri, Oct 10, 2008 at 11:44:38PM +0200, Emmanuel Seyman wrote:
>  * Patrice Dumas [10/10/2008 19:45] :
>  >
>  > When it requires cooperation with the infrastructure, it does.
>  
>  How so ?
>  
>  Reading through the archives, your project was to extend support
>  for Fedora releases past EOL on a volunteer basis. That doesn't 
But within the fedora infrastructure, and with the fedora rules (unlike 
fedora legacy that had different infrastructure and rules).

If I had my own infrastructure, I would still be maintaining some
packages for oldest releases.

As a side note, I think that in the end my project would certainly have
failed because I don't think that somebody would have stepped up to take
the big ones, like glibc, kernel, gcc but this would have been an
interesting test.

--
Pat

[Emmanuel Seyman]

* Patrice Dumas [11/10/2008 00:59] :
>  But within the fedora infrastructure, and with the fedora rules (unlike 
>  fedora legacy that had different infrastructure and rules). 
What's so important about the fedora infrastructure that it is required
to release updates past EOL ? The rules I can understand (even if I don't
agree) but those can be replicated elsewhere.

>  As a side note, I think that in the end my project would certainly
> have
>  failed because I don't think that somebody would have stepped up to take
>  the big ones, like glibc, kernel, gcc but this would have been an
>  interesting test. 
But why didn't you try ?
Your proposal sounded like a good idea (although I think you're right
that not enough people are interested in it for it to be viable) and
I think it's a shame that you didn't go ahead and implement it.

Emmanuel

[Patrice Dumas]

On Sat, Oct 11, 2008 at 01:38:42AM +0200, Emmanuel Seyman wrote:
>  * Patrice Dumas [11/10/2008 00:59] :
>  >
>  > But within the fedora infrastructure, and with the fedora rules (unlike 
>  > fedora legacy that had different infrastructure and rules).
>  
>  What's so important about the fedora infrastructure that it is required
>  to release updates past EOL ? The rules I can understand (even if I don't
>  agree) but those can be replicated elsewhere.
>  
>  But why didn't you try ? 
It requires hardware and some admins to have a build system. I don't
have the time, nor the computers.

>  Your proposal sounded like a good idea (although I think you're
> right
>  that not enough people are interested in it for it to be viable) and
>  I think it's a shame that you didn't go ahead and implement it. 
I cannot do that on my own. I am a packager and I know next to nothing
about how to set up a buildsystem. It took quite a long time for
rpmfusion to do that I don't have that time (nor the hardware).

--
Pat

[Till Maas]

On Fri October 10 2008, Patrice Dumas wrote:

>  support from the boards. Some months ago I proposed something for a
>  fedora lts that was brought down, maybe for good reasons, but the tone
>  of the discussions really showed very few support, and I'd even say some
>  antagonism. 
Iirc you would get support in terms of infrastructure in case you have a clear 
proposal and enough people doing the work. Also they should show, that they 
are really interested in doing this for long enough, that it does not look 
like a failed project. E.g. starting now a Fedora LTS project and ending it 
next year, because there are not enough maintainers/people interested in 
doing the work, does not look good for Fedora.

If you think you have enough people, then maybe create a list of them and show 
how they will maintain the packages for the LTS. E.g. they could be already 
(co)maintainers of the current Fedora packages and do work within Fedora 
Infrastructure, Security Response Team and Release Engineering, Translations 
and all the other teams that are needed to compose a distribution. But you 
cannot expect much support from people who do not have a big enough interest 
in this project and spend time on it, that they could spend on improving the 
parts of Fedora, they are interested in.

Regards,
Till

[Patrice Dumas]

On Sat, Oct 11, 2008 at 04:58:43PM +0200, Till Maas wrote:
>  On Fri October 10 2008, Patrice Dumas wrote:
>  
>  > support from the boards. Some months ago I proposed something for a
>  > fedora lts that was brought down, maybe for good reasons, but the tone
>  > of the discussions really showed very few support, and I'd even say some
>  > antagonism.
>  
>  Iirc you would get support in terms of infrastructure in case you have a clear 
>  proposal and enough people doing the work. Also they should show, that they 
>  are really interested in doing this for long enough, that it does not look 
>  like a failed project. E.g. starting now a Fedora LTS project and ending it 
>  next year, because there are not enough maintainers/people interested in 
>  doing the work, does not look good for Fedora. 
My proposal was clear: start the project when somebody has volunteered
for each of the packages that are in @code and @base (and maybe other
comps groups, I don't remember exactly). And keep a page with the
packages maintained such as not to give wrong expectations.

--
Pat

[Henrique Junior]

Hello, everyone,
I would like to share with you an situation related to Fedora's time
of life that comes to me in recent days.
I was recently promoted to Software Manager in the governmental
partition where I work. Next year we've plans to migrate 500 Linux
desktop stations and, in the last month, finished the migration of all
servers to CentOS.
The question that worries me is that, despite the willingness to use
Fedora, dealing with an "end of life" of 13 months can make Fedora
impractical in these 500 desktops. I'll be pressed to use Ubuntu and
even got to think about maintain by myself an repository for
maintaining, maybe, the most important RPMs always updated even if the
Fedora come to the inevitable 13 months of use.
Perhaps it is time to seek volunteers to bring back the Fedora Legacy
and see if more people are interested this time.

Regards from Brazil


2008/10/11 Patrice Dumas <pertusus(a)free.fr&gt;:
>  On Sat, Oct 11, 2008 at 04:58:43PM +0200, Till Maas wrote:
> > On Fri October 10 2008, Patrice Dumas wrote:
> >
> > > support from the boards. Some months ago I proposed something for a
> > > fedora lts that was brought down, maybe for good reasons, but the tone
> > > of the discussions really showed very few support, and I'd even say some
> > > antagonism.
> >
> > Iirc you would get support in terms of infrastructure in case you have a clear
> > proposal and enough people doing the work. Also they should show, that they
> > are really interested in doing this for long enough, that it does not look
> > like a failed project. E.g. starting now a Fedora LTS project and ending it
> > next year, because there are not enough maintainers/people interested in
> > doing the work, does not look good for Fedora.
>
>  My proposal was clear: start the project when somebody has volunteered
>  for each of the packages that are in @code and @base (and maybe other
>  comps groups, I don't remember exactly). And keep a page with the
>  packages maintained such as not to give wrong expectations.
>
>  --
>  Pat
>
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list
>  


-- 
Henrique "LonelySpooky" Junior
http://www.lonelyspooky.com
-------------------------------------------------------------
"In a world without walls and fences, who needs windows and gates?!"

[Arthur Pemberton]

On Sat, Oct 11, 2008 at 4:55 PM, Henrique Junior <henriquecsj(a)gmail.com&gt; wrote:
>  Hello, everyone,
>  I would like to share with you an situation related to Fedora's time
>  of life that comes to me in recent days.
>  I was recently promoted to Software Manager in the governmental
>  partition where I work. Next year we've plans to migrate 500 Linux
>  desktop stations and, in the last month, finished the migration of all
>  servers to CentOS.
>  The question that worries me is that, despite the willingness to use
>  Fedora, dealing with an "end of life" of 13 months can make Fedora
>  impractical in these 500 desktops. I'll be pressed to use Ubuntu and
>  even got to think about maintain by myself an repository for
>  maintaining, maybe, the most important RPMs always updated even if the
>  Fedora come to the inevitable 13 months of use.
>  Perhaps it is time to seek volunteers to bring back the Fedora Legacy
>  and see if more people are interested this time.
>
>  Regards from Brazil 

A few points/questions:
* Does CentOS not meet your desktop needs?
* You should have a local repo for 500 machines anyways. You don't
want untested updates going to your 500 machines
* I don't think you're going to label running your desktops on a
Ubuntu LTS release as a "bad thing"
* As I understand it, Fedora Legacy died out of lack of interest, not
due to some intentional action


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )

[Henrique Junior]

Hi,
As a desktop, Fedora is the best solution. Should I use the best 2nd
solution? (Ubuntu).
Maybe if we take *some* releases to LLT, lets say, Fedora N, Fedora
N+4. The intermediary releases will be "non LLT".... Well, I know that
Fedora have to worry about all releases, but if we have few people to
work it should be one point.
Maybe it looks crazy.

P.S.: I'm sorry for my poor english.


2008/10/11 Arthur Pemberton <pemboa(a)gmail.com&gt;:
>  On Sat, Oct 11, 2008 at 4:55 PM, Henrique Junior
> <henriquecsj(a)gmail.com&gt; wrote:
> > Hello, everyone,
> > I would like to share with you an situation related to Fedora's time
> > of life that comes to me in recent days.
> > I was recently promoted to Software Manager in the governmental
> > partition where I work. Next year we've plans to migrate 500 Linux
> > desktop stations and, in the last month, finished the migration of all
> > servers to CentOS.
> > The question that worries me is that, despite the willingness to use
> > Fedora, dealing with an "end of life" of 13 months can make Fedora
> > impractical in these 500 desktops. I'll be pressed to use Ubuntu and
> > even got to think about maintain by myself an repository for
> > maintaining, maybe, the most important RPMs always updated even if the
> > Fedora come to the inevitable 13 months of use.
> > Perhaps it is time to seek volunteers to bring back the Fedora Legacy
> > and see if more people are interested this time.
> >
> > Regards from Brazil
>
>
>  A few points/questions:
>  * Does CentOS not meet your desktop needs?
>  * You should have a local repo for 500 machines anyways. You don't
>  want untested updates going to your 500 machines
>  * I don't think you're going to label running your desktops on a
>  Ubuntu LTS release as a "bad thing"
>  * As I understand it, Fedora Legacy died out of lack of interest, not
>  due to some intentional action
>
>
>  --
>  Fedora 9 : sulphur is good for the skin
>  ( www.pembo13.com )
>
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list
>  


-- 
Henrique "LonelySpooky" Junior
http://www.lonelyspooky.com
-------------------------------------------------------------
"In a world without walls and fences, who needs windows and gates?!"

[Robert Locke]

On Sat, 2008-10-11 at 19:21 -0300, Henrique Junior wrote:
>  Hi,
>  As a desktop, Fedora is the best solution. Should I use the best 2nd
>  solution? (Ubuntu).
>  Maybe if we take *some* releases to LLT, lets say, Fedora N, Fedora
>  N+4. The intermediary releases will be "non LLT".... Well, I know that
>  Fedora have to worry about all releases, but if we have few people to
>  work it should be one point.
>  Maybe it looks crazy.
>  
>  P.S.: I'm sorry for my poor english. 
But, isn't that exactly what RHEL/CentOS are?  RHEL/CentOS 3 were based
on Red Hat Linux 9, RHEL/CentOS 4 were based on Fedora Core 3,
RHEL/CentOS 5 were based on Fedora Core 6.  I presume that RHEL/CentOS 6
will be based around Fedora 10 or 11....  So, RHEL/CentOS are the Long
Term solution for Fedora.

What I think is lacking (but seem to be being worked on), is a
convenient "upgrade" process within the "family".  So that if I use
Fedora 9 or 10, that I could "in-place" upgrade to RHEL/CentOS 6 when it
comes out.

Historically, using RHEL/CentOS for desktop has been problematic for
some given their "stability" and "lack of movement".  But it does
appear
that this is changing.  Looking at RHEL/CentOS 5.2 compared to 5.0,
there are some actual version upgrades to some of the packages, so
perhaps it becomes more feasible for more people as a desktop.

--Rob

[Chuck Anderson]

On Sat, Oct 11, 2008 at 11:12:38PM -0400, Robert Locke wrote:
>  What I think is lacking (but seem to be being worked on), is a
>  convenient "upgrade" process within the "family".  So that if I use
>  Fedora 9 or 10, that I could "in-place" upgrade to RHEL/CentOS 6 when it
>  comes out. 
You could always pass "upgradeany" to Anaconda to upgrade other 
distros, but this isn't officially supported.

[Horst H. von Brand]

Robert Locke <lists(a)ralii.com&gt; wrote:

[...]

>  What I think is lacking (but seem to be being worked on), is a
>  convenient "upgrade" process within the "family".  So that if I use
>  Fedora 9 or 10, that I could "in-place" upgrade to RHEL/CentOS 6 when it
>  comes out. 
By the time RHEL/CentOS comes out, the Fedora from which it branched has
long moved past it...
 
>  Historically, using RHEL/CentOS for desktop has been problematic for
>  some given their "stability" and "lack of movement". 
For many desktop uses the latest bling is definitely not a requirement,
more the contrary.  Sure, on notebooks stuff like WiFi is required (and
needs a newer kernel, etc). Perhaps a line with the required packages
(paralell to EPEL) would be doable?

>                                                       But it does
> appear
>  that this is changing.  Looking at RHEL/CentOS 5.2 compared to 5.0,
>  there are some actual version upgrades to some of the packages, so
>  perhaps it becomes more feasible for more people as a desktop. 
It has always been that selected packages get version upgrades during
RHEL's life. I'd suspect that happens when the pain of backporting gets too
large and the visible differences are small enough to not make a
difference. I.e., it helps you not a bit to get an "up to date desktop".
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

[Robert Locke]

On Sun, 2008-10-12 at 21:53 -0300, Horst H. von Brand wrote:
>  Robert Locke <lists(a)ralii.com&gt; wrote:
>  
>  [...]
>  
>  > What I think is lacking (but seem to be being worked on), is a
>  > convenient "upgrade" process within the "family".  So that if I
> use
>  > Fedora 9 or 10, that I could "in-place" upgrade to RHEL/CentOS 6 when it
>  > comes out.
>  
>  By the time RHEL/CentOS comes out, the Fedora from which it branched has
>  long moved past it... 
Really?  You saying that Fedora 7 came out before RHEL5?  Looking at the
calendar, it's a pretty simple Fedora Core 6, RHEL/CentOS 5, Fedora 7.
I don't see that "long moved past", unless you like to run Rawhide, at
which point, why are we talking about a stable LTS?

>   
>  > Historically, using RHEL/CentOS for desktop has been problematic for
>  > some given their "stability" and "lack of movement".
>  
>  For many desktop uses the latest bling is definitely not a requirement,
>  more the contrary.  Sure, on notebooks stuff like WiFi is required (and
>  needs a newer kernel, etc). Perhaps a line with the required packages
>  (paralell to EPEL) would be doable? 
Pick a side please.  If the latest bling is not a requirement, then
explain why CentOS is insufficient in providing the "long term
solution"?

I'm still not seeing the "need" for an LTS Fedora....

--Rob

[Kevin Kofler]

Robert Locke <lists <at> ralii.com> writes:
>  Really?  You saying that Fedora 7 came out before RHEL5?  Looking at
> the
>  calendar, it's a pretty simple Fedora Core 6, RHEL/CentOS 5, Fedora 7.
>  I don't see that "long moved past", unless you like to run Rawhide, at
>  which point, why are we talking about a stable LTS? 
One word: updates!
By the time RHEL 5 came out, even FC5 had a newer kernel (and several other 
packages).

        Kevin Kofler

[Les Mikesell]

Kevin Kofler wrote:
>  Robert Locke <lists <at> ralii.com> writes:
> > Really?  You saying that Fedora 7 came out before RHEL5?  Looking at the
> > calendar, it's a pretty simple Fedora Core 6, RHEL/CentOS 5, Fedora 7.
> > I don't see that "long moved past", unless you like to run Rawhide, at
> > which point, why are we talking about a stable LTS?
>  
>  One word: updates!
>  By the time RHEL 5 came out, even FC5 had a newer kernel (and several other 
>  packages). 
Ummm, as I recall, there were some update kernels in FC5 and even FC6 
that wouldn't boot on various hardware.  Was it _really_ necessary to 
ship those after a reliable version was available?

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

[Ralph angenendt]

Henrique Junior wrote:
>  Perhaps it is time to seek volunteers to bring back the Fedora
> Legacy
>  and see if more people are interested this time. 
It didn't work with the limited number of packages in 1, 2 and 3 - why (or
how) should it work now with the much larger number of packages available
for F9/10/11? The workload for maintaining legacy systems has increased 
manyfold. Sure, the number of people involved also has increased, but ...

Cheers,

Ralph

[Patrice Dumas]

On Sun, Oct 12, 2008 at 12:01:35AM +0200, Ralph Angenendt wrote:
>  
>  It didn't work with the limited number of packages in 1, 2 and 3 - why (or
>  how) should it work now with the much larger number of packages available
>  for F9/10/11? The workload for maintaining legacy systems has increased 
>  manyfold. Sure, the number of people involved also has increased, but ... 
There are many other differences. We can use the rules of fedora (and
could use the infrastructure). And after the merging there are more
involvment of the community in maintaining packages. I was interested in
legacy at some point, but everything was so different than in fedora
extras that it deterred me.

--
Pat

reviving Fedora Legacy

[Chuck Anderson]

On Sun, Oct 12, 2008 at 12:17:05AM +0200, Patrice Dumas wrote:
>  On Sun, Oct 12, 2008 at 12:01:35AM +0200, Ralph Angenendt wrote:
>  > 
>  > It didn't work with the limited number of packages in 1, 2 and 3 - why (or
>  > how) should it work now with the much larger number of packages available
>  > for F9/10/11? The workload for maintaining legacy systems has increased 
>  > manyfold. Sure, the number of people involved also has increased, but ...
>  
>  There are many other differences. We can use the rules of fedora (and
>  could use the infrastructure). And after the merging there are more
>  involvment of the community in maintaining packages. I was interested in
>  legacy at some point, but everything was so different than in fedora
>  extras that it deterred me. 
There also doesn't need to be a requirement that every single package 
in the Everything repo be maintained for a longer time.  We could 
start with some of the spins, like Fedora spin, which contains most of 
the "core" packages.  Interested contributors would need to commit to 
support either their own packages for a longer term, or other packages 
where the current Fedora maintainer doesn't want to do long term 
maintenance.  This would be simlar to how EPEL works, but for Fedora 
releases.

reviving Fedora Legacy

[Ralf Corsepius]

On Sat, 2008-10-11 at 18:28 -0400, Chuck Anderson wrote:
>  On Sun, Oct 12, 2008 at 12:17:05AM +0200, Patrice Dumas wrote:
>  > On Sun, Oct 12, 2008 at 12:01:35AM +0200, Ralph Angenendt wrote:
>  > > 
>  > > It didn't work with the limited number of packages in 1, 2 and 3 - why (or
>  > > how) should it work now with the much larger number of packages available
>  > > for F9/10/11? The workload for maintaining legacy systems has increased 
>  > > manyfold. Sure, the number of people involved also has increased, but ...
>  > 
>  > There are many other differences. We can use the rules of fedora (and
>  > could use the infrastructure). And after the merging there are more
>  > involvment of the community in maintaining packages. I was interested in
>  > legacy at some point, but everything was so different than in fedora
>  > extras that it deterred me.
>  
>  There also doesn't need to be a requirement that every single package 
>  in the Everything repo be maintained for a longer time.  We could 
>  start with some of the spins, like Fedora spin, which contains most of 
>  the "core" packages.  Interested contributors would need to commit to 
>  support either their own packages for a longer term, or other packages 
>  where the current Fedora maintainer doesn't want to do long term 
>  maintenance.  This would be simlar to how EPEL works, but for Fedora 
>  releases. 
Similar proposals have come up several times before (I once proposed
something like this), but so far, they all had been shoot down so far.

Openly said, my impression that certain parties in Fedora fear a Fedora
LTS rsp. life-time-extended Fedora to compete with RH products.

Ralf

reviving Fedora Legacy

[Rahul Sundaram]

Ralf Corsepius wrote:
>  
>  Similar proposals have come up several times before (I once proposed
>  something like this), but so far, they all had been shoot down so far. 
It seems that there isn't enough people interested in doing the work. If 
there are, it is easy enough to form a SIG, demonstrate the interest and 
get others to endorse that effort.

>  Openly said, my impression that certain parties in Fedora fear a
> Fedora
>  LTS rsp. life-time-extended Fedora to compete with RH products. 
That makes no sense. Red Hat's business is providing services on top of 
open source software. Fedora LTS wouldn't compete any better than one of 
binary compatible RHEL rebuilds. Vague accusations such as these are 
distinctly unhelpful. If you are going to make a claim, name the 
specific "certain parties in Fedora".

Rahul

reviving Fedora Legacy

[Patrice Dumas]

On Sun, Oct 12, 2008 at 03:19:51PM +0530, Rahul Sundaram wrote:
>  Ralf Corsepius wrote:
> >
> > Similar proposals have come up several times before (I once proposed
> > something like this), but so far, they all had been shoot down so far.
>
>  It seems that there isn't enough people interested in doing the work. If  
>  there are, it is easy enough to form a SIG, demonstrate the interest and  
>  get others to endorse that effort. 
The interest will be very different depending whether we are allowed to
use the fedora infra at no cost or if we have to set up a whole new
infra. Saying 'use the infra if you find somebody to sign your package'
is much less costly than gathering packagers.

Doing a SIG although fedora infra won't be used is just pointless. And
yes, the right to use the fedora space was turned down.

--
Pat

reviving Fedora Legacy

[Rex Dieter]

Patrice Dumas wrote:

>  Doing a SIG although fedora infra won't be used is just
> pointless. And
>  yes, the right to use the fedora space was turned down. 
Really?  By whom?  References?

-- Rex

reviving Fedora Legacy

[Patrice Dumas]

On Sun, Oct 12, 2008 at 07:51:09AM -0500, Rex Dieter wrote:
>  Patrice Dumas wrote:
>  
>  > Doing a SIG although fedora infra won't be used is just pointless. And
>  > yes, the right to use the fedora space was turned down.
>  
>  Really?  By whom?  References? 
It begins here:
https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00598....

--
Pat

reviving Fedora Legacy

[Rex Dieter]

Patrice Dumas wrote:

>  On Sun, Oct 12, 2008 at 07:51:09AM -0500, Rex Dieter wrote:
> > Patrice Dumas wrote:
> > 
> > > Doing a SIG although fedora infra won't be used is just pointless. And
> > > yes, the right to use the fedora space was turned down.
> > 
> > Really?  By whom?  References?
>  
>  It begins here: 
...

I perused the thread, but failed to find any reference to any authoritative statement that
fedora infrastructure could not be used for such an effort.  Am I missing something?

-- Rex

reviving Fedora Legacy

[Patrice Dumas]

On Sun, Oct 12, 2008 at 09:57:47AM -0500, Rex Dieter wrote:
>  
>  I perused the thread, but failed to find any reference to any authoritative statement
> that fedora infrastructure could not be used for such an effort.  Am I missing something?
There was no support, and hostility toward the project, for example,
but it is not the only one:
https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00802....

In my response to that mail, failing to have a metric I retired my
proposal, and nobody supported my views (and overall nobody supported my
views).

I found the page, with a summary of why this was abandonned:
http://fedoraproject.org/wiki/DraftUAEL

I guess that Jef speaks for himself, but he also is on the board 
and he seemed authoritative enough to me.

--
Pat

reviving Fedora Legacy

[Kevin Kofler]

Patrice Dumas <pertusus <at> free.fr> writes:
>  In my response to that mail, failing to have a metric I retired my
>  proposal, and nobody supported my views (and overall nobody supported my
>  views). 
In terms of those metrics, I'm still in favor of a mostly anarchical approach:
* Don't promise *anything* yet - tell users that they may or may not get 
updates. Promises can come if the project turns out working.
* Lift *all* ACLs for the EOL branches (yes, even for the kernel).
* Security fixes can be committed and built by *anyone* without asking for 
anyone's approval.
* Likewise for bug fixes which went into the lowest maintained Fedora release 
(but they can be pushed to testing resp. stable no earlier than to testing 
resp. stable for that release).
* Anything else is strongly discouraged and needs approval from both the 
maintainer and some committee (which should be granted only in reasonable 
cases, such as new hardware support). (That's where the anarchy ends, otherwise 
we can end up in all sorts of absurd situations.) If necessary, offenders could 
be banned from committing to EOL branches.
* Just push out the results to the official Fedora repositories.

        Kevin Kofler

reviving Fedora Legacy

[Kevin Kofler]

I wrote:
>  In terms of those metrics, I'm still in favor of a mostly
> anarchical
>  approach: 
[snip]

Oh, and I forgot:
* *No* QA of the type the original Fedora Legacy had, where all updates had to 
reviewed before even pushing them to testing and tested before pushing them to 
stable. I believe it was this excessive QA which killed Fedora Legacy. Instead, 
it should be up to whoever submits the updates to decide whether to go through 
testing and when to push to stable, and no QA whatsoever should be required to 
push an update to testing, just as things work in all of Fedora. If the 
security team insists on it, the security team approval system for security 
updates could be applied (though I consider that completely unnecessary 
bureaucracy, but that's a separate rant), if they don't want to be approving 
security updates for EOL releases, then they should just go straight to stable.

        Kevin Kofler

reviving Fedora Legacy

[Patrice Dumas]

On Sun, Oct 12, 2008 at 09:12:05PM +0000, Kevin Kofler wrote:
>  Patrice Dumas <pertusus <at> free.fr> writes:
>  > In my response to that mail, failing to have a metric I retired my
>  > proposal, and nobody supported my views (and overall nobody supported my
>  > views).
>  
>  In terms of those metrics, I'm still in favor of a mostly anarchical approach:
I completly agree. This is simple and leave everything to the packagers
initiative, I think that it is also what Ralf had in mind. But some people 
insisted on communicating to the public what was maintained, hence my 
proposal. But what you propose is better.

--
Pat

reviving Fedora Legacy

[shmuel siegel]

Patrice Dumas wrote:
>  On Sun, Oct 12, 2008 at 09:12:05PM +0000, Kevin Kofler wrote:
>    
> > Patrice Dumas <pertusus <at> free.fr> writes:
> >     
> >> In my response to that mail, failing to have a metric I retired my
> >> proposal, and nobody supported my views (and overall nobody supported my
> >> views).
> >>       
> > In terms of those metrics, I'm still in favor of a mostly anarchical approach:
> >     
>
>  I completly agree. This is simple and leave everything to the packagers
>  initiative, I think that it is also what Ralf had in mind. But some people 
>  insisted on communicating to the public what was maintained, hence my 
>  proposal. But what you propose is better.
>
>  --
>  Pat
>
>     
Up to here you definitely had my sympathy. But this anarchical approach 
makes me wonder who your target audience is. I would think that the 
majority of people who wouldn't want to upgrade to an official Fedora 
release would be people who need stability. Fedora itself  is probably a 
little bit too unstable for them. These people would probably want more 
than the average level of QA. To borrow a phrasing from Jef, legacy 
updates should be edible by babies.

reviving Fedora Legacy

[Patrice Dumas]

On Mon, Oct 13, 2008 at 12:01:53AM +0200, shmuel siegel wrote:
> >   
>  Up to here you definitely had my sympathy. But this anarchical approach  
>  makes me wonder who your target audience is. I would think that the  
>  majority of people who wouldn't want to upgrade to an official Fedora  
>  release would be people who need stability. Fedora itself  is probably a  
>  little bit too unstable for them. These people would probably want more  
>  than the average level of QA. To borrow a phrasing from Jef, legacy  
>  updates should be edible by babies. 
More QA in EOL than in release doesn't make sense. This 'anarchical'
approach is not very anarchical given what kind of changes are allowed.

--
Pat

reviving Fedora Legacy

[shmuel siegel]

Patrice Dumas wrote:
>  On Mon, Oct 13, 2008 at 12:01:53AM +0200, shmuel siegel wrote:
>    
> >>   
> >>       
> > Up to here you definitely had my sympathy. But this anarchical approach  
> > makes me wonder who your target audience is. I would think that the  
> > majority of people who wouldn't want to upgrade to an official Fedora  
> > release would be people who need stability. Fedora itself  is probably a  
> > little bit too unstable for them. These people would probably want more  
> > than the average level of QA. To borrow a phrasing from Jef, legacy  
> > updates should be edible by babies.
> >     
>
>  More QA in EOL than in release doesn't make sense. This 'anarchical'
>  approach is not very anarchical given what kind of changes are allowed.
>
>  --
>  Pat
>
>     
 From a developer's point of view you are right. But I believe that the 
majority of risk takers would upgrade before the end of life simply 
because they want the newer stuff. Like I said, I am at a loss to 
understand who your target audience is. I identified my concept of a 
target audience, one that doesn't want the instability of an upgrade. 
Who is your target audience and how big do you expect this audience to 
be? Are there any statistics from Fedora legacy which would indicate the 
demand for the product? Any surveys indicating what people wanted from a 
Fedora legacy.
Don't get me wrong. I am not trying to discourage you. I am trying to 
help you build a better use case.

reviving Fedora Legacy

[Kevin Kofler]

shmuel siegel <fedora <at> shmuelhome.mine.nu> writes:
>  Patrice Dumas wrote:
>  > More QA in EOL than in release doesn't make sense. This 'anarchical'
>  > approach is not very anarchical given what kind of changes are allowed.
>
>   From a developer's point of view you are right. But I believe that the 
>  majority of risk takers would upgrade before the end of life simply 
>  because they want the newer stuff. 
We're just being pragmatic. It doesn't make sense to demand more QA than we 
have the resources to provide, that is what ultimately made Fedora Legacy fail.

        Kevin Kofler

reviving Fedora Legacy

[shmuel siegel]

Kevin Kofler wrote:
>  shmuel siegel <fedora <at> shmuelhome.mine.nu> writes:
>    
> > Patrice Dumas wrote:
> >     
> >> More QA in EOL than in release doesn't make sense. This 'anarchical'
> >> approach is not very anarchical given what kind of changes are allowed.
> >>       
> >  From a developer's point of view you are right. But I believe that the 
> > majority of risk takers would upgrade before the end of life simply 
> > because they want the newer stuff.
> >     
>
>  We're just being pragmatic. It doesn't make sense to demand more QA than we 
>  have the resources to provide, that is what ultimately made Fedora Legacy fail.
>
>          Kevin Kofler
>
>     
I disagree. You are not being pragmatic. You are looking for 
infrastructure support from Fedora without indicating that there is a 
benefit to Fedora. Supply without demand is no more useful than demand 
without supply. Since Fedora views itself as "the cutting edge distro", 
you have an uphill PR fight. Give the Fedora project a reason to spend 
some of their limited resources on you. At least let them know your 
target audience and why they would be interested.

reviving Fedora Legacy

[Kevin Kofler]

shmuel siegel <fedora <at> shmuelhome.mine.nu> writes:
>  I disagree. You are not being pragmatic. You are looking for 
>  infrastructure support from Fedora without indicating that there is a 
>  benefit to Fedora. Supply without demand is no more useful than demand 
>  without supply. Since Fedora views itself as "the cutting edge distro", 
>  you have an uphill PR fight. Give the Fedora project a reason to spend 
>  some of their limited resources on you. At least let them know your 
>  target audience and why they would be interested. 
My point of view is: If there are people wanting to do the work, why not let 
them? It costs almost nothing to just let people commit and build what they 
want, the infrastructure is essentially already there. Right now, we're stuck 
in a chicken&egg situation, where the people controlling the infrastructure 
say "show us interested maintainers first" and potentially interested packagers

say "show us the infrastructure first".

My interest in this project doesn't go much farther than that - well, I could 
build KDE security updates, which are few and far between, I might even help 
with xine-lib security updates (which are more of a PITA), but I have only 
limited interest in old stuff -, but I think there are people who would build 
the important updates, it was overreaching bureaucracy which killed Fedora 
Legacy (e.g. excessive QA requirements, paranoia such as not trusting 
Bugzilla's authentication mechanisms, instead requiring GPG signing of Bugzilla 
comments, which raised the barrier to entry), not lack of interested 
developers.

        Kevin Kofler

reviving Fedora Legacy

[Jef Spaleta]

On Sun, Oct 12, 2008 at 4:22 PM, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
>  My point of view is: If there are people wanting to do the work, why
> not let
>  them? It costs almost nothing to just let people commit and build what they
>  want, the infrastructure is essentially already there. Right now, we're stuck
>  in a chicken&egg situation, where the people controlling the infrastructure
>  say "show us interested maintainers first" and potentially interested
> packagers
>  say "show us the infrastructure first". 

Okay...if you start with enough maintainers... how do you plan to
verify that you continue to have enough maintainers to hold a branch
open?  Without a firm timeline on when to close a branch.. will we
ever see a branch close?

-jef

reviving Fedora Legacy

[Kevin Kofler]

Jeff Spaleta <jspaleta <at> gmail.com> writes:
>  Okay...if you start with enough maintainers... how do you plan to
>  verify that you continue to have enough maintainers to hold a branch
>  open?  Without a firm timeline on when to close a branch.. will we
>  ever see a branch close? 
Why would we want to? Just let things going as long as there is at least one 
maintainer committing something. Even if not all security issues get fixed, 
it's better than if none gets fixed.

       Kevin Kofler

reviving Fedora Legacy

[Martin Langhoff]

On Mon, Oct 13, 2008 at 2:40 PM, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
> > open?  Without a firm timeline on when to close a branch.. will
> we
> > ever see a branch close?
>
>  Why would we want to? Just let things going as long as there is at least one
>  maintainer committing something. Even if not all security issues get fixed,
>  it's better than if none gets fixed. 
I don't think anyone would sign up as a user for such "support". LTS
is about a fairly specific promise that is very hard to commit to.

The work I am doing would definitely benefit from having some Fedora
releases turn into LTS, even if it's perhaps for clearly defined a
subset of packages. What Ubuntu does with it's LTS is hard for the
distro team but is excellent for "users" (re-spinners) like OLPC.

At the moment, it's not clear to me (perhaps because I haven't read
the appropriate doco...)

 - Which Fedora release becomes the base for the next RH/CentOS release.
 - How I transition my userbase from Fedora support to CentOS support at EOL

So I think it is a fair expectation to be able to "follow" a Fedora
release into its RH/CentOS stabilisation, knowing that the process
exists and that the stable branches are published. It definitely works
for other distros. Perhaps it's possible with Fedora -- hints and
pointers welcome.

But I would not sign up for the "whatever" support plan some people
are suggesting -- how the hell do I plan for it? Ah, some things might
get patched, some might not, and we won't know or tell in advance.

cheers,



m
-- 
 martin.langhoff(a)gmail.com
 martin(a)laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff

reviving Fedora Legacy

[Ralf Corsepius]

On Mon, 2008-10-13 at 15:12 +1300, Martin Langhoff wrote:
>  On Mon, Oct 13, 2008 at 2:40 PM, Kevin Kofler
> <kevin.kofler(a)chello.at&gt; wrote:
>  >> open?  Without a firm timeline on when to close a branch.. will we
>  >> ever see a branch close?
>  >
>  > Why would we want to? Just let things going as long as there is at least one
>  > maintainer committing something. Even if not all security issues get fixed,
>  > it's better than if none gets fixed.
>  
>  I don't think anyone would sign up as a user for such "support". LTS
>  is about a fairly specific promise that is very hard to commit to. 
How so? It would
be a legacy effort, run by volunteers, no guarantees,
no commitments.

>  The work I am doing would definitely benefit from having some Fedora
>  releases turn into LTS, even if it's perhaps for clearly defined a
>  subset of packages. What Ubuntu does with it's LTS is hard for the
>  distro team but is excellent for "users" (re-spinners) like OLPC. 
Yes,
but their notion of "LTS" is different from that of the "Legacy
Fedora" we are discussing here.

>  At the moment, it's not clear to me (perhaps because I
> haven't read
>  the appropriate doco...)
>  
>   - Which Fedora release becomes the base for the next RH/CentOS release. 
Pardon, to
me that's a RH internal business, not of any importance to
Fedora.

>   - How I transition my userbase from Fedora support to CentOS support
> at EOL 
This thought is exactly what I am aiming against. I want to people to
stay with Fedora, which would imply them  to upgrade to a newer Fedora,
instead of seeing them switching away from Fedora.

>  So I think it is a fair expectation to be able to "follow"
> a Fedora
>  release into its RH/CentOS stabilisation, knowing that the process
>  exists and that the stable branches are published. It definitely works
>  for other distros. Perhaps it's possible with Fedora -- hints and
>  pointers welcome.
>  
>  But I would not sign up for the "whatever" support plan some people
>  are suggesting -- how the hell do I plan for it? Ah, some things might
>  get patched, some might not, and we won't know or tell in advance. 
Right, but
if you are consequent, you could start with the latest
released CentOS/RHEL right from the beginning instead of Fedora.
Besides the fact that the Fedora->RHEL upgrade path is unsupported (and
will never be complete), you'd loose some "technology preview", however
you would avoid "the Fedora hassle" more or less entirely.

Ralf

reviving Fedora Legacy

[Horst H. von Brand]

Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  On Mon, 2008-10-13 at 15:12 +1300, Martin Langhoff wrote: 
[...]

>  > I don't think anyone would sign up as a user for such
> "support". LTS
>  > is about a fairly specific promise that is very hard to commit to. 
>  How so? It would be a legacy effort, run by volunteers, no
> guarantees,
>  no commitments. 
So would that satisfy /you/ in very particular? You would come screaming
bloody murder when one fine summer day, out of the blue, the "LTS" you were
planning on using for a few months more until you are ready to migrate to
the Latest And Greatest announces it will stop out of boredom of its last
maintainers... or just /the/ package you depend on is left stranded for
lack of interest... or terrible security problems in some unmaintained
packages show up...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

reviving Fedora Legacy

[Kevin Kofler]

Martin Langhoff <martin.langhoff <at> gmail.com> writes:
>  I don't think anyone would sign up as a user for such
> "support". LTS
>  is about a fairly specific promise that is very hard to commit to. 
The users I have in mind wouldn't actively "sign up" for it, they'd end
up with 
it due to inaction, just as they currently end up with no updates at all.

See also Ralf Corsépius's reply:
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01110.html

>  At the moment, it's not clear to me (perhaps because I
> haven't read
>  the appropriate doco...)
>  
>   - Which Fedora release becomes the base for the next RH/CentOS release. 
This is a decision made by Red Hat behind closed doors and only when it's time 
for it, not in advance. So we cannot know.

>   - How I transition my userbase from Fedora support to CentOS support
> at EOL 
This is just not possible, as explained many times in this thread. See e.g.:
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01047.html

>  So I think it is a fair expectation to be able to "follow"
> a Fedora
>  release into its RH/CentOS stabilisation, knowing that the process
>  exists and that the stable branches are published. It definitely works
>  for other distros. Perhaps it's possible with Fedora -- hints and
>  pointers welcome. 
It's neither a fair expectation nor possible.

        Kevin Kofler

reviving Fedora Legacy

[Emmanuel Seyman]

* Kevin Kofler [13/10/2008 10:36] :
>  The users I have in mind wouldn't actively "sign up" for it, they'd end
> up with 
>  it due to inaction, just as they currently end up with no updates at all. 
With not even an opt-in ?
This means that we'll be changing support conditions on a user's box
without even telling him we're doing so.

Emmanuel

reviving Fedora Legacy

[Patrice Dumas]

On Mon, Oct 13, 2008 at 10:46:14AM +0200, Emmanuel Seyman wrote:
>  * Kevin Kofler [13/10/2008 10:36] :
>  >
>  > The users I have in mind wouldn't actively "sign up" for it,
> they'd end up with 
>  > it due to inaction, just as they currently end up with no updates at all.
>  
>  With not even an opt-in ?
>  This means that we'll be changing support conditions on a user's box
>  without even telling him we're doing so. 
We don't need to tell if it is on the right direction. And sure we'll
tell, but only if it is succesful in term of enough packagers doing so.

--
Pat

reviving Fedora Legacy

[Emmanuel Seyman]

* Patrice Dumas [13/10/2008 11:28] :
>  We don't need to tell if it is on the right direction. 
I strongly disagree. This is no way to provide support.

>                                                         And sure
> we'll
>  tell, but only if it is succesful in term of enough packagers doing so. 
You mean that you want to change support conditions on somebody's box
and only tell them if the support is decent enough ?
If the "long term support" project isn't succesful, we're going to
force
half baked updates on a box and not even warn him we're doing so ?

Emmanuel

reviving Fedora Legacy

[Patrice Dumas]

On Mon, Oct 13, 2008 at 11:41:55AM +0200, Emmanuel Seyman wrote:
>  * Patrice Dumas [13/10/2008 11:28] :
>  >
>  >                                                        And sure we'll
>  > tell, but only if it is succesful in term of enough packagers doing so.
>  
>  You mean that you want to change support conditions on somebody's box
>  and only tell them if the support is decent enough ?
>  If the "long term support" project isn't succesful, we're going to
> force
>  half baked updates on a box and not even warn him we're doing so ? 
Why are you telling about half baked updates? Who will do that? Fedora
packagers?

--
Pat

reviving Fedora Legacy

[Emmanuel Seyman]

* Patrice Dumas [13/10/2008 13:23] :
>  Why are you telling about half baked updates? Who will do that? Fedora 
They're half-baked in the sense that there's less commitement
post-EOL than pre-EOL.

Emmanuel

reviving Fedora Legacy

[Patrice Dumas]

On Mon, Oct 13, 2008 at 01:30:21PM +0200, Emmanuel Seyman wrote:
>  * Patrice Dumas [13/10/2008 13:23] :
>  >
>  > Why are you telling about half baked updates? Who will do that? Fedora
>  
>  They're half-baked in the sense that there's less commitement
>  post-EOL than pre-EOL. 
But post-EOL there is currently no commitment and there won't be any
promise on it. Some is better than not at all.

--
Pat

reviving Fedora Legacy

[Horst H. von Brand]

Patrice Dumas <pertusus(a)free.fr&gt; wrote:
>  On Mon, Oct 13, 2008 at 01:30:21PM +0200, Emmanuel Seyman wrote:
>  > * Patrice Dumas [13/10/2008 13:23] :
>  > >
>  > > Why are you telling about half baked updates? Who will do that? Fedora
>  > 
>  > They're half-baked in the sense that there's less commitement
>  > post-EOL than pre-EOL. 
>  But post-EOL there is currently no commitment and there won't be
> any
>  promise on it. Some is better than not at all. 
"Might someday get looked at and fixed, if somebody cares" is definitely
much worse than "No more fixes, do upgrade".

[Yes, the exact same reasoning behind rm(1)ed files are gone for good:
 Users moan the first few times they get burned, afterwards they learn and
 are careful.]
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

reviving Fedora Legacy

[Ralf Corsepius]

On Tue, 2008-10-14 at 09:42 -0300, Horst H. von Brand wrote:
>  Patrice Dumas <pertusus(a)free.fr&gt; wrote:
>  > On Mon, Oct 13, 2008 at 01:30:21PM +0200, Emmanuel Seyman wrote:
>  > > * Patrice Dumas [13/10/2008 13:23] :
>  > > >
>  > > > Why are you telling about half baked updates? Who will do that? Fedora
>  > > 
>  > > They're half-baked in the sense that there's less commitement
>  > > post-EOL than pre-EOL.
>  
>  > But post-EOL there is currently no commitment and there won't be any
>  > promise on it. Some is better than not at all.
>  
>  "Might someday get looked at and fixed, if somebody cares" is definitely
>  much worse than "No more fixes, do upgrade". 
Some users will do so, but others will react as Wikipedia did: Quit
using Fedora and switch to a different distro or OS.

Hell, folks, I have seen people switching to MinGW, because of this.
They told me, "MinGW" better suites their needs because it offers
support for "this weird GNU-stuff" on "the industry-standard OS".

reviving Fedora Legacy

[Les Mikesell]

Ralf Corsepius wrote:
>  
> >>>> Why are you telling about half baked updates? Who will do that? Fedora
> >>> They're half-baked in the sense that there's less commitement
> >>> post-EOL than pre-EOL.
> >> But post-EOL there is currently no commitment and there won't be any
> >> promise on it. Some is better than not at all.
> > "Might someday get looked at and fixed, if somebody cares" is definitely
> > much worse than "No more fixes, do upgrade".
>  
>  Some users will do so, but others will react as Wikipedia did: Quit
>  using Fedora and switch to a different distro or OS.
>  
>  Hell, folks, I have seen people switching to MinGW, because of this.
>  They told me, "MinGW" better suites their needs because it offers
>  support for "this weird GNU-stuff" on "the industry-standard OS".
I don't think I'd use 'standard' to describe something unique and 
proprietary, but there is something to be said about an OS that runs for 
years without reinstalling and works with vendor provided drivers that 
also don't need to be reinstalled every few weeks.

-- 
    Les Mikesell
      lesmikesell(a)gmail.com

reviving Fedora Legacy

[Horst H. von Brand]

Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:

[...]

>  I don't think I'd use 'standard' to describe
> something unique and
>  proprietary, but there is something to be said about an OS that runs
>  for years without reinstalling and works with vendor provided drivers
>  that also don't need to be reinstalled every few weeks. 
You must have been using a different strand of that stuff than I got...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

reviving Fedora Legacy

[Les Mikesell]

Horst H. von Brand wrote:
>  Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:
>  
>  [...]
>  
> > I don't think I'd use 'standard' to describe something unique and
> > proprietary, but there is something to be said about an OS that runs
> > for years without reinstalling and works with vendor provided drivers
> > that also don't need to be reinstalled every few weeks.
>  
>  You must have been using a different strand of that stuff than I got... 
Or maybe you haven't kept up to date.  Win2k and XP with service pack 2 
and everything since are very reliable if kept updated and 
virus-protected.  Vista broke some interfaces and shows the problems you 
expect from that, though.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

reviving Fedora Legacy

[Patrice Dumas]

On Tue, Oct 14, 2008 at 09:42:21AM -0300, Horst H. von Brand wrote:
>  Patrice Dumas <pertusus(a)free.fr&gt; wrote:
>  > On Mon, Oct 13, 2008 at 01:30:21PM +0200, Emmanuel Seyman wrote:
>  > > * Patrice Dumas [13/10/2008 13:23] :
>  > > >
>  > > > Why are you telling about half baked updates? Who will do that? Fedora
>  > > 
>  > > They're half-baked in the sense that there's less commitement
>  > > post-EOL than pre-EOL.
>  
>  > But post-EOL there is currently no commitment and there won't be any
>  > promise on it. Some is better than not at all.
>  
>  "Might someday get looked at and fixed, if somebody cares" is definitely
>  much worse than "No more fixes, do upgrade". 
It will still be "No more fixes, do upgrade" that will be the main
message, but packagers could have the possibility to care. If there are
enough packagers, then we'll communicate on this but only if succesful.

--
Pat

reviving Fedora Legacy

[Les Mikesell]

Kevin Kofler wrote:
> >  - Which Fedora release becomes the base for the next RH/CentOS release.
>  
>  This is a decision made by Red Hat behind closed doors and only when it's time 
>  for it, not in advance. So we cannot know. 
Does that mean that they think their customers like surprises?

> >  - How I transition my userbase from Fedora support to CentOS
> support at EOL
>  
>  This is just not possible, as explained many times in this thread. See e.g.:
>  https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01047.html
>  
> > So I think it is a fair expectation to be able to "follow" a Fedora
> > release into its RH/CentOS stabilisation, knowing that the process
> > exists and that the stable branches are published. It definitely works
> > for other distros. Perhaps it's possible with Fedora -- hints and
> > pointers welcome.
>  
>  It's neither a fair expectation nor possible. 
Then no one should be surprised at the migration to Ubuntu and other 
distributions that have a more orderly transition from version to version.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

reviving Fedora Legacy

[Ralph angenendt]

Les Mikesell wrote:
>  Then no one should be surprised at the migration to Ubuntu and other 
>
>  distributions that have a more orderly transition from version to 
>  version. 
Which problem do you have with the transition from Fedora x to Fedora
x+1?

Ralph

reviving Fedora Legacy

[Les Mikesell]

Ralph Angenendt wrote:
>  Les Mikesell wrote:
> > Then no one should be surprised at the migration to Ubuntu and other  
> > distributions that have a more orderly transition from version to 
> > version.
>  
>  Which problem do you have with the transition from Fedora x to Fedora
>  x+1? 
Massive breakage...  Compatibility with the jpackage repo would be one 
example.  Keeping a mod_perl program working with apache/perl version 
changes would be another.  Database version changes.  Basically any API 
change anywhere is likely to break local programming as well as 3rd 
party repo usability, and Fedora changes wildly between versions.  But 
more to the point, no version of Fedora is  suitable for production use. 
  For example, long after a stable, reliable kernel was available in 
RHEL5 and Centos, FC6 shipped an update kernel that crashed on a variety 
of scsi controllers.  The nature of the project is just such that 
sufficient QA is never going to happen.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

reviving Fedora Legacy

[Nicolas Mailhot]

Le Lun 13 octobre 2008 16:52, Les Mikesell a écrit :
>  Ralph Angenendt wrote:
> > Les Mikesell wrote:
> >> Then no one should be surprised at the migration to Ubuntu and
> >> other
> >> distributions that have a more orderly transition from version to
> >> version.
> >
> > Which problem do you have with the transition from Fedora x to
> > Fedora
> > x+1?
>
>  Massive breakage...  Compatibility with the jpackage repo would be one
>  example. 
This is not a Fedora LTS (or even jpackage) problem, it's an artifact
of the historical OS/java split produced by closed JVMs.

It will heal itself as the jvm is internalised and the jpp <-> fedora
flow gets more dynamic.

-- 
Nicolas Mailhot

reviving Fedora Legacy

[Les Mikesell]

Nicolas Mailhot wrote:
>  
> >>> Then no one should be surprised at the migration to Ubuntu and
> >>> other
> >>> distributions that have a more orderly transition from version to
> >>> version.
> >> Which problem do you have with the transition from Fedora x to
> >> Fedora
> >> x+1?
> > Massive breakage...  Compatibility with the jpackage repo would be one
> > example.
>  
>  This is not a Fedora LTS (or even jpackage) problem, 
Changing APIs and thus becoming incompatible with everything that 
depended on them is very much a Fedora problem - or perhaps better 
stated as a Fedora user's problem.

>  it's an artifact
>  of the historical OS/java split produced by closed JVMs. 
No, it is an artifact of wildly changing APIs.  That was just an obvious 
example.  The same applies to apache/perl/python and just about every 
other package versioning.

>  It will heal itself as the jvm is internalised and the jpp <->
> fedora
>  flow gets more dynamic. 
I'm nowhere near that optimistic.  I expect more of the usual fedora 
syndrome where everything must become part of the internal repository 
and carefully tweaked to match today's weirdness to be expected to work 
at all, instead of working to match and maintain standard APIs and 
compatibility with 3rd party work.   And then between fedora releases, 
the internal weirdness makes wild jumps so even your own development 
work that depended on earlier APIs has to start over.

-- 
    Les Mikesell
     lesmikesell(a)gmail.com

reviving Fedora Legacy

[Jesse Keating]

On Mon, 2008-10-13 at 10:46 -0500, Les Mikesell wrote:
>  
>  No, it is an artifact of wildly changing APIs.  That was just an obvious 
>  example.  The same applies to apache/perl/python and just about every 
>  other package versioning. 
But upstream chanced those APIs, and isn't upstream always right?

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

reviving Fedora Legacy

[Les Mikesell]

Jesse Keating wrote:
>  On Mon, 2008-10-13 at 10:46 -0500, Les Mikesell wrote:
> > No, it is an artifact of wildly changing APIs.  That was just an obvious 
> > example.  The same applies to apache/perl/python and just about every 
> > other package versioning.
>  
>  But upstream chanced those APIs, and isn't upstream always right? 
Even if it is right in the long run, the point of a distribution is to 
to protect its users from mid-release breakage.  If I wanted the 
upstream version as-is every day, I'd download it directly myself.  I 
expect a distribution to not break compatibility with what it packaged 
and shipped yesterday.

-- 
   Les Mikesell
     lesmikesell(a)gmail.com

reviving Fedora Legacy

[Jesse Keating]

On Mon, 2008-10-13 at 15:46 -0500, Les Mikesell wrote:
>  
>  Even if it is right in the long run, the point of a distribution is to 
>  to protect its users from mid-release breakage.  If I wanted the 
>  upstream version as-is every day, I'd download it directly myself.  I 
>  expect a distribution to not break compatibility with what it packaged 
>  and shipped yesterday. 
You certainly have a point if we're talking about in release updates,
but not if we're talking release to release upgrades (IE 9 to 10).  We
(the Fedora project) leave it up to maintainer discretion as to what
kind of updates to bring to in release updates.  I'm pretty certain that
if we tried to be more authoritative on this front you'd find lots of
your brethren quite upset at the 'bureaucracy' getting involved.

So if you have a issue with in-release updates, you need to look no
further than the other maintainers.  This is what happens when we let
maintainers make their own decisions, for better or worse.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

reviving Fedora Legacy

[Horst H. von Brand]

Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
>  Martin Langhoff <martin.langhoff <at> gmail.com> writes:
>  > I don't think anyone would sign up as a user for such "support". LTS
>  > is about a fairly specific promise that is very hard to commit to. 
>  The users I have in mind wouldn't actively "sign up"
> for it, they'd end
>  up with it due to inaction, just as they currently end up with no updates
>  at all. 
Catering to lazyness sounds misguided to me...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

reviving Fedora Legacy

[Les Mikesell]

Horst H. von Brand wrote:
>  Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
> > Martin Langhoff <martin.langhoff <at> gmail.com> writes:
> >> I don't think anyone would sign up as a user for such "support".
> LTS
> >> is about a fairly specific promise that is very hard to commit to.
>  
> > The users I have in mind wouldn't actively "sign up" for it, they'd
> end
> > up with it due to inaction, just as they currently end up with no updates
> > at all.
>  
>  Catering to lazyness sounds misguided to me... 
While I don't have much faith in Fedora to provide long term or even 
short term stability, providing security fixes for bugs you shipped even 
beyond the expected support time frame sounds like a very responsible 
thing to do.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

reviving Fedora Legacy

[Jesse Keating]

On Tue, 2008-10-14 at 08:00 -0500, Les Mikesell wrote:
>  While I don't have much faith in Fedora to provide long term or
> even 
>  short term stability, providing security fixes for bugs you shipped even 
>  beyond the expected support time frame sounds like a very responsible 
>  thing to do. 
It would be, if all security updates were pushed, or at least all
critical updates.  However the current proposals are "whatever any
maintainer feels like" not even close to "all".  Leading people into
that realm via lazyness is in fact very irresponsible, and not something
Fedora would put it's name on.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

reviving Fedora Legacy

[Kevin Kofler]

Jesse Keating <jkeating <at> redhat.com> writes:
>  It would be, if all security updates were pushed, or at least all
>  critical updates.  However the current proposals are "whatever any
>  maintainer feels like" not even close to "all".  Leading people into
>  that realm via lazyness is in fact very irresponsible, and not something
>  Fedora would put it's name on. 
The assumption in the proposal is that if the update is really critical, 
somebody will care.

And those "lazy" people (in quotes because there are also other reasons than 
laziness) would otherwise end up with no updates at all, how is that better 
than at least providing _some_ security fixes, even if not all gets fixed?

        Kevin Kofler

reviving Fedora Legacy

[Jesse Keating]

On Tue, 2008-10-14 at 18:22 +0000, Kevin Kofler wrote:
>  And those "lazy" people (in quotes because there are also
> other reasons than 
>  laziness) would otherwise end up with no updates at all, how is that better 
>  than at least providing _some_ security fixes, even if not all gets fixed? 
No updates, as well as warnings from PackageKit et al that explains that
the release has gone end of life is a heck of a lot different from a
continued dribble of updates that /looks/ like the release is still in
good support.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

reviving Fedora Legacy

[Benny Amorsen]

Kevin Kofler <kevin.kofler(a)chello.at&gt; writes:

>  Why would we want to? Just let things going as long as there is at
> least one 
>  maintainer committing something. Even if not all security issues get fixed, 
>  it's better than if none gets fixed. 
I'd love to see this. It could e.g. keep a service in the process of
being decommissioned alive a little longer without having to do the
usual upgrade.

It wouldn't be good for anything too serious, but if noone steps up
for a necessary security patch, I could do it myself and then get to
share the result with everyone else on that obsolete release. I would
have to test all updates locally, but for services on the way out that
is generally easier than testing the full upgrade.

If it breaks something for someone, well, they should be more careful
which updates they apply, especially once official support is gone. It
might even encourage an upgrade and perhaps keep one box from being
compromised.


/Benny

reviving Fedora Legacy

[Horst H. von Brand]

Benny Amorsen <benny+usenet(a)amorsen.dk&gt; wrote:
>  Kevin Kofler <kevin.kofler(a)chello.at&gt; writes: 
>  > Why would we want to? Just let things going as long as there is
> at
>  > least one maintainer committing something. Even if not all security
>  > issues get fixed, it's better than if none gets fixed. 
>  I'd love to see this. It could e.g. keep a service in the process
> of
>  being decommissioned alive a little longer without having to do the
>  usual upgrade. 
Currently you have *6 months* to move over to the next Fedora...

>  It wouldn't be good for anything too serious, 
I.e., completely useless.

>                                                but if noone steps up
>  for a necessary security patch, I could do it myself 
Sorry, I very much doubt that.

>                                                       and then get to
>  share the result with everyone else on that obsolete release. I would
>  have to test all updates locally, but for services on the way out that
>  is generally easier than testing the full upgrade. 
It is even easier to migrate to CentOS and keep going with that one... the
difference is that the bumps in the road are much bigger, but you have a
couple of years to migrate your stuff.

>  If it breaks something for someone, well, they should be more
> careful
>  which updates they apply, especially once official support is gone. It
>  might even encourage an upgrade and perhaps keep one box from being
>  compromised. 
How is that less work in the longer run than just keep upgrading or moving
to some LTS distribution?
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

reviving Fedora Legacy

[Rex Dieter]

Horst H. von Brand wrote:

>  Benny Amorsen <benny+usenet(a)amorsen.dk&gt; wrote: 
> > I'd love to see this. It could e.g. keep a service in the
> process of
> > being decommissioned alive a little longer without having to do the
> > usual upgrade.
>  
>  Currently you have *6 months* to move over to the next Fedora... 
s/6/13/ ?

-- Rex

reviving Fedora Legacy

[Stephen John Smoogen]

On Tue, Oct 14, 2008 at 11:13 AM, Rex Dieter <rdieter(a)math.unl.edu&gt; wrote:
>  Horst H. von Brand wrote:
>
> > Benny Amorsen <benny+usenet(a)amorsen.dk&gt; wrote:
>
> >> I'd love to see this. It could e.g. keep a service in the process of
> >> being decommissioned alive a little longer without having to do the
> >> usual upgrade.
> >
> > Currently you have *6 months* to move over to the next Fedora...
>
>  s/6/13/ ?
>  
I think the problem is that people have a hard time seeing what each
other is talking about. I think this is what the upgrade policy is.

           Release                 EOL
Fedora 8   2007-11-10      2008-12-25?
Fedora 9   2008-05-13      2008-05-XX
Fedora 10  2008-11-25?     2008-11-XX
Fedora 11  2008-05-XX      2009-05-XX

If Fedora were to make its schedules of 6 months.. and I am at Fedora
8, I have 7 months to move from Fedora 8 -> 9 since 8 isn't available
til 6 months out of my 13 month support. Now the lifetime of Fedora 8
would be 13 months.. but my window to upgrade before I lose security
is 7 months.

-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

reviving Fedora Legacy

[Stephen John Smoogen]

On Tue, Oct 14, 2008 at 11:25 AM, Stephen John Smoogen <smooge(a)gmail.com&gt; wrote:
>  On Tue, Oct 14, 2008 at 11:13 AM, Rex Dieter
> <rdieter(a)math.unl.edu&gt; wrote:
> > Horst H. von Brand wrote:
> >
> >> Benny Amorsen <benny+usenet(a)amorsen.dk&gt; wrote:
> >
> >>> I'd love to see this. It could e.g. keep a service in the process of
> >>> being decommissioned alive a little longer without having to do the
> >>> usual upgrade.
> >>
> >> Currently you have *6 months* to move over to the next Fedora...
> >
> > s/6/13/ ?
> >
>
>  I think the problem is that people have a hard time seeing what each
>  other is talking about. I think this is what the upgrade policy is.
>
>            Release                 EOL
>  Fedora 8   2007-11-10      2008-12-25?
>  Fedora 9   2008-05-13      2008-05-XX
>  Fedora 10  2008-11-25?     2008-11-XX
>  Fedora 11  2008-05-XX      2009-05-XX
>  
I don't know who the idiot who wrote this is... but boy he should be shot.

           Release                 EOL
Fedora  8  2007-11-10      2008-12-25?
Fedora  9  2008-05-13      2008-06-XX
Fedora 10  2008-11-25?     2009-12-XX
Fedora 11  2009-05-XX      2010-06-XX
Fedora 12  2009-11-XX      2010-12-XX
Fedora 13  2010-05-XX      2011-06-XX


>  If Fedora were to make its schedules of 6 months.. and I am at
> Fedora
>  8, I have 7 months to move from Fedora 8 -> 9 since 8 isn't available
>  til 6 months out of my 13 month support. Now the lifetime of Fedora 8
>  would be 13 months.. but my window to upgrade before I lose security
>  is 7 months.
>
>  --
>  Stephen J Smoogen. -- BSD/GNU/Linux
>  How far that little candle throws his beams! So shines a good deed
>  in a naughty world. = Shakespeare. "The Merchant of Venice"
>  


-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

reviving Fedora Legacy

[Seth Vidal]

On Tue, 2008-10-14 at 11:44 -0600, Stephen John Smoogen wrote:
>  I don't know who the idiot who wrote this is... but boy he should
> be shot.
>  
>             Release                 EOL
>  Fedora  8  2007-11-10      2008-12-25?
>  Fedora  9  2008-05-13      2008-06-XX 
                             ^^^^ 2009-06-XX? I hope. :)


-sv

reviving Fedora Legacy

[Stephen John Smoogen]

On Tue, Oct 14, 2008 at 11:50 AM, seth vidal <skvidal(a)fedoraproject.org&gt; wrote:
>  On Tue, 2008-10-14 at 11:44 -0600, Stephen John Smoogen wrote:
> > I don't know who the idiot who wrote this is... but boy he should be shot.
> >
> >            Release                 EOL
> > Fedora  8  2007-11-10      2008-12-25?
> > Fedora  9  2008-05-13      2008-06-XX
>
>                              ^^^^ 2009-06-XX? I hope. :)
>  
Geez.. the guy who updated the original author really needs to be shot also.



-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

reviving Fedora Legacy

[Rich Megginson]

Stephen John Smoogen wrote:
>  On Tue, Oct 14, 2008 at 11:50 AM, seth vidal
> <skvidal(a)fedoraproject.org&gt; wrote:
>    
> > On Tue, 2008-10-14 at 11:44 -0600, Stephen John Smoogen wrote:
> >     
> >> I don't know who the idiot who wrote this is... but boy he should be shot.
> >>
> >>            Release                 EOL
> >> Fedora  8  2007-11-10      2008-12-25?
> >> Fedora  9  2008-05-13      2008-06-XX
> >>       
> >                             ^^^^ 2009-06-XX? I hope. :)
> >
> >     
>
>  Geez.. the guy who updated the original author really needs to be shot also.
>     
The directors of the project enlisted to     
correct the dates after the other   
people had been sacked, wish it to     
be known that they have just been      
sacked.                                

The release and EOL dates have been completed        
in an entirely different style at great
effort and at the last minute.

reviving Fedora Legacy

[Ralph angenendt]

seth vidal wrote:
>  On Tue, 2008-10-14 at 11:44 -0600, Stephen John Smoogen wrote:
>  > I don't know who the idiot who wrote this is... but boy he should be shot.
>  > 
>  >            Release                 EOL
>  > Fedora  8  2007-11-10      2008-12-25?
>  > Fedora  9  2008-05-13      2008-06-XX
>  
>                               ^^^^ 2009-06-XX? I hope. :) 
Just shoot that idiot again =:D

Ralph

reviving Fedora Legacy

[Benny Amorsen]

"Horst H. von Brand" <vonbrand(a)inf.utfsm.cl&gt; writes:

>  Currently you have *6 months* to move over to the next Fedora...
Sure, and in the vast majority of cases I make it on time. It's just
for a few not so important services.

> > It wouldn't be good for anything too serious, 
>  I.e., completely useless. 
Useless for you, not for me.

> >                                               but if noone steps
> up
> > for a necessary security patch, I could do it myself
>
>  Sorry, I very much doubt that. 
You doubt that I could? I'd generally just rebuild the SRPM from a
newer release or from CentOS. It's not particularly hard, even for me.

> > and then get to share the result with everyone else on that
> > obsolete release. I would have to test all updates locally, but for
> > services on the way out that is generally easier than testing the
> > full upgrade. 
>  It is even easier to migrate to CentOS and keep going with that
> one... the
>  difference is that the bumps in the road are much bigger, but you have a
>  couple of years to migrate your stuff. 
It is in fact quite difficult to migrate to CentOS, unless your timing
is very lucky. CentOS and RHEL live in the past most of the time. If
you need a newer kernel feature, you end up running RHEL+custom
kernel, and even running your very own mini-distro is better than
that.

> > If it breaks something for someone, well, they should be more
> careful
> > which updates they apply, especially once official support is gone. It
> > might even encourage an upgrade and perhaps keep one box from being
> > compromised.
>
>  How is that less work in the longer run than just keep upgrading or moving
>  to some LTS distribution? 
In the longer run the server gets shut down. If the service is to be
kept alive for more than perhaps a year, upgrading or moving to some
LTS distribution are indeed the only options.


/Benny

reviving Fedora Legacy

[Jef Spaleta]

On Sun, Oct 12, 2008 at 5:40 PM, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
>  Why would we want to? Just let things going as long as there is at
> least one
>  maintainer committing something. Even if not all security issues get fixed,
>  it's better than if none gets fixed. 

Ha!  Keeping a branch open because one maintainer interested in
something.  That's not a distribution. That's a personal respository.

-jef

reviving Fedora Legacy

[Patrice Dumas]

On Mon, Oct 13, 2008 at 08:25:38AM -0800, Jeff Spaleta wrote:
>  On Sun, Oct 12, 2008 at 5:40 PM, Kevin Kofler
> <kevin.kofler(a)chello.at&gt; wrote:
>  > Why would we want to? Just let things going as long as there is at least one
>  > maintainer committing something. Even if not all security issues get fixed,
>  > it's better than if none gets fixed.
>  
>  
>  Ha!  Keeping a branch open because one maintainer interested in
>  something.  That's not a distribution. That's a personal respository. 
If it turns out that no community agregates around that idea and it is
indeed a personnal repository it should be stopped, but you cannot know
if you don't try.

--
Pat

reviving Fedora Legacy

[Ralf Corsepius]

On Mon, 2008-10-13 at 08:25 -0800, Jeff Spaleta wrote:
>  On Sun, Oct 12, 2008 at 5:40 PM, Kevin Kofler
> <kevin.kofler(a)chello.at&gt; wrote:
>  > Why would we want to? Just let things going as long as there is at least one
>  > maintainer committing something. Even if not all security issues get fixed,
>  > it's better than if none gets fixed.
>  
>  
>  Ha!  Keeping a branch open because one maintainer interested in
>  something.  That's not a distribution. That's a personal respository.
Nonsense - Such a strategy would not be any different from how Fedora
works now.

Ralf

reviving Fedora Legacy

[Bill Nottingham]

Kevin Kofler (kevin.kofler(a)chello.at) said: 
>  Why would we want to? Just let things going as long as there is at
> least one 
>  maintainer committing something. Even if not all security issues get fixed, 
>  it's better than if none gets fixed. 
Hi! We've got this great new thing for you! 

Do you like your current Fedora release?

Do you not want to upgrade?

Well, then here we go - we'll support it for you! [*]

[*] Not guaranteed to prevent any or all security attacks [**]
[**] Not all packages to receive security fixes [***]
[***] Maintenance guaranteed for a completely indeterminate period of time [****]
[****] Maintenance can be taken away at any time

Tell me again... what sort of people are you trying to serve with this? In what
way does this serve them better than RHEL or CentOS?

Bill

reviving Fedora Legacy

[Patrice Dumas]

On Mon, Oct 13, 2008 at 03:21:04PM -0400, Bill Nottingham wrote:
>  
>  [*] Not guaranteed to prevent any or all security attacks [**]
>  [**] Not all packages to receive security fixes [***]
>  [***] Maintenance guaranteed for a completely indeterminate period of time [****]
>  [****] Maintenance can be taken away at any time 
Can you guarantee that for any fedora release. No. There is the same
level of guarantee, at least at the package level since there are only
volunteers. Of course there is a community and an enterprise behind
fedora proper so there can be a good confidence that the most important
parts of the distro will be maintained, but there is nothing binding.

>  Tell me again... what sort of people are you trying to serve with
> this? In what
>  way does this serve them better than RHEL or CentOS? 
This has been answered many times. It is not the same to have some more
time of fedora than to install directly a Centos/RHEL, and upgrading to
Centos/RHEL is not always possible.

--
Pat

reviving Fedora Legacy

[Bill Nottingham]

Patrice Dumas (pertusus(a)free.fr) said: 
>  > [*] Not guaranteed to prevent any or all security attacks [**]
>  > [**] Not all packages to receive security fixes [***]
>  > [***] Maintenance guaranteed for a completely indeterminate period of time [****]
>  > [****] Maintenance can be taken away at any time
>  
>  Can you guarantee that for any fedora release. 

Yes. There's the defined release lifespan; anything of consequence
will be maintained for that period.

>  > Tell me again... what sort of people are you trying to serve
> with this? In what
>  > way does this serve them better than RHEL or CentOS?
>  
>  This has been answered many times. It is not the same to have some more
>  time of fedora than to install directly a Centos/RHEL, and upgrading to
>  Centos/RHEL is not always possible. 
Neither is upgrading from TurboGears to Ruby on Rails and having your app
work. If you started off by choosing the wrong tool, why would you expect
an upgrade to something different to work? 

Bill

reviving Fedora Legacy

[Patrice Dumas]

On Mon, Oct 13, 2008 at 04:00:47PM -0400, Bill Nottingham wrote:
>  
>  Yes. There's the defined release lifespan; anything of consequence
>  will be maintained for that period. 
You can say that but cannot give any guarantee.

>  Neither is upgrading from TurboGears to Ruby on Rails and having your
> app
>  work. If you started off by choosing the wrong tool, why would you expect
>  an upgrade to something different to work?  
I know about users for which Centos/RHEL is not right because it is too
old, fedora would suit them, if they had not to upgrade after one year.
Currently I have to propose them to install ubuntu, because there is
nothing in the fedora/RHEL market that suits them. Not enough power user
for fedora updates every year, need too recent stuff for RHEL. Another
category who be those who want to use a controlled set of next
technology preview in production environment and are willing to do some
testing and help with bugs, hence would have choosen fedora, but cannot
if they have to update each year.

--
Pat

reviving Fedora Legacy

[Bill Nottingham]

Patrice Dumas (pertusus(a)free.fr) said: 
>  > Yes. There's the defined release lifespan; anything of
> consequence
>  > will be maintained for that period.
>  
>  You can say that but cannot give any guarantee. 
On the contrary. The Fedora project provides maintenance of the release
for the release period. You're guaranteeing ... nothing.

>  > Neither is upgrading from TurboGears to Ruby on Rails and having
> your app
>  > work. If you started off by choosing the wrong tool, why would you expect
>  > an upgrade to something different to work? 
>  
>  I know about users for which Centos/RHEL is not right because it is too
>  old, 
... but then later want a longer term of support, up to 3-5 years, during
which... their OS will be old. Just as old as an equivalent RHEL/CentOS,
in fact.

>  technology preview in production environment and are willing to do
> some
>  testing and help with bugs, hence would have choosen fedora, but cannot
>  if they have to update each year. 
I'm beginning to wonder if this isn't a straw horse that's being beaten to
death.

Fedora 8's been out less a year. It has, in that timeframe, received *over
4600 updates*. Fedora 9 has received over 2600 in its current lifetime.

How is upgrading to the next release really that many orders of magnitude
more change than this?

After all, if you're on F9 you've already consumed a KDE-4.0 to KDE-4.1
update, for example. Or kernel updates from 2.6.25 through to 2.6.27.
Or NetworkManager updates to the current version. Or ... <insert
changes here>...

Bill

reviving Fedora Legacy

[Paul W. Frields]

On Mon, 2008-10-13 at 16:49 -0400, Bill Nottingham wrote:
>  Patrice Dumas (pertusus(a)free.fr) said: 
>  > > Yes. There's the defined release lifespan; anything of consequence
>  > > will be maintained for that period.
>  > 
>  > You can say that but cannot give any guarantee.
>  
>  On the contrary. The Fedora project provides maintenance of the release
>  for the release period. You're guaranteeing ... nothing.
>  
>  > > Neither is upgrading from TurboGears to Ruby on Rails and having your app
>  > > work. If you started off by choosing the wrong tool, why would you expect
>  > > an upgrade to something different to work? 
>  > 
>  > I know about users for which Centos/RHEL is not right because it is too
>  > old,
>  
>  ... but then later want a longer term of support, up to 3-5 years, during
>  which... their OS will be old. Just as old as an equivalent RHEL/CentOS,
>  in fact.
>  
>  > technology preview in production environment and are willing to do some
>  > testing and help with bugs, hence would have choosen fedora, but cannot
>  > if they have to update each year.
>  
>  I'm beginning to wonder if this isn't a straw horse that's being beaten to
>  death.
>  
>  Fedora 8's been out less a year. It has, in that timeframe, received *over
>  4600 updates*. Fedora 9 has received over 2600 in its current lifetime.
>  
>  How is upgrading to the next release really that many orders of magnitude
>  more change than this?
>  
>  After all, if you're on F9 you've already consumed a KDE-4.0 to KDE-4.1
>  update, for example. Or kernel updates from 2.6.25 through to 2.6.27.
>  Or NetworkManager updates to the current version. Or ... <insert
>  changes here>... 
The expectations people will undoubtedly have from this sort of extended
release maintenance will be completely out of line with what's provided.
How can you provide security updates for some of a distribution and have
it be meaningful?  What does it matter if you patch a problem in a user
application and not those in the kernel?  And how do you reconcile that
disparity with the expectations of the user of this supposedly
maintained branch, who thinks that somehow they're doing better
security-wise than if they move to a platform actively maintained by a
community, be it a current Fedora, RHEL, or CentOS?

-- 
Paul W. Frields
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://paul.frields.org/   -  -   http://pfrields.fedorapeople.org/
  irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug

reviving Fedora Legacy

[Patrice Dumas]

On Mon, Oct 13, 2008 at 09:14:42PM +0000, Paul W. Frields wrote:
>  
>  The expectations people will undoubtedly have from this sort of extended
>  release maintenance will be completely out of line with what's provided.
>  How can you provide security updates for some of a distribution and have
>  it be meaningful?  What does it matter if you patch a problem in a user
>  application and not those in the kernel?  And how do you reconcile that
>  disparity with the expectations of the user of this supposedly
>  maintained branch, who thinks that somehow they're doing better
>  security-wise than if they move to a platform actively maintained by a
>  community, be it a current Fedora, RHEL, or CentOS? 
I cannot do anything if people don't read the pages explaining what the
project offers. Did I said something about 'doing better
security-wise than if they move to a platform actively maintained by a
community, be it a current Fedora, RHEL, or CentOS'. No.

--
Pat

reviving Fedora Legacy

[Patrice Dumas]

On Mon, Oct 13, 2008 at 04:49:19PM -0400, Bill Nottingham wrote:
>  
>  On the contrary. The Fedora project provides maintenance of the release
>  for the release period. You're guaranteeing ... nothing. 
It provides maintainance, but cannot guarantee anytihng. The idea is to 
provide maintainance for the packages people are interested in providing 
maintainance.

>  ... but then later want a longer term of support, up to 3-5 years,
> during
>  which... their OS will be old. Just as old as an equivalent RHEL/CentOS,
>  in fact. 
Not at all. Centos starts already old, it is very different.

>  I'm beginning to wonder if this isn't a straw horse
> that's being beaten to
>  death.
>  
>  Fedora 8's been out less a year. It has, in that timeframe, received *over
>  4600 updates*. Fedora 9 has received over 2600 in its current lifetime.
>  
>  How is upgrading to the next release really that many orders of magnitude
>  more change than this? 
It is very different because the updates are not fundamental changes,
like those that happens between releases. You know that, don't you,
those changes that goes through rawhide.

>  After all, if you're on F9 you've already consumed a KDE-4.0
> to KDE-4.1
>  update, for example. Or kernel updates from 2.6.25 through to 2.6.27.
>  Or NetworkManager updates to the current version. Or ... <insert
>  changes here>... 
Sure, but not the big changes that goes between version. I am sure you
know what I am speaking about.

--
Pat

reviving Fedora Legacy

[Bill Nottingham]

Patrice Dumas (pertusus(a)free.fr) said: 
>  > On the contrary. The Fedora project provides maintenance of the
> release
>  > for the release period. You're guaranteeing ... nothing.
>  
>  It provides maintainance, but cannot guarantee anytihng. 
Be realistic. If we didn't de-facto guarantee that we'd provide security
updates during the specified lifespan for all relevant packages, we woudn't
have a viable distribution.

>  The idea is to 
>  provide maintainance for the packages people are interested in providing 
>  maintainance. 
I know exactly what you're proposing, you don't need to restate it. I just
think it's a fundamentally bad idea that actively harms users by giving
them an open-ended rope to hang themselves with, which doesn't at all claim
to cover their entire system, as opposed to the clear support and
maintenance they have now.

To put it a different way - would you buy a car whose extended warranty
won't tell you what it covers, or for how long, and tells you it's subject
to change *AT ANY TIME*? If so, I think I've got some cars to sell you.

You want me to support your plan? Cover the entire distribution, for a
specified period of time. Simple, right?

>  > ... but then later want a longer term of support, up to 3-5
> years, during
>  > which... their OS will be old. Just as old as an equivalent RHEL/CentOS,
>  > in fact.
>  
>  Not at all. Centos starts already old, it is very different. 
How so? When Centos 5/RHEL 5 is released, it's pretty much up to date, or
at least within 6 months. If you're looking for a 3-5 year lifespan (which
you said your goal is), that's nothing. And halfway or so through your
proposed arrangement, your release would be just as old and outdated
as an equivalent RHEL release of the same vintage.

>  > How is upgrading to the next release really that many orders of
> magnitude
>  > more change than this?
>  
>  It is very different because the updates are not fundamental changes,
>  like those that happens between releases. You know that, don't you,
>  those changes that goes through rawhide. 
... how so? There's a ton of changes between kernel-2.6.25 and kernel-2.6.27.
KDE-4.1 is a fairly big step from KDE-4.0. The entirety of system
network configuration support was added between F8 GA NetworkManager
and the F8 updates version.

Is it *all* of the large changes? No. But it's more than you'd think.
Moreover, exactly which of these big changes break people? Is
rhgb -> plymouth a big change? Sure. Does it actively break third-party
applications or development? No.

Honestly, I think a whole lot more of the work here is best done:
- promoting RHEL/CentOS as the alternative for users who need longer support
- making distribution upgrades seamless and easy

Bill

reviving Fedora Legacy

[Matthew Woehlke]

Bill Nottingham wrote:
>  To put it a different way - would you buy a car whose extended
> warranty
>  won't tell you what it covers, or for how long, and tells you it's subject
>  to change *AT ANY TIME*? If so, I think I've got some cars to sell you. 
Have you ever bought a used car?

People drive cars not under warranty because they know that, if 
something goes wrong, they can either fix it themselves (for those who 
are hobby mechanics) or pay someone to fix it. The same goes for a 
distro; if you need an update and there is no support, you can always 
build it yourself or pay someone to build it for you (which is, after 
all, sort of the point of Free Software).

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"NT was a marketing name that stood for New Technology, but it was still 
an amusing coincidence that WNT was VMS with each letter replaced by the 
next one."
   -- Jeremy Reimer

reviving Fedora Legacy

[Josh Boyer]

On Mon, Oct 13, 2008 at 07:44:17PM -0500, Matthew Woehlke wrote:
>  Bill Nottingham wrote:
> > To put it a different way - would you buy a car whose extended warranty
> > won't tell you what it covers, or for how long, and tells you it's subject
> > to change *AT ANY TIME*? If so, I think I've got some cars to sell you.
>
>  Have you ever bought a used car?
>
>  People drive cars not under warranty because they know that, if  
>  something goes wrong, they can either fix it themselves (for those who  
>  are hobby mechanics) or pay someone to fix it. The same goes for a  
>  distro; if you need an update and there is no support, you can always  
>  build it yourself or pay someone to build it for you (which is, after  
>  all, sort of the point of Free Software). 
Thank you for providing the analogy that proves the Fedora project
(the car dealership here) does not need to provide an LTS because the
consumers (the Fedora users) can fix things themselves.

josh

reviving Fedora Legacy

[Chuck Anderson]

On Mon, Oct 13, 2008 at 08:51:13PM -0400, Josh Boyer wrote:
>  On Mon, Oct 13, 2008 at 07:44:17PM -0500, Matthew Woehlke wrote:
>  > Bill Nottingham wrote:
>  >> To put it a different way - would you buy a car whose extended warranty
>  >> won't tell you what it covers, or for how long, and tells you it's
> subject
>  >> to change *AT ANY TIME*? If so, I think I've got some cars to sell you.
>  >
>  > Have you ever bought a used car?
>  >
>  > People drive cars not under warranty because they know that, if  
>  > something goes wrong, they can either fix it themselves (for those who  
>  > are hobby mechanics) or pay someone to fix it. The same goes for a  
>  > distro; if you need an update and there is no support, you can always  
>  > build it yourself or pay someone to build it for you (which is, after  
>  > all, sort of the point of Free Software).
>  
>  Thank you for providing the analogy that proves the Fedora project
>  (the car dealership here) does not need to provide an LTS because the
>  consumers (the Fedora users) can fix things themselves. 
And why shouldn't the Fedora project provide a place for the consumers 
who fixed things themselves to share with those who can't fix things?

reviving Fedora Legacy

[Ralf Corsepius]

On Mon, 2008-10-13 at 21:17 -0400, Chuck Anderson wrote:
>  On Mon, Oct 13, 2008 at 08:51:13PM -0400, Josh Boyer wrote:
>  > On Mon, Oct 13, 2008 at 07:44:17PM -0500, Matthew Woehlke wrote:
>  > > Bill Nottingham wrote:
>  > >> To put it a different way - would you buy a car whose extended warranty
>  > >> won't tell you what it covers, or for how long, and tells you it's
> subject
>  > >> to change *AT ANY TIME*? If so, I think I've got some cars to sell
> you.
>  > >
>  > > Have you ever bought a used car?
>  > >
>  > > People drive cars not under warranty because they know that, if  
>  > > something goes wrong, they can either fix it themselves (for those who  
>  > > are hobby mechanics) or pay someone to fix it. The same goes for a  
>  > > distro; if you need an update and there is no support, you can always  
>  > > build it yourself or pay someone to build it for you (which is, after  
>  > > all, sort of the point of Free Software).
>  > 
>  > Thank you for providing the analogy that proves the Fedora project
>  > (the car dealership here) does not need to provide an LTS because the
>  > consumers (the Fedora users) can fix things themselves.
>  
>  And why shouldn't the Fedora project provide a place for the consumers 
>  who fixed things themselves to share with those who can't fix things? 
Exactly! Wasn't this the original idea behind Fedora?

Ralf

reviving Fedora Legacy

[Jeffrey Ollie]

On Mon, Oct 13, 2008 at 10:46 PM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
> >
> > And why shouldn't the Fedora project provide a place for the consumers
> > who fixed things themselves to share with those who can't fix things?
>
>  Exactly! Wasn't this the original idea behind Fedora? 
While my memory isn't the best (and my google-fu fails me), I'm pretty
sure that Fedora was never meant to be a free-for-all.

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"

reviving Fedora Legacy

[Ralf Corsepius]

On Mon, 2008-10-13 at 23:22 -0500, Jeffrey Ollie wrote:
>  On Mon, Oct 13, 2008 at 10:46 PM, Ralf Corsepius
> <rc040203(a)freenet.de&gt; wrote:
>  >>
>  >> And why shouldn't the Fedora project provide a place for the consumers
>  >> who fixed things themselves to share with those who can't fix things?
>  >
>  > Exactly! Wasn't this the original idea behind Fedora?
>  
>  While my memory isn't the best (and my google-fu fails me), I'm pretty
>  sure that Fedora was never meant to be a free-for-all. 
FE was meant to be an "integration forum" to "bundle" various
external
repos. This was never meant to be free-for-all.

Ralf

reviving Fedora Legacy

[Bill Nottingham]

Matthew Woehlke (mw_triad(a)users.sourceforge.net) said: 
>  Bill Nottingham wrote:
> > To put it a different way - would you buy a car whose extended warranty
> > won't tell you what it covers, or for how long, and tells you it's subject
> > to change *AT ANY TIME*? If so, I think I've got some cars to sell you.
>
>  Have you ever bought a used car?
>
>  People drive cars not under warranty because they know that, if  
>  something goes wrong, they can either fix it themselves (for those who  
>  are hobby mechanics) or pay someone to fix it. The same goes for a  
>  distro; if you need an update and there is no support, you can always  
>  build it yourself or pay someone to build it for you (which is, after  
>  all, sort of the point of Free Software). 
Right, that's what we have now. What he's suggesting is some sort
of 'other' warranty that can expire at any time, and which packages/
parts of the car are covered can change at any time. I know of *no one*
who gets that sort of warranty.

Bill

reviving Fedora Legacy

[Matthew Woehlke]

Bill Nottingham wrote:
>  Matthew Woehlke (mw_triad(a)users.sourceforge.net) said: 
> > Bill Nottingham wrote:
> >> To put it a different way - would you buy a car whose extended warranty
> >> won't tell you what it covers, or for how long, and tells you it's
> subject
> >> to change *AT ANY TIME*? If so, I think I've got some cars to sell you.
> > Have you ever bought a used car?
> >
> > People drive cars not under warranty because they know that, if  
> > something goes wrong, they can either fix it themselves (for those who  
> > are hobby mechanics) or pay someone to fix it. The same goes for a  
> > distro; if you need an update and there is no support, you can always  
> > build it yourself or pay someone to build it for you (which is, after  
> > all, sort of the point of Free Software).
>  
>  Right, that's what we have now. What he's suggesting is some sort
>  of 'other' warranty that can expire at any time, and which packages/
>  parts of the car are covered can change at any time. I know of *no one*
>  who gets that sort of warranty. 
Well, if it were free, I might... well, I can't say I'd buy it, because 
I'm not buying anything :-). I'll let all y'all argue amongst yourselves 
if that's better or worse than nothing.

However... your original analogy didn't ask if I'd buy a /warranty/, it 
asked if I'd buy a /car/.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Oh, the double-entendre!

reviving Fedora Legacy

[Patrice Dumas]

On Mon, Oct 13, 2008 at 08:36:50PM -0400, Bill Nottingham wrote:
>  Patrice Dumas (pertusus(a)free.fr) said: 
>  > > On the contrary. The Fedora project provides maintenance of the release
>  > > for the release period. You're guaranteeing ... nothing.
>  > 
>  > It provides maintainance, but cannot guarantee anytihng.
>  
>  Be realistic. If we didn't de-facto guarantee that we'd provide security
>  updates during the specified lifespan for all relevant packages, we woudn't
>  have a viable distribution. 
Sure. I exactly the same in response to your first mail. There is a
de-facto guarantee, but nothing substantial to fedora. And specific
packages can go unmaintained, important bugs can be unfixed and so on...

>  > The idea is to 
>  > provide maintainance for the packages people are interested in providing 
>  > maintainance.
>  
>  I know exactly what you're proposing, you don't need to restate it. I just
>  think it's a fundamentally bad idea that actively harms users by giving
>  them an open-ended rope to hang themselves with, which doesn't at all claim
>  to cover their entire system, as opposed to the clear support and
>  maintenance they have now. 
If it is clearly communicated, and requires manual steps to set up, with
a clear comunication (well as clear as possible) I can't see where is
the issue.

>  To put it a different way - would you buy a car whose extended
> warranty
>  won't tell you what it covers, or for how long, and tells you it's subject
>  to change *AT ANY TIME*? If so, I think I've got some cars to sell you. 
Once again fedora cannot make that claim either.

>  You want me to support your plan? Cover the entire distribution, for
> a
>  specified period of time. Simple, right? 
Unneeded and impossible (at least in the short term). First there is no
point in covering the parts that are not central to the distribution.
And then covering parts is much better than covering nothing. And I
recall you that the plan is to see how many people are interested before
doing anything publicly.

>  > > ... but then later want a longer term of support, up to 3-5
> years, during
>  > > which... their OS will be old. Just as old as an equivalent RHEL/CentOS,
>  > > in fact.
>  > 
>  > Not at all. Centos starts already old, it is very different.
>  
>  How so? When Centos 5/RHEL 5 is released, it's pretty much up to date, or
>  at least within 6 months. If you're looking for a 3-5 year lifespan (which
>  you said your goal is), that's nothing. And halfway or so through your
>  proposed arrangement, your release would be just as old and outdated
>  as an equivalent RHEL release of the same vintage. 
Of course, but it would have started from something recent. And if you
begin at any other time than time of a RHEL release which doesn't happen
very often, there is absolutely nothing for you.

>  > It is very different because the updates are not fundamental
> changes,
>  > like those that happens between releases. You know that, don't you,
>  > those changes that goes through rawhide.
>  
>  ... how so? There's a ton of changes between kernel-2.6.25 and kernel-2.6.27.
>  KDE-4.1 is a fairly big step from KDE-4.0. The entirety of system
>  network configuration support was added between F8 GA NetworkManager
>  and the F8 updates version.
>  
>  Is it *all* of the large changes? No. But it's more than you'd think.
>  Moreover, exactly which of these big changes break people? Is
>  rhgb -> plymouth a big change? Sure. Does it actively break third-party
>  applications or development? No. 
That's exactly the point. The changes in stable release break less than
between releases. I really can't see why you can't agree to that with
your level of knowledge of th edistro.

>  Honestly, I think a whole lot more of the work here is best done:
>  - promoting RHEL/CentOS as the alternative for users who need longer support
>  - making distribution upgrades seamless and easy 
It isn't exclusive. But it isn't the same and doesn't solve the same use
cases. I am already personally very involved in EPEL (all my packages
are in EPEL since long), and I can't see what I can do for distribution
upgrades to be seamless and easy, except for my own packages (and those
I co-maintain).

--
Pat

reviving Fedora Legacy

[Benny Amorsen]

Bill Nottingham <notting(a)redhat.com&gt; writes:

>  Fedora 8's been out less a year. It has, in that timeframe,
> received *over
>  4600 updates*. Fedora 9 has received over 2600 in its current lifetime.
>
>  How is upgrading to the next release really that many orders of magnitude
>  more change than this? 
The largest difference is that upgrading to the next release is almost
an all-or-nothing thing. Incremental upgrades during the release
generally affect just one package at a time, so testing is relatively
easy. When you upgrade the whole distribution you change openssl
version, and that basically means upgrading everything that could in
any way cause trouble, all at once. It is far from impossible, I do it
all the time, but it does need a lot more care.

Once OpenSSL gets banished this pain will subside a bit, but it will
probably never go away. Back in the "good" old days it was libc
causing that problem, but the developers of glibc have done an
excellent job of keeping compatibility for many years now.


/Benny

reviving Fedora Legacy

[Horst H. von Brand]

Benny Amorsen <benny+usenet(a)amorsen.dk&gt; wrote:
>  Bill Nottingham <notting(a)redhat.com&gt; writes:
>  > Fedora 8's been out less a year. It has, in that timeframe, received *over
>  > 4600 updates*. Fedora 9 has received over 2600 in its current lifetime.
>  >
>  > How is upgrading to the next release really that many orders of magnitude
>  > more change than this? 
>  The largest difference is that upgrading to the next release is
> almost
>  an all-or-nothing thing. Incremental upgrades during the release
>  generally 
  ---------
      |
      +--- But by no means always...

>            affect just one package at a time, so testing is
> relatively
>  easy. When you upgrade the whole distribution you change openssl
>  version, and that basically means upgrading everything that could in
>  any way cause trouble, all at once. 
Exactly like when OpenSSL is upgraded mid-life of the distribution. And
"just rebuild the new stuff over the old distribution" will probably break
badly when this happens too.

>                                      It is far from impossible, I do
> it
>  all the time, but it does need a lot more care. 
Care that could better be spent on the /new/ release.

>  Once OpenSSL gets banished this pain will subside a bit, but it will
>  probably never go away. 
/That/ pain might dissapear, others are sure around...

>                          Back in the "good" old days it was
> libc
>  causing that problem, but the developers of glibc have done an
>  excellent job of keeping compatibility for many years now. 
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

reviving Fedora Legacy

[Benny Amorsen]

ons, 15 10 2008 kl. 17:27 -0300, skrev Horst H. von Brand:

>  Exactly like when OpenSSL is upgraded mid-life of the distribution.
> And
>  "just rebuild the new stuff over the old distribution" will probably break
>  badly when this happens too. 
I don't remember OpenSSL getting an incompatible upgrade during mid-life
Fedora. I'm fairly sure I would have noticed. Has it happened?


/Benny

reviving Fedora Legacy

[Chris Weyl]

On Mon, Oct 13, 2008 at 1:22 PM, Patrice Dumas <pertusus(a)free.fr&gt; wrote:
>  On Mon, Oct 13, 2008 at 04:00:47PM -0400, Bill Nottingham wrote:
>
>  > Neither is upgrading from TurboGears to Ruby on Rails and having your app
>  > work. If you started off by choosing the wrong tool, why would you expect
>  > an upgrade to something different to work?
>
>  I know about users for which Centos/RHEL is not right because it is too
>  old, fedora would suit them, if they had not to upgrade after one year.
>  Currently I have to propose them to install ubuntu, because there is
>  nothing in the fedora/RHEL market that suits them. Not enough power user
>  for fedora updates every year, need too recent stuff for RHEL. Another
>  category who be those who want to use a controlled set of next
>  technology preview in production environment and are willing to do some
>  testing and help with bugs, hence would have choosen fedora, but cannot
>  if they have to update each year. 
On this point, I know I tend to be pretty liberal with my personal
machines (and tend to keep them at the latest !rawhide), but for my
work laptop, while I run Fedora for a variety of reasons, I tend to be
pretty conservative and upgrade to the latest only when forced to by
distro EOL or some other compelling reason.  A LTS plan would make
sense for reasonable situations like this.

                                                  -Chris
--
Chris Weyl
Ex astris, scientia

reviving Fedora Legacy

[Josh Boyer]

On Mon, Oct 13, 2008 at 02:17:01PM -0700, Chris Weyl wrote:
> > I know about users for which Centos/RHEL is not right because it
> is too
> > old, fedora would suit them, if they had not to upgrade after one year.
> > Currently I have to propose them to install ubuntu, because there is
> > nothing in the fedora/RHEL market that suits them. Not enough power user
> > for fedora updates every year, need too recent stuff for RHEL. Another
> > category who be those who want to use a controlled set of next
> > technology preview in production environment and are willing to do some
> > testing and help with bugs, hence would have choosen fedora, but cannot
> > if they have to update each year.
>
> On this point, I know I tend to be pretty liberal with my personal
> machines (and tend to keep them at the latest !rawhide), but for my
> work laptop, while I run Fedora for a variety of reasons, I tend to be
> pretty conservative and upgrade to the latest only when forced to by
> distro EOL or some other compelling reason.  A LTS plan would make
> sense for reasonable situations like this. 
No, it wouldn't.

(I know you know that I know what you know so you should know what
I know and I know there are other options and I know that you know
that.)

josh

reviving Fedora Legacy

[Chris Weyl]

On Mon, Oct 13, 2008 at 5:47 PM, Josh Boyer <jwboyer(a)gmail.com&gt; wrote:
>  On Mon, Oct 13, 2008 at 02:17:01PM -0700, Chris Weyl wrote:
> >> I know about users for which Centos/RHEL is not right because it is too
> >> old, fedora would suit them, if they had not to upgrade after one year.
> >> Currently I have to propose them to install ubuntu, because there is
> >> nothing in the fedora/RHEL market that suits them. Not enough power user
> >> for fedora updates every year, need too recent stuff for RHEL. Another
> >> category who be those who want to use a controlled set of next
> >> technology preview in production environment and are willing to do some
> >> testing and help with bugs, hence would have choosen fedora, but cannot
> >> if they have to update each year.
> >
> >On this point, I know I tend to be pretty liberal with my personal
> >machines (and tend to keep them at the latest !rawhide), but for my
> >work laptop, while I run Fedora for a variety of reasons, I tend to be
> >pretty conservative and upgrade to the latest only when forced to by
> >distro EOL or some other compelling reason.  A LTS plan would make
> >sense for reasonable situations like this.
>
>  No, it wouldn't.
>
>  (I know you know that I know what you know so you should know what
>  I know and I know there are other options and I know that you know
>  that.) 
I know :)  But, along those lines you know it's not that clear cut... ya know?

But this isn't really about other options, whether they be centos/rhel
or ubuntu/debian or slackware or gentoo, this is about people who
choose to use Fedora.  What does it say about freedom, when we say
"Use Fedora and be free! ...except, you know, how you want to."  Why
are we spending so much time and effort saying no, instead of getting
out of the way of those who are interested in doing it and watching it
succeed or fail on its merits?

                                  -Chris
-- 
Chris Weyl
Ex astris, scientia

reviving Fedora Legacy

[Jeffrey Ollie]

On Mon, Oct 13, 2008 at 9:39 PM, Chris Weyl <cweyl(a)alumni.drew.edu&gt; wrote:
>  What does it say about freedom, when we say
>  "Use Fedora and be free! ...except, you know, how you want to."  Why
>  are we spending so much time and effort saying no, instead of getting
>  out of the way of those who are interested in doing it and watching it
>  succeed or fail on its merits? 
"We" are saying no because "they" want "us" to do something,
rather
than doing it themselves.  All of the software that goes into
producing Fedora is free (in both the Beer and Speech senses).  What
*isn't* free is the infrastructure that goes into producing Fedora
releases (the power/cooling/bandwidth/hardware as well as the time of
the various employees and volunteers).   *I* think that Red Hat has
been extremely generous in letting us use that infrastructure to build
a cool distribution like Fedora.

But why should Red Hat (and those of us that believe in the current
Fedora mission) let that infrastructure and perhaps more importantly
the Fedora brand get used for some "Fedora LTS" project?  Based upon
the failure of the Fedora Legacy project and the most recent
discussion there are only a few people interested in volunteering
their time to such a project.  And from what I've seen in this latest
discussion the LTS project goals are either ill-defined or
overambitious or both.

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"

reviving Fedora Legacy

[Ralf Corsepius]

On Mon, 2008-10-13 at 23:37 -0500, Jeffrey Ollie wrote:
>  On Mon, Oct 13, 2008 at 9:39 PM, Chris Weyl
> <cweyl(a)alumni.drew.edu&gt; wrote:
>  >
>  > What does it say about freedom, when we say
>  > "Use Fedora and be free! ...except, you know, how you want to."  Why
>  > are we spending so much time and effort saying no, instead of getting
>  > out of the way of those who are interested in doing it and watching it
>  > succeed or fail on its merits?
>  
>  "We" are saying no because "they" want "us" to do
> something, rather
>  than doing it themselves.  All of the software that goes into
>  producing Fedora is free (in both the Beer and Speech senses).  What
>  *isn't* free is the infrastructure that goes into producing Fedora
>  releases (the power/cooling/bandwidth/hardware as well as the time of
>  the various employees and volunteers).   *I* think that Red Hat has
>  been extremely generous in letting us use that infrastructure to build
>  a cool distribution like Fedora. 
Well, it had been RH's deliberate decision to
do so.

/me thinks, they actually had no other choice at that time.

>  But why should Red Hat (and those of us that believe in the current
>  Fedora mission) let that infrastructure and perhaps more importantly
>  the Fedora brand get used for some "Fedora LTS" project? 
Marketing,
customer bonding, ... ?

>    Based upon
>  the failure of the Fedora Legacy project and the most recent
>  discussion there are only a few people interested in volunteering
>  their time to such a project.  And from what I've seen in this latest
>  discussion the LTS project goals are either ill-defined or
>  overambitious or both. 
Your opinion.

Ralf

reviving Fedora Legacy

[David Woodhouse]

On Tue, 2008-10-14 at 06:47 +0200, Ralf Corsepius wrote:
>  On Mon, 2008-10-13 at 23:37 -0500, Jeffrey Ollie wrote:
>  >   Based upon
>  > the failure of the Fedora Legacy project and the most recent
>  > discussion there are only a few people interested in volunteering
>  > their time to such a project.  And from what I've seen in this latest
>  > discussion the LTS project goals are either ill-defined or
>  > overambitious or both. 
>  Your opinion. 
Mine, too.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse(a)intel.com                              Intel Corporation

reviving Fedora Legacy

[Patrice Dumas]

On Mon, Oct 13, 2008 at 11:37:03PM -0500, Jeffrey Ollie wrote:
>  
>  "We" are saying no because "they" want "us" to do
> something, rather
>  than doing it themselves.  All of the software that goes into
>  producing Fedora is free (in both the Beer and Speech senses).  What
>  *isn't* free is the infrastructure that goes into producing Fedora
>  releases (the power/cooling/bandwidth/hardware as well as the time of
>  the various employees and volunteers).   *I* think that Red Hat has
>  been extremely generous in letting us use that infrastructure to build
>  a cool distribution like Fedora. 
If it turns out that this project requires too much resources, as I
repeadly said, no problem not to do it. But currently I don't think it
requires much resources (and I may be wrong), since it profits from
scale economies and the fact that there isn't a full use of the
resources most of the time (on the builders).

>  But why should Red Hat (and those of us that believe in the current
>  Fedora mission) let that infrastructure and perhaps more importantly
>  the Fedora brand get used for some "Fedora LTS" project?  Based upon 
The fedora brand wouldn't be involved, at least until the project has
proven to be succesful.

>  the failure of the Fedora Legacy project and the most recent 
It was under different conditions, but I'm becoming to be tired of
reexplaining that. I made that point in at least 2 mails if not 3...

>  discussion there are only a few people interested in volunteering
>  their time to such a project.  And from what I've seen in this latest 
I'd say the rerverse. Very fine packagers like Kevin, Chris and Orion
seemed to be supportive (at least of the idea), and there were also
some users saying that they would love to see such a project happen. And
Jesse and Josh made very constructive comments. Sure there are also many
people that are against the idea, among those who count in fedora, but
it is definitly much better than the last attempt.

How many people started EPEL?

>  discussion the LTS project goals are either ill-defined or
>  overambitious or both. 
Reread Kevin proposition and my answers to Josh. At least it is not ill
defined (and there is still the UEAL proposal that can be a commplement)
as for overambition I don't really see what you mean here.

--
Pat

reviving Fedora Legacy

[Benny Amorsen]

"Jeffrey Ollie" <jeff(a)ocjtech.us&gt; writes:

>  And from what I've seen in this latest discussion the LTS
> project
>  goals are either ill-defined or overambitious or both. 
Most of the complaints have been about the goals being
underambitious. No ambition for a specific time frame, no ambition for
a specific package set, no ambition for a response guarantee for
security problems...


/Benny

reviving Fedora Legacy

[David Woodhouse]

On Mon, 2008-10-13 at 01:40 +0000, Kevin Kofler wrote:
>  Why would we want to? Just let things going as long as there is at
> least one 
>  maintainer committing something. Even if not all security issues get fixed, 
>  it's better than if none gets fixed. 
I disagree with that very strongly.

If we present the _appearance_ of a distro with security updates, while
in fact there are serious security issues being unfixed, then that is
_much_ worse than the current "That distro is EOL. Upgrade before you
get hacked" messaging.

For anything to have the Fedora name on it, it _must_ have guaranteed
security fixes for at least the highest priority issues.

(That's not a decree; I'm not in a position to make such. It's just
common sense.)

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse(a)intel.com                              Intel Corporation

reviving Fedora Legacy

[Patrice Dumas]

On Wed, Oct 15, 2008 at 08:36:05AM +0100, David Woodhouse wrote:
>  
>  If we present the _appearance_ of a distro with security updates, while
>  in fact there are serious security issues being unfixed, then that is
>  _much_ worse than the current "That distro is EOL. Upgrade before you
>  get hacked" messaging. 
The aim here is not to present the _appearance_ of a distro with
security updates but give the choice to the user either to upgrade or to
stick with a distro where some packages will not be maintained.
Something along "That distro is EOL. Upgrade before you get hacked.
Alternatively, and at your own risk, you can enable a repository where 
some packages are updated on a volunteer basis, but some packages aren't
maintained anymore."

With a page listing which packages are still supported.

--
Pat

reviving Fedora Legacy

[Josh Boyer]

On Wed, Oct 15, 2008 at 09:42:28AM +0200, Patrice Dumas wrote:
> On Wed, Oct 15, 2008 at 08:36:05AM +0100, David Woodhouse wrote:
> > 
> > If we present the _appearance_ of a distro with security updates, while
> > in fact there are serious security issues being unfixed, then that is
> > _much_ worse than the current "That distro is EOL. Upgrade before you
> > get hacked" messaging.
>
> The aim here is not to present the _appearance_ of a distro with
> security updates but give the choice to the user either to upgrade or to
> stick with a distro where some packages will not be maintained.
> Something along "That distro is EOL. Upgrade before you get hacked.
> Alternatively, and at your own risk, you can enable a repository where 
> some packages are updated on a volunteer basis, but some packages aren't
> maintained anymore."
>
> With a page listing which packages are still supported. 
The issue you will have is that people will not be comfortable opening the
ACLs for things like the kernel or glibc or gcc.  And if those ACLs are still
closed and the maintainers have no interest in participating in this "life
after EOL" scheme, then it's very hard to have any appearance of security.

josh

reviving Fedora Legacy

[Patrice Dumas]

On Wed, Oct 15, 2008 at 07:33:17AM -0400, Josh Boyer wrote:
>  >
>  >The aim here is not to present the _appearance_ of a distro with
>  >security updates but give the choice to the user either to upgrade or to
>  >stick with a distro where some packages will not be maintained.
>  >Something along "That distro is EOL. Upgrade before you get hacked.
>  >Alternatively, and at your own risk, you can enable a repository where 
>  >some packages are updated on a volunteer basis, but some packages aren't
>  >maintained anymore."
>  >
>  >With a page listing which packages are still supported.
>  
>  The issue you will have is that people will not be comfortable opening the
>  ACLs for things like the kernel or glibc or gcc.  And if those ACLs are still
>  closed and the maintainers have no interest in participating in this "life
>  after EOL" scheme, then it's very hard to have any appearance of security.
You mean, even for branches they don't maintain anymore? That would be
strange.

--
Pat

reviving Fedora Legacy

[Josh Boyer]

On Wed, Oct 15, 2008 at 02:13:50PM +0200, Patrice Dumas wrote:
> On Wed, Oct 15, 2008 at 07:33:17AM -0400, Josh Boyer wrote:
> > >
> > >The aim here is not to present the _appearance_ of a distro with
> > >security updates but give the choice to the user either to upgrade or to
> > >stick with a distro where some packages will not be maintained.
> > >Something along "That distro is EOL. Upgrade before you get hacked.
> > >Alternatively, and at your own risk, you can enable a repository where 
> > >some packages are updated on a volunteer basis, but some packages aren't
> > >maintained anymore."
> > >
> > >With a page listing which packages are still supported.
> > 
> > The issue you will have is that people will not be comfortable opening the
> > ACLs for things like the kernel or glibc or gcc.  And if those ACLs are still
> > closed and the maintainers have no interest in participating in this "life
> > after EOL" scheme, then it's very hard to have any appearance of security.
>
> You mean, even for branches they don't maintain anymore? That would be
> strange. 
No, it really wouldn't.  If the ACLs are open for the kernel on an older branch
anyone with cvsextras (or whatever the FAS group is now called) can commit to it.
That means anyone can fsck up the kernel and break all of those users on this
EOLed release.

(And bug reports, blah blah blah.)

josh

reviving Fedora Legacy

[Till Maas]

On Wed October 15 2008, Josh Boyer wrote:

>  (And bug reports, blah blah blah.) 
If the ACLs for the EOL releases are cleared, the maintainers of the supported 
packages will not get any bug reports (unless Bugzilla does not support this 
of course). Also the EOL-team can triage the bugs for the supported release 
to avoid bugging the maintainers.

Regards,
Till

reviving Fedora Legacy

[Toshio Kuratomi]

Till Maas wrote:
>  On Wed October 15 2008, Josh Boyer wrote:
>  
> > (And bug reports, blah blah blah.)
>  
>  If the ACLs for the EOL releases are cleared, the maintainers of the supported 
>  packages will not get any bug reports (unless Bugzilla does not support this 
>  of course). Also the EOL-team can triage the bugs for the supported release 
>  to avoid bugging the maintainers.
>   
I think we're stretching beyond bugzilla's capabilities but I'd be
happy
to be proved wrong :-)

I don't think bugzilla has separation of Product-versions so there's no
way to assign different people to Fedora-10 and Fedora-7.

Like Fedora Legacy we could have a separate Fedora Legacy/LTS Product...
but then, how do we guide people to use that Product when their machine
suddenly transitions from Fedora-Current-Release to Fedora-Legacy-Release?

-Toshio

reviving Fedora Legacy

[Till Maas]

On Wed October 15 2008, Toshio Kuratomi wrote:
>  Till Maas wrote:
>  > On Wed October 15 2008, Josh Boyer wrote:
>  >> (And bug reports, blah blah blah.)
>  >
>  > If the ACLs for the EOL releases are cleared, the maintainers of the
>  > supported packages will not get any bug reports (unless Bugzilla does not
>  > support this of course). Also the EOL-team can triage the bugs for the
>  > supported release to avoid bugging the maintainers.
>
>  I think we're stretching beyond bugzilla's capabilities but I'd be happy
>  to be proved wrong :-)
>
>  I don't think bugzilla has separation of Product-versions so there's no
>  way to assign different people to Fedora-10 and Fedora-7. 
I always feared this. In case this is true and initialCC cannot be configured 
differently for different Fedora versions, too, (which I assume is 
unrealistic if bugzilla cannot distinguish versions for assignees) imho the 
packageDB UI should reflect this.

Regards,
Till

reviving Fedora Legacy

[Patrice Dumas]

On Wed, Oct 15, 2008 at 09:37:57AM -0700, Toshio Kuratomi wrote:
>  > 
>  I think we're stretching beyond bugzilla's capabilities but I'd be happy
>  to be proved wrong :-)
>  
>  I don't think bugzilla has separation of Product-versions so there's no
>  way to assign different people to Fedora-10 and Fedora-7. 
That's annoying. Is it something we have to worry about in Fedora and
EPEL proper, that is, would we like to be able to separate owners for
different releases, or is it something we need to worry about only if
infrastructure is kept open for old branches?

>  Like Fedora Legacy we could have a separate Fedora Legacy/LTS
> Product...
>  but then, how do we guide people to use that Product when their machine
>  suddenly transitions from Fedora-Current-Release to Fedora-Legacy-Release? 
I don't think there should ever be a sudden and unnoticed transition. I
like what Jesse proposed with PackageKit for the long term, and in the
short term people would have to manually install a yum config file
(maybe part of a rpm, but manually).

--
Pat

reviving Fedora Legacy

[Patrice Dumas]

On Wed, Oct 15, 2008 at 08:43:48AM -0400, Josh Boyer wrote:
>  
>  No, it really wouldn't.  If the ACLs are open for the kernel on an older branch
>  anyone with cvsextras (or whatever the FAS group is now called) can commit to it.
>  That means anyone can fsck up the kernel and break all of those users on this
>  EOLed release. 
In the proposal the updated packages go to another repository, isn't
that enough? I honestly don't think that FESCo would endorse such an attitude.
Unless I am missing something, the closed ACL are only accepted for
security reasons, I don't think that a "don't touch my packages even
though I don't maintain them" attitude is something we want to have in
Fedora. My understanding of the current situation is even that Jesse 
(hoping I recall well) is pushing forward opening ACLs for former core 
packages except when there is a strong security concern, now that there 
are 2 groups, uberpackagers and packagers.

>  (And bug reports, blah blah blah.) 
Also removing the owners from the ACL (which is something that should be
done in the future, I think) will stop them from receiving bug reports
for the branch.

--
Pat

reviving Fedora Legacy

[Bill Nottingham]

Patrice Dumas (pertusus(a)free.fr) said: 
>  In the proposal the updated packages go to another repository,
> isn't
>  that enough? I honestly don't think that FESCo would endorse such an attitude.
If it's going to another repository... why do you need the same CVS
history? (To play devil's advocate.)

Bill

reviving Fedora Legacy

[Patrice Dumas]

On Wed, Oct 15, 2008 at 10:51:09AM -0400, Bill Nottingham wrote:
>  Patrice Dumas (pertusus(a)free.fr) said: 
>  > In the proposal the updated packages go to another repository, isn't
>  > that enough? I honestly don't think that FESCo would endorse such an attitude.
>  
>  If it's going to another repository... why do you need the same CVS
>  history? (To play devil's advocate.) 
In the long term, if the project has gained trust and approval from
fedora and can be under the fedora umbrella it will be more simple. And
even before it will be more simple...

--
Pat

reviving Fedora Legacy

[Ralf Corsepius]

On Wed, 2008-10-15 at 10:51 -0400, Bill Nottingham wrote:
>  Patrice Dumas (pertusus(a)free.fr) said: 
>  > In the proposal the updated packages go to another repository, isn't
>  > that enough? I honestly don't think that FESCo would endorse such an attitude.
>  
>  If it's going to another repository... why do you need the same CVS
>  history? (To play devil's advocate.) 
Right. 

If this all shall make sense and remain unbureaucratic and efficient,
there must not be any "other repo" nor "other VCS" nor distrust.

Seems to me as if some people around here are resistant to learning?

reviving Fedora Legacy

[Pekka Savola]

On Wed, 15 Oct 2008, Ralf Corsepius wrote:
>  If this all shall make sense and remain unbureaucratic and
> efficient,
>  there must not be any "other repo" nor "other VCS" nor distrust.
>
>  Seems to me as if some people around here are resistant to learning? 
Learning what?

It seems folks proposing this madness failed to learn from how Fedora 
Legacy failed.

I was there.  During the last year or so (when the updates were still 
being cranked out regularly), there were about 2 or 3 folks who would 
review proposed updates or try to put any significant work in it.

Unless we get a list of 20 maintainer-capable people willing to spend 
time in doing security fixes (for _any_ package, not just their pet 
packages), we shouldn't even be wasting time discussing this.

Is there such a list?  If you wish to continue with this, I'd suggest 
you start collecting one at a wiki somewhere, where people could sign 
and tell the terms under which they would be interested in 
contributing.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

reviving Fedora Legacy

[Patrice Dumas]

On Wed, Oct 15, 2008 at 08:00:47PM +0300, Pekka Savola wrote:
>  I was there.  During the last year or so (when the updates were still  
>  being cranked out regularly), there were about 2 or 3 folks who would  
>  review proposed updates or try to put any significant work in it. 
Now there won't be a strict need for reviewers. After some time in
bodhi things will get pushed, as it is the case in releases. Hopefully
people will review the updates. As I said repeatedly, we won't ask more
QA than what is in fedora release, and therefore not the amount that was
in legacy.

>  Unless we get a list of 20 maintainer-capable people willing to spend
>  
>  time in doing security fixes (for _any_ package, not just their pet  
>  packages), we shouldn't even be wasting time discussing this.
>
>  Is there such a list?  If you wish to continue with this, I'd suggest  
>  you start collecting one at a wiki somewhere, where people could sign  
>  and tell the terms under which they would be interested in contributing. 
The conditions of such a project is what is discussed here. Having
fedora infrastructure and fedora rules used or not is, in my opinion the
most important item for potential contributors. I wanted to contribute
to legacy but was deterred by the fact that another infra with another
set of rules was used. And other people told the same.

--
Pat

reviving Fedora Legacy

[Stephen John Smoogen]

On Wed, Oct 15, 2008 at 11:08 AM, Patrice Dumas <pertusus(a)free.fr&gt; wrote:
>  On Wed, Oct 15, 2008 at 08:00:47PM +0300, Pekka Savola wrote:
> >
> > I was there.  During the last year or so (when the updates were still
> > being cranked out regularly), there were about 2 or 3 folks who would
> > review proposed updates or try to put any significant work in it.
>
>  Now there won't be a strict need for reviewers. After some time in
>  bodhi things will get pushed, as it is the case in releases. Hopefully
>  people will review the updates. As I said repeatedly, we won't ask more
>  QA than what is in fedora release, and therefore not the amount that was
>  in legacy.
>  
I think its this which is causing people to react in fear to the
proposal. The large amount of uncertainty ( how long, what to do with
bad vulnerabilities not getting fixed, no knowledge of the quality of
the package, etc) is causing doubt. And this is the sort of FUD that
comes about because something is too amorphous and isn't getting
fleshed out.

1) Dealing with the fear of hurting the Fedora brand. Come up with a
new brand for this: Long Term Blue Shoes (or something).
2) Dealing with the various uncertainties:
  A. Get a list of people dedicated to this
  B. Put out how long you are extending it:  1 extra year.
  C. How to vet package quality/deal with bad trees.
  D. What stuff is staying 'static/slow-moving' and what gets whatever
is in the latest Fedora?
3) Dealing with the Doubt.
  A. Get the SIG organized
  B. Build a test project of supporting Fedora 9 for 6 extra months.
        This allows you time to get procedures, infrastructure, and
whatever else needed.
  C. Follow your plans
  D. Report how it worked.
  E. Fix what didn't work and repeat.

If you can do that you will have a working project that will show that
LTS is possible and a viable proposition that some place like
Wikipedia or Brazil would trust their computers on.

[And yes, you are going to need to deal with infrastructure. Disk
space, cpu cycles, memory and power is not 'cheap' as much as people
think it is. Extra build boxes will be needed, extra disk space to
store stuff, and extra cpu cycles as Fedora's current infrastructure
is built on the assumption that it only needs to deal with X releases
for Y time. Adding to X and Y means more equipment needed. It will
also mean that someone's on the team are going ot have to focus on the
infrastructure problems as that addition also increases the number of
people needed to watch builds, etc.



-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

reviving Fedora Legacy

[Jesse Keating]

On Wed, 2008-10-15 at 11:25 -0600, Stephen John Smoogen wrote:
>  
>  [And yes, you are going to need to deal with infrastructure. Disk
>  space, cpu cycles, memory and power is not 'cheap' as much as people
>  think it is. Extra build boxes will be needed, extra disk space to
>  store stuff, and extra cpu cycles as Fedora's current infrastructure
>  is built on the assumption that it only needs to deal with X releases
>  for Y time. Adding to X and Y means more equipment needed. It will
>  also mean that someone's on the team are going ot have to focus on the
>  infrastructure problems as that addition also increases the number of
>  people needed to watch builds, etc. 
along with infrastructure, you need a release engineer.  Somebody who's
going to babysit the collections, do buildroot overrides to build chains
of packages, do package signing, urge (a) bodhi into pushing the
updates, making sure they get rsynced properly, dealing with bug reports
about broken deps, so on and so forth.  I say this, because I'm not
about to volunteer to do that work for you.  I say this also, because
trying to bring somebody in to do these things on the "LTS" section, but
isolate that person from the normal section is going to be difficult, if
we have to go that route.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

reviving Fedora Legacy

[Matthew Miller]

On Wed, Oct 15, 2008 at 10:47:15AM -0700, Jesse Keating wrote:
>  along with infrastructure, you need a release engineer.  Somebody
> who's
>  going to babysit the collections, do buildroot overrides to build chains
>  of packages, do package signing, urge (a) bodhi into pushing the
>  updates, making sure they get rsynced properly, dealing with bug reports
>  about broken deps, so on and so forth.  I say this, because I'm not
>  about to volunteer to do that work for you.  I say this also, because
>  trying to bring somebody in to do these things on the "LTS" section, but
>  isolate that person from the normal section is going to be difficult, if
>  we have to go that route. 
And let's be clear: this alone is a full-time job. Or job and a half.

-- 
Matthew Miller <mattdm(a)mattdm.org&gt;
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences

reviving Fedora Legacy

[Les Mikesell]

Matthew Miller wrote:
>  On Wed, Oct 15, 2008 at 10:47:15AM -0700, Jesse Keating wrote:
> > along with infrastructure, you need a release engineer.  Somebody who's
> > going to babysit the collections, do buildroot overrides to build chains
> > of packages, do package signing, urge (a) bodhi into pushing the
> > updates, making sure they get rsynced properly, dealing with bug reports
> > about broken deps, so on and so forth.  I say this, because I'm not
> > about to volunteer to do that work for you.  I say this also, because
> > trying to bring somebody in to do these things on the "LTS" section, but
> > isolate that person from the normal section is going to be difficult, if
> > we have to go that route.
>  
>  And let's be clear: this alone is a full-time job. Or job and a half. 
Ahh, nostalgia for the old days when Freshrpms and a few others were 
one-man shows covering most of the early RH releases and some of the 
fedoras beyond their own supported life - and inventing the way to do 
it.   Maybe you could find a third party site to take over...

-- 
   Les Mikesell
     lesmikesell(a)gmail.com

reviving Fedora Legacy

[Matthew Miller]

On Thu, Oct 16, 2008 at 08:12:14AM -0500, Les Mikesell wrote:
>  Ahh, nostalgia for the old days when Freshrpms and a few others were
>
>  one-man shows covering most of the early RH releases and some of the 
>  fedoras beyond their own supported life - and inventing the way to do it.   
>  Maybe you could find a third party site to take over... 
Sure, those places supported (and still support) their own random collection
of packages for older releases. That's very different from what's needed
here.

-- 
Matthew Miller <mattdm(a)mattdm.org&gt;
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences

reviving Fedora Legacy

[Ralf Corsepius]

On Wed, 2008-10-15 at 10:47 -0700, Jesse Keating wrote:
>  On Wed, 2008-10-15 at 11:25 -0600, Stephen John Smoogen wrote:
>  > 
>  > [And yes, you are going to need to deal with infrastructure. Disk
>  > space, cpu cycles, memory and power is not 'cheap' as much as people
>  > think it is. Extra build boxes will be needed, extra disk space to
>  > store stuff, and extra cpu cycles as Fedora's current infrastructure
>  > is built on the assumption that it only needs to deal with X releases
>  > for Y time. Adding to X and Y means more equipment needed. It will
>  > also mean that someone's on the team are going ot have to focus on the
>  > infrastructure problems as that addition also increases the number of
>  > people needed to watch builds, etc.
>  
>  along with infrastructure, you need a release engineer. 
I guess, you will apply the
same rationale when EPEL6 comes out?

Ralf

reviving Fedora Legacy

[Jesse Keating]

On Thu, 2008-10-16 at 06:53 +0200, Ralf Corsepius wrote:
>  I guess, you will apply the same rationale when EPEL6 comes out?
EPEL currently has people filling this role.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

reviving Fedora Legacy

[Ralf Corsepius]

On Wed, 2008-10-15 at 22:05 -0700, Jesse Keating wrote:
>  On Thu, 2008-10-16 at 06:53 +0200, Ralf Corsepius wrote:
>  > I guess, you will apply the same rationale when EPEL6 comes out?
>  
>  EPEL currently has people filling this role. 
You mean, RH's hegemony is taking
care about it and has allocated
budgets.

reviving Fedora Legacy

[Jesse Keating]

On Thu, 2008-10-16 at 07:23 +0200, Ralf Corsepius wrote:
>  You mean, RH's hegemony is taking care about it and has
> allocated
>  budgets. 
Actually no, I don't believe any @redhat.com folks are filling the
releng tasks for EPEL, or if they are, they were doing it before being
hired at RH and it is not part of their job.

To the best of my knowledge, not a single person within Red Hat is paid
to work on EPEL.  Any @redhat.com participation is done in one's spare
time.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

reviving Fedora Legacy

[Chris Adams]

Once upon a time, Ralf Corsepius <rc040203(a)freenet.de&gt; said:
>  On Wed, 2008-10-15 at 22:05 -0700, Jesse Keating wrote:
>  > On Thu, 2008-10-16 at 06:53 +0200, Ralf Corsepius wrote:
>  > > I guess, you will apply the same rationale when EPEL6 comes out?
>  > 
>  > EPEL currently has people filling this role.
>  You mean, RH's hegemony is taking care about it and has allocated
>  budgets. 
Why are you here if you have so little faith in Red Hat and their
alleged ulterior motives?
-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

reviving Fedora Legacy

[Ralf Corsepius]

On Thu, 2008-10-16 at 07:48 -0500, Chris Adams wrote:
>  Once upon a time, Ralf Corsepius <rc040203(a)freenet.de&gt; said:
>  > On Wed, 2008-10-15 at 22:05 -0700, Jesse Keating wrote:
>  > > On Thu, 2008-10-16 at 06:53 +0200, Ralf Corsepius wrote:
>  > > > I guess, you will apply the same rationale when EPEL6 comes out?
>  > > 
>  > > EPEL currently has people filling this role.
>  > You mean, RH's hegemony is taking care about it and has allocated
>  > budgets.
>  
>  Why are you here if you have so little faith in Red Hat and their
>  alleged ulterior motives? 
Who said I don't have faith in RH and their motives?

They are a commercial enterprise and hardly wouldn't sponsor Fedora if
they would not want to profit from it and if they wouldn't want to
conduct it in directions they want it to head to?

Yes, I feel bitter and frustrated about how Fedora evolves, yes, I was
sarcastic, and yes, I am personally disappointed about Jesse Keating and
some other FPB and FESCO folks.

reviving Fedora Legacy

[Dmitry Butskoy]

Ralf Corsepius wrote:
>  On Thu, 2008-10-16 at 07:48 -0500, Chris Adams wrote:
>    
> > Why are you here if you have so little faith in Red Hat and their
> > alleged ulterior motives?
> >     
>  Who said I don't have faith in RH and their motives?
>
>  They are a commercial enterprise and hardly wouldn't sponsor Fedora if
>  they would not want to profit from it and if they wouldn't want to
>  conduct it in directions they want it to head to?
>
>  Yes, I feel bitter and frustrated about how Fedora evolves, yes, I was
>  sarcastic, and yes, I am personally disappointed about Jesse Keating and
>  some other FPB and FESCO folks.
>
>
>     
...and it is completely normal and even useful situation. It is kinda 
opposition. A people system without any opposition is dictatorship.

Former "Red Hat Linux" was very popular, and had become a much more 
wider than just a RH project. There are people which use RH/Fedora 
themselves -- ie. not buying some support, and not planning to buy such 
a support at all. Some of those people are here.

The question is: Is it suitable to have a contributor in Fedora,  whose 
activity never will bring direct money for RH? Just patches, testing 
(including production environments) etc. only? What to do if he see that 
something goes wrong? Just answer him, that he should leave?


~buc

reviving Fedora Legacy

[Nicu Buculei]

Dmitry Butskoy wrote:
>  
>  The question is: Is it suitable to have a contributor in Fedora,  whose 
>  activity never will bring direct money for RH? Just patches, testing 
>  (including production environments) etc. only? What to do if he see that 
>  something goes wrong? Just answer him, that he should leave? 
I believe that all the contributions regarding games (OpenArena and 
such) do not bring direct money for Red Hat and we have plenty of games.

-- 
nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com
Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/
Open Clip Art Library: http://www.openclipart.org
my Fedora stuff: http://fedora.nicubunu.ro

reviving Fedora Legacy

[Patrice Dumas]

On Wed, Oct 15, 2008 at 11:25:18AM -0600, Stephen John Smoogen wrote:
>  On Wed, Oct 15, 2008 at 11:08 AM, Patrice Dumas
> <pertusus(a)free.fr&gt; wrote:
>  
>  I think its this which is causing people to react in fear to the
>  proposal. The large amount of uncertainty ( how long, what to do with
>  bad vulnerabilities not getting fixed, no knowledge of the quality of
>  the package, etc) is causing doubt. And this is the sort of FUD that
>  comes about because something is too amorphous and isn't getting
>  fleshed out. 
There are 2 reasons why I don't want to flesh it too much. One is
because I think it is an iterative process, we don't need much to start
and we'll see how it goes, and in the start it won't be public, only
something experimental. The other reason is that I see a lot of over
confidence in fedora releases although fedora cannot promise 
anything: some guarantes that Fedora releases cannot make are asked for
for that project, I really can't understand why.

>  1) Dealing with the fear of hurting the Fedora brand. Come up with a
>  new brand for this: Long Term Blue Shoes (or something). 
I proposed UAEL. Update After End of Life. But I don't care a bit about
the name, as long as there is one and that it is clear that it is not
under the fedora brand.

>  2) Dealing with the various uncertainties:
>    A. Get a list of people dedicated to this 
I want to do this as soon as possible, but not before there is a formal
agreement that it will be possible to use fedora infrastructure and
rules, because it completly determines if people are interested. I won't
be, for example, if I have to set up a new infrastructure.

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

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

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

>  3) Dealing with the Doubt.
>    A. Get the SIG organized 
That's th efirst thing to do if the basics are agreed.

>    B. Build a test project of supporting Fedora 9 for 6 extra months.
>          This allows you time to get procedures, infrastructure, and
>  whatever else needed. 
The current plan is more for F8. But indeed this is the plan, begin
first with one branch, see if it works both on the infrastructure and 
packaging side, and stop if not (maybe before 6 months...).

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

>  [And yes, you are going to need to deal with infrastructure. Disk
>  space, cpu cycles, memory and power is not 'cheap' as much as people
>  think it is. Extra build boxes will be needed, extra disk space to 
I am not sure that cpu cycles, memory and power will be very
problematic, since we really should be on the side of stability and, in
contrary to EPEL the pacakges are already built. Moreover this is a one
time cost. Bandwidth and disk cost is another story, especially since it
is replicated in mirrors.

>  store stuff, and extra cpu cycles as Fedora's current
> infrastructure
>  is built on the assumption that it only needs to deal with X releases
>  for Y time. Adding to X and Y means more equipment needed. It will
>  also mean that someone's on the team are going ot have to focus on the
>  infrastructure problems as that addition also increases the number of
>  people needed to watch builds, etc. 
Indeed. I am ready to face that the project uses too much resources, but
without trying one cannot know.

--
Pat

reviving Fedora Legacy

[Jef Spaleta]

On Wed, Oct 15, 2008 at 10:57 AM, Patrice Dumas <pertusus(a)free.fr&gt; wrote:
>  There are 2 reasons why I don't want to flesh it too much. One
> is
>  because I think it is an iterative process, we don't need much to start
>  and we'll see how it goes, and in the start it won't be public, only
>  something experimental. 
I've no problem with interested people making an experimental stab at
this.  if the intent is to have FESCo revisit this in like a year or
something, try to setup the metrics or milestones now that will form
the basis of that future progress review.

I will say however, that if the initial mission and goals for a SIG
are too ill-defined you may have a problem harnessing manpower and
have everyone pulling the effort forward in a common direction.  Just
be wary of that.  As you move forward and create a SIG, I'm going to
need something concrete enough as a statement so when I'm talking to
people "outside" about their interests I know whether or not to point
them to this SIG as a place to dig in and help.  The last thing I want
to do is encourage people with dissimilar needs/interest to sit in a
room together and have them fight with each other.

>  In fact I think that something that should be
>  discussed within the SIG is how hard we try to keep a possible
>  upgrade path toward the next RHEL/EPEL. 
That statement right there, is probably simultaneously the hardest and
potentially rewarding objective that an extended update effort could
attempt to achieve.  And its a far different thing to state that as an
objective to work towards over just saying maintainers can do whatever
they want.  But to do it well, would probably require a consensual
understanding by Red Hat and the external community that such an
upgrade path was a valuable thing to work towards together.

-jef

reviving Fedora Legacy

[Patrice Dumas]

On Wed, Oct 15, 2008 at 11:48:18AM -0800, Jeff Spaleta wrote:
>  On Wed, Oct 15, 2008 at 10:57 AM, Patrice Dumas
> <pertusus(a)free.fr&gt; wrote:
>  > There are 2 reasons why I don't want to flesh it too much. One is
>  > because I think it is an iterative process, we don't need much to start
>  > and we'll see how it goes, and in the start it won't be public, only
>  > something experimental.
>  
>  I've no problem with interested people making an experimental stab at
>  this.  if the intent is to have FESCo revisit this in like a year or
>  something, try to setup the metrics or milestones now that will form
>  the basis of that future progress review. 
I think that it is too soon to try to set metrics before it is clear if
people should mandatorily sign off as maintainers for older branches,
whether and when there will be bug reports (and how) and so on.

>  I will say however, that if the initial mission and goals for a SIG
>  are too ill-defined you may have a problem harnessing manpower and
>  have everyone pulling the effort forward in a common direction.  Just
>  be wary of that.  As you move forward and create a SIG, I'm going to
>  need something concrete enough as a statement so when I'm talking to
>  people "outside" about their interests I know whether or not to point
>  them to this SIG as a place to dig in and help.  The last thing I want
>  to do is encourage people with dissimilar needs/interest to sit in a
>  room together and have them fight with each other. 
Indeed, that's a real issue for this project, as there is no consensus
on what is a good LTS project. For some it is absolute stability, for
other it is innovative as in fedora release, for other it is to bridge
the gap between RHEL releases, and so on. In my opinion saying that it
is more on the stability side, but without the same constraints than in
EPEL is a good start.

>  > In fact I think that something that should be
>  > discussed within the SIG is how hard we try to keep a possible
>  > upgrade path toward the next RHEL/EPEL.
>  
>  That statement right there, is probably simultaneously the hardest and
>  potentially rewarding objective that an extended update effort could
>  attempt to achieve.  And its a far different thing to state that as an
>  objective to work towards over just saying maintainers can do whatever
>  they want.  But to do it well, would probably require a consensual
>  understanding by Red Hat and the external community that such an
>  upgrade path was a valuable thing to work towards together. 
I think that this is far too soon to have such target. In the short 
term leaving maintainers to do whatever they want is in my opinion a 
better option to begin with. As soon as th eSIG is established there
could be a refinement of the rules, but before I think that letting
packagers do what they want is the simplest and most general target we
can have.

--
Pat

reviving Fedora Legacy

[Kevin Kofler]

Pekka Savola <pekkas <at> netcore.fi> writes:
>  I was there.  During the last year or so (when the updates were still
>
>  being cranked out regularly), there were about 2 or 3 folks who would 
>  review proposed updates or try to put any significant work in it. 
With no QA to worry about, that might even be enough.

And less bureaucracy, no separate infrastructure to worry about and ability to 
reuse existing Fedora sponsorship instead of going through yet another 
community process might help attract more packagers. (I intentionally don't use 
the word "maintainers" here because I think more of a "bazaar" model
where 
whoever feels able to fix a given security hole can do it, only membership in 
uberpackager (or maybe even only packager) required.)

        Kevin Kofler

reviving Fedora Legacy

[Ralf Corsepius]

On Wed, 2008-10-15 at 20:00 +0300, Pekka Savola wrote:
>  On Wed, 15 Oct 2008, Ralf Corsepius wrote:
>  > If this all shall make sense and remain unbureaucratic and efficient,
>  > there must not be any "other repo" nor "other VCS" nor
> distrust.
>  >
>  > Seems to me as if some people around here are resistant to learning?
>  
>  Learning what? 
Keeping things simple, avoiding bureaucracy, developing trust etc.

>  It seems folks proposing this madness failed to learn from how Fedora
>
>  Legacy failed. 
Legacy failed exactly for the reasons above: Separate VCS, separate
buildsystem, blownup bureaucracy, lack of collaboration, distrust.

Ralf

reviving Fedora Legacy

[Ralf Corsepius]

On Wed, 2008-10-15 at 07:33 -0400, Josh Boyer wrote:
>  On Wed, Oct 15, 2008 at 09:42:28AM +0200, Patrice Dumas wrote:
>  >On Wed, Oct 15, 2008 at 08:36:05AM +0100, David Woodhouse wrote:
>  >> 
>  >> If we present the _appearance_ of a distro with security updates, while
>  >> in fact there are serious security issues being unfixed, then that is
>  >> _much_ worse than the current "That distro is EOL. Upgrade before you
>  >> get hacked" messaging.
>  >
>  >The aim here is not to present the _appearance_ of a distro with
>  >security updates but give the choice to the user either to upgrade or to
>  >stick with a distro where some packages will not be maintained.
>  >Something along "That distro is EOL. Upgrade before you get hacked.
>  >Alternatively, and at your own risk, you can enable a repository where 
>  >some packages are updated on a volunteer basis, but some packages aren't
>  >maintained anymore."
>  >
>  >With a page listing which packages are still supported.
>  
>  The issue you will have is that people will not be comfortable opening the
>  ACLs for things like the kernel or glibc or gcc. 
And their rationale being what?

Them preferring leaving users exposed to vulnerabilities?

Or is their rationale of personal nature?

reviving Fedora Legacy

[Josh Boyer]

On Wed, Oct 15, 2008 at 02:19:09PM +0200, Ralf Corsepius wrote:
> On Wed, 2008-10-15 at 07:33 -0400, Josh Boyer wrote:
> > On Wed, Oct 15, 2008 at 09:42:28AM +0200, Patrice Dumas wrote:
> > >On Wed, Oct 15, 2008 at 08:36:05AM +0100, David Woodhouse wrote:
> > >> 
> > >> If we present the _appearance_ of a distro with security updates, while
> > >> in fact there are serious security issues being unfixed, then that is
> > >> _much_ worse than the current "That distro is EOL. Upgrade before you
> > >> get hacked" messaging.
> > >
> > >The aim here is not to present the _appearance_ of a distro with
> > >security updates but give the choice to the user either to upgrade or to
> > >stick with a distro where some packages will not be maintained.
> > >Something along "That distro is EOL. Upgrade before you get hacked.
> > >Alternatively, and at your own risk, you can enable a repository where 
> > >some packages are updated on a volunteer basis, but some packages aren't
> > >maintained anymore."
> > >
> > >With a page listing which packages are still supported.
> > 
> > The issue you will have is that people will not be comfortable opening the
> > ACLs for things like the kernel or glibc or gcc.
> And their rationale being what? 
See my other reply.

> Them preferring leaving users exposed to vulnerabilities? 
Obviously not, since the newer distros are maintained.

> Or is their rationale of personal nature? 
Well, since we're all just talking theoreticals I don't see how anything
can be of a personal nature yet.

josh

reviving Fedora Legacy

[Les Mikesell]

Josh Boyer wrote:
>  On Wed, Oct 15, 2008 at 02:19:09PM +0200, Ralf Corsepius wrote:
> > On Wed, 2008-10-15 at 07:33 -0400, Josh Boyer wrote:
> >> On Wed, Oct 15, 2008 at 09:42:28AM +0200, Patrice Dumas wrote:
> >>> On Wed, Oct 15, 2008 at 08:36:05AM +0100, David Woodhouse wrote:
> >>>> If we present the _appearance_ of a distro with security updates, while
> >>>> in fact there are serious security issues being unfixed, then that is
> >>>> _much_ worse than the current "That distro is EOL. Upgrade before
> you
> >>>> get hacked" messaging.
> >>> The aim here is not to present the _appearance_ of a distro with
> >>> security updates but give the choice to the user either to upgrade or to
> >>> stick with a distro where some packages will not be maintained.
> >>> Something along "That distro is EOL. Upgrade before you get hacked.
> >>> Alternatively, and at your own risk, you can enable a repository where 
> >>> some packages are updated on a volunteer basis, but some packages aren't
> >>> maintained anymore."
> >>>
> >>> With a page listing which packages are still supported.
> >> The issue you will have is that people will not be comfortable opening the
> >> ACLs for things like the kernel or glibc or gcc.
> > And their rationale being what?
>  
>  See my other reply.
>  
> > Them preferring leaving users exposed to vulnerabilities?
>  
>  Obviously not, since the newer distros are maintained. 
With disruptive changes that make it impossible to know if your hardware 
or applications will still work after an upgrade - and what is the 
alternative if they don't?

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

reviving Fedora Legacy

[Bruno Wolff III]

On Wed, Oct 15, 2008 at 07:57:00 -0500,
  Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:
>  With disruptive changes that make it impossible to know if your hardware  
>  or applications will still work after an upgrade - and what is the  
>  alternative if they don't? 
Don't upgrade and deal with security problems yourself. I ran Redhat 6.2 on
on a network connected system for several years after support ended. For
critical network facing services, I build them from up to date source.
Other stuff stayed the way it was. Later I was stuck at FC5 for a while
past EOL because of a kernel bug and kept an eye on security bug fixes to see
if I needed to update any packages to fix a problem that would apply to me.

reviving Fedora Legacy

[Jef Spaleta]

On Tue, Oct 14, 2008 at 11:42 PM, Patrice Dumas <pertusus(a)free.fr&gt; wrote:
>  The aim here is not to present the _appearance_ of a distro with
>  security updates but give the choice to the user either to upgrade or to
>  stick with a distro where some packages will not be maintained.
>  Something along "That distro is EOL. Upgrade before you get hacked.
>  Alternatively, and at your own risk, you can enable a repository where
>  some packages are updated on a volunteer basis, but some packages aren't
>  maintained anymore."
>
>  With a page listing which packages are still supported. 
I still want to see more affirmative scenarios on how old branches are
to be closed out..eventually.  If you can not decide and publish a
pre-determined EOL date, then you will have to measure something to
determine when to close out the branch. Branches must have an end
scenario.. we can not make an open ended resource commitment to each
and every Fedora release from now into the future.  What you are
setting up is a situation were all branches remain open forever on the
off-chance that someone might want to pick up and maintain a package
15 years from now. Not acceptable.  If these branches are going to
remain open based on interest..then we'll need to measure that
interest and set a bar to meet that makes sense as a determining point
to start shutting down the branch.

-jef

reviving Fedora Legacy

[Patrice Dumas]

On Wed, Oct 15, 2008 at 08:48:55AM -0800, Jeff Spaleta wrote:
>  
>  I still want to see more affirmative scenarios on how old branches are
>  to be closed out..eventually.  If you can not decide and publish a
>  pre-determined EOL date, then you will have to measure something to
>  determine when to close out the branch. Branches must have an end
>  scenario.. we can not make an open ended resource commitment to each
>  and every Fedora release from now into the future.  What you are
>  setting up is a situation were all branches remain open forever on the
>  off-chance that someone might want to pick up and maintain a package
>  15 years from now. Not acceptable.  If these branches are going to 
No, I have proposed 3 or 5 years, and currently only F8, as an
experimental proof of concept and proof of interest. In the scope of
this we coould then set up rules for closing branches, try to see what
is th erates of updates, the coverage... but for now I just want to get
it started as an experimental F8 only project to see if there is
interest or not, set up a SIG and discuss the other points.

I wouldn't be bothered if FESCo said, you only have 18 months, as well.

--
Pat

reviving Fedora Legacy

[Emmanuel Seyman]

* Kevin Kofler [13/10/2008 09:57] :
>  want, the infrastructure is essentially already there. Right now, we're stuck 
>  in a chicken&egg situation, where the people controlling the infrastructure 
>  say "show us interested maintainers first" and potentially interested packagers
>
>  say "show us the infrastructure first". 
The difference between the two sides is that, while the packagers are a
necessity, the Fedora infrastructure isn't.

Emmanuel

reviving Fedora Legacy

[Michael Schwendt]

On Mon, 13 Oct 2008 00:22:42 +0000 (UTC), Kevin Kofler wrote:

>  it was overreaching bureaucracy which killed Fedora 
>  Legacy (e.g. excessive QA requirements, paranoia such as not trusting 
>  Bugzilla's authentication mechanisms, instead requiring GPG signing of Bugzilla 
>  comments, which raised the barrier to entry), not lack of interested 
>  developers. 
Well, if there had been many "interested developers", they could have
simply appeared as boycotters of GPG clear-text signing in bugzilla
while at the same time offering update candidate rpms and reviews.
Hasn't happened IMO.

reviving Fedora Legacy

[Ralf Corsepius]

On Mon, 2008-10-13 at 00:01 +0200, shmuel siegel wrote:
>  Patrice Dumas wrote:
>  > On Sun, Oct 12, 2008 at 09:12:05PM +0000, Kevin Kofler wrote:
>  >   
>  >> Patrice Dumas <pertusus <at> free.fr> writes:
>  >>     
>  >>> In my response to that mail, failing to have a metric I retired my
>  >>> proposal, and nobody supported my views (and overall nobody supported my
>  >>> views).
>  >>>       
>  >> In terms of those metrics, I'm still in favor of a mostly anarchical
> approach:
>  >>     
>  >
>  > I completly agree. This is simple and leave everything to the packagers
>  > initiative, I think that it is also what Ralf had in mind. But some people 
>  > insisted on communicating to the public what was maintained, hence my 
>  > proposal. But what you propose is better.
>  >
>  > --
>  > Pat
>  >
>  >   
>  Up to here you definitely had my sympathy. But this anarchical approach 
>  makes me wonder who your target audience is. 
All "users", esp. those who
currently stay with discontinued and
unmaintained Fedoras, because
- they are not aware about these Fedora's being dead.
- they can't cope with the "frequent upgrades" or can't afford
upgrading
at the point in time a Fedora release is going EOL. discontinued.
- they can't upgrade for technical reasons.

Another aspect would be "keep users with Fedora" and to not force them
to resort to other distros.

Ralf

reviving Fedora Legacy

[Patrice Dumas]

On Sun, Oct 12, 2008 at 09:57:47AM -0500, Rex Dieter wrote:
>  
>  I perused the thread, but failed to find any reference to any authoritative statement
> that fedora infrastructure could not be used for such an effort.  Am I missing something?
In fact you are missing the previous thread, which is much longer, 
https://www.redhat.com/archives/fedora-devel-list/2008-January/msg02191.html

with, for example:
https://www.redhat.com/archives/fedora-devel-list/2008-January/msg02213.html
https://www.redhat.com/archives/fedora-devel-list/2008-January/msg02562.html

It ends with Jef Spaleta telling that it is sad that I voice my concerns
without taking the lead:
https://www.redhat.com/archives/fedora-devel-list/2008-January/msg02640.html

I ended up doing it by proposing UAEL, but without much more success
even if I took the lead I was shot down by the same Jef, on the metric
about packager investment in UAEL... I must say that, personnally for me
this was a bit bitter to see that unrealistic things are asked for to
shoot down an idea and that involvment is not necessarily enough to get
things done when some people oppose. 

--
Pat

reviving Fedora Legacy

[Michael Schwendt]

On Sun, 12 Oct 2008 15:19:51 +0530, Rahul Sundaram wrote:

>  It seems that there isn't enough people interested in doing the
> work. 
Ack. For potential contributors apparently it is easier to build their own
private updates from tarballs (or RHEL/Fedora N+1 src.rpms). Even current
Fedora users often (see various web forums) try to fix issues themselves
with builds from source code instead of submitting problem reports in
bugzilla and working together with the Fedora packagers. You can see
rumours that claim how rebuilds from source work while rpms from Fedora
would not work, and getting those people to help in finding and preparing
officially fixed rpms is hard.

One big problem is accountability. With roles like "package maintainer"
or "reviewer" (who approves something) come responsibilities. Few people
want to make an extra effort as would be necessary for pkgs to be
published as official Fedora Updates.

reviving Fedora Legacy

[Emmanuel Seyman]

* Ralf Corsepius [12/10/2008 11:45] :
>  Similar proposals have come up several times before (I once proposed
>  something like this), but so far, they all had been shoot down so far. 
Actually, nothing has ever been proposed.

Occasionnally, someone suggests that updates be released post-EOL and
we then get submerged in proposals that all vary on the set of packages
to be supported, the ABI/API compatibility that should be given, who
will actually maintain what, ...

All of the people willing to work on this project start arguing amongst
themselves as to what is the right thing to do and nothing ever gets
proposed so there's never been anything to refuse.

We then get a whole host of excuses (the most popular of which is that
this is something that can only be done with the Fedora infrastructure),
all of which get replaced with other excuses every time one is shot
down.

Emmanuel

reviving Fedora Legacy

[shmuel siegel]

Emmanuel Seyman wrote:
>  * Ralf Corsepius [12/10/2008 11:45] :
>    
> > Similar proposals have come up several times before (I once proposed
> > something like this), but so far, they all had been shoot down so far.
> >     
>
>  Actually, nothing has ever been proposed.
>
>  Occasionnally, someone suggests that updates be released post-EOL and
>  we then get submerged in proposals that all vary on the set of packages
>  to be supported, the ABI/API compatibility that should be given, who
>  will actually maintain what, ...
>
>  All of the people willing to work on this project start arguing amongst
>  themselves as to what is the right thing to do and nothing ever gets
>  proposed so there's never been anything to refuse.
>
>  We then get a whole host of excuses (the most popular of which is that
>  this is something that can only be done with the Fedora infrastructure),
>  all of which get replaced with other excuses every time one is shot
>  down.
>
>  Emmanuel
>
>     
Seems to me that you have the beginning of a plan. There needs to be an 
individual with the responsibility to create a full-blown proposal. He 
must identify the scope of the task and the resources that would be 
required to fulfill the requirements. He must also be willing and able 
to incorporate the various suggestions and objections into the overall 
plan. Judging by the comments on this thread he would also need to 
identify an infrastructure sponsor who would commit to giving the 
project a home. As long as this remains a group of individuals with a 
vague feeling that a legacy project would be a good thing to have, 
nothing will happen.
And no, I am not that individual.

reviving Fedora Legacy

[Patrice Dumas]

On Sun, Oct 12, 2008 at 01:34:15PM +0200, shmuel siegel wrote:
> >
> >   
>  Seems to me that you have the beginning of a plan. There needs to be an  
>  individual with the responsibility to create a full-blown proposal. He   
https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00598....

At some point there was a page in the wiki, I can't find it anymore.

--
Pat

reviving Fedora Legacy

[Chuck Anderson]

On Sun, Oct 12, 2008 at 02:33:41PM +0200, Patrice Dumas wrote:
>  On Sun, Oct 12, 2008 at 01:34:15PM +0200, shmuel siegel wrote:
>  > Seems to me that you have the beginning of a plan. There needs to be an  
>  > individual with the responsibility to create a full-blown proposal. He  
>  
>  https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00598....
>  
>  At some point there was a page in the wiki, I can't find it anymore. 
I just re-read the entire thread (its not that huge):

http://fedoraproject.org/wiki/DraftPageUAEL
http://fedoraproject.org/wiki/DraftUAEL

It sees that the main objections were/are:

1. Without some sort of statement on lifetime, users would be left 
high and dry at any instant in time that the branch could be declared 
"dead" after 7 days without a maintainer for one of the @core @base 
packages.

It was proposed to have a client-side UI to inform users of the 
viability/end-of-life/status of a branch.  I believe PackageKit could 
be used to do this now.  It has been discussed for regular Fedora EOL 
that a notification be sent via package metadata, possibly offering 
the user an upgrade path.  This upgrade path could be to the next 
Fedora via Pre-Upgrade, or to UAEL via changing the yum repo 
locations.  Likewise, at the end of UAEL life, similar warnings could 
be put out in advance of the EOL.

Also the bit about "if one of these packages isn't maintained anymore, 
the whole branch is retired after 1 week." won't really work with the 
above.  At the very least, give 3-4 weeks for a new maintainer to be 
found, on par with the existing Fedora policies.

My personal opinion is to start with a very limited extension of 
lifespan.  E.g. when F-8 goes EOL one month after F-10, UAEL would 
extend F-8 to one month after F-11 is released, giving an additional 
6-7 months of lifespan to F-8.  This would limit the amount of UAEL 
work to one distro release at a time and would solve one set of 
user/sysadmin problems, which is that by the time F-N stabalizes and 
slows down enough to upgrade to it (in my experience that is around 
the time F-N+1 comes out), there is only 6-7 months left before it 
goes EOL.  This proposal would extend that remainder to 12-13 months.  
At least then they could follow an annual upgrade cycle.  If they need 
more than a year, perhaps RHEL/CentOS is the right choice for them.

I think it is important that no matter what timeframe is decided, UAEL 
maintainers as a group must agree to stick to it, just like Fedora 
maintainers now are expected to stick to supporting their packages for 
the lifespan of F-N and F-N-1.

2. Jeff Spaleta wanted metrics and verification to be sure the UAEL 
maintainers were actually doing their job and maintaining the packages 
they said they would, and metrics to be sure no one maintainer took on 
too large of a load to prevent from getting burned out.

I think it is unrealistic to require more oversight for UAEL than 
there is for regular Fedora maintainers.  Trust that they will do the 
work.  If they don't, follow the same policies and procedures we have 
to deal with that in Fedora today.  

3. On the matter of infrastructure.  The UAEL proposal suggested that 
we reuse the existing Fedora infrastructure and just let the F-N 
branches live on, or create new branches in CVS for UAEL-N so as to 
allow UAEL contributors to concentrate on packaging, rather than 
setting up new infrastructure.

How would this affect the existing Fedora Infrastructure maintainers?  
Would this require much more committment and work from them?  Or is 
this just limited to finding someone to sign packages?  Are they okay 
with that?  By limiting the lifespan to 7 months or so, this also 
limits the expectations we have from Fedora Infrastructure.

4.  On ABI/API stability.  Fedora has no guarantee for ABI/API 
stability.  Neither would UAEL.  Maintainers could choose to upgrade, 
backport, or "steal" from newer Fedora/RHEL/CentOS as they see fit, to 
the same extent that Fedora package maintainers can and do today.  I 
don't see UAEL having any more guarantees than Fedora does in this 
regard.  Again, if you want more than this, then perhaps RHEL/CentOS 
is the right choice for you.

5. On security.  How does the Fedora Security Team work now?  It seems 
to be a pretty opaque group, i.e. not transparent to the rest of the 
community.  Without knowing how this part of Fedora works, it is hard 
to formulate a plan for UAEL.  At worst, UAEL could be reactive to 
other security announcements and update releases, like how Fedora 
Legacy used to work.  At best, there would be some cooperation between 
the Fedora Security Team and UAEL.

reviving Fedora Legacy

[Jef Spaleta]

On Sun, Oct 12, 2008 at 7:47 AM, Chuck Anderson <cra(a)wpi.edu&gt; wrote:
>  2. Jeff Spaleta wanted metrics and verification to be sure the UAEL
>  maintainers were actually doing their job and maintaining the packages
>  they said they would, and metrics to be sure no one maintainer took on
>  too large of a load to prevent from getting burned out.
>
>  I think it is unrealistic to require more oversight for UAEL than
>  there is for regular Fedora maintainers.  Trust that they will do the
>  work.  If they don't, follow the same policies and procedures we have
>  to deal with that in Fedora today. 
I think its unrealistic to not require more oversight for something
that is essentially an open-ended commitment.  if you are going to
leave it as an open-ended commitment with no firm EOL on the branch
then yes... i want metrics to make sure we aren't leaving people stuck
in a weird state for critical but unmaintained items for what could be
years.  I also do not accept the idea that its okay to open up a
Fedora branded branch which gives users absolutely no guidance as to
how long the packages branch will be usable.  I think its a poor use
of the brand.

I'm not talking about QA.. I'm talking about verifying that the
volunteer maintainers are actually still in place a year+ later.  How
do make users aware that packages are unmaintained for 1+ years? Do
you plan to expire unmaintained packages so new users don't have
access to them?You have to have some process to verify that the
maintainers are there because you are explicitly stating that the life
of branch depends on an accurate count of the active maintainers. if
you don't build a process to try to verify maintainer involvement..the
branches could live forever because there is no pre-defined EOL.

If the UAEL draft is not updated to include some firm EOL
expectations, I will continue to push back concerning metrics as to
maintainer commitment because the plan relies on maintainer commitment
to set the EOL timeframe.  How to address that concern is completely
unexplored because up till this point the proponents haven't cared to
try to address it.

Honestly after several days of discussion this week are the proponents
any further along than what was proposed in the UAEL draft? I haven't
seen a single new idea.  Until someone new, who is committed to moving
an implementation forward steps forward, this discussion is moot.
Would WPI give you some infrastructure resources to burn on this to
supplement existing project infrastructure to demonstrate that it was
a sustainable effort?


-jef

reviving Fedora Legacy

[Bob Arendt]

Jeff Spaleta wrote:
>  I'm not talking about QA.. I'm talking about verifying that
> the
>  volunteer maintainers are actually still in place a year+ later.  How
>  do make users aware that packages are unmaintained for 1+ years? Do
>  you plan to expire unmaintained packages so new users don't have
>  access to them?You have to have some process to verify that the
>  maintainers are there because you are explicitly stating that the life
>  of branch depends on an accurate count of the active maintainers. if
>  you don't build a process to try to verify maintainer involvement..the
>  branches could live forever because there is no pre-defined EOL.
>
>     
I really don't see how a Fedora Legacy can be maintained.  If the goal 
is increased
stability and security patches, you need to guarantee that you have 
folks supporting
backpatches to the kernel, glibc, firefox, evolution,  openoffice, and 
several other large
and complex packages.  Incorporating new security patches into old 
baselines is *hard*.
Plus Fedora would "fork" a new release every 6 months.  How many legacy
Fedora's would be retained?  At some point it seems the legacy volunteer 
force
would saturate and legacy Fedora's would have to start dropping off 
every 6 months.

reviving Fedora Legacy

[Chuck Anderson]

On Sun, Oct 12, 2008 at 06:22:16PM -0700, Bob Arendt wrote:
>  I really don't see how a Fedora Legacy can be maintained.  If the
>
>  goal is increased stability and security patches, you need to 
>  guarantee that you have folks supporting backpatches to the kernel, 
>  glibc, firefox, evolution, openoffice, and several other large and 
>  complex packages.  Incorporating new security patches into old 
>  baselines is *hard*. Plus Fedora would "fork" a new release every 6 
>  months.  How many legacy Fedora's would be retained?  At some point 
>  it seems the legacy volunteer force would saturate and legacy 
>  Fedora's would have to start dropping off every 6 months. 
Why do we need to guarantee any more than active Fedora releases 
guarantee?  Forget backporting.  Just upgrade the package.  Take it 
from the current Fedora and rebuild it if necessary.

I've already said my piece on the timeline.  6-7 months to start out.  
If that works, we can talk about extending it.

reviving Fedora Legacy

[Robert Locke]

On Sun, 2008-10-12 at 22:14 -0400, Chuck Anderson wrote:
>  On Sun, Oct 12, 2008 at 06:22:16PM -0700, Bob Arendt wrote:
>  > I really don't see how a Fedora Legacy can be maintained.  If the 
>  > goal is increased stability and security patches, you need to 
>  > guarantee that you have folks supporting backpatches to the kernel, 
>  > glibc, firefox, evolution, openoffice, and several other large and 
>  > complex packages.  Incorporating new security patches into old 
>  > baselines is *hard*. Plus Fedora would "fork" a new release every 6 
>  > months.  How many legacy Fedora's would be retained?  At some point 
>  > it seems the legacy volunteer force would saturate and legacy 
>  > Fedora's would have to start dropping off every 6 months.
>  
>  Why do we need to guarantee any more than active Fedora releases 
>  guarantee?  Forget backporting.  Just upgrade the package.  Take it 
>  from the current Fedora and rebuild it if necessary. 
And then have everyone complaining when the "upgrade" to the new version
introduced an incompatibility.  Take a look at the recent complaining as
KDE moved forward.  Why not just upgrade to the next Fedora release
then?  If you want security/stability, it requires backporting....

But, then, I let RHEL/CentOS take care of that for me.... :-)

--Rob

reviving Fedora Legacy

[Kevin Kofler]

Robert Locke <lists <at> ralii.com> writes:
>  And then have everyone complaining when the "upgrade" to
> the new version
>  introduced an incompatibility.  Take a look at the recent complaining as
>  KDE moved forward.  Why not just upgrade to the next Fedora release
>  then?  If you want security/stability, it requires backporting.... 
Obviously we wouldn't upgrade F8 to KDE 4!

If anything, we'd upgrade it to newer 3.5.x releases, but even that is not 
necessary because KDE is among the few upstream projects who publish backported 
security patches for older releases, so we do not have to backport anything on 
our own, just apply the security fixes from KDE. We could stay on 3.5.10 for 
years, and that also works for branches like 4.0, 4.1 or 4.2 which aren't as 
long-lived as 3.5.

         Kevin Kofler

reviving Fedora Legacy

[Orion Poplawski]

>  Obviously we wouldn't upgrade F8 to KDE 4!
>
>  If anything, we'd upgrade it to newer 3.5.x releases, but even that is not
>  necessary because KDE is among the few upstream projects who publish
>  backported
>  security patches for older releases, so we do not have to backport
>  anything on
>  our own, just apply the security fixes from KDE. We could stay on 3.5.10
>  for
>  years, and that also works for branches like 4.0, 4.1 or 4.2 which aren't
>  as
>  long-lived as 3.5.
>
>           Kevin Kofler 
This is the issue I face at the moment.  I've felt that KDE4 is just not
ready for me to upgrade to at work, so I've stuck with F8.  This has
happened a couple time over Fedora history, although for different reason,
where I've had to skip a release or two (at least now skipping a release
is supported).  CentOS is really not an option (for laptops and desktop)
due to lack of support for very current hardware and I'm not aware of KDE
for CentOS.

But this is a specific issue with a specific set of releases.  I'm not
sure it warrants a general policy, with the possible exception of simply
(is this really simple?) keeping Fedora infrastructure open for updates
for F-8 past the scheduled EOL.

- Orion

reviving Fedora Legacy

[Kevin Kofler]

 <orion <at> cora.nwra.com> writes:
>  I'm not aware of KDE for CentOS. 
RHEL/CentOS contains KDE, and there are also newer versions available from the 
kde-redhat project. (There's currently 3.5.9 in stable and 3.5.10 in testing 
for EL5. The stock EL5 KDE is 3.5.4.)

        Kevin Kofler

reviving Fedora Legacy

[Horst H. von Brand]

Chuck Anderson <cra(a)WPI.EDU&gt; wrote:

[...]

>  Why do we need to guarantee any more than active Fedora releases 
>  guarantee?  Forget backporting.  Just upgrade the package.  Take it 
>  from the current Fedora and rebuild it if necessary. 
What is the difference from regular Fedora then, if you propose just
dumping new packages into the "stable" release?

>  I've already said my piece on the timeline.  6-7 months to start
> out.  
>  If that works, we can talk about extending it. 
Nope. If anything, pick a Fedora release and propose to extend its life for
a year (less makes very little sense). Then move to the one EOL at that
point, etc.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

reviving Fedora Legacy

[David Woodhouse]

On Sun, 2008-10-12 at 22:14 -0400, Chuck Anderson wrote:
>  On Sun, Oct 12, 2008 at 06:22:16PM -0700, Bob Arendt wrote:
>  > I really don't see how a Fedora Legacy can be maintained.  If the 
>  > goal is increased stability and security patches, you need to 
>  > guarantee that you have folks supporting backpatches to the kernel, 
>  > glibc, firefox, evolution, openoffice, and several other large and 
>  > complex packages.  Incorporating new security patches into old 
>  > baselines is *hard*. Plus Fedora would "fork" a new release every 6 
>  > months.  How many legacy Fedora's would be retained?  At some point 
>  > it seems the legacy volunteer force would saturate and legacy 
>  > Fedora's would have to start dropping off every 6 months.
>  
>  Why do we need to guarantee any more than active Fedora releases 
>  guarantee?  Forget backporting.  Just upgrade the package.  Take it 
>  from the current Fedora and rebuild it if necessary. 
Once you start upgrading packages all over the place to a much newer
version than was in the original release, you might as well just
upgrade.

Seriously, I don't know why people are so scared of just _upgrading_, if
new packages are acceptable.

I upgrade remote, headless machines with yum, and reboot them into the
new distribution. Quite frequently. And I laugh at the people who say it
doesn't work. It's a fairly fundamental part of my server management
technique -- yes, I run Fedora on my servers.

Perhaps a better approach to this whole thing would be to educate people
a little better that upgrades _do_ work, and they're generally fairly
seamless. And to fix the occasional cases where they're not.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse(a)intel.com                              Intel Corporation

reviving Fedora Legacy

[Patrice Dumas]

On Wed, Oct 15, 2008 at 08:31:12AM +0100, David Woodhouse wrote:
>  
>  Once you start upgrading packages all over the place to a much newer
>  version than was in the original release, you might as well just
>  upgrade.
>  
>  Seriously, I don't know why people are so scared of just _upgrading_, if
>  new packages are acceptable. 
One example in my mind is the change from pam_console to consolekit.
Sure this is an improvement. But xdm and wdm didn't worked after that.
This is typically a big change that happens between releases that a user
may want to avoid. The thing that don't work in later versions may even
get fixed over time. There are a lot of similar regressions between
fedora releases. Other examples are programs that worked with KDE 3 and
don't work with KDE 4.

>  I upgrade remote, headless machines with yum, and reboot them into
> the
>  new distribution. Quite frequently. And I laugh at the people who say it
>  doesn't work. It's a fairly fundamental part of my server management
>  technique -- yes, I run Fedora on my servers.
>  
>  Perhaps a better approach to this whole thing would be to educate people
>  a little better that upgrades _do_ work, and they're generally fairly
>  seamless. And to fix the occasional cases where they're not. 
Sometime it is easily fixable, sometime it is complicated, it depends a
lot whether upstream takes care about compatibility or not (as is the
case, for example in the dbus/hal/*Kit case). And in any case it takes 
some time. Also in general the maintainers in fedora are 
looking forward and don't care about breaking compatibility, and if they 
cared this would slow down innovation.

--
Pat

reviving Fedora Legacy

[Les Mikesell]

David Woodhouse wrote:
>  
> >> I really don't see how a Fedora Legacy can be maintained.  If the 
> >> goal is increased stability and security patches, you need to 
> >> guarantee that you have folks supporting backpatches to the kernel, 
> >> glibc, firefox, evolution, openoffice, and several other large and 
> >> complex packages.  Incorporating new security patches into old 
> >> baselines is *hard*. Plus Fedora would "fork" a new release every 6 
> >> months.  How many legacy Fedora's would be retained?  At some point 
> >> it seems the legacy volunteer force would saturate and legacy 
> >> Fedora's would have to start dropping off every 6 months.
> > Why do we need to guarantee any more than active Fedora releases 
> > guarantee?  Forget backporting.  Just upgrade the package.  Take it 
> > from the current Fedora and rebuild it if necessary.
>  
>  Once you start upgrading packages all over the place to a much newer
>  version than was in the original release, you might as well just
>  upgrade.
>  
>  Seriously, I don't know why people are so scared of just _upgrading_, if
>  new packages are acceptable.
>  
>  I upgrade remote, headless machines with yum, and reboot them into the
>  new distribution. Quite frequently. And I laugh at the people who say it
>  doesn't work. It's a fairly fundamental part of my server management
>  technique -- yes, I run Fedora on my servers. 
What do you do when the upgrade kernel won't boot?   This sometimes 
happens even on updates within a version.

>  Perhaps a better approach to this whole thing would be to educate
> people
>  a little better that upgrades _do_ work, and they're generally fairly
>  seamless. And to fix the occasional cases where they're not. 
And supply them with spare test machines like you must use?

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

reviving Fedora Legacy

[Josh Boyer]

On Wed, Oct 15, 2008 at 08:12:04AM -0500, Les Mikesell wrote:
>  David Woodhouse wrote:
> >
> >>> I really don't see how a Fedora Legacy can be maintained.  If the  
> >>> goal is increased stability and security patches, you need to  
> >>> guarantee that you have folks supporting backpatches to the kernel, 
> >>> glibc, firefox, evolution, openoffice, and several other large and  
> >>> complex packages.  Incorporating new security patches into old  
> >>> baselines is *hard*. Plus Fedora would "fork" a new release every 6
>
> >>> months.  How many legacy Fedora's would be retained?  At some point 
> >>> it seems the legacy volunteer force would saturate and legacy  
> >>> Fedora's would have to start dropping off every 6 months.
> >> Why do we need to guarantee any more than active Fedora releases  
> >> guarantee?  Forget backporting.  Just upgrade the package.  Take it  
> >> from the current Fedora and rebuild it if necessary.
> >
> > Once you start upgrading packages all over the place to a much newer
> > version than was in the original release, you might as well just
> > upgrade.
> >
> > Seriously, I don't know why people are so scared of just _upgrading_, if
> > new packages are acceptable.
> >
> > I upgrade remote, headless machines with yum, and reboot them into the
> > new distribution. Quite frequently. And I laugh at the people who say it
> > doesn't work. It's a fairly fundamental part of my server management
> > technique -- yes, I run Fedora on my servers.
>
>  What do you do when the upgrade kernel won't boot?   This sometimes  
>  happens even on updates within a version. 
Yum updates leave the kernel you are currently running on in-place.
Boot back to that one and file a bug.

josh

reviving Fedora Legacy

[Les Mikesell]

Josh Boyer wrote:
>  On Wed, Oct 15, 2008 at 08:12:04AM -0500, Les Mikesell wrote:
> > David Woodhouse wrote:
> >>>> I really don't see how a Fedora Legacy can be maintained.  If the  
> >>>> goal is increased stability and security patches, you need to  
> >>>> guarantee that you have folks supporting backpatches to the kernel, 
> >>>> glibc, firefox, evolution, openoffice, and several other large and  
> >>>> complex packages.  Incorporating new security patches into old  
> >>>> baselines is *hard*. Plus Fedora would "fork" a new release
> every 6 
> >>>> months.  How many legacy Fedora's would be retained?  At some point 
> >>>> it seems the legacy volunteer force would saturate and legacy  
> >>>> Fedora's would have to start dropping off every 6 months.
> >>> Why do we need to guarantee any more than active Fedora releases  
> >>> guarantee?  Forget backporting.  Just upgrade the package.  Take it  
> >>> from the current Fedora and rebuild it if necessary.
> >> Once you start upgrading packages all over the place to a much newer
> >> version than was in the original release, you might as well just
> >> upgrade.
> >>
> >> Seriously, I don't know why people are so scared of just _upgrading_, if
> >> new packages are acceptable.
> >>
> >> I upgrade remote, headless machines with yum, and reboot them into the
> >> new distribution. Quite frequently. And I laugh at the people who say it
> >> doesn't work. It's a fairly fundamental part of my server management
> >> technique -- yes, I run Fedora on my servers.
> > What do you do when the upgrade kernel won't boot?   This sometimes  
> > happens even on updates within a version.
>  
>  Yum updates leave the kernel you are currently running on in-place.
>  Boot back to that one and file a bug. 
And if the machine is remote and headless as above?  Or just generally 
inconvenient to access or have down while you figure out what broke?

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

reviving Fedora Legacy

[Ralf Corsepius]

On Sun, 2008-10-12 at 18:22 -0700, Bob Arendt wrote:
>  Jeff Spaleta wrote:
>  > I'm not talking about QA.. I'm talking about verifying that the
>  > volunteer maintainers are actually still in place a year+ later.  How
>  > do make users aware that packages are unmaintained for 1+ years? Do
>  > you plan to expire unmaintained packages so new users don't have
>  > access to them?You have to have some process to verify that the
>  > maintainers are there because you are explicitly stating that the life
>  > of branch depends on an accurate count of the active maintainers. if
>  > you don't build a process to try to verify maintainer involvement..the
>  > branches could live forever because there is no pre-defined EOL.
>  >
>  >   
>  I really don't see how a Fedora Legacy can be maintained. 
Ask yourselves: How
can EPEL be maintained?

>    If the goal is increased stability and security patches, 
The
goal would be "extended life-time" at "no guarantees/use at your own
risk".

>   you need to guarantee that you have 
>  folks supporting
>  backpatches to the kernel, glibc, firefox, evolution,  openoffice, and 
>  several other large
>  and complex packages.  Incorporating new security patches into old 
>  baselines is *hard*. 
Right, ... the consequence would be instability and security
risks
gradually creeping in. 

This is bad, nevertheless it still would better than letting people stay
with totally discontinued/unmaintained Fedoras or with driving them away
from Fedora and redirecting them to CentOS or RHEL.

>  Plus Fedora would "fork" a new release every 6 months.  How
> many legacy
>  Fedora's would be retained?  At some point it seems the legacy volunteer 
>  force
>  would saturate and legacy Fedora's would have to start dropping off 
>  every 6 months. 
Right, ... nevertheless, such an extended life-time would provide people
more time to upgrade to a newer Fedora.

Ralf

reviving Fedora Legacy

[Michael Schwendt]

On Mon, 13 Oct 2008 08:16:49 +0200, Ralf Corsepius wrote:

>  On Sun, 2008-10-12 at 18:22 -0700, Bob Arendt wrote:
>
>  > I really don't see how a Fedora Legacy can be maintained.
>
>  Ask yourselves: How can EPEL be maintained? 
It's a relatively new project. It still has to prove that it will be
maintained properly after two or more years. Let's wait and see how the
EPEL packagers will react to the first build troubles, where they will get
failures because current Fedora and upstream are versions ahead of RHEL
and they cannot simply push a version upgrade into EPEL.

EPEL itself doesn't even have the man-power to fix the repoclosure
report. The person who broke it almost half a year ago could simply
revert the broken changes, but even that doesn't happen.

reviving Fedora Legacy

[Chuck Anderson]

On Sun, Oct 12, 2008 at 05:02:30PM -0800, Jeff Spaleta wrote:
>  Honestly after several days of discussion this week are the
> proponents
>  any further along than what was proposed in the UAEL draft? I haven't
>  seen a single new idea.   
Like my ideas above about having a 6 month timeframe for UAEL?

>  Until someone new, who is committed to moving an implementation 
>  forward steps forward, this discussion is moot. Would WPI give you 
>  some infrastructure resources to burn on this to supplement existing 
>  project infrastructure to demonstrate that it was a sustainable 
>  effort? 
Sure, what is needed?  Nothing that isn't already provided by Fedora 
Infrastructure as far as I can see.

reviving Fedora Legacy

[Horst H. von Brand]

Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:

[...]

>  Openly said, my impression that certain parties in Fedora fear a
> Fedora
>  LTS rsp. life-time-extended Fedora to compete with RH products. 
CentOS or other repackaged RHEL is a /much/ greater threat than any Fedora
LTS could ever be... and much easier to maintain to boot. And Red Hat is
going out of its way to make them possible (by segregating the Red Hat only
stuff in easily replaced packages, by not adding a Red Hat icon to
everything they ship (that would be rather easy), by keeping the
distribution as such under GPL, by making the SRPMs publicly available,
even if they aren't forced to do so (yes, there is lots of non-GPL stuff in
RHEL; and GPL doesn't say you have to give source out to everybody freely,
just to anybody who got the binaries and asks)).

This conspiracy theory makes little sense (does any?).
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

reviving Fedora Legacy

[David Woodhouse]

On Sun, 2008-10-12 at 11:35 +0200, Ralf Corsepius wrote:
>  Similar proposals have come up several times before (I once proposed
>  something like this), but so far, they all had been shoot down so far.
>  
>  Openly said, my impression that certain parties in Fedora fear a Fedora
>  LTS rsp. life-time-extended Fedora to compete with RH products. 
I understand that there is a market for a Fedora-based distribution
which doesn't receive megabytes of updates each week, and which is
supported for longer than a year.

Those are reasonable and understandable desires, although they aren't
something that I want personally.

What I _don't_ understand is why these requirements are not met by
CentOS. Isn't that _precisely_ the 'market' that RHEL and CentOS exist
to serve?

Perhaps I've been inattentive; if so then I apologise. But could someone
please state for the record precisely what they want when they ask for
'Fedora LTS', that CentOS doesn't provide?

As I see it, there is a continuum of sorts -- from the daily churn of
rawhide, through the less anarchic but still considerable churn of the
latest Fedora release (currently F9), to the more conservative set of
updates for the previous release (F8), and then a bit of a jump to the
long-term stagnation¹ of RHEL/CentOS. You can pick whichever one you
like, according to your needs.

There is _perhaps_ some reason to desire some kind of middle ground
between CentOS and the outgoing Fedora release. But is there _such_ a
wide gap between the two that it's worth creating a completely new
distribution to fill it?

It seems like you're trying to make a completely new bikeshed, because
you think you want it a _slightly_ different hue to the existing one.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse(a)intel.com                              Intel Corporation

¹ in this case, 'stagnation' is a feature rather than being derogatory.

reviving Fedora Legacy

[Patrice Dumas]

On Mon, Oct 13, 2008 at 01:18:01PM +0100, David Woodhouse wrote:
>  
>  I understand that there is a market for a Fedora-based distribution
>  which doesn't receive megabytes of updates each week, and which is
>  supported for longer than a year. 
What have been proposed so far doesn't solve the 'which doesn't receive
megabytes of updates each week' part, only the 'supported for longer
than a year' part.

>  What I _don't_ understand is why these requirements are not met
> by
>  CentOS. Isn't that _precisely_ the 'market' that RHEL and CentOS exist
>  to serve? 
Because it is not the same as you stress yourself. Centos is clearly not
the same than 'Fedora-based distribution which is supported for longer 
than a year'. It allows to use innovative technologies while not being
forced to update each year.

>  As I see it, there is a continuum of sorts -- from the daily churn
> of
>  rawhide, through the less anarchic but still considerable churn of the
>  latest Fedora release (currently F9), to the more conservative set of
>  updates for the previous release (F8), and then a bit of a jump to the
>  long-term stagnation¹ of RHEL/CentOS. You can pick whichever one you
>  like, according to your needs. 
The last jump is not realistic in all cases. What should F6 user jump
to? Centos 5? Centos 6? And F8 users?

>  There is _perhaps_ some reason to desire some kind of middle ground
>  between CentOS and the outgoing Fedora release. But is there _such_ a
>  wide gap between the two that it's worth creating a completely new
>  distribution to fill it? 
The proposal is not to create a new distribution, but simply haev EOLed
branches acl removed and leave th epossibility to build and push th
eresults, with a limitation of the changes to grave bug fixes and
security issues.

>  It seems like you're trying to make a completely new bikeshed,
> because
>  you think you want it a _slightly_ different hue to the existing one. 
Who wants that?

(That being said, it is also possible that 'which doesn't receive 
megabytes of updates each week' issue may deserve to be looked at, but
it is a different issue).
--
Pat

reviving Fedora Legacy

[Josh Boyer]

On Mon, Oct 13, 2008 at 02:29:55PM +0200, Patrice Dumas wrote:
> On Mon, Oct 13, 2008 at 01:18:01PM +0100, David Woodhouse wrote:
> > 
> > I understand that there is a market for a Fedora-based distribution
> > which doesn't receive megabytes of updates each week, and which is
> > supported for longer than a year.
>
> What have been proposed so far doesn't solve the 'which doesn't receive
> megabytes of updates each week' part, only the 'supported for longer
> than a year' part.
>
> > What I _don't_ understand is why these requirements are not met by
> > CentOS. Isn't that _precisely_ the 'market' that RHEL and CentOS exist
> > to serve?
>
> Because it is not the same as you stress yourself. Centos is clearly not
> the same than 'Fedora-based distribution which is supported for longer 
> than a year'. It allows to use innovative technologies while not being
> forced to update each year. 
That, to me, sounds like you want to update/backport $new_hotness of the
day to Fedora LTS.  And that, to me, sounds like pain.

As an example, CentoOS and RHEL5 don't support KVM.  Would you want the
ability to backport KVM (or features like it) to a Fedora LTS?  If so,
that way lies madness.

> The proposal is not to create a new distribution, but simply haev
> EOLed
> branches acl removed and leave th epossibility to build and push th
> eresults, with a limitation of the changes to grave bug fixes and
> security issues. 
Except that conflicts with what you said above about "...use innovative
technologies while not being forced to update each year.".

josh

reviving Fedora Legacy

[Patrice Dumas]

On Mon, Oct 13, 2008 at 09:11:24AM -0400, Josh Boyer wrote:
>  
>  >The proposal is not to create a new distribution, but simply haev EOLed
>  >branches acl removed and leave th epossibility to build and push th
>  >eresults, with a limitation of the changes to grave bug fixes and
>  >security issues.
>  
>  Except that conflicts with what you said above about "...use innovative
>  technologies while not being forced to update each year.". 
I wasn't clear, I should have said 'use innovative technologies during
the time fedora is not eol', while not being forced to update each year
(that's for the 'LTS' part).

--
Pat

reviving Fedora Legacy

[Josh Boyer]

On Mon, Oct 13, 2008 at 03:17:53PM +0200, Patrice Dumas wrote:
> On Mon, Oct 13, 2008 at 09:11:24AM -0400, Josh Boyer wrote:
> > 
> > >The proposal is not to create a new distribution, but simply haev EOLed
> > >branches acl removed and leave th epossibility to build and push th
> > >eresults, with a limitation of the changes to grave bug fixes and
> > >security issues.
> > 
> > Except that conflicts with what you said above about "...use innovative
> > technologies while not being forced to update each year.".
>
> I wasn't clear, I should have said 'use innovative technologies during
> the time fedora is not eol', while not being forced to update each year
> (that's for the 'LTS' part). 
Ah.  And how is that different from CentOS?  At the time CentOS 5 was
release, it also contained the latest "innovative" technologies.  So,
what would be different about a Fedora LTS?

josh

reviving Fedora Legacy

[Patrice Dumas]

On Mon, Oct 13, 2008 at 09:23:37AM -0400, Josh Boyer wrote:
>  
>  Ah.  And how is that different from CentOS?  At the time CentOS 5 was
>  release, it also contained the latest "innovative" technologies.  So,
>  what would be different about a Fedora LTS? 
Because it is not possible to switch to centos from all fedora releases.
Right now you cannot switch from F8 to any centos, and even an updated F6
couldn't switch to centos 5. So it would be interesting for F6, F7, F8.
Maybe not F9 if switching from an updated F9 to centos 6 is possible,
but will centos 6 be ready in 6 months?

--
Pat

reviving Fedora Legacy

[Jeffrey Ollie]

On Mon, Oct 13, 2008 at 8:55 AM, Patrice Dumas <pertusus(a)free.fr&gt; wrote:
>  On Mon, Oct 13, 2008 at 09:23:37AM -0400, Josh Boyer wrote:
> >
> > Ah.  And how is that different from CentOS?  At the time CentOS 5 was
> > release, it also contained the latest "innovative" technologies.  So,
> > what would be different about a Fedora LTS?
>
>  Because it is not possible to switch to centos from all fedora releases.
>  Right now you cannot switch from F8 to any centos, and even an updated F6
>  couldn't switch to centos 5. So it would be interesting for F6, F7, F8.
>  Maybe not F9 if switching from an updated F9 to centos 6 is possible,
>  but will centos 6 be ready in 6 months? 
If you have a system you are developing that needs to run on
RHEL/CentOS, you start development on RHEL/CentOS not on Fedora.  The
same goes for anything - if you were going to deploy on Ubuntu 8.04
(the most recent LTS version) you wouldn't start development on Ubuntu
8.10 would you?

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"

reviving Fedora Legacy

[Les Mikesell]

Jeffrey Ollie wrote:
>  On Mon, Oct 13, 2008 at 8:55 AM, Patrice Dumas
> <pertusus(a)free.fr&gt; wrote:
> > On Mon, Oct 13, 2008 at 09:23:37AM -0400, Josh Boyer wrote:
> >> Ah.  And how is that different from CentOS?  At the time CentOS 5 was
> >> release, it also contained the latest "innovative" technologies.  So,
> >> what would be different about a Fedora LTS?
> > Because it is not possible to switch to centos from all fedora releases.
> > Right now you cannot switch from F8 to any centos, and even an updated F6
> > couldn't switch to centos 5. So it would be interesting for F6, F7, F8.
> > Maybe not F9 if switching from an updated F9 to centos 6 is possible,
> > but will centos 6 be ready in 6 months?
>  
>  If you have a system you are developing that needs to run on
>  RHEL/CentOS, you start development on RHEL/CentOS not on Fedora. 
That doesn't make sense.  If you expect your system to run on RH6 that 
would mean you couldn't start development until after it is released.

>  The
>  same goes for anything - if you were going to deploy on Ubuntu 8.04
>  (the most recent LTS version) you wouldn't start development on Ubuntu
>  8.10 would you? 
You don't plan to release something new on the last version of a 
distribution, you plan for the next - so yes, Ubuntu 8.10 would be a 
suitable development platform and Ubuntu has so far had a reasonable 
update process to their next versions (but admittedly they haven't had a 
hard one like going from a 2.4 to a 2.6 kernel yet).

-- 
   Les Mikesell
     lesmikesell(a)gmail.com

reviving Fedora Legacy

[Jeffrey Ollie]

On Mon, Oct 13, 2008 at 9:33 AM, Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:
>  Jeffrey Ollie wrote:
> >
> > On Mon, Oct 13, 2008 at 8:55 AM, Patrice Dumas <pertusus(a)free.fr&gt; wrote:
> >>
> >> On Mon, Oct 13, 2008 at 09:23:37AM -0400, Josh Boyer wrote:
> >>>
> >>> Ah.  And how is that different from CentOS?  At the time CentOS 5 was
> >>> release, it also contained the latest "innovative" technologies. 
> So,
> >>> what would be different about a Fedora LTS?
> >>
> >> Because it is not possible to switch to centos from all fedora releases.
> >> Right now you cannot switch from F8 to any centos, and even an updated F6
> >> couldn't switch to centos 5. So it would be interesting for F6, F7, F8.
> >> Maybe not F9 if switching from an updated F9 to centos 6 is possible,
> >> but will centos 6 be ready in 6 months?
> >
> > If you have a system you are developing that needs to run on
> > RHEL/CentOS, you start development on RHEL/CentOS not on Fedora.
>
>  That doesn't make sense.  If you expect your system to run on RH6 that would
>  mean you couldn't start development until after it is released. 
Sure it makes sense.  With RHEL being supported for 7 years, I can
spend a year or so developing my service on RHEL X and have five or
six years before I have to upgrade to RHEL X+1 or X+2.

> > The
> > same goes for anything - if you were going to deploy on Ubuntu 8.04
> > (the most recent LTS version) you wouldn't start development on Ubuntu
> > 8.10 would you?
>
>  You don't plan to release something new on the last version of a
>  distribution, you plan for the next - so yes, Ubuntu 8.10 would be a
>  suitable development platform and Ubuntu has so far had a reasonable update
>  process to their next versions (but admittedly they haven't had a hard one
>  like going from a 2.4 to a 2.6 kernel yet). 
Well it really depends on what I was building.  If I was developing a
new desktop application what you say might make sense.  If I was
developing an e-commerce web site you'd be nuts to do that.

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"

reviving Fedora Legacy

[Les Mikesell]

Jeffrey Ollie wrote:
>  
>  Well it really depends on what I was building.  If I was developing a
>  new desktop application what you say might make sense.  If I was
>  developing an e-commerce web site you'd be nuts to do that. 
But then you'd probably use java to isolate yourself as much as possible 
from silly API changes in OS and distributions...  And fedora hasn't 
been a great place to use java.

-- 
   Les Mikesell
     lesmikesell(a)gmail.com

reviving Fedora Legacy

[Jeffrey Ollie]

On Mon, Oct 13, 2008 at 11:00 AM, Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:
>  Jeffrey Ollie wrote:
> >
> > Well it really depends on what I was building.  If I was developing a
> > new desktop application what you say might make sense.  If I was
> > developing an e-commerce web site you'd be nuts to do that.
>
>  But then you'd probably use java to isolate yourself as much as possible
>  from silly API changes in OS and distributions...  And fedora hasn't been a
>  great place to use java. 
I'm not a Java developer (I've written a few "Hello World" type things
but nothing more complex than that) but from what I've seen from
deploying a few Java-based systems is that while the "core" Java API
may be stable, "real-world" Java systems have dependencies on things
like Tomcat/Apache or other similar systems and are highly dependent
on particular versions of those apps and associated libraries.

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"

reviving Fedora Legacy

[Robert 'Bob' Jensen]

Fedora Legacy is DEAD, maybe call it Fedora Zombie. Walking dead packages, Walking dead
packagers from trying to keep up...

Robert 'Bob' Jensen

reviving Fedora Legacy

[Les Mikesell]

Jeffrey Ollie wrote:
>  
> >> Well it really depends on what I was building.  If I was developing a
> >> new desktop application what you say might make sense.  If I was
> >> developing an e-commerce web site you'd be nuts to do that.
> > But then you'd probably use java to isolate yourself as much as possible
> > from silly API changes in OS and distributions...  And fedora hasn't been a
> > great place to use java.
>  
>  I'm not a Java developer (I've written a few "Hello World" type things
>  but nothing more complex than that) but from what I've seen from
>  deploying a few Java-based systems is that while the "core" Java API
>  may be stable, "real-world" Java systems have dependencies on things
>  like Tomcat/Apache or other similar systems and are highly dependent
>  on particular versions of those apps and associated libraries. 
Agreed, but I'm not sure where this point leads.  Fedora has been fairly 
horrible about consistency in those areas too.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

reviving Fedora Legacy

[Horst H. von Brand]

Patrice Dumas <pertusus(a)free.fr&gt; wrote:

[...]

>  I wasn't clear, I should have said 'use innovative
> technologies during
>  the time fedora is not eol', while not being forced to update each year
>  (that's for the 'LTS' part). 
OK, so you want not to have to upgrade _and_ the latest technology...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

reviving Fedora Legacy

[David Woodhouse]

On Mon, 2008-10-13 at 14:29 +0200, Patrice Dumas wrote:
>  On Mon, Oct 13, 2008 at 01:18:01PM +0100, David Woodhouse wrote:
>  > 
>  > I understand that there is a market for a Fedora-based distribution
>  > which doesn't receive megabytes of updates each week, and which is
>  > supported for longer than a year.
>  
>  What have been proposed so far doesn't solve the 'which doesn't receive
>  megabytes of updates each week' part, only the 'supported for longer
>  than a year' part.
>  
>  > What I _don't_ understand is why these requirements are not met by
>  > CentOS. Isn't that _precisely_ the 'market' that RHEL and CentOS exist
>  > to serve?
>  
>  Because it is not the same as you stress yourself. Centos is clearly not
>  the same than 'Fedora-based distribution which is supported for longer 
>  than a year'. It allows to use innovative technologies while not being
>  forced to update each year. 
This is the part I have difficulty understanding. You want to use new
and innovative technologies, but you don't want to update your nice
stable system?

Do you want a perpetual motion machine with that too?

You're right -- you are offered updates, or you are offered stability,
and there isn't much of a middle ground. But that's just reality.

>  > As I see it, there is a continuum of sorts -- from the daily
> churn of
>  > rawhide, through the less anarchic but still considerable churn of the
>  > latest Fedora release (currently F9), to the more conservative set of
>  > updates for the previous release (F8), and then a bit of a jump to the
>  > long-term stagnation¹ of RHEL/CentOS. You can pick whichever one you
>  > like, according to your needs.
>  
>  The last jump is not realistic in all cases. What should F6 user jump
>  to? Centos 5? Centos 6? And F8 users? 
F6 is basically RHEL4/CentOS 4 for the most part, isn't it?
And F8 would probably be closest to RHEL5/CentOS 5.

>  The proposal is not to create a new distribution, but simply have
>  EOLed branches acl removed and leave the possibility to build and push
>  the results, with a limitation of the changes to grave bug fixes and
>  security issues. 
So no new innovation then? And you'd want to do this for _every_
six-monthly release of Fedora? Surely that's a whole boatload of effort
you don't need? Why not just do it for every other release? Or, perhaps
more usefully, every third release -- a new one about every 18 months?

I see no fundamental reason why we should _forbid_ people from doing
security updates for packages in EOL distributions, although I'm very
wary of the expectations that it would create. If we ship
official-looking updates for _some_ security bugs, naïve users will
quite reasonably expect that they'll be receiving updates for _all_
serious security bugs, and our "You are unsupported; you need to upgrade
before you get hacked" message will be compromised.

I also think that with a niche market that small, between Fedora and
CentOS, you are unlikely to get enough volunteers to keep it viable --
isn't that what happened with Fedora Legacy last time? 

>  (That being said, it is also possible that 'which doesn't
> receive 
>  megabytes of updates each week' issue may deserve to be looked at, but
>  it is a different issue). 
That and/or ensuring that the packages you miss in CentOS are actually
in EPEL.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse(a)intel.com                              Intel Corporation

reviving Fedora Legacy

[Ralf Corsepius]

On Mon, 2008-10-13 at 14:33 +0100, David Woodhouse wrote:
>  On Mon, 2008-10-13 at 14:29 +0200, Patrice Dumas wrote:
>  > On Mon, Oct 13, 2008 at 01:18:01PM +0100, David Woodhouse wrote:
>  > > 
>  > > I understand that there is a market for a Fedora-based distribution
>  > > which doesn't receive megabytes of updates each week, and which is
>  > > supported for longer than a year.
>  > 
>  > What have been proposed so far doesn't solve the 'which doesn't receive
>  > megabytes of updates each week' part, only the 'supported for longer
>  > than a year' part.
>  > 
>  > > What I _don't_ understand is why these requirements are not met by
>  > > CentOS. Isn't that _precisely_ the 'market' that RHEL and CentOS
> exist
>  > > to serve?
>  > 
>  > Because it is not the same as you stress yourself. Centos is clearly not
>  > the same than 'Fedora-based distribution which is supported for longer 
>  > than a year'. It allows to use innovative technologies while not being
>  > forced to update each year.
>  
>  This is the part I have difficulty understanding. You want to use new
>  and innovative technologies, but you don't want to update your nice
>  stable system? 
It's not necessarily a matter of will on the user's side.

It often is a matter of situations where you can't upgrade because your
personal restrictions aren't synch'ed with Fedora's schedule.

>  > The proposal is not to create a new distribution, but simply
> have
>  > EOLed branches acl removed and leave the possibility to build and push
>  > the results, with a limitation of the changes to grave bug fixes and
>  > security issues.
>  
>  So no new innovation then?  
Yes, just bug fixes for those bugs contributors find
time to look into.

If things blow up, they blow up, still better than users using an
entirely unmaintained distro.

>  And you'd want to do this for _every_
>  six-monthly release of Fedora? Surely that's a whole boatload of effort
>  you don't need? Why not just do it for every other release? Or, perhaps
>  more usefully, every third release -- a new one about every 18 months? 
This would
be an alternative. 

In this case, I'd use those Fedora releases RHEL releases are being
derived from, because this would allow to harvest RHEL packages.

reviving Fedora Legacy

[Patrice Dumas]

On Mon, Oct 13, 2008 at 02:33:51PM +0100, David Woodhouse wrote:
>  > 
>  > Because it is not the same as you stress yourself. Centos is clearly not
>  > the same than 'Fedora-based distribution which is supported for longer 
>  > than a year'. It allows to use innovative technologies while not being
>  > forced to update each year.
>  
>  This is the part I have difficulty understanding. You want to use new
>  and innovative technologies, but you don't want to update your nice
>  stable system?
>  
>  You're right -- you are offered updates, or you are offered stability,
>  and there isn't much of a middle ground. But that's just reality. 
There can be a change in time, 1 year of innovative technologies and 
then only critical updates, if fedora maintainers are volunteering to
keep on doing critical updates. And I even think that 6 months of
innovative technologies, 6 months with a slowdown in updates, only
important updates, on user demand and then only critical fixes as long
as a maintainer is doing them would even be better.

>  > The last jump is not realistic in all cases. What should F6 user
> jump
>  > to? Centos 5? Centos 6? And F8 users?
>  
>  F6 is basically RHEL4/CentOS 4 for the most part, isn't it? 
If I recall well, FC-5 could be upgraded to RHEL/EPEL, but not a fully
uptodate FC-6.

>  And F8 would probably be closest to RHEL5/CentOS 5. 
Not necessarily. F8 could already be way ahead from RHEL5/Centos5/EPEL5 
(although it is likely not to be the case in reality since EPEL, for 
instance is relatively new). The reverse is also possible, but if a
maintainer still pushed updates to F-8 until th eend, then F-8 should be
much newer than EL-5.

That being said I'd do what I can to help with having better update
paths, between fedora distros and between fedora and RHEL/Centos, but I
can't see what else I can do, at least for all the packages I 
(co-)maintain. But this doesn't remove the need for more than one year
support on a volunteer basis.

>  So no new innovation then? And you'd want to do this for _every_
>  six-monthly release of Fedora? Surely that's a whole boatload of effort
>  you don't need? Why not just do it for every other release? Or, perhaps
>  more usefully, every third release -- a new one about every 18 months? 
That's up to the packagers. My hope is that if there is an argeement
than the above is possible, a SIG is constituted and people agree on
that. This may lead to different result depending on what packagers
wants to do.

>  I see no fundamental reason why we should _forbid_ people from doing
>  security updates for packages in EOL distributions, although I'm very
>  wary of the expectations that it would create. If we ship
>  official-looking updates for _some_ security bugs, naïve users will
>  quite reasonably expect that they'll be receiving updates for _all_
>  serious security bugs, and our "You are unsupported; you need to upgrade
>  before you get hacked" message will be compromised. 
The updates may be pushed to another location than the usual updates
directory, such that it is not in the fedora name.

>  I also think that with a niche market that small, between Fedora and
>  CentOS, you are unlikely to get enough volunteers to keep it viable --
>  isn't that what happened with Fedora Legacy last time?  
Repeating once again, this is quite different from legacy, because this
is the same set of rule, there is no heavy QA, only what is done
normally in fedora, so the entrance barrier is much lower. I personnally
considered helping legacy but is was so different from fedora and so
complicated that I gave up.

>  That and/or ensuring that the packages you miss in CentOS are
> actually
>  in EPEL. 
I don't miss any package in EPEL, when I miss one I (co-)maintain it. 
Still I'd prefer to be able to suggest people asking me which distro to
choose to use fedora and not ubuntu (in case RHEL/Centos is not the right
distro for them), like I have to do today, because of the one year only
support.

--
Pat

reviving Fedora Legacy

[Kevin Kofler]

Patrice Dumas <pertusus <at> free.fr> writes:
>  If I recall well, FC-5 could be upgraded to RHEL/EPEL, but not a
> fully
>  uptodate FC-6. 
Even an updated FC5 doesn't upgrade safely to EL5. For example, the kernel and 
KDE are newer in FC5 updates than in EL5. I'm sure there are more such 
packages.

        Kevin Kofler

reviving Fedora Legacy

[Horst H. von Brand]

Patrice Dumas <pertusus(a)free.fr&gt; wrote:

[...]

>  There can be a change in time, 1 year of innovative technologies
Fedora users are happy, you are grumbling that your "stable" setup
breaks each other day...

>                                                                   and
>
>  then only critical updates, 
... and now you are happy, while Fedora users leave disappointed that there
is no new technology... and next cycle is a _huge_ jump, and your grumbling
can only get worse.

>                              if fedora maintainers are volunteering
> to
>  keep on doing critical updates. 
They aren't. It is enough of a chore to track upstream, to track upstream
_and_ backport fixes is too much to ask. And most fun comes to your average
geek from playing with the newest, shiniest toy around...

>                                  And I even think that 6 months of
>  innovative technologies, 6 months with a slowdown in updates, only
>  important updates, on user demand and then only critical fixes as long
>  as a maintainer is doing them would even be better. 
Tell you what, this is /exactly/ (well, almost) what you'd get following
CentOS or RHEL, only /without/ screwing up Fedora.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

reviving Fedora Legacy

[Thorsten Leemhuis]

On 13.10.2008 14:18, David Woodhouse wrote:
>  On Sun, 2008-10-12 at 11:35 +0200, Ralf Corsepius wrote:
>  
>  Perhaps I've been inattentive; if so then I apologise. But could someone
>  please state for the record precisely what they want when they ask for
>  'Fedora LTS', that CentOS doesn't provide? 
Sounds stupid, but afaics it's just two:

(1) having Fedora in the name.

(2) having all the package available that are Fedora and Add-On repos ship


"1" sounds stupid, but afaics it's really a big problem for a lot of 
people. They simply view CentOS as something completely different, which 
  it IMHO not really is. Maybe Fedora and CentOS should merge? Or maybe 
RH should simply start to distribute the RHEL bits freely.

Problem "2" is slowly getting fixed; EPEL now ships lots of those Fedora 
packages that are missing in RHEL/CentOS. More are needed, but that will 
happen over time. RPM Fusion will soon support RHEL/CentOS + EPEL as 
well, so most things soon will just work similarly on Fedora and 
RHEL/CentOS.

CU
knurd

reviving Fedora Legacy

[Ralf Corsepius]

On Mon, 2008-10-13 at 14:56 +0200, Thorsten Leemhuis wrote:
>  On 13.10.2008 14:18, David Woodhouse wrote:
>  > On Sun, 2008-10-12 at 11:35 +0200, Ralf Corsepius wrote:
>  > 
>  > Perhaps I've been inattentive; if so then I apologise. But could someone
>  > please state for the record precisely what they want when they ask for
>  > 'Fedora LTS', that CentOS doesn't provide?
>  
>  Sounds stupid, but afaics it's just two:
>  
>  (1) having Fedora in the name. 
* CentOS/RHEL often are outdated in details, even in
comparison with older Fedoras.
* RHEL being non-free.

>  (2) having all the package available that are Fedora and Add-On repos
> ship 
* Right, there is a huge gap between the packages being shipped by RHEL
+EPEL and those of Fedora.

>  "1" sounds stupid, but afaics it's really a big problem
> for a lot of 
>  people. They simply view CentOS as something completely different, which 
>    it IMHO not really is. 
I disagree, CentOS and Fedora are completely different,
e.g. on the
"project control/management" side, target-audience wise and
feature-wise.

>   Maybe Fedora and CentOS should merge? 
Yes, this would be an
improvement.

>   Or maybe 
>  RH should simply start to distribute the RHEL bits freely. 
And this would be an
even better alternative, but it's not that I would
expect this to ever happen.

Ralf

reviving Fedora Legacy

[Nicolas Mailhot]

Le Lun 13 octobre 2008 15:09, Ralf Corsepius a écrit :
>  On Mon, 2008-10-13 at 14:56 +0200, Thorsten Leemhuis wrote: 
> > (2) having all the package available that are Fedora and Add-On
> > repos ship
>  * Right, there is a huge gap between the packages being shipped by
>  RHEL
>  +EPEL and those of Fedora. 
And there has nothing to do with the project name. Re-christening EPEL
Fedora LTS won't magically increase contributors.

-- 
Nicolas Mailhot

reviving Fedora Legacy

[Thorsten Leemhuis]

On 13.10.2008 15:09, Ralf Corsepius wrote:
>  On Mon, 2008-10-13 at 14:56 +0200, Thorsten Leemhuis wrote:
> > On 13.10.2008 14:18, David Woodhouse wrote:
> >> On Sun, 2008-10-12 at 11:35 +0200, Ralf Corsepius wrote:
>  [...]
> > "1" sounds stupid, but afaics it's really a big problem for a lot of 
> > people. They simply view CentOS as something completely different, which 
> >   it IMHO not really is.
>  I disagree, CentOS and Fedora are completely different, e.g. on the
>  "project control/management" side, target-audience wise and
>  feature-wise. 
Of course they are quite different in those areas. But when RHEL5 came 
out it felt and looked a lot like a slightly modified and enhanced 
Fedora Core 5 or 6 (which it was)-- that is want I meant ;-)

>  [...]
> >  Or maybe 
> > RH should simply start to distribute the RHEL bits freely.
>  And this would be an even better alternative, but it's not that I would
>  expect this to ever happen. 
Well, if things continue like in the past two years then the younger 
generation will only learn the Debian and Ubuntu way; that will 
influence the decisions which Linux distribution to take when those 
people get older and become decisions makers (the Wikipedia change is a 
good example for it afaics). Hence Red Hat and Fedora afaics really need 
to change some things become a bit more popular again if Red Hat wants 
to continue making money in the long run ;-)

Cu
knurd

reviving Fedora Legacy

[Ralf Corsepius]

On Mon, 2008-10-13 at 15:24 +0200, Thorsten Leemhuis wrote:
>  On 13.10.2008 15:09, Ralf Corsepius wrote:
>  > On Mon, 2008-10-13 at 14:56 +0200, Thorsten Leemhuis wrote:
>  >> On 13.10.2008 14:18, David Woodhouse wrote:
>  >>> On Sun, 2008-10-12 at 11:35 +0200, Ralf Corsepius wrote:
>   > [...]
>  >> "1" sounds stupid, but afaics it's really a big problem for a lot
> of 
>  >> people. They simply view CentOS as something completely different, which 
>  >>   it IMHO not really is.
>  > I disagree, CentOS and Fedora are completely different, e.g. on the
>  > "project control/management" side, target-audience wise and
>  > feature-wise.
>  
>  Of course they are quite different in those areas. But when RHEL5 came 
>  out it felt and looked a lot like a slightly modified and enhanced 
>  Fedora Core 5 or 6 (which it was)-- that is want I meant ;-) 
True, at the time
RHEL5 was new, it had been more or less a rebuilt
FC5/6 and switching between them had not been a major problem.

Nowadays, it isn't anymore and even will be less when FC10 comes out.

I.e. to today's FC7 or FC8 users, RHEL5 or CentOS5 are not viable
alternatives. They are kind of a flashback to yesterday's state-of-art.

>  > [...]
>  >>  Or maybe 
>  >> RH should simply start to distribute the RHEL bits freely.
>  > And this would be an even better alternative, but it's not that I would
>  > expect this to ever happen.
>  
>  Well, if things continue like in the past two years then the younger 
>  generation will only learn the Debian and Ubuntu way; that will 
>  influence the decisions which Linux distribution to take when those 
>  people get older and become decisions makers (the Wikipedia change is a 
>  good example for it afaics). Hence Red Hat and Fedora afaics really need 
>  to change some things become a bit more popular again if Red Hat wants 
>  to continue making money in the long run ;-) 
Chapeau! I whole-heartily agree.

Ralf

reviving Fedora Legacy

[Jeffrey Ollie]

On Mon, Oct 13, 2008 at 8:38 AM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  True, at the time RHEL5 was new, it had been more or less a rebuilt
>  FC5/6 and switching between them had not been a major problem.
>
>  Nowadays, it isn't anymore and even will be less when FC10 comes out.
>
>  I.e. to today's FC7 or FC8 users, RHEL5 or CentOS5 are not viable
>  alternatives. They are kind of a flashback to yesterday's state-of-art. 
Well, DUH!

Long term stability is achieved by *NOT ADDING NEW FEATURES*.  *ADDING
NEW FEATURES INTRODUCES NEW BUGS*
*YOU CAN'T HAVE YOUR CAKE AND EAT IT TOO*

Sorry for shouting, but all of these people demanding a "Fedora LTS"
don't seem to get this fundamental point.

I mean really, if RHEL5 switched from KDE3.5 to KDE4.0 I'd be
screaming bloody murder. Or even from BIND 9.3 to BIND 9.5.  Or
whatever.

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"

reviving Fedora Legacy

[Ralf Corsepius]

On Mon, 2008-10-13 at 09:03 -0500, Jeffrey Ollie wrote:
>  On Mon, Oct 13, 2008 at 8:38 AM, Ralf Corsepius
> <rc040203(a)freenet.de&gt; wrote:
>  >
>  > True, at the time RHEL5 was new, it had been more or less a rebuilt
>  > FC5/6 and switching between them had not been a major problem.
>  >
>  > Nowadays, it isn't anymore and even will be less when FC10 comes out.
>  >
>  > I.e. to today's FC7 or FC8 users, RHEL5 or CentOS5 are not viable
>  > alternatives. They are kind of a flashback to yesterday's state-of-art.
>  
>  Well, DUH!
>  
>  Long term stability is achieved by *NOT ADDING NEW FEATURES*.  *ADDING
>  NEW FEATURES INTRODUCES NEW BUGS*
>  *YOU CAN'T HAVE YOUR CAKE AND EAT IT TOO*
>  
>  Sorry for shouting, but all of these people demanding a "Fedora LTS"
>  don't seem to get this fundamental point. 
WHAT? Guess why people are demanding
for a *FEDORA LTS* and are not
demanding for RHEL5 or CENTOS.

Answer: RHEL5 is not a replacement for a lifetime extended current
Fedora.

Rationale, e.g. this:
>  I mean really, if RHEL5 switched from KDE3.5 to KDE4.0 I'd be
>  screaming bloody murder. Or even from BIND 9.3 to BIND 9.5.  Or
>  whatever. 
If Fedora and RHEL were synch'ed, things would be different.

Ralf

reviving Fedora Legacy

[Josh Boyer]

On Mon, Oct 13, 2008 at 04:12:40PM +0200, Ralf Corsepius wrote:
> Answer: RHEL5 is not a replacement for a lifetime extended current
> Fedora. 
Extended for how long?  Fedora releases are supported for roughly
13 months (1 month after N+2 is released).  Actually longer if you
take into account the slips that inevitably hit during each release
cycle.

So, what _exactly_ are you asking for?

josh

reviving Fedora Legacy

[Patrice Dumas]

On Mon, Oct 13, 2008 at 10:14:52AM -0400, Josh Boyer wrote:
>  On Mon, Oct 13, 2008 at 04:12:40PM +0200, Ralf Corsepius wrote:
>  >Answer: RHEL5 is not a replacement for a lifetime extended current
>  >Fedora.
>  
>  Extended for how long?  Fedora releases are supported for roughly
>  13 months (1 month after N+2 is released).  Actually longer if you
>  take into account the slips that inevitably hit during each release
>  cycle.
>  
>  So, what _exactly_ are you asking for? 
That infrastructure for EOLed Fedora is not shut down such that
maintainers can keep on maintaining packages, with an emphasis on
critical updates only, as long as they want. In my proposal I said no
more than 5 years (but could be 3 if you want I don't care), and as long
as it doesn't mean specific extra work for nonvolunteering people in the 
infrastructure team.

--
Pat

reviving Fedora Legacy

[Ralf Corsepius]

On Mon, 2008-10-13 at 10:14 -0400, Josh Boyer wrote:
>  On Mon, Oct 13, 2008 at 04:12:40PM +0200, Ralf Corsepius wrote:
>  >Answer: RHEL5 is not a replacement for a lifetime extended current
>  >Fedora.
>  
>  Extended for how long?  Fedora releases are supported for roughly
>  13 months (1 month after N+2 is released).  Actually longer if you
>  take into account the slips that inevitably hit during each release
>  cycle.
>  
>  So, what _exactly_ are you asking for? 
Reread this thread, I am really getting
tired of reiterating everything
over and over again.

In a nutshell:
* Lift acls from all discontinued Fedoras
* Keep the buildinfrastructure alive.
* Allow fedora maintainers to fix bugs in discontinued Fedoras.

Alternative: Officially extend Fedora life-times.

Alternative: Discontinue EPEL and replace it a full RHEL/CentOS
derivative as part of Fedora.

Ralf

reviving Fedora Legacy

[Josh Boyer]

On Mon, Oct 13, 2008 at 04:23:49PM +0200, Ralf Corsepius wrote:
> On Mon, 2008-10-13 at 10:14 -0400, Josh Boyer wrote:
> > On Mon, Oct 13, 2008 at 04:12:40PM +0200, Ralf Corsepius wrote:
> > >Answer: RHEL5 is not a replacement for a lifetime extended current
> > >Fedora.
> > 
> > Extended for how long?  Fedora releases are supported for roughly
> > 13 months (1 month after N+2 is released).  Actually longer if you
> > take into account the slips that inevitably hit during each release
> > cycle.
> > 
> > So, what _exactly_ are you asking for?
> Reread this thread, I am really getting tired of reiterating everything
> over and over again. 
I've read the thread.  Twice.

> In a nutshell:
> * Lift acls from all discontinued Fedoras
> * Keep the buildinfrastructure alive.
> * Allow fedora maintainers to fix bugs in discontinued Fedoras. 
This has impacts on everyone though, not just the people that
want to keep an old branch active.  You have to worry about:

1) Upgrade paths
2) buildsystem inheritence
3) Storage (CVS, mirrors, koji, etc)
4) Bug reports (because they certainly will get reported to the
   overall package maintainers, not just the "LTS" maintainers)
5a) Depletion of test and development resources to current releases
 or
5b) Lack of participation

I'm not saying it's a bad idea, just needs a lot of thought.
There is a reason the Fedora Legacy project died.

> Alternative: Officially extend Fedora life-times. 
This is not an alternative to the above.  This is where my
confusion comes in.  You say "extend Fedora life-times", but
you don't say to what.  Just keep this one out because it's
not really a viable solution.

> Alternative: Discontinue EPEL and replace it a full RHEL/CentOS
> derivative as part of Fedora. 
I think if you remove the RHEL part of this, it makes some sense.
I doubt Red Hat is going to sign up for support of all the EPEL
packages, so they will never be part of RHEL proper.

josh

reviving Fedora Legacy

[Patrice Dumas]

On Mon, Oct 13, 2008 at 10:35:18AM -0400, Josh Boyer wrote:
>  
>  This has impacts on everyone though, not just the people that
>  want to keep an old branch active.  You have to worry about:
>  
>  1) Upgrade paths 
No more than in fedora releases.

>  2) buildsystem inheritence 
That seems like an interesting issue...  Could you be a bit more 
specific?

>  3) Storage (CVS, mirrors, koji, etc) 
CVS is not really an issue, we leave old branches already currently.
Others may be problematic. How many updates do we keep in the download
server? Is it only one version or more? If there is only one version,
then there is no problem, in my opinion. For koji, I know that some
builds are already deleted, maybe for LTS we could keep builds around
for some months and delete all except the last one?

>  4) Bug reports (because they certainly will get reported to the
>     overall package maintainers, not just the "LTS" maintainers) 
I see 2 phases. In the first phase we consider that EOL product aren't
maintained anymore, that is we respond to those bug reports in the same
way than we respond to bug reports about EOL products today. If there is
enough interest in the project, then we mandate LTS maintainers to be in
watchbugzilla and we find a way to advertise which packages are still
maintained. The most simple would be mass orphaning packages such that a
maintainer has to put himself in the fedora db for a package for that
package to be considered to be still maintained.

>  5a) Depletion of test and development resources to current releases
I don't think we should mandate how fedora contributors allocate their
time.

>   or
>  5b) Lack of participation 
Time will tell.

>  I'm not saying it's a bad idea, just needs a lot of thought.
>  There is a reason the Fedora Legacy project died. 
Once again it is very different now. Legacy had different
infrastructure, different rules, and overall was more complicated. And
there has been improvements in the fedora infrastructure since then.

--
Pat

reviving Fedora Legacy

[Patrice Dumas]

On Mon, Oct 13, 2008 at 04:54:29PM +0200, Patrice Dumas wrote:
>  
>  CVS is not really an issue, we leave old branches already currently.
>  Others may be problematic. How many updates do we keep in the download
>  server? Is it only one version or more? If there is only one version,
>  then there is no problem, in my opinion. 
Thinking about it a bit more, there can be a problem. Indeed, even
though update directories shouldn't grow much, each 'supported' LTS
release will take a big space on mirrors (6G or something like that?).
So I think that the maximal number of EOL braches that are kept open
should be constrained by the available place. For example, 3 more years
would roughly mean 3*2 more updates directories. It could be too much, 
or not, depending on what is acceptable on fedora download servers.

In that case skipping some of the fedora release, like doing the LTS
stuff only each year may help.

--
Pat

reviving Fedora Legacy

[Arjan van de Ven]

On Mon, 13 Oct 2008 17:05:08 +0200
Patrice Dumas <pertusus(a)free.fr&gt; wrote:

>  In that case skipping some of the fedora release, like doing the LTS
>  stuff only each year may help. 

before solving the "how many" problem...
lets be realistic

1) Making every release LTS is not feasible, there's just not going to
be enough manpower for that (history has shown that) for now at least.
2) I don't think users would even really demand such a beast
3) The volunteer base is a bit thin; current fedora volunteers tend to
work on the latest version (or maybe two). In fact, so do many users.

I would suggest focusing on first getting ONE such LTS release going.
Figure out a plan on how to get out of it first (communication wise
etc) in case interest isn't what you expect, and how to monitor the
health. With that I suspect the fedora leadership will be happy to
endorse it happily.

Do one. Get that working. Don't even think about multiple until you
have gotten one down. You'll learn so much that it's not worth planning
beyond that.


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

reviving Fedora Legacy

[Jesse Keating]

On Mon, 2008-10-13 at 11:26 -0400, Arjan van de Ven wrote:
>  1) Making every release LTS is not feasible, there's just not
> going to
>  be enough manpower for that (history has shown that) for now at least.
>  2) I don't think users would even really demand such a beast 
The problem you run into is that everybody wants a /different/ one to be
the LTS release, that is the one they're currently stuck on.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

reviving Fedora Legacy

[Kevin Kofler]

Jesse Keating <jkeating <at> redhat.com> writes:
>  The problem you run into is that everybody wants a /different/ one to
> be
>  the LTS release, that is the one they're currently stuck on. 
I think at least this time the choice of F8 is obvious:
* It's the version to go EOL next.
* F9 is a version with huge changes:
  - KDE 4
  - X.Org X11R7.4 (server 1.5.0)
  - GCC 4.3
  etc.
  all of which contribute to people being stuck on F8.

Frankly, if even the manpower to maintain F8 now can't be found, then I doubt 
there will ever be enough manpower for an LTS release.

        Kevin Kofler

reviving Fedora Legacy

[Patrice Dumas]

On Mon, Oct 13, 2008 at 11:26:22AM -0400, Arjan van de Ven wrote:
>  On Mon, 13 Oct 2008 17:05:08 +0200
>  Patrice Dumas <pertusus(a)free.fr&gt; wrote:
>  
>  > In that case skipping some of the fedora release, like doing the LTS
>  > stuff only each year may help.
>  
>  
>  before solving the "how many" problem...
>  lets be realistic 
I agree, but the issue of space may be a show stopper for some, so
better think about it.

>  1) Making every release LTS is not feasible, there's just not
> going to
>  be enough manpower for that (history has shown that) for now at least. 
Agreed.

>  2) I don't think users would even really demand such a beast
I don't know in general, but I know that I stopped proposing people that
were not absolute power users to use fedora, even if they were fluent
enough because of this issue. So fedora lost at least 2 users. But they
were not users likely to contribute, so they don't weight that much.

>  3) The volunteer base is a bit thin; current fedora volunteers tend
> to
>  work on the latest version (or maybe two). In fact, so do many users. 
There are only 2 versions... But it is true I don't think there are that 
many packagers interested in LTS, for the user, I am not sure. But I
also think that the amount of work for the 2 first year is not high, no
updates, for most packages is right. There are indeed some big and
complex core packages that may be problematic, we'll see.

>  I would suggest focusing on first getting ONE such LTS release
> going.
>  Figure out a plan on how to get out of it first (communication wise
>  etc) in case interest isn't what you expect, and how to monitor the
>  health. With that I suspect the fedora leadership will be happy to
>  endorse it happily. 
My suggestion is first to communicate only to the packagers that they
can update the packages, look whether there are some that are updated,
especially those in @code and @base, and especially when there is a
knowledge that something is broken or a security issue, create a SIG if
it looks that there is support, discuss the details, see how many
participants, make the rules and only afterwards communicate something 
to the exterior.

>  Do one. Get that working. Don't even think about multiple until
> you
>  have gotten one down. You'll learn so much that it's not worth planning
>  beyond that. 
Indeed, maybe the best would be to start with F9 such that the
infrastructure doesn't have to be revived.

--
Pat

reviving Fedora Legacy

[Kevin Kofler]

Patrice Dumas <pertusus <at> free.fr> writes:
>  Indeed, maybe the best would be to start with F9 such that the
>  infrastructure doesn't have to be revived. 
Why not F8? It's still supported now, so nothing to revive, and I think a lot 
more people will be interested in a longer-term support for F8 than F9. F9->F10 
has few major changes (I see only the new RPM as a potential trouble point), 
F8->F9 had a lot of them (GCC 4.3 can be a problem for developers, KDE 4 for 
users, the new X11 for users of proprietary graphics drivers etc.).

        Kevin Kofler

reviving Fedora Legacy

[Patrice Dumas]

On Mon, Oct 13, 2008 at 07:18:31PM +0000, Kevin Kofler wrote:
>  Patrice Dumas <pertusus <at> free.fr> writes:
>  > Indeed, maybe the best would be to start with F9 such that the
>  > infrastructure doesn't have to be revived.
>  
>  Why not F8? It's still supported now, so nothing to revive, and I think a lot 
>  more people will be interested in a longer-term support for F8 than F9. F9->F10 
Forgot that F8 was still maintained... F8 would be nice, yes. It doesn't
make that much time to organize, but still right.

--
Pat

reviving Fedora Legacy

[Ralf Corsepius]

On Mon, 2008-10-13 at 10:35 -0400, Josh Boyer wrote:
>  On Mon, Oct 13, 2008 at 04:23:49PM +0200, Ralf Corsepius wrote:
>  >On Mon, 2008-10-13 at 10:14 -0400, Josh Boyer wrote:
>  >> On Mon, Oct 13, 2008 at 04:12:40PM +0200, Ralf Corsepius wrote: 
>  >Alternative: Officially extend Fedora life-times.
>  
>  This is not an alternative to the above.  
Why not?

Other distros apply much longer life-times.

openSUSE has 2 years:
http://lists.opensuse.org/opensuse-announce/2008-10/msg00000.html

>  >Alternative: Discontinue EPEL and replace it a full RHEL/CentOS
>  >derivative as part of Fedora.
>  
>  I think if you remove the RHEL part of this, it makes some sense.
>  I doubt Red Hat is going to sign up for support of all the EPEL
>  packages, so they will never be part of RHEL proper. 
Agreed.

Ralf

reviving Fedora Legacy

[Jesse Keating]

On Mon, 2008-10-13 at 16:23 +0200, Ralf Corsepius wrote:
>  
>  In a nutshell:
>  * Lift acls from all discontinued Fedoras
>  * Keep the buildinfrastructure alive.
>  * Allow fedora maintainers to fix bugs in discontinued Fedoras. 
I think the only way I'd vote for this to happen is if it was setup in
thusly:

At the point of official EOL (IE the 13~ month mark) PackageKit is
notified in such a way so that in it's attempts to fetch new updates
from existing repos it warns users about the EOL and explains to them
the situation.  It can offer a few different options:

A) Upgrade (via pre-upgrade) to a newer version of Fedora.

B) Configure itself for a new set of repos that are the product of
post-eol updates by maintainers, giving clear information to the user
that there is no set lifespan, no set package list, no set expectation,
no nothing.

C) Do nothing.

Users of EOL releases would have to make a conscious choice to jump on
the post-eol update world, so that they are given a chance to understand
what it is they would be consuming.  I would not want people to wind up
there without any prior knowledge and properly set expectation of what
they are getting, and I would want them to be urged to upgrade if at all
possible.

Furthermore I would want to prevent maintainers who do not wish to
participate in the post-EOL update world from getting bugzilla reports
by people using their software in EOL releases.

Finally, I would prefer if we had our automated signing system in place
prior to this, but I'm not going to make this a blocker.

Maintainer teams of various systems such as Bodhi and pkgdb and koji and
mirrormanager et al would also need to give their explicit approval and
add any further adjustments to any such plan.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

reviving Fedora Legacy

[Patrice Dumas]

On Mon, Oct 13, 2008 at 09:23:42AM -0700, Jesse Keating wrote:
>  On Mon, 2008-10-13 at 16:23 +0200, Ralf Corsepius wrote:
>  > 
>  > In a nutshell:
>  > * Lift acls from all discontinued Fedoras
>  > * Keep the buildinfrastructure alive.
>  > * Allow fedora maintainers to fix bugs in discontinued Fedoras.
>  
>  I think the only way I'd vote for this to happen is if it was setup in
>  thusly:
>  
>  At the point of official EOL (IE the 13~ month mark) PackageKit is
>  notified in such a way so that in it's attempts to fetch new updates
>  from existing repos it warns users about the EOL and explains to them
>  the situation.  It can offer a few different options:
>  
>  A) Upgrade (via pre-upgrade) to a newer version of Fedora.
>  
>  B) Configure itself for a new set of repos that are the product of
>  post-eol updates by maintainers, giving clear information to the user
>  that there is no set lifespan, no set package list, no set expectation,
>  no nothing.
>  
>  C) Do nothing.
>  
>  Users of EOL releases would have to make a conscious choice to jump on
>  the post-eol update world, so that they are given a chance to understand
>  what it is they would be consuming.  I would not want people to wind up
>  there without any prior knowledge and properly set expectation of what
>  they are getting, and I would want them to be urged to upgrade if at all
>  possible. 
Agreed. In fact I think that we could start something even without B)
available in packagekit, but only with a manual change in the yum config
files. But packagekit pointing to the post-eol repo would be even
better.

>  Furthermore I would want to prevent maintainers who do not wish to
>  participate in the post-EOL update world from getting bugzilla reports
>  by people using their software in EOL releases. 
My proposal is to do a mass orphaning of EOLed branches, such that a
maintainer has to actively step in. But I can't see a way to avoid bugs
labelled against a non EOLed branch to reach the current maintainer. If
a packager maintains a EOLed branch I also thing that it should be
mandatory (and also logical!) to be in watchbugzilla (if the maintainer 
agrees, of course) to do bug triaging, but for those that are orphaned
in the EOLed branch I can't see waht to do for wrongly labelled bugs.

>  Finally, I would prefer if we had our automated signing system in
> place
>  prior to this, but I'm not going to make this a blocker.
>  
>  Maintainer teams of various systems such as Bodhi and pkgdb and koji and
>  mirrormanager et al would also need to give their explicit approval and
>  add any further adjustments to any such plan. 
Of course. At least for me, I think that this idea is not worth pursuing
if the cost in term of infras manpower or even hardware and the like is
not almost nill (except for volunteers really interested in that).

--
Pat

reviving Fedora Legacy

[Jesse Keating]

On Mon, 2008-10-13 at 18:56 +0200, Patrice Dumas wrote:
>  Agreed. In fact I think that we could start something even without
> B)
>  available in packagekit, but only with a manual change in the yum config
>  files. But packagekit pointing to the post-eol repo would be even
>  better. 
That's acceptable to me too.

>  
>  > Furthermore I would want to prevent maintainers who do not wish to
>  > participate in the post-EOL update world from getting bugzilla reports
>  > by people using their software in EOL releases.
>  
>  My proposal is to do a mass orphaning of EOLed branches, such that a
>  maintainer has to actively step in. But I can't see a way to avoid bugs
>  labelled against a non EOLed branch to reach the current maintainer. If
>  a packager maintains a EOLed branch I also thing that it should be
>  mandatory (and also logical!) to be in watchbugzilla (if the maintainer 
>  agrees, of course) to do bug triaging, but for those that are orphaned
>  in the EOLed branch I can't see waht to do for wrongly labelled bugs. 
Right, it would be silly of me to expect you to somehow prevent people
from filing bugs to the wrong release.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

reviving Fedora Legacy

[Rahul Sundaram]

Patrice Dumas wrote:

>  Of course. At least for me, I think that this idea is not worth
> pursuing
>  if the cost in term of infras manpower or even hardware and the like is
>  not almost nill (except for volunteers really interested in that). 
Patrice,

It appears that 2.6.27 will be maintained for a longer period of time. 
If this project gets started, you might want to keep track of this.

http://thread.gmane.org/gmane.linux.kernel/742570/focus=743377

Rahul

reviving Fedora Legacy

[Josh Boyer]

On Mon, Oct 13, 2008 at 11:47:13PM +0530, Rahul Sundaram wrote:
>  Patrice Dumas wrote:
>
> > Of course. At least for me, I think that this idea is not worth pursuing
> > if the cost in term of infras manpower or even hardware and the like is
> > not almost nill (except for volunteers really interested in that).
>
>  Patrice,
>
>  It appears that 2.6.27 will be maintained for a longer period of time.  
>  If this project gets started, you might want to keep track of this.
>
>  http://thread.gmane.org/gmane.linux.kernel/742570/focus=743377 
Except that over the life of F10, it will likely migrate to 2.6.28 and
therefore if/when a Fedora LTS gets created at the point that F10 is EOL,
the fact that 2.6.27 will be long-term maintained will be sort of irrelevant.

josh

reviving Fedora Legacy

[Rahul Sundaram]

Josh Boyer wrote:
>  On Mon, Oct 13, 2008 at 11:47:13PM +0530, Rahul Sundaram wrote:
> > Patrice Dumas wrote:
> >
> >> Of course. At least for me, I think that this idea is not worth pursuing
> >> if the cost in term of infras manpower or even hardware and the like is
> >> not almost nill (except for volunteers really interested in that).
> > Patrice,
> >
> > It appears that 2.6.27 will be maintained for a longer period of time.  
> > If this project gets started, you might want to keep track of this.
> >
> > http://thread.gmane.org/gmane.linux.kernel/742570/focus=743377
>  
>  Except that over the life of F10, it will likely migrate to 2.6.28 and
>  therefore if/when a Fedora LTS gets created at the point that F10 is EOL,
>  the fact that 2.6.27 will be long-term maintained will be sort of irrelevant. 
I can't predict the future. 2.6.27 hasn't been pushed to Fedora 9. Maybe 
Patrice wants to start off with Fedora 8 or Fedora 9 instead of Fedora 
10. Maybe 2.6.28 won't hit Fedora 10. It is a potentially useful data 
point to consider. That's all.

Rahul

reviving Fedora Legacy

[Patrice Dumas]

On Tue, Oct 14, 2008 at 12:24:46AM +0530, Rahul Sundaram wrote:
>  I can't predict the future. 2.6.27 hasn't been pushed to Fedora 9. Maybe  
>  Patrice wants to start off with Fedora 8 or Fedora 9 instead of Fedora  
>  10. Maybe 2.6.28 won't hit Fedora 10. It is a potentially useful data  
>  point to consider. That's all. 
As Kevin suggested F8 would be a good start. And if we don't have time
to set things up, F9 would be the second choice. So this info is
definitely usefull.

--
Pat

reviving Fedora Legacy

[Jeffrey Ollie]

On Mon, Oct 13, 2008 at 9:12 AM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  WHAT? Guess why people are demanding for a *FEDORA LTS* and are not
>  demanding for RHEL5 or CENTOS.
>
>  Answer: RHEL5 is not a replacement for a lifetime extended current
>  Fedora. 
So basically you're peeved that Red Hat doesn't release a new RHEL
every six months?  I thought you said that you were worried about Red
Hat remaining profitable in the future?

Not even Canonical does that - they release a LTS version every two years.

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"

reviving Fedora Legacy

[Les Mikesell]

Jeffrey Ollie wrote:
>  On Mon, Oct 13, 2008 at 8:38 AM, Ralf Corsepius
> <rc040203(a)freenet.de&gt; wrote:
> > True, at the time RHEL5 was new, it had been more or less a rebuilt
> > FC5/6 and switching between them had not been a major problem.
> >
> > Nowadays, it isn't anymore and even will be less when FC10 comes out.
> >
> > I.e. to today's FC7 or FC8 users, RHEL5 or CentOS5 are not viable
> > alternatives. They are kind of a flashback to yesterday's state-of-art.
>  
>  Well, DUH!
>  
>  Long term stability is achieved by *NOT ADDING NEW FEATURES*.  *ADDING
>  NEW FEATURES INTRODUCES NEW BUGS* 
But that's generally an upstream issue. The bugs get fixed upstream but 
in general the new releases aren't included in RHEL/Centos updates even 
after the updated program becomes less buggy that the shipped version. 
(Firefox and OO being recent, rare exceptions).

>  *YOU CAN'T HAVE YOUR CAKE AND EAT IT TOO* 
And sometimes you don't get either.  Like a beta Dovecot shipped in RHEL 
  4 and not replaced by the stable upstream when the release version was 
available.

>  Sorry for shouting, but all of these people demanding a "Fedora
> LTS"
>  don't seem to get this fundamental point. 
Your point applies only on a package-by-package basis, but RHEL applies 
it across the board (with the above-mentioned rare exceptions).

>  I mean really, if RHEL5 switched from KDE3.5 to KDE4.0 I'd be
>  screaming bloody murder. 
Nobody ever claimed KDE 4.0 was stable, did they?

>  Or even from BIND 9.3 to BIND 9.5.  Or
>  whatever. 
Not sure about that, but if upstream says it is better, it probably is.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

reviving Fedora Legacy

[Jeffrey Ollie]

On Mon, Oct 13, 2008 at 9:41 AM, Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:
>  Jeffrey Ollie wrote:
> >
> > Long term stability is achieved by *NOT ADDING NEW FEATURES*.  *ADDING
> > NEW FEATURES INTRODUCES NEW BUGS*
>
>  But that's generally an upstream issue. The bugs get fixed upstream but in
>  general the new releases aren't included in RHEL/Centos updates even after
>  the updated program becomes less buggy that the shipped version. (Firefox
>  and OO being recent, rare exceptions). 
Unfortunately, upstream developers don't always release bugfix-only
releases.  Many times they introduce new features or change the
behavior of old features.  Introducing new features means that there
are probably new bugs which is bad for distributions like RHEL/CentOS.
 Changing the behavior of old features is just as bad for RHEL/CentOS
because people are building systems that expect the old behavior.

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"

reviving Fedora Legacy

[Les Mikesell]

Jeffrey Ollie wrote:
>  
> >> Long term stability is achieved by *NOT ADDING NEW FEATURES*.  *ADDING
> >> NEW FEATURES INTRODUCES NEW BUGS*
> > But that's generally an upstream issue. The bugs get fixed upstream but in
> > general the new releases aren't included in RHEL/Centos updates even after
> > the updated program becomes less buggy that the shipped version. (Firefox
> > and OO being recent, rare exceptions).
>  
>  Unfortunately, upstream developers don't always release bugfix-only
>  releases.  Many times they introduce new features or change the
>  behavior of old features. 
Agreed - sometimes they do things as bizarre as dropping a feature, then 
putting it back with a different name, like "yum --download-only" vs. 
much later an optional module invoked as "yum --downloadonly".

>  Introducing new features means that there
>  are probably new bugs which is bad for distributions like RHEL/CentOS. 
But again, that's a package by package issue as to whether upstream is 
improved or not.  And mostly RHEL/Centos treats the whole distro the same.

>   Changing the behavior of old features is just as bad for
> RHEL/CentOS
>  because people are building systems that expect the old behavior. 
Yes, ideally there would be an optional, alternate repo for 
behavior-changing updates.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

reviving Fedora Legacy

[Ralf Corsepius]

On Mon, 2008-10-13 at 10:16 -0500, Jeffrey Ollie wrote:
>  On Mon, Oct 13, 2008 at 9:41 AM, Les Mikesell
> <lesmikesell(a)gmail.com&gt; wrote:
>  > Jeffrey Ollie wrote:
>  >>
>  >> Long term stability is achieved by *NOT ADDING NEW FEATURES*.  *ADDING
>  >> NEW FEATURES INTRODUCES NEW BUGS*
>  >
>  > But that's generally an upstream issue. The bugs get fixed upstream but in
>  > general the new releases aren't included in RHEL/Centos updates even after
>  > the updated program becomes less buggy that the shipped version. (Firefox
>  > and OO being recent, rare exceptions).
>  
>  Unfortunately, upstream developers don't always release bugfix-only
>  releases.  Many times they introduce new features or change the
>  behavior of old features. 
Right, and how do you expect EPEL to handle this issue?

I would expect EPEL to starve out contributors during RHEL's long time
time and those who will try to continue supporting it, will be facing
the problems you described.

May-be I missed it, but I would like to hear about EPEL's visions on
this matter.

Ralf

reviving Fedora Legacy

[Kevin Fenzi]

On Tue, 14 Oct 2008 05:43:05 +0200
rc040203(a)freenet.de (Ralf Corsepius) wrote:

>  On Mon, 2008-10-13 at 10:16 -0500, Jeffrey Ollie wrote:
...snip...
>  > 
>  > Unfortunately, upstream developers don't always release bugfix-only
>  > releases.  Many times they introduce new features or change the
>  > behavior of old features.
>  Right, and how do you expect EPEL to handle this issue?
>  
>  I would expect EPEL to starve out contributors during RHEL's long time
>  time and those who will try to continue supporting it, will be facing
>  the problems you described.
>  
>  May-be I missed it, but I would like to hear about EPEL's visions on
>  this matter. 
Sorry for the late reply. 

In many ways EPEL has it easy. Since they don't maintain the kernel,
glibc, and all the other packages that RHEL maintains. 

But you are right, for the packages they do maintain it will get harder
over time to backport security fixes or avoid updating versions.

I think the fact that EPEL doesn't have to handle those more
vulnerable core packages, and only has to worry about the leaf node
packages is one thing that makes it more viable. 

Also, note that since many of the packages in EPEL are leaf nodes /
add on packages they don't tend to have deep dependencies that more
central packages have. 
 
>  Ralf 
kevin

reviving Fedora Legacy

[Ralf Corsepius]

On Tue, 2008-10-14 at 14:31 -0600, Kevin Fenzi wrote:
>  On Tue, 14 Oct 2008 05:43:05 +0200
>  rc040203(a)freenet.de (Ralf Corsepius) wrote:
>  
>  > On Mon, 2008-10-13 at 10:16 -0500, Jeffrey Ollie wrote:
>  ...snip...
>  > > 
>  > > Unfortunately, upstream developers don't always release bugfix-only
>  > > releases.  Many times they introduce new features or change the
>  > > behavior of old features.
>  > Right, and how do you expect EPEL to handle this issue?
>  > 
>  > I would expect EPEL to starve out contributors during RHEL's long time
>  > time and those who will try to continue supporting it, will be facing
>  > the problems you described.
>  > 
>  > May-be I missed it, but I would like to hear about EPEL's visions on
>  > this matter.
>  
>  Sorry for the late reply. 
>  
>  In many ways EPEL has it easy. Since they don't maintain the kernel,
>  glibc, and all the other packages that RHEL maintains. 
>  
>  But you are right, for the packages they do maintain it will get harder
>  over time to backport security fixes or avoid updating versions.
>  
>  I think the fact that EPEL doesn't have to handle those more
>  vulnerable core packages, and only has to worry about the leaf node
>  packages is one thing that makes it more viable.  
OK.

>  Also, note that since many of the packages in EPEL are leaf nodes /
>  add on packages they don't tend to have deep dependencies that more
>  central packages have. 
OK, so you're basically ignoring this issue and hope for the best?

Certainly, the likelihood of such an incident to happen in "non-core
packages" is less than in "core packages" and the severity of such
incidents in "leaf-packages" is likely less than that in core packages,
nevertheless they are possible to happen over the long time span EPEL is
supposed to be around, nevertheless are non-core packages which can have
long and deep dependency chains.

I only need to have a look into the packages I maintain in fedora ;)

Ralf

reviving Fedora Legacy

[Benny Amorsen]

David Woodhouse <dwmw2(a)infradead.org&gt; writes:

>  What I _don't_ understand is why these requirements are not met
> by
>  CentOS. Isn't that _precisely_ the 'market' that RHEL and CentOS exist
>  to serve? 
RHEL and CentOS are simply too slow for some things, unless you get
very lucky and they happen to have a release at the perfect time.

Imagine starting development on something to be deployed in half a
year or a year. RHEL right now is on kernel 2.6.18. If you e.g. need
some of the many new features of netfilter since 2.6.18, you're
"stuck" with Fedora. Not that I mind in the least being stuck with
Fedora, of course.

Also, let's take Asterisk, which is included in Fedora. You get to
have 1.4.x if you use Fedora 8, and 1.6.x with Fedora 9. With EPEL,
you currently get neither, but that is relatively easy to fix. What
isn't so easy to fix is that you get either 1.4.x or 1.6.x with EPEL,
and it's a long wait for the next release of RHEL just to get a new
Asterisk. You can solve that by adding updated packages yourself, of
course, but it can easily devolve into your very own distro where RHEL
updates don't apply safely.

So I want a RHEL with a new release every 6 months and 5 years of
stability. And a pony. If I can't have that, I'd like to have whatever
updates people can be bothered to make for old Fedoras. It's ok if
they break things, it's ok if they don't manage to cover all the
updates that RHEL would have done, it's ok if everyone gives up on it
after 3 months. I'll take what I can get.


/Benny

reviving Fedora Legacy

[Jarod Wilson]

On Monday 13 October 2008 17:43:12 Benny Amorsen wrote:
>  RHEL and CentOS are simply too slow for some things, unless you get
>  very lucky and they happen to have a release at the perfect time.
>
>  Imagine starting development on something to be deployed in half a
>  year or a year. RHEL right now is on kernel 2.6.18. If you e.g. need
>  some of the many new features of netfilter since 2.6.18, you're
>  "stuck" with Fedora. Not that I mind in the least being stuck with
>  Fedora, of course. 
I don't mind being "stuck" with Fedora either, but I'd like to clarify 
something... If you need new features of netfilter (or other feature foo) 
since 2.6.18, its likely others do too, and its also likely that we've back-
ported said features to the RHEL5 kernel already (or intend to for the next 
release). Just because it says 2.6.18 doesn't mean its completely devoid of 
features that have gone upstream since then.

Certainly, there *are* cases where features can't/won't be back-ported to the 
RHEL kernel and a newer kernel is the only option, but beware of what you 
think the RHEL kernel can't do. ;)

-- 
Jarod Wilson
jarod(a)redhat.com

[Michael Schwendt]

On Sun, 12 Oct 2008 00:17:05 +0200, Patrice Dumas wrote:

>  I was interested in
>  legacy at some point, but everything was so different than in fedora
>  extras that it deterred me. 
Fedora Legacy was close to dead already much earlier, failing to deliver
updates for Red Hat Linux 7.3 and 9. Originally, it had started with parts
of the fedora.us infrastructure (the Fedora Extras predecessor), using the
same bugzilla, the same review'n'release process in bugzilla, a human-driven
build-system, but not inheriting the existing web of trust. Even simple
updates took four or more weeks to be looked at in bugzilla.

[Horst H. von Brand]

Henrique Junior <henriquecsj(a)gmail.com&gt; wrote:
>  I would like to share with you an situation related to Fedora's
> time
>  of life that comes to me in recent days.
>  I was recently promoted to Software Manager in the governmental
>  partition where I work. Next year we've plans to migrate 500 Linux
>  desktop stations and, in the last month, finished the migration of all
>  servers to CentOS.
>  The question that worries me is that, despite the willingness to use
>  Fedora, dealing with an "end of life" of 13 months can make Fedora
>  impractical in these 500 desktops. I'll be pressed to use Ubuntu and
>  even got to think about maintain by myself an repository for
>  maintaining, maybe, the most important RPMs always updated even if the
>  Fedora come to the inevitable 13 months of use.
>  Perhaps it is time to seek volunteers to bring back the Fedora Legacy
>  and see if more people are interested this time. 
Isn't CentOS enough for your desktop use?

Futzing around with two philosphies of how to handle packages,
configuration, etc is very definitely not fun. We had such a setup for a
time (Solaris on SPARC servers and Red Hat on workstations (yes, it was
long ago)), and we moved the SPARCs to Red Hat as soon as practical.

Later we moved to Fedora everywhere (needed in lab workstations, where
users demand latest bling), but it was a pain on the server side, so we
settled on CentOS there.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

[Till Maas]

On Sat October 11 2008, Patrice Dumas wrote:

>  My proposal was clear: start the project when somebody has
> volunteered
>  for each of the packages that are in @code and @base (and maybe other
>  comps groups, I don't remember exactly). And keep a page with the
>  packages maintained such as not to give wrong expectations. 
So why don't you start to find the maintainers you need? If you got them 
together, it will be a lot easier to get this done.

Regards,
Till

[Patrice Dumas]

On Sun, Oct 12, 2008 at 12:42:39AM +0200, Till Maas wrote:
>  On Sat October 11 2008, Patrice Dumas wrote:
>  
>  > My proposal was clear: start the project when somebody has volunteered
>  > for each of the packages that are in @code and @base (and maybe other
>  > comps groups, I don't remember exactly). And keep a page with the
>  > packages maintained such as not to give wrong expectations.
>  
>  So why don't you start to find the maintainers you need? If you got them 
>  together, it will be a lot easier to get this done. 
There is also the need for some infrastructure. (My proposal here was 
just to let the old branches live. At that time there was no packagedb,
now with packagedb it would even be simpler.) Without infrastructure, it
is not really worth gathering maintainers.

--
Pat

[Till Maas]

On Sun October 12 2008, Patrice Dumas wrote:

>  There is also the need for some infrastructure. (My proposal here
> was
>  just to let the old branches live. At that time there was no packagedb,
>  now with packagedb it would even be simpler.) Without infrastructure, it
>  is not really worth gathering maintainers. 
If you gather maintainers, you will probably also get people who can spare a 
machine to build up some infrastructure. Also you will easier get access to 
Fedora infrastructure. Or say to change your sentence:

Without interested people, it is not really worth preparing infrastructure.

Regards,
Till

[Patrice Dumas]

On Sun, Oct 12, 2008 at 11:25:11AM +0200, Till Maas wrote:
>  On Sun October 12 2008, Patrice Dumas wrote:
>  
>  > There is also the need for some infrastructure. (My proposal here was
>  > just to let the old branches live. At that time there was no packagedb,
>  > now with packagedb it would even be simpler.) Without infrastructure, it
>  > is not really worth gathering maintainers.
>  
>  If you gather maintainers, you will probably also get people who can spare a 
>  machine to build up some infrastructure. Also you will easier get access to 
>  Fedora infrastructure. Or say to change your sentence:
>  
>  Without interested people, it is not really worth preparing infrastructure. 
Look, saying 'yes, if you gather maintainers according to your plan,
we'll let you use the fedora infras, if you find someone willing to sign
your packages' doesn't cost any time. Gathering maintainers, just to
find that there is no infra in the end is very costly.

No infrastructure needs to be prepared. The existing one needs to be
kept (if it is done in the fedora scope). That's one very important
point of my plan, the no-cost infrastructure and no new community
organization.

--
Pat

[Till Maas]

On Sun October 12 2008, Patrice Dumas wrote:

>  Look, saying 'yes, if you gather maintainers according to your
> plan,
>  we'll let you use the fedora infras, if you find someone willing to sign
>  your packages' doesn't cost any time. Gathering maintainers, just to
>  find that there is no infra in the end is very costly. 
I do not see why creating a wiki page with a table that contains the minimum 
package set you want to support and people who would maintain it is very 
costly. If you find the 50 or whatever amount of people it at least needs to 
do this project, you will have good chances to be able to use the Fedora 
infrastructure. If you want to do this with only 5 people, you do not even 
much of an infrastructure.

Regards,
Till

[Emmanuel Seyman]

* Patrice Dumas [12/10/2008 11:45] :
>                                            That's one very important
>  point of my plan, the no-cost infrastructure and no new community
>  organization. 
The cost of setting up infrastructure is trivial compared to
encouraging people to release updates past EOL. If you can't do
the former, how are you supposed to do the latter ?

Emmanuel

[Patrice Dumas]

On Sun, Oct 12, 2008 at 01:03:13PM +0200, Emmanuel Seyman wrote:
>  * Patrice Dumas [12/10/2008 11:45] :
>  >
>  >                                           That's one very important
>  > point of my plan, the no-cost infrastructure and no new community
>  > organization.
>  
>  The cost of setting up infrastructure is trivial compared to
>  encouraging people to release updates past EOL. If you can't do
>  the former, how are you supposed to do the latter ? 
I really can't see how you can say that. Look at the setup of rpmfusion, 
for example, it is clearly not something I can undertake myself.

--
Pat

[Till Maas]

On Sun October 12 2008, Patrice Dumas wrote:
>  On Sun, Oct 12, 2008 at 01:03:13PM +0200, Emmanuel Seyman wrote:
>  > * Patrice Dumas [12/10/2008 11:45] :
>  > >                                           That's one very important
>  > > point of my plan, the no-cost infrastructure and no new community
>  > > organization.
>  >
>  > The cost of setting up infrastructure is trivial compared to
>  > encouraging people to release updates past EOL. If you can't do
>  > the former, how are you supposed to do the latter ?
>
>  I really can't see how you can say that. Look at the setup of rpmfusion,
>  for example, it is clearly not something I can undertake myself. 
Why do you have to do it by yourself? You can recruit interested people to do 
so. And in case you are by yourself, you do not need such a complex setup. 
You only need a script to run mock, rpm --addsign, rsync and createrepo.

Regards,
Till

[Patrice Dumas]

On Sun, Oct 12, 2008 at 03:24:21PM +0200, Till Maas wrote:
>  
>  Why do you have to do it by yourself? You can recruit interested people to do 
>  so. And in case you are by yourself, you do not need such a complex setup. 
>  You only need a script to run mock, rpm --addsign, rsync and createrepo. 
What you describe doesn't looks like a fedora LTS buildsystem. You are
describing how I maintain my personal repo (though no mock, rpmbuild is 
enough) but this is rather different from having a real infrastructure.
And I am not interested in maintaining all the packages in @core and
@base, so definitly need more people. Not to mention that I don't have
anything else than an i386.

--
Pat

[Till Maas]

On Sun October 12 2008, Patrice Dumas wrote:
>  On Sun, Oct 12, 2008 at 03:24:21PM +0200, Till Maas wrote:
>  > Why do you have to do it by yourself? You can recruit interested people
>  > to do so. And in case you are by yourself, you do not need such a complex
>  > setup. You only need a script to run mock, rpm --addsign, rsync and
>  > createrepo.
>
>  What you describe doesn't looks like a fedora LTS buildsystem. You are
>  describing how I maintain my personal repo (though no mock, rpmbuild is
>  enough) but this is rather different from having a real infrastructure.
>  And I am not interested in maintaining all the packages in @core and
>  @base, so definitly need more people. Not to mention that I don't have
>  anything else than an i386. 
Your only argument against setting up your own infrastructure is, that you 
cannot do it on your own. You agree that you need additional people, so this 
argument does not count.

Regards,
Till

[Patrice Dumas]

On Sun, Oct 12, 2008 at 03:38:12PM +0200, Till Maas wrote:
>  
>  Your only argument against setting up your own infrastructure is, that you 
>  cannot do it on your own. You agree that you need additional people, so this 
>  argument does not count. 
My argument is that it is a lot of work to set up an infrastructure. I
wouldn't want to contribute a LTS project where the infrastructure is to
be done, while I would happily maintain packages and even drive the
project if an existing infrastructure is used. Now if there are people
who have the infrastructure, and it is similar with the fedora
infrastructure, and want packagers I'll join.

--
Pat

[Emmanuel Seyman]

* Patrice Dumas [12/10/2008 14:43] :
>  I really can't see how you can say that. Look at the setup of rpmfusion,  
Rpmfusion chose to duplicate the Fedora infrastructure (bugzilla, CVS+FAS,
mailman, the works). This is much more difficult and goes above and beyond
the requirements for a third party repo to get started.

>  for example, it is clearly not something I can undertake myself.
Once again, if you do not have the manpower to setup an infrastructure,
you do not have the manpower to support @code + @base . This is why
you need to start by building a community.

Emmanuel

[Patrice Dumas]

On Sun, Oct 12, 2008 at 04:21:55PM +0200, Emmanuel Seyman wrote:
>  * Patrice Dumas [12/10/2008 14:43] :
>  >
>  Rpmfusion chose to duplicate the Fedora infrastructure (bugzilla, CVS+FAS,
>  mailman, the works). This is much more difficult and goes above and beyond
>  the requirements for a third party repo to get started. 
It doesn't go beyond the requirements for a fedora LTS. If fedora LTS
isn't on par with fedora from the infrastrructure point of view, it is
not worth pursuing.

>  Once again, if you do not have the manpower to setup an
> infrastructure,
>  you do not have the manpower to support @code + @base . This is why
>  you need to start by building a community. 
A community of packagers. Not a community for infrastructure. This is
very different.

--
Pat

[Emmanuel Seyman]

* Patrice Dumas [12/10/2008 16:29] :
>  It doesn't go beyond the requirements for a fedora LTS. If fedora LTS
>  isn't on par with fedora from the infrastrructure point of view, it is
>  not worth pursuing. 
At which point we're back to making excuses for not actually doing
anything and demanding that people who aren't interested in Fedora LTS
do the needed work.

This is insane and if everybody had that atitude, half the Fedora SIGs
would never have seen the light of day.

Emmanuel

[Patrice Dumas]

On Sun, Oct 12, 2008 at 04:43:38PM +0200, Emmanuel Seyman wrote:
>  * Patrice Dumas [12/10/2008 16:29] :
>  >
>  > It doesn't go beyond the requirements for a fedora LTS. If fedora LTS
>  > isn't on par with fedora from the infrastrructure point of view, it is
>  > not worth pursuing.
>  
>  At which point we're back to making excuses for not actually doing
>  anything and demanding that people who aren't interested in Fedora LTS
>  do the needed work. 
Which work? Not shutting down builders and other infras for the EOL 
branches? In my proposal I propose to find somebody to do the signing,
which is the only part that requires work -- unless I am missing
something.

I am not competent in infrastructure building nor have I the time to 
lead a project which includes building an infrastructure. But I can lead
a project targeted at packaging the core of fedora for LTS -- but only
the packaging part.

>  This is insane and if everybody had that atitude, half the Fedora
> SIGs
>  would never have seen the light of day. 
Most of the SIGs don't need specific infrastructure. The analogy is
EPEL, but EPEL got support.

--
Pat

[Emmanuel Seyman]

* Patrice Dumas [12/10/2008 16:51] :
>  Which work? Not shutting down builders and other infras for the EOL 
>  branches? 
Not just not shutting them down but actively maintaining them, which
would require more work than maintaining the non-EOL branches.

I'm sorry but, until there's a community committed to actually doing
the work, asking that infrastructure be created/adapted/maintained is an
unreasonable request, IMHO.

Emmanuel

[Horst H. von Brand]

Emmanuel Seyman <emmanuel.seyman(a)club-internet.fr&gt; wrote:
>  * Patrice Dumas [12/10/2008 16:51] :
>  > Which work? Not shutting down builders and other infras for the EOL 
>  > branches? 
>  Not just not shutting them down but actively maintaining them, which
>  would require more work than maintaining the non-EOL branches. 
I fail to see what the big job is here, but whatever.

>  I'm sorry but, until there's a community committed to
> actually doing
>  the work, 
Backporting fixes, handling bug reports, ... Note that here you _can't_
rely on upstream, they generally aren't interested in ancient versions, so
this is /much/ more work than regular maintainership.

>            asking that infrastructure be created/adapted/maintained is
> an
>  unreasonable request, IMHO. 
Nodz.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

[Ralf Corsepius]

On Sun, 2008-10-12 at 22:32 -0300, Horst H. von Brand wrote:
>  Emmanuel Seyman <emmanuel.seyman(a)club-internet.fr&gt; wrote:
>  > * Patrice Dumas [12/10/2008 16:51] :
>  > > Which work? Not shutting down builders and other infras for the EOL 
>  > > branches?
>  
>  > Not just not shutting them down but actively maintaining them, which
>  > would require more work than maintaining the non-EOL branches.
>  
>  I fail to see what the big job is here, but whatever. 
Is Fedora's
infrastructure working such kind of ineffective, "keeping
the build infrastructure alive" is such an overwhelming amount of
effort?

If so, I am very sure, EPEL4 will be discontinued, once RHEL6 will be
released, because of the additional effort, right?

Of cause this will not happen. More likely RH will assign people to
maintain it - See, no secret plans, just "hegemony of interests".

[Les Mikesell]

Emmanuel Seyman wrote:
>  * Patrice Dumas [12/10/2008 14:43] :
> > I really can't see how you can say that. Look at the setup of rpmfusion, 
>  
>  Rpmfusion chose to duplicate the Fedora infrastructure (bugzilla, CVS+FAS,
>  mailman, the works). This is much more difficult and goes above and beyond
>  the requirements for a third party repo to get started.
>  
> > for example, it is clearly not something I can undertake myself.
>  
>  Once again, if you do not have the manpower to setup an infrastructure,
>  you do not have the manpower to support @code + @base . This is why
>  you need to start by building a community. 
But the first question should be why a separate community is necessary. 
  Why is it not possible for one of fedora's goals to be to provide a 
clean transition to RHEL or Centos at the end of certain development 
cycles, at which point EPEL/Rpmfusion, etc. would be unnecessary as 
separate entities since that fedora cycle's repository would be directly 
usable as-is and would simply need to be maintained instead of the 
various 3rd party versions that have been necessary to fill this void?

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

[Ralph angenendt]

Les Mikesell wrote:
>  But the first question should be why a separate community is
> necessary.  
>  Why is it not possible for one of fedora's goals to be to provide a  
>  clean transition to RHEL or Centos at the end of certain development  
>  cycles,  
That point would have been FC6 alpha (or something like that) for RHEL 5. 
So you would have an alpha release from which you could do the transition. 

Everything (or mostly everything) else in FC6 after that point is newer than
the stuff you'd find in RHEL. How do you want to switch from there to RHEL? 

>  at which point EPEL/Rpmfusion, etc. would be unnecessary as  
>  separate entities since that fedora cycle's repository would be directly  
>  usable as-is and would simply need to be maintained instead of the  
>  various 3rd party versions that have been necessary to fill this void? 
No, it wouldn't as stuff probably would require newer versions of base 
packages than are available in RHEL. 

I do not think that what you suggest is even remotely possible given the
development cycles of Fedora and the ones of Red Hat Enterprise.

And I don't think it is necessary.

Ralph

[Les Mikesell]

Ralph Angenendt wrote:
>  
> > But the first question should be why a separate community is necessary.  
> > Why is it not possible for one of fedora's goals to be to provide a  
> > clean transition to RHEL or Centos at the end of certain development  
> > cycles, 
>  
>  That point would have been FC6 alpha (or something like that) for RHEL 5. 
>  So you would have an alpha release from which you could do the transition. 
>  
>  Everything (or mostly everything) else in FC6 after that point is newer than
>  the stuff you'd find in RHEL. How do you want to switch from there to RHEL?  
"How" is the part that should be planned from the start instead of 
leaving all of your users in this position.

> > at which point EPEL/Rpmfusion, etc. would be unnecessary as  
> > separate entities since that fedora cycle's repository would be directly  
> > usable as-is and would simply need to be maintained instead of the  
> > various 3rd party versions that have been necessary to fill this void?
>  
>  No, it wouldn't as stuff probably would require newer versions of base 
>  packages than are available in RHEL.  
Again, that seems like bad planning.  Wasn't that predictable?  But, 
there are people who claim to have don't successful upgrades from FC6 to 
RHEL/Centos.

>  I do not think that what you suggest is even remotely possible given
> the
>  development cycles of Fedora and the ones of Red Hat Enterprise.
>  
>  And I don't think it is necessary. 
Perhaps having a user base isn't necessary. I doubt if RH would have 
ever attracted one in the beginning if they had not planned to support 
their users from development through production.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

[Kevin Kofler]

Les Mikesell <lesmikesell <at> gmail.com> writes:
>  Again, that seems like bad planning.  Wasn't that predictable?
It was predictable, but not avoidable.

>  But, there are people who claim to have don't successful upgrades
> from FC6 to 
>  RHEL/Centos. 
(I assume you mean "have done", not "have
don't" which makes no sense.)

There are people who *claim* many things, I doubt their claims make sense, 
because really the first (and likely the last) RHEL which FC6 will have even 
the slightest chance of safely upgrading to will be RHEL 6. And that will be an 
upgrade skipping many Fedora releases and thus really bumpy. And at that point 
you'll have had a support hole of somewhere around 2 years!

Going from FC6 to RHEL 5 is essentially a downgrade, especially so if you got 
the numerous upgrades which went out after the FC6 release (if you never 
updated anything, not even security stuff, then you might have more success, 
but Fedora security upgrades are often new versions, RHEL security upgrades are 
usually backports) and the infrastructure doesn't support downgrades at all, 
neither Anaconda nor YUM support them.

        Kevin Kofler

[Stephen John Smoogen]

On Sun, Oct 12, 2008 at 9:21 AM, Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:
>  Emmanuel Seyman wrote:
> >
> > * Patrice Dumas [12/10/2008 14:43] :
> >>
> >> I really can't see how you can say that. Look at the setup of rpmfusion,
> >
> > Rpmfusion chose to duplicate the Fedora infrastructure (bugzilla, CVS+FAS,
> > mailman, the works). This is much more difficult and goes above and beyond
> > the requirements for a third party repo to get started.
> >
> >> for example, it is clearly not something I can undertake myself.
> >
> > Once again, if you do not have the manpower to setup an infrastructure,
> > you do not have the manpower to support @code + @base . This is why
> > you need to start by building a community.
>
>  But the first question should be why a separate community is necessary.  Why
>  is it not possible for one of fedora's goals to be to provide a clean
>  transition to RHEL or Centos at the end of certain development cycles, at
>  which point EPEL/Rpmfusion, etc. would be unnecessary as separate entities
>  since that fedora cycle's repository would be directly usable as-is and
>  would simply need to be maintained instead of the various 3rd party versions
>  that have been necessary to fill this void? 
It would take a change in the branching of EL from Fedora. In the
past, EL's product cycle has required that it be branched on its
timeline NOT fedora's. So if Fedora is late, then the branch is taken
anyway and people start working on that to meet the EL roadmap. Thus
EL-3 is branched not from RH-9 but RH-9 beta. EL-4 is branched from
FC-3 beta ad EL-5 FC-6 beta.

Because packages are pushed into a release that hae major changes
(FC-6 final and RHEL-5 are very different in various packages so you
have to be careful getting some stuff moved over.) For the branching
to work it would need to be done at the END of a cycle. So instead of
RHEL-6 being based off of Fedora-11 it would need to be based off of
Fedora-8 when mainline does not make changes to it anymore.


-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

[Les Mikesell]

Stephen John Smoogen wrote:
>  
> > But the first question should be why a separate community is necessary.  Why
> > is it not possible for one of fedora's goals to be to provide a clean
> > transition to RHEL or Centos at the end of certain development cycles, at
> > which point EPEL/Rpmfusion, etc. would be unnecessary as separate entities
> > since that fedora cycle's repository would be directly usable as-is and
> > would simply need to be maintained instead of the various 3rd party versions
> > that have been necessary to fill this void?
>  
>  It would take a change in the branching of EL from Fedora. In the
>  past, EL's product cycle has required that it be branched on its
>  timeline NOT fedora's. 
And now?   I don't think fedora is a suitable starting point for a 
server OS so perhaps things will change for other reasons.  From a 
user's perspective the approach was always wrong anyway.  It would be 
good for both RHEL and fedora if they didn't really branch within a 
version - that is, at some point the RH betas take over the 
corresponding fedora release and fedora takes its wild and crazy changes 
to a new release.

>  So if Fedora is late, then the branch is taken
>  anyway and people start working on that to meet the EL roadmap. Thus
>  EL-3 is branched not from RH-9 but RH-9 beta. EL-4 is branched from
>  FC-3 beta ad EL-5 FC-6 beta. 
Even so, some people claim to have done successful upgrades from fedora 
to the corresponding EL/Centos with just a few quirks that probably 
could have been avoided with a little central planning.  That is, even 
if it is impossible to coordinate the changes that lead to RHEL/Centos, 
there should be a way to have the final fedora update do a clean 
conversion - or at least better than most users could do on their own.

>  Because packages are pushed into a release that hae major changes
>  (FC-6 final and RHEL-5 are very different in various packages so you
>  have to be careful getting some stuff moved over.) For the branching
>  to work it would need to be done at the END of a cycle. So instead of
>  RHEL-6 being based off of Fedora-11 it would need to be based off of
>  Fedora-8 when mainline does not make changes to it anymore. 
The question isn't so much whether it is easy or not, it is whether 
thousands of people should have to figure out on their own how to make 
this transition when fedora abandons their support or whether it should 
be planned and automatic.  The harder it is, the more critical it is to 
have it planned once and designed to be repeatable.  Personally I don't 
think 'long term fedora support' makes a bit of sense in terms of 
maintaining an update repository for years that is incompatible with, 
but only slightly different from RHEL or Centos, but neither does 
abandoning the community of users that developed around a fedora release 
and now needs a way to put their work into production.  It also doesn't 
make much sense for EPEL to be something different than the final 
version of the fedora release that becomes the enterprise version plus 
ongoing updates.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

[Kevin Kofler]

Les Mikesell <lesmikesell <at> gmail.com> writes:
>  user's perspective the approach was always wrong anyway.  It
> would be 
>  good for both RHEL and fedora if they didn't really branch within a 
>  version - that is, at some point the RH betas take over the 
>  corresponding fedora release and fedora takes its wild and crazy changes 
>  to a new release. 
Look, what you're asking for is really impossible:

1. There is no way RHEL will branch from a near-EOL or EOL Fedora release just 
so you can safely upgrade from that version to RHEL. It would mean throwing out 
at least a year of development and going back to old stuff, and RHEL would ship 
with very outdated software (there are *already* complaints about its software 
being outdated, but that's unavoidable due to stabilization/QA and 
certification, but users would not tolerate even older software, they'd use a 
competitor with newer software). It would also not help those who already 
upgraded to a newer Fedora release.

2. There is also no way Fedora will stop pushing version upgrades to the 
releases RHEL gets branched from, that's not how Fedora works. Fedora is about 
bringing current software to our users and version upgrades are part of that. 
There are also several cases where backporting security fixes is much harder 
than just upgrading to a new version. It would also affect not just the version 
RHEL gets branched from, but the previous version (or even 2 versions below if 
it's the first month after a release) too, for obvious upgrade path reasons. 
And many Fedora users would see a move like that as RH perverting Fedora for 
their own purposes.

So Fedora will always have at least some packages which are newer than the RHEL 
versions at any point in time, and thus it is impossible to guarantee an 
upgrade path in that direction.

>  Even so, some people claim to have done successful upgrades from
> fedora 
>  to the corresponding EL/Centos with just a few quirks that probably 
>  could have been avoided with a little central planning. 
No amount of planning is going to avoid the fundamental impossibility outlined 
above. The upgrades you mention were either from long-EOL Fedora releases (that 
can work out, but it means months or even years without security updates!) or 
involved downgrading several packages (e.g. the kernel).

>  That is, even if it is impossible to coordinate the changes that lead
> to
>  RHEL/Centos, there should be a way to have the final fedora update do a clean 
>  conversion - or at least better than most users could do on their own. 
Even if you think there should be a way, the fact is that there is none.

         Kevin Kofler

[Horst H. von Brand]

Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:

[...]

>  Even so, some people claim to have done successful upgrades from
>  fedora to the corresponding EL/Centos with just a few quirks that
>  probably could have been avoided with a little central planning.  That
>  is, even if it is impossible to coordinate the changes that lead to
>  RHEL/Centos, there should be a way to have the final fedora update do
>  a clean conversion - or at least better than most users could do on
>  their own. 
Why on earth would anybody start out on Fedora, and then move over to
RHEL/CentOS when it nears EOL? Better start off on RHEL/CentOS...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

[Les Mikesell]

Horst H. von Brand wrote:
>  
> > Even so, some people claim to have done successful upgrades from
> > fedora to the corresponding EL/Centos with just a few quirks that
> > probably could have been avoided with a little central planning.  That
> > is, even if it is impossible to coordinate the changes that lead to
> > RHEL/Centos, there should be a way to have the final fedora update do
> > a clean conversion - or at least better than most users could do on
> > their own.
>  
>  Why on earth would anybody start out on Fedora, and then move over to
>  RHEL/CentOS when it nears EOL? Better start off on RHEL/CentOS... 
That puts you about a year and a half behind if you wait for the release 
before starting.  Or you are developing to wildly different libraries, 
database versions, etc., etc. if you develop on the current version for 
something you plan to run on the next one.

-- 
    Les Mikesell
     lesmikesell(a)gmail.com

[Emmanuel Seyman]

* Les Mikesell [12/10/2008 17:28] :
>  Why is it not possible for one of fedora's goals to be to provide a  
>  clean transition to RHEL or Centos at the end of certain development  
>  cycles, 
-1.

Fedora already has a mission, one that I agree 100%. Anything that
distracts us from that mission is a negative.

Get the RHEL people to cover migrations from other distributions to RHEL
and the CentOS prople to cover migrations to CentOS. The Fedora people
should only be concerned with migrations to Fedora, not from it.

Emmanuel

[Chuck Anderson]

On Sun, Oct 12, 2008 at 06:03:03PM +0200, Emmanuel Seyman wrote:
>  * Les Mikesell [12/10/2008 17:28] :
>  >
>  > Why is it not possible for one of fedora's goals to be to provide a  
>  > clean transition to RHEL or Centos at the end of certain development  
>  > cycles,
>  
>  -1.
>  
>  Fedora already has a mission, one that I agree 100%. Anything that
>  distracts us from that mission is a negative.
>  
>  Get the RHEL people to cover migrations from other distributions to RHEL
>  and the CentOS prople to cover migrations to CentOS. The Fedora people
>  should only be concerned with migrations to Fedora, not from it. 
So we should make sure Fedora can upgrade old RHEL installations?  And 
how about cross-grading Ubuntu to Fedora?  Now that would be a hoot 
:-)

[Kevin Kofler]

Chuck Anderson <cra <at> WPI.EDU> writes:
>  So we should make sure Fedora can upgrade old RHEL installations?
That actually mostly works. "upgradeany" is your friend.

        Kevin Kofler

[Les Mikesell]

Emmanuel Seyman wrote:
>  * Les Mikesell [12/10/2008 17:28] :
> > Why is it not possible for one of fedora's goals to be to provide a  
> > clean transition to RHEL or Centos at the end of certain development  
> > cycles,
>  
>  -1.
>  
>  Fedora already has a mission, one that I agree 100%. Anything that
>  distracts us from that mission is a negative. 
Yes but what is the point of developing for it?  That is, why design 
anything or build support infrastructure for a planned dead-end? In 
particular, why should anyone even try building/running server software 
on fedora when it is clearly not a suitable environment.

>  Get the RHEL people to cover migrations from other distributions to
> RHEL
>  and the CentOS prople to cover migrations to CentOS. The Fedora people
>  should only be concerned with migrations to Fedora, not from it. 
First you have to give someone a reason to want to migrate to Fedora. 
With a planned progression to an enterprise version, that would not 
really be a migration away from fedora but the expected end point where 
you are permitted to continue using anything you've contributed or 
developed for your own use, staying in the same community instead of 
having all previous work dumped out the window at the end of a cycle. 
I'll point out again that this is the way Red Hat developed its 
popularity, although it was probably a mistake to have tried to support 
every release forever.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

[Kevin Kofler]

Les Mikesell <lesmikesell <at> gmail.com> writes:
>  With a planned progression to an enterprise version, that would not 
>  really be a migration away from fedora but the expected end point where 
>  you are permitted to continue using anything you've contributed or 
>  developed for your own use, staying in the same community instead of 
>  having all previous work dumped out the window at the end of a cycle.  
You don't have to throw away the development you've done, you just have to keep 
it updated with progress in technology. Or find somebody else who will, e.g. by 
getting your work integrated into some upstream project or by starting a Free 
Software project on your own. Fedora is not and will never be about "fire and 
forget" type of development.

        Kevin Kofler

[Emmanuel Seyman]

* Les Mikesell [12/10/2008 22:14] :
>  Yes but what is the point of developing for it? 
There's a notion called freedom that you may have heard of.

>  With a planned progression to an enterprise version, that would not 
>
>  really be a migration away from fedora but the expected end point where   
Again, this supposes that one of Fedora's end goals is to easily
permit its users to migrate to other distributions. This isn't the
case.

>  you are permitted to continue using anything you've contributed
> or  
>  developed for your own use, staying in the same community instead of  
>  having all previous work dumped out the window at the end of a cycle.   
When a Fedora version release reaches EOL, users have the possibility
of upgrading to the next release. These days, they even have the option
of upgrading to the release following that one if they wait long enough.
I have no idea where you get the notion that we're guiding users to a
"planned dead-end" or that, once a Fedora release is EOL-ed, they have
to dump out their work out the window.

If your goal is to use an distribution that promises ABI/API
compatibility, long term support and other "enterprise" features, there
are a whole host of distributions for which these are goals.
Why not use them ?
 
Emmanuel

[Les Mikesell]

Emmanuel Seyman wrote:
> > Yes but what is the point of developing for it?
>  
>  There's a notion called freedom that you may have heard of. 
And how is that specific to Fedora?  I meant as opposed to a system 
where you can actually deploy something that needs stability.

> > With a planned progression to an enterprise version, that would
> not  
> > really be a migration away from fedora but the expected end point where  
>  
>  Again, this supposes that one of Fedora's end goals is to easily
>  permit its users to migrate to other distributions. This isn't the
>  case. 
Agreed, Fedora does not seem suitable as is.

> > you are permitted to continue using anything you've
> contributed or  
> > developed for your own use, staying in the same community instead of  
> > having all previous work dumped out the window at the end of a cycle.  
>  
>  When a Fedora version release reaches EOL, users have the possibility
>  of upgrading to the next release. These days, they even have the option
>  of upgrading to the release following that one if they wait long enough.
>  I have no idea where you get the notion that we're guiding users to a
>  "planned dead-end" or that, once a Fedora release is EOL-ed, they have
>  to dump out their work out the window. 
I've used Fedora... Every version ends support quickly.  Frequently the 
next version has completely incompatible versions of libraries, 
programs, and API's.  It's not something you can run in production.

>  If your goal is to use an distribution that promises ABI/API
>  compatibility, long term support and other "enterprise" features, there
>  are a whole host of distributions for which these are goals.
>  Why not use them ? 
Local development for things you want to put into production progresses 
at about the same rate as the system itself.  If you wait for an 
enterprise version's release before starting, you'll be about a year and 
a half behind.  If you develop on the previous enterprise version, there 
will be a huge version jump in libraries, database versions, jvms, etc. 
that will require changes and not take advantage of new capabilities. 
For all the same reasons that the Fedora components need to be developed 
together, so does local development for the things you want to run on it 
- but Fedora never turns into something you can use for a long term or 
where you need reliability.

-- 
    Les Mikesell
     lesmikesell(a)gmail.com

[Emmanuel Seyman]

* Les Mikesell [13/10/2008 09:57] :
>  Emmanuel Seyman wrote:
>
> > There's a notion called freedom that you may have heard of.
>
>  And how is that specific to Fedora?  I meant as opposed to a system  
>  where you can actually deploy something that needs stability. 
There are few distributions that I consider as free as Fedora and
none that I would consider more free.

>  Local development for things you want to put into production
> progresses  
>  at about the same rate as the system itself.  If you wait for an  
>  enterprise version's release before starting, you'll be about a year and  
>  a half behind.  If you develop on the previous enterprise version, there  
>  will be a huge version jump in libraries, database versions, jvms, etc.  
>  that will require changes and not take advantage of new capabilities.   
This sounds like you have an issue with the entreprise distributions and
you're trying to shoehorn Fedora into being a stopgap solution for it.
Why don't you work with the entreprise distributions' communities to
find a better solution ?

Emmanuel

[Les Mikesell]

Emmanuel Seyman wrote:
>  
> >> There's a notion called freedom that you may have heard of.
> > And how is that specific to Fedora?  I meant as opposed to a system  
> > where you can actually deploy something that needs stability.
>  
>  There are few distributions that I consider as free as Fedora and
>  none that I would consider more free. 
OK, but how much of that freedom originates in Fedora?  I don't see how 
omitting more things from a distribution helps anyone.  But that's a 
different issue.

> > Local development for things you want to put into production
> progresses  
> > at about the same rate as the system itself.  If you wait for an  
> > enterprise version's release before starting, you'll be about a year and  
> > a half behind.  If you develop on the previous enterprise version, there  
> > will be a huge version jump in libraries, database versions, jvms, etc.  
> > that will require changes and not take advantage of new capabilities.  
>  
>  This sounds like you have an issue with the entreprise distributions and
>  you're trying to shoehorn Fedora into being a stopgap solution for it.
>  Why don't you work with the entreprise distributions' communities to
>  find a better solution ? 
The issue is that the enterprise distributions don't put their own brand 
name on the early development work and ship it so users have a smooth 
transition through development, testing and the final release.  But the 
reason that doesn't happen is that Fedora fills that role except for 
providing a smooth transition to something production-ready.  I don't 
think it is me 'shoehorning' Fedora into the role that RH X.0 releases 
used to fill.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

[Emmanuel Seyman]

* Les Mikesell [13/10/2008 14:48] :
>  The issue is that the enterprise distributions don't put their own brand  
>  name on the early development work and ship it so users have a smooth  
>  transition through development, testing and the final release.  But the   
Again, this sounds like a problem that the entreprise distributions are
responsible. Working with them to release betas seems like the best
solution to your problem, IMHO.

Emmanuel

[Les Mikesell]

Emmanuel Seyman wrote:
>  * Les Mikesell [13/10/2008 14:48] :
> > The issue is that the enterprise distributions don't put their own brand  
> > name on the early development work and ship it so users have a smooth  
> > transition through development, testing and the final release.  But the  
>  
>  Again, this sounds like a problem that the entreprise distributions are
>  responsible.  
Yes, of course.  The change happened when RH stopped shipping X.0 
versions that were subsequently updated to X.1, X.2, etc. as they did 
through up through the 7.3 version, keeping the same community of users 
through the process.

>  Working with them to release betas seems like the best
>  solution to your problem, IMHO. 
But Fedora _is_ the beta now... Or at least it was before the direction 
turned away from something suitable for servers.  I'm not quite sure 
where things are going now.

-- 
   Les Mikesell
    lesmikesell#gmail.com

[Horst H. von Brand]

Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:

[...]

>  First you have to give someone a reason to want to migrate to
>  Fedora. With a planned progression to an enterprise version, that
>  would not really be a migration away from fedora but the expected end
>  point where you are permitted to continue using anything you've
>  contributed or developed for your own use, staying in the same
>  community instead of having all previous work dumped out the window at
>  the end of a cycle. I'll point out again that this is the way Red Hat
>  developed its popularity, although it was probably a mistake to have
>  tried to support every release forever. 
Fedora is _not_ enterprise, it is _not_ in its goals, it is _not_ it's
target audience. Why would anybody start on Fedora planning to "graduate"
to EL?
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  [phone]

[Les Mikesell]

Horst H. von Brand wrote:
>  Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:
>  
> > First you have to give someone a reason to want to migrate to
> > Fedora. With a planned progression to an enterprise version, that
> > would not really be a migration away from fedora but the expected end
> > point where you are permitted to continue using anything you've
> > contributed or developed for your own use, staying in the same
> > community instead of having all previous work dumped out the window at
> > the end of a cycle. I'll point out again that this is the way Red Hat
> > developed its popularity, although it was probably a mistake to have
> > tried to support every release forever.
>  
>  Fedora is _not_ enterprise, it is _not_ in its goals, it is _not_ it's
>  target audience. Why would anybody start on Fedora planning to "graduate"
>  to EL? 
For exactly the same reason that people used to use RH X.0 versions for 
development and testing, planning to  run their programs on X.2 as both 
their local development and the distribution mature.  That's what made 
RH popular.  And there is no equivalent now that Fedora never matures to 
a supported stable version.

-- 
    Les Mikesell
     lesmikesell(a)gmail.com

[Robert Locke]

On Sun, 2008-10-12 at 21:41 -0500, Les Mikesell wrote:
>  Horst H. von Brand wrote:
>  > Les Mikesell <lesmikesell(a)gmail.com&gt; wrote:
>  > 
>  >> First you have to give someone a reason to want to migrate to
>  >> Fedora. With a planned progression to an enterprise version, that
>  >> would not really be a migration away from fedora but the expected end
>  >> point where you are permitted to continue using anything you've
>  >> contributed or developed for your own use, staying in the same
>  >> community instead of having all previous work dumped out the window at
>  >> the end of a cycle. I'll point out again that this is the way Red Hat
>  >> developed its popularity, although it was probably a mistake to have
>  >> tried to support every release forever.
>  > 
>  > Fedora is _not_ enterprise, it is _not_ in its goals, it is _not_ it's
>  > target audience. Why would anybody start on Fedora planning to "graduate"
>  > to EL?
>  
>  For exactly the same reason that people used to use RH X.0 versions for 
>  development and testing, planning to  run their programs on X.2 as both 
>  their local development and the distribution mature.  That's what made 
>  RH popular.  And there is no equivalent now that Fedora never matures to 
>  a supported stable version.
>   
So, we are talking about doing development on a platform that evolves
and represents the latest in open source technology?  And we are wanting
to deploy on a production ready/stable release?  Doesn't the current
Fedora for development, and CentOS/RHEL for production not satisfy your
need?

I think the only thing missing from your need is a smooth "in-place"
upgrade capability?

But how often is development done (for a year or so) that then becomes
the actual production system?  Would not the production system be
installed in parallel as you approached the timeframe for deployment?

--Rob

[Kevin Kofler]

Robert Locke <lists <at> ralii.com> writes:
>  But how often is development done (for a year or so) that then
> becomes
>  the actual production system?  Would not the production system be
>  installed in parallel as you approached the timeframe for deployment? 
They probably use the infamous "developmestuction" methodology. :-/

http://thedailywtf.com/Articles/The_Developmestuction_Environment.aspx

        Kevin Kofler

[Till Maas]

On Sun October 12 2008, Les Mikesell wrote:

>  But the first question should be why a separate community is
> necessary.
>    Why is it not possible for one of fedora's goals to be to provide a
>  clean transition to RHEL or Centos at the end of certain development
>  cycles, at which point EPEL/Rpmfusion, etc. would be unnecessary as
>  separate entities since that fedora cycle's repository would be directly
>  usable as-is and would simply need to be maintained instead of the
>  various 3rd party versions that have been necessary to fill this void? 
You only need people to test this and document what needs to be done, like the 
yum upgrade SIG do. They document what is needed to run an upgrade without 
using anaconda from one Fedora release to another.

Regards,
Till

[Les Mikesell]

Till Maas wrote:
>  On Sun October 12 2008, Les Mikesell wrote:
>  
> > But the first question should be why a separate community is necessary.
> >   Why is it not possible for one of fedora's goals to be to provide a
> > clean transition to RHEL or Centos at the end of certain development
> > cycles, at which point EPEL/Rpmfusion, etc. would be unnecessary as
> > separate entities since that fedora cycle's repository would be directly
> > usable as-is and would simply need to be maintained instead of the
> > various 3rd party versions that have been necessary to fill this void?
>  
>  You only need people to test this and document what needs to be done, like the 
>  yum upgrade SIG do. They document what is needed to run an upgrade without 
>  using anaconda from one Fedora release to another. 
Change 'document' to 'script' and I might agree with you.  No one really 
wants to know what one-off oddball quirks need to be handled between 
distros/versions, they just want it to be done correctly.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

[D. Hugh Redelmeier]

| From: Les Mikesell <lesmikesell(a)gmail.com&gt;

| But the first question should be why a separate community is necessary.  Why
| is it not possible for one of fedora's goals to be to provide a clean
| transition to RHEL or Centos at the end of certain development cycles

I think that this idea has some merit.  I'm taking this out of context
to use as a jump-off point.

[I'm a long-term Red Hat and Fedora user.  I also use Ubuntu
sometimes.]

Ubuntu 8.04 LTS has seduced me with its simultaneous promises of being
maintained and having a current code base.

RHEL/CentOS feels too old.  Concrete issues:

- support for video cards

- PostgreSQL 8.3 vs 8.1

Ubuntu 8.04 will be quite stale before the next LTS comes out.
Probably more stale that RHEL/CentOS.  It is all a matter of where
each stream is in the cycle.  Right now, Ubuntu LTS is ahead of
RHEL/CentOS.

Ubuntu LTS is in the same series as regular Ubuntu.  RHEL/CentOS are
not the same as Fedora.  One could predict that the transition costs
between Ubuntus are lower that the transition costs from RHEL/CentOS
to or from Fedora.  This is a disadvantage.

I find the various Fedora-targeted 3rd party repositories confusing
and even conflicting.  This isn't healthy.  I've not had this problem
with Ubuntu but I'm not sure why.


I like that fedora is willing to take radical steps.  This is the only
way to do some important experiments.


Some changes make me (a conservative at heart) uncomfortable:

- the idea that network connectivity is part of a session just seems
  bizarre to me.  Network Manager may be useful but I think that this
  aspect does not fit in with my UNIX world-view.

- the idea that non-X consoles will go bothers me.  Just a few minutes
  ago, I used a non-X console to whack on an X problem.  I hit a lot
  of X problems due to the way hardware gets introduced more quickly
  than X versions are released (and debugged).  I may stop using
  Fedora when this change comes to pass.

- Documentation that I expect is not provided.

- the anatomy of the system changes more quickly than my
  understanding.  HAL/d-bus/etc. all seem like magic to me.



Why should a (source) package release be tied to a distro release?
For a lot of packages, the actual minimum requirements on the
environment are satisfied by earlier distro releases.

The strongest argument against is to do with testing: real
dependencies might diverge from declared dependencies and only testing
can show this.  This adds a lot of testing burden to the package
maintainer.

Some packages really are not independent modules.  Updating such a
package may require updating a lot of others.  At least sometimes
these binary packages are all created from a single source package.


I wonder if smooth evolution (frequent uncoordinated package updates),
as opposed to punctuated equilibrium (updates tied to distro releases)
would work.

[Luya Tshimbalanga]

Quoting "D. Hugh Redelmeier" <hugh(a)mimosa.com&gt;:

>  | From: Les Mikesell <lesmikesell(a)gmail.com&gt;
>
>  | But the first question should be why a separate community is necessary.
>  Why
>  | is it not possible for one of fedora's goals to be to provide a clean
>  | transition to RHEL or Centos at the end of certain development cycles
>
>  I think that this idea has some merit.  I'm taking this out of context
>  to use as a jump-off point.
>
>  [I'm a long-term Red Hat and Fedora user.  I also use Ubuntu
>  sometimes.]
>
>  Ubuntu 8.04 LTS has seduced me with its simultaneous promises of being
>  maintained and having a current code base.
>
>  RHEL/CentOS feels too old.  Concrete issues:
>
>  - support for video cards
>
>  - PostgreSQL 8.3 vs 8.1 

Obvious reasons, RHEL/CentOS are enterprise distributions where support for old
applications and old hardware are important. Trying to install a brand new
system without testing stability, perfornamce before applying to enterprise
fields is plain silly. Wikipedia is a non-profit organization, not an
enterprise.

>  Ubuntu 8.04 will be quite stale before the next LTS comes out.
>  Probably more stale that RHEL/CentOS.  It is all a matter of where
>  each stream is in the cycle.  Right now, Ubuntu LTS is ahead of
>  RHEL/CentOS.
>
>  Ubuntu LTS is in the same series as regular Ubuntu.  RHEL/CentOS are
>  not the same as Fedora.  One could predict that the transition costs
>  between Ubuntus are lower that the transition costs from RHEL/CentOS
>  to or from Fedora.  This is a disadvantage. 
 It is very easy to be attracted by low cost transition without considering for
a long term approach. Remember Oracle promised the same thing with their
Unbreakable distribition. In this case, it is about Canonical that are looking
to make money because they are not even profitable since their inception. Time
will tell how successful Canonical strategy will be.

>  I find the various Fedora-targeted 3rd party repositories confusing
>  and even conflicting.  This isn't healthy.  I've not had this problem
>  with Ubuntu but I'm not sure why. 
Blame the software patents system. Fedora being an USA distribution cannot
afford for being a big target for patent vultures and, because of this FOSS
philosophy, does not include any closed and patented applications (apart
Firmware which are separate problems). Ubuntu chose to made compromise being a
non-USA distribution but has to follow US Patent law. It will be foolish to not
consider those legal issues especially for company like Canonical and Red Hat.

>  I like that fedora is willing to take radical steps.  This is the only
>  way to do some important experiments.
>
>
>  Some changes make me (a conservative at heart) uncomfortable:
>
>  - the idea that network connectivity is part of a session just seems
>    bizarre to me.  Network Manager may be useful but I think that this
>    aspect does not fit in with my UNIX world-view. 
That is the problem: your UNIX world-view.

>  - the idea that non-X consoles will go bothers me.  Just a few
> minutes
>    ago, I used a non-X console to whack on an X problem.  I hit a lot
>    of X problems due to the way hardware gets introduced more quickly
>    than X versions are released (and debugged).  I may stop using
>    Fedora when this change comes to pass. 
What about other methods that may replace the old one?


>  - Documentation that I expect is not provided. 
Which one?

>  - the anatomy of the system changes more quickly than my
>    understanding.  HAL/d-bus/etc. all seem like magic to me. 
Perhaps a difficulty to adapt.


-- 
Luya Tshimbalanga
Fedora Project contributor
http://www.fedoraproject.org/wiki/LuyaTshimbalanga

[Michael Schwendt]

On Sat, 11 Oct 2008 23:33:41 +0200, Patrice Dumas wrote:

>  My proposal was clear: start the project when somebody has
> volunteered
>  for each of the packages that are in @code and @base (and maybe other
>  comps groups, I don't remember exactly). And keep a page with the
>  packages maintained such as not to give wrong expectations. 
Be careful with a project based on promises. Somebody might volunteer to
maintain a package, but leave the project already prior to the first
important security-fix due to lack of time or because of more important
obligations. Learn from Fedora Legacy's fate. Not enough commitment from
the target group. Too much bureaucracy for the few people who prepared
updates [= a slow review process in bugzilla even for small patches copied
from RHEL, lack of trust, all contributors had to wait for reviews,
bottle-necks in the build'n'release process]. With every week a security
update had to wait somewhere in a review ticket, some more people
(including contributors) left the target group.

[Stephen John Smoogen]

On Tue, Oct 21, 2008 at 3:39 PM, Michael Schwendt <mschwendt(a)gmail.com&gt; wrote:
>  On Sat, 11 Oct 2008 23:33:41 +0200, Patrice Dumas wrote:
>
> > My proposal was clear: start the project when somebody has volunteered
> > for each of the packages that are in @code and @base (and maybe other
> > comps groups, I don't remember exactly). And keep a page with the
> > packages maintained such as not to give wrong expectations.
>
>  Be careful with a project based on promises. Somebody might volunteer to
>  maintain a package, but leave the project already prior to the first
>  important security-fix due to lack of time or because of more important
>  obligations. Learn from Fedora Legacy's fate. Not enough commitment from
>  the target group. Too much bureaucracy for the few people who prepared
>  updates [= a slow review process in bugzilla even for small patches copied
>  from RHEL, lack of trust, all contributors had to wait for reviews,
>  bottle-necks in the build'n'release process]. With every week a security
>  update had to wait somewhere in a review ticket, some more people
>  (including contributors) left the target group.
>  
Now that we are constructive talking.. how can we lower the
bureaucracy and build trust in an environment where its all based on
who knows who and relationships take a long time to build up (I mean
this for any project from the Linux kernel, etc.) And you are correct,
my attitude towards Ralph earlier stunk.



-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

[Michael Schwendt]

On Tue, 21 Oct 2008 15:54:20 -0600, Stephen John Smoogen wrote:

>  Now that we are constructive talking.. how can we lower the
>  bureaucracy and build trust in an environment where its all based on
>  who knows who and relationships take a long time to build up (I mean
>  this for any project from the Linux kernel, etc.) 
Well, that's the interesting part of starting such a project. ;) How many
of the "interested developers" will be new people who would register in
FAS for the first time? How much information about themselves are they
willing to disclose? Inside the Fedora project you need to ask yourself
anyway how much you trust fellow contributors? Some are with the project
for several years, but you need to rely on the sponsorship process as you
don't know everyone (and you don't verify regularly that it's still the
same person who uses a fedora account or that the intentions are still
good).

How many volunteer specialists are available to support some of the huge
core packages? Copying and rediff'ing patches only is one thing, porting
patches between versions is something completely different. In an older
discussion I've suggested a dry-run for such a project. It could start
with F8 EOL, albeit a boring period and a lot to do (evaluating
vulnerability notifications alone is a lot of work). How patient would
contributors stay before they would give up or switch to another dist?

If reviewing is needed, the core team of a LTS project could sign off
patches submitted by completely new contributors, who haven't been active
in Fedora before. It ought not create significant delays in getting
something published, as contributors will likely become unsatisfactory
soon with productivity issues or find other reasons to leave. There are
existing procedures, such as the sponsor- or mentor-model for new
people. Existing infrastructure would help, too: pkg cvs commit diffs
posted to a mailing-list, for example, which is not a separate list on a
server in some other domain. This adds the possibility that some
completely unexpected pair of eyes skims over the diffs, rather than just
a small number of contributors. More convenient than having to do rpmdiff
manually. Source tarballs can be checksum-compared with newer Fedora
branches in lookaside cache.

[Patrice Dumas]

On Tue, Oct 21, 2008 at 11:39:12PM +0200, Michael Schwendt wrote:
>  On Sat, 11 Oct 2008 23:33:41 +0200, Patrice Dumas wrote:
>  
>  > My proposal was clear: start the project when somebody has volunteered
>  > for each of the packages that are in @code and @base (and maybe other
>  > comps groups, I don't remember exactly). And keep a page with the
>  > packages maintained such as not to give wrong expectations.
>  
>  Be careful with a project based on promises. Somebody might volunteer to
>  maintain a package, but leave the project already prior to the first
>  important security-fix due to lack of time or because of more important
>  obligations. Learn from Fedora Legacy's fate. Not enough commitment from
>  the target group. Too much bureaucracy for the few people who prepared
>  updates [= a slow review process in bugzilla even for small patches copied
>  from RHEL, lack of trust, all contributors had to wait for reviews,
>  bottle-necks in the build'n'release process]. With every week a security
>  update had to wait somewhere in a review ticket, some more people
>  (including contributors) left the target group. 
My proposal has always been to use the exact same procedures than in
fedora, so nothing like in fedora legacy.

--
Pat

[Michael Schwendt]

On Tue, 21 Oct 2008 23:59:06 +0200, Patrice Dumas wrote:

>  My proposal has always been to use the exact same procedures than in
>  fedora, so nothing like in fedora legacy. 
In Fedora you don't become a kernel/glibc/X pkg maintainer all of a
sudden. You would either work at Red Hat, or you would have to use the
current kernel-maintainers as your proxy for quite a long time before they
would approve a "commits" request in pkgdb.

[Patrice Dumas]

On Wed, Oct 22, 2008 at 02:08:53AM +0200, Michael Schwendt wrote:
>  On Tue, 21 Oct 2008 23:59:06 +0200, Patrice Dumas wrote:
>  
>  > My proposal has always been to use the exact same procedures than in
>  > fedora, so nothing like in fedora legacy.
>  
>  In Fedora you don't become a kernel/glibc/X pkg maintainer all of a
>  sudden. You would either work at Red Hat, or you would have to use the
>  current kernel-maintainers as your proxy for quite a long time before they
>  would approve a "commits" request in pkgdb. 
The idea here is to open ACLs for release that are no longer supported.

--
Pat

[Michael Schwendt]

On Wed, 22 Oct 2008 02:52:17 +0200, Patrice Dumas wrote:

>  On Wed, Oct 22, 2008 at 02:08:53AM +0200, Michael Schwendt wrote:
>  > On Tue, 21 Oct 2008 23:59:06 +0200, Patrice Dumas wrote:
>  > 
>  > > My proposal has always been to use the exact same procedures than in
>  > > fedora, so nothing like in fedora legacy.
>  > 
>  > In Fedora you don't become a kernel/glibc/X pkg maintainer all of a
>  > sudden. You would either work at Red Hat, or you would have to use the
>  > current kernel-maintainers as your proxy for quite a long time before they
>  > would approve a "commits" request in pkgdb.
>  
>  The idea here is to open ACLs for release that are no longer supported. 
I do understand that, but we talk past eachother. Let's assume you start
with the F-8 branch opened up to all packagers. Then you still need a
procedure where previously unknown people join the project and be
sponsored or something like that to get direct access to the pkgs and
buildsys and so on.

[Patrice Dumas]

On Wed, Oct 22, 2008 at 11:16:21AM +0200, Michael Schwendt wrote:
>  
>  I do understand that, but we talk past eachother. Let's assume you start
>  with the F-8 branch opened up to all packagers. Then you still need a
>  procedure where previously unknown people join the project and be
>  sponsored or something like that to get direct access to the pkgs and
>  buildsys and so on. 
I see, you mean that, given the different target, people wanting to
participate to a fedora EOL would be different from people participating 
in fedora (say, like, people wanting to participate in EPEL but not 
in fedora). I didn't thought about that, but it seems to me that going
through bugzilla should be enough? The EOL SIG should take care of the
patches.

--
Pat

[Benny Amorsen]

Matej Cepl <mcepl(a)redhat.com&gt; writes:

>  b) If anybody is running production servers on Fedora, then worse 
>     for him -- Fedora is a developers' distro and that's the 
>     reason why it has limited support. 
If your set up is such that you can survive an upgrade every 9 months,
Fedora is fine for servers.

With Fedora, you get benefits of the bleeding edge. Linux software in
general, even server software, is improving rapidly, and having your
software stack 12 months (or more) ahead of the competition is
valuable.

For servers, you can often do a full Fedora upgrade with yum and not
even have to reboot at the same time. That's officially unsupported,
but you can't get a support contract from Fedora anyway.


/Benny

[Arthur Pemberton]

On Fri, Oct 10, 2008 at 7:53 AM, Itamar - IspBrasil
<itamar(a)ispbrasil.com.br&gt; wrote:
>  forwarding message from Rodrigo Padula
>
>  any chance to increase the life of fedora releases ?
>
>  or fedora will be only blending edge ?
>
>  In my opinion fedora is losing space from centos and ubuntu
>  

Markets like that should be using Centos. I have no opinion on Ubuntu,
except that I don't personally feel they contribute enough to the
community.

According to the article, these people were using Fedora and Redhat 9.
Based on that they probably have been using some EOLed Fedora for
years now. In which switching to an updated Ubuntu is much better.
Ideally, they should have switched to Centos however.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )

[Arthur Pemberton]

On Fri, Oct 10, 2008 at 7:53 AM, Itamar - IspBrasil
<itamar(a)ispbrasil.com.br&gt; wrote:
>  forwarding message from Rodrigo Padula
>
>  any chance to increase the life of fedora releases ?
>
>  or fedora will be only blending edge ?
>
>  In my opinion fedora is losing space from centos and ubuntu 

Reading the article again, no mention was made of Centos. Only Fedora
and RedHat were considered. They didn't want to pay, but didn't
consider Centos. That leads me to believe that whoever was making the
decision before knew that they wanted Ubuntu and just  gave a
justification after the fact -- which is really their right, but
misleading of them.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )

[Callum Lerwick]

On Fri, 2008-10-10 at 09:53 -0300, Itamar - IspBrasil wrote:
>  forwarding message from Rodrigo Padula
>  
>  any chance to increase the life of fedora releases ?
>  
>  or fedora will be only blending edge ?
>  
>  In my opinion fedora is losing space from centos and ubuntu 
We're nearing a release so I guess it's time for dead threads to rise
again:

http://fedoraproject.org/wiki/FWN/Issue117#Long-term_Support_Release

...but I seem to be too late to nip this thread in the bud.

[Christopher Brown]

2008/10/10 Callum Lerwick <seg(a)haxxed.com&gt;:
>  On Fri, 2008-10-10 at 09:53 -0300, Itamar - IspBrasil wrote:
> > forwarding message from Rodrigo Padula
> >
> > any chance to increase the life of fedora releases ?
> >
> > or fedora will be only blending edge ?
> >
> > In my opinion fedora is losing space from centos and ubuntu
>
>  We're nearing a release so I guess it's time for dead threads to rise
>  again:
>
>  http://fedoraproject.org/wiki/FWN/Issue117#Long-term_Support_Release 
No I think this horse is still twitching a litttle...

-- 
Christopher Brown

http://www.chruz.com

[Behdad Esfahbod]

Itamar - IspBrasil wrote:
>  forwarding message from Rodrigo Padula
>  
>  any chance to increase the life of fedora releases ?
>  
>  or fedora will be only blending edge ?
>  
>  In my opinion fedora is losing space from centos and ubuntu 
I agree with the rest of the threda that CentOS *is* Fedora LTS!
The major problem Wikipedia faced seems to me more being that
Fedora/RHEL/CentOS is not really upgradeable, whereas Debian/Ubuntu handled
upgrades quite nicely.  *That* seems to be a major weakness of us.

My 0.02CAD
behdad

>  
>  -------- Original Message --------
>  Subject:     Wikipidia - Goodbye Red Hat and Fedora
>  Date:     Fri, 10 Oct 2008 09:42:55 -0300
>  From:     Rodrigo Padula de Oliveira <rodrigopadula(a)projetofedora.org&gt;
>  Reply-To:     For discussions about marketing and expanding the Fedora
>  user base <fedora-marketing-list(a)redhat.com&gt;
>  To:     For discussions about marketing and expanding the Fedora user
>  base <fedora-marketing-list(a)redhat.com&gt;
>  
>  
>  
>  Hello Guys!
>  
>  Read this bad news:
>  
>  http://www.linuxworld.com.au/index.php/id;1474805050;fp;16;fpid;1
>  
>  This is happening frequently. I think we will have to revise some things
>  within the project, particularly the creation of a Legacy project or a
>  Fedora LTS.
>  
>  The brazilian government, one of the biggest Fedora Case of the world is
>  changing from Fedora/ Red Hat to Ubuntu/Debian.
>  
>  We need to think and create a solution to give support by a long time or
>  the fedora user will decrease!
>  
>  My 0,02
>

[Arthur Pemberton]

On Fri, Oct 10, 2008 at 4:56 PM, Behdad Esfahbod <behdad(a)behdad.org&gt; wrote:
>  Itamar - IspBrasil wrote:
> > forwarding message from Rodrigo Padula
> >
> > any chance to increase the life of fedora releases ?
> >
> > or fedora will be only blending edge ?
> >
> > In my opinion fedora is losing space from centos and ubuntu
>
>  I agree with the rest of the threda that CentOS *is* Fedora LTS!
>  The major problem Wikipedia faced seems to me more being that
>  Fedora/RHEL/CentOS is not really upgradeable, whereas Debian/Ubuntu handled
>  upgrades quite nicely.  *That* seems to be a major weakness of us. 

I saw no mention of Centos, though someone in the thread mentioned
that it had been attempted. Your point about upgrade makes sense,
though I find it pretty weak. Is doing an inplace upgrade on a
production server common? I don't think so, but I am quite possibly
wrong.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )

[Rahul Sundaram]

Arthur Pemberton wrote:
>  
>  I saw no mention of Centos, though someone in the thread mentioned
>  that it had been attempted. Your point about upgrade makes sense,
>  though I find it pretty weak. Is doing an inplace upgrade on a
>  production server common? I don't think so, but I am quite possibly
>  wrong. 
In my previous organization working as a administrator, I was asked by a 
server owner to live upgrade his Red Hat Linux 9 system to Fedora Core 2 
even though there was several hundreds of active domains in it. They had 
backups but time was absolutely of essence that he was willing to risk 
it. The upgrade via yum turned out to be fine in the end. I suspect 
situations like these are not very uncommon and more people will be able 
to use it, if we spend some resources tackling the problem. Thankfully, 
it is happening already.

Now that PackageKit has support for distro upgrades (ie) desktop 
notification for new releases, the situation is much better for many 
users. Preupgrade which PackageKit will be using to do the job, is also 
enhanced by making use of the blacklist and whiteout yum plugins that 
have been split up from Anaconda.

Rahul

[Kevin Kofler]

Behdad Esfahbod <behdad <at> behdad.org> writes:
>  The major problem Wikipedia faced seems to me more being that
>  Fedora/RHEL/CentOS is not really upgradeable, whereas Debian/Ubuntu handled
>  upgrades quite nicely.  *That* seems to be a major weakness of us. 
The same "apt-get dist-upgrade" which works on Debian/Ubuntu just works here 
too (with apt-rpm - I've done several upgrades to the next Fedora release that 
way), as does yum (which is better supported and nowadays also more reliable). 
And don't forget that Anaconda also supports upgrades (for RHEL, "upgrade" 
or "upgradeany" is your friend; you can even switch from RHEL/CentOS to Fedora 
with upgradeany (the opposite will only work properly if your Fedora is 
completely outdated though)).

         Kevin Kofler

[Behdad Esfahbod]

Kevin Kofler wrote:
>  Behdad Esfahbod <behdad <at> behdad.org> writes:
> > The major problem Wikipedia faced seems to me more being that
> > Fedora/RHEL/CentOS is not really upgradeable, whereas Debian/Ubuntu handled
> > upgrades quite nicely.  *That* seems to be a major weakness of us.
>  
>  The same "apt-get dist-upgrade" which works on Debian/Ubuntu just works here 
>  too (with apt-rpm - I've done several upgrades to the next Fedora release that 
>  way), as does yum (which is better supported and nowadays also more reliable). 
>  And don't forget that Anaconda also supports upgrades (for RHEL, "upgrade"
>
>  or "upgradeany" is your friend; you can even switch from RHEL/CentOS to Fedora
>
>  with upgradeany (the opposite will only work properly if your Fedora is 
>  completely outdated though)). 
You certainly "can", but does it "work"?

behdad

>           Kevin Kofler
>

[Seth Vidal]

On Fri, 2008-10-10 at 19:27 -0400, Behdad Esfahbod wrote:
>  Kevin Kofler wrote:
>  > Behdad Esfahbod <behdad <at> behdad.org> writes:
>  >> The major problem Wikipedia faced seems to me more being that
>  >> Fedora/RHEL/CentOS is not really upgradeable, whereas Debian/Ubuntu handled
>  >> upgrades quite nicely.  *That* seems to be a major weakness of us.
>  > 
>  > The same "apt-get dist-upgrade" which works on Debian/Ubuntu just works
> here 
>  > too (with apt-rpm - I've done several upgrades to the next Fedora release that 
>  > way), as does yum (which is better supported and nowadays also more reliable). 
>  > And don't forget that Anaconda also supports upgrades (for RHEL,
> "upgrade" 
>  > or "upgradeany" is your friend; you can even switch from RHEL/CentOS to
> Fedora 
>  > with upgradeany (the opposite will only work properly if your Fedora is 
>  > completely outdated though)).
>  
>  You certainly "can", but does it "work"?
>   
It really depends on the package set you've got.


If you're talking about a server w/o an infinite set of pkgs installed,
sure, it's doable.

If you're talking about an ornate and baroque pkg selection on a server
which does a bazillion things, no, it won't be a clean process. notably,
it won't be clean on ANY distro.

-sv