f18: how to install into a LVM partitions (or RAID)

[Dario Lesca]

Hi, I have download the last Fedora-18-Beta-TC4 to do some tests
http://dl.fedoraproject.org/pub/alt/stage/18-Beta-TC4/Fedora/x86_64/iso/F...

How to install it on a empty disk and use LVM (or create a software
RaID)?

> From the new disk manager anaconda panel I did not understand how to
create a new LVM partition and root and swap volume.

Is this features not yet supported or I have lost some HOWTO?

Many thanks

-- 
Dario Lesca - sip:[e-mail]
(Inviato dal mio Linux Fedora 17 Gnome3)

[Ian Pilcher]

On 10/16/2012 08:29 AM, Dario Lesca wrote:
>  How to install it on a empty disk and use LVM (or create a software
>  RaID)? 
I don't believe it's currently possible.  Nor is it possible to use
space in existing VGs or RAID devices.

It's unclear whether F18 final is going to include this functionality
or not.

-- 
========================================================================
Ian Pilcher                                         arequipeno(a)gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.
========================================================================

[Dario Lesca]

Il giorno mar, 16/10/2012 alle 10.20 -0500, Ian Pilcher ha scritto:
>  It's unclear whether F18 final is going to include this
> functionality
>  or not.  
Hopefully it is not so, You're kidding, right?

If this feature is not included then you can not update F1[0-7] on
systems that have used LVM / RAID: all my PCs and laptops.

Mi question is: Why change the interface disk partitioning? the previous
interface was perfect ... here is another thing, that worked well, was
sacrificed in honor of the news.

Thanks for reply

-- 
Dario Lesca - sip:[e-mail]
(Inviato dal mio Linux Fedora 17 Gnome3)

[Jesse Keating]

On 10/16/2012 08:53 AM, Dario Lesca wrote:
>  If this feature is not included then you can not update F1[0-7] on
>  systems that have used LVM / RAID: all my PCs and laptops. 
Anaconda no longer handles upgrades, so this isn't a concern.

-- 
Help me fight child abuse: http://tinyurl.com/jlkcourage

- jlk

[Vít Ondruch]

Dne 16.10.2012 18:06, Jesse Keating napsal(a):
>  On 10/16/2012 08:53 AM, Dario Lesca wrote:
> > If this feature is not included then you can not update F1[0-7] on
> > systems that have used LVM / RAID: all my PCs and laptops.
>
>  Anaconda no longer handles upgrades, so this isn't a concern.
>  
Oh come on. I have LVM and luks on my system with different versions of 
Fedora. I want to install Fedora into newly created partitions, but I 
can't, since Anaconda does not display the LVM volume label, so I don't 
know what is what, nor let me unlock luks partition.

Upgrade would be if I want to move from my F17 to F18, but I want to 
install them side by side (which is not upgrade) and that is not possible.


Vit

[Adam Williamson]

On Wed, 2012-10-17 at 10:49 +0200, Vít Ondruch wrote:
>  Dne 16.10.2012 18:06, Jesse Keating napsal(a):
>  > On 10/16/2012 08:53 AM, Dario Lesca wrote:
>  >> If this feature is not included then you can not update F1[0-7] on
>  >> systems that have used LVM / RAID: all my PCs and laptops.
>  >
>  > Anaconda no longer handles upgrades, so this isn't a concern.
>  >
>  
>  Oh come on. I have LVM and luks on my system with different versions of 
>  Fedora. I want to install Fedora into newly created partitions, but I 
>  can't, since Anaconda does not display the LVM volume label, so I don't 
>  know what is what, nor let me unlock luks partition.
>  
>  Upgrade would be if I want to move from my F17 to F18, but I want to 
>  install them side by side (which is not upgrade) and that is not possible. 
I think this is going in the wrong direction. The whole discussion was
based on a false premise: newUI does intend to handle LUKS, LVM and
RAID. Where it doesn't read and display an existing LUKS, LVM and/or
RAID-based layout correctly/usefully this is a bug, please report it as
such. Those earlier in the thread who leapt to the conclusion that
anaconda did not handle these things any more were *incorrect*.

Jesse, above, is only saying that upgrades no longer go through
anaconda, so any upgrade-related concerns are irrelevant. But for the
purposes of fresh installs, newUI is intended to handle the creation of
new LUKS/LVM/RAID devices and the display and editing of existing ones.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Juan Orti Alcaine]

On Martes, 16 de octubre de 2012 10:20:50 Ian Pilcher escribió:
>  On 10/16/2012 08:29 AM, Dario Lesca wrote:
>  > How to install it on a empty disk and use LVM (or create a software
>  > RaID)?
>  
>  I don't believe it's currently possible.  Nor is it possible to use
>  space in existing VGs or RAID devices.
>  
>  It's unclear whether F18 final is going to include this functionality
>  or not. 
I think It's totally unacceptable to lose this functionality. The new GUI 
should have been pushed when it has all the features of the old GUI, we have 
lost a lot of testing in alpha because people could not upgrade their existing 
setups.

I just hope the support for RAID, LVM, Luks,...  to be available in the beta, 
or this feature should be reverted.

[Dario Lesca]

Il giorno mar, 16/10/2012 alle 17.59 +0200, Juan Orti Alcaine ha
scritto:
>  I think It's totally unacceptable to lose this functionality.
+1 ... I'm Totally agree

-- 
Dario Lesca - sip:[e-mail]
(Inviato dal mio Linux Fedora 17 Gnome3)

[David Lehman]

On Tue, 2012-10-16 at 15:29 +0200, Dario Lesca wrote:
>  Hi, I have download the last Fedora-18-Beta-TC4 to do some tests
>
> http://dl.fedoraproject.org/pub/alt/stage/18-Beta-TC4/Fedora/x86_64/iso/F...
>  
>  How to install it on a empty disk and use LVM (or create a software
>  RaID)?
>  
>  From the new disk manager anaconda panel I did not understand how to
>  create a new LVM partition and root and swap volume.
>   
1. Click the + button near the bottom of the screen.
2. Enter '/' for mountpoint and whatever size you want.
3. Hit Confirm or Add or whatever the dialog button is.
4. Select the new mountpoint on the left side of the
   screen.
5. Click the + on the right side of the screen to edit
   the device options.
6. Select your desired device type from the available
   options, which will include LVM.

Repeat for swap. (Hint: enter "swap" as the mountpoint
when adding the device initially)


Various tips:

Both the size and mountpoint entries in the "Add Mountpoint" dialog have
tooltips, so hover the mouse pointer on them if you are in doubt as to
how to specify these things.

If you want the device you are adding to grow to occupy as much space as
is possible, leave the size field blank when adding the device
initially. When editing a defined device, if you want to make it as
large as possible, specify a size greater than the available space. The
installer will grow the device as close to your requested size as
possible. This also works when adding a new device.

Devices are not treated as "growable" once they have been defined, so if
you define one device with a blank size and then try to define another
without adjusting the first one, it will probably fail due to
insufficient free space. This makes sense if you think about it, so
don't file a bug for it.

>  Is this features not yet supported or I have lost some HOWTO? 
There's a very brief HOWTO above. I am hoping to produce a basic
beginners' guide at some point, but time is scarce.

>  
>  Many thanks
>  
>  -- 
>  Dario Lesca - sip:[e-mail]
>  (Inviato dal mio Linux Fedora 17 Gnome3)
>

[Adam Williamson]

On Tue, 2012-10-16 at 13:22 -0500, David Lehman wrote:
>  On Tue, 2012-10-16 at 15:29 +0200, Dario Lesca wrote:
>  > Hi, I have download the last Fedora-18-Beta-TC4 to do some tests
>  >
> http://dl.fedoraproject.org/pub/alt/stage/18-Beta-TC4/Fedora/x86_64/iso/F...
>  > 
>  > How to install it on a empty disk and use LVM (or create a software
>  > RaID)?
>  > 
>  > From the new disk manager anaconda panel I did not understand how to
>  > create a new LVM partition and root and swap volume.
>  > 
>  
>  1. Click the + button near the bottom of the screen.
>  2. Enter '/' for mountpoint and whatever size you want.
>  3. Hit Confirm or Add or whatever the dialog button is.
>  4. Select the new mountpoint on the left side of the
>     screen.
>  5. Click the + on the right side of the screen to edit
>     the device options.
>  6. Select your desired device type from the available
>     options, which will include LVM. 
Note that these instructions cover *what to do when you get into custom
partitioning mode*. My other mail explained how to get into custom
partitioning.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Richard Marko]

On 10/16/2012 08:22 PM, David Lehman wrote:
>  On Tue, 2012-10-16 at 15:29 +0200, Dario Lesca wrote:
> > Hi, I have download the last Fedora-18-Beta-TC4 to do some tests
> >
> http://dl.fedoraproject.org/pub/alt/stage/18-Beta-TC4/Fedora/x86_64/iso/F...
> >
> > How to install it on a empty disk and use LVM (or create a software
> > RaID)?
> >
> > From the new disk manager anaconda panel I did not understand how to
> > create a new LVM partition and root and swap volume.
> >
>  1. Click the + button near the bottom of the screen.
>  2. Enter '/' for mountpoint and whatever size you want.
>  3. Hit Confirm or Add or whatever the dialog button is.
>  4. Select the new mountpoint on the left side of the
>     screen.
>  5. Click the + on the right side of the screen to edit
>     the device options.
>  6. Select your desired device type from the available
>     options, which will include LVM.
>
>  Repeat for swap. (Hint: enter "swap" as the mountpoint
>  when adding the device initially) 
Previous structured partitioning dialog was much better compared to
this. Why
it was removed in favor of this confusing thing?


>  Various tips:
>
>  Both the size and mountpoint entries in the "Add Mountpoint" dialog have
>  tooltips, so hover the mouse pointer on them if you are in doubt as to
>  how to specify these things.
>
>  If you want the device you are adding to grow to occupy as much space as
>  is possible, leave the size field blank when adding the device
>  initially. When editing a defined device, if you want to make it as
>  large as possible, specify a size greater than the available space. The
>  installer will grow the device as close to your requested size as
>  possible. This also works when adding a new device.
>
>  Devices are not treated as "growable" once they have been defined, so if
>  you define one device with a blank size and then try to define another
>  without adjusting the first one, it will probably fail due to
>  insufficient free space. This makes sense if you think about it, so
>  don't file a bug for it.
>
> > Is this features not yet supported or I have lost some HOWTO?
>  There's a very brief HOWTO above. I am hoping to produce a basic
>  beginners' guide at some point, but time is scarce.
>
> > Many thanks
> >
> > -- 
> > Dario Lesca - sip:[e-mail]
> > (Inviato dal mio Linux Fedora 17 Gnome3)
> >
>  

-- 
Richard Marko

[David Lehman]

On Wed, 2012-10-17 at 14:28 +0200, Richard Marko wrote:
>  Previous structured partitioning dialog was much better compared to
>  this. Why
>  it was removed in favor of this confusing thing? 
to keep you on your toes, of course

[Dario Lesca]

Il giorno mer, 17/10/2012 alle 08.37 -0500, David Lehman ha scritto:
>  to keep you on your toes, of course 
you forgot ;-) ... because if you're talking seriously this is a wild
unacceptable answer

What is the real reason for this (for now unjustified) change?

Does anyone know?

-- 
Dario Lesca - sip:[e-mail]
(Inviato dal mio Linux Fedora 17 Gnome3)

[Adam Williamson]

On Wed, 2012-10-17 at 16:05 +0200, Dario Lesca wrote:
>  Il giorno mer, 17/10/2012 alle 08.37 -0500, David Lehman ha scritto:
>  > to keep you on your toes, of course
>  
>  you forgot ;-) ... because if you're talking seriously this is a wild
>  unacceptable answer
>  
>  What is the real reason for this (for now unjustified) change?
>  
>  Does anyone know? 
Was the old one really better, or were you just used to it? Comparing
the first time you use the new dialog to the 50th time you used the old
one is an entirely unfair comparison. You have to compare the first time
you use the new dialog to the first time you used the old one. *Any* new
design will seem more difficult than the old one, at first, to someone
who was familiar with the old one.

I think the new dialog could use some improvements, and it's getting
them, but a question like 'the old one ruled, the new one sucks, why u
change?!' is really not that productive. The reasons for the UI
re-design are in the feature page.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Clyde E. Kunkel]

On 10/17/2012 11:55 AM, Adam Williamson wrote:
>  On Wed, 2012-10-17 at 16:05 +0200, Dario Lesca wrote:
> > Il giorno mer, 17/10/2012 alle 08.37 -0500, David Lehman ha scritto:
> >> to keep you on your toes, of course
> >
> > you forgot ;-) ... because if you're talking seriously this is a wild
> > unacceptable answer
> >
> > What is the real reason for this (for now unjustified) change?
> >
> > Does anyone know?
>
>  Was the old one really better, or were you just used to it? Comparing
>  the first time you use the new dialog to the 50th time you used the old
>  one is an entirely unfair comparison. You have to compare the first time
>  you use the new dialog to the first time you used the old one. *Any* new
>  design will seem more difficult than the old one, at first, to someone
>  who was familiar with the old one.
>
>  I think the new dialog could use some improvements, and it's getting
>  them, but a question like 'the old one ruled, the new one sucks, why u
>  change?!' is really not that productive. The reasons for the UI
>  re-design are in the feature page.
>  
The newui is akin to gnome 3 in that it takes some getting used to. Now, 
g3 is second nature and very usable.  Using newui as much as possible, 
and filing bugs, helps a lot.  My only gripe is that the storage portion 
of F17 worked very well at final and I only wish that logic had gone 
into F18 from alpha on.  Why fight the storage battle again when it has 
already been won?

-- 
Regards,
OldFart

[Ian Pilcher]

On 10/17/2012 10:55 AM, Adam Williamson wrote:
>  Was the old one really better, or were you just used to it?
> Comparing
>  the first time you use the new dialog to the 50th time you used the old
>  one is an entirely unfair comparison. You have to compare the first time
>  you use the new dialog to the first time you used the old one. *Any* new
>  design will seem more difficult than the old one, at first, to someone
>  who was familiar with the old one. 
Just my opinion, but I believe that a lot of the confusion is caused by
the lack of a clear statement that LVM, RAID, etc., are *supposed* to
work.

We are at the beta test compose stage, which most people interpret to
mean something close to feature complete.  Combine this with the fact
there's no indication in the UI (that I could discern) of support for
existing RAID arrays or LVM VGs, and I don't believe it's at all
unreasonable to wonder if this functionality is simply being removed.

-- 
========================================================================
Ian Pilcher                                         arequipeno(a)gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.
========================================================================

[Adam Williamson]

On Thu, 2012-10-18 at 12:17 -0500, Ian Pilcher wrote:
>  On 10/17/2012 10:55 AM, Adam Williamson wrote:
>  > Was the old one really better, or were you just used to it? Comparing
>  > the first time you use the new dialog to the 50th time you used the old
>  > one is an entirely unfair comparison. You have to compare the first time
>  > you use the new dialog to the first time you used the old one. *Any* new
>  > design will seem more difficult than the old one, at first, to someone
>  > who was familiar with the old one.
>  
>  Just my opinion, but I believe that a lot of the confusion is caused by
>  the lack of a clear statement that LVM, RAID, etc., are *supposed* to
>  work.
>  
>  We are at the beta test compose stage, which most people interpret to
>  mean something close to feature complete.  Combine this with the fact
>  there's no indication in the UI (that I could discern) of support for
>  existing RAID arrays or LVM VGs, and I don't believe it's at all
>  unreasonable to wonder if this functionality is simply being removed. 
I'm not sure what 'indication' you're expecting, exactly. AIUI, existing
RAID arrays and VGs should just show up in the list of existing
filesystems on the left-hand side of the custom partitioning screen. (In
a recent enough Beta TC, of course, Alpha is ancient stuff now). If they
don't, that's a bug. Do you have a case where they don't? If so, it
should just be reported as a bug.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Ian Pilcher]

On 10/18/2012 05:02 PM, Adam Williamson wrote:
>  I'm not sure what 'indication' you're expecting,
> exactly. AIUI, existing
>  RAID arrays and VGs should just show up in the list of existing
>  filesystems on the left-hand side of the custom partitioning screen. (In
>  a recent enough Beta TC, of course, Alpha is ancient stuff now). If they
>  don't, that's a bug. Do you have a case where they don't? If so, it
>  should just be reported as a bug.
>   
They didn't the last time I checked, which I believe was beta TC2.

Just checked again in a test VM and I don't see any way to use the free
space in the existing VG.  (vgdisplay reports 7.74 GiB free of 19.48
GiB.)

On the left hand side, I see:

- New Fedora 18-Beta-TC2
  Installation

    You haven't created any mount points for your
    Fedora 18-Beta-TC2 installation yet:

    Click here to create them automatically

    Or, create new mount points below with the '+'
    icon.

- CentOS Linux 6.3 for x86_64

  DATA
  SYSTEM

    Root            7.92 GB
    /
    Swap          4.09 GB

- Unknown
    Unknown         19.97 GB

    Unknown            498 MB

    Unknown          19.97 GB

When I attempt to add a 6GB "mount point" for /, I get a "not enough
free space on disks" error.

So how's it supposed to work?

-- 
========================================================================
Ian Pilcher                                         arequipeno(a)gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.
========================================================================

[Adam Williamson]

On Thu, 2012-10-18 at 23:12 -0500, Ian Pilcher wrote:
>  On 10/18/2012 05:02 PM, Adam Williamson wrote:
>  > I'm not sure what 'indication' you're expecting, exactly. AIUI,
> existing
>  > RAID arrays and VGs should just show up in the list of existing
>  > filesystems on the left-hand side of the custom partitioning screen. (In
>  > a recent enough Beta TC, of course, Alpha is ancient stuff now). If they
>  > don't, that's a bug. Do you have a case where they don't? If so, it
>  > should just be reported as a bug.
>  > 
>  
>  They didn't the last time I checked, which I believe was beta TC2.
>  
>  Just checked again in a test VM and I don't see any way to use the free
>  space in the existing VG.  (vgdisplay reports 7.74 GiB free of 19.48
>  GiB.)
>  
>  On the left hand side, I see:
>  
>  - New Fedora 18-Beta-TC2
>    Installation
>  
>      You haven't created any mount points for your
>      Fedora 18-Beta-TC2 installation yet:
>  
>      Click here to create them automatically
>  
>      Or, create new mount points below with the '+'
>      icon.
>  
>  - CentOS Linux 6.3 for x86_64
>  
>    DATA
>    SYSTEM
>  
>      Root            7.92 GB
>      /
>      Swap          4.09 GB
>  
>  - Unknown
>      Unknown         19.97 GB
>  
>      Unknown            498 MB
>  
>      Unknown          19.97 GB
>  
>  When I attempt to add a 6GB "mount point" for /, I get a "not enough
>  free space on disks" error.
>  
>  So how's it supposed to work? 
So it looks like the / and swap partitions of the CentOS 6.3 install are
inside the VG, and there's ~8GB of space left inside the 20GB VG, but
we're not recognizing that space. The fact that the VG simply shows up
as 'Unknown' is probably wrong too.

So I'm not sure how the UI is actually supposed to present this, but
it's clearly not what we really want to happen :) Can you file a bug
against anaconda with the info from this mail (maybe a screenshot)? The
anaconda folks will be able to take a look at it. Thanks.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[David Lehman]

On Thu, 2012-10-18 at 23:12 -0500, Ian Pilcher wrote:
>  On 10/18/2012 05:02 PM, Adam Williamson wrote:
>  > I'm not sure what 'indication' you're expecting, exactly. AIUI,
> existing
>  > RAID arrays and VGs should just show up in the list of existing
>  > filesystems on the left-hand side of the custom partitioning screen. (In
>  > a recent enough Beta TC, of course, Alpha is ancient stuff now). If they
>  > don't, that's a bug. Do you have a case where they don't? If so, it
>  > should just be reported as a bug.
>  > 
>  
>  They didn't the last time I checked, which I believe was beta TC2.
>  
>  Just checked again in a test VM and I don't see any way to use the free
>  space in the existing VG.  (vgdisplay reports 7.74 GiB free of 19.48
>  GiB.)
>   
<<snip>>

>  When I attempt to add a 6GB "mount point" for /, I get a
> "not enough
>  free space on disks" error.
>  
>  So how's it supposed to work? 
This is the main piece of functionality that's still missing: allocating
devices from preexisting VGs.

You can create and destroy lvm devices. You can reuse existing LVs,
optionally reformatting them. You can encrypt or decrypt them. What you
cannot do is allocate new LVs from old VGs. That's sort of the last item
on the TODO list.

[Ian Pilcher]

On 10/19/2012 10:01 AM, David Lehman wrote:
>  You can create and destroy lvm devices. You can reuse existing LVs,
>  optionally reformatting them. You can encrypt or decrypt them. What you
>  cannot do is allocate new LVs from old VGs. That's sort of the last item
>  on the TODO list. 
Is this functionality planned for the beta?  GA?  F19?

As I said up-thread, I believe that this information should be much more
widely disseminated.

-- 
========================================================================
Ian Pilcher                                         arequipeno(a)gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.
========================================================================

[David Lehman]

On Fri, 2012-10-19 at 18:24 -0500, Ian Pilcher wrote:
>  On 10/19/2012 10:01 AM, David Lehman wrote:
>  > You can create and destroy lvm devices. You can reuse existing LVs,
>  > optionally reformatting them. You can encrypt or decrypt them. What you
>  > cannot do is allocate new LVs from old VGs. That's sort of the last item
>  > on the TODO list.
>  
>  Is this functionality planned for the beta?  GA?  F19? 
It is planned (but at risk) for the beta and a must-have for GA.

David

>  
>  As I said up-thread, I believe that this information should be much more
>  widely disseminated.
>  
>  -- 
>  ========================================================================
>  Ian Pilcher                                         arequipeno(a)gmail.com
>  Sometimes there's nothing left to do but crash and burn...or die trying.
>  ========================================================================

[Ian Pilcher]

On 10/25/2012 10:46 AM, David Lehman wrote:
>  It is planned (but at risk) for the beta and a must-have for GA.
If it's a must-have for GA, but it isn't in the beta, how does it get
tested?

-- 
========================================================================
Ian Pilcher                                         arequipeno(a)gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.
========================================================================

[David Lehman]

On Fri, 2012-10-26 at 09:36 -0500, Ian Pilcher wrote:
>  On 10/25/2012 10:46 AM, David Lehman wrote:
>  > It is planned (but at risk) for the beta and a must-have for GA.
>  
>  If it's a must-have for GA, but it isn't in the beta, how does it get
>  tested? 
Before it goes in it will be discussed by the installer team and qa and
rel-eng and whoever else needs to be involved and a decision will be
made as to whether to include it.

>  
>  -- 
>  ========================================================================
>  Ian Pilcher                                         arequipeno(a)gmail.com
>  Sometimes there's nothing left to do but crash and burn...or die trying.
>  ========================================================================

[Adam Williamson]

On Fri, 2012-10-26 at 09:36 -0500, Ian Pilcher wrote:
>  On 10/25/2012 10:46 AM, David Lehman wrote:
>  > It is planned (but at risk) for the beta and a must-have for GA.
>  
>  If it's a must-have for GA, but it isn't in the beta, how does it get
>  tested? 
As part of Final validation testing.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Ian Pilcher]

On 10/19/2012 10:01 AM, David Lehman wrote:
>  This is the main piece of functionality that's still missing:
> allocating
>  devices from preexisting VGs.
>  
>  You can create and destroy lvm devices. You can reuse existing LVs,
>  optionally reformatting them. You can encrypt or decrypt them. What you
>  cannot do is allocate new LVs from old VGs. That's sort of the last item
>  on the TODO list. 
It looks like this is still the case in beta RC1, right?

-- 
========================================================================
Ian Pilcher                                         arequipeno(a)gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.
========================================================================

[David Lehman]

On Wed, 2012-11-21 at 12:09 -0600, Ian Pilcher wrote:
>  On 10/19/2012 10:01 AM, David Lehman wrote:
>  > This is the main piece of functionality that's still missing: allocating
>  > devices from preexisting VGs.
>  > 
>  > You can create and destroy lvm devices. You can reuse existing LVs,
>  > optionally reformatting them. You can encrypt or decrypt them. What you
>  > cannot do is allocate new LVs from old VGs. That's sort of the last item
>  > on the TODO list.
>  
>  It looks like this is still the case in beta RC1, right? 
Yes. I've just completed testing of patches for this stuff. It was
decided that it's too late to try to get them into the Beta. I can
provide you with an updates image that adds the functionality if you are
interested.

David

[Clyde E. Kunkel]

On 11/21/2012 03:01 PM, David Lehman wrote:
>  <snip>
>  Yes. I've just completed testing of patches for this stuff. It was
>  decided that it's too late to try to get them into the Beta. I can
>  provide you with an updates image that adds the functionality if you are
>  interested.
>
>  David
>  
I, for one, would be interested.  Will the image be usable with RC9?

Thanks for all of your hard work!!

-- 
Regards,
OldFart

[Ian Pilcher]

On 11/21/2012 02:01 PM, David Lehman wrote:
>  On Wed, 2012-11-21 at 12:09 -0600, Ian Pilcher wrote:
> >
> > It looks like this is still the case in beta RC1, right?
>  
>  Yes. I've just completed testing of patches for this stuff. It was
>  decided that it's too late to try to get them into the Beta. I can
>  provide you with an updates image that adds the functionality if you are
>  interested.
>   
Please.  Thanks!

-- 
========================================================================
Ian Pilcher                                         arequipeno(a)gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.
========================================================================

[David Lehman]

On Wed, 2012-11-21 at 14:01 -0600, David Lehman wrote:
>  On Wed, 2012-11-21 at 12:09 -0600, Ian Pilcher wrote:
>  > On 10/19/2012 10:01 AM, David Lehman wrote:
>  > > This is the main piece of functionality that's still missing: allocating
>  > > devices from preexisting VGs.
>  > > 
>  > > You can create and destroy lvm devices. You can reuse existing LVs,
>  > > optionally reformatting them. You can encrypt or decrypt them. What you
>  > > cannot do is allocate new LVs from old VGs. That's sort of the last item
>  > > on the TODO list.
>  > 
>  > It looks like this is still the case in beta RC1, right?
>  
>  Yes. I've just completed testing of patches for this stuff. It was
>  decided that it's too late to try to get them into the Beta. I can
>  provide you with an updates image that adds the functionality if you are
>  interested. 
See https://bugzilla.redhat.com/show_bug.cgi?id=860677#c10

>  
>  David
>

[Dario Lesca]

Il giorno mar, 16/10/2012 alle 13.22 -0500, David Lehman ha scritto:
>  Repeat for swap. (Hint: enter "swap" as the mountpoint
>  when adding the device initially)
>   
Ok, thanks, this steps work with a TC6.

There is a method to use and mount a previous partition (es. /home
or /opt) without format it?

Many thanks

-- 
Dario Lesca - sip:[e-mail]
(Inviato dal mio Linux Fedora 17 Gnome3)

[David Lehman]

On Mon, 2012-10-29 at 01:06 +0100, Dario Lesca wrote:
>  Il giorno mar, 16/10/2012 alle 13.22 -0500, David Lehman ha scritto:
>  > Repeat for swap. (Hint: enter "swap" as the mountpoint
>  > when adding the device initially)
>  > 
>  Ok, thanks, this steps work with a TC6.
>  
>  There is a method to use and mount a previous partition (es. /home
>  or /opt) without format it? 
Just select that device and enter the desired mountpoint without
changing the filesystem type or activating the "Reformat" checkbutton.


>  
>  Many thanks
>  
>  -- 
>  Dario Lesca - sip:[e-mail]
>  (Inviato dal mio Linux Fedora 17 Gnome3)
>

[Dario Lesca]

Il giorno lun, 29/10/2012 alle 09.05 -0500, David Lehman ha scritto:
>  Just select that device and enter the desired mountpoint without
>  changing the filesystem type or activating the "Reformat"
>  checkbutton.  
Where is the "Reformat" checkbutton?

sorry, but I do not see (see screenshot)

Thanks

-- 
Dario Lesca - sip:[e-mail]
(Inviato dal mio Linux Fedora 17 Gnome3)

[David Lehman]

On Mon, 2012-10-29 at 16:15 +0100, Dario Lesca wrote:
>  Il giorno lun, 29/10/2012 alle 09.05 -0500, David Lehman ha scritto:
>  > Just select that device and enter the desired mountpoint without
>  > changing the filesystem type or activating the "Reformat"
>  > checkbutton. 
>  
>  Where is the "Reformat" checkbutton? 
If your version of anaconda is too old to have a "Reformat" checkbutton
that is one less thing for you to worry about in this procedure. It was
not introduced until after TC6.

>  
>  sorry, but I do not see (see screenshot)
>  
>  Thanks
>

[Adam Williamson]

On Mon, 2012-10-29 at 15:43 -0500, David Lehman wrote:
>  On Mon, 2012-10-29 at 16:15 +0100, Dario Lesca wrote:
>  > Il giorno lun, 29/10/2012 alle 09.05 -0500, David Lehman ha scritto:
>  > > Just select that device and enter the desired mountpoint without
>  > > changing the filesystem type or activating the "Reformat"
>  > > checkbutton. 
>  > 
>  > Where is the "Reformat" checkbutton?
>  
>  If your version of anaconda is too old to have a "Reformat" checkbutton
>  that is one less thing for you to worry about in this procedure. It was
>  not introduced until after TC6. 
To be 100% clear: if you have a build where there is no 'reformat'
checkbox then the default and only behaviour anaconda has is not to
reformat the partition. Beta TC6 and all earlier builds had no ability
to re-use a partition while re-formatting it. That ability has been
added since Beta TC6.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Dario Lesca]

Il giorno lun, 29/10/2012 alle 17.09 -0700, Adam Williamson ha scritto:
>  That ability has been added since Beta TC6. 
ok, I'll wait a version > TC-6

Thanks to all
-- 
Dario Lesca - sip:[e-mail]
(Inviato dal mio Linux Fedora 17 Gnome3)

[Adam Williamson]

On Tue, 2012-10-30 at 08:17 +0100, Dario Lesca wrote:
>  Il giorno lun, 29/10/2012 alle 17.09 -0700, Adam Williamson ha
> scritto:
>  > That ability has been added since Beta TC6.
>  
>  ok, I'll wait a version > TC-6 
Sigh. Apparently I _still_ wasn't clear enough.

You indicated at the start of this side-thread that you wanted to use an
existing partition without re-formatting it. You can do so just fine
with TC6 or other Beta builds. If you re-use a partition in TC6 it will
be re-used without being re-formatted.

What is missing from TC6 and will be added in the next build is the
ability to choose to reformat the partition. If you do not want to
reformat it, this is not a problem for you.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Tom Lane]

It's time somebody asked this, so ...

Adam Williamson <awilliam(a)redhat.com&gt; writes:
>  What is missing from TC6 and will be added in the next build is the
>  ability to choose to reformat the partition. If you do not want to
>  reformat it, this is not a problem for you. 
It appears to me that anaconda is months away from being shippable.
It's still got major features that are incomplete (one example above,
but there are more), and I don't seem to be able to do anything at all
with it without hitting serious bugs.

How is it that we're even considering shipping this version for F18?
For any other package, we'd be telling the maintainer to hold off
till F19.  The rest of us don't get to be doing major feature
development post-beta-freeze.

			regards, tom lane

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Adam Williamson]

On Tue, 2012-10-30 at 14:08 -0400, Tom Lane wrote:
>  It's time somebody asked this, so ...
>  
>  Adam Williamson <awilliam(a)redhat.com&gt; writes:
>  > What is missing from TC6 and will be added in the next build is the
>  > ability to choose to reformat the partition. If you do not want to
>  > reformat it, this is not a problem for you.
>  
>  It appears to me that anaconda is months away from being shippable.
>  It's still got major features that are incomplete (one example above,
>  but there are more), and I don't seem to be able to do anything at all
>  with it without hitting serious bugs.
>  
>  How is it that we're even considering shipping this version for F18?
>  For any other package, we'd be telling the maintainer to hold off
>  till F19.  The rest of us don't get to be doing major feature
>  development post-beta-freeze. 
I'd recommend asking dcantrell, as he has some good points on this
topic. I broadly agree with him that it might well be more or less
impossible to smoothly handle a major rewrite of anaconda in our current
development process. CCing to make sure he sees this.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Gianluca Sforna]

On Tue, Oct 30, 2012 at 7:12 PM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  I'd recommend asking dcantrell, as he has some good points on
> this
>  topic. I broadly agree with him that it might well be more or less
>  impossible to smoothly handle a major rewrite of anaconda in our current
>  development process. CCing to make sure he sees this. 
If you are saying that 6 months are a too short time for something
like this I think I can understand it.

However, from the relevant feature page contingency plan:

"""
First, at some point before the development freeze, we need to merge
the newui branch into master in git. At this point, regular anaconda
builds will include the new UI and that's what everyone will see.
Should we not get to a point where we're comfortable with merging
before the development freeze, the contingency plan would simply be to
not merge and wait for the next Fedora release.

Second, after merging we are kind of committed to taking this UI in
for Fedora 18. It will be too large of a body of work to revert. Plus,
much of our effort will have been spent on the newui branch which
means regular bug fixing will have suffered. I do not have a good idea
of what the contingency plan for this point will be.
""""

So, apparently, we approved this feature knowing that after the merge
we effectively had no plan in case of large issues.

I don't know if it's impossible to revert to the F17 anaconda at this
time, however it is clear that F18 is going to be the longest release
cycle we had in 9 years and somehow we need to avoid this in the
future.

Cheers

G.

-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://identi.ca/giallu - http://twitter.com/giallu

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Adam Williamson]

On Tue, 2012-10-30 at 19:32 +0100, Gianluca Sforna wrote:

>  I don't know if it's impossible to revert to the F17 anaconda
> at this
>  time, however it is clear that F18 is going to be the longest release
>  cycle we had in 9 years and somehow we need to avoid this in the
>  future. 
It's not impossible, well, nothing is impossible, but at this point it's
almost certainly more of a disruption than just plowing on with newui.

It's worth noting quite a lot of the early issues in this cycle -
particularly during Alpha - weren't actually much to do with newui; they
were more to do with changes in dracut which affected anaconda. oldui
wasn't fixed for that, so if were to try and switch back to oldui at
this point, we'd have to go through the whole process of adjusting the
code for the changes to dracut again, quite apart from any other issues.

I think there are some larger issues to do with the Fedora dev cycle and
the feature process that could stand discussion and improvement on the
basis of the experience we've had with F18 so far, for sure. It would be
nice to avoid excessive negativity in doing so, though...I think
throughout everyone has tried their best. Practically speaking, for F18,
though, I think we just need to soldier on with newUI and get it done as
best we can. Obviously slipping the schedule by a week again and again
in response to the latest fire isn't the best way to do things, but
stepping back and taking a wider view, a release that's a month or two
behind but with a reasonably solid new anaconda wouldn't be a disaster. 

In a way I think the fact that various groups - QA, anaconda team, FESCo
- have all more or less agreed that we need to ensure decent quality in
the new installer even at the cost of schedule slips is a positive
result of the process; it's dangerous to posit counterfactuals, but I
suspect there are points in Fedora's history where we would have just
more or less stuck to the schedule and kicked out a final release on
time but with a really incomplete new anaconda. Whatever lessons we
learn from this release...I'd like them to be more about how we can
achieve major change with acceptable quality even if that means some
more flexibility about the release cycle, rather than starting from the
assumption that whatever we do, the goal is to stick closer to a fixed
short schedule.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[drago01]

On Tue, Oct 30, 2012 at 7:45 PM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  On Tue, 2012-10-30 at 19:32 +0100, Gianluca Sforna wrote:
>
> > I don't know if it's impossible to revert to the F17 anaconda at this
> > time, however it is clear that F18 is going to be the longest release
> > cycle we had in 9 years and somehow we need to avoid this in the
> > future.
>
>  It's not impossible, well, nothing is impossible, but at this point it's
>  almost certainly more of a disruption than just plowing on with newui.
>
>  It's worth noting quite a lot of the early issues in this cycle -
>  particularly during Alpha - weren't actually much to do with newui; they
>  were more to do with changes in dracut which affected anaconda. oldui
>  wasn't fixed for that, so if were to try and switch back to oldui at
>  this point, we'd have to go through the whole process of adjusting the
>  code for the changes to dracut again, quite apart from any other issues. 
The mistake was to accept a feature this large without a contingency
plan ... even the anaconda roadmap listed some features like
"upgrades" as to be finished by F19 beta.
So the people involved all knew that this was far from being ready.

But there is nothing we can do at this point ... other then outright
reject such features in the future.

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Paul W. Frields]

On Tue, Oct 30, 2012 at 11:45:02AM -0700, Adam Williamson wrote:
>  On Tue, 2012-10-30 at 19:32 +0100, Gianluca Sforna wrote:
>  
>  > I don't know if it's impossible to revert to the F17 anaconda at this
>  > time, however it is clear that F18 is going to be the longest release
>  > cycle we had in 9 years and somehow we need to avoid this in the
>  > future.
>  
>  It's not impossible, well, nothing is impossible, but at this point it's
>  almost certainly more of a disruption than just plowing on with newui. 
Also, I believe we haven't got close to the length of the Fedora Core
5 development cycle, which was more than 9 months.[1] Not that we
should aim for it either, but it's certainly not a given we'll even
get to that point.  Thanks for pointing out that everyone is trying
their best to avoid taking that prize.

* * *
[1] https://fedoraproject.org/wiki/Releases/HistoricalSchedules
-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
    The open source story continues to grow: http://opensource.com

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Seth Vidal]

On Tue, 30 Oct 2012, Paul W. Frields wrote:

>  On Tue, Oct 30, 2012 at 11:45:02AM -0700, Adam Williamson wrote:
> > On Tue, 2012-10-30 at 19:32 +0100, Gianluca Sforna wrote:
> >
> >> I don't know if it's impossible to revert to the F17 anaconda at this
> >> time, however it is clear that F18 is going to be the longest release
> >> cycle we had in 9 years and somehow we need to avoid this in the
> >> future.
> >
> > It's not impossible, well, nothing is impossible, but at this point it's
> > almost certainly more of a disruption than just plowing on with newui.
>
>  Also, I believe we haven't got close to the length of the Fedora Core
>  5 development cycle, which was more than 9 months.[1] Not that we
>  should aim for it either, but it's certainly not a given we'll even
>  get to that point.  Thanks for pointing out that everyone is trying
>  their best to avoid taking that prize. 

Fedora 5 was 9months intentionally, though.

it was intentionally lengthened to see if that would be useful.

this time is not intentional, aiui.
-sv

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Richard Hughes]

On 30 October 2012 18:45, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  so if were to try and switch back to oldui at
>  this point, we'd have to go through the whole process of adjusting the
>  code for the changes to dracut again, quite apart from any other issues. 
I don't understand how fixing up the old anaconda with the dracut
changes would be so difficult. More than 140 man-hours? It's surely
going to be a lot less work than getting anaconda to a point where it
actually works with a consistent UI. Anaconda isn't the kind of thing
we can fix with a zero day update, and surely it should have been
developed in parallel with a release and then "switched on" just after
branching rather than the situation we have now where there is major
design and development work being done *so close* to where we should
have everything locked down tight.

I really don't see why the Anaconda team should be treated so
differently from every other team. If we ship anything close to the
Anaconda we've got now then F18 is going to get ripped apart by the
reviewers.

Richard.

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[David Airlie]

----- Original Message -----
>  From: "Richard Hughes" <hughsient(a)gmail.com&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Sent: Wednesday, 31 October, 2012 6:35:14 AM
>  Subject: Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how	to install
> into a LVM partitions (or
>  RAID))
>  
>  On 30 October 2012 18:45, Adam Williamson <awilliam(a)redhat.com&gt;
>  wrote:
>  > so if were to try and switch back to oldui at
>  > this point, we'd have to go through the whole process of adjusting
>  > the
>  > code for the changes to dracut again, quite apart from any other
>  > issues.
>  
>  I don't understand how fixing up the old anaconda with the dracut
>  changes would be so difficult. More than 140 man-hours? It's surely
>  going to be a lot less work than getting anaconda to a point where it
>  actually works with a consistent UI. Anaconda isn't the kind of thing
>  we can fix with a zero day update, and surely it should have been
>  developed in parallel with a release and then "switched on" just
>  after
>  branching rather than the situation we have now where there is major
>  design and development work being done *so close* to where we should
>  have everything locked down tight.
>  
>  I really don't see why the Anaconda team should be treated so
>  differently from every other team. If we ship anything close to the
>  Anaconda we've got now then F18 is going to get ripped apart by the
>  reviewers. 
Should we just skip F18? (like seriously).

Dave.

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Brendan Conoboy]

On 10/30/2012 02:58 PM, David Airlie wrote:
>  Should we just skip F18? (like seriously). 
Seems a little over the top.  Why not use the extra time to squash other 
bugs, making F18 a better release overall?

-- 
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Tim Lauridsen]

On Tue, Oct 30, 2012 at 10:58 PM, David Airlie <airlied(a)redhat.com&gt; wrote:

>  ----- Original Message -----
>  > From: "Richard Hughes" <hughsient(a)gmail.com&gt;
>  > To: "Development discussions related to Fedora" <
>  devel(a)lists.fedoraproject.org&gt;
>  > Sent: Wednesday, 31 October, 2012 6:35:14 AM
>  > Subject: Re: Anaconda is totally trashing the F18 schedule (was Re: f18:
>  how  to install into a LVM partitions (or
>  > RAID))
>  >
>  > On 30 October 2012 18:45, Adam Williamson <awilliam(a)redhat.com&gt;
>  > wrote:
>  > > so if were to try and switch back to oldui at
>  > > this point, we'd have to go through the whole process of adjusting
>  > > the
>  > > code for the changes to dracut again, quite apart from any other
>  > > issues.
>  >
>  > I don't understand how fixing up the old anaconda with the dracut
>  > changes would be so difficult. More than 140 man-hours? It's surely
>  > going to be a lot less work than getting anaconda to a point where it
>  > actually works with a consistent UI. Anaconda isn't the kind of thing
>  > we can fix with a zero day update, and surely it should have been
>  > developed in parallel with a release and then "switched on" just
>  > after
>  > branching rather than the situation we have now where there is major
>  > design and development work being done *so close* to where we should
>  > have everything locked down tight.
>  >
>  > I really don't see why the Anaconda team should be treated so
>  > differently from every other team. If we ship anything close to the
>  > Anaconda we've got now then F18 is going to get ripped apart by the
>  > reviewers.
>
>  Should we just skip F18? (like seriously).
>
>  Dave.
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  

Or just push the release by 1-2 months, So there is time to beat anaconda
into shape, going back to oldui will not be very productive, then we will
have the same problems in F19

Tim

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jóhann B. Guðmundsson]

On 10/30/2012 08:35 PM, Richard Hughes wrote:
>  I really don't see why the Anaconda team should be treated so
>  differently from every other team. If we ship anything close to the
>  Anaconda we've got now then F18 is going to get ripped apart by the
>  reviewers. 
My thoughts exactly...

JBG

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Marian Ganisin]

On Tue, Oct 30, 2012 at 11:45:02AM -0700, Adam Williamson wrote:
>  It's worth noting quite a lot of the early issues in this cycle
> -
>  particularly during Alpha - weren't actually much to do with newui; they
>  were more to do with changes in dracut which affected anaconda. oldui
>  wasn't fixed for that, so if were to try and switch back to oldui at
>  this point, we'd have to go through the whole process of adjusting the
>  code for the changes to dracut again, quite apart from any other issues. 
This temporary step-back can be reverted to pre-dracut era and it would work.

-- 
Regards,
Marian

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Panu Matilainen]

On 10/30/2012 08:45 PM, Adam Williamson wrote:
>  On Tue, 2012-10-30 at 19:32 +0100, Gianluca Sforna wrote:
>
> > I don't know if it's impossible to revert to the F17 anaconda at this
> > time, however it is clear that F18 is going to be the longest release
> > cycle we had in 9 years and somehow we need to avoid this in the
> > future.
>
>  It's not impossible, well, nothing is impossible, but at this point it's
>  almost certainly more of a disruption than just plowing on with newui.
>
>  It's worth noting quite a lot of the early issues in this cycle -
>  particularly during Alpha - weren't actually much to do with newui; they
>  were more to do with changes in dracut which affected anaconda. oldui
>  wasn't fixed for that, so if were to try and switch back to oldui at
>  this point, we'd have to go through the whole process of adjusting the
>  code for the changes to dracut again, quite apart from any other issues. 
Makes me wonder... were the anaconda developers and FESCo aware of the 
oncoming major changes to dracut? At least I failed to see anything 
obviously related to that on a quick skim through the f18 feature list.

	- Panu -

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Tomas Mraz]

On Wed, 2012-10-31 at 16:12 +0200, Panu Matilainen wrote: 
>  On 10/30/2012 08:45 PM, Adam Williamson wrote:
>  > On Tue, 2012-10-30 at 19:32 +0100, Gianluca Sforna wrote:
>  >
>  >> I don't know if it's impossible to revert to the F17 anaconda at this
>  >> time, however it is clear that F18 is going to be the longest release
>  >> cycle we had in 9 years and somehow we need to avoid this in the
>  >> future.
>  >
>  > It's not impossible, well, nothing is impossible, but at this point it's
>  > almost certainly more of a disruption than just plowing on with newui.
>  >
>  > It's worth noting quite a lot of the early issues in this cycle -
>  > particularly during Alpha - weren't actually much to do with newui; they
>  > were more to do with changes in dracut which affected anaconda. oldui
>  > wasn't fixed for that, so if were to try and switch back to oldui at
>  > this point, we'd have to go through the whole process of adjusting the
>  > code for the changes to dracut again, quite apart from any other issues.
>  
>  Makes me wonder... were the anaconda developers and FESCo aware of the 
>  oncoming major changes to dracut? At least I failed to see anything 
>  obviously related to that on a quick skim through the f18 feature list. 
Good point, unfortunately there is no _actively enforced_ requirement to
have a Fedora Feature for every major changes in core components of
Fedora that affect other components.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Matthew Miller]

On Wed, Oct 31, 2012 at 03:33:33PM +0100, Tomas Mraz wrote:
>  Good point, unfortunately there is no _actively enforced_ requirement
> to
>  have a Fedora Feature for every major changes in core components of
>  Fedora that affect other components. 
We at least need some better carrots here.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jesse Keating]

On 10/31/2012 07:12 AM, Panu Matilainen wrote:
>  Makes me wonder... were the anaconda developers and FESCo aware of
> the
>  oncoming major changes to dracut? At least I failed to see anything
>  obviously related to that on a quick skim through the f18 feature list. 
I think we had some idea that dracut would be switching to use systemd 
to run things, but what we didn't anticipate was the amount of fallout 
from that switch in our scripts.

This was compounded by focusing on building newUI on top of F17 content 
because it was stable, rather than fighting the never ending slog of 
rawhide issues, so we didn't notice all the subtle ways things were 
breaking in rawhide until it was late in the game.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Tom Lane]

Adam Williamson <awilliam(a)redhat.com&gt; writes:
>  ... Practically speaking, for F18,
>  though, I think we just need to soldier on with newUI and get it done as
>  best we can. Obviously slipping the schedule by a week again and again
>  in response to the latest fire isn't the best way to do things, but
>  stepping back and taking a wider view, a release that's a month or two
>  behind but with a reasonably solid new anaconda wouldn't be a disaster.  
My concern at this point is exactly that we're "slipping a week at a
time", rather than facing up to the *undeniable fact* that anaconda is
not close to being shippable.  If we don't have a workable contingency
plan, I think the best thing to do would be to start slipping a month at
a time.  And drop the beta-freeze restrictions, until we reach a point
where anaconda actually is beta quality.  Other people have work they
could usefully be getting done, except that they have to jump through
these beta-freeze hoops --- which not incidentally are slowing down
anaconda work too.  It's insane that we are wasting time debating
whether anaconda bugs are release blockers or beta blockers or only NTH,
when any honest evaluation would recognize that the whole thing hasn't
reached alpha quality yet, and *all* those bugs had better get fixed if
we don't want F18 to permanently damage the reputation of Fedora.

You can slip a month (or two) honestly, or you can fritter it away a
week at a time, and ensure that as much of that time is unproductive as
possible.  There is not a third option.  (Brooks' _Mythical_Man-Month_
has useful things to say about this sort of scheduling trap --- anybody
who hasn't read it should.)

			regards, tom lane

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jaroslav Reznik]

----- Original Message -----
>  Adam Williamson <awilliam(a)redhat.com&gt; writes:
>  > ... Practically speaking, for F18,
>  > though, I think we just need to soldier on with newUI and get it
>  > done as
>  > best we can. Obviously slipping the schedule by a week again and
>  > again
>  > in response to the latest fire isn't the best way to do things, but
>  > stepping back and taking a wider view, a release that's a month or
>  > two
>  > behind but with a reasonably solid new anaconda wouldn't be a
>  > disaster.
>  
>  My concern at this point is exactly that we're "slipping a week at a
>  time", rather than facing up to the *undeniable fact* that anaconda
>  is
>  not close to being shippable.  If we don't have a workable
>  contingency
>  plan, I think the best thing to do would be to start slipping a month
>  at
>  a time.  And drop the beta-freeze restrictions, until we reach a
>  point
>  where anaconda actually is beta quality.  Other people have work they
>  could usefully be getting done, except that they have to jump through
>  these beta-freeze hoops --- which not incidentally are slowing down
>  anaconda work too.   
That's actually what we did - we slipped *before* freezing for two weeks
and Beta was frozen as late as possible when we saw possibility of 
having fedup tool ready and we thought we are close to all blocker 
bugs solved. That's really the time when freeze makes sense to stabilize
the beast we want to release.

And a lot of goods stuff was done in Fedora 18 for Beta when it was
still possible to contribute, finish features etc.

Jaroslav

>  It's insane that we are wasting time debating
>  whether anaconda bugs are release blockers or beta blockers or only
>  NTH,
>  when any honest evaluation would recognize that the whole thing
>  hasn't
>  reached alpha quality yet, and *all* those bugs had better get fixed
>  if
>  we don't want F18 to permanently damage the reputation of Fedora.
>  
>  You can slip a month (or two) honestly, or you can fritter it away a
>  week at a time, and ensure that as much of that time is unproductive
>  as
>  possible.  There is not a third option.  (Brooks'
>  _Mythical_Man-Month_
>  has useful things to say about this sort of scheduling trap ---
>  anybody
>  who hasn't read it should.)
>  
>  			regards, tom lane
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jesse Keating]

On 10/31/2012 08:08 AM, Tom Lane wrote:
>  My concern at this point is exactly that we're "slipping a
> week at a
>  time", rather than facing up to the*undeniable fact*  that anaconda is
>  not close to being shippable.  If we don't have a workable contingency
>  plan, I think the best thing to do would be to start slipping a month at
>  a time.  And drop the beta-freeze restrictions, until we reach a point
>  where anaconda actually is beta quality.  Other people have work they
>  could usefully be getting done, except that they have to jump through
>  these beta-freeze hoops --- which not incidentally are slowing down
>  anaconda work too.  It's insane that we are wasting time debating
>  whether anaconda bugs are release blockers or beta blockers or only NTH,
>  when any honest evaluation would recognize that the whole thing hasn't
>  reached alpha quality yet, and*all*  those bugs had better get fixed if
>  we don't want F18 to permanently damage the reputation of Fedora.
>
>  You can slip a month (or two) honestly, or you can fritter it away a
>  week at a time, and ensure that as much of that time is unproductive as
>  possible.  There is not a third option.  (Brooks'_Mythical_Man-Month_
>  has useful things to say about this sort of scheduling trap --- anybody
>  who hasn't read it should.) 
Had I any say in the matter I would have strongly urged to not enter the 
beta freeze when we did.  I also think it's counter-productive to 
getting things in shape, and mostly just makes a lot of people hate 
Anaconda because it's keeping the freeze going.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Peter Jones]

On Wed, Oct 31, 2012 at 10:47:39AM -0700, Jesse Keating wrote:
>  On 10/31/2012 08:08 AM, Tom Lane wrote:
>  >My concern at this point is exactly that we're "slipping a week at a
>  >time", rather than facing up to the*undeniable fact*  that anaconda is
>  >not close to being shippable.  If we don't have a workable contingency
>  >plan, I think the best thing to do would be to start slipping a month at
>  >a time.  And drop the beta-freeze restrictions, until we reach a point
>  >where anaconda actually is beta quality.  Other people have work they
>  >could usefully be getting done, except that they have to jump through
>  >these beta-freeze hoops --- which not incidentally are slowing down
>  >anaconda work too.  It's insane that we are wasting time debating
>  >whether anaconda bugs are release blockers or beta blockers or only NTH,
>  >when any honest evaluation would recognize that the whole thing hasn't
>  >reached alpha quality yet, and*all*  those bugs had better get fixed if
>  >we don't want F18 to permanently damage the reputation of Fedora.
>  >
>  >You can slip a month (or two) honestly, or you can fritter it away a
>  >week at a time, and ensure that as much of that time is unproductive as
>  >possible.  There is not a third option.  (Brooks'_Mythical_Man-Month_
>  >has useful things to say about this sort of scheduling trap --- anybody
>  >who hasn't read it should.)
>  
>  Had I any say in the matter I would have strongly urged to not enter
>  the beta freeze when we did.  I also think it's counter-productive
>  to getting things in shape, and mostly just makes a lot of people
>  hate Anaconda because it's keeping the freeze going. 
Yeah, I don't think it's helped, either.  FWIW I voted against it, and
I voted against the schedule, because I don't think it allows us the
time to make large changes like this without the serious problems we're
seeing now.

-- 
        Peter

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jiri Eischmann]

Tom Lane píše v St 31. 10. 2012 v 11:08 -0400:
>  Adam Williamson <awilliam(a)redhat.com&gt; writes:
>  > ... Practically speaking, for F18,
>  > though, I think we just need to soldier on with newUI and get it done as
>  > best we can. Obviously slipping the schedule by a week again and again
>  > in response to the latest fire isn't the best way to do things, but
>  > stepping back and taking a wider view, a release that's a month or two
>  > behind but with a reasonably solid new anaconda wouldn't be a disaster. 
>  
>  My concern at this point is exactly that we're "slipping a week at a
>  time", rather than facing up to the *undeniable fact* that anaconda is
>  not close to being shippable.  If we don't have a workable contingency
>  plan, I think the best thing to do would be to start slipping a month at
>  a time. 
That would also definitely help from the PR perspective. Another and
another announcement of a slip by one week is starting to be ridiculous.
We should finally admit that we've screwed up this release and it would
take a significant delay to fix it.
I think the community will accept it better than a continuous stream of
one-week slips. It's also better for planning to know an honest
estimation of the final release of F18. People, who are not familiar
with the state of Anaconda, still believe that F18 will be released on
the Dec 11th and plan e.g. release parties accordingly.

Jiri

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Vratislav Podzimek]

On Tue, 2012-10-30 at 19:32 +0100, Gianluca Sforna wrote:
>  On Tue, Oct 30, 2012 at 7:12 PM, Adam Williamson
> <awilliam(a)redhat.com&gt; wrote:
>  > I'd recommend asking dcantrell, as he has some good points on this
>  > topic. I broadly agree with him that it might well be more or less
>  > impossible to smoothly handle a major rewrite of anaconda in our current
>  > development process. CCing to make sure he sees this.
>  
>  If you are saying that 6 months are a too short time for something
>  like this I think I can understand it. 
6 months are a too short time. And it was
less than 6 months. As can be
seen from the F18 release schedule [1], originally it was about 3 months
between the day F17 was released and the day new Anaconda was expected
to work (F18 Alpha release). We of course didn't start the work on May
29, but since there were significant changes in F17 too at least part of
the team had to fix bugs and make F17 releasable. Also Alpha is not
supposed to be 100% feature complete, but it seemed to me that not
everybody was taking this into account.

[1] http://fedoraproject.org/wiki/Releases/18/Schedule

-- 
Vratislav Podzimek

Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[drago01]

On Wed, Oct 31, 2012 at 10:27 AM, Vratislav Podzimek
<vpodzime(a)redhat.com&gt; wrote:
>  On Tue, 2012-10-30 at 19:32 +0100, Gianluca Sforna wrote:
> > On Tue, Oct 30, 2012 at 7:12 PM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
> > > I'd recommend asking dcantrell, as he has some good points on this
> > > topic. I broadly agree with him that it might well be more or less
> > > impossible to smoothly handle a major rewrite of anaconda in our current
> > > development process. CCing to make sure he sees this.
> >
> > If you are saying that 6 months are a too short time for something
> > like this I think I can understand it.
>  6 months are a too short time. And it was less than 6 months. As can be
>  seen from the F18 release schedule [1], originally it was about 3 months
>  between the day F17 was released and the day new Anaconda was expected
>  to work (F18 Alpha release). 
Sure in that case you shouldn't have propose it for F18 to begin with
but take your time and introduce it in F19. There is no need for this
rush.

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Vratislav Podzimek]

On Wed, 2012-10-31 at 10:33 +0100, drago01 wrote:
>  On Wed, Oct 31, 2012 at 10:27 AM, Vratislav Podzimek
>  <vpodzime(a)redhat.com&gt; wrote:
>  > On Tue, 2012-10-30 at 19:32 +0100, Gianluca Sforna wrote:
>  >> On Tue, Oct 30, 2012 at 7:12 PM, Adam Williamson <awilliam(a)redhat.com&gt;
> wrote:
>  >> > I'd recommend asking dcantrell, as he has some good points on this
>  >> > topic. I broadly agree with him that it might well be more or less
>  >> > impossible to smoothly handle a major rewrite of anaconda in our current
>  >> > development process. CCing to make sure he sees this.
>  >>
>  >> If you are saying that 6 months are a too short time for something
>  >> like this I think I can understand it.
>  > 6 months are a too short time. And it was less than 6 months. As can be
>  > seen from the F18 release schedule [1], originally it was about 3 months
>  > between the day F17 was released and the day new Anaconda was expected
>  > to work (F18 Alpha release).
>  
>  Sure in that case you shouldn't have propose it for F18 to begin with
>  but take your time and introduce it in F19. There is no need for this
>  rush. 
I don't see any advantage in that, because it would end up the same as
with F17 and F18. We don't do only changes we want to do and we come up
with. As many other packages change these changes have to be reflected
in Anaconda [1]. And that's the work that has to be done no matter we
want/need to focus on the redesign/rewrite or not.

[1] just to see what I'm talking about --
http://msivak.fedorapeople.org/anaconda-openhouse/#%285%29

-- 
Vratislav Podzimek

Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[drago01]

On Wed, Oct 31, 2012 at 10:45 AM, Vratislav Podzimek
<vpodzime(a)redhat.com&gt; wrote:
>  On Wed, 2012-10-31 at 10:33 +0100, drago01 wrote:
> > On Wed, Oct 31, 2012 at 10:27 AM, Vratislav Podzimek
> > <vpodzime(a)redhat.com&gt; wrote:
> > > On Tue, 2012-10-30 at 19:32 +0100, Gianluca Sforna wrote:
> > >> On Tue, Oct 30, 2012 at 7:12 PM, Adam Williamson <awilliam(a)redhat.com&gt;
> wrote:
> > >> > I'd recommend asking dcantrell, as he has some good points on this
> > >> > topic. I broadly agree with him that it might well be more or less
> > >> > impossible to smoothly handle a major rewrite of anaconda in our
> current
> > >> > development process. CCing to make sure he sees this.
> > >>
> > >> If you are saying that 6 months are a too short time for something
> > >> like this I think I can understand it.
> > > 6 months are a too short time. And it was less than 6 months. As can be
> > > seen from the F18 release schedule [1], originally it was about 3 months
> > > between the day F17 was released and the day new Anaconda was expected
> > > to work (F18 Alpha release).
> >
> > Sure in that case you shouldn't have propose it for F18 to begin with
> > but take your time and introduce it in F19. There is no need for this
> > rush.
>  I don't see any advantage in that, because it would end up the same as
>  with F17 and F18. We don't do only changes we want to do and we come up
>  with. As many other packages change these changes have to be reflected
>  in Anaconda [1]. And that's the work that has to be done no matter we
>  want/need to focus on the redesign/rewrite or not. 
Not buying that .... anaconda is not the only package that interacts
with others.

You can have a newui branch where you rewrite things (you could also
provide images for people to test) while having the working version in
a stable branch,
Once newui is feature complete it can be moved to stable.

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Gianluca Sforna]

On Wed, Oct 31, 2012 at 10:33 AM, drago01 <drago01(a)gmail.com&gt; wrote:
>  On Wed, Oct 31, 2012 at 10:27 AM, Vratislav Podzimek
>  <vpodzime(a)redhat.com&gt; wrote:
> > On Tue, 2012-10-30 at 19:32 +0100, Gianluca Sforna wrote:
> >> If you are saying that 6 months are a too short time for something
> >> like this I think I can understand it.
> > 6 months are a too short time. And it was less than 6 months. As can be
> > seen from the F18 release schedule [1], originally it was about 3 months
> > between the day F17 was released and the day new Anaconda was expected
> > to work (F18 Alpha release).
>
>  Sure in that case you shouldn't have propose it for F18 to begin with
>  but take your time and introduce it in F19. There is no need for this
>  rush. 
I'm not happy with the outcome either, but as a developer I can really
see how bringing forward the old ui (which would need changes even if
you do not add features there) and the new one at the same time would
be impractical and/or plain impossible to do.

However, I think anaconda developers knew that 6 months were too short
since the beginning. If this was abundantly clear to FESCo and other
interested parties, I think we could even accept a one time 9/12
months release cycle instead, without raising all this fuss for each
week of delay.

-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://identi.ca/giallu - http://twitter.com/giallu

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[drago01]

On Wed, Oct 31, 2012 at 10:50 AM, Gianluca Sforna <giallu(a)gmail.com&gt; wrote:
>  On Wed, Oct 31, 2012 at 10:33 AM, drago01 <drago01(a)gmail.com&gt;
> wrote:
> > On Wed, Oct 31, 2012 at 10:27 AM, Vratislav Podzimek
> > <vpodzime(a)redhat.com&gt; wrote:
> >> On Tue, 2012-10-30 at 19:32 +0100, Gianluca Sforna wrote:
> >>> If you are saying that 6 months are a too short time for something
> >>> like this I think I can understand it.
> >> 6 months are a too short time. And it was less than 6 months. As can be
> >> seen from the F18 release schedule [1], originally it was about 3 months
> >> between the day F17 was released and the day new Anaconda was expected
> >> to work (F18 Alpha release).
> >
> > Sure in that case you shouldn't have propose it for F18 to begin with
> > but take your time and introduce it in F19. There is no need for this
> > rush.
>
>  I'm not happy with the outcome either, but as a developer I can really
>  see how bringing forward the old ui (which would need changes even if
>  you do not add features there) and the new one at the same time would
>  be impractical and/or plain impossible to do. 
That's nonsense see the other mail. Would it be more work to maintain
two branches? Sure. Impossible? *NO*. Even if it delays newui to F20
so be it.
If we don't have the resources to do something we should not pretend
that we have (we are currently seeing where this leads to).

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Rahul Sundaram]

On 10/31/2012 03:33 PM, drago01 wrote:
>  That's nonsense see the other mail. Would it be more work to maintain
>  two branches? Sure. Impossible? *NO*. Even if it delays newui to F20
>  so be it.
>  If we don't have the resources to do something we should not pretend
>  that we have (we are currently seeing where this leads to). 
I agree with that.  It is clear that a lot of features have been part of 
that single feature proposal (new ui, new upgrade tool, no lvm by 
default etc) and we just didn't have enough time to do it all within 
this cycle.  Either the feature should have been pushed back to another 
release or two or more resources have should have been provided to the 
Anaconda team for this ambitious goal or the release should have been 
extended *deliberately* ahead of time.  No LVM by default also seems to 
have raised some questions around communication with the storage team.

I must note however that I am very much in favour of the new UI and any 
criticism directed towards the process doesn't change that at all.  The 
end result of this is that Fedora is suffering through several 
unexpected and unprecedented release delays.

Rahul

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Peter Robinson]

On Wed, Oct 31, 2012 at 11:34 AM, Rahul Sundaram <metherid(a)gmail.com&gt; wrote:
>  On 10/31/2012 03:33 PM, drago01 wrote:
> >
> >
> > That's nonsense see the other mail. Would it be more work to maintain
> > two branches? Sure. Impossible? *NO*. Even if it delays newui to F20
> > so be it.
> > If we don't have the resources to do something we should not pretend
> > that we have (we are currently seeing where this leads to).
>
>
>  I agree with that.  It is clear that a lot of features have been part of
>  that single feature proposal (new ui, new upgrade tool, no lvm by default
>  etc) and we just didn't have enough time to do it all within this cycle.
>  Either the feature should have been pushed back to another release or two or
>  more resources have should have been provided to the Anaconda team for this
>  ambitious goal or the release should have been extended *deliberately* ahead
>  of time.  No LVM by default also seems to have raised some questions around
>  communication with the storage team. 
It's already been pushed back once, the first iteration of newui was
attempted to land in F-17 and was pushed back to F-18 if my memory
serves me correctly. So I think we need to land it now and deal with
the fall out then move on. The one thing that concerns me is the lack
of communications about LVM with the storage team as it makes me
wonder what else has been missed/assumed.

>  I must note however that I am very much in favour of the new UI and
> any
>  criticism directed towards the process doesn't change that at all.  The end
>  result of this is that Fedora is suffering through several unexpected and
>  unprecedented release delays. 
Me too! I think it's long over due and with luck once it's there it
should be more modular and we, with luck, or at least I hope, will
have an anaconda that is easier to deal with and extend/change moving
forward.

Peter

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jóhann B. Guðmundsson]

On 10/31/2012 11:42 AM, Peter Robinson wrote:
>  It's already been pushed back once, the first iteration of newui
> was
>  attempted to land in F-17 and was pushed back to F-18 if my memory
>  serves me correctly. 
Dont think it did

>    So I think we need to land it now and deal with
>  the fall out then move on. The one thing that concerns me is the lack
>  of communications about LVM with the storage team as it makes me
>  wonder what else has been missed/assumed. 
Lack of communication lol those RH storage developers could have.

A) subscribed to the Anaconda developers list to monitor changes 
relevant to their setup as anyone else affected by any upstream changes 
( this got mentioned in August )
B) bothered to do a simple test install of alpha they would have noticed 
that the installer did not default to LVM partition layout by default 
and had that discussion then and there...

So the Storage team within Red Hat they themselves expecting the 
Anaconda team to be running around notify them or FESCO for that matter 
is just utter and total bullocks and their little lvm no being turned on 
by default pails in comparison with what we ( QA Community )  
"discovered" where missing in the installer early on...

There is a lot of things FESCO and Anaconda developers can be blamed for 
and those two groups will have do a hard look into how they are doing 
things but lvm on or off by default and those Red Hat developers not 
knowing about it falls entirely into those individuals own laps.

JBG

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jared K. Smith]

On Wed, Oct 31, 2012 at 7:54 AM, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com&gt; wrote:
>  On 10/31/2012 11:42 AM, Peter Robinson wrote:
> >
> > It's already been pushed back once, the first iteration of newui was
> > attempted to land in F-17 and was pushed back to F-18 if my memory
> > serves me correctly.
>
>
>  Dont think it did 
It was proposed to land in F17, and it was discussed quite a bit at
FUDCon in Blacksburg (where almost all of the anaconda team was
assembled), and it was decided that pushing it in the F17 wasn't
feasible, given the amount of work it entails.

--
Jared Smith

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jóhann B. Guðmundsson]

On 10/31/2012 12:22 PM, Jared K. Smith wrote:
>  It was proposed to land in F17, and it was discussed quite a bit at
>  FUDCon in Blacksburg (where almost all of the anaconda team was
>  assembled), and it was decided that pushing it in the F17 wasn't
>  feasible, given the amount of work it entails. 
And those that are aware of that ( and any other decision making ) are 
the only ones who can afford or otherwise attend fudcon...

JBG

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Olav Vitters]

On Wed, Oct 31, 2012 at 11:54:22AM +0000, "Jóhann B. Guðmundsson" wrote:
>  Lack of communication lol those RH storage developers could have.
>  
>  A) subscribed to the Anaconda developers list to monitor changes
>  relevant to their setup as anyone else affected by any upstream
>  changes ( this got mentioned in August )
>  B) bothered to do a simple test install of alpha they would have
>  noticed that the installer did not default to LVM partition layout
>  by default and had that discussion then and there... 
Not trying to lay blame, but if something major changes, it is nice to
almost over communicate and ensure everyone is really aware of the
impact.

E.g. this example: maybe everything worked the same for the storage team
for all Fedora release cycles. Or at least that any change was directed
by that team. If a major change happens, I'd be happy if everyone
figures that out on their own, but think it is better if you don't
expect that.

Quite easy to miss a few emails or not properly read a few for instance.
I sometimes completely forget about something major.

As said, not trying to lay blame, just giving suggestions / different
perspective.
-- 
Regards,
Olav

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Ric Wheeler]

On 10/31/2012 07:54 AM, "Jóhann B. Guðmundsson" wrote:
>  On 10/31/2012 11:42 AM, Peter Robinson wrote:
> > It's already been pushed back once, the first iteration of newui was
> > attempted to land in F-17 and was pushed back to F-18 if my memory
> > serves me correctly.
>
>  Dont think it did
>
> >   So I think we need to land it now and deal with
> > the fall out then move on. The one thing that concerns me is the lack
> > of communications about LVM with the storage team as it makes me
> > wonder what else has been missed/assumed.
>
>  Lack of communication lol those RH storage developers could have.
>
>  A) subscribed to the Anaconda developers list to monitor changes relevant to 
>  their setup as anyone else affected by any upstream changes ( this got 
>  mentioned in August )
>  B) bothered to do a simple test install of alpha they would have noticed that 
>  the installer did not default to LVM partition layout by default and had that 
>  discussion then and there...
>
>  So the Storage team within Red Hat they themselves expecting the Anaconda team 
>  to be running around notify them or FESCO for that matter is just utter and 
>  total bullocks and their little lvm no being turned on by default pails in 
>  comparison with what we ( QA Community )  "discovered" where missing in the 
>  installer early on...
>
>  There is a lot of things FESCO and Anaconda developers can be blamed for and 
>  those two groups will have do a hard look into how they are doing things but 
>  lvm on or off by default and those Red Hat developers not knowing about it 
>  falls entirely into those individuals own laps.
>
>  JBG 
You continue to miss the point by trying to cast dispersions on the storage people.

The file system and storage developers are subscribed to the our domain specific 
lists and to fedora-devel where we do our work. We did review early versions of 
the UI redesign, but no mention of of flipping LVM off by default was raised.

Do the anaconda people subscribe to device mapper lists and file system lists?  
I don't see that as a scalable or useful way to spend your time to require every 
developer to subscribe to every other teams internal lists.

When work impacts another team - especially work that disables another team's 
contributions and features - it is reasonable to assume that they should be 
pro-actively reached out to.

As well, when we cut modern features from Fedora, that should be reviewed 
explicitly and stated as a FEATURE page, not part of  a UI redesign.  Or at 
least posted to fedora-devel with a "heads up".

They really are orthogonal issues.

As I mentioned elsewhere, I personally organized a community day at plumbers 
which pulled in members of the anaconda team, others working on storage 
configuration and device mapper and file system developers.

The teams do talk and work together, we clearly need to improve here on process.

Regards,

Ric

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Josef Bacik]

On Wed, Oct 31, 2012 at 7:54 AM, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com&gt; wrote:
>  On 10/31/2012 11:42 AM, Peter Robinson wrote:
> >
> > It's already been pushed back once, the first iteration of newui was
> > attempted to land in F-17 and was pushed back to F-18 if my memory
> > serves me correctly.
>
>
>  Dont think it did
>
>
> >   So I think we need to land it now and deal with
> > the fall out then move on. The one thing that concerns me is the lack
> > of communications about LVM with the storage team as it makes me
> > wonder what else has been missed/assumed.
>
>
>  Lack of communication lol those RH storage developers could have.
>
>  A) subscribed to the Anaconda developers list to monitor changes relevant to
>  their setup as anyone else affected by any upstream changes ( this got
>  mentioned in August )
>  B) bothered to do a simple test install of alpha they would have noticed
>  that the installer did not default to LVM partition layout by default and
>  had that discussion then and there...
>
>  So the Storage team within Red Hat they themselves expecting the Anaconda
>  team to be running around notify them or FESCO for that matter is just utter
>  and total bullocks and their little lvm no being turned on by default pails
>  in comparison with what we ( QA Community )  "discovered" where missing in
>  the installer early on...
>  
You know what the storage team does right?  I can only speak for
myself really, but 26 hours out of the day my head is buried in btrfs.
 Sure I'm subscribed to anaconda devel and fedora devel, which means I
search "btrfs" in my fedora-devel and anaconda folders once a week to
see if somebody is complaining.  We just had a big get together in
August with the storage developers and anaconda people and I don't
remember hearing anything about this.  The anaconda guys are the same
way, they focus on the installer and don't look up unless they have
to.  So when I need something btrfs-y done in Anaconda I go find Dave
or somebody and tell them what I need and we get it worked out
together.  The same thing should be done from the anaconda side when
it comes to changing the basic behavior of storage in Fedora.  Red Hat
employs the top storage developers in the world, why would they not
take advantage of that expertise and experience?  So no it's not
"utter and total bullocks" to expect some sort of heads up when it
comes to storage related changes in anaconda, we're all on the same
team and why would you not talk to each other?  We should be working
to create a well integrated solution for our users that provides the
best possible experience, and the only way we get that done is if we
all work together.  Thanks,

Josef

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jóhann B. Guðmundsson]

On 10/31/2012 02:13 PM, Josef Bacik wrote:
>  You know what the storage team does right? 
As far as I know there only exist individual developers working on 
storage be it filesystem or direct storage solution.

You for btrfs and Eric for ext

But I'm not aware of any specific "storage team" or and storage 
community within the distribution that acts as one.

Can you point me to your mailing list which I assume discussion or an 
announcement would go to ?

JBG

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Ric Wheeler]

On 10/31/2012 10:33 AM, "Jóhann B. Guðmundsson" wrote:
>  On 10/31/2012 02:13 PM, Josef Bacik wrote:
> > You know what the storage team does right?
>
>  As far as I know there only exist individual developers working on storage be 
>  it filesystem or direct storage solution.
>
>  You for btrfs and Eric for ext
>
>  But I'm not aware of any specific "storage team" or and storage community 
>  within the distribution that acts as one.
>
>  Can you point me to your mailing list which I assume discussion or an 
>  announcement would go to ?
>
>  JBG 
A good place to see a summary of the broad community work is the annual Linux 
Storage and File System Workshop (LSF). You can google for the recent notes, 
usually well covered on LWN.net.

The most general list and lowest traffic is: linux-fsdevel(a)vger.kernel.org

MD team list is: linux-raid(a)vger.kernel.org

The device mapper team list is: dm-devel(a)redhat.com

Each local file system has its list:

xfs(a)oss.sgi.com
linux-btrfs(a)vger.kernel.org
linux-nfs(a)vger.kernel.org
linux-ext4(a)vger.kernel.org

SCSI issues are:
linux-scsi(a)vger.kernel.org

S-ATA issues are:
linux-ide(a)vger.kernel.org

Ric

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jóhann B. Guðmundsson]

On 10/31/2012 02:57 PM, Ric Wheeler wrote:
>  A good place to see a summary of the broad community work is the 
>  annual Linux Storage and File System Workshop (LSF). You can google 
>  for the recent notes, usually well covered on LWN.net.
>
>  The most general list and lowest traffic is: 
>  linux-fsdevel(a)vger.kernel.org
>
>  MD team list is: linux-raid(a)vger.kernel.org
>
>  The device mapper team list is: dm-devel(a)redhat.com
>
>  Each local file system has its list:
>
>  xfs(a)oss.sgi.com
>  linux-btrfs(a)vger.kernel.org
>  linux-nfs(a)vger.kernel.org
>  linux-ext4(a)vger.kernel.org
>
>  SCSI issues are:
>  linux-scsi(a)vger.kernel.org
>
>  S-ATA issues are:
>  linux-ide(a)vger.kernel.org 
These are all upstream mailing list none specific to the distribution so 
perhaps it's time for you guys within the Fedora distribution to unite 
under such list so other developers, user and alike can contact you and 
other interested parties that might be subscribed to that list with 
heads up for changes like the one that Anaconda made...

JBG

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Eric Sandeen]

On 10/31/12 10:20 AM, "Jóhann B. Guðmundsson" wrote:
>  On 10/31/2012 02:57 PM, Ric Wheeler wrote:
> > A good place to see a summary of the broad community work is the annual Linux Storage
> and File System Workshop (LSF). You can google for the recent notes, usually well covered
> on LWN.net.
> >
> > The most general list and lowest traffic is: linux-fsdevel(a)vger.kernel.org
> >
> > MD team list is: linux-raid(a)vger.kernel.org
> >
> > The device mapper team list is: dm-devel(a)redhat.com
> >
> > Each local file system has its list:
> >
> > xfs(a)oss.sgi.com
> > linux-btrfs(a)vger.kernel.org
> > linux-nfs(a)vger.kernel.org
> > linux-ext4(a)vger.kernel.org
> >
> > SCSI issues are:
> > linux-scsi(a)vger.kernel.org
> >
> > S-ATA issues are:
> > linux-ide(a)vger.kernel.org
>  
>  These are all upstream mailing list none specific to the distribution
>  so perhaps it's time for you guys within the Fedora distribution to
>  unite under such list so other developers, user and alike can contact
>  you and other interested parties that might be subscribed to that
>  list with heads up for changes like the one that Anaconda made... 
It might be useful to have a storage list for Fedora, but I'm on the
fence.

I'm on fedora-devel, fedora-kernel, and the anaconda lists already.

I'm in #fedora-devel, #fedora-kernel, and #anaconda on IRC too.

It's not clear to me that the root cause for low communication on this
change was "too few lists."  

Now that I've actively searched for it, I do find, deep in a thread
about "partitioning expectations for F18," a tester who was surprised
by the change back in August.  The surprise makes me think it probably
wasn't well communicated to anyone, originally.  For example, not
communicated to the fedora test lists, even though they existed.
(I'm not on _that_ list, so if I'm wrong, please forgive me).

I also found your "Does this mean we can ( finally ) disable lvm and
related services by default" comment in that thread, which gives me a
little better context for your passion on this topic.  ;)

-Eric

>  JBG
>

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Ric Wheeler]

On 10/31/2012 11:39 AM, Eric Sandeen wrote:
>  On 10/31/12 10:20 AM, "Jóhann B. Guðmundsson" wrote:
> > On 10/31/2012 02:57 PM, Ric Wheeler wrote:
> >> A good place to see a summary of the broad community work is the annual Linux
> Storage and File System Workshop (LSF). You can google for the recent notes, usually well
> covered on LWN.net.
> >>
> >> The most general list and lowest traffic is: linux-fsdevel(a)vger.kernel.org
> >>
> >> MD team list is: linux-raid(a)vger.kernel.org
> >>
> >> The device mapper team list is: dm-devel(a)redhat.com
> >>
> >> Each local file system has its list:
> >>
> >> xfs(a)oss.sgi.com
> >> linux-btrfs(a)vger.kernel.org
> >> linux-nfs(a)vger.kernel.org
> >> linux-ext4(a)vger.kernel.org
> >>
> >> SCSI issues are:
> >> linux-scsi(a)vger.kernel.org
> >>
> >> S-ATA issues are:
> >> linux-ide(a)vger.kernel.org
> > These are all upstream mailing list none specific to the distribution
> > so perhaps it's time for you guys within the Fedora distribution to
> > unite under such list so other developers, user and alike can contact
> > you and other interested parties that might be subscribed to that
> > list with heads up for changes like the one that Anaconda made...
>  It might be useful to have a storage list for Fedora, but I'm on the
>  fence.
>
>  I'm on fedora-devel, fedora-kernel, and the anaconda lists already.
>
>  I'm in #fedora-devel, #fedora-kernel, and #anaconda on IRC too.
>
>  It's not clear to me that the root cause for low communication on this
>  change was "too few lists."
>
>  Now that I've actively searched for it, I do find, deep in a thread
>  about "partitioning expectations for F18," a tester who was surprised
>  by the change back in August.  The surprise makes me think it probably
>  wasn't well communicated to anyone, originally.  For example, not
>  communicated to the fedora test lists, even though they existed.
>  (I'm not on _that_ list, so if I'm wrong, please forgive me).
>
>  I also found your "Does this mean we can ( finally ) disable lvm and
>  related services by default" comment in that thread, which gives me a
>  little better context for your passion on this topic.  ;)
>
>  -Eric
>  
Maybe having a fedora specific file & storage, low traffic list would be a great 
way to get focused, cross team exchanges.

I certainly have enough email to drown in, but this could be actually a positive 
thing....

ric

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jóhann B. Guðmundsson]

On 10/31/2012 03:39 PM, Eric Sandeen wrote:
>  It might be useful to have a storage list for Fedora, but I'm on
> the
>  fence.
>
>  I'm on fedora-devel, fedora-kernel, and the anaconda lists already.
>
>  I'm in #fedora-devel, #fedora-kernel, and #anaconda on IRC too.
>
>  It's not clear to me that the root cause for low communication on this
>  change was "too few lists."
>
>  Now that I've actively searched for it, I do find, deep in a thread
>  about "partitioning expectations for F18," a tester who was surprised
>  by the change back in August.  The surprise makes me think it probably
>  wasn't well communicated to anyone, originally.  For example, not
>  communicated to the fedora test lists, even though they existed.
>  (I'm not on_that_  list, so if I'm wrong, please forgive me). 
Oh there where quite few other changes they forgot to give heads up 
about that that...

>  I also found your "Does this mean we can ( finally ) disable lvm
> and
>  related services by default" comment in that thread, which gives me a
>  little better context for your passion on this topic.;) 
That's not news I have been for ext4 only partition layout for several 
years to me delivers worse out of the box experience to novice end users.

In F17 the installer offered you to hash/unhash lvm as the default 
partition layout which rendered this argument moot,

In the newUI they chose to remove that ability from the end users hence 
back to square one with that debate...

JBG

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Adam Williamson]

On Wed, 2012-10-31 at 10:39 -0500, Eric Sandeen wrote:

>  wasn't well communicated to anyone, originally.  For example,
> not
>  communicated to the fedora test lists, even though they existed.
>  (I'm not on _that_ list, so if I'm wrong, please forgive me). 
In practice, QA was well aware of the change, as it's pretty obvious
when you're doing validation testing. I know I knew about it right from
Alpha validation, and I believe other testers did too. However, we
weren't aware that _you_ weren't aware, IYSWIM. :)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Eric Sandeen]

On 10/31/12 2:59 PM, Adam Williamson wrote:
>  On Wed, 2012-10-31 at 10:39 -0500, Eric Sandeen wrote:
>  
> > wasn't well communicated to anyone, originally.  For example, not
> > communicated to the fedora test lists, even though they existed.
> > (I'm not on _that_ list, so if I'm wrong, please forgive me).
>  
>  In practice, QA was well aware of the change, as it's pretty obvious
>  when you're doing validation testing. I know I knew about it right from
>  Alpha validation, and I believe other testers did too. However, we
>  weren't aware that _you_ weren't aware, IYSWIM. :) 
Just to keep flogging this dead horse: You became aware because you
tested it, right?  Not because it was announced anywhere.

-Eric

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Adam Williamson]

On Wed, 2012-10-31 at 15:09 -0500, Eric Sandeen wrote:
>  On 10/31/12 2:59 PM, Adam Williamson wrote:
>  > On Wed, 2012-10-31 at 10:39 -0500, Eric Sandeen wrote:
>  > 
>  >> wasn't well communicated to anyone, originally.  For example, not
>  >> communicated to the fedora test lists, even though they existed.
>  >> (I'm not on _that_ list, so if I'm wrong, please forgive me).
>  > 
>  > In practice, QA was well aware of the change, as it's pretty obvious
>  > when you're doing validation testing. I know I knew about it right from
>  > Alpha validation, and I believe other testers did too. However, we
>  > weren't aware that _you_ weren't aware, IYSWIM. :)
>  
>  Just to keep flogging this dead horse: You became aware because you
>  tested it, right?  Not because it was announced anywhere. 
I honestly don't recall. The release validation process is way, way,
way, way too busy and chaotic for me to remember such a thing reliably.
Speaking personally again. Others in QA may have better memories.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jóhann B. Guðmundsson]

On 10/31/2012 08:09 PM, Eric Sandeen wrote:
>  Just to keep flogging this dead horse: You became aware because you
>  tested it, right?  Not because it was announced anywhere. 
Yes and Adam forgot to add to his list here...

* The change to only allowing one desktop environment to be installed
interactively
* The change to not requiring a root password to be set
* The change to raw ext4 rather than LVM as the default partition scheme
* The fact that anaconda would no longer handle upgrades but an entirely
new tool would be written for this

The plan to remove rescue and text/serial install which we "found out" 
and "convinced" the Anaconda developers to bring back which they did...

JBG

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jesse Keating]

On 10/31/2012 01:53 PM, "Jóhann B. Guðmundsson" wrote:
>  The plan to remove rescue and text/serial install which we "found out"
>  and "convinced" the Anaconda developers to bring back which they did... 
That's not accurate in the least.

text/serial was lost when the switch to newUI was made.  They just 
wouldn't work anymore.  The original plan, the one that the anaconda 
team committed to, was having them back in place for F19.  I joined the 
team and Martin and I got lucky in having enough time to quickly bang 
out a minimalist text interface, which I spent a little more time in to 
make sure it worked well over serial.  We happened to get it done well 
ahead of time, but we never committed to having it at all for F18.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Chris Adams]

Once upon a time, "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt; said:
>  The plan to remove rescue and text/serial install which we
> "found out" 
>  and "convinced" the Anaconda developers to bring back which they did... 
That was in the initial feature page (go see the link posted here
earlier today).
-- 
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.

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Eric Sandeen]

On 10/31/12 9:13 AM, Josef Bacik wrote:
>  On Wed, Oct 31, 2012 at 7:54 AM, "Jóhann B. Guðmundsson"
>  <johannbg(a)gmail.com&gt; wrote:
> > On 10/31/2012 11:42 AM, Peter Robinson wrote:
> >>
> >> It's already been pushed back once, the first iteration of newui was
> >> attempted to land in F-17 and was pushed back to F-18 if my memory
> >> serves me correctly.
> >
> >
> > Dont think it did
> >
> >
> >>   So I think we need to land it now and deal with
> >> the fall out then move on. The one thing that concerns me is the lack
> >> of communications about LVM with the storage team as it makes me
> >> wonder what else has been missed/assumed.
> >
> >
> > Lack of communication lol those RH storage developers could have.
> >
> > A) subscribed to the Anaconda developers list to monitor changes relevant to
> > their setup as anyone else affected by any upstream changes ( this got
> > mentioned in August )
> > B) bothered to do a simple test install of alpha they would have noticed
> > that the installer did not default to LVM partition layout by default and
> > had that discussion then and there...
> >
> > So the Storage team within Red Hat they themselves expecting the Anaconda
> > team to be running around notify them or FESCO for that matter is just utter
> > and total bullocks and their little lvm no being turned on by default pails
> > in comparison with what we ( QA Community )  "discovered" where missing in
> > the installer early on...
> >
>  
>  You know what the storage team does right?  I can only speak for
>  myself really, but 26 hours out of the day my head is buried in btrfs.
>   Sure I'm subscribed to anaconda devel and fedora devel, which means I
>  search "btrfs" in my fedora-devel and anaconda folders once a week to
>  see if somebody is complaining.  We just had a big get together in
>  August with the storage developers and anaconda people and I don't
>  remember hearing anything about this.  The anaconda guys are the same
>  way, they focus on the installer and don't look up unless they have
>  to.  So when I need something btrfs-y done in Anaconda I go find Dave
>  or somebody and tell them what I need and we get it worked out
>  together.  The same thing should be done from the anaconda side when
>  it comes to changing the basic behavior of storage in Fedora.  Red Hat
>  employs the top storage developers in the world, why would they not
>  take advantage of that expertise and experience?  So no it's not
>  "utter and total bullocks" to expect some sort of heads up when it
>  comes to storage related changes in anaconda, we're all on the same
>  team and why would you not talk to each other?  We should be working
>  to create a well integrated solution for our users that provides the
>  best possible experience, and the only way we get that done is if we
>  all work together.  Thanks, 
Preach it, brother. ;)

Josef is right, we have rather full days making sure all your data is safe
& fast, and keeping an eye out for sudden changes in installer behavior
just isn't always on our radar.  I haven't test-installed F18, personally;
I've been busy chasing upstream ext4 metadata corruption bugs and the like.

I trusted the feature process to publicize and vet any significant installer
changes in the fs/storage realm, TBH.

-Eric

>  Josef
>

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jóhann B. Guðmundsson]

On 10/31/2012 02:34 PM, Eric Sandeen wrote:
> > >You know what the storage team does right?  I can only speak
> for
> > >myself really, but 26 hours out of the day my head is buried in btrfs.
> > >  Sure I'm subscribed to anaconda devel and fedora devel, which means I
> > >search "btrfs" in my fedora-devel and anaconda folders once a week to
> > >see if somebody is complaining.  We just had a big get together in
> > >August with the storage developers and anaconda people and I don't
> > >remember hearing anything about this.  The anaconda guys are the same
> > >way, they focus on the installer and don't look up unless they have
> > >to.  So when I need something btrfs-y done in Anaconda I go find Dave
> > >or somebody and tell them what I need and we get it worked out
> > >together.  The same thing should be done from the anaconda side when
> > >it comes to changing the basic behavior of storage in Fedora.  Red Hat
> > >employs the top storage developers in the world, why would they not
> > >take advantage of that expertise and experience?  So no it's not
> > >"utter and total bullocks" to expect some sort of heads up when it
> > >comes to storage related changes in anaconda, we're all on the same
> > >team and why would you not talk to each other?  We should be working
> > >to create a well integrated solution for our users that provides the
> > >best possible experience, and the only way we get that done is if we
> > >all work together.  Thanks,
>  Preach it, brother.;)
>
>  Josef is right, we have rather full days making sure all your data is safe
>  & fast, and keeping an eye out for sudden changes in installer behavior
>  just isn't always on our radar.  I haven't test-installed F18, personally;
>  I've been busy chasing upstream ext4 metadata corruption bugs and the like.
>
>  I trusted the feature process to publicize and vet any significant installer
>  changes in the fs/storage realm, TBH. 
Yeah well I'm not so sure how you can actually expect that of the 
feature process given how utterly broken that is?

For the first you are not obligated to participate in the feature 
process and even if you did what does the process categorize as an 
actual feature?

And I propose that you start lowering your expectations since there is a 
proposal floating with  FESCo where the main think is that they want to 
avoid voting on all features but just decide in details on the bigger 
scope/escalated ones to FESCo. The rest will be acked just by announcing 
them (and again - anyone can escalate it to FESCo)...

JBG

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Josh Boyer]

On Wed, Oct 31, 2012 at 10:50 AM, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com&gt; wrote:
>  Yeah well I'm not so sure how you can actually expect that of the
> feature
>  process given how utterly broken that is?
>
>  For the first you are not obligated to participate in the feature process
>  and even if you did what does the process categorize as an actual feature?
>
>  And I propose that you start lowering your expectations since there is a
>  proposal floating with  FESCo where the main think is that they want to
>  avoid voting on all features but just decide in details on the bigger
>  scope/escalated ones to FESCo. The rest will be acked just by announcing
>  them (and again - anyone can escalate it to FESCo)... 
I have no idea where you're getting this information, but I haven't seen
anyone suggest anything like that.  There is a desire to make the Feature
process actually worthwhile, but it has nothing to do with blindly acking
features.

josh

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jaroslav Reznik]

----- Original Message -----
>  On Wed, Oct 31, 2012 at 10:50 AM, "Jóhann B. Guðmundsson"
>  <johannbg(a)gmail.com&gt; wrote:
>  > Yeah well I'm not so sure how you can actually expect that of the
>  > feature
>  > process given how utterly broken that is?
>  >
>  > For the first you are not obligated to participate in the feature
>  > process
>  > and even if you did what does the process categorize as an actual
>  > feature?
>  >
>  > And I propose that you start lowering your expectations since there
>  > is a
>  > proposal floating with  FESCo where the main think is that they
>  > want to
>  > avoid voting on all features but just decide in details on the
>  > bigger
>  > scope/escalated ones to FESCo. The rest will be acked just by
>  > announcing
>  > them (and again - anyone can escalate it to FESCo)...
>  
>  I have no idea where you're getting this information, but I haven't
>  seen
>  anyone suggest anything like that.  There is a desire to make the
>  Feature
>  process actually worthwhile, but it has nothing to do with blindly
>  acking
>  features. 
It's one think that was an outcome of me talking to a few FESCo
members - so it's definitely not FESCo decision and I did not talk
to everyone. I should really start on the actual proposal (and I 
wanted to come with a real one, not just talking) but - the main 
idea was to free FESCo hands by not having to approve every single
feature and have a time to spent more on the system wide/escalated
ones. Also the announcement is a part of better visibility of 
proposed features as this seems does not work well (and yeah, there's
barrier as before the feature is approved by FESCo, it's just one
of a huge list of incompleted ones). 

Although this does not solve a problem that some really big changes
does not go through the process at all as it's not mandatory (or
we do not have a way how to actually enforce it).

Jaroslav

>  josh
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jóhann B. Guðmundsson]

On 10/31/2012 02:56 PM, Josh Boyer wrote:
>  I have no idea where you're getting this information, but I
> haven't seen
>  anyone suggest anything like that.  There is a desire to make the Feature
>  process actually worthwhile, but it has nothing to do with blindly acking
>  features. 
No arguments from me making the feature process worth while...

JBG

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jaroslav Reznik]

----- Original Message -----
>  On 10/31/12 9:13 AM, Josef Bacik wrote:
>  > On Wed, Oct 31, 2012 at 7:54 AM, "Jóhann B. Guðmundsson"
>  > <johannbg(a)gmail.com&gt; wrote:
>  >> On 10/31/2012 11:42 AM, Peter Robinson wrote:
>  >>>
>  >>> It's already been pushed back once, the first iteration of newui
>  >>> was
>  >>> attempted to land in F-17 and was pushed back to F-18 if my
>  >>> memory
>  >>> serves me correctly.
>  >>
>  >>
>  >> Dont think it did
>  >>
>  >>
>  >>>   So I think we need to land it now and deal with
>  >>> the fall out then move on. The one thing that concerns me is the
>  >>> lack
>  >>> of communications about LVM with the storage team as it makes me
>  >>> wonder what else has been missed/assumed.
>  >>
>  >>
>  >> Lack of communication lol those RH storage developers could have.
>  >>
>  >> A) subscribed to the Anaconda developers list to monitor changes
>  >> relevant to
>  >> their setup as anyone else affected by any upstream changes ( this
>  >> got
>  >> mentioned in August )
>  >> B) bothered to do a simple test install of alpha they would have
>  >> noticed
>  >> that the installer did not default to LVM partition layout by
>  >> default and
>  >> had that discussion then and there...
>  >>
>  >> So the Storage team within Red Hat they themselves expecting the
>  >> Anaconda
>  >> team to be running around notify them or FESCO for that matter is
>  >> just utter
>  >> and total bullocks and their little lvm no being turned on by
>  >> default pails
>  >> in comparison with what we ( QA Community )  "discovered" where
>  >> missing in
>  >> the installer early on...
>  >>
>  > 
>  > You know what the storage team does right?  I can only speak for
>  > myself really, but 26 hours out of the day my head is buried in
>  > btrfs.
>  >  Sure I'm subscribed to anaconda devel and fedora devel, which
>  >  means I
>  > search "btrfs" in my fedora-devel and anaconda folders once a week
>  > to
>  > see if somebody is complaining.  We just had a big get together in
>  > August with the storage developers and anaconda people and I don't
>  > remember hearing anything about this.  The anaconda guys are the
>  > same
>  > way, they focus on the installer and don't look up unless they have
>  > to.  So when I need something btrfs-y done in Anaconda I go find
>  > Dave
>  > or somebody and tell them what I need and we get it worked out
>  > together.  The same thing should be done from the anaconda side
>  > when
>  > it comes to changing the basic behavior of storage in Fedora.  Red
>  > Hat
>  > employs the top storage developers in the world, why would they not
>  > take advantage of that expertise and experience?  So no it's not
>  > "utter and total bullocks" to expect some sort of heads up when it
>  > comes to storage related changes in anaconda, we're all on the same
>  > team and why would you not talk to each other?  We should be
>  > working
>  > to create a well integrated solution for our users that provides
>  > the
>  > best possible experience, and the only way we get that done is if
>  > we
>  > all work together.  Thanks,
>  
>  Preach it, brother. ;)
>  
>  Josef is right, we have rather full days making sure all your data is
>  safe
>  & fast, and keeping an eye out for sudden changes in installer
>  behavior
>  just isn't always on our radar.  I haven't test-installed F18,
>  personally;
>  I've been busy chasing upstream ext4 metadata corruption bugs and the
>  like.
>  
>  I trusted the feature process to publicize and vet any significant
>  installer
>  changes in the fs/storage realm, TBH. 
The feature process is as good as feature pages itself. And it's same
with trust. We can only trust feature owners to provide all relevant
information (and same applies for submitting features). If you take a look
on New Installer UI feature page, it's clear, talks about a new UI, 
it's there. It matches the description. Does it talk about feature parity
with the old one - no, and this could be done better next time. Same
for contingency plan... This feature landed in an unfortunate time - during
the Fedora PGMs transition - Robyn was already busy with FPL job, there 
was no FPGM  that time and that means nearly no progress tracking.

Jaroslav 


>  -Eric
>  
>  > Josef
>  > 
>  
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Adam Williamson]

On Wed, 2012-10-31 at 10:58 -0400, Jaroslav Reznik wrote:

>  The feature process is as good as feature pages itself. And it's
> same
>  with trust. We can only trust feature owners to provide all relevant
>  information (and same applies for submitting features). If you take a look
>  on New Installer UI feature page, it's clear, talks about a new UI, 
>  it's there. It matches the description.  
Note that it has been changed to reflect several of the identified
inadequacies.

IIRC, at the time the feature was approved, it had no mention of at
least the following:

* The change to only allowing one desktop environment to be installed
interactively
* The change to not requiring a root password to be set
* The change to raw ext4 rather than LVM as the default partition scheme
* The fact that anaconda would no longer handle upgrades but an entirely
new tool would be written for this

There were probably others, those are ones I recall. These four things
alone are clearly major changes that merited discussion beyond the
anaconda team and should have been at least explicitly included in the
newUI feature and, in the fedup case, probably split out as its own
feature. An entirely new upgrade mechanism which obsoletes both our old
ones is clearly not an implementation detail, as we learned.

Again, not to level accusations at anyone, just to clearly identify an
area where the process clearly did not achieve what ideally it ought to
have achieved.

For the record, this link is the newUI feature page as it existed at the
time FESCo approved the feature:

https://fedoraproject.org/w/index.php?title=Features/NewInstallerUI&o...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Heiko Adams]

Am 31.10.2012 20:49, schrieb Adam Williamson:
>  On Wed, 2012-10-31 at 10:58 -0400, Jaroslav Reznik wrote:
>  
>  * The fact that anaconda would no longer handle upgrades but an entirely
>  new tool would be written for this
>   
Maybe I missunderstood something but IMHO such an elementary feature
like handling upgrade should only be removed if there is a replacement
*available* for all supported versions of fedora which is *fully tested*
and ready for action.
Otherwise the devs who removed such a feature should take the next trip
to the dark side of the moon.
-- 
Regards

Heiko Adams

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jóhann B. Guðmundsson]

On 10/31/2012 09:50 AM, Gianluca Sforna wrote:
>  However, I think anaconda developers knew that 6 months were too
> short
>  since the beginning. If this was abundantly clear to FESCo and other
>  interested parties, I think we could even accept a one time 9/12
>  months release cycle instead, without raising all this fuss for each
>  week of delay. 
Oh they knew all right [1]...

"There is no such thing as new anaconda. It supports so many features, 
that we are able to rewrite only parts at a time. And even at this pace 
it usually takes one or two Fedora releases to stabilize the rewritten 
part."

Pay very much attention to this...

"we are able to rewrite only parts at a time."

and

"two Fedora releases to stabilize the rewritten part."

JBG

1. http://msivak.fedorapeople.org/anaconda-openhouse/#%2818%29

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Vratislav Podzimek]

On Wed, 2012-10-31 at 10:05 +0000, "Jóhann B. Guðmundsson" wrote:
>  On 10/31/2012 09:50 AM, Gianluca Sforna wrote:
>  > However, I think anaconda developers knew that 6 months were too short
>  > since the beginning. If this was abundantly clear to FESCo and other
>  > interested parties, I think we could even accept a one time 9/12
>  > months release cycle instead, without raising all this fuss for each
>  > week of delay.
>  
>  Oh they knew all right [1]...
>  
>  "There is no such thing as new anaconda. It supports so many features, 
>  that we are able to rewrite only parts at a time. And even at this pace 
>  it usually takes one or two Fedora releases to stabilize the rewritten 
>  part."
>  
>  Pay very much attention to this...
>  
>  "we are able to rewrite only parts at a time." 
That's true and
believe me that UI *is only a part* of the Anaconda
installer.

>  
>  and
>  
>  "two Fedora releases to stabilize the rewritten part." 
And that's
something that happens to many more packages/features in
Fedora.

-- 
Vratislav Podzimek

Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Toshio Kuratomi]

On Wed, Oct 31, 2012 at 10:27:09AM +0100, Vratislav Podzimek wrote:
>  On Tue, 2012-10-30 at 19:32 +0100, Gianluca Sforna wrote:
>  > On Tue, Oct 30, 2012 at 7:12 PM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  > > I'd recommend asking dcantrell, as he has some good points on this
>  > > topic. I broadly agree with him that it might well be more or less
>  > > impossible to smoothly handle a major rewrite of anaconda in our current
>  > > development process. CCing to make sure he sees this.
>  > 
>  > If you are saying that 6 months are a too short time for something
>  > like this I think I can understand it.
>  6 months are a too short time. And it was less than 6 months. As can be
>  seen from the F18 release schedule [1], originally it was about 3 months
>  between the day F17 was released and the day new Anaconda was expected
>  to work (F18 Alpha release).  We of course didn't start the work on May
>  29, but since there were significant changes in F17 too at least part of
>  the team had to fix bugs and make F17 releasable.
>  
There's a mismatch between this practice and the theory of how we
develop Fedora.

https://fedoraproject.org/wiki/No_Frozen_Rawhide_Proposal#Problem_Space
"""
We also tell folks that a development cycle of Fedora starts from the branch
point of the release to be and goes all the way to the release of the next
release
"""

The theory of developing Fedora is that development starts when we branch
rawhide from Fedora-Next.  For the F18 cycle, this was January or February
2012.  So the theory is that currently, there's been about 9 months for the
development of Anaconda for F18.  There were 6-7 months up to Feature
Freeze when your feature was supposed to be implemented.

Now a couple comments based on both the practice and the theory:

* Many other contributors use the same practical development cycle as you
  do rather than the theoretical one.
  - We could decide this was okay and figure that the real development cycle
    that we give people is only 3 months so how do we help people with that.
  - We could decide that there's no way we can make two releases a year
    (especially if we have to adjust for slips by absorbing the time in the
    next cycle) and force people to start thinking of development starting
    at branch time.  One possibility here would be to freeze Next more. For
    instance, from alpha-release, next would be frozen with only "approved"
    changes going in.
* There's a lot of talk about focusing energies on getting the next release
  out the door rather than developing for rawhide.
  - This could be a perception thing.  Since people are already running
    behind with when they started development, they're behind on finishing
    it up at the end.  I don't think this theory fits with human behaviour
    :-)
  - This could be a sign of lack of manpower to both make releases and
    do big feature development within some teams.  This has several possible
    solutions
    + Don't do big feature development
    + Add more manpower
    + Remove some of the burden on them -- for instance, if dracut would
      require big anaconda changes dracut becomes responsible for providing
      the manpower to adjust to the change.
  - This could just mean that people care more about the release that is due
    out really soon rather than the one that's due out in 6+ months.
* Jesse Keating, Jeremy Katz, and others who helped shape the current policy
  and theory of our release schedule felt that the 6 month release cycle was
  fine but that certain features were going to take longer to develop.
  Those would need to be developed and not enter into Fedora until they were
  close enough that they could be completed during that cycle. 
  - No matter what we do to try and increase the development cycle within
    a release, there's always going to be issues that take longer than the
    release that we need to deal with.  Perhaps, we just need to be better
    about making people follow this model.

>  Also Alpha is not
>  supposed to be 100% feature complete, but it seemed to me that not
>  everybody was taking this into account.
>   
Here you're treading on a very thin grey line:
https://fedoraproject.org/wiki/Features/Policy/Milestones#Feature_Freeze

"""
Feature Freeze

New features must be feature complete or close enough to completion by
Feature Freeze so that a majority of its functionality can be tested during
the Alpha and Beta releases.
"""

At this point in the cycle, we should be Feature Complete and Testable.  The
Fedora Alpha release is like a Beta release in more traditional software
development release cycles.... we're supposeed to just be squashing bugs
from here on out.

-Toshio

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Stephen John Smoogen]

On 31 October 2012 10:56, Toshio Kuratomi <a.badger(a)gmail.com&gt; wrote:

>  There's a mismatch between this practice and the theory of how we
>  develop Fedora. 
When there is a mismatch from practice and theory... theory usually
needs to change :).


> https://fedoraproject.org/wiki/No_Frozen_Rawhide_Proposal#Problem_Space
>  """
>  We also tell folks that a development cycle of Fedora starts from the branch
>  point of the release to be and goes all the way to the release of the next
>  release
>  """
>
>  The theory of developing Fedora is that development starts when we branch
>  rawhide from Fedora-Next.  For the F18 cycle, this was January or February
>  2012.  So the theory is that currently, there's been about 9 months for the
>  development of Anaconda for F18.  There were 6-7 months up to Feature
>  Freeze when your feature was supposed to be implemented. 
This only seems to work for teams or parts that can split their
resources over doing 4 releases at one time (really old, current
release, new release fixes, next release coding). With stuff like
anaconda where the code usually has to get its stuff fixed after
everything else has landed.. that makes it a very hard to ever look at
next release coding unless it is done in a jarring way.

Historically I don't think any installer rewrite has hit schedule or
not caused a looooong delay in a release no matter which team has done
it (and there have been multiple ones who have tried to not repeat the
mistakes from the last team.)




-- 
Stephen J Smoogen.
"Don't derail a useful feature for the 99% because you're not in it."
Linus Torvalds
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me."  —James Stewart as Elwood P. Dowd

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Chris Adams]

Once upon a time, Stephen John Smoogen <smooge(a)gmail.com&gt; said:
>  This only seems to work for teams or parts that can split their
>  resources over doing 4 releases at one time (really old, current
>  release, new release fixes, next release coding). With stuff like
>  anaconda where the code usually has to get its stuff fixed after
>  everything else has landed.. that makes it a very hard to ever look at
>  next release coding unless it is done in a jarring way. 
That's true in general, but not really for anaconda.  Since there are no
official update images, once a release is out the door, the anaconda
team should basically be done with it (especially when there's not much
point in bug-fixing code that isn't going to ever be released again).

I think part of the problem was that there was an accepted feature for
newUI that just punted a bunch of things (such as upgrades and text
mode) to F19, and then later (like at Alpha time) people said "wait, we
can't do that".  IIRC the upgrade code had not been written at Alpha (at
least per the original schedule); even though upgrades are not part of
the Alpha test matrix, that should have failed as not being at or near
feature complete.

A lot more thought should have gone into the feature before it was
accepted.  The initial code needed to be ready (or very close) at F17
branch so it could have landed in rawhide (with install images being
built regularly for testing).  The list of required functionality for
F18 should have been reviewed better, at which point it should have been
recognized that it wasn't all going to happen for the original F18
schedule.  At that point, the schedule should have been adjusted
significantly (maybe another 9 month cycle instead of 6 month), which
would have let _all_ of Fedora benefit (with proper planning).

IMHO at this point, the schedule should be adjusted for another month
(at least, maybe two), and drop the Beta freeze until the re-scheduled
time hits.  I'm afraid that week-at-a-time slips (with everything else
frozen) are going to lead to rushed code, and that often leads to
significant problems down the road (bugs as well as poor design
choices).

-- 
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.

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Stephen John Smoogen]

On 31 October 2012 11:39, Chris Adams <cmadams(a)hiwaay.net&gt; wrote:
>  Once upon a time, Stephen John Smoogen <smooge(a)gmail.com&gt;
> said:
> > This only seems to work for teams or parts that can split their
> > resources over doing 4 releases at one time (really old, current
> > release, new release fixes, next release coding). With stuff like
> > anaconda where the code usually has to get its stuff fixed after
> > everything else has landed.. that makes it a very hard to ever look at
> > next release coding unless it is done in a jarring way.
>
>  That's true in general, but not really for anaconda.  Since there are no
>  official update images, once a release is out the door, the anaconda
>  team should basically be done with it (especially when there's not much
>  point in bug-fixing code that isn't going to ever be released again). 
Again.. that is a nice theory but in reality it is not true. Fedora
Intel is not Anaconda's only customer.  Fixes have to go in for other
branches. Fixes have to go in for spins, Fixes have to go in for
downstream customers be it some respin or Red Hat Enterprise Linux.
Fixes need to go in because maybe you won't run into that problem in
the next release and you better fix it now versus pulling that broken
code later. This means that you are not going to be able to stick on
new development until some X date which is going to be at least a
month or 3 before you can really focus on new development.

Honest Fact: 2-3 releases ago I would have been on the "This is crap
why is this happening yet again???". I am not doing so because I took
time out to look at the sausage factory and see what causes these
pile-ups every 2-3 years when an anaconda rewrite has to occur for one
reason or another.

-- 
Stephen J Smoogen.
"Don't derail a useful feature for the 99% because you're not in it."
Linus Torvalds
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me."  —James Stewart as Elwood P. Dowd

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jesse Keating]

On 10/31/2012 09:56 AM, Toshio Kuratomi wrote:
>  * Jesse Keating, Jeremy Katz, and others who helped shape the current
> policy
>     and theory of our release schedule felt that the 6 month release cycle was
>     fine but that certain features were going to take longer to develop.
>     Those would need to be developed and not enter into Fedora until they were
>     close enough that they could be completed during that cycle.
>     - No matter what we do to try and increase the development cycle within
>       a release, there's always going to be issues that take longer than the
>       release that we need to deal with.  Perhaps, we just need to be better
>       about making people follow this model. 
I'm not entirely sure what I felt then, but I'm certainly open to a 
longer release cycle.  In fact I'm very much in favor of one, one that 
puts more time between "feature complete" and the actual alpha release. 
  All too often we see features crash land right at the deadline, and 
any software that has to integrate across a lot of pieces (like 
anaconda) gets stuck trying to account for all these changes in a very 
limited time frame, only to be hindered quickly by a freeze process.

I think we need to give developers more time for feature integration 
after the feature freeze.

-- 
Help me fight child abuse: http://tinyurl.com/jlkcourage

- jlk

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jaroslav Reznik]

----- Original Message -----
>  On 10/31/2012 09:56 AM, Toshio Kuratomi wrote:
>  > * Jesse Keating, Jeremy Katz, and others who helped shape the
>  > current policy
>  >    and theory of our release schedule felt that the 6 month release
>  >    cycle was
>  >    fine but that certain features were going to take longer to
>  >    develop.
>  >    Those would need to be developed and not enter into Fedora until
>  >    they were
>  >    close enough that they could be completed during that cycle.
>  >    - No matter what we do to try and increase the development cycle
>  >    within
>  >      a release, there's always going to be issues that take longer
>  >      than the
>  >      release that we need to deal with.  Perhaps, we just need to
>  >      be better
>  >      about making people follow this model.
>  
>  I'm not entirely sure what I felt then, but I'm certainly open to a
>  longer release cycle.  In fact I'm very much in favor of one, one
>  that
>  puts more time between "feature complete" and the actual alpha
>  release.
>    All too often we see features crash land right at the deadline, and
>  any software that has to integrate across a lot of pieces (like
>  anaconda) gets stuck trying to account for all these changes in a
>  very
>  limited time frame, only to be hindered quickly by a freeze process. 
This makes sense, to have a period to integrate bits before  Alpha is 
released - and from two options - cutting time for a new feature 
development (and thus forcing us to the similar position of rushing
features) or prolong time between feature complete and alpha freeze,
it makes sense. On the other hand I'd like to see a little bit shorter
that time between Alpha and Final. As currently I'd say the proportion
of time spent on development and time spent on release (and not only
testing) seem quite inadequate... But of course, QA could no agree :)

I'm going to create a F19 schedule draft this week, any input would
be welcomed!

Jaroslav

>  I think we need to give developers more time for feature integration
>  after the feature freeze.
>  
>  --
>  Help me fight child abuse: http://tinyurl.com/jlkcourage
>  
>  - jlk
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Adam Williamson]

On Wed, 2012-10-31 at 15:58 -0400, Jaroslav Reznik wrote:

>  On the other hand I'd like to see a little bit shorter
>  that time between Alpha and Final. As currently I'd say the proportion
>  of time spent on development and time spent on release (and not only
>  testing) seem quite inadequate... But of course, QA could no agree :) 
We are certainly never short of stuff to test and stuff to fix between
Alpha and Final, let's put it that way.

However, this could plausibly simply be a result of there not being
enough time between 'feature complete' and Alpha. It's certainly
possible that tweaking things in the way suggested would not make stuff
any worse. Speaking personally I think we can't bless or condemn such a
change from a QA perspective ahead of time, we can probably only give it
a shot and see how it works out.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Toshio Kuratomi]

On Wed, Oct 31, 2012 at 10:59:54AM -0700, Jesse Keating wrote:
>  
>  I think we need to give developers more time for feature integration
>  after the feature freeze.
>   
+1

No matter whether we increase the length of development or not, the time
between feature freeze and the spinning of a release is too quick.

-Toshio

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Ralf Corsepius]

On 10/31/2012 11:00 PM, Toshio Kuratomi wrote:
>  On Wed, Oct 31, 2012 at 10:59:54AM -0700, Jesse Keating wrote:
> >
> > I think we need to give developers more time for feature integration
> > after the feature freeze.
> >
>  +1
>
>  No matter whether we increase the length of development or not, the time
>  between feature freeze and the spinning of a release is too quick. 
No matter which length of timeslots you choose, these timeslots will 
always be too short.

IMO, Fedora devs and FESCO needs to take fallback strategies and 
backing-out strategies into account right from the beginning and be 
prepared for devs not meeting deadlines.

Ralf

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Peter Robinson]

On Thu, Nov 1, 2012 at 6:37 AM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:

>  On 10/31/2012 11:00 PM, Toshio Kuratomi wrote:
>
> > On Wed, Oct 31, 2012 at 10:59:54AM -0700, Jesse Keating wrote:
> >
> >>
> >> I think we need to give developers more time for feature integration
> >> after the feature freeze.
> >>
> >>  +1
> >
> > No matter whether we increase the length of development or not, the time
> > between feature freeze and the spinning of a release is too quick.
> >
>
>  No matter which length of timeslots you choose, these timeslots will
>  always be too short.
>
>  IMO, Fedora devs and FESCO needs to take fallback strategies and
>  backing-out strategies into account right from the beginning and be
>  prepared for devs not meeting deadlines.
>
>  
And be prepared to take the hard decision to enforce them.

Peter

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Panu Matilainen]

On 11/01/2012 08:37 AM, Ralf Corsepius wrote:
>  On 10/31/2012 11:00 PM, Toshio Kuratomi wrote:
> > On Wed, Oct 31, 2012 at 10:59:54AM -0700, Jesse Keating wrote:
> >>
> >> I think we need to give developers more time for feature integration
> >> after the feature freeze.
> >>
> > +1
> >
> > No matter whether we increase the length of development or not, the time
> > between feature freeze and the spinning of a release is too quick.
>
>  No matter which length of timeslots you choose, these timeslots will
>  always be too short.
>
>  IMO, Fedora devs and FESCO needs to take fallback strategies and
>  backing-out strategies into account right from the beginning and be
>  prepared for devs not meeting deadlines. 
Nod. Seems to me one of the bigger issues is the tendency for features 
to crash-land right on the eve of the freeze + branch - so late there 
might not be time to revert (or at least postpone) them in case piles of 
unforeseen issues are found. Witness UsrMove which landed *just before* 
the branch, when something of that scale should've landed immediately 
*after* a branch to give time to discover and fix most of the problems 
it brought in rawhide.

There are features and features... some of them are new versions of 
leafnode packages or a just bunch of new packages which nothing else 
depends on, and some of them affect *everything* in the distro. Perhaps 
the invasive changes should have a considerably earlier deadline, and if 
the deadline is not met then the feature would be "automatically" 
postponed to next release.

	- Panu -

Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Matthew Miller]

On Thu, Nov 01, 2012 at 09:24:52AM +0200, Panu Matilainen wrote:
>  There are features and features... some of them are new versions of
>  leafnode packages or a just bunch of new packages which nothing else
>  depends on, and some of them affect *everything* in the distro.
>  Perhaps the invasive changes should have a considerably earlier
>  deadline, and if the deadline is not met then the feature would be
>  "automatically" postponed to next release. 
Right now, the Feature template has this sections:

  == Scope ==
  <!-- What work do the developers have to accomplish to complete the feature
  in time for release?  Is it a large change affecting many parts of the
  distribution or is it a very isolated change? What are those changes?-->

Maybe the explanation could be strengthened, and some "checkbox" options
added:

Choose one of:

 ☐ "This is a "leaf" feature adding new, stand-alone functionality.

 ☐ This feature brings new functionality which changes the default user
   experience for many users.

 ☐ This feature introduces changes which affect the user experience only in
   its own area.

Also, pick all that are relevant:
      
 ☐ This feature introduces broad change across the distribution requiring
   package changes from many contributors.
   
 ☐ If this feature is not 100% complete, there will be no regressions if
   packages built for it are shipped anyway.
   
 ☐ Once work on this feature passes a certain tipping point, it will be
   harder to revert than to go on.
   
And so on. (I can think of a few more offhand: "This feature will require a
mass rebuild", "This feature is likely to break Rawhide at some point in its
development", "This feature is a First, where Fedora is leading the
way"....)


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Adam Williamson]

On Thu, 2012-11-01 at 09:56 -0400, Matthew Miller wrote:
>  On Thu, Nov 01, 2012 at 09:24:52AM +0200, Panu Matilainen wrote:
>  > There are features and features... some of them are new versions of
>  > leafnode packages or a just bunch of new packages which nothing else
>  > depends on, and some of them affect *everything* in the distro.
>  > Perhaps the invasive changes should have a considerably earlier
>  > deadline, and if the deadline is not met then the feature would be
>  > "automatically" postponed to next release.
>  
>  Right now, the Feature template has this sections:
>  
>    == Scope ==
>    <!-- What work do the developers have to accomplish to complete the feature
>    in time for release?  Is it a large change affecting many parts of the
>    distribution or is it a very isolated change? What are those changes?-->
>  
>  Maybe the explanation could be strengthened, and some "checkbox" options
>  added:
>  
>  Choose one of:
>  
>   ☐ "This is a "leaf" feature adding new, stand-alone functionality.
>  
>   ☐ This feature brings new functionality which changes the default user
>     experience for many users.
>  
>   ☐ This feature introduces changes which affect the user experience only in
>     its own area. 
To make things clearer I think you could drop 'brings new functionality
which' from the second checkbox. The key thing we're trying to isolate
is whether the feature has implications for 'normal' usage; it doesn't
matter whether it's introducing new functionality.

I was rather thinking we can simply take advantage of the critical path
definition here. After all, when we came up with the critpath, the idea
was it was a general concept which could be useful beyond the idea of a
'critpath package'. So why don't we just introduce the concept of a
'critpath feature' - any feature with implications for the critical
path?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Panu Matilainen]

On 11/01/2012 07:08 PM, Adam Williamson wrote:
>  On Thu, 2012-11-01 at 09:56 -0400, Matthew Miller wrote:
> > On Thu, Nov 01, 2012 at 09:24:52AM +0200, Panu Matilainen wrote:
> >> There are features and features... some of them are new versions of
> >> leafnode packages or a just bunch of new packages which nothing else
> >> depends on, and some of them affect *everything* in the distro.
> >> Perhaps the invasive changes should have a considerably earlier
> >> deadline, and if the deadline is not met then the feature would be
> >> "automatically" postponed to next release.
> >
> > Right now, the Feature template has this sections:
> >
> >    == Scope ==
> >    <!-- What work do the developers have to accomplish to complete the feature
> >    in time for release?  Is it a large change affecting many parts of the
> >    distribution or is it a very isolated change? What are those changes?-->
> >
> > Maybe the explanation could be strengthened, and some "checkbox" options
> > added:
> >
> > Choose one of:
> >
> >   ☐ "This is a "leaf" feature adding new, stand-alone functionality.
> >
> >   ☐ This feature brings new functionality which changes the default user
> >     experience for many users.
> >
> >   ☐ This feature introduces changes which affect the user experience only in
> >     its own area.
>
>  To make things clearer I think you could drop 'brings new functionality
>  which' from the second checkbox. The key thing we're trying to isolate
>  is whether the feature has implications for 'normal' usage; it doesn't
>  matter whether it's introducing new functionality.
>
>  I was rather thinking we can simply take advantage of the critical path
>  definition here. After all, when we came up with the critpath, the idea
>  was it was a general concept which could be useful beyond the idea of a
>  'critpath package'. So why don't we just introduce the concept of a
>  'critpath feature' - any feature with implications for the critical
>  path? 
Nod. The critical path package set would serve at least as a point for 
refining the feature process. What the actual implications of critpath 
feature would be, Debian-style earlier freeze and/or something else, is 
probably a whole another (no doubt lengthy) topic :)

	- Panu -

Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Matthew Miller]

On Thu, Nov 01, 2012 at 10:08:39AM -0700, Adam Williamson wrote:
>  I was rather thinking we can simply take advantage of the critical
> path
>  definition here. After all, when we came up with the critpath, the idea
>  was it was a general concept which could be useful beyond the idea of a
>  'critpath package'. So why don't we just introduce the concept of a
>  'critpath feature' - any feature with implications for the critical
>  path? 

That sounds good. Maybe recast those ideas as three levels?

 - Critical Path Feature
 - Other Enhancement Feature
 - New Leaf Feature

I think this is nice for presenting the list of features overall, actually,
both on the web site and in the eventual release notes.

I also still like the idea of some other basic checkbox options which
encourage people to clarify the wider implications of the feature.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Jaroslav Reznik]

----- Original Message -----
>  On Thu, Nov 01, 2012 at 10:08:39AM -0700, Adam Williamson wrote:
>  > I was rather thinking we can simply take advantage of the critical
>  > path
>  > definition here. After all, when we came up with the critpath, the
>  > idea
>  > was it was a general concept which could be useful beyond the idea
>  > of a
>  > 'critpath package'. So why don't we just introduce the concept of a
>  > 'critpath feature' - any feature with implications for the critical
>  > path?
>  
>  
>  That sounds good. Maybe recast those ideas as three levels?
>  
>   - Critical Path Feature
>   - Other Enhancement Feature
>   - New Leaf Feature 
We were thinking with a few folks more about "Self contained feature"
but yeah, there's a lack of real definition.

Other thing is - these "Self contained features" could be approved
implicitly once are announced on devel list (in cooperation with
Feature Wrangler). Features that requires integration etc. will be
still approved by FESCo, but idea is to offload amount of work from
FESCo so they can give more time to track these features. Not to
bother with leaf features or enhancements. And as these should be
very visible (thanks to announcement) anybody could escalate any
feature to the FESCo for discussion/explicit approval.

That's the idea, I promised my proposal delivered to FESCo before
Beta ;-) But you know, moving target....

Any suggestions are welcomed!

Jaroslav


>  I think this is nice for presenting the list of features overall,
>  actually,
>  both on the web site and in the eventual release notes.
>  
>  I also still like the idea of some other basic checkbox options which
>  encourage people to clarify the wider implications of the feature.
>  
>  
>  --
>  Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁
>   <mattdm(a)fedoraproject.org&gt;
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Jóhann B. Guðmundsson]

On 11/01/2012 06:09 PM, Jaroslav Reznik wrote:
>  We were thinking with a few folks more about "Self contained
> feature"
>  but yeah, there's a lack of real definition.
>
>  Other thing is - these "Self contained features" could be approved
>  implicitly once are announced on devel list (in cooperation with
>  Feature Wrangler). Features that requires integration etc. will be
>  still approved by FESCo, but idea is to offload amount of work from
>  FESCo so they can give more time to track these features. Not to
>  bother with leaf features or enhancements. And as these should be
>  very visible (thanks to announcement) anybody could escalate any
>  feature to the FESCo for discussion/explicit approval.
>
>  That's the idea, I promised my proposal delivered to FESCo before
>  Beta;-)  But you know, moving target....
>
>  Any suggestions are welcomed! 
Blindly accepting features are unacceptable from QA stand point and 
arguably minor release updates should be kept out of the feature process

JBG

Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Jaroslav Reznik]

----- Original Message -----
>  On 11/01/2012 06:09 PM, Jaroslav Reznik wrote:
>  > We were thinking with a few folks more about "Self contained
>  > feature"
>  > but yeah, there's a lack of real definition.
>  >
>  > Other thing is - these "Self contained features" could be approved
>  > implicitly once are announced on devel list (in cooperation with
>  > Feature Wrangler). Features that requires integration etc. will be
>  > still approved by FESCo, but idea is to offload amount of work from
>  > FESCo so they can give more time to track these features. Not to
>  > bother with leaf features or enhancements. And as these should be
>  > very visible (thanks to announcement) anybody could escalate any
>  > feature to the FESCo for discussion/explicit approval.
>  >
>  > That's the idea, I promised my proposal delivered to FESCo before
>  > Beta;-)  But you know, moving target....
>  >
>  > Any suggestions are welcomed!
>  
>  Blindly accepting features are unacceptable from QA stand point and
>  arguably minor release updates should be kept out of the feature
>  process 
Definitely not blinding accepting - the feature would have to go through
the Feature Wrangler as for now and then it should be announced in public
way. So the Feature is not blindly accepted as many Features on FESCo
meeting to get rid of a queue of unapproved ones and even it gets
better visibility - so developers can interact with Feature owner and
in case of any issues - raise it to FESCo. And FESCo will have time to
actually work on it, not just +1-ing it.

Jaroslav

>  JBG
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Miloslav Trmač]

On Thu, Nov 1, 2012 at 7:10 PM, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com&gt; wrote:
>  On 11/01/2012 06:09 PM, Jaroslav Reznik wrote:
> > We were thinking with a few folks more about "Self contained feature"
> > but yeah, there's a lack of real definition.
> >
> > Other thing is - these "Self contained features" could be approved
> > implicitly once are announced on devel list (in cooperation with
> > Feature Wrangler). Features that requires integration etc. will be
> > still approved by FESCo, but idea is to offload amount of work from
> > FESCo so they can give more time to track these features. Not to
> > bother with leaf features or enhancements. And as these should be
> > very visible (thanks to announcement) anybody could escalate any
> > feature to the FESCo for discussion/explicit approval.
> >
> > That's the idea, I promised my proposal delivered to FESCo before
> > Beta;-)  But you know, moving target....
> >
> > Any suggestions are welcomed!
>
>  Blindly accepting features are unacceptable from QA stand point and arguably
>  minor release updates should be kept out of the feature process 
An important part of this proposal is to make the mailing list
announcement and time for discussion mandatory; that would actually
significantly increase the visibility of many features.  Also, the
feature would not be accepted "automatically", only "by default" -
anyone, including QA, could move the feature into the "full" process.
    Mirek

Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Matthew Miller]

On Thu, Nov 01, 2012 at 02:09:21PM -0400, Jaroslav Reznik wrote:
>  > That sounds good. Maybe recast those ideas as three levels?
>  >  - Critical Path Feature
>  >  - Other Enhancement Feature
>  >  - New Leaf Feature
>  We were thinking with a few folks more about "Self contained feature"
>  but yeah, there's a lack of real definition. 
I think "Leaf" is better than "Self contained", since it's
unlikely for the
feature to have zero outside dependencies. I think it'd be fine for such a
feature to rely on small changes to existing packages (version updates,
say).



>  Other thing is - these "Self contained features" could be
> approved
>  implicitly once are announced on devel list (in cooperation with
>  Feature Wrangler). Features that requires integration etc. will be
>  still approved by FESCo, but idea is to offload amount of work from
>  FESCo so they can give more time to track these features. Not to
>  bother with leaf features or enhancements. And as these should be
>  very visible (thanks to announcement) anybody could escalate any
>  feature to the FESCo for discussion/explicit approval.
>  
>  That's the idea, I promised my prposal delivered to FESCo before
>  Beta ;-) But you know, moving target....
>  
>  Any suggestions are welcomed!
>  
>  Jaroslav
>  
>  
>  > I think this is nice for presenting the list of features overall,
>  > actually,
>  > both on the web site and in the eventual release notes.
>  > 
>  > I also still like the idea of some other basic checkbox options which
>  > encourage people to clarify the wider implications of the feature.
>  > 
>  > 
>  > --
>  > Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁
>  >  <mattdm(a)fedoraproject.org&gt;
>  > --
>  > devel mailing list
>  > devel(a)lists.fedoraproject.org
>  > https://admin.fedoraproject.org/mailman/listinfo/devel
>  -- 
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel 
-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[drago01]

On Thu, Nov 1, 2012 at 7:34 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  On Thu, Nov 01, 2012 at 02:09:21PM -0400, Jaroslav Reznik wrote:
> > > That sounds good. Maybe recast those ideas as three levels?
> > >  - Critical Path Feature
> > >  - Other Enhancement Feature
> > >  - New Leaf Feature
> > We were thinking with a few folks more about "Self contained feature"
> > but yeah, there's a lack of real definition.
>
>  I think "Leaf" is better than "Self contained", since it's
> unlikely for the
>  feature to have zero outside dependencies. I think it'd be fine for such a
>  feature to rely on small changes to existing packages (version updates,
>  say). 
I'd argue that this isn't a "feature" ... otherwise we could advertise
every version upgrade as feature.
If it does not affect a large amount of users it is simply a version
upgrade not a "fedora feature".

Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Jaroslav Reznik]

----- Original Message -----
>  On Thu, Nov 1, 2012 at 7:34 PM, Matthew Miller
>  <mattdm(a)fedoraproject.org&gt; wrote:
>  > On Thu, Nov 01, 2012 at 02:09:21PM -0400, Jaroslav Reznik wrote:
>  >> > That sounds good. Maybe recast those ideas as three levels?
>  >> >  - Critical Path Feature
>  >> >  - Other Enhancement Feature
>  >> >  - New Leaf Feature
>  >> We were thinking with a few folks more about "Self contained
>  >> feature"
>  >> but yeah, there's a lack of real definition.
>  >
>  > I think "Leaf" is better than "Self contained", since it's
> unlikely
>  > for the
>  > feature to have zero outside dependencies. I think it'd be fine for
>  > such a
>  > feature to rely on small changes to existing packages (version
>  > updates,
>  > say).
>  
>  I'd argue that this isn't a "feature" ... otherwise we could
>  advertise
>  every version upgrade as feature.
>  If it does not affect a large amount of users it is simply a version
>  upgrade not a "fedora feature". 
The question is - how do you know if it affects large amount of users,
it's not an important one, without letting people know, there's such
feature?

Jaroslav

>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[drago01]

On Thu, Nov 1, 2012 at 7:45 PM, Jaroslav Reznik <jreznik(a)redhat.com&gt; wrote:
>  ----- Original Message -----
> > On Thu, Nov 1, 2012 at 7:34 PM, Matthew Miller
> > <mattdm(a)fedoraproject.org&gt; wrote:
> > > On Thu, Nov 01, 2012 at 02:09:21PM -0400, Jaroslav Reznik wrote:
> > >> > That sounds good. Maybe recast those ideas as three levels?
> > >> >  - Critical Path Feature
> > >> >  - Other Enhancement Feature
> > >> >  - New Leaf Feature
> > >> We were thinking with a few folks more about "Self contained
> > >> feature"
> > >> but yeah, there's a lack of real definition.
> > >
> > > I think "Leaf" is better than "Self contained", since
> it's unlikely
> > > for the
> > > feature to have zero outside dependencies. I think it'd be fine for
> > > such a
> > > feature to rely on small changes to existing packages (version
> > > updates,
> > > say).
> >
> > I'd argue that this isn't a "feature" ... otherwise we could
> > advertise
> > every version upgrade as feature.
> > If it does not affect a large amount of users it is simply a version
> > upgrade not a "fedora feature".
>
>  The question is - how do you know if it affects large amount of users,
>  it's not an important one, without letting people know, there's such
>  feature? 
Does a lot of other packages depend on it? -> Likely affects a lot of users.
Is it installed by default or a commonly used application / package ?
-> Likely affects a lot of users.
Is it a new package that isn't intended to be installed by default? ->
Probably does not affects a lot of users.
... etc.

So while there is no 100% accurate definition applying some common
sense helps here.

Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Adam Williamson]

On Thu, 2012-11-01 at 19:50 +0100, drago01 wrote:
>  On Thu, Nov 1, 2012 at 7:45 PM, Jaroslav Reznik
> <jreznik(a)redhat.com&gt; wrote:
>  > ----- Original Message -----
>  >> On Thu, Nov 1, 2012 at 7:34 PM, Matthew Miller
>  >> <mattdm(a)fedoraproject.org&gt; wrote:
>  >> > On Thu, Nov 01, 2012 at 02:09:21PM -0400, Jaroslav Reznik wrote:
>  >> >> > That sounds good. Maybe recast those ideas as three levels?
>  >> >> >  - Critical Path Feature
>  >> >> >  - Other Enhancement Feature
>  >> >> >  - New Leaf Feature
>  >> >> We were thinking with a few folks more about "Self contained
>  >> >> feature"
>  >> >> but yeah, there's a lack of real definition.
>  >> >
>  >> > I think "Leaf" is better than "Self contained", since
> it's unlikely
>  >> > for the
>  >> > feature to have zero outside dependencies. I think it'd be fine for
>  >> > such a
>  >> > feature to rely on small changes to existing packages (version
>  >> > updates,
>  >> > say).
>  >>
>  >> I'd argue that this isn't a "feature" ... otherwise we could
>  >> advertise
>  >> every version upgrade as feature.
>  >> If it does not affect a large amount of users it is simply a version
>  >> upgrade not a "fedora feature".
>  >
>  > The question is - how do you know if it affects large amount of users,
>  > it's not an important one, without letting people know, there's such
>  > feature?
>  
>  Does a lot of other packages depend on it? -> Likely affects a lot of users.
>  Is it installed by default or a commonly used application / package ?
>  -> Likely affects a lot of users.
>  Is it a new package that isn't intended to be installed by default? ->
>  Probably does not affects a lot of users.
>  ... etc.
>  
>  So while there is no 100% accurate definition applying some common
>  sense helps here. 
Well. It's worth considering the underlying problem here, which we've
known about for a while: the feature process is overloaded. We use it
for multiple purposes.

In this thread we're mostly concerned with the aspects of the feature
process that deal with genuine technical / QA issues: are we doing well
enough at evaluating and overseeing features from a technical
perspective.

However, the feature process achieves other things too. The other
obvious big one is publicity/documentation: that's the reason all these
leaf features are made features at all, so they can be written up in our
announcements and documentation.

I think the direction we're driving here will actually address that
problem too; if we split features into 'critpath' and 'leaf' (and maybe
some other category/ies) we will be able to make the process more sane.
For 'leaf' features we can concentrate on the PR/documentation stuff and
we really don't have to worry too much about the technical / release
schedule side of things for those features.

So if we go down the road of categorizing features and do a good job of
it, I think that rather makes the issue of 'why are these little things
features at all?' go away. They'd be features simply for the PR, and we
could codify that.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Richard W.M. Jones]

The other thing that we mustn't forget are major changes that aren't
put through the feature process, but slip in "via the back door".

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v

Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Matthew Miller]

On Thu, Nov 01, 2012 at 08:13:57PM +0000, Richard W.M. Jones wrote:
>  The other thing that we mustn't forget are major changes that
> aren't
>  put through the feature process, but slip in "via the back door". 
That's where the critpath vs. other enhancement distinction comes in -- for
critpath we can be more strict about requiring the process without making it
more onerous for other changes.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Jóhann B. Guðmundsson]

On 11/01/2012 08:13 PM, Richard W.M. Jones wrote:
>  The other thing that we mustn't forget are major changes that
> aren't
>  put through the feature process, but slip in "via the back door". 
As far as I know you are not obligated to participate in the feature 
process and what do you exactly define as slip in "via the back door" ?

JBG

Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Adam Williamson]

On Thu, 2012-11-01 at 21:28 +0000, "Jóhann B. Guðmundsson" wrote:
>  On 11/01/2012 08:13 PM, Richard W.M. Jones wrote:
>  > The other thing that we mustn't forget are major changes that aren't
>  > put through the feature process, but slip in "via the back door".
>  
>  As far as I know you are not obligated to participate in the feature 
>  process and what do you exactly define as slip in "via the back door" ? 
'not participate in the feature process', I think =)

I think I once proposed that FESCo should formally have the ability to
declare that a given change ought to be a feature and force it through
the feature process, but that proposal was rejected.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Matthew Miller]

On Thu, Nov 01, 2012 at 02:43:00PM -0700, Adam Williamson wrote:
>  I think I once proposed that FESCo should formally have the ability
> to
>  declare that a given change ought to be a feature and force it through
>  the feature process, but that proposal was rejected. 
I think that requiring the feature process for major critical path changes
is at least the platonic ideal, even if we're not at a point where we can do
it yet.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Josh Boyer]

On Thu, Nov 1, 2012 at 2:45 PM, Jaroslav Reznik <jreznik(a)redhat.com&gt; wrote:
>  ----- Original Message -----
> > On Thu, Nov 1, 2012 at 7:34 PM, Matthew Miller
> > <mattdm(a)fedoraproject.org&gt; wrote:
> > > On Thu, Nov 01, 2012 at 02:09:21PM -0400, Jaroslav Reznik wrote:
> > >> > That sounds good. Maybe recast those ideas as three levels?
> > >> >  - Critical Path Feature
> > >> >  - Other Enhancement Feature
> > >> >  - New Leaf Feature
> > >> We were thinking with a few folks more about "Self contained
> > >> feature"
> > >> but yeah, there's a lack of real definition.
> > >
> > > I think "Leaf" is better than "Self contained", since
> it's unlikely
> > > for the
> > > feature to have zero outside dependencies. I think it'd be fine for
> > > such a
> > > feature to rely on small changes to existing packages (version
> > > updates,
> > > say).
> >
> > I'd argue that this isn't a "feature" ... otherwise we could
> > advertise
> > every version upgrade as feature.
> > If it does not affect a large amount of users it is simply a version
> > upgrade not a "fedora feature".
>
>  The question is - how do you know if it affects large amount of users,
>  it's not an important one, without letting people know, there's such
>  feature? 
Version upgrades of _most_ packages are not features.  When someone is
updating or installing a new Fedora they _expect_ to be getting newer
versions of packages already.  It doesn't make much sense to update
your local Fedora install if you aren't actually going to get new
things.

Coordination among the other packages in the distro should already be
handled with ABI/soname change notifications in rawhide.  In the rare
case a package change some file format that users need to manually
handle or otherwise be aware of, release notes can cover that under a
special update section.  It doesn't make that version update a
feature.

For things like Gnome 3.6, or KDE 4.<whatever>, or MATE, then sure a
Feature might be warranted there.  Those are clearly large undertakings
that need to be carefully coordinated.  Updating postgresql or gwibber
or cowsay or less are not.

josh

Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Matthew Miller]

On Thu, Nov 01, 2012 at 07:41:21PM +0100, drago01 wrote:
>  > I think "Leaf" is better than "Self
> contained", since it's unlikely for the
>  > feature to have zero outside dependencies. I think it'd be fine for such a
>  > feature to rely on small changes to existing packages (version updates,
>  > say).
>  I'd argue that this isn't a "feature" ... otherwise we could advertise
>  every version upgrade as feature.
>  If it does not affect a large amount of users it is simply a version
>  upgrade not a "fedora feature". 
Sorry, I wasn't clear. It may be that some set of new functionality requires
small version upgrades. The feature is the new functionality, not the
version upgrades.

An example: I want to propose Scratch, the educational programming language,
as a feature for F19. It's not big, but it's popular and there's a new book,
generating public interest so it'd be nice for it to be included in the
process. Scratch itself is a new package. But it requires an update to
Squeak VM in order to work properly. This is incidental to the feature
itself -- so it'd be weird to classify this as an update to existing
functionality -- but the feature isn't "self contained".

That said, a significant version upgrade to something _should_ be able to be
a feature in itself.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Miloslav Trmač]

On Thu, Nov 1, 2012 at 7:34 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  On Thu, Nov 01, 2012 at 02:09:21PM -0400, Jaroslav Reznik wrote:
> > > That sounds good. Maybe recast those ideas as three levels?
> > >  - Critical Path Feature
> > >  - Other Enhancement Feature
> > >  - New Leaf Feature
> > We were thinking with a few folks more about "Self contained feature"
> > but yeah, there's a lack of real definition.
>
>  I think "Leaf" is better than "Self contained", since it's
> unlikely for the
>  feature to have zero outside dependencies. I think it'd be fine for such a
>  feature to rely on small changes to existing packages (version updates,
>  say). 
"Self-contained" in the proposal is intentionally more broad than
"leaf".  For example, it allows a small SIG for a less-used language
that does not affect the rest of the distribution to agree to do a
major version upgrade and to coordinate among the SIG members (as they
would coordinate in any case), without FESCo playing an useless
middle-man.

(The suggested definition of "self-contained" is something like
"maintainers of all affected packages sign up to participate on the
work for the feature".)
    Mirek

Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Matthew Miller]

On Mon, Nov 05, 2012 at 05:45:14PM +0100, Miloslav Trmač wrote:
>  > I think "Leaf" is better than "Self
> contained", since it's unlikely for
>  > the feature to have zero outside dependencies. I think it'd be fine for
>  > such a feature to rely on small changes to existing packages (version
>  > updates, say).
>  "Self-contained" in the proposal is intentionally more broad than
>  "leaf".  For example, it allows a small SIG for a less-used language
>  that does not affect the rest of the distribution to agree to do a
>  major version upgrade and to coordinate among the SIG members (as they
>  would coordinate in any case), without FESCo playing an useless
>  middle-man.
>  
>  (The suggested definition of "self-contained" is something like
>  "maintainers of all affected packages sign up to participate on the
>  work for the feature".) 
I don't mind too much what the actual name is as long as the scope is clear.

Here, I think you're smooshing together two of the three levels I'd
suggested, putting both non-crit-path enhancements and new leaf
functionality into one category. Is that correct?



-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Miloslav Trmač]

On Mon, Nov 5, 2012 at 7:34 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  On Mon, Nov 05, 2012 at 05:45:14PM +0100, Miloslav Trmač wrote:
> > > I think "Leaf" is better than "Self contained", since
> it's unlikely for
> > > the feature to have zero outside dependencies. I think it'd be fine for
> > > such a feature to rely on small changes to existing packages (version
> > > updates, say).
> > "Self-contained" in the proposal is intentionally more broad than
> > "leaf".  For example, it allows a small SIG for a less-used language
> > that does not affect the rest of the distribution to agree to do a
> > major version upgrade and to coordinate among the SIG members (as they
> > would coordinate in any case), without FESCo playing an useless
> > middle-man.
> >
> > (The suggested definition of "self-contained" is something like
> > "maintainers of all affected packages sign up to participate on the
> > work for the feature".)
>
>  I don't mind too much what the actual name is as long as the scope is clear.
>
>  Here, I think you're smooshing together two of the three levels I'd
>  suggested, putting both non-crit-path enhancements and new leaf
>  functionality into one category. Is that correct? 
Yes, the "self-contained" wording covers both leaf features and a
subset of non-leaf features.  "Non-crit-path" and "all relevant
maintainer are involved" are different subsets of non-leaf features,
however.
    Mirek

Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Matthew Miller]

On Mon, Nov 05, 2012 at 07:55:26PM +0100, Miloslav Trmač wrote:
>  > Here, I think you're smooshing together two of the three
> levels I'd
>  > suggested, putting both non-crit-path enhancements and new leaf
>  > functionality into one category. Is that correct?
>  Yes, the "self-contained" wording covers both leaf features and a
>  subset of non-leaf features.  "Non-crit-path" and "all relevant
>  maintainer are involved" are different subsets of non-leaf features,
>  however. 
> From the point of view of evaluating impact, and for that matter for
> the 
release notes, I think it's good to have big-non-crit-path-enhancements and
leaf functionality categorized separately. Both of them would need to be
self contained in the sense you're suggesting.

In fact, for that matter, wouldn't crit path updates _also_ benefit from the
"all relevant maintainers" rule? 



-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Miloslav Trmač]

On Mon, Nov 5, 2012 at 8:38 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  On Mon, Nov 05, 2012 at 07:55:26PM +0100, Miloslav Trmač wrote:
> > > Here, I think you're smooshing together two of the three levels I'd
> > > suggested, putting both non-crit-path enhancements and new leaf
> > > functionality into one category. Is that correct?
> > Yes, the "self-contained" wording covers both leaf features and a
> > subset of non-leaf features.  "Non-crit-path" and "all relevant
> > maintainer are involved" are different subsets of non-leaf features,
> > however.
>
>  From the point of view of evaluating impact, and for that matter for the
>  release notes, I think it's good to have big-non-crit-path-enhancements and
>  leaf functionality categorized separately. Both of them would need to be
>  self contained in the sense you're suggesting. 
Sure, the primary measure is the overall impact on the OS.  The
proposal is to treat "self-contained" features as "approved by
default", nothing more; features with large impact would still go
through the full process by overriding the default approval.

>  In fact, for that matter, wouldn't crit path updates _also_
> benefit from the
>  "all relevant maintainers" rule? 
A crit path update that affects, say, two packages and nothing else,
could be "approved by default" as well.  Many of the crit path
features however affect a large or extremely large package set (e.g.
the sysv->systemd script migration), in which case explicitly
involving every maintainer as the feature owner before even proposing
the feature wouldn't scale; that's where FESCo does need to step in as
a more efficient way to represent the large group of packagers.
    Mirek

Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Jóhann B. Guðmundsson]

On 11/05/2012 07:52 PM, Miloslav Trmač wrote:
>  A crit path update that affects, say, two packages and nothing else,
>  could be "approved by default" as well.  Many of the crit path
>  features however affect a large or extremely large package set (e.g.
>  the sysv->systemd script migration), in which case explicitly
>  involving every maintainer as the feature owner before even proposing
>  the feature wouldn't scale; that's where FESCo does need to step in as
>  a more efficient way to represent the large group of packagers. 
Case in point for F18 [1] and perfect example of one thing that should 
have been completed within one release cycle...

JBG


1.http://fedoraproject.org/wiki/Features/PackagePresets

Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Garrett Holmstrom]

On 2012-11-05 12:22, "Jóhann B. Guðmundsson" wrote:
>  On 11/05/2012 07:52 PM, Miloslav Trmač wrote:
> > A crit path update that affects, say, two packages and nothing else,
> > could be "approved by default" as well.  Many of the crit path
> > features however affect a large or extremely large package set (e.g.
> > the sysv->systemd script migration), in which case explicitly
> > involving every maintainer as the feature owner before even proposing
> > the feature wouldn't scale; that's where FESCo does need to step in as
> > a more efficient way to represent the large group of packagers.
>
>  Case in point for F18 [1] and perfect example of one thing that should
>  have been completed within one release cycle...
>
>  JBG
>
>
>  1.http://fedoraproject.org/wiki/Features/PackagePresets 
As that feature is about changing distribution-wide policy, I cannot act 
on it until said policy is written.  (See 
https://fedorahosted.org/fesco/ticket/945)  The feature's owners do not 
appear to be interested in doing so.  If you are, I would greatly 
appreciate it if you would add a proposal to that FESCo ticket so I can 
have a clear path forward.

Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]

[Jóhann B. Guðmundsson]

On 11/06/2012 05:35 AM, Garrett Holmstrom wrote:
>  On 2012-11-05 12:22, "Jóhann B. Guðmundsson" wrote:
> > On 11/05/2012 07:52 PM, Miloslav Trmač wrote:
> >> A crit path update that affects, say, two packages and nothing else,
> >> could be "approved by default" as well.  Many of the crit path
> >> features however affect a large or extremely large package set (e.g.
> >> the sysv->systemd script migration), in which case explicitly
> >> involving every maintainer as the feature owner before even proposing
> >> the feature wouldn't scale; that's where FESCo does need to step in as
> >> a more efficient way to represent the large group of packagers.
> >
> > Case in point for F18 [1] and perfect example of one thing that should
> > have been completed within one release cycle...
> >
> > JBG
> >
> >
> > 1.http://fedoraproject.org/wiki/Features/PackagePresets
>
>  As that feature is about changing distribution-wide policy, I cannot 
>  act on it until said policy is written.  (See 
>  https://fedorahosted.org/fesco/ticket/945)  The feature's owners do 
>  not appear to be interested in doing so.  If you are, I would greatly 
>  appreciate it if you would add a proposal to that FESCo ticket so I 
>  can have a clear path forward. 
Well I guess we probably should follow what other distributions most 
notably opensuse I suppose since they switched to using preset a while 
back but I'm not finding any clause about packages preset files 
themselves [1] so I'm not sure how they handled it unless they just have 
stricter rules that everything should be defaulted to off which can be 
seen by the default preset policy for opensuse [2] compared to our 
bloated one [3].

Issues like these are perfect example for something that should have 
been resolved *before* the feature was accepted by FESCO...

JBG

1.http://en.opensuse.org/openSUSE:Systemd_packaging_guidelines
2.https://build.opensuse.org/package/view_file?file=default-openSUSE.pres...
3.http://pkgs.fedoraproject.org/cgit/systemd.git/tree/90-default.preset

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Michael Scherer]

Le mercredi 31 octobre 2012 à 10:59 -0700, Jesse Keating a écrit :
>  On 10/31/2012 09:56 AM, Toshio Kuratomi wrote:
>  > * Jesse Keating, Jeremy Katz, and others who helped shape the current policy
>  >    and theory of our release schedule felt that the 6 month release cycle was
>  >    fine but that certain features were going to take longer to develop.
>  >    Those would need to be developed and not enter into Fedora until they were
>  >    close enough that they could be completed during that cycle.
>  >    - No matter what we do to try and increase the development cycle within
>  >      a release, there's always going to be issues that take longer than the
>  >      release that we need to deal with.  Perhaps, we just need to be better
>  >      about making people follow this model.
>  
>  I'm not entirely sure what I felt then, but I'm certainly open to a 
>  longer release cycle.  In fact I'm very much in favor of one, one that 
>  puts more time between "feature complete" and the actual alpha release. 
>    All too often we see features crash land right at the deadline, and 
>  any software that has to integrate across a lot of pieces (like 
>  anaconda) gets stuck trying to account for all these changes in a very 
>  limited time frame, only to be hindered quickly by a freeze process. 
Or do like Debian and have more than 1 freeze. IE, the basesystem is
freezed and then the rest is freezed.

Having packages on the critical path to be frozen sooner could make
sense. 

Maybe having some kind of dependencies between feature could also be a
idea. Anaconda requires dracut to not change, so we need a way to
express this, and a way to avoid changes at the same time. The same goes
for a python upgrade or lots of things.

-- 
Michael Scherer

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jóhann B. Guðmundsson]

On 11/01/2012 12:22 PM, Michael Scherer wrote:
>  Maybe having some kind of dependencies between feature could also be
> a
>  idea. Anaconda requires dracut to not change, so we need a way to
>  express this, and a way to avoid changes at the same time. The same goes
>  for a python upgrade or lots of things. 
It would be good if any of the Anaconda developers could comment what 
external components can affect Anaconda and to what extend atleast if 
I'm not mistaken these external components can affect Anaconda

Kernel
Dracut
Systemd
NetworkManager
Changes in comps/packaging group ( rpm/yum? )

JBG

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[David Lehman]

On Thu, 2012-11-01 at 13:01 +0000, "Jóhann B. Guðmundsson" wrote:
>  On 11/01/2012 12:22 PM, Michael Scherer wrote:
>  > Maybe having some kind of dependencies between feature could also be a
>  > idea. Anaconda requires dracut to not change, so we need a way to
>  > express this, and a way to avoid changes at the same time. The same goes
>  > for a python upgrade or lots of things.
>  
>  It would be good if any of the Anaconda developers could comment what 
>  external components can affect Anaconda and to what extend atleast if 
>  I'm not mistaken these external components can affect Anaconda
>  
>  Kernel
>  Dracut
>  Systemd
>  NetworkManager
>  Changes in comps/packaging group ( rpm/yum? ) 
lvm
mdadm
btrfs-progs

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jesse Keating]

On 11/01/2012 07:32 AM, David Lehman wrote:
>  On Thu, 2012-11-01 at 13:01 +0000, "Jóhann B. Guðmundsson"
> wrote:
> > On 11/01/2012 12:22 PM, Michael Scherer wrote:
> >> Maybe having some kind of dependencies between feature could also be a
> >> idea. Anaconda requires dracut to not change, so we need a way to
> >> express this, and a way to avoid changes at the same time. The same goes
> >> for a python upgrade or lots of things.
> >
> > It would be good if any of the Anaconda developers could comment what
> > external components can affect Anaconda and to what extend atleast if
> > I'm not mistaken these external components can affect Anaconda
> >
> > Kernel
> > Dracut
> > Systemd
> > NetworkManager
> > Changes in comps/packaging group ( rpm/yum? )
>
>  lvm
>  mdadm
>  btrfs-progs
>
>  
e2fsprogs
xfsprogs
xvnc
......

Basically anything in lorax's runtime-install.tmpl and all the deps 
therein can destabilize anaconda.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Adam Williamson]

On Thu, 2012-11-01 at 09:32 -0500, David Lehman wrote:
>  On Thu, 2012-11-01 at 13:01 +0000, "Jóhann B. Guðmundsson"
> wrote:
>  > On 11/01/2012 12:22 PM, Michael Scherer wrote:
>  > > Maybe having some kind of dependencies between feature could also be a
>  > > idea. Anaconda requires dracut to not change, so we need a way to
>  > > express this, and a way to avoid changes at the same time. The same goes
>  > > for a python upgrade or lots of things.
>  > 
>  > It would be good if any of the Anaconda developers could comment what 
>  > external components can affect Anaconda and to what extend atleast if 
>  > I'm not mistaken these external components can affect Anaconda
>  > 
>  > Kernel
>  > Dracut
>  > Systemd
>  > NetworkManager
>  > Changes in comps/packaging group ( rpm/yum? )
>  
>  lvm
>  mdadm
>  btrfs-progs 
parted, grub2, everything in anaconda-tools group in comps...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Peter Robinson]

On Thu, Nov 1, 2012 at 5:12 PM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:

>  On Thu, 2012-11-01 at 09:32 -0500, David Lehman wrote:
>  > On Thu, 2012-11-01 at 13:01 +0000, "Jóhann B. Guðmundsson" wrote:
>  > > On 11/01/2012 12:22 PM, Michael Scherer wrote:
>  > > > Maybe having some kind of dependencies between feature could also be
>  a
>  > > > idea. Anaconda requires dracut to not change, so we need a way to
>  > > > express this, and a way to avoid changes at the same time. The same
>  goes
>  > > > for a python upgrade or lots of things.
>  > >
>  > > It would be good if any of the Anaconda developers could comment what
>  > > external components can affect Anaconda and to what extend atleast if
>  > > I'm not mistaken these external components can affect Anaconda
>  > >
>  > > Kernel
>  > > Dracut
>  > > Systemd
>  > > NetworkManager
>  > > Changes in comps/packaging group ( rpm/yum? )
>  >
>  > lvm
>  > mdadm
>  > btrfs-progs
>
>  parted, grub2, everything in anaconda-tools group in comps...
>
>  
EFI, and enterprise storage (FCP, iSCSI, FCoE etc).

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jóhann B. Guðmundsson]

On 10/31/2012 05:59 PM, Jesse Keating wrote:
>  On 10/31/2012 09:56 AM, Toshio Kuratomi wrote:
> > * Jesse Keating, Jeremy Katz, and others who helped shape the current 
> > policy
> >    and theory of our release schedule felt that the 6 month release 
> > cycle was
> >    fine but that certain features were going to take longer to develop.
> >    Those would need to be developed and not enter into Fedora until 
> > they were
> >    close enough that they could be completed during that cycle.
> >    - No matter what we do to try and increase the development cycle 
> > within
> >      a release, there's always going to be issues that take longer 
> > than the
> >      release that we need to deal with.  Perhaps, we just need to be 
> > better
> >      about making people follow this model.
>
>  I'm not entirely sure what I felt then, but I'm certainly open to a 
>  longer release cycle.  In fact I'm very much in favor of one, one that 
>  puts more time between "feature complete" and the actual alpha 
>  release.  All too often we see features crash land right at the 
>  deadline, and any software that has to integrate across a lot of 
>  pieces (like anaconda) gets stuck trying to account for all these 
>  changes in a very limited time frame, only to be hindered quickly by a 
>  freeze process.
>
>  I think we need to give developers more time for feature integration 
>  after the feature freeze.
>  
We ( QA community ) would benefit from a longer release cycle since we 
need more time to properly test "features" and other vital components 
and arguably the QA part of an feature should FESCO delegate to QA 
community to oversee and handle...

JBG

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Heiko Adams]

Am 01.11.2012 15:41, schrieb "Jóhann B. Guðmundsson":
>  
>  We ( QA community ) would benefit from a longer release cycle since we
>  need more time to properly test "features" and other vital components
>  and arguably the QA part of an feature should FESCO delegate to QA
>  community to oversee and handle...
>   
Maybe we should think again about switching to a roling release models
for Fedora stable. This would IMHO have some benefits to the whole
community.

It would allow dev to take the time they need to develop new features
like the anaconda rewrite and push them to stable when "it's done"
without getting into trouble with the release schedule. On the other
hand Fedora releases would become just a regular snapshot of Fedoras
stable repository. So QA could focus on testing new features *before*
they are pushed to the stable repository. And last but not least Fedora
could stay in sync with major upstream projects.
-- 
Regards

Heiko Adams

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jared K. Smith]

On Thu, Nov 1, 2012 at 10:56 AM, Heiko Adams <heiko.adams(a)gmail.com&gt; wrote:
>  Maybe we should think again about switching to a roling release
> models
>  for Fedora stable. This would IMHO have some benefits to the whole
>  community. 
I'm afraid a rolling release model would make it *harder* to make
major changes to Fedora, not easier.  We've had discussion after
discussion about the rolling release model over the past several
years, but I don't think the majority of the people who build Fedora
and make it work want to move to that model model.  If they did, we'd
have gone down that row by now.  (And, while it's not close to
perfect, rawhide is roughly analogous to a rolling release anyway --
enough so that many people are actively using it, even if it causes a
little pain from time to time.)

In short, bringing the topic of rolling releases  up again at this
time doesn't help us fix the situation at hand -- it simply distracts
us with vague alternatives rather than providing any concrete ideas
for making our current feature process better.

--
Jared Smith

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Adam Williamson]

On Thu, 2012-11-01 at 15:56 +0100, Heiko Adams wrote:
>  Am 01.11.2012 15:41, schrieb "Jóhann B. Guðmundsson":
>  > 
>  > We ( QA community ) would benefit from a longer release cycle since we
>  > need more time to properly test "features" and other vital components
>  > and arguably the QA part of an feature should FESCO delegate to QA
>  > community to oversee and handle...
>  > 
>  Maybe we should think again about switching to a roling release models
>  for Fedora stable. This would IMHO have some benefits to the whole
>  community. 
I didn't want to throw this grenade into the debate, but now someone
else has, I'll just note that I was in favour of this before and I'm
still in favour of it now. :) Rolling release is a model that makes
clear sense for a distribution with the goals that Fedora has.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Michael Cronenworth]

Adam Williamson wrote:
>  I didn't want to throw this grenade into the debate, but now
> someone
>  else has, I'll just note that I was in favour of this before and I'm
>  still in favour of it now. :) Rolling release is a model that makes
>  clear sense for a distribution with the goals that Fedora has. 
I've wanted to write up a blog post about my plan for a rolling release,
but I'll post a snip-it here.

Fedora Rawhide - stays as is... it is a rolling release

Fedora Feature - think of it as F18 beta right now

Fedora Stable - think of it as F16/F17 right now

People choose the branch level at install time. Of course, like now,
people can override this in the future with a change of fedora-release
or yum --releasever. However, per-package updates from another branch
level might not be something everyone can agree on how to handle, so it
might be wise to limit support of it at first.

Workflow:
A shiny new feature is introduced in Rawhide. Things go boom. Not many
people are hurt by this. Once it has been given a few band-aids the
feature could be submitted to Fedora Feature. After some hardening and
polishing the feature could finally be pushed to Fedora Stable.

I feel this should give a good compromise to everyone's fears of a
rolling release. It gives the feature freaks a place in Fedora. It gives
the stable stubborns a place in Fedora.

I'll wake up from my dream now.

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Stanislav Ochotnicky]

Quoting Michael Cronenworth (2012-11-01 18:33:24)
>  Adam Williamson wrote:
>  > I didn't want to throw this grenade into the debate, but now someone
>  > else has, I'll just note that I was in favour of this before and I'm
>  > still in favour of it now. :) Rolling release is a model that makes
>  > clear sense for a distribution with the goals that Fedora has.
>  
>  I've wanted to write up a blog post about my plan for a rolling release,
>  but I'll post a snip-it here.
>  
>  Fedora Rawhide - stays as is... it is a rolling release
>  
>  Fedora Feature - think of it as F18 beta right now
>  
>  Fedora Stable - think of it as F16/F17 right now
>  
>  People choose the branch level at install time. Of course, like now,
>  people can override this in the future with a change of fedora-release
>  or yum --releasever. However, per-package updates from another branch
>  level might not be something everyone can agree on how to handle, so it
>  might be wise to limit support of it at first.
>  
>  Workflow:
>  A shiny new feature is introduced in Rawhide. Things go boom. Not many
>  people are hurt by this. Once it has been given a few band-aids the
>  feature could be submitted to Fedora Feature. After some hardening and
>  polishing the feature could finally be pushed to Fedora Stable.
>  
>  I feel this should give a good compromise to everyone's fears of a
>  rolling release. It gives the feature freaks a place in Fedora. It gives
>  the stable stubborns a place in Fedora.
>  
>  I'll wake up from my dream now. 
I recently came up with similar 3-layer idea. My description was a bit
different, something like this:
1. level - rawhide-like repository, more or less anything goes
2. level - package moves here after maintainer says "this package has been
           working for me for some time and looks OK. Let's integrate properly
           with rest of the system".
3. level - packages integrated and experience should be splendid :-)

However let's see how we'd handle systemd change with this system:
1. level - Lennart packages systemd, plays around with it. FESCO accepts systemd
           as worthy FEATURE for future stable (3rd level). Packages interacting
           with init system can take their time updating. 
2. level - systemd moves here. After this point, packages moving from 1st level
           here, will have to support systemd. Experience will likely be shaky
           for a time, then settle down. 
3. level - after some time (1 year, 2 years?) systemd moves here and all
           packages that have been fixed to work with it as well

There are several problems with this approach though:
1. There are always multiple big changes happening in fedora. So even stable
   would see big updates on relatively frequent basis. 
2. Several big changes will interact with each other. I.e. Gnome update will
   contain some daemons so they'd have to integrate with systemd on 2nd level.
   But then Gnome couldn't go into 3rd level before systemd.
3...x. a long list of further problems

I am hopeful that we could make this work. Would anyone be willing to do
analysis like this for multiple updates and play devil's advocate as well?
Ideally trying to see how we could create processes to handle updates of the
last 1-2 years? Because all I could come up with is: we'd end up like Debian,
where stable is...ancient. Not that that is bad in itself if you can pick. 

-- 
Stanislav Ochotnicky <sochotnicky(a)redhat.com&gt;
Software Engineer - Base Operating Systems Brno

PGP: 7B087241
Red Hat Inc.                               http://cz.redhat.com

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jóhann B. Guðmundsson]

On 11/02/2012 10:55 AM, Stanislav Ochotnicky wrote:
>  Quoting Michael Cronenworth (2012-11-01 18:33:24)
> > Adam Williamson wrote:
> >> I didn't want to throw this grenade into the debate, but now someone
> >> else has, I'll just note that I was in favour of this before and I'm
> >> still in favour of it now. :) Rolling release is a model that makes
> >> clear sense for a distribution with the goals that Fedora has.
> > I've wanted to write up a blog post about my plan for a rolling release,
> > but I'll post a snip-it here.
> >
> > Fedora Rawhide - stays as is... it is a rolling release
> >
> > Fedora Feature - think of it as F18 beta right now
> >
> > Fedora Stable - think of it as F16/F17 right now
> >
> > People choose the branch level at install time. Of course, like now,
> > people can override this in the future with a change of fedora-release
> > or yum --releasever. However, per-package updates from another branch
> > level might not be something everyone can agree on how to handle, so it
> > might be wise to limit support of it at first.
> >
> > Workflow:
> > A shiny new feature is introduced in Rawhide. Things go boom. Not many
> > people are hurt by this. Once it has been given a few band-aids the
> > feature could be submitted to Fedora Feature. After some hardening and
> > polishing the feature could finally be pushed to Fedora Stable.
> >
> > I feel this should give a good compromise to everyone's fears of a
> > rolling release. It gives the feature freaks a place in Fedora. It gives
> > the stable stubborns a place in Fedora.
> >
> > I'll wake up from my dream now.
>  I recently came up with similar 3-layer idea. My description was a bit
>  different, something like this:
>  1. level - rawhide-like repository, more or less anything goes
>  2. level - package moves here after maintainer says "this package has been
>              working for me for some time and looks OK. Let's integrate properly
>              with rest of the system".
>  3. level - packages integrated and experience should be splendid :-)
>
>  However let's see how we'd handle systemd change with this system:
>  1. level - Lennart packages systemd, plays around with it. FESCO accepts systemd
>              as worthy FEATURE for future stable (3rd level). Packages interacting
>              with init system can take their time updating.
>  2. level - systemd moves here. After this point, packages moving from 1st level
>              here, will have to support systemd. Experience will likely be shaky
>              for a time, then settle down.
>  3. level - after some time (1 year, 2 years?) systemd moves here and all
>              packages that have been fixed to work with it as well
>
>  There are several problems with this approach though:
>  1. There are always multiple big changes happening in fedora. So even stable
>      would see big updates on relatively frequent basis.
>  2. Several big changes will interact with each other. I.e. Gnome update will
>      contain some daemons so they'd have to integrate with systemd on 2nd level.
>      But then Gnome couldn't go into 3rd level before systemd.
>  3...x. a long list of further problems
>
>  I am hopeful that we could make this work. Would anyone be willing to do
>  analysis like this for multiple updates and play devil's advocate as well?
>  Ideally trying to see how we could create processes to handle updates of the
>  last 1-2 years? Because all I could come up with is: we'd end up like Debian,
>  where stable is...ancient. Not that that is bad in itself if you can pick.
>  
Trust me when I say this we have to fix other processes we have *before* 
we can properly fix the feature process.

Until that is done there is no point in trying to fix the feature process.

JBG

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Josh Boyer]

On Fri, Nov 2, 2012 at 9:03 AM, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com&gt; wrote:
>  Trust me when I say this we have to fix other processes we have *before* we
>  can properly fix the feature process. 
Which?

>  Until that is done there is no point in trying to fix the feature
> process. 
I disagree.  While we might not be able to come to a set-in-stone
perfect process for Features, we can certainly make incremental
improvements to it.  It will never be set-in-stone anyway.  Perfect is
the enemy of good, etc etc.

josh

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jóhann B. Guðmundsson]

On 11/02/2012 01:20 PM, Josh Boyer wrote:
>  On Fri, Nov 2, 2012 at 9:03 AM, "Jóhann B. Guðmundsson"
>  <johannbg(a)gmail.com&gt; wrote:
> > Trust me when I say this we have to fix other processes we have *before* we
> > can properly fix the feature process.
>  Which? 
As soon as an feature depends on other components or several other 
components and their maintainers involvement/participation, then for 
example the unresponsive maintainers policy conflicts with the feature 
process given our relatively short development cycle. ( in general the 
current ownership model works against features that involve more then 
one component )   Another example cleaning up dead/deprecated packages 
which ought to happen at the beginning on new development cycle so 
feature maintainers wont work on dead or unmaintained packages etc...

JBG

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Matthew Miller]

On Fri, Nov 02, 2012 at 02:52:46PM +0000, "Jóhann B. Guðmundsson" wrote:
>  As soon as an feature depends on other components or several other
>  components and their maintainers involvement/participation, then for
>  example the unresponsive maintainers policy conflicts with the
>  feature process given our relatively short development cycle. ( in 
Can you explain that a little more? Do you mean the policy is too slow?

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jóhann B. Guðmundsson]

On 11/02/2012 02:58 PM, Matthew Miller wrote:
>  On Fri, Nov 02, 2012 at 02:52:46PM +0000, "Jóhann B.
> Guðmundsson" wrote:
> > As soon as an feature depends on other components or several other
> > components and their maintainers involvement/participation, then for
> > example the unresponsive maintainers policy conflicts with the
> > feature process given our relatively short development cycle. ( in
>  Can you explain that a little more? Do you mean the policy is too slow?
>  
Dead/un-maintained packages need to be removed/reassigned at the very 
*beginning* of an new development cycle so feature owners and others 
working in the community are dealing with active and actively maintained 
packages.

JBG

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Matthew Miller]

On Fri, Nov 02, 2012 at 03:12:56PM +0000, "Jóhann B. Guðmundsson" wrote:
>  >>As soon as an feature depends on other components or several
> other
>  >>components and their maintainers involvement/participation, then for
>  >>example the unresponsive maintainers policy conflicts with the
>  >>feature process given our relatively short development cycle. ( in
>  >Can you explain that a little more? Do you mean the policy is too slow?
>  Dead/un-maintained packages need to be removed/reassigned at the
>  very *beginning* of an new development cycle so feature owners and
>  others working in the community are dealing with active and actively
>  maintained packages. 
Okay. But I'm having trouble seeing how that's a blocker for incremental
improvement to the features process.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jóhann B. Guðmundsson]

On 11/02/2012 03:32 PM, Matthew Miller wrote:
>  On Fri, Nov 02, 2012 at 03:12:56PM +0000, "Jóhann B.
> Guðmundsson" wrote:
> >>> As soon as an feature depends on other components or several other
> >>> components and their maintainers involvement/participation, then for
> >>> example the unresponsive maintainers policy conflicts with the
> >>> feature process given our relatively short development cycle. ( in
> >> Can you explain that a little more? Do you mean the policy is too slow?
> > Dead/un-maintained packages need to be removed/reassigned at the
> > very *beginning* of an new development cycle so feature owners and
> > others working in the community are dealing with active and actively
> > maintained packages.
>  Okay. But I'm having trouble seeing how that's a blocker for incremental
>  improvement to the features process.
>  
It's pretty apparent that there is no point in working with the feature 
process et all if those issues aren't address first no matter how many 
incremental improvements you make to the process or when you do it for 
that matter.


JBG

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Tom Lane]

=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= <johannbg(a)gmail.com&gt; writes:
>  On 11/02/2012 03:32 PM, Matthew Miller wrote:
> > On Fri, Nov 02, 2012 at 03:12:56PM +0000, "Jóhann B. Guðmundsson" wrote:
> >> Dead/un-maintained packages need to be removed/reassigned at the
> >> very *beginning* of an new development cycle so feature owners and
> >> others working in the community are dealing with active and actively
> >> maintained packages. 
How exactly are you going to force maintainers who go missing to do so
at a prescheduled time?  Real life is seldom that convenient.

			regards, tom lane

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jóhann B. Guðmundsson]

On 11/02/2012 04:25 PM, Tom Lane wrote:
>  =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=
> <johannbg(a)gmail.com&gt; writes:
> > On 11/02/2012 03:32 PM, Matthew Miller wrote:
> >> On Fri, Nov 02, 2012 at 03:12:56PM +0000, "Jóhann B. Guðmundsson"
> wrote:
> >>> Dead/un-maintained packages need to be removed/reassigned at the
> >>> very *beginning* of an new development cycle so feature owners and
> >>> others working in the community are dealing with active and actively
> >>> maintained packages.
>  How exactly are you going to force maintainers who go missing to do so
>  at a prescheduled time?  Real life is seldom that convenient. 
If at this point we dont have any process that can actively tell if a 
maintainer is present and active within the project then we have bigger 
fish to fry then the feature process...

Seriously it should not be anymore complex than monitoring last login 
into the relevant infrastructure pieces to determine if the relevant 
maintainer is active or not.

bash script + a cron job should suffice to achieve just that.

JBG

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Tom Lane]

=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= <johannbg(a)gmail.com&gt; writes:
>  On 11/02/2012 04:25 PM, Tom Lane wrote:
> > How exactly are you going to force maintainers who go missing to do so
> > at a prescheduled time?  Real life is seldom that convenient. 
>  bash script + a cron job should suffice to achieve just that. 
Somehow, we are failing to communicate.

			regards, tom lane

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jon Ciesla]

Indeed.  If someone owns 4 packages that are all stable and have no bug
reports, are they inactive?

-J


On Fri, Nov 2, 2012 at 11:56 AM, Tom Lane <tgl(a)redhat.com&gt; wrote:

>  =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=
> <johannbg(a)gmail.com&gt;
>  writes:
>  > On 11/02/2012 04:25 PM, Tom Lane wrote:
>  >> How exactly are you going to force maintainers who go missing to do so
>  >> at a prescheduled time?  Real life is seldom that convenient.
>
>  > bash script + a cron job should suffice to achieve just that.
>
>  Somehow, we are failing to communicate.
>
>                          regards, tom lane
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel 



-- 
http://cecinestpasunefromage.wordpress.com/
------------------------------------------------
in your fear, seek only peace
in your fear, seek only love

-d. bowie

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jóhann B. Guðmundsson]

On 11/02/2012 04:56 PM, Tom Lane wrote:
> >> >>How exactly are you going to force maintainers who go
> missing to do so
> >> >>at a prescheduled time?  Real life is seldom that convenient.
> > >bash script + a cron job should suffice to achieve just that.
>  Somehow, we are failing to communicate. 
We would not force them to do anything how could we they are awol and 
you do realize that process can be automated even if that just generates 
a list of components that *look* to be unmaintained and then what 
releng? goes through that list of components and takes the next step to 
"orphan" them...

JBG

Revamping the non responsive maintainer process

[Kevin Fenzi]

On Fri, 02 Nov 2012 16:44:06 +0000
"Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt; wrote:

>  On 11/02/2012 04:25 PM, Tom Lane wrote:
>  > =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=
>  > <johannbg(a)gmail.com&gt; writes:
>  >> On 11/02/2012 03:32 PM, Matthew Miller wrote:
>  >>> On Fri, Nov 02, 2012 at 03:12:56PM +0000, "Jóhann B.
>  >>> Guðmundsson" wrote:
>  >>>> Dead/un-maintained packages need to be removed/reassigned at the
>  >>>> very *beginning* of an new development cycle so feature owners
>  >>>> and others working in the community are dealing with active and
>  >>>> actively maintained packages.
>  > How exactly are you going to force maintainers who go missing to do
>  > so at a prescheduled time?  Real life is seldom that convenient.
>  
>  If at this point we dont have any process that can actively tell if a 
>  maintainer is present and active within the project then we have
>  bigger fish to fry then the feature process... 
If we have problem A and problem B, can't we work on both at the same
time? :) 

>  Seriously it should not be anymore complex than monitoring last login
>
>  into the relevant infrastructure pieces to determine if the relevant 
>  maintainer is active or not.
>  
>  bash script + a cron job should suffice to achieve just that. 
It's not at all that simple, I'm afraid. 

How long since last activity do you consider someone 'inactive' ?

What if the packages that maintain simply don't need any changes? 

What if they are on vacation? 

What if they are active on package A, but not doing something on
package B that you wish they would?

I've long wanted to revamp our process. 
I welcome concrete proposals to do so. 

kevin

Revamping the non responsive maintainer process

[Jóhann B. Guðmundsson]

On 11/02/2012 04:56 PM, Kevin Fenzi wrote:
>  On Fri, 02 Nov 2012 16:44:06 +0000
>  "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt; wrote:
>
> > On 11/02/2012 04:25 PM, Tom Lane wrote:
> >> =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=
> >> <johannbg(a)gmail.com&gt; writes:
> >>> On 11/02/2012 03:32 PM, Matthew Miller wrote:
> >>>> On Fri, Nov 02, 2012 at 03:12:56PM +0000, "Jóhann B.
> >>>> Guðmundsson" wrote:
> >>>>> Dead/un-maintained packages need to be removed/reassigned at the
> >>>>> very *beginning* of an new development cycle so feature owners
> >>>>> and others working in the community are dealing with active and
> >>>>> actively maintained packages.
> >> How exactly are you going to force maintainers who go missing to do
> >> so at a prescheduled time?  Real life is seldom that convenient.
> > If at this point we dont have any process that can actively tell if a
> > maintainer is present and active within the project then we have
> > bigger fish to fry then the feature process...
>  If we have problem A and problem B, can't we work on both at the same
>  time? :)
>
> > Seriously it should not be anymore complex than monitoring last login
> > into the relevant infrastructure pieces to determine if the relevant
> > maintainer is active or not.
> >
> > bash script + a cron job should suffice to achieve just that.
>  It's not at all that simple, I'm afraid.
>
>  How long since last activity do you consider someone 'inactive' ?
>
>  What if the packages that maintain simply don't need any changes?
>
>  What if they are on vacation?
>
>  What if they are active on package A, but not doing something on
>  package B that you wish they would?
>
>  I've long wanted to revamp our process.
>  I welcome concrete proposals to do so. 

Surely if an individual has not logged into for several months into our 
infrastructure he must be inactive no?

Bash script + a cron job that monitors login should suffice to check and 
even email him asking him to confirm if he is active encase he has a low 
maintenance component and only logs in when something is filed  ;)

JBG

Revamping the non responsive maintainer process

[Bruno Wolff III]

On Fri, Nov 02, 2012 at 17:57:57 +0000,
   "\"Jóhann B. Guðmundsson\"" <johannbg(a)gmail.com&gt; wrote:
> Surely if an individual has not logged into for several months into 
> our infrastructure he must be inactive no? 
Not necessarily. You can watch things without having to login to 
infrastructure. Unless you need to make changes or respond to bug 
reports there might not be anything to do.

Revamping the non responsive maintainer process

[Jon Ciesla]

On Fri, Nov 2, 2012 at 12:57 PM, "Jóhann B. Guðmundsson" <johannbg(a)gmail.com
>  wrote: 
> On 11/02/2012 04:56 PM, Kevin Fenzi wrote:
>
>> On Fri, 02 Nov 2012 16:44:06 +0000
>> "Jóhann B. Guðmundsson" <johannbg(a)gmail.com
>  wrote: 
>>
>>  On 11/02/2012 04:25 PM, Tom Lane wrote:
>>>
>>>> =?UTF-8?B?**IkrDs2hhbm4gQi4gR3XDsG11bmRzc2**9uIg==?=
>>>> <johannbg(a)gmail.com&gt; writes:
>>>>
>>>>> On 11/02/2012 03:32 PM, Matthew Miller wrote:
>>>>>
>>>>>> On Fri, Nov 02, 2012 at 03:12:56PM +0000, "Jóhann B.
>>>>>> Guðmundsson" wrote:
>>>>>>
>>>>>>> Dead/un-maintained packages need to be removed/reassigned at
the
>>>>>>> very *beginning* of an new development cycle so feature
owners
>>>>>>> and others working in the community are dealing with active
and
>>>>>>> actively maintained packages.
>>>>>>>
>>>>>> How exactly are you going to force maintainers who go missing to
do
>>>> so at a prescheduled time?  Real life is seldom that convenient.
>>>>
>>> If at this point we dont have any process that can actively tell if a
>>> maintainer is present and active within the project then we have
>>> bigger fish to fry then the feature process...
>>>
>> If we have problem A and problem B, can't we work on both at the same
>> time? :)
>>
>>  Seriously it should not be anymore complex than monitoring last login
>>> into the relevant infrastructure pieces to determine if the relevant
>>> maintainer is active or not.
>>>
>>> bash script + a cron job should suffice to achieve just that.
>>>
>> It's not at all that simple, I'm afraid.
>>
>> How long since last activity do you consider someone 'inactive' ?
>>
>> What if the packages that maintain simply don't need any changes?
>>
>> What if they are on vacation?
>>
>> What if they are active on package A, but not doing something on
>> package B that you wish they would?
>>
>> I've long wanted to revamp our process.
>> I welcome concrete proposals to do so.
>>
>
>
> Surely if an individual has not logged into for several months into our
> infrastructure he must be inactive no?
>

No, they might simply have had nothing to do.  Sometimes applications are
stable, have no releases, and have no bugs files against them.

-J


>  Bash script + a cron job that monitors login should suffice to check
> and
>  even email him asking him to confirm if he is active encase he has a low
>  maintenance component and only logs in when something is filed  ;)
>
>  JBG
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>
> https://admin.fedoraproject.**org/mailman/listinfo/devel<https://admin...



-- 
http://cecinestpasunefromage.wordpress.com/
------------------------------------------------
in your fear, seek only peace
in your fear, seek only love

-d. bowie

Revamping the non responsive maintainer process

[Jóhann B. Guðmundsson]

On 11/02/2012 06:05 PM, Jon Ciesla wrote:
>  No, they might simply have had nothing to do.  Sometimes applications 
>  are stable, have no releases, and have no bugs files against them. 
<sigh>

Then those individuals would simply respond to the email that that was 
the case and they are still alive and active within the project and they 
might even have to take an step and simply "login" to prevent them from 
being ping next time the cron-job runs .

Seriously we can just cross that bridge if and when that case happens 
that surely beats doing nothing as things stand now

Have fun bringing up all the hypothetical issue in the world, I however 
got better things to do with my time than trying to convince people that 
is extremely necessary and deal with any hypothetical issue that might 
arise should we try to automate that process...

JBG

Revamping the non responsive maintainer process

[Till Maas]

On Fri, Nov 02, 2012 at 06:12:02PM +0000, "Jóhann B. Guðmundsson" wrote:
>  On 11/02/2012 06:05 PM, Jon Ciesla wrote:
>  >
>  >No, they might simply have had nothing to do.  Sometimes
>  >applications are stable, have no releases, and have no bugs files
>  >against them.
>  
>  <sigh>
>  
>  Then those individuals would simply respond to the email that that
>  was the case and they are still alive and active within the project
>  and they might even have to take an step and simply "login" to
>  prevent them from being ping next time the cron-job runs .
>  
>  Seriously we can just cross that bridge if and when that case
>  happens that surely beats doing nothing as things stand now
>  
>  Have fun bringing up all the hypothetical issue in the world, I
>  however got better things to do with my time than trying to convince
>  people that is extremely necessary and deal with any hypothetical
>  issue that might arise should we try to automate that process... 
The easiest thing to convince people is to propose a concrete proposal
for the time frame and show numbers of how many false positives this
would lead to. Some information about how many packagers were inactive
for how long would be helpful, too. All this information would be easy
to get with the cron job script, which needs to be written anyway.

Regards
Till

Revamping the non responsive maintainer process

[Aleksandar Kurtakov]

----- Original Message -----
>  From: "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt;
>  To: devel(a)lists.fedoraproject.org
>  Sent: Friday, November 2, 2012 7:57:57 PM
>  Subject: Re: Revamping the non responsive maintainer process
>  
>  On 11/02/2012 04:56 PM, Kevin Fenzi wrote:
>  > On Fri, 02 Nov 2012 16:44:06 +0000
>  > "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt; wrote:
>  >
>  >> On 11/02/2012 04:25 PM, Tom Lane wrote:
>  >>> =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=
>  >>> <johannbg(a)gmail.com&gt; writes:
>  >>>> On 11/02/2012 03:32 PM, Matthew Miller wrote:
>  >>>>> On Fri, Nov 02, 2012 at 03:12:56PM +0000, "Jóhann B.
>  >>>>> Guðmundsson" wrote:
>  >>>>>> Dead/un-maintained packages need to be removed/reassigned at
>  >>>>>> the
>  >>>>>> very *beginning* of an new development cycle so feature owners
>  >>>>>> and others working in the community are dealing with active
>  >>>>>> and
>  >>>>>> actively maintained packages.
>  >>> How exactly are you going to force maintainers who go missing to
>  >>> do
>  >>> so at a prescheduled time?  Real life is seldom that convenient.
>  >> If at this point we dont have any process that can actively tell
>  >> if a
>  >> maintainer is present and active within the project then we have
>  >> bigger fish to fry then the feature process...
>  > If we have problem A and problem B, can't we work on both at the
>  > same
>  > time? :)
>  >
>  >> Seriously it should not be anymore complex than monitoring last
>  >> login
>  >> into the relevant infrastructure pieces to determine if the
>  >> relevant
>  >> maintainer is active or not.
>  >>
>  >> bash script + a cron job should suffice to achieve just that.
>  > It's not at all that simple, I'm afraid.
>  >
>  > How long since last activity do you consider someone 'inactive' ?
>  >
>  > What if the packages that maintain simply don't need any changes?
>  >
>  > What if they are on vacation?
>  >
>  > What if they are active on package A, but not doing something on
>  > package B that you wish they would?
>  >
>  > I've long wanted to revamp our process.
>  > I welcome concrete proposals to do so.
>  
>  
>  Surely if an individual has not logged into for several months into
>  our
>  infrastructure he must be inactive no? 
Wrong. Do you know how few of the problems we see in Eclipse land don't need fixes
upstreams? And some of these issues require man/months (years sometimes) upstream before
there is smth to show in Fedora. Don't make your assumptions based on that. So if one
logs in every few months to take a look at the number of bugs (nothing more) he is active
but one that does fixes upstream for months before putting into Fedora is not. You see
there is no black and white here! 
Plus, did you intentionally skipped the part about being active on A but not on B ? So if
one does a good job of maintaining 9 packages but doesn't do it for 1 because he/she
is overloaded we should dump him? And please don't tell me that a good maintainer
would not do that because many of us don't know the count(not the names) of the things
they are responsible for so it's more than easier for a component to goes unnoticed.
All of this was to show that whatever policy might be chosen it should be PER
PROJECT/PACKAGE not per maintainer. Do you know what happens when someone as I described
is currently overloaded and one dares to start the inactive maintainer procedure for him?
I can tell you - for one unmaintained package, we lose a number of others that he/she
maintained in a decent state. 
There was such a case recently for an on and off contributor who did *a lot* in the years,
so when we say we want to learn from mistakes let's not do it by making bigger ones.

Alexander Kurtakov
Red Hat Eclipse team

>  
>  Bash script + a cron job that monitors login should suffice to check
>  and
>  even email him asking him to confirm if he is active encase he has a
>  low
>  maintenance component and only logs in when something is filed  ;)
>  
>  JBG
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

Revamping the non responsive maintainer process

[Jóhann B. Guðmundsson]

On 11/02/2012 06:27 PM, Aleksandar Kurtakov wrote:
>  Wrong. Do you know how few of the problems we see in Eclipse land
> don't need fixes upstreams? And some of these issues require man/months (years
> sometimes) upstream before there is smth to show in Fedora. Don't make your
> assumptions based on that. So if one logs in every few months to take a look at the number
> of bugs (nothing more) he is active but one that does fixes upstream for months before
> putting into Fedora is not. You see there is no black and white here! 
Then that individual would simply log in or perform some other action to 
get him off that list...

>  Plus, did you intentionally skipped the part about being active on A
> but not on B ? So if one does a good job of maintaining 9 packages but doesn't do it
> for 1 because he/she is overloaded we should dump him? And please don't tell me that a
> good maintainer would not do that because many of us don't know the count(not the
> names) of the things they are responsible for so it's more than easier for a component
> to goes unnoticed. 
No I simply assumed that he would have logged in to fiddle with one or 
more packages he owns and or is responsible for which would clearly mark 
him *active*.

I know my English sucks on a good day but i thought it was clear I was 
speaking of checking logins in our infrastructure not *packages* or 
number of packages* maintainer might maintain since that's totally 
irrelevant and just brings unnecessary complication to the equation from 
my pov...

Instead of people constant bringing up hypothetical solution while we 
have plethora of unmaintained rotten packages in our repos why dont you 
try to come up with or propose an alternative solution to the problem at 
hand...

JBG

Revamping the non responsive maintainer process

[Aleksandar Kurtakov]

----- Original Message -----
>  From: "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt;
>  To: devel(a)lists.fedoraproject.org
>  Sent: Friday, November 2, 2012 9:20:05 PM
>  Subject: Re: Revamping the non responsive maintainer process
>  
>  On 11/02/2012 06:27 PM, Aleksandar Kurtakov wrote:
>  > Wrong. Do you know how few of the problems we see in Eclipse land
>  > don't need fixes upstreams? And some of these issues require
>  > man/months (years sometimes) upstream before there is smth to show
>  > in Fedora. Don't make your assumptions based on that. So if one
>  > logs in every few months to take a look at the number of bugs
>  > (nothing more) he is active but one that does fixes upstream for
>  > months before putting into Fedora is not. You see there is no
>  > black and white here!
>  
>  Then that individual would simply log in or perform some other action
>  to
>  get him off that list...
>  
>  > Plus, did you intentionally skipped the part about being active on
>  > A but not on B ? So if one does a good job of maintaining 9
>  > packages but doesn't do it for 1 because he/she is overloaded we
>  > should dump him? And please don't tell me that a good maintainer
>  > would not do that because many of us don't know the count(not the
>  > names) of the things they are responsible for so it's more than
>  > easier for a component to goes unnoticed.
>  
>  No I simply assumed that he would have logged in to fiddle with one
>  or
>  more packages he owns and or is responsible for which would clearly
>  mark
>  him *active*.
>  
>  I know my English sucks on a good day but i thought it was clear I
>  was
>  speaking of checking logins in our infrastructure not *packages* or
>  number of packages* maintainer might maintain since that's totally
>  irrelevant and just brings unnecessary complication to the equation
>  from
>  my pov...
>  
>  Instead of people constant bringing up hypothetical solution while we
>  have plethora of unmaintained rotten packages in our repos why dont
>  you
>  try to come up with or propose an alternative solution to the problem
>  at
>  hand... 
I already wrote it:

All of this was to show that whatever policy might be chosen it should be PER
PROJECT/PACKAGE not per maintainer.

The whole idea of non-responsive maintainer is nonsense. A person that does one thing in a
year is still more valuable than a hundred of freeloaders - because he/she actually did
one thing. We ship packages so every action should be per package and not per person! 

Alexander Kurtakov
Red Hat Eclipse team



>  
>  JBG
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

Revamping the non responsive maintainer process

[Chris Adams]

Once upon a time, "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt; said:
>  Surely if an individual has not logged into for several months into
> our 
>  infrastructure he must be inactive no? 
I maintain just a couple of low-overhead packages, and I haven't changed
either in a couple of years.  The only time I've logged into any of the
Fedora servers in that time has been related to mirror management (and
that is pretty rare as well).

And (because I'm a lazy email reader) I post here from a different email
address than my Fedora-registered one.
-- 
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.

Revamping the non responsive maintainer process

[Marcela Mašláňová]

On 11/02/2012 06:57 PM, "Jóhann B. Guðmundsson" wrote:
>  On 11/02/2012 04:56 PM, Kevin Fenzi wrote:
> > On Fri, 02 Nov 2012 16:44:06 +0000
> > "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt; wrote:
> >
> >> On 11/02/2012 04:25 PM, Tom Lane wrote:
> >>> =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=
> >>> <johannbg(a)gmail.com&gt; writes:
> >>>> On 11/02/2012 03:32 PM, Matthew Miller wrote:
> >>>>> On Fri, Nov 02, 2012 at 03:12:56PM +0000, "Jóhann B.
> >>>>> Guðmundsson" wrote:
> >>>>>> Dead/un-maintained packages need to be removed/reassigned at the
> >>>>>> very *beginning* of an new development cycle so feature owners
> >>>>>> and others working in the community are dealing with active and
> >>>>>> actively maintained packages.
> >>> How exactly are you going to force maintainers who go missing to do
> >>> so at a prescheduled time?  Real life is seldom that convenient.
> >> If at this point we dont have any process that can actively tell if a
> >> maintainer is present and active within the project then we have
> >> bigger fish to fry then the feature process...
> > If we have problem A and problem B, can't we work on both at the same
> > time? :)
> >
> >> Seriously it should not be anymore complex than monitoring last login
> >> into the relevant infrastructure pieces to determine if the relevant
> >> maintainer is active or not.
> >>
> >> bash script + a cron job should suffice to achieve just that.
> > It's not at all that simple, I'm afraid.
> >
> > How long since last activity do you consider someone 'inactive' ?
> >
> > What if the packages that maintain simply don't need any changes?
> >
> > What if they are on vacation?
> >
> > What if they are active on package A, but not doing something on
> > package B that you wish they would?
> >
> > I've long wanted to revamp our process.
> > I welcome concrete proposals to do so.
>
>
>  Surely if an individual has not logged into for several months into our
>  infrastructure he must be inactive no?
>
>  Bash script + a cron job that monitors login should suffice to check and
>  even email him asking him to confirm if he is active encase he has a low
>  maintenance component and only logs in when something is filed  ;)
>
>  JBG 
No, he can own only one package and be an upstream of the package, 
therefore he will login only for update of the package.

You are using your use-case for everyone. If you insist on automatic 
process, then the metric should work with more data.

Marcela

Revamping the non responsive maintainer process

[Jóhann B. Guðmundsson]

On 11/05/2012 09:22 AM, Marcela Mašláňová wrote:
>  You are using your use-case for everyone. If you insist on automatic
>
>  process, then the metric should work with more data.  
It's good that we elected FESCO to find out and decide which appropriate 
metric data should be used to determine that...

JBG

Revamping the non responsive maintainer process

[Vít Ondruch]

Dne 5.11.2012 10:22, Marcela Mašláňová napsal(a):
>  On 11/02/2012 06:57 PM, "Jóhann B. Guðmundsson" wrote:
> > On 11/02/2012 04:56 PM, Kevin Fenzi wrote:
> >> On Fri, 02 Nov 2012 16:44:06 +0000
> >> "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt; wrote:
> >>
> >>> On 11/02/2012 04:25 PM, Tom Lane wrote:
> >>>> =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=
> >>>> <johannbg(a)gmail.com&gt; writes:
> >>>>> On 11/02/2012 03:32 PM, Matthew Miller wrote:
> >>>>>> On Fri, Nov 02, 2012 at 03:12:56PM +0000, "Jóhann B.
> >>>>>> Guðmundsson" wrote:
> >>>>>>> Dead/un-maintained packages need to be removed/reassigned at
> the
> >>>>>>> very *beginning* of an new development cycle so feature
> owners
> >>>>>>> and others working in the community are dealing with active
> and
> >>>>>>> actively maintained packages.
> >>>> How exactly are you going to force maintainers who go missing to do
> >>>> so at a prescheduled time?  Real life is seldom that convenient.
> >>> If at this point we dont have any process that can actively tell if a
> >>> maintainer is present and active within the project then we have
> >>> bigger fish to fry then the feature process...
> >> If we have problem A and problem B, can't we work on both at the same
> >> time? :)
> >>
> >>> Seriously it should not be anymore complex than monitoring last login
> >>> into the relevant infrastructure pieces to determine if the relevant
> >>> maintainer is active or not.
> >>>
> >>> bash script + a cron job should suffice to achieve just that.
> >> It's not at all that simple, I'm afraid.
> >>
> >> How long since last activity do you consider someone 'inactive' ?
> >>
> >> What if the packages that maintain simply don't need any changes?
> >>
> >> What if they are on vacation?
> >>
> >> What if they are active on package A, but not doing something on
> >> package B that you wish they would?
> >>
> >> I've long wanted to revamp our process.
> >> I welcome concrete proposals to do so.
> >
> >
> > Surely if an individual has not logged into for several months into our
> > infrastructure he must be inactive no?
> >
> > Bash script + a cron job that monitors login should suffice to check and
> > even email him asking him to confirm if he is active encase he has a low
> > maintenance component and only logs in when something is filed ;)
> >
> > JBG
>
>  No, he can own only one package and be an upstream of the package, 
>  therefore he will login only for update of the package.
>
>  You are using your use-case for everyone. If you insist on automatic 
>  process, then the metric should work with more data.
>
>  Marcela 
Requiring action every 6 months, such as pressing button "Yes, I am 
still alive and kicking" in FAS after you are nagged by email, would be 
acceptable annoyance even for such package maintainers, wouldn't be?

And there is such script, which is checking user activity on several 
places: https://github.com/pypingou/fedora-active-user

Vit

Revamping the non responsive maintainer process

[Aleksandar Kurtakov]

Where is the community spirit? What went wrong with fedora community? Why on earth do you
people insist on tracking people activity and not try detecting unmaintained packages?
Detecting unmaintained packages is even easier and has clearer metrics. 

Really, why noone wants people that are ready to do one thing in a year? Are many people
here feeling superior than the rest of the world and think there is no need for further
contributions and they can do everything alone ? I'm starting to be really worried for
the path Fedora is going.

Alexander Kurtakov
Red Hat Eclipse team

----- Original Message -----
>  From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
>  To: devel(a)lists.fedoraproject.org
>  Sent: Tuesday, November 6, 2012 10:28:11 AM
>  Subject: Re: Revamping the non responsive maintainer process
>  
>  Dne 5.11.2012 10:22, Marcela Mašláňová napsal(a):
>  > On 11/02/2012 06:57 PM, "Jóhann B. Guðmundsson" wrote:
>  >> On 11/02/2012 04:56 PM, Kevin Fenzi wrote:
>  >>> On Fri, 02 Nov 2012 16:44:06 +0000
>  >>> "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt; wrote:
>  >>>
>  >>>> On 11/02/2012 04:25 PM, Tom Lane wrote:
>  >>>>> =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=
>  >>>>> <johannbg(a)gmail.com&gt; writes:
>  >>>>>> On 11/02/2012 03:32 PM, Matthew Miller wrote:
>  >>>>>>> On Fri, Nov 02, 2012 at 03:12:56PM +0000, "Jóhann B.
>  >>>>>>> Guðmundsson" wrote:
>  >>>>>>>> Dead/un-maintained packages need to be
> removed/reassigned at
>  >>>>>>>> the
>  >>>>>>>> very *beginning* of an new development cycle so feature
>  >>>>>>>> owners
>  >>>>>>>> and others working in the community are dealing with
> active
>  >>>>>>>> and
>  >>>>>>>> actively maintained packages.
>  >>>>> How exactly are you going to force maintainers who go missing
>  >>>>> to do
>  >>>>> so at a prescheduled time?  Real life is seldom that
>  >>>>> convenient.
>  >>>> If at this point we dont have any process that can actively tell
>  >>>> if a
>  >>>> maintainer is present and active within the project then we have
>  >>>> bigger fish to fry then the feature process...
>  >>> If we have problem A and problem B, can't we work on both at the
>  >>> same
>  >>> time? :)
>  >>>
>  >>>> Seriously it should not be anymore complex than monitoring last
>  >>>> login
>  >>>> into the relevant infrastructure pieces to determine if the
>  >>>> relevant
>  >>>> maintainer is active or not.
>  >>>>
>  >>>> bash script + a cron job should suffice to achieve just that.
>  >>> It's not at all that simple, I'm afraid.
>  >>>
>  >>> How long since last activity do you consider someone 'inactive' ?
>  >>>
>  >>> What if the packages that maintain simply don't need any changes?
>  >>>
>  >>> What if they are on vacation?
>  >>>
>  >>> What if they are active on package A, but not doing something on
>  >>> package B that you wish they would?
>  >>>
>  >>> I've long wanted to revamp our process.
>  >>> I welcome concrete proposals to do so.
>  >>
>  >>
>  >> Surely if an individual has not logged into for several months
>  >> into our
>  >> infrastructure he must be inactive no?
>  >>
>  >> Bash script + a cron job that monitors login should suffice to
>  >> check and
>  >> even email him asking him to confirm if he is active encase he has
>  >> a low
>  >> maintenance component and only logs in when something is filed ;)
>  >>
>  >> JBG
>  >
>  > No, he can own only one package and be an upstream of the package,
>  > therefore he will login only for update of the package.
>  >
>  > You are using your use-case for everyone. If you insist on
>  > automatic
>  > process, then the metric should work with more data.
>  >
>  > Marcela
>  
>  Requiring action every 6 months, such as pressing button "Yes, I am
>  still alive and kicking" in FAS after you are nagged by email, would
>  be
>  acceptable annoyance even for such package maintainers, wouldn't be?
>  
>  And there is such script, which is checking user activity on several
>  places: https://github.com/pypingou/fedora-active-user
>  
>  Vit
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

Revamping the non responsive maintainer process

[Vít Ondruch]

I don't know what are you reading in my response, but I definitely did 
not propose anything like "noone wants people that are ready to do one 
thing in a year".

Vit



Dne 6.11.2012 09:52, Aleksandar Kurtakov napsal(a):
>  Where is the community spirit? What went wrong with fedora community?
> Why on earth do you people insist on tracking people activity and not try detecting
> unmaintained packages?
>  Detecting unmaintained packages is even easier and has clearer metrics.
>
>  Really, why noone wants people that are ready to do one thing in a year? Are many people
> here feeling superior than the rest of the world and think there is no need for further
> contributions and they can do everything alone ? I'm starting to be really worried for
> the path Fedora is going.
>
>  Alexander Kurtakov
>  Red Hat Eclipse team
>
>  ----- Original Message -----
> > From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
> > To: devel(a)lists.fedoraproject.org
> > Sent: Tuesday, November 6, 2012 10:28:11 AM
> > Subject: Re: Revamping the non responsive maintainer process
> >
> > Dne 5.11.2012 10:22, Marcela Mašláňová napsal(a):
> >> On 11/02/2012 06:57 PM, "Jóhann B. Guðmundsson" wrote:
> >>> On 11/02/2012 04:56 PM, Kevin Fenzi wrote:
> >>>> On Fri, 02 Nov 2012 16:44:06 +0000
> >>>> "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt; wrote:
> >>>>
> >>>>> On 11/02/2012 04:25 PM, Tom Lane wrote:
> >>>>>> =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=
> >>>>>> <johannbg(a)gmail.com&gt; writes:
> >>>>>>> On 11/02/2012 03:32 PM, Matthew Miller wrote:
> >>>>>>>> On Fri, Nov 02, 2012 at 03:12:56PM +0000, "Jóhann
> B.
> >>>>>>>> Guðmundsson" wrote:
> >>>>>>>>> Dead/un-maintained packages need to be
> removed/reassigned at
> >>>>>>>>> the
> >>>>>>>>> very *beginning* of an new development cycle so
> feature
> >>>>>>>>> owners
> >>>>>>>>> and others working in the community are dealing with
> active
> >>>>>>>>> and
> >>>>>>>>> actively maintained packages.
> >>>>>> How exactly are you going to force maintainers who go missing
> >>>>>> to do
> >>>>>> so at a prescheduled time?  Real life is seldom that
> >>>>>> convenient.
> >>>>> If at this point we dont have any process that can actively tell
> >>>>> if a
> >>>>> maintainer is present and active within the project then we have
> >>>>> bigger fish to fry then the feature process...
> >>>> If we have problem A and problem B, can't we work on both at the
> >>>> same
> >>>> time? :)
> >>>>
> >>>>> Seriously it should not be anymore complex than monitoring last
> >>>>> login
> >>>>> into the relevant infrastructure pieces to determine if the
> >>>>> relevant
> >>>>> maintainer is active or not.
> >>>>>
> >>>>> bash script + a cron job should suffice to achieve just that.
> >>>> It's not at all that simple, I'm afraid.
> >>>>
> >>>> How long since last activity do you consider someone 'inactive'
> ?
> >>>>
> >>>> What if the packages that maintain simply don't need any changes?
> >>>>
> >>>> What if they are on vacation?
> >>>>
> >>>> What if they are active on package A, but not doing something on
> >>>> package B that you wish they would?
> >>>>
> >>>> I've long wanted to revamp our process.
> >>>> I welcome concrete proposals to do so.
> >>>
> >>> Surely if an individual has not logged into for several months
> >>> into our
> >>> infrastructure he must be inactive no?
> >>>
> >>> Bash script + a cron job that monitors login should suffice to
> >>> check and
> >>> even email him asking him to confirm if he is active encase he has
> >>> a low
> >>> maintenance component and only logs in when something is filed ;)
> >>>
> >>> JBG
> >> No, he can own only one package and be an upstream of the package,
> >> therefore he will login only for update of the package.
> >>
> >> You are using your use-case for everyone. If you insist on
> >> automatic
> >> process, then the metric should work with more data.
> >>
> >> Marcela
> > Requiring action every 6 months, such as pressing button "Yes, I am
> > still alive and kicking" in FAS after you are nagged by email, would
> > be
> > acceptable annoyance even for such package maintainers, wouldn't be?
> >
> > And there is such script, which is checking user activity on several
> > places: https://github.com/pypingou/fedora-active-user
> >
> > Vit
> > --
> > devel mailing list
> > devel(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/devel

Revamping the non responsive maintainer process

[Aleksandar Kurtakov]

It's the whole thread that implies that not your mail only. 
No one managed to explain why there should be actions against people instead of packages.
I would be really thankful if someone explains how he can getter better measurement of
people activity than of package maintenance problems and what is the benefit of tracking
persons activity - it's not a competition it's supposed to be a collaboration and
every should do as much as he can and wants.

Alexander Kurtakov
Red Hat Eclipse team

----- Original Message -----
>  From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
>  To: devel(a)lists.fedoraproject.org
>  Sent: Tuesday, November 6, 2012 12:55:27 PM
>  Subject: Re: Revamping the non responsive maintainer process
>  
>  I don't know what are you reading in my response, but I definitely
>  did
>  not propose anything like "noone wants people that are ready to do
>  one
>  thing in a year".
>  
>  Vit
>  
>  
>  
>  Dne 6.11.2012 09:52, Aleksandar Kurtakov napsal(a):
>  > Where is the community spirit? What went wrong with fedora
>  > community? Why on earth do you people insist on tracking people
>  > activity and not try detecting unmaintained packages?
>  > Detecting unmaintained packages is even easier and has clearer
>  > metrics.
>  >
>  > Really, why noone wants people that are ready to do one thing in a
>  > year? Are many people here feeling superior than the rest of the
>  > world and think there is no need for further contributions and
>  > they can do everything alone ? I'm starting to be really worried
>  > for the path Fedora is going.
>  >
>  > Alexander Kurtakov
>  > Red Hat Eclipse team
>  >
>  > ----- Original Message -----
>  >> From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
>  >> To: devel(a)lists.fedoraproject.org
>  >> Sent: Tuesday, November 6, 2012 10:28:11 AM
>  >> Subject: Re: Revamping the non responsive maintainer process
>  >>
>  >> Dne 5.11.2012 10:22, Marcela Mašláňová napsal(a):
>  >>> On 11/02/2012 06:57 PM, "Jóhann B. Guðmundsson" wrote:
>  >>>> On 11/02/2012 04:56 PM, Kevin Fenzi wrote:
>  >>>>> On Fri, 02 Nov 2012 16:44:06 +0000
>  >>>>> "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt; wrote:
>  >>>>>
>  >>>>>> On 11/02/2012 04:25 PM, Tom Lane wrote:
>  >>>>>>> =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=
>  >>>>>>> <johannbg(a)gmail.com&gt; writes:
>  >>>>>>>> On 11/02/2012 03:32 PM, Matthew Miller wrote:
>  >>>>>>>>> On Fri, Nov 02, 2012 at 03:12:56PM +0000,
> "Jóhann B.
>  >>>>>>>>> Guðmundsson" wrote:
>  >>>>>>>>>> Dead/un-maintained packages need to be
> removed/reassigned
>  >>>>>>>>>> at
>  >>>>>>>>>> the
>  >>>>>>>>>> very *beginning* of an new development cycle so
> feature
>  >>>>>>>>>> owners
>  >>>>>>>>>> and others working in the community are dealing
> with
>  >>>>>>>>>> active
>  >>>>>>>>>> and
>  >>>>>>>>>> actively maintained packages.
>  >>>>>>> How exactly are you going to force maintainers who go
> missing
>  >>>>>>> to do
>  >>>>>>> so at a prescheduled time?  Real life is seldom that
>  >>>>>>> convenient.
>  >>>>>> If at this point we dont have any process that can actively
>  >>>>>> tell
>  >>>>>> if a
>  >>>>>> maintainer is present and active within the project then we
>  >>>>>> have
>  >>>>>> bigger fish to fry then the feature process...
>  >>>>> If we have problem A and problem B, can't we work on both at
>  >>>>> the
>  >>>>> same
>  >>>>> time? :)
>  >>>>>
>  >>>>>> Seriously it should not be anymore complex than monitoring
>  >>>>>> last
>  >>>>>> login
>  >>>>>> into the relevant infrastructure pieces to determine if the
>  >>>>>> relevant
>  >>>>>> maintainer is active or not.
>  >>>>>>
>  >>>>>> bash script + a cron job should suffice to achieve just that.
>  >>>>> It's not at all that simple, I'm afraid.
>  >>>>>
>  >>>>> How long since last activity do you consider someone
> 'inactive'
>  >>>>> ?
>  >>>>>
>  >>>>> What if the packages that maintain simply don't need any
>  >>>>> changes?
>  >>>>>
>  >>>>> What if they are on vacation?
>  >>>>>
>  >>>>> What if they are active on package A, but not doing something
>  >>>>> on
>  >>>>> package B that you wish they would?
>  >>>>>
>  >>>>> I've long wanted to revamp our process.
>  >>>>> I welcome concrete proposals to do so.
>  >>>>
>  >>>> Surely if an individual has not logged into for several months
>  >>>> into our
>  >>>> infrastructure he must be inactive no?
>  >>>>
>  >>>> Bash script + a cron job that monitors login should suffice to
>  >>>> check and
>  >>>> even email him asking him to confirm if he is active encase he
>  >>>> has
>  >>>> a low
>  >>>> maintenance component and only logs in when something is filed
>  >>>> ;)
>  >>>>
>  >>>> JBG
>  >>> No, he can own only one package and be an upstream of the
>  >>> package,
>  >>> therefore he will login only for update of the package.
>  >>>
>  >>> You are using your use-case for everyone. If you insist on
>  >>> automatic
>  >>> process, then the metric should work with more data.
>  >>>
>  >>> Marcela
>  >> Requiring action every 6 months, such as pressing button "Yes, I
>  >> am
>  >> still alive and kicking" in FAS after you are nagged by email,
>  >> would
>  >> be
>  >> acceptable annoyance even for such package maintainers, wouldn't
>  >> be?
>  >>
>  >> And there is such script, which is checking user activity on
>  >> several
>  >> places: https://github.com/pypingou/fedora-active-user
>  >>
>  >> Vit
>  >> --
>  >> devel mailing list
>  >> devel(a)lists.fedoraproject.org
>  >> https://admin.fedoraproject.org/mailman/listinfo/devel
>  
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

Revamping the non responsive maintainer process

[Marcela Mašláňová]

I agree. I'd rather give people permission to co-maintain package, then 
push them out of community. I'm afraid we can only loose maintainers by 
measurements of activity.

Marcela

On 11/06/2012 12:10 PM, Aleksandar Kurtakov wrote:
>  It's the whole thread that implies that not your mail only.
>  No one managed to explain why there should be actions against people instead of packages.
> I would be really thankful if someone explains how he can getter better measurement of
> people activity than of package maintenance problems and what is the benefit of tracking
> persons activity - it's not a competition it's supposed to be a collaboration and
> every should do as much as he can and wants.
>
>  Alexander Kurtakov
>  Red Hat Eclipse team
>
>  ----- Original Message -----
> > From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
> > To: devel(a)lists.fedoraproject.org
> > Sent: Tuesday, November 6, 2012 12:55:27 PM
> > Subject: Re: Revamping the non responsive maintainer process
> >
> > I don't know what are you reading in my response, but I definitely
> > did
> > not propose anything like "noone wants people that are ready to do
> > one
> > thing in a year".
> >
> > Vit
> >
> >
> >
> > Dne 6.11.2012 09:52, Aleksandar Kurtakov napsal(a):
> >> Where is the community spirit? What went wrong with fedora
> >> community? Why on earth do you people insist on tracking people
> >> activity and not try detecting unmaintained packages?
> >> Detecting unmaintained packages is even easier and has clearer
> >> metrics.
> >>
> >> Really, why noone wants people that are ready to do one thing in a
> >> year? Are many people here feeling superior than the rest of the
> >> world and think there is no need for further contributions and
> >> they can do everything alone ? I'm starting to be really worried
> >> for the path Fedora is going.
> >>
> >> Alexander Kurtakov
> >> Red Hat Eclipse team
> >>
> >> ----- Original Message -----
> >>> From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
> >>> To: devel(a)lists.fedoraproject.org
> >>> Sent: Tuesday, November 6, 2012 10:28:11 AM
> >>> Subject: Re: Revamping the non responsive maintainer process
> >>>
> >>> Dne 5.11.2012 10:22, Marcela Mašláňová napsal(a):
> >>>> On 11/02/2012 06:57 PM, "Jóhann B. Guðmundsson" wrote:
> >>>>> On 11/02/2012 04:56 PM, Kevin Fenzi wrote:
> >>>>>> On Fri, 02 Nov 2012 16:44:06 +0000
> >>>>>> "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt;
> wrote:
> >>>>>>
> >>>>>>> On 11/02/2012 04:25 PM, Tom Lane wrote:
> >>>>>>>> =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=
> >>>>>>>> <johannbg(a)gmail.com&gt; writes:
> >>>>>>>>> On 11/02/2012 03:32 PM, Matthew Miller wrote:
> >>>>>>>>>> On Fri, Nov 02, 2012 at 03:12:56PM +0000,
> "Jóhann B.
> >>>>>>>>>> Guðmundsson" wrote:
> >>>>>>>>>>> Dead/un-maintained packages need to be
> removed/reassigned
> >>>>>>>>>>> at
> >>>>>>>>>>> the
> >>>>>>>>>>> very *beginning* of an new development cycle
> so feature
> >>>>>>>>>>> owners
> >>>>>>>>>>> and others working in the community are
> dealing with
> >>>>>>>>>>> active
> >>>>>>>>>>> and
> >>>>>>>>>>> actively maintained packages.
> >>>>>>>> How exactly are you going to force maintainers who go
> missing
> >>>>>>>> to do
> >>>>>>>> so at a prescheduled time?  Real life is seldom that
> >>>>>>>> convenient.
> >>>>>>> If at this point we dont have any process that can actively
> >>>>>>> tell
> >>>>>>> if a
> >>>>>>> maintainer is present and active within the project then we
> >>>>>>> have
> >>>>>>> bigger fish to fry then the feature process...
> >>>>>> If we have problem A and problem B, can't we work on both at
> >>>>>> the
> >>>>>> same
> >>>>>> time? :)
> >>>>>>
> >>>>>>> Seriously it should not be anymore complex than monitoring
> >>>>>>> last
> >>>>>>> login
> >>>>>>> into the relevant infrastructure pieces to determine if the
> >>>>>>> relevant
> >>>>>>> maintainer is active or not.
> >>>>>>>
> >>>>>>> bash script + a cron job should suffice to achieve just
> that.
> >>>>>> It's not at all that simple, I'm afraid.
> >>>>>>
> >>>>>> How long since last activity do you consider someone
> 'inactive'
> >>>>>> ?
> >>>>>>
> >>>>>> What if the packages that maintain simply don't need any
> >>>>>> changes?
> >>>>>>
> >>>>>> What if they are on vacation?
> >>>>>>
> >>>>>> What if they are active on package A, but not doing something
> >>>>>> on
> >>>>>> package B that you wish they would?
> >>>>>>
> >>>>>> I've long wanted to revamp our process.
> >>>>>> I welcome concrete proposals to do so.
> >>>>>
> >>>>> Surely if an individual has not logged into for several months
> >>>>> into our
> >>>>> infrastructure he must be inactive no?
> >>>>>
> >>>>> Bash script + a cron job that monitors login should suffice to
> >>>>> check and
> >>>>> even email him asking him to confirm if he is active encase he
> >>>>> has
> >>>>> a low
> >>>>> maintenance component and only logs in when something is filed
> >>>>> ;)
> >>>>>
> >>>>> JBG
> >>>> No, he can own only one package and be an upstream of the
> >>>> package,
> >>>> therefore he will login only for update of the package.
> >>>>
> >>>> You are using your use-case for everyone. If you insist on
> >>>> automatic
> >>>> process, then the metric should work with more data.
> >>>>
> >>>> Marcela
> >>> Requiring action every 6 months, such as pressing button "Yes, I
> >>> am
> >>> still alive and kicking" in FAS after you are nagged by email,
> >>> would
> >>> be
> >>> acceptable annoyance even for such package maintainers, wouldn't
> >>> be?
> >>>
> >>> And there is such script, which is checking user activity on
> >>> several
> >>> places: https://github.com/pypingou/fedora-active-user
> >>>
> >>> Vit
> >>> --
> >>> devel mailing list
> >>> devel(a)lists.fedoraproject.org
> >>> https://admin.fedoraproject.org/mailman/listinfo/devel
> >
> > --
> > devel mailing list
> > devel(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/devel 

-- 
Marcela Mašláňová
BaseOS team Brno

Revamping the non responsive maintainer process

[Jóhann B. Guðmundsson]

Is it really that hard for you people to follow our mailing list 
guidelines[1]?

JBG

1.https://fedoraproject.org/wiki/Mailing_list_guidelines#If_You_Are_Reply...

Revamping the non responsive maintainer process

[Vít Ondruch]

So give me the permission [1] as well as the others who requested it 
before me.

Apparently the current owner doesn't care. You can compare the version 
history in koji [2] and [3] and if he doesn't care about one package, it 
is reasonable to doubt that the other packages will be in better state.

And please don't tell me about nonresponsive maintainer policy, if you 
want to speak about community and collaboration [4].


Vit


[1] https://admin.fedoraproject.org/pkgdb/acls/name/rubygem-json
[2] http://koji.fedoraproject.org/koji/packageinfo?packageID=9017
[3] https://rubygems.org/gems/json/versions
[4] https://bugzilla.redhat.com/show_bug.cgi?id=620436



Dne 6.11.2012 12:58, Marcela Mašláňová napsal(a):
>  I agree. I'd rather give people permission to co-maintain
> package, 
>  then push them out of community. I'm afraid we can only loose 
>  maintainers by measurements of activity.
>
>  Marcela
>
>  On 11/06/2012 12:10 PM, Aleksandar Kurtakov wrote:
> > It's the whole thread that implies that not your mail only.
> > No one managed to explain why there should be actions against people 
> > instead of packages. I would be really thankful if someone explains 
> > how he can getter better measurement of people activity than of 
> > package maintenance problems and what is the benefit of tracking 
> > persons activity - it's not a competition it's supposed to be a 
> > collaboration and every should do as much as he can and wants.
> >
> > Alexander Kurtakov
> > Red Hat Eclipse team
> >
> > ----- Original Message -----
> >> From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
> >> To: devel(a)lists.fedoraproject.org
> >> Sent: Tuesday, November 6, 2012 12:55:27 PM
> >> Subject: Re: Revamping the non responsive maintainer process
> >>
> >> I don't know what are you reading in my response, but I definitely
> >> did
> >> not propose anything like "noone wants people that are ready to do
> >> one
> >> thing in a year".
> >>
> >> Vit
> >>
> >>
> >>
> >> Dne 6.11.2012 09:52, Aleksandar Kurtakov napsal(a):
> >>> Where is the community spirit? What went wrong with fedora
> >>> community? Why on earth do you people insist on tracking people
> >>> activity and not try detecting unmaintained packages?
> >>> Detecting unmaintained packages is even easier and has clearer
> >>> metrics.
> >>>
> >>> Really, why noone wants people that are ready to do one thing in a
> >>> year? Are many people here feeling superior than the rest of the
> >>> world and think there is no need for further contributions and
> >>> they can do everything alone ? I'm starting to be really worried
> >>> for the path Fedora is going.
> >>>
> >>> Alexander Kurtakov
> >>> Red Hat Eclipse team
> >>>
> >>> ----- Original Message -----
> >>>> From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
> >>>> To: devel(a)lists.fedoraproject.org
> >>>> Sent: Tuesday, November 6, 2012 10:28:11 AM
> >>>> Subject: Re: Revamping the non responsive maintainer process
> >>>>
> >>>> Dne 5.11.2012 10:22, Marcela Mašláňová napsal(a):
> >>>>> On 11/02/2012 06:57 PM, "Jóhann B. Guðmundsson" wrote:
> >>>>>> On 11/02/2012 04:56 PM, Kevin Fenzi wrote:
> >>>>>>> On Fri, 02 Nov 2012 16:44:06 +0000
> >>>>>>> "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt;
> wrote:
> >>>>>>>
> >>>>>>>> On 11/02/2012 04:25 PM, Tom Lane wrote:
> >>>>>>>>> =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=
> >>>>>>>>> <johannbg(a)gmail.com&gt; writes:
> >>>>>>>>>> On 11/02/2012 03:32 PM, Matthew Miller wrote:
> >>>>>>>>>>> On Fri, Nov 02, 2012 at 03:12:56PM +0000,
> "Jóhann B.
> >>>>>>>>>>> Guðmundsson" wrote:
> >>>>>>>>>>>> Dead/un-maintained packages need to be
> removed/reassigned
> >>>>>>>>>>>> at
> >>>>>>>>>>>> the
> >>>>>>>>>>>> very *beginning* of an new development
> cycle so feature
> >>>>>>>>>>>> owners
> >>>>>>>>>>>> and others working in the community are
> dealing with
> >>>>>>>>>>>> active
> >>>>>>>>>>>> and
> >>>>>>>>>>>> actively maintained packages.
> >>>>>>>>> How exactly are you going to force maintainers who go
> missing
> >>>>>>>>> to do
> >>>>>>>>> so at a prescheduled time?  Real life is seldom that
> >>>>>>>>> convenient.
> >>>>>>>> If at this point we dont have any process that can
> actively
> >>>>>>>> tell
> >>>>>>>> if a
> >>>>>>>> maintainer is present and active within the project then
> we
> >>>>>>>> have
> >>>>>>>> bigger fish to fry then the feature process...
> >>>>>>> If we have problem A and problem B, can't we work on both
> at
> >>>>>>> the
> >>>>>>> same
> >>>>>>> time? :)
> >>>>>>>
> >>>>>>>> Seriously it should not be anymore complex than
> monitoring
> >>>>>>>> last
> >>>>>>>> login
> >>>>>>>> into the relevant infrastructure pieces to determine if
> the
> >>>>>>>> relevant
> >>>>>>>> maintainer is active or not.
> >>>>>>>>
> >>>>>>>> bash script + a cron job should suffice to achieve just
> that.
> >>>>>>> It's not at all that simple, I'm afraid.
> >>>>>>>
> >>>>>>> How long since last activity do you consider someone
> 'inactive'
> >>>>>>> ?
> >>>>>>>
> >>>>>>> What if the packages that maintain simply don't need any
> >>>>>>> changes?
> >>>>>>>
> >>>>>>> What if they are on vacation?
> >>>>>>>
> >>>>>>> What if they are active on package A, but not doing
> something
> >>>>>>> on
> >>>>>>> package B that you wish they would?
> >>>>>>>
> >>>>>>> I've long wanted to revamp our process.
> >>>>>>> I welcome concrete proposals to do so.
> >>>>>>
> >>>>>> Surely if an individual has not logged into for several months
> >>>>>> into our
> >>>>>> infrastructure he must be inactive no?
> >>>>>>
> >>>>>> Bash script + a cron job that monitors login should suffice to
> >>>>>> check and
> >>>>>> even email him asking him to confirm if he is active encase he
> >>>>>> has
> >>>>>> a low
> >>>>>> maintenance component and only logs in when something is filed
> >>>>>> ;)
> >>>>>>
> >>>>>> JBG
> >>>>> No, he can own only one package and be an upstream of the
> >>>>> package,
> >>>>> therefore he will login only for update of the package.
> >>>>>
> >>>>> You are using your use-case for everyone. If you insist on
> >>>>> automatic
> >>>>> process, then the metric should work with more data.
> >>>>>
> >>>>> Marcela
> >>>> Requiring action every 6 months, such as pressing button "Yes, I
> >>>> am
> >>>> still alive and kicking" in FAS after you are nagged by email,
> >>>> would
> >>>> be
> >>>> acceptable annoyance even for such package maintainers, wouldn't
> >>>> be?
> >>>>
> >>>> And there is such script, which is checking user activity on
> >>>> several
> >>>> places: https://github.com/pypingou/fedora-active-user
> >>>>
> >>>> Vit
> >>>> -- 
> >>>> devel mailing list
> >>>> devel(a)lists.fedoraproject.org
> >>>> https://admin.fedoraproject.org/mailman/listinfo/devel
> >>
> >> -- 
> >> devel mailing list
> >> devel(a)lists.fedoraproject.org
> >> https://admin.fedoraproject.org/mailman/listinfo/devel
>
>

Revamping the non responsive maintainer process

[Marcela Mašláňová]

On 11/06/2012 01:56 PM, Vít Ondruch wrote:
>  So give me the permission [1] as well as the others who requested it
>  before me.
>
>  Apparently the current owner doesn't care. You can compare the version
>  history in koji [2] and [3] and if he doesn't care about one package, it
>  is reasonable to doubt that the other packages will be in better state.
>
>  And please don't tell me about nonresponsive maintainer policy, if you
>  want to speak about community and collaboration [4].
>
>
>  Vit
>
>
>  [1] https://admin.fedoraproject.org/pkgdb/acls/name/rubygem-json
>  [2] http://koji.fedoraproject.org/koji/packageinfo?packageID=9017
>  [3] https://rubygems.org/gems/json/versions
>  [4] https://bugzilla.redhat.com/show_bug.cgi?id=620436
>
>
>
>  Dne 6.11.2012 12:58, Marcela Mašláňová napsal(a):
> > I agree. I'd rather give people permission to co-maintain package,
> > then push them out of community. I'm afraid we can only loose
> > maintainers by measurements of activity.
> >
> > Marcela
> >
> > On 11/06/2012 12:10 PM, Aleksandar Kurtakov wrote:
> >> It's the whole thread that implies that not your mail only.
> >> No one managed to explain why there should be actions against people
> >> instead of packages. I would be really thankful if someone explains
> >> how he can getter better measurement of people activity than of
> >> package maintenance problems and what is the benefit of tracking
> >> persons activity - it's not a competition it's supposed to be a
> >> collaboration and every should do as much as he can and wants.
> >>
> >> Alexander Kurtakov
> >> Red Hat Eclipse team
> >>
> >> ----- Original Message -----
> >>> From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
> >>> To: devel(a)lists.fedoraproject.org
> >>> Sent: Tuesday, November 6, 2012 12:55:27 PM
> >>> Subject: Re: Revamping the non responsive maintainer process
> >>>
> >>> I don't know what are you reading in my response, but I definitely
> >>> did
> >>> not propose anything like "noone wants people that are ready to do
> >>> one
> >>> thing in a year".
> >>>
> >>> Vit
> >>>
> >>>
> >>>
> >>> Dne 6.11.2012 09:52, Aleksandar Kurtakov napsal(a):
> >>>> Where is the community spirit? What went wrong with fedora
> >>>> community? Why on earth do you people insist on tracking people
> >>>> activity and not try detecting unmaintained packages?
> >>>> Detecting unmaintained packages is even easier and has clearer
> >>>> metrics.
> >>>>
> >>>> Really, why noone wants people that are ready to do one thing in a
> >>>> year? Are many people here feeling superior than the rest of the
> >>>> world and think there is no need for further contributions and
> >>>> they can do everything alone ? I'm starting to be really worried
> >>>> for the path Fedora is going.
> >>>>
> >>>> Alexander Kurtakov
> >>>> Red Hat Eclipse team
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
> >>>>> To: devel(a)lists.fedoraproject.org
> >>>>> Sent: Tuesday, November 6, 2012 10:28:11 AM
> >>>>> Subject: Re: Revamping the non responsive maintainer process
> >>>>>
> >>>>> Dne 5.11.2012 10:22, Marcela Mašláňová napsal(a):
> >>>>>> On 11/02/2012 06:57 PM, "Jóhann B. Guðmundsson" wrote:
> >>>>>>> On 11/02/2012 04:56 PM, Kevin Fenzi wrote:
> >>>>>>>> On Fri, 02 Nov 2012 16:44:06 +0000
> >>>>>>>> "Jóhann B. Guðmundsson"
> <johannbg(a)gmail.com&gt; wrote:
> >>>>>>>>
> >>>>>>>>> On 11/02/2012 04:25 PM, Tom Lane wrote:
> >>>>>>>>>> =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=
> >>>>>>>>>> <johannbg(a)gmail.com&gt; writes:
> >>>>>>>>>>> On 11/02/2012 03:32 PM, Matthew Miller
> wrote:
> >>>>>>>>>>>> On Fri, Nov 02, 2012 at 03:12:56PM +0000,
> "Jóhann B.
> >>>>>>>>>>>> Guðmundsson" wrote:
> >>>>>>>>>>>>> Dead/un-maintained packages need to
> be removed/reassigned
> >>>>>>>>>>>>> at
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>> very *beginning* of an new
> development cycle so feature
> >>>>>>>>>>>>> owners
> >>>>>>>>>>>>> and others working in the community
> are dealing with
> >>>>>>>>>>>>> active
> >>>>>>>>>>>>> and
> >>>>>>>>>>>>> actively maintained packages.
> >>>>>>>>>> How exactly are you going to force maintainers
> who go missing
> >>>>>>>>>> to do
> >>>>>>>>>> so at a prescheduled time?  Real life is seldom
> that
> >>>>>>>>>> convenient.
> >>>>>>>>> If at this point we dont have any process that can
> actively
> >>>>>>>>> tell
> >>>>>>>>> if a
> >>>>>>>>> maintainer is present and active within the project
> then we
> >>>>>>>>> have
> >>>>>>>>> bigger fish to fry then the feature process...
> >>>>>>>> If we have problem A and problem B, can't we work on
> both at
> >>>>>>>> the
> >>>>>>>> same
> >>>>>>>> time? :)
> >>>>>>>>
> >>>>>>>>> Seriously it should not be anymore complex than
> monitoring
> >>>>>>>>> last
> >>>>>>>>> login
> >>>>>>>>> into the relevant infrastructure pieces to determine
> if the
> >>>>>>>>> relevant
> >>>>>>>>> maintainer is active or not.
> >>>>>>>>>
> >>>>>>>>> bash script + a cron job should suffice to achieve
> just that.
> >>>>>>>> It's not at all that simple, I'm afraid.
> >>>>>>>>
> >>>>>>>> How long since last activity do you consider someone
> 'inactive'
> >>>>>>>> ?
> >>>>>>>>
> >>>>>>>> What if the packages that maintain simply don't need
> any
> >>>>>>>> changes?
> >>>>>>>>
> >>>>>>>> What if they are on vacation?
> >>>>>>>>
> >>>>>>>> What if they are active on package A, but not doing
> something
> >>>>>>>> on
> >>>>>>>> package B that you wish they would?
> >>>>>>>>
> >>>>>>>> I've long wanted to revamp our process.
> >>>>>>>> I welcome concrete proposals to do so.
> >>>>>>>
> >>>>>>> Surely if an individual has not logged into for several
> months
> >>>>>>> into our
> >>>>>>> infrastructure he must be inactive no?
> >>>>>>>
> >>>>>>> Bash script + a cron job that monitors login should suffice
> to
> >>>>>>> check and
> >>>>>>> even email him asking him to confirm if he is active encase
> he
> >>>>>>> has
> >>>>>>> a low
> >>>>>>> maintenance component and only logs in when something is
> filed
> >>>>>>> ;)
> >>>>>>>
> >>>>>>> JBG
> >>>>>> No, he can own only one package and be an upstream of the
> >>>>>> package,
> >>>>>> therefore he will login only for update of the package.
> >>>>>>
> >>>>>> You are using your use-case for everyone. If you insist on
> >>>>>> automatic
> >>>>>> process, then the metric should work with more data.
> >>>>>>
> >>>>>> Marcela
> >>>>> Requiring action every 6 months, such as pressing button "Yes,
> I
> >>>>> am
> >>>>> still alive and kicking" in FAS after you are nagged by email,
> >>>>> would
> >>>>> be
> >>>>> acceptable annoyance even for such package maintainers, wouldn't
> >>>>> be?
> >>>>>
> >>>>> And there is such script, which is checking user activity on
> >>>>> several
> >>>>> places: https://github.com/pypingou/fedora-active-user
> >>>>>
> >>>>> Vit
> >>>>> --
> >>>>> devel mailing list
> >>>>> devel(a)lists.fedoraproject.org
> >>>>> https://admin.fedoraproject.org/mailman/listinfo/devel
> >>>
> >>> --
> >>> devel mailing list
> >>> devel(a)lists.fedoraproject.org
> >>> https://admin.fedoraproject.org/mailman/listinfo/devel
> >
> >
>  
Oh no, you are top posting again ;-)

Could you create fesco ticket for this package? I proposed usage of the 
script in Johann's ticket 
https://fedorahosted.org/fesco/ticket/967#comment:7 Imho it might be 
better to give acl to more people, then only punish developers.

Marcela

Revamping the non responsive maintainer process

[Jóhann B. Guðmundsson]

On 11/06/2012 01:07 PM, Marcela Mašláňová wrote:
>  Oh no, you are top posting again ;-)
>
>  Could you create fesco ticket for this package? I proposed usage of 
>  the script in Johann's ticket 
>  https://fedorahosted.org/fesco/ticket/967#comment:7 Imho it might be 
>  better to give acl to more people, then only punish developers.  
If that's the plan why not drop the ownership model ( a.k.a dictatorship 
model ) all together so everyone can contribute to every package?

If the answer to the above is no we cant/wont do that then we need 
proper cleanup process "to punish developer" as you put it failing to 
understand that packagers/maintainers aren't' the only one in the 
community dealing with packages ( QA,Releng,Infra etc )...

JBG

Revamping the non responsive maintainer process

[Marcela Mašláňová]

On 11/06/2012 04:32 PM, "Jóhann B. Guðmundsson" wrote:
>  On 11/06/2012 01:07 PM, Marcela Mašláňová wrote:
> > Oh no, you are top posting again ;-)
> >
> > Could you create fesco ticket for this package? I proposed usage of
> > the script in Johann's ticket
> > https://fedorahosted.org/fesco/ticket/967#comment:7 Imho it might be
> > better to give acl to more people, then only punish developers.
>
>  If that's the plan why not drop the ownership model ( a.k.a dictatorship
>  model ) all together so everyone can contribute to every package?
>
>  If the answer to the above is no we cant/wont do that then we need
>  proper cleanup process "to punish developer" as you put it failing to
>  understand that packagers/maintainers aren't' the only one in the
>  community dealing with packages ( QA,Releng,Infra etc )...
>
>  JBG 
The "dictatorship" is there to safe us from reckless changes. If Fedora 
allow everyone to patch everything, then we have to check packagers more 
thoroughly than give them a few reviews usually of one language.

I safe my comments for tomorrows FESCo because we probably can't reach 
consensus.

Marcela

Revamping the non responsive maintainer process

[Vít Ondruch]

Dne 6.11.2012 16:40, Marcela Mašláňová napsal(a):
>  On 11/06/2012 04:32 PM, "Jóhann B. Guðmundsson" wrote:
> > On 11/06/2012 01:07 PM, Marcela Mašláňová wrote:
> >> Oh no, you are top posting again ;-)
> >>
> >> Could you create fesco ticket for this package? I proposed usage of
> >> the script in Johann's ticket
> >> https://fedorahosted.org/fesco/ticket/967#comment:7 Imho it might be
> >> better to give acl to more people, then only punish developers.
> >
> > If that's the plan why not drop the ownership model ( a.k.a dictatorship
> > model ) all together so everyone can contribute to every package?
> >
> > If the answer to the above is no we cant/wont do that then we need
> > proper cleanup process "to punish developer" as you put it failing to
> > understand that packagers/maintainers aren't' the only one in the
> > community dealing with packages ( QA,Releng,Infra etc )...
> >
> > JBG
>
>  The "dictatorship" is there to safe us from reckless changes. 
If you want to be sure, there should be some code review tool in the 
process, which would allow pear reviews of commits, e.g. if approved 
packager commits something into package he does not own/maintain, the 
commit would need to go through peer-review, but any other packager 
could be the peer.

Moreover every reckless change can be reverted.

Vit



>  If Fedora allow everyone to patch everything, then we have to check 
>  packagers more thoroughly than give them a few reviews usually of one 
>  language.
>
>  I safe my comments for tomorrows FESCo because we probably can't reach 
>  consensus.
>
>  Marcela

Revamping the non responsive maintainer process

[Vít Ondruch]

Dne 7.11.2012 09:52, Vít Ondruch napsal(a):
>  Dne 6.11.2012 16:40, Marcela Mašláňová napsal(a):
> > On 11/06/2012 04:32 PM, "Jóhann B. Guðmundsson" wrote:
> >> On 11/06/2012 01:07 PM, Marcela Mašláňová wrote:
> >>> Oh no, you are top posting again ;-)
> >>>
> >>> Could you create fesco ticket for this package? I proposed usage of
> >>> the script in Johann's ticket
> >>> https://fedorahosted.org/fesco/ticket/967#comment:7 Imho it might be
> >>> better to give acl to more people, then only punish developers.
> >>
> >> If that's the plan why not drop the ownership model ( a.k.a 
> >> dictatorship
> >> model ) all together so everyone can contribute to every package?
> >>
> >> If the answer to the above is no we cant/wont do that then we need
> >> proper cleanup process "to punish developer" as you put it failing to
> >> understand that packagers/maintainers aren't' the only one in the
> >> community dealing with packages ( QA,Releng,Infra etc )...
> >>
> >> JBG
> >
> > The "dictatorship" is there to safe us from reckless changes.
>
>  If you want to be sure, there should be some code review tool in the 
>  process, which would allow pear reviews 
* of course it should be peer review ;)

>  of commits, e.g. if approved packager commits something into package
>
>  he does not own/maintain, the commit would need to go through 
>  peer-review, but any other packager could be the peer.
>
>  Moreover every reckless change can be reverted.
>
>  Vit
>
>
>
> > If Fedora allow everyone to patch everything, then we have to check 
> > packagers more thoroughly than give them a few reviews usually of one 
> > language.
> >
> > I safe my comments for tomorrows FESCo because we probably can't 
> > reach consensus.
> >
> > Marcela
>

Revamping the non responsive maintainer process

[Orion Poplawski]

On 11/06/2012 06:07 AM, Marcela Mašláňová wrote:
>  Oh no, you are top posting again ;-)
>  
And please, please, please could we trim quotes to relevant ones?  Thanks!


-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: [phone]
3380 Mitchell Lane                  orion(a)cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com

Revamping the non responsive maintainer process

[Przemek Klosowski]

On 11/11/2012 10:01 PM, Orion Poplawski wrote:
>  On 11/06/2012 06:07 AM, Marcela Mašláňová wrote:
> > Oh no, you are top posting again ;-)
> >
>
>  And please, please, please could we trim quotes to relevant ones?  Thanks!
>
>  
Ohmahgerd, thank you for saying that. I am all for bottom posting but 
the _reason_ for bottom posting is that one responds to a specific 
phrase in the original. When people bottom-post a short reply under 
dozen-quoting-levels, multi-paragraph quote, it's actually less useful 
than if they just top-posted. In other words, bottom posting should not 
be a cargo cult, but instead a result of commitment to careful editing 
and meaningful communication.

Revamping the non responsive maintainer process

[Aleksandar Kurtakov]

----- Original Message -----
>  From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
>  To: devel(a)lists.fedoraproject.org
>  Sent: Tuesday, November 6, 2012 2:56:18 PM
>  Subject: Re: Revamping the non responsive maintainer process
>  
>  So give me the permission [1] as well as the others who requested it
>  before me.
>  
>  Apparently the current owner doesn't care. You can compare the
>  version
>  history in koji [2] and [3] and if he doesn't care about one package,
>  it
>  is reasonable to doubt that the other packages will be in better
>  state. 
The problem here is that pkgdb requests are not auto approved after some timeout period if
the maintainer hasn't reacted.
I remember I already said that in some past discussion on the topic. And it says nothing
about the maintainer you speak about he might be back some time soon and be more active
than all of us speaking here for some period. But if you declare him unresponsive and
throw him away we as a community lose him forever.

Alexander Kurtakov

>  
>  And please don't tell me about nonresponsive maintainer policy, if
>  you
>  want to speak about community and collaboration [4].
>  
>  
>  Vit
>  
>  
>  [1] https://admin.fedoraproject.org/pkgdb/acls/name/rubygem-json
>  [2] http://koji.fedoraproject.org/koji/packageinfo?packageID=9017
>  [3] https://rubygems.org/gems/json/versions
>  [4] https://bugzilla.redhat.com/show_bug.cgi?id=620436
>  
>  
>  
>  Dne 6.11.2012 12:58, Marcela Mašláňová napsal(a):
>  > I agree. I'd rather give people permission to co-maintain package,
>  > then push them out of community. I'm afraid we can only loose
>  > maintainers by measurements of activity.
>  >
>  > Marcela
>  >
>  > On 11/06/2012 12:10 PM, Aleksandar Kurtakov wrote:
>  >> It's the whole thread that implies that not your mail only.
>  >> No one managed to explain why there should be actions against
>  >> people
>  >> instead of packages. I would be really thankful if someone
>  >> explains
>  >> how he can getter better measurement of people activity than of
>  >> package maintenance problems and what is the benefit of tracking
>  >> persons activity - it's not a competition it's supposed to be a
>  >> collaboration and every should do as much as he can and wants.
>  >>
>  >> Alexander Kurtakov
>  >> Red Hat Eclipse team
>  >>
>  >> ----- Original Message -----
>  >>> From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
>  >>> To: devel(a)lists.fedoraproject.org
>  >>> Sent: Tuesday, November 6, 2012 12:55:27 PM
>  >>> Subject: Re: Revamping the non responsive maintainer process
>  >>>
>  >>> I don't know what are you reading in my response, but I
>  >>> definitely
>  >>> did
>  >>> not propose anything like "noone wants people that are ready to
>  >>> do
>  >>> one
>  >>> thing in a year".
>  >>>
>  >>> Vit
>  >>>
>  >>>
>  >>>
>  >>> Dne 6.11.2012 09:52, Aleksandar Kurtakov napsal(a):
>  >>>> Where is the community spirit? What went wrong with fedora
>  >>>> community? Why on earth do you people insist on tracking people
>  >>>> activity and not try detecting unmaintained packages?
>  >>>> Detecting unmaintained packages is even easier and has clearer
>  >>>> metrics.
>  >>>>
>  >>>> Really, why noone wants people that are ready to do one thing in
>  >>>> a
>  >>>> year? Are many people here feeling superior than the rest of the
>  >>>> world and think there is no need for further contributions and
>  >>>> they can do everything alone ? I'm starting to be really worried
>  >>>> for the path Fedora is going.
>  >>>>
>  >>>> Alexander Kurtakov
>  >>>> Red Hat Eclipse team
>  >>>>
>  >>>> ----- Original Message -----
>  >>>>> From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
>  >>>>> To: devel(a)lists.fedoraproject.org
>  >>>>> Sent: Tuesday, November 6, 2012 10:28:11 AM
>  >>>>> Subject: Re: Revamping the non responsive maintainer process
>  >>>>>
>  >>>>> Dne 5.11.2012 10:22, Marcela Mašláňová napsal(a):
>  >>>>>> On 11/02/2012 06:57 PM, "Jóhann B. Guðmundsson"
> wrote:
>  >>>>>>> On 11/02/2012 04:56 PM, Kevin Fenzi wrote:
>  >>>>>>>> On Fri, 02 Nov 2012 16:44:06 +0000
>  >>>>>>>> "Jóhann B. Guðmundsson"
> <johannbg(a)gmail.com&gt; wrote:
>  >>>>>>>>
>  >>>>>>>>> On 11/02/2012 04:25 PM, Tom Lane wrote:
>  >>>>>>>>>>
> =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=
>  >>>>>>>>>> <johannbg(a)gmail.com&gt; writes:
>  >>>>>>>>>>> On 11/02/2012 03:32 PM, Matthew Miller
> wrote:
>  >>>>>>>>>>>> On Fri, Nov 02, 2012 at 03:12:56PM
> +0000, "Jóhann B.
>  >>>>>>>>>>>> Guðmundsson" wrote:
>  >>>>>>>>>>>>> Dead/un-maintained packages need to
> be
>  >>>>>>>>>>>>> removed/reassigned
>  >>>>>>>>>>>>> at
>  >>>>>>>>>>>>> the
>  >>>>>>>>>>>>> very *beginning* of an new
> development cycle so feature
>  >>>>>>>>>>>>> owners
>  >>>>>>>>>>>>> and others working in the community
> are dealing with
>  >>>>>>>>>>>>> active
>  >>>>>>>>>>>>> and
>  >>>>>>>>>>>>> actively maintained packages.
>  >>>>>>>>>> How exactly are you going to force maintainers
> who go
>  >>>>>>>>>> missing
>  >>>>>>>>>> to do
>  >>>>>>>>>> so at a prescheduled time?  Real life is seldom
> that
>  >>>>>>>>>> convenient.
>  >>>>>>>>> If at this point we dont have any process that can
> actively
>  >>>>>>>>> tell
>  >>>>>>>>> if a
>  >>>>>>>>> maintainer is present and active within the project
> then we
>  >>>>>>>>> have
>  >>>>>>>>> bigger fish to fry then the feature process...
>  >>>>>>>> If we have problem A and problem B, can't we work on
> both at
>  >>>>>>>> the
>  >>>>>>>> same
>  >>>>>>>> time? :)
>  >>>>>>>>
>  >>>>>>>>> Seriously it should not be anymore complex than
> monitoring
>  >>>>>>>>> last
>  >>>>>>>>> login
>  >>>>>>>>> into the relevant infrastructure pieces to determine
> if the
>  >>>>>>>>> relevant
>  >>>>>>>>> maintainer is active or not.
>  >>>>>>>>>
>  >>>>>>>>> bash script + a cron job should suffice to achieve
> just
>  >>>>>>>>> that.
>  >>>>>>>> It's not at all that simple, I'm afraid.
>  >>>>>>>>
>  >>>>>>>> How long since last activity do you consider someone
>  >>>>>>>> 'inactive'
>  >>>>>>>> ?
>  >>>>>>>>
>  >>>>>>>> What if the packages that maintain simply don't need
> any
>  >>>>>>>> changes?
>  >>>>>>>>
>  >>>>>>>> What if they are on vacation?
>  >>>>>>>>
>  >>>>>>>> What if they are active on package A, but not doing
>  >>>>>>>> something
>  >>>>>>>> on
>  >>>>>>>> package B that you wish they would?
>  >>>>>>>>
>  >>>>>>>> I've long wanted to revamp our process.
>  >>>>>>>> I welcome concrete proposals to do so.
>  >>>>>>>
>  >>>>>>> Surely if an individual has not logged into for several
>  >>>>>>> months
>  >>>>>>> into our
>  >>>>>>> infrastructure he must be inactive no?
>  >>>>>>>
>  >>>>>>> Bash script + a cron job that monitors login should suffice
>  >>>>>>> to
>  >>>>>>> check and
>  >>>>>>> even email him asking him to confirm if he is active encase
>  >>>>>>> he
>  >>>>>>> has
>  >>>>>>> a low
>  >>>>>>> maintenance component and only logs in when something is
>  >>>>>>> filed
>  >>>>>>> ;)
>  >>>>>>>
>  >>>>>>> JBG
>  >>>>>> No, he can own only one package and be an upstream of the
>  >>>>>> package,
>  >>>>>> therefore he will login only for update of the package.
>  >>>>>>
>  >>>>>> You are using your use-case for everyone. If you insist on
>  >>>>>> automatic
>  >>>>>> process, then the metric should work with more data.
>  >>>>>>
>  >>>>>> Marcela
>  >>>>> Requiring action every 6 months, such as pressing button "Yes,
>  >>>>> I
>  >>>>> am
>  >>>>> still alive and kicking" in FAS after you are nagged by email,
>  >>>>> would
>  >>>>> be
>  >>>>> acceptable annoyance even for such package maintainers,
>  >>>>> wouldn't
>  >>>>> be?
>  >>>>>
>  >>>>> And there is such script, which is checking user activity on
>  >>>>> several
>  >>>>> places: https://github.com/pypingou/fedora-active-user
>  >>>>>
>  >>>>> Vit
>  >>>>> --
>  >>>>> devel mailing list
>  >>>>> devel(a)lists.fedoraproject.org
>  >>>>> https://admin.fedoraproject.org/mailman/listinfo/devel
>  >>>
>  >>> --
>  >>> devel mailing list
>  >>> devel(a)lists.fedoraproject.org
>  >>> https://admin.fedoraproject.org/mailman/listinfo/devel
>  >
>  >
>  
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

Revamping the non responsive maintainer process

[Vít Ondruch]

Dne 6.11.2012 14:17, Aleksandar Kurtakov napsal(a):
>  ----- Original Message -----
> > From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
> > To: devel(a)lists.fedoraproject.org
> > Sent: Tuesday, November 6, 2012 2:56:18 PM
> > Subject: Re: Revamping the non responsive maintainer process
> >
> > So give me the permission [1] as well as the others who requested it
> > before me.
> >
> > Apparently the current owner doesn't care. You can compare the
> > version
> > history in koji [2] and [3] and if he doesn't care about one package,
> > it
> > is reasonable to doubt that the other packages will be in better
> > state.
>  The problem here is that pkgdb requests are not auto approved after some timeout period
> if the maintainer hasn't reacted. 
That would be sweet if it would be auto approved.

>  I remember I already said that in some past discussion on the topic.
> And it says nothing about the maintainer you speak about he might be back some time soon
> and be more active than all of us speaking here for some period. 
Yes, he might get back and is occupied currently, but this should not be 
showstopper for Fedora.

>    But if you declare him unresponsive and throw him away we as a
> community lose him forever. 
Any statistics on this? ;)



Vit

Revamping the non responsive maintainer process

[Ralf Corsepius]

On 11/06/2012 02:24 PM, Vít Ondruch wrote:
>  Dne 6.11.2012 14:17, Aleksandar Kurtakov napsal(a):
> > ----- Original Message -----
> >> From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
> >> To: devel(a)lists.fedoraproject.org
> >> Sent: Tuesday, November 6, 2012 2:56:18 PM
> >> Subject: Re: Revamping the non responsive maintainer process
> >>
> >> So give me the permission [1] as well as the others who requested it
> >> before me.
> >>
> >> Apparently the current owner doesn't care. You can compare the
> >> version
> >> history in koji [2] and [3] and if he doesn't care about one package,
> >> it
> >> is reasonable to doubt that the other packages will be in better
> >> state.
> > The problem here is that pkgdb requests are not auto approved after
> > some timeout period if the maintainer hasn't reacted.
>
>  That would be sweet if it would be auto approved. 
Do you want a backdoor permitting all script kidz and overzealous, but 
unexperienced newcomers to automatically take over packages?

I regret having to say so, but the unpleasant fact is, Fedora does have 
such "participants".

When I do not react upon requests, I usually either missed or forgot 
about the request or deliberately do not yet want to approve.
That said, what I feel is missing in Fedora's pkgdb web-forms is an 
option to "leave a comment to applicant" and an "some automated reminder 
mechanisms" to remind "approvers" about pending requests.

Ralf

Revamping the non responsive maintainer process

[Bruno Wolff III]

On Tue, Nov 06, 2012 at 16:04:39 +0100,
   Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
> When I do not react upon requests, I usually either missed or forgot 
> about the request or deliberately do not yet want to approve.
> That said, what I feel is missing in Fedora's pkgdb web-forms is an 
> option to "leave a comment to applicant" and an "some automated 
> reminder mechanisms" to remind "approvers" about pending requests. 
When I ask to co-maintain a package I always email the maintainer stating 
why I want access and what I plan on doing.

Revamping the non responsive maintainer process

[Vít Ondruch]

Dne 6.11.2012 16:04, Ralf Corsepius napsal(a):
>  On 11/06/2012 02:24 PM, Vít Ondruch wrote:
> > Dne 6.11.2012 14:17, Aleksandar Kurtakov napsal(a):
> >> ----- Original Message -----
> >>> From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
> >>> To: devel(a)lists.fedoraproject.org
> >>> Sent: Tuesday, November 6, 2012 2:56:18 PM
> >>> Subject: Re: Revamping the non responsive maintainer process
> >>>
> >>> So give me the permission [1] as well as the others who requested it
> >>> before me.
> >>>
> >>> Apparently the current owner doesn't care. You can compare the
> >>> version
> >>> history in koji [2] and [3] and if he doesn't care about one package,
> >>> it
> >>> is reasonable to doubt that the other packages will be in better
> >>> state.
> >> The problem here is that pkgdb requests are not auto approved after
> >> some timeout period if the maintainer hasn't reacted.
> >
> > That would be sweet if it would be auto approved.
>
>  Do you want a backdoor permitting all script kidz and overzealous, but 
>  unexperienced newcomers to automatically take over packages? 
Come on, there are the same alarmist who think that Wikipedia will be 
hijacked and destroyed but have it happened any time?

You are still maintainer, you are still owner and you are notified by 
email about every change in your package, so you'll be able to catch 
such activity pretty soon and act accordingly.

>  I regret having to say so, but the unpleasant fact is, Fedora does 
>  have such "participants". 
Such people are everywhere. May be they can trick the system, become 
proven packager and takeover you packages. Who knows. You can never be sure.

>  When I do not react upon requests,  
I appreciate you swiftly react upon request, but unfortunately that does 
not imply that every other packager will react as swiftly as you.

>  I usually either missed or forgot about the request or deliberately
> do 
>  not yet want to approve.
>  That said, what I feel is missing in Fedora's pkgdb web-forms is an 
>  option to "leave a comment to applicant" and an "some automated 
>  reminder mechanisms" to remind "approvers" about pending requests. 
There is bugzilla, but it is definitely not the most flexible tool on 
the world.

>  Ralf
>

Revamping the non responsive maintainer process

[Pierre-Yves Chibon]

On Wed, 2012-11-07 at 09:49 +0100, Vít Ondruch wrote:
>  
>  You are still maintainer, you are still owner and you are notified by 
>  email about every change in your package, so you'll be able to catch 
>  such activity pretty soon and act accordingly. 
To be the devil's advocate, you do get the email but most of the time
right after the commit the person will push an update which you're not
able to withdraw as you did not create it.
Plus sometime, people takes days off...

Yeah, changes can be reverted but epoch sucks!

I do like the idea of some kind of per-review. Either the official
maintainer approve the changes or say two other maintainers do.
But there should be at minimal some time between the change in the spec
and the build of the new package.

Pierre

Revamping the non responsive maintainer process

[Vít Ondruch]

Dne 7.11.2012 10:00, Pierre-Yves Chibon napsal(a):
>  On Wed, 2012-11-07 at 09:49 +0100, Vít Ondruch wrote:
> > You are still maintainer, you are still owner and you are notified by
> > email about every change in your package, so you'll be able to catch
> > such activity pretty soon and act accordingly.
>  To be the devil's advocate, you do get the email but most of the time
>  right after the commit the person will push an update which you're not
>  able to withdraw as you did not create it. 
Yes, update in Bodhi. It takes 7 days to go through review. If it cannot 
be withdrawen by maintainer or lets say proven packager, then it can be 
improved.

>  Plus sometime, people takes days off... 
Yes, and if you did mistake before you go to holidays, then what?

You can always find some drawbacks with any process, but it doesn't mean 
that we should not be more open and trust your peers.

>  Yeah, changes can be reverted but epoch sucks!
>
>  I do like the idea of some kind of per-review. Either the official
>  maintainer approve the changes or say two other maintainers do.
>  But there should be at minimal some time between the change in the spec
>  and the build of the new package.
>
>  Pierre

Revamping the non responsive maintainer process

[Pierre-Yves Chibon]

On Wed, 2012-11-07 at 10:12 +0100, Vít Ondruch wrote:
>  Dne 7.11.2012 10:00, Pierre-Yves Chibon napsal(a):
>  > On Wed, 2012-11-07 at 09:49 +0100, Vít Ondruch wrote:
>  >> You are still maintainer, you are still owner and you are notified by
>  >> email about every change in your package, so you'll be able to catch
>  >> such activity pretty soon and act accordingly.
>  > To be the devil's advocate, you do get the email but most of the time
>  > right after the commit the person will push an update which you're not
>  > able to withdraw as you did not create it.
>  
>  Yes, update in Bodhi. It takes 7 days to go through review. If it cannot 
>  be withdrawen by maintainer or lets say proven packager, then it can be 
>  improved.
>  
>  > Plus sometime, people takes days off...
>  
>  Yes, and if you did mistake before you go to holidays, then what? 
Id'think that's also why we have updates-testing

>  You can always find some drawbacks with any process, but it
> doesn't mean 
>  that we should not be more open and trust your peers. 
Agreed. I was more playing the devil's advocate as I know the situation
has happened before.
People modified a spec thinking that was the way to go, the maintainer
who had the bigger picture was away and the changes had to be reverted
and the package got an epoch.

Pierre

Revamping the non responsive maintainer process

[Ralf Corsepius]

On 11/07/2012 09:49 AM, Vít Ondruch wrote:
>  Dne 6.11.2012 16:04, Ralf Corsepius napsal(a):
> > On 11/06/2012 02:24 PM, Vít Ondruch wrote:
> >> Dne 6.11.2012 14:17, Aleksandar Kurtakov napsal(a):
> >>> ----- Original Message -----
> >>>> From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
> >>>> To: devel(a)lists.fedoraproject.org
> >>>> Sent: Tuesday, November 6, 2012 2:56:18 PM
> >>>> Subject: Re: Revamping the non responsive maintainer process
> >>>>
> >>>> So give me the permission [1] as well as the others who requested it
> >>>> before me.
> >>>>
> >>>> Apparently the current owner doesn't care. You can compare the
> >>>> version
> >>>> history in koji [2] and [3] and if he doesn't care about one
> package,
> >>>> it
> >>>> is reasonable to doubt that the other packages will be in better
> >>>> state.
> >>> The problem here is that pkgdb requests are not auto approved after
> >>> some timeout period if the maintainer hasn't reacted.
> >>
> >> That would be sweet if it would be auto approved.
> >
> > Do you want a backdoor permitting all script kidz and overzealous, but
> > unexperienced newcomers to automatically take over packages?
>
>  Come on, there are the same alarmist who think that Wikipedia will be
>  hijacked and destroyed but have it happened any time? 
Well, you might not be aware about it, but at least de.wikipedia.org 
does have similiar problems as we are discussing here.

>  You are still maintainer, you are still owner and you are notified
> by
>  email about every change in your package, so you'll be able to catch
>  such activity pretty soon and act accordingly. 
You get notified when the damage is done, e.g. when your spec file has 
been modified to your dissatisfaction and when the package already has 
entered rawhide.

All that's left to you unless these changes immediately break something, 
is to either silently swallow these changes or to revert them sometime 
later.

> > I usually either missed or forgot about the request or
> deliberately do
> > not yet want to approve.
> > That said, what I feel is missing in Fedora's pkgdb web-forms is an
> > option to "leave a comment to applicant" and an "some automated
> > reminder mechanisms" to remind "approvers" about pending requests.
>
>  There is bugzilla, but it is definitely not the most flexible tool on
>  the world. 
Wrt. bugzilla, similar considerations apply: BZ-mails are sent out once

and therefore are easy to forget/miss.


Ralf

Revamping the non responsive maintainer process

[Vít Ondruch]

Dne 7.11.2012 10:21, Ralf Corsepius napsal(a):
>  On 11/07/2012 09:49 AM, Vít Ondruch wrote:
> > Dne 6.11.2012 16:04, Ralf Corsepius napsal(a):
> >> On 11/06/2012 02:24 PM, Vít Ondruch wrote:
> >>> Dne 6.11.2012 14:17, Aleksandar Kurtakov napsal(a):
> >>>> ----- Original Message -----
> >>>>> From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
> >>>>> To: devel(a)lists.fedoraproject.org
> >>>>> Sent: Tuesday, November 6, 2012 2:56:18 PM
> >>>>> Subject: Re: Revamping the non responsive maintainer process
> >>>>>
> >>>>> So give me the permission [1] as well as the others who requested it
> >>>>> before me.
> >>>>>
> >>>>> Apparently the current owner doesn't care. You can compare the
> >>>>> version
> >>>>> history in koji [2] and [3] and if he doesn't care about one 
> >>>>> package,
> >>>>> it
> >>>>> is reasonable to doubt that the other packages will be in better
> >>>>> state.
> >>>> The problem here is that pkgdb requests are not auto approved after
> >>>> some timeout period if the maintainer hasn't reacted.
> >>>
> >>> That would be sweet if it would be auto approved.
> >>
> >> Do you want a backdoor permitting all script kidz and overzealous, but
> >> unexperienced newcomers to automatically take over packages?
> >
> > Come on, there are the same alarmist who think that Wikipedia will be
> > hijacked and destroyed but have it happened any time?
>
>  Well, you might not be aware about it, but at least de.wikipedia.org 
>  does have similiar problems as we are discussing here.
>
> > You are still maintainer, you are still owner and you are notified by
> > email about every change in your package, so you'll be able to catch
> > such activity pretty soon and act accordingly.
>
>  You get notified when the damage is done 
Definitely, we are not in age of Minority Report yet, but even Pre-crime 
had its issues.

>  , e.g. when your spec file has been modified to your dissatisfaction
>
>  and when the package already has entered rawhide.
>
>  All that's left to you unless these changes immediately break 
>  something, is to either silently swallow these changes or to revert 
>  them sometime later.
>
> >> I usually either missed or forgot about the request or deliberately do
> >> not yet want to approve.
> >> That said, what I feel is missing in Fedora's pkgdb web-forms is an
> >> option to "leave a comment to applicant" and an "some automated
> >> reminder mechanisms" to remind "approvers" about pending
> requests.
> >
> > There is bugzilla, but it is definitely not the most flexible tool on
> > the world.
>  Wrt. bugzilla, similar considerations apply: BZ-mails are sent out 
>  once and therefore are easy to forget/miss.
>
>
>  Ralf
>

Revamping the non responsive maintainer process

[Björn Persson]

Vít Ondruch wrote:
>  Come on, there are the same alarmist who think that Wikipedia will
> be
>  hijacked and destroyed but have it happened any time? 
Edit wars often break out on Wikipedia. That's not something I would 
like to see in Fedora.
http://en.wikipedia.org/wiki/Wikipedia:Lamest_edit_wars

Also, mistakes on Wikipedia are unlikely to cause widespread breakage of 
users' work environments or insert backdoors into lots of computers all 
over the world.

Björn Persson

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Emmanuel Seyman]

* "Jóhann B. Guðmundsson" [02/11/2012 18:59] :
>  If at this point we dont have any process that can actively tell if
>  a maintainer is present and active within the project then we have
>  bigger fish to fry then the feature process... 
This really does not matter. We've had maintainers that were AWOL for years
without this affecting the distribution one bit because their packages were
cared for by co-maintainers and the appropriate SIGs.

If a package is unmaintained, send out a call to co-maintain to devel@ and open
up its ACLs.

>  Seriously it should not be anymore complex than monitoring last
>  login into the relevant infrastructure pieces to determine if the
>  relevant maintainer is active or not. 
Flagging maintainers as active/inactive is fun but it doesn't actually
improve the distribution.

Emmanuel

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jóhann B. Guðmundsson]

On 11/02/2012 06:56 PM, Emmanuel Seyman wrote:
>  If a package is unmaintained, send out a call to co-maintain to
> devel@ and open
>  up its ACLs. 
That package would hardly be un-maintained if it has co-maintainers now 
does it...

JBG

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Michał Piotrowski]

Hi,

Do current anaconda problems will have an impact on preupgrade?

-- 
Best regards,
Michal

http://eventhorizon.pl/
https://getactive.pl/

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Bill Nottingham]

Michał Piotrowski (mkkp4x4(a)gmail.com) said: 
>  Do current anaconda problems will have an impact on preupgrade?
preupgrade is not the current supported upgrade tool to upgrade to Fedora 18.
So the simple answer to your question is 'yes', although not exactly for the
reasons you expect.

https://fedoraproject.org/wiki/QA%3AFedora_18_Upgrade_Testing

Bill

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Emmanuel Seyman]

* "Jóhann B. Guðmundsson" [02/11/2012 20:34] :
>  That package would hardly be un-maintained if it has co-maintainers
>  now does it... 
Absolutely. Hence my request that any process we put in place be
package-focused rather than maintainer-focused.

Emmanuel

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Reindl Harald]

Am 03.11.2012 15:38, schrieb Emmanuel Seyman:
>  * "Jóhann B. Guðmundsson" [02/11/2012 20:34] :
> >
> > That package would hardly be un-maintained if it has co-maintainers
> > now does it...
>  
>  Absolutely. Hence my request that any process we put in place be
>  package-focused rather than maintainer-focused 
why?
how will you do this?
if there is nothing to change on a apckage it is at it is

if any maintainer not login he is INACTIVE
if a package has more maintainers it is no problem retire the inactive maintainer
if a package has only one maintainer and he is gone away the package has to be retired

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Aleksandar Kurtakov]

Hmm, actually I have new proposal. 
Policy about active/inactive maintainers should be decided only by actual maintainers. In
the true meritocracy way - if you don't maintain anything you don't have a say.

Alexander Kurtakov
Red Hat Eclipse team

----- Original Message -----
>  From: "Reindl Harald" <h.reindl(a)thelounge.net&gt;
>  To: devel(a)lists.fedoraproject.org
>  Sent: Saturday, November 3, 2012 4:47:57 PM
>  Subject: Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how	to install
> into a LVM partitions (or
>  RAID))
>  
>  
>  
>  Am 03.11.2012 15:38, schrieb Emmanuel Seyman:
>  > * "Jóhann B. Guðmundsson" [02/11/2012 20:34] :
>  >>
>  >> That package would hardly be un-maintained if it has
>  >> co-maintainers
>  >> now does it...
>  > 
>  > Absolutely. Hence my request that any process we put in place be
>  > package-focused rather than maintainer-focused
>  
>  why?
>  how will you do this?
>  if there is nothing to change on a apckage it is at it is
>  
>  if any maintainer not login he is INACTIVE
>  if a package has more maintainers it is no problem retire the
>  inactive maintainer
>  if a package has only one maintainer and he is gone away the package
>  has to be retired
>  
>  
>  
>  
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Aleksandar Kurtakov]

How does it sound? Really like the right way to build community by excluding people? Think
about this more before trying to screw others work? Your feature might mean nothing for
someone else if you want to see it happen step in and do your part and don't tell
people that there work should be removed.
P.S. My words would have been a lot more harsh if sending from personal email!!

Alexander Kurtakov
Red Hat Eclipse team

----- Original Message -----
>  From: "Aleksandar Kurtakov" <akurtako(a)redhat.com&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Sent: Sunday, November 4, 2012 9:30:49 AM
>  Subject: Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how	to install
> into a LVM partitions (or
>  RAID))
>  
>  Hmm, actually I have new proposal.
>  Policy about active/inactive maintainers should be decided only by
>  actual maintainers. In the true meritocracy way - if you don't
>  maintain anything you don't have a say.
>  
>  Alexander Kurtakov
>  Red Hat Eclipse team
>  
>  ----- Original Message -----
>  > From: "Reindl Harald" <h.reindl(a)thelounge.net&gt;
>  > To: devel(a)lists.fedoraproject.org
>  > Sent: Saturday, November 3, 2012 4:47:57 PM
>  > Subject: Re: Anaconda is totally trashing the F18 schedule (was Re:
>  > f18: how	to install into a LVM partitions (or
>  > RAID))
>  > 
>  > 
>  > 
>  > Am 03.11.2012 15:38, schrieb Emmanuel Seyman:
>  > > * "Jóhann B. Guðmundsson" [02/11/2012 20:34] :
>  > >>
>  > >> That package would hardly be un-maintained if it has
>  > >> co-maintainers
>  > >> now does it...
>  > > 
>  > > Absolutely. Hence my request that any process we put in place be
>  > > package-focused rather than maintainer-focused
>  > 
>  > why?
>  > how will you do this?
>  > if there is nothing to change on a apckage it is at it is
>  > 
>  > if any maintainer not login he is INACTIVE
>  > if a package has more maintainers it is no problem retire the
>  > inactive maintainer
>  > if a package has only one maintainer and he is gone away the
>  > package
>  > has to be retired
>  > 
>  > 
>  > 
>  > 
>  > --
>  > devel mailing list
>  > devel(a)lists.fedoraproject.org
>  > https://admin.fedoraproject.org/mailman/listinfo/devel
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Reindl Harald]

nobody here is screwing others work

teh topic is how about to find out AUTOMATICALLY which are
they doing the work and which things are orphaned without
finding it out the hard way in the running release cycle

and if you need to find out things automatically you need
any flag to measure - this would be FAS login

Am 04.11.2012 08:37, schrieb Aleksandar Kurtakov:
>  How does it sound? Really like the right way to build community by
> excluding people? Think about this more before trying to screw others work? Your feature
> might mean nothing for someone else if you want to see it happen step in and do your part
> and don't tell people that there work should be removed.
>  P.S. My words would have been a lot more harsh if sending from personal email!!
>  
>  Alexander Kurtakov
>  Red Hat Eclipse team
>  
>  ----- Original Message -----
> > From: "Aleksandar Kurtakov" <akurtako(a)redhat.com&gt;
> > To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
> > Sent: Sunday, November 4, 2012 9:30:49 AM
> > Subject: Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how	to
> install into a LVM partitions (or
> > RAID))
> >
> > Hmm, actually I have new proposal.
> > Policy about active/inactive maintainers should be decided only by
> > actual maintainers. In the true meritocracy way - if you don't
> > maintain anything you don't have a say.
> >
> > Alexander Kurtakov
> > Red Hat Eclipse team
> >
> > ----- Original Message -----
> >> From: "Reindl Harald" <h.reindl(a)thelounge.net&gt;
> >> To: devel(a)lists.fedoraproject.org
> >> Sent: Saturday, November 3, 2012 4:47:57 PM
> >> Subject: Re: Anaconda is totally trashing the F18 schedule (was Re:
> >> f18: how	to install into a LVM partitions (or
> >> RAID))
> >>
> >>
> >>
> >> Am 03.11.2012 15:38, schrieb Emmanuel Seyman:
> >>> * "Jóhann B. Guðmundsson" [02/11/2012 20:34] :
> >>>>
> >>>> That package would hardly be un-maintained if it has
> >>>> co-maintainers
> >>>> now does it...
> >>>
> >>> Absolutely. Hence my request that any process we put in place be
> >>> package-focused rather than maintainer-focused
> >>
> >> why?
> >> how will you do this?
> >> if there is nothing to change on a apckage it is at it is
> >>
> >> if any maintainer not login he is INACTIVE
> >> if a package has more maintainers it is no problem retire the
> >> inactive maintainer
> >> if a package has only one maintainer and he is gone away the
> >> package has to be retired

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Aleksandar Kurtakov]

The point is that such a measurement serves nothing but pissing off people.
You need to track activity on packages - how long bugs stay open without response (note
that this doesn't mean becoming accepted as one might be busy with other things), how
long the package stay with open CVEs, what is the usual delay for getting to latest
upstream, etc. Come up with strategy based on such measurement and you'll get
packagers support for some automated actions against packages (NOT PEOPLE).
Measuring people activity means nothing as I think we want MORE people to work with us not
less (even if they do it once in a year).
P.S. The words in capital letters are such intentionally.

Alexander Kurtakov
Red Hat Eclipse team

----- Original Message -----
>  From: "Reindl Harald" <h.reindl(a)thelounge.net&gt;
>  To: devel(a)lists.fedoraproject.org
>  Sent: Sunday, November 4, 2012 12:15:14 PM
>  Subject: Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how	to install
> into a LVM partitions (or
>  RAID))
>  
>  nobody here is screwing others work
>  
>  teh topic is how about to find out AUTOMATICALLY which are
>  they doing the work and which things are orphaned without
>  finding it out the hard way in the running release cycle
>  
>  and if you need to find out things automatically you need
>  any flag to measure - this would be FAS login
>  
>  Am 04.11.2012 08:37, schrieb Aleksandar Kurtakov:
>  > How does it sound? Really like the right way to build community by
>  > excluding people? Think about this more before trying to screw
>  > others work? Your feature might mean nothing for someone else if
>  > you want to see it happen step in and do your part and don't tell
>  > people that there work should be removed.
>  > P.S. My words would have been a lot more harsh if sending from
>  > personal email!!
>  > 
>  > Alexander Kurtakov
>  > Red Hat Eclipse team
>  > 
>  > ----- Original Message -----
>  >> From: "Aleksandar Kurtakov" <akurtako(a)redhat.com&gt;
>  >> To: "Development discussions related to Fedora"
>  >> <devel(a)lists.fedoraproject.org&gt;
>  >> Sent: Sunday, November 4, 2012 9:30:49 AM
>  >> Subject: Re: Anaconda is totally trashing the F18 schedule (was
>  >> Re: f18: how	to install into a LVM partitions (or
>  >> RAID))
>  >>
>  >> Hmm, actually I have new proposal.
>  >> Policy about active/inactive maintainers should be decided only by
>  >> actual maintainers. In the true meritocracy way - if you don't
>  >> maintain anything you don't have a say.
>  >>
>  >> Alexander Kurtakov
>  >> Red Hat Eclipse team
>  >>
>  >> ----- Original Message -----
>  >>> From: "Reindl Harald" <h.reindl(a)thelounge.net&gt;
>  >>> To: devel(a)lists.fedoraproject.org
>  >>> Sent: Saturday, November 3, 2012 4:47:57 PM
>  >>> Subject: Re: Anaconda is totally trashing the F18 schedule (was
>  >>> Re:
>  >>> f18: how	to install into a LVM partitions (or
>  >>> RAID))
>  >>>
>  >>>
>  >>>
>  >>> Am 03.11.2012 15:38, schrieb Emmanuel Seyman:
>  >>>> * "Jóhann B. Guðmundsson" [02/11/2012 20:34] :
>  >>>>>
>  >>>>> That package would hardly be un-maintained if it has
>  >>>>> co-maintainers
>  >>>>> now does it...
>  >>>>
>  >>>> Absolutely. Hence my request that any process we put in place be
>  >>>> package-focused rather than maintainer-focused
>  >>>
>  >>> why?
>  >>> how will you do this?
>  >>> if there is nothing to change on a apckage it is at it is
>  >>>
>  >>> if any maintainer not login he is INACTIVE
>  >>> if a package has more maintainers it is no problem retire the
>  >>> inactive maintainer
>  >>> if a package has only one maintainer and he is gone away the
>  >>> package has to be retired
>  
>  
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Michael Scherer]

Le dimanche 04 novembre 2012 à 13:19 -0500, Aleksandar Kurtakov a
écrit :
>  The point is that such a measurement serves nothing but pissing off
> people.
>  You need to track activity on packages - how long bugs stay open without response 
>  (note that this doesn't mean becoming accepted as one might be busy with other 
>  things), how long the package stay with open CVEs, what is the usual delay for 
>  getting to latest upstream, etc. Come up with strategy based on such measurement 
>  and you'll get packagers support for some automated actions against packages (NOT 
>  PEOPLE).
>  Measuring people activity means nothing as I think we want MORE people to work with 
>  us not less (even if they do it once in a year).
>  P.S. The words in capital letters are such intentionally. 
While I agree that this may make lose some contributions, on the other
hand, there is some team that have more aggressive pruning
( infrastructure team, for example ).

And keeping inactive accounts could cause issue for voting ( ie, if we
need for some reason to have a quorum of people ), and for sure could
increase the work for various sysadmin tasks in some specific case
( like if we need to contact all users to make them change their
password and check they did ).

-- 
Michael Scherer

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Aleksandar Kurtakov]

Michael, 
Without contributors there is no need for infrastructure, right? ;)
To me it means that we need more contributors working on infrastructure (as on every other
aspect of the distro) not pruning.

Alexander Kurtakov
Red Hat Eclipse team

----- Original Message -----
>  From: "Michael Scherer" <misc(a)zarb.org&gt;
>  To: devel(a)lists.fedoraproject.org
>  Sent: Sunday, November 4, 2012 9:43:49 PM
>  Subject: Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how	to install
> into a LVM partitions (or
>  RAID))
>  
>  Le dimanche 04 novembre 2012 à 13:19 -0500, Aleksandar Kurtakov a
>  écrit :
>  > The point is that such a measurement serves nothing but pissing off
>  > people.
>  > You need to track activity on packages - how long bugs stay open
>  > without response
>  > (note that this doesn't mean becoming accepted as one might be busy
>  > with other
>  > things), how long the package stay with open CVEs, what is the
>  > usual delay for
>  > getting to latest upstream, etc. Come up with strategy based on
>  > such measurement
>  > and you'll get packagers support for some automated actions against
>  > packages (NOT
>  > PEOPLE).
>  > Measuring people activity means nothing as I think we want MORE
>  > people to work with
>  > us not less (even if they do it once in a year).
>  > P.S. The words in capital letters are such intentionally.
>  
>  While I agree that this may make lose some contributions, on the
>  other
>  hand, there is some team that have more aggressive pruning
>  ( infrastructure team, for example ).
>  
>  And keeping inactive accounts could cause issue for voting ( ie, if
>  we
>  need for some reason to have a quorum of people ), and for sure could
>  increase the work for various sysadmin tasks in some specific case
>  ( like if we need to contact all users to make them change their
>  password and check they did ).
>  
>  --
>  Michael Scherer
>  
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Reindl Harald]

Am 02.11.2012 17:25, schrieb Tom Lane:
>  =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=
> <johannbg(a)gmail.com&gt; writes:
> > On 11/02/2012 03:32 PM, Matthew Miller wrote:
> >> On Fri, Nov 02, 2012 at 03:12:56PM +0000, "Jóhann B. Guðmundsson"
> wrote:
> >>> Dead/un-maintained packages need to be removed/reassigned at the
> >>> very *beginning* of an new development cycle so feature owners and
> >>> others working in the community are dealing with active and actively
> >>> maintained packages.
>  
>  How exactly are you going to force maintainers who go missing to do so
>  at a prescheduled time?  Real life is seldom that convenient 
well, it would maybe a start to DROP packages which are still
missing systemd-units or do fedora tend to have this "feature"
another 5 releases, currently it is the FOURTH

do not tell me packages where the maintainer until know did not
hear the shoot that Fedora uses systemd since more than year
is well maintained at all

again: this "feature" should have been finalized at F15
_________________________________

http://fedoraproject.org/wiki/Releases/18/FeatureList

60% 	
SysV to Systemd 	
Porting from sysVinit init scripts to systemd unit files	
2012-06-05

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Rahul Sundaram]

On Fri, Nov 2, 2012 at 10:25 PM, Reindl Harald wrote:

>  well, it would maybe a start to DROP packages which are still
>  missing systemd-units
>
>  http://fedoraproject.org/wiki/Releases/18/FeatureList
>
>  60%
>  SysV to Systemd
>  
Dropping 40% of packages isn't going to happen. Sorry

Rahul

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Michael Scherer]

Le samedi 03 novembre 2012 à 11:19 +0530, Rahul Sundaram a écrit :
>  
>  
>  On Fri, Nov 2, 2012 at 10:25 PM, Reindl Harald wrote:
>          well, it would maybe a start to DROP packages which are still
>          missing systemd-units 
>          
>          http://fedoraproject.org/wiki/Releases/18/FeatureList
>          
>          60%
>          SysV to Systemd
>  
>  Dropping 40% of packages isn't going to happen. Sorry 
Especially since some of those packages may have more complex initscript
than a simple systemd unit can produce.

For example, on my system, ceph, netcf-transaction or libvirt-guests are
more complex initscripts, and I could understand why they were not
migrated by now. 

-- 
Michael Scherer

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jóhann B. Guðmundsson]

On 11/03/2012 08:17 AM, Michael Scherer wrote:
>  Le samedi 03 novembre 2012 à 11:19 +0530, Rahul Sundaram a écrit :
> >
> > On Fri, Nov 2, 2012 at 10:25 PM, Reindl Harald wrote:
> >          well, it would maybe a start to DROP packages which are still
> >          missing systemd-units
> >          
> >          http://fedoraproject.org/wiki/Releases/18/FeatureList
> >          
> >          60%
> >          SysV to Systemd
> >
> > Dropping 40% of packages isn't going to happen. Sorry
>  Especially since some of those packages may have more complex initscript
>  than a simple systemd unit can produce.
>
>  For example, on my system, ceph, netcf-transaction or libvirt-guests are
>  more complex initscripts, and I could understand why they were not
>  migrated by now.
>  
Yeah upstream often is working making some other changes surrounding the 
unit and the daemon + nobody said or promised this was going to be 
migrated within one release cycle anyway
Reindl Harald just likes to make a fuzz...

And people should not be staring to much into the % they do not always 
accurately reflect the feature completeness...

JBG

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Richard W.M. Jones]

On Fri, Nov 02, 2012 at 11:55:37AM +0100, Stanislav Ochotnicky wrote:
>  I recently came up with similar 3-layer idea. My description was a
> bit
>  different, something like this:
>  1. level - rawhide-like repository, more or less anything goes
>  2. level - package moves here after maintainer says "this package has been
>             working for me for some time and looks OK. Let's integrate properly
>             with rest of the system".
>  3. level - packages integrated and experience should be splendid :-) 
If you substitute 'unstable' for level 1, 'testing' for level 2 and
'stable' for level 3, then this is not dissimilar to how Debian
operates.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Matej Cepl]

On Fri, 02 Nov 2012 13:32:33 +0000, Richard W.M. Jones wrote:
>  If you substitute 'unstable' for level 1, 'testing'
> for level 2 and
>  'stable' for level 3, then this is not dissimilar to how Debian
>  operates. 
Sure, and if you eliminate level 3 (which leads to multi-year-long 
freezes), then you have mostly I would like to see ;)

Matěj

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Tom Lane]

Stanislav Ochotnicky <sochotnicky(a)redhat.com&gt; writes:
>  Quoting Michael Cronenworth (2012-11-01 18:33:24)
> > I've wanted to write up a blog post about my plan for a rolling release,
> > but I'll post a snip-it here. 
>  I recently came up with similar 3-layer idea. 
In my little corner of the system, the main thing that causes
distro-level issues is new upstream versions of libraries, carrying
API/ABI breaks.  (Recent examples include the libpng 1.2.x -> 1.5.x
and libtiff 3.9.x -> 4.0.x upgrades.)  To push one of those into
rawhide, we at least have to rebuild all dependent packages, and
typically some of them need source-level patches too.  In the current
model, once that's been done in rawhide, the problem is over: all those
packages will propagate to release branches together.  ISTM a rolling
release would make this sort of thing enormously more complicated.
Almost certainly, not all those packages would be at similar levels of
stability and so there would be no point at which they could all get
pushed to any stable branch.  How would you handle that without creating
a huge amount of extra work for packagers?  Keep in mind this type of
thing happens *constantly*, probably a dozen times per release cycle
across the whole distro.  Any significant extra burden is going to be
insupportable.

			regards, tom lane

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Adam Williamson]

On Fri, 2012-11-02 at 11:55 +0100, Stanislav Ochotnicky wrote:
>  Quoting Michael Cronenworth (2012-11-01 18:33:24)
>  > Adam Williamson wrote:
>  > > I didn't want to throw this grenade into the debate, but now someone
>  > > else has, I'll just note that I was in favour of this before and I'm
>  > > still in favour of it now. :) Rolling release is a model that makes
>  > > clear sense for a distribution with the goals that Fedora has.
>  > 
>  > I've wanted to write up a blog post about my plan for a rolling release,
>  > but I'll post a snip-it here.
>  > 
>  > Fedora Rawhide - stays as is... it is a rolling release
>  > 
>  > Fedora Feature - think of it as F18 beta right now
>  > 
>  > Fedora Stable - think of it as F16/F17 right now
>  > 
>  > People choose the branch level at install time. Of course, like now,
>  > people can override this in the future with a change of fedora-release
>  > or yum --releasever. However, per-package updates from another branch
>  > level might not be something everyone can agree on how to handle, so it
>  > might be wise to limit support of it at first.
>  > 
>  > Workflow:
>  > A shiny new feature is introduced in Rawhide. Things go boom. Not many
>  > people are hurt by this. Once it has been given a few band-aids the
>  > feature could be submitted to Fedora Feature. After some hardening and
>  > polishing the feature could finally be pushed to Fedora Stable.
>  > 
>  > I feel this should give a good compromise to everyone's fears of a
>  > rolling release. It gives the feature freaks a place in Fedora. It gives
>  > the stable stubborns a place in Fedora.
>  > 
>  > I'll wake up from my dream now.
>  
>  I recently came up with similar 3-layer idea.  
<snip>

Honestly, my take on this is that anything like Debian's system would be
over-engineering.

The reason I like rolling release for Fedora is that Fedora is supposed
to be where we do cutting-edge development and integration. The way I
read Fedora's mission statement, target user statement etc is that it's
not _really_ meant to be a 'stable distribution' at all. We do a fairly
poor imitation of being one, to no great effect, but wasting a great
deal of resources.

The entire QA team (and the entire anaconda team, for that matter) is
currently spending virtually all its time trying to help bash the new
anaconda into something vaguely resembling shape for a fairly arbitrary
release deadline, so we can ship something called 'the Fedora 18 stable
release' without *completely* corpsing Jimmy Fallon-style as we do the
release announcement ("suuuure, this is a stable release..." *giggle*
*giggle* *guffaw* *full-blown laughing fit*). We've barely looked at the
desktop or the update mechanism or anything else. Stuff in Fedora
regresses all over the place...there all sorts of weirdness in how
fairly basic bits of our OS work, like updates and login and various
other crap. We can't really look in a mirror and say that, say, Fedora
17 is a serious stable operating system release by any reasonable
definition. It's a stable Fedora release, and we all know what that is.
We had a feature for a smooth boot process back in F12, remember? where
everything was polished and had the same background and you didn't see
any mode transitions? How's that working these days? It was supposed to
be a feature of our operating system. We almost got it done for one
release, and have been consistently regressing it ever since. That's not
what stable, mature operating systems do.

Over in kernel land, for a long time, the kernel team was wasting tons
of resources maintaining three or four different kernels for three or
four different releases - which is what they're supposed to do, under
our current policies. They have now solved that problem, but only
essentially by moving the kernel to a rolling release model: F16, F17
and F18 now have more or less the same kernel build, and F16 is like
three major versions on from where it started. Let's be honest - this is
a clear breach of what our update policy is supposed to achieve. We
wrote a get-out clause into the update policy to let the kernel team do
this and claim they're in line with the policy, but that was an obvious
process hack.

Basically what I'd like Fedora to do is 'that, only bigger'. We are not
really doing a convincing job of releasing and maintaining stable
operating systems, we're just wasting a lot of resources on pretending
to do so. Badly. Resources we could better be spending on what we're
good at - constantly building and iterating interesting new stuff in the
broad framework of a distribution that's usable enough for the job of
building and testing interesting new stuff.

If we want to look at the Debian model, I'd say we should have 'sid' and
'testing' or even just 'experimental' and 'sid' and stop lying to
people
that we are even interested in, let alone that our release cycle and
processes are capable of, building a stable general purpose operating
system. That's not what we're doing in practice, it's not really what
we're _trying_ to do, and that's fine. We are constantly building a
rough prototype of the next generation stable general purpose operating
system, and I think that's both a necessary thing that no-one else is
really doing, and a really fun thing to be doing. But we need to be
honest about it.

A light rolling-release model matches what Fedora is really doing rather
well, to my mind. It lets us iterate quickly, with an appropriate level
of QA that isn't needlessly stifling to development. In theory we'd be
'lowering our standards', but in practice they're lofty words we're not
backing up anyway. On a personal level, I can say for sure it'd free up
a lot of QA resources that are currently more or less wasted on an
almost constant treadmill of installer testing in order to be 'ready for
release' every six months. We could move to simply building, testing and
shipping updated installer images _when it made sense to do so_, not
'every six months because we do a release every six months'.

A heavy (three-tier, with a 'stable' tier) rolling-release model by
contrast would just wind up tying up needless development and QA
resources trying to ensure stability in the 'stable' tier, which I
rather suspect we'd wind up doing a bad job of anyway, because again,
stability really isn't what Fedora is about.

Anyway, we've rather torpedo'ed the feature process discussion now, and
I'm sorry about that :/. Hence the topic change. But while we're blue
sky thinking about massive release process changes, I think it's worth
keeping a firm grasp on what Fedora is really about and what it's
capable of achieving.

(the above is of course my personal opinion, and nothing official from
RH. in fact, I've no idea whether such a plan would be better for RH or
worse...my angle on this is purely a Fedora-based one.)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[drago01]

Well your point basically is "we can't/don't ship anything that is
stable so we should give up on that."

I disagree with that. Fedora releases had some small regression
introduced via updates from time but is is *very* usable as a stable
operating system.

Compare it to "always cutting edge" like rawhide ... you can't get any
work done with that. It keeps breaking almost every second day.

So things aren't perfect now they aren't as bad as you paint them to
be. The current anaconda mess is just a project management failure ...
nothing else really.

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Adam Williamson]

On Fri, 2012-11-02 at 21:07 +0100, drago01 wrote:
>  Well your point basically is "we can't/don't ship
> anything that is
>  stable so we should give up on that." 
More or less, yes.

>  I disagree with that. Fedora releases had some small regression
>  introduced via updates from time but is is *very* usable as a stable
>  operating system. 
I disagree. It's usable by the kind of people who use Fedora. Who like
shiny cutting-edge stuff and don't mind dealing with wonkiness
constantly. I wouldn't dream of putting any regular person on a Fedora
install, quite frankly. It's easy to get into a perspective bubble where
Fedora looks normal, but it isn't. It is not a stable general-purpose
operating system and it's absurd to represent it as such. I wouldn't put
Fedora 17 on my uncle Bob's computer (I don't have an uncle Bob, this is
just your hackneyed old 'regular person' example) and say 'there's your
computer'. How many of us would? Even if you get a good Fedora release
and don't hit problems with updates - which we don't do a _bad_ job of
these days, admittedly - our releases really aren't quality general
purpose OSes (we let all kinds of weirdnesses go into our releases which
a serious user-facing OS would never let go), and after 12 months, you
have to do an upgrade, which has about a 50/50 chance of exploding,
let's face it. That's not a convincing stable general purpose operating
system.

It's telling that when you meet 'normal people' who are running Fedora,
they're usually using Fedora N-5, which hasn't had security updates for
a year and a half. That's how 'normal people' use their computers - they
don't upgrade every year and find it _fun_ to fix the upgrade process
when it explodes. I don't think we're serving the (few) 'normal people'
who run Fedora in this fashion very well, frankly. They'd probably be
better off with something else.

I realize my point of view here is somewhat radical, but you need the
lunatic fringe around to keep people on their toes, I've always
thought. ;)

>  Compare it to "always cutting edge" like rawhide ... you
> can't get any
>  work done with that. It keeps breaking almost every second day. 
Well, that's why I said two streams. One would be what Rawhide is now
and the other would be pretty much branched/stable level. On a broad
conceptual level - there's several ways of doing this, of course. But my
basic point is that the three stream idea works for a project like
Debian, which has a conservative approach to everything and is able,
over a very long timeframe, to produce something that actually *is* a
stable operating system. It's not appropriate to a project like Fedora,
which really isn't doing that. How often have we said we don't have the
people interested in doing LTS releases, for instance? That's the kind
of work you need to maintain a true 'stable' tier in a three-tier
system. It's boring maintenance of long-dead code, and that's not
generally what Fedora people are interested in. How many maintainers
right now are doing a convincing job of maintaining F16? How many people
are testing the updates? How many Fedora packagers wake up in the
morning and think 'hey, what I really want to do today is carefully test
and backport specific fixes to the F16 branches of my packages'?

>  So things aren't perfect now they aren't as bad as you paint
> them to
>  be. The current anaconda mess is just a project management failure ...
>  nothing else really. 
The current anaconda mess is an example I used in my post, but it's not
the only one. I've been thinking along these lines for a long while, not
related to any particular fire. It's a general perspective.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Tom Lane]

Adam Williamson <awilliam(a)redhat.com&gt; writes:
>  On Fri, 2012-11-02 at 21:07 +0100, drago01 wrote:
> > I disagree with that. Fedora releases had some small regression
> > introduced via updates from time but is is *very* usable as a stable
> > operating system. 
>  I disagree. It's usable by the kind of people who use Fedora.
Uh, no.  What you describe is usable by the kind of people who use
rawhide.  Which is what, 1% of our user base?  If that.

Abandoning any pretense of having stable releases will eliminate a huge
fraction of the user community.  For sure it will eliminate *me*.  I'm
not in the business of fighting OS bugs every single day, and I will not
be forced into that business.  I have other things that I'm more
productive at.

I'm curious what you think package maintainers will do their package
maintenance on, if there is no Fedora version that they can trust to
still work tomorrow or the day after.  (Anyone up for porting fedpkg
to Ubuntu?)

I've seen a whole lot of user demand for *more* stable versions of
Fedora.  I've seen none whatever for less stable versions.

			regards, tom lane

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[drago01]

On Fri, Nov 2, 2012 at 10:53 PM, Tom Lane <tgl(a)redhat.com&gt; wrote:
>  Adam Williamson <awilliam(a)redhat.com&gt; writes:
> > On Fri, 2012-11-02 at 21:07 +0100, drago01 wrote:
> >> I disagree with that. Fedora releases had some small regression
> >> introduced via updates from time but is is *very* usable as a stable
> >> operating system.
>
> > I disagree. It's usable by the kind of people who use Fedora.
>
>  Uh, no.  What you describe is usable by the kind of people who use
>  rawhide.  Which is what, 1% of our user base?  If that.
>
>  Abandoning any pretense of having stable releases will eliminate a huge
>  fraction of the user community.  For sure it will eliminate *me*.  I'm
>  not in the business of fighting OS bugs every single day, and I will not
>  be forced into that business.  I have other things that I'm more
>  productive at. 
Exactly saves me time to write a reply to Adam's post.

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Reindl Harald]

Am 02.11.2012 22:53, schrieb Tom Lane:
>  Abandoning any pretense of having stable releases will eliminate a
> huge
>  fraction of the user community.  For sure it will eliminate *me*.  I'm
>  not in the business of fighting OS bugs every single day, and I will not
>  be forced into that business.  I have other things that I'm more
>  productive at. 
+1

>  I'm curious what you think package maintainers will do their
> package
>  maintenance on, if there is no Fedora version that they can trust to
>  still work tomorrow or the day after.  (Anyone up for porting fedpkg
>  to Ubuntu?) 
+1

>  I've seen a whole lot of user demand for *more* stable versions
> of
>  Fedora.  I've seen none whatever for less stable versions. 
+1

Fedora IS USEABLE as a stable base for nearly anything
even large upgrades like systemd and UsrMove are working finally
they "only" have too much impact which could be optimized by relax
the release-schedules in a direction "ok, things are not running
like we thought at the begin of the schedule, let us take the time
it needs to make stings clean and stable"

current F18 is a good example

POSITIVE: beta delayed multiple times for good reasons
NEGATIVE: the promise to hold final release date

NO!
the right way would be to delay final release to 2013
this would greatly improve the time of testing of a
as final declared release where ALL components are
having this state at the same time

PLEASE: keep in mind this is free software NOT driven by
marketing idiots who define release dates - why wasting
this real huge benefit for "beeing first everytime"
_____________________________

as said:

i would propose that one of the two releases each year does
not bring large new features with great impact and instead
use one schedule to stabilize and fine-polish the distribution
at all which maybe save a lot of ressources for upcoming
features in the following release

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Adam Williamson]

On Fri, 2012-11-02 at 17:53 -0400, Tom Lane wrote:
>  Adam Williamson <awilliam(a)redhat.com&gt; writes:
>  > On Fri, 2012-11-02 at 21:07 +0100, drago01 wrote:
>  >> I disagree with that. Fedora releases had some small regression
>  >> introduced via updates from time but is is *very* usable as a stable
>  >> operating system.
>  
>  > I disagree. It's usable by the kind of people who use Fedora.
>  
>  Uh, no.  What you describe is usable by the kind of people who use
>  rawhide.  Which is what, 1% of our user base?  If that.
>  
>  Abandoning any pretense of having stable releases will eliminate a huge
>  fraction of the user community.  For sure it will eliminate *me*.  I'm
>  not in the business of fighting OS bugs every single day, and I will not
>  be forced into that business.  I have other things that I'm more
>  productive at.
>  
>  I'm curious what you think package maintainers will do their package
>  maintenance on, if there is no Fedora version that they can trust to
>  still work tomorrow or the day after.  (Anyone up for porting fedpkg
>  to Ubuntu?)
>  
>  I've seen a whole lot of user demand for *more* stable versions of
>  Fedora.  I've seen none whatever for less stable versions. 
Perhaps I ought to be more clear. I think we can maintain the level of
*actual* stability our current 'stable' releases provide with a model
such as I describe, while substantially reducing the amount of resources
we're wasting at least _theoretically_ maintaining up to four releases
at once (currently, 16, 17, 18 and 19). I think there's a lot of heat
and not much light going on there.

I would envisage that people like you and drago would run the 'stabler'
branch in my plan and be happy. The idea isn't to make Fedora less
stable than it already is, it's just to be more realistic. I would say
that our current process produces the level of stability that you and
drago are happy with, but we sometimes act as if it produces a level of
stability you could put in a box and sell to people, which it doesn't.

If you're using a Fedora release today you're _already_ fighting OS bugs
more often than most people do, I'd say. I disagree with drago's
assertion that my description was of people who use Rawhide. It was not
intended to be, and it was drawn from the experience of me and other
people who do not run Rawhide. I almost never run Rawhide, only
Branched.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Kevin Fenzi]

On Fri, 02 Nov 2012 15:17:02 -0700
Adam Williamson <awilliam(a)redhat.com&gt; wrote:

..snip...

>  If you're using a Fedora release today you're _already_
> fighting OS
>  bugs more often than most people do, I'd say. I disagree with drago's
>  assertion that my description was of people who use Rawhide. It was
>  not intended to be, and it was drawn from the experience of me and
>  other people who do not run Rawhide. I almost never run Rawhide, only
>  Branched. 
Perhaps you have your head too much in the Branched world right now?

In my experience, in the last few years, Fedora stable releases have
become much more stable. My "stable" boxes here at home I have not
really had to poke at since I upgraded them to Fedora 17. I apply
updates every few days and things keep working along fine. 

In previous cycles there were some real nasty brown paper bag type
blowups that required me to do things to downgrade or tweak to keep my
stable version working, that (knock on wood) hasn't happened in f16/f17
in my experence. 

I realize there are bugs and problems that hit, but I think the stable
updates policy has helped keep those down. (Cue KevinK to come in and
shout and tell me how wrong I am, etc etc)

I'm personally -1 to any kind of rolling release beyond rawhide. 

kevin

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Adam Williamson]

On Fri, 2012-11-02 at 16:31 -0600, Kevin Fenzi wrote:
>  On Fri, 02 Nov 2012 15:17:02 -0700
>  Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  
>  ..snip...
>  
>  > If you're using a Fedora release today you're _already_ fighting OS
>  > bugs more often than most people do, I'd say. I disagree with drago's
>  > assertion that my description was of people who use Rawhide. It was
>  > not intended to be, and it was drawn from the experience of me and
>  > other people who do not run Rawhide. I almost never run Rawhide, only
>  > Branched.
>  
>  Perhaps you have your head too much in the Branched world right now? 
Not really. I think I have my head more in the 'real' world than some
Fedora folks do though ;)

I usually run Branched on my desktop and current stable (F-N) on my
laptop. How stable is that? Well, the sound on my laptop broke with F17.
For several months. It only got fixed because I took the bug upstream
and then ensured the fix got ported down into Fedora...that's the
experience that *someone who knows how to get people to fix his bugs*
has with our product. Imagine the experience a normal person has.

>  In my experience, in the last few years, Fedora stable releases have
>  become much more stable. My "stable" boxes here at home I have not
>  really had to poke at since I upgraded them to Fedora 17. I apply
>  updates every few days and things keep working along fine. 
>  
>  In previous cycles there were some real nasty brown paper bag type
>  blowups that required me to do things to downgrade or tweak to keep my
>  stable version working, that (knock on wood) hasn't happened in f16/f17
>  in my experence. 
>  
>  I realize there are bugs and problems that hit, but I think the stable
>  updates policy has helped keep those down. (Cue KevinK to come in and
>  shout and tell me how wrong I am, etc etc) 
Sure, like I said in another mail, we've got better at that than before.
But as I also said in the same mail, you still have to do a version
upgrade every twelve months. That alone is ridiculous for a 'stable'
operating system.

I don't think we destabilize things - in the sense of 'you update and
your machine stops working' very often within a single one of our stable
releases. That isn't my point, really. My points are more:

* Upgrading every year, with an unreliable upgrade process, is not
something you have to do with a proper stable OS
* We do not insist on a level of polish or lack of functional regression
in our stable releases which is any way consistent with a true
productized general purpose OS

I'm as well placed as anyone to know _exactly_ what we as a project are
happy with signing off on as a final release, and based on my experience
working on, using, and doing user support for various distributions and
operating systems, I'm happy to maintain that that level is nowhere near
a level suitable for a general-purpose stable OS. Our standard for a
final release is, broadly, that the installer works pretty well, there
are no giant booboos on the desktop, and you can run the updater. We
don't care if a feature that was introduced in the previous release is
completely broken, unless it affects the critical path, we just say 'fix
it with an update'. We don't hold releases for cosmetic bugs, even
really obvious ones. We don't hold releases for usability issues. These
are all things that serious grown-up operating systems do.

That's fine. My posts have a general negative tone just based on the way
I'm constructing my argument, but it's important to realize I don't
think this is a _problem_. I think what we achieve is roughly what many
people who run Fedora want. But we _only_ achieve that level, and we
really don't need this unwieldy system of maintaining four releases at a
time to achieve it. My fundamental argument is there's a bit of a
disconnect between our release process - which is sort of aping the way
a stable general-purpose OS would be released, but on fast-forward and
with far fewer resources - and our actual goals for the project and the
standards we really enforce. We don't _need_ the heavy, constant release
cycle we currently employ in order to deliver the good things we already
currently deliver.

Anyway, I think the point is mashed into the ground by now, so I'll
stop. My proposal is more about trying to get people thinking at a
fundamental level than it is necessarily something I actually expect the
project to adopt wholesale - I just want to make the point that, in
designing whatever changes we may make to our processes, we should keep
a realistic view of what Fedora is actually _for_, and not over-engineer
things.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[drago01]

On Sat, Nov 3, 2012 at 12:04 AM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  [...]
>  * Upgrading every year, with an unreliable upgrade process, is not
>  something you have to do with a proper stable OS 
I am not sure why you call it unreliable ... I *never* reinstall
unless I really had to (moving one installation from i386 to x86_64).
Otherwise I always upgrade using either anaconda back in the days and
then preupgrade.

There is some weird attitude that "upgrades don't work anyway people
should just reinstall". Not only is a reinstall a lot more work it is
just not something you could ask from a user to do every 6-12 months.

Technically there is no difference between an upgrade and package
updates just the package set is larger, it just makes dealing with
stuff like usrmove easier. If an update from foo-1.0 to foo-2.0 breaks
the whole system it will regardless whether you upgrade from FN-1 to
FN or doing a "yum update" in a rolling release.

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Adam Williamson]

On Sat, 2012-11-03 at 00:18 +0100, drago01 wrote:
>  On Sat, Nov 3, 2012 at 12:04 AM, Adam Williamson
> <awilliam(a)redhat.com&gt; wrote:
>  > [...]
>  > * Upgrading every year, with an unreliable upgrade process, is not
>  > something you have to do with a proper stable OS
>  
>  I am not sure why you call it unreliable ... I *never* reinstall 
Because I read the forums =)

It's not usually terribly unreliable for me either. But I'm a smart
cookie like you. I update my systems with yum and I know what I have to
do to make it work properly - I follow the instructions and I know how
to wiggle my way around dependency issues. This is second nature to me
as I'm sure it is to you. You've probably dealt with bugs on upgrades
before that you've forgotten about, even. Also, I don't use third party
repositories. Normal people do. Especially with a distro like Fedora
which doesn't ship Flash, proprietary drivers, Chrome...

I've been hanging around user forums for Mandriva, Fedora and Ubuntu for
a decade now and I can tell you, every time a new release of any of
those comes out, the forums get a big dump of people with problems
upgrading. Regular as clockwork. has always happened, more or less will
always happen. operating system upgrades are an insoluble problem,
really. The number of variables involved in one is astronomical. Note
that neither Red Hat nor Microsoft actually support major version
upgrades for their operating systems, both of which have exponentially
more testing done on them, much lower levels of churn, and much smaller
sets of packages. (Also note how much trouble phone companies have
updating Android.)

I also know what we do to test upgrades before we sign off on a release,
which is 'do a clean install of F-N in a VM and check it can be upgraded
to F-N+1'. If that passes, we ship. That is not a level of testing which
allows me to declare with confidence that our upgrade process is solid
and reliable ;)

>  unless I really had to (moving one installation from i386 to
> x86_64).
>  Otherwise I always upgrade using either anaconda back in the days and
>  then preupgrade.
>  
>  There is some weird attitude that "upgrades don't work anyway people
>  should just reinstall". Not only is a reinstall a lot more work it is
>  just not something you could ask from a user to do every 6-12 months.
>  
>  Technically there is no difference between an upgrade and package
>  updates just the package set is larger, it just makes dealing with
>  stuff like usrmove easier. If an update from foo-1.0 to foo-2.0 breaks
>  the whole system it will regardless whether you upgrade from FN-1 to
>  FN or doing a "yum update" in a rolling release. 
Well, kinda. The advantage of a rolling release is that it tends to
narrow the focus. You don't have a million people hitting five hundred
potentially destabilizing updates all at once; you have a million people
all getting one potentially destabilizing update at a time (or, at
least, a fairly small set at a time). When everyone starts yelling, you
can just look at what got updated the night before and probably find the
culprit. That's what happens with Rawhide, after all. And anyway, I
don't think a rolling release would be *better* from this point of view
- as with my other points, I think a rolling release would allow us to
do *just as well* while reducing our testing and development overheads.

In a rolling release model, everyone deals with foo-1.0 to foo-2.0, then
a week later they deal with bar-1.0 to bar-2.0, then a week later they
deal with monkeys-1.0 to monkeys-2.0...in a 'stable' release model,
everyone gets to deal with foo, bar, monkeys and five hundred other
changes all at once. Which is chaos on a stick.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Michał Piotrowski]

Hi,

2012/11/3 Adam Williamson <awilliam(a)redhat.com&gt;:
>  Note
>  that neither Red Hat nor Microsoft actually support major version
>  upgrades for their operating systems 
Just take a look at this - MS rocks here
http://www.youtube.com/watch?v=vPnehDhGa14

-- 
Best regards,
Michal

http://eventhorizon.pl/
https://getactive.pl/

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Stephen John Smoogen]

On 2 November 2012 17:36, Michał Piotrowski <mkkp4x4(a)gmail.com&gt; wrote:
>  Hi,
>
>  2012/11/3 Adam Williamson <awilliam(a)redhat.com&gt;:
> > Note
> > that neither Red Hat nor Microsoft actually support major version
> > upgrades for their operating systems
>
>  Just take a look at this - MS rocks here
>  http://www.youtube.com/watch?v=vPnehDhGa14 
Support is an  overloaded word. You and Adam are using it differently
so it of course it is going to conflict.

There is a huge difference from it will work and they will support it.
Adam is talking about the fact that if your upgrade breaks you will
get 0 support from Microsoft to fix it. That only comes with special
platinum contracts where they will come in before hand, make sure that
it might work, run it on their own machines first, and the do it for
you.


-- 
Stephen J Smoogen.
"Don't derail a useful feature for the 99% because you're not in it."
Linus Torvalds
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me."  —James Stewart as Elwood P. Dowd

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Simo Sorce]

On Sat, 2012-11-03 at 00:36 +0100, Michał Piotrowski wrote:
>  Hi,
>  
>  2012/11/3 Adam Williamson <awilliam(a)redhat.com&gt;:
>  > Note
>  > that neither Red Hat nor Microsoft actually support major version
>  > upgrades for their operating systems 
Adam, this is plainly untrue for Microsoft, they always supported
upgrading to the next version.

>  Just take a look at this - MS rocks here
>  http://www.youtube.com/watch?v=vPnehDhGa14 
However keep in mind, that in MS case the OS, is *a lot* smaller than
what we have.
They do not give any guarantee that third party apps will keep working
although they *do* do their damn best to make sure they don't break most
important stuff. (By simply not changing interfaces, ABIs, or adding
compatibility libraries in the system).

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Adam Williamson]

On Sun, 2012-11-04 at 12:18 -0500, Simo Sorce wrote:
>  On Sat, 2012-11-03 at 00:36 +0100, Michał Piotrowski wrote:
>  > Hi,
>  > 
>  > 2012/11/3 Adam Williamson <awilliam(a)redhat.com&gt;:
>  > > Note
>  > > that neither Red Hat nor Microsoft actually support major version
>  > > upgrades for their operating systems
>  
>  Adam, this is plainly untrue for Microsoft, they always supported
>  upgrading to the next version. 
As someone already pointed out, 'support' is an overloaded term. They
'support' upgrades the same way we 'support' upgrades - they provide an
upgrade mechanism for you to hang yourself with. As was clarified later,
the point is that they don't guarantee it will work, and in practice, it
doesn't work reliably enough for anyone doing anything really critical
to rely on it. And they don't.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[drago01]

On Sun, Nov 4, 2012 at 6:55 PM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  On Sun, 2012-11-04 at 12:18 -0500, Simo Sorce wrote:
> > On Sat, 2012-11-03 at 00:36 +0100, Michał Piotrowski wrote:
> > > Hi,
> > >
> > > 2012/11/3 Adam Williamson <awilliam(a)redhat.com&gt;:
> > > > Note
> > > > that neither Red Hat nor Microsoft actually support major version
> > > > upgrades for their operating systems
> >
> > Adam, this is plainly untrue for Microsoft, they always supported
> > upgrading to the next version.
>
>  As someone already pointed out, 'support' is an overloaded term. They
>  'support' upgrades the same way we 'support' upgrades - they provide an
>  upgrade mechanism for you to hang yourself with. As was clarified later,
>  the point is that they don't guarantee it will work, 
[citation needed]

I can't believe that they were selling something "windows X upgrade"
without supporting it at all.
That's like selling a car and telling the customer "it might not move
at all in that case you are on your own sorry".

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Emmanuel Seyman]

* drago01 [05/11/2012 08:00] :
>  That's like selling a car and telling the customer "it might not move
>  at all in that case you are on your own sorry". 
This is par the course for proprietary software (with the added bonus
that you can't actually fix it since you don't have the source code).

Emmanuel

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[drago01]

On Mon, Nov 5, 2012 at 8:02 AM, Emmanuel Seyman <emmanuel(a)seyman.fr&gt; wrote:
>  * drago01 [05/11/2012 08:00] :
> >
> > That's like selling a car and telling the customer "it might not move
> > at all in that case you are on your own sorry".
>
>  This is par the course for proprietary software (with the added bonus
>  that you can't actually fix it since you don't have the source code). 
The point here is that they are *selling* it ... you might not have
the source code but if it does not work at all you can return it back
and get a refund.

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Stephen John Smoogen]

On 4 November 2012 23:57, drago01 <drago01(a)gmail.com&gt; wrote:
>  On Sun, Nov 4, 2012 at 6:55 PM, Adam Williamson
> <awilliam(a)redhat.com&gt; wrote:
> > On Sun, 2012-11-04 at 12:18 -0500, Simo Sorce wrote:
> >> On Sat, 2012-11-03 at 00:36 +0100, Michał Piotrowski wrote:
> >> > Hi,
> >> >
> >> > 2012/11/3 Adam Williamson <awilliam(a)redhat.com&gt;:
> >> > > Note
> >> > > that neither Red Hat nor Microsoft actually support major version
> >> > > upgrades for their operating systems
> >>
> >> Adam, this is plainly untrue for Microsoft, they always supported
> >> upgrading to the next version.
> >
> > As someone already pointed out, 'support' is an overloaded term. They
> > 'support' upgrades the same way we 'support' upgrades - they provide
> an
> > upgrade mechanism for you to hang yourself with. As was clarified later,
> > the point is that they don't guarantee it will work,
>
>  [citation needed]
>
>  I can't believe that they were selling something "windows X upgrade"
>  without supporting it at all.
>  That's like selling a car and telling the customer "it might not move
>  at all in that case you are on your own sorry". 
I only have my personal experience because trying to find the exact
line in the tiny print which covers it requires me to know more legal
terms than I do. The scenarios I have run into multiple times is where
a manager decided to not pay Microsoft for their upgrade support and
ended up with having to pay for some sort of tiger team to figure out
what went wrong. Usually it is not with the core OS.. that upgrades
fine.. it is usually with registry and non-core programs OR it might
be hardware drivers for anything above the basics .

At which point Microsoft will point you towards the OEM or software
group that manufactures that software.. which is very fun when that is
Microsoft itself.


-- 
Stephen J Smoogen.
"Don't derail a useful feature for the 99% because you're not in it."
Linus Torvalds
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me."  —James Stewart as Elwood P. Dowd

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[devzero2000]

For microsoft perhaps, but Ubuntu, Debian ? Upgrading from a release
to the next is trivial, and in general work well. Sure, probably the
update to the core system component is more light, no Usrmove, no
systemd, or something like this. And preserving, updating the new
configuration based on the previous really is not so simple. But this
problem today is really well solved if you use a good configuration
manager, but this is not applicable for a general end user, i think.

Best and sorry for the top posting.

2012/11/4, Simo Sorce <simo(a)redhat.com&gt;:
>  On Sat, 2012-11-03 at 00:36 +0100, Michał Piotrowski wrote:
> > Hi,
> >
> > 2012/11/3 Adam Williamson <awilliam(a)redhat.com&gt;:
> > > Note
> > > that neither Red Hat nor Microsoft actually support major version
> > > upgrades for their operating systems
>
>  Adam, this is plainly untrue for Microsoft, they always supported
>  upgrading to the next version.
>
> > Just take a look at this - MS rocks here
> > http://www.youtube.com/watch?v=vPnehDhGa14
>
>  However keep in mind, that in MS case the OS, is *a lot* smaller than
>  what we have.
>  They do not give any guarantee that third party apps will keep working
>  although they *do* do their damn best to make sure they don't break most
>  important stuff. (By simply not changing interfaces, ABIs, or adding
>  compatibility libraries in the system).
>
>  Simo.
>
>  --
>  Simo Sorce * Red Hat, Inc * New York
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel 
-- 
Inviato dal mio dispositivo mobile

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[drago01]

On Sat, Nov 3, 2012 at 12:32 AM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  On Sat, 2012-11-03 at 00:18 +0100, drago01 wrote:
> > On Sat, Nov 3, 2012 at 12:04 AM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
> > > [...]
> > > * Upgrading every year, with an unreliable upgrade process, is not
> > > something you have to do with a proper stable OS
> >
> > I am not sure why you call it unreliable ... I *never* reinstall
>
>  Because I read the forums =)
>
>  It's not usually terribly unreliable for me either. But I'm a smart
>  cookie like you. I update my systems with yum and I know what I have to
>  do to make it work properly - I follow the instructions and I know how
>  to wiggle my way around dependency issues. This is second nature to me
>  as I'm sure it is to you. You've probably dealt with bugs on upgrades
>  before that you've forgotten about, even. Also, I don't use third party
>  repositories. Normal people do. Especially with a distro like Fedora
>  which doesn't ship Flash, proprietary drivers, Chrome...
>
>  I've been hanging around user forums for Mandriva, Fedora and Ubuntu for
>  a decade now and I can tell you, every time a new release of any of
>  those comes out, the forums get a big dump of people with problems
>  upgrading. 
What kind of problems? "I did upgrade and now my sound card does not
work?" or actually problems with the upgrade itself?
The former would just have happened with a reinstall as well.


>  The number of variables involved in one is astronomical. Note
>  that neither Red Hat nor Microsoft actually support major version
>  upgrades for their operating systems, 
Microsoft does. They do even sell upgrade boxes ...

>  much lower levels of churn, 
No they actually have way higher levels of churn ... just think about
it ... in fedora we are talking about 6 months worth of chrun not 5+
years. Can't speak for Red Hat but maybe this is one of the reasons
why they don't support upgrades.

>  (Also note how much trouble phone companies have
>  updating Android.) 
That has more to do with how bad forking is for maintenance ... we
don't really have this problem in fedora (ubuntu is driving themselves
into this corner but that's OT).

>  I also know what we do to test upgrades before we sign off on a
> release,
>  which is 'do a clean install of F-N in a VM and check it can be upgraded
>  to F-N+1'. If that passes, we ship. That is not a level of testing which
>  allows me to declare with confidence that our upgrade process is solid
>  and reliable ;) 
Well it means that the process works. Everything else are bugs in the
packages itself which you would have hit during a normal yum update
otherwise.

> > unless I really had to (moving one installation from i386 to
> x86_64).
> > Otherwise I always upgrade using either anaconda back in the days and
> > then preupgrade.
> >
> > There is some weird attitude that "upgrades don't work anyway people
> > should just reinstall". Not only is a reinstall a lot more work it is
> > just not something you could ask from a user to do every 6-12 months.
> >
> > Technically there is no difference between an upgrade and package
> > updates just the package set is larger, it just makes dealing with
> > stuff like usrmove easier. If an update from foo-1.0 to foo-2.0 breaks
> > the whole system it will regardless whether you upgrade from FN-1 to
> > FN or doing a "yum update" in a rolling release.
>
>  Well, kinda. The advantage of a rolling release is that it tends to
>  narrow the focus. You don't have a million people hitting five hundred
>  potentially destabilizing updates all at once; you have a million people
>  all getting one potentially destabilizing update at a time (or, at
>  least, a fairly small set at a time). When everyone starts yelling, you
>  can just look at what got updated the night before and probably find the
>  culprit. That's what happens with Rawhide, after all. And anyway, I
>  don't think a rolling release would be *better* from this point of view
>  - as with my other points, I think a rolling release would allow us to
>  do *just as well* while reducing our testing and development overheads.
>
>  In a rolling release model, everyone deals with foo-1.0 to foo-2.0, then
>  a week later they deal with bar-1.0 to bar-2.0, then a week later they
>  deal with monkeys-1.0 to monkeys-2.0...in a 'stable' release model,
>  everyone gets to deal with foo, bar, monkeys and five hundred other
>  changes all at once. Which is chaos on a stick. 
But then you have to deal with this kind of stuff every time you
update something. That's not really usable if you want to get work
done.
While the bigger upgrade leaves only hits you once or twice a year.

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Adam Williamson]

On Sat, 2012-11-03 at 00:44 +0100, drago01 wrote:

>  > The number of variables involved in one is astronomical. Note
>  > that neither Red Hat nor Microsoft actually support major version
>  > upgrades for their operating systems,
>  
>  Microsoft does. They do even sell upgrade boxes ... 
Well, it's a bit complicated. They didn't support 'true' upgrades from
XP to Win 7, for instance - the 'upgrade' process just did a fresh
install and then tried to copy back 'important' stuff like your desktop
layout. And if it goes wrong...well you can call tech support and
they'll do their best, but you're not getting a refund. And Windows
upgrades *do* go wrong. Corporate deployments of Windows, to my
knowledge, virtually never rely on the upgrade functionality.

>  > much lower levels of churn,
>  
>  No they actually have way higher levels of churn ... just think about
>  it ... in fedora we are talking about 6 months worth of chrun not 5+
>  years. Can't speak for Red Hat but maybe this is one of the reasons
>  why they don't support upgrades. 
True, that was a bad point; the average rate of churn is lower but the
churn between any two releases is big.

>  > (Also note how much trouble phone companies have
>  > updating Android.)
>  
>  That has more to do with how bad forking is for maintenance ... we
>  don't really have this problem in fedora (ubuntu is driving themselves
>  into this corner but that's OT).
>  
>  > I also know what we do to test upgrades before we sign off on a release,
>  > which is 'do a clean install of F-N in a VM and check it can be upgraded
>  > to F-N+1'. If that passes, we ship. That is not a level of testing which
>  > allows me to declare with confidence that our upgrade process is solid
>  > and reliable ;)
>  
>  Well it means that the process works. Everything else are bugs in the
>  packages itself which you would have hit during a normal yum update
>  otherwise. 
That's an oversimplification. A stock install only has a small part of
our *official* package set installed. Any given user's system might have
any of the others installed, or any third party repo (including a
graphics driver from a third party repo). On some upgrades we reinstall
the bootloader or do other disruptive things. And again, I'm not saying
we could do upgrades better; the fact that 'it'd be just as bad with
yum' is besides the point. My point is that major version upgrades are
such an intrinsically unreliable operation that any workflow which
requires people to do one once a year has problems. They're not
something you can realistically expect people to rely on.

Microsoft don't really expect you to upgrade Windows. They expect you to
buy a computer with Windows X on it, use it for three years, then throw
it away and buy a new computer with Windows Y on it. Red Hat expects
something similar for RHEL - they don't expect people to upgrade systems
from RHEL 5 to RHEL 6 on the fly. Corporations spend *years* planning OS
migrations, which usually involve buying new hardware, not upgrading
existing systems. This is an implicit acknowledgment that upgrades are
just not a great way to do things. I don't think we can realistically
expect Fedora to do it massively better. If you're going to do stable
releases of your operating system, it just doesn't make a lot of sense
to make people upgrade every twelve months. If you're going to have
stable releases, you should maintain them long enough that people don't
really rely on the upgrade function. That seems to be how the big boys
do it. If we can't do that, are the stable releases really achieving
much?

>  > In a rolling release model, everyone deals with foo-1.0 to
> foo-2.0, then
>  > a week later they deal with bar-1.0 to bar-2.0, then a week later they
>  > deal with monkeys-1.0 to monkeys-2.0...in a 'stable' release model,
>  > everyone gets to deal with foo, bar, monkeys and five hundred other
>  > changes all at once. Which is chaos on a stick.
>  
>  But then you have to deal with this kind of stuff every time you
>  update something. That's not really usable if you want to get work
>  done.
>  While the bigger upgrade leaves only hits you once or twice a year. 
My position is that the people who use Fedora and the kind of people we
really _want_ to use Fedora can cope with it. Remember, I'm not
proposing it be as bad as Rawhide; we have the whole Bodhi karma process
to work with. I think it's plausible to design a process where people
only rarely have trouble with updates, even ones that are theoretically
pretty messy; about the same frequency they'd have had trouble with
upgrading our stable releases. Remember, I mentioned the kernel team as
a model; despite my sound gripe, they seem to be managing pretty well in
bumping older releases to newer kernels without causing massive
breakage. They do cause some problems...but we get 'some problems'
anyway.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Reindl Harald]

Am 03.11.2012 00:58, schrieb Adam Williamson:
>  Microsoft don't really expect you to upgrade Windows. They expect
> you to
>  buy a computer with Windows X on it, use it for three years, then throw
>  it away and buy a new computer with Windows Y on it. Red Hat expects
>  something similar for RHEL - they don't expect people to upgrade systems
>  from RHEL 5 to RHEL 6 on the fly. Corporations spend *years* planning OS
>  migrations, which usually involve buying new hardware, not upgrading
>  existing systems. This is an implicit acknowledgment that upgrades are
>  just not a great way to do things. I don't think we can realistically
>  expect Fedora to do it massively better. If you're going to do stable
>  releases of your operating system, it just doesn't make a lot of sense
>  to make people upgrade every twelve months. If you're going to have
>  stable releases, you should maintain them long enough that people don't
>  really rely on the upgrade function. That seems to be how the big boys
>  do it. If we can't do that, are the stable releases really achieving
>  much? 
look below, i prove you the opposite

Filesystem created: Mon Aug 18 06:48:05 2008

this is the rootfs, which means it was installed with F9
now it has F17, this machine is from the same golden-master
as any other machine in the whole company and there is running
any service you can imagine on Fedora in production

ANY upgrade was done with yum

so NO fedora is not as bad as you thin in upgrades
the really important ting it that it does not get worser!

YES these are Vmware-guests and that is why UPGRADES becoming
more and more important - the times where you plan new hardware
and install it with a new OS are gone

these days you install the OS on hardware X, buy hardware Y
and move the whole setup live to the new hardware, the same
i am doing even for physical setups on RAID10 - bouy a new
machine, start it with the old disks, maybe re-create the
initrd and AFTER that if i find it nice change disk by
disk and re-sync the RAID or even stuck on the old disks
____________________________

[root@arrakis:~]$ tune2fs -l /dev/sdb1
tune2fs 1.42.3 (14-May-2012)
Filesystem volume name:   /
Last mounted on:          /
Filesystem UUID:          918f24a7-bc8e-4da5-8a23-8800d5104421
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype
needs_recovery extent flex_bg
sparse_super large_file uninit_bg dir_nlink
Filesystem flags:         signed_directory_hash
Default mount options:    journal_data_writeback
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              393216
Block count:              1572354
Reserved block count:     15723
Free blocks:              999376
Free inodes:              325103
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      383
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Filesystem created:       Mon Aug 18 06:48:05 2008
Last mount time:          Sun Oct 28 19:00:37 2012
Last write time:          Sun Oct 28 19:00:36 2012
Mount count:              18
Maximum mount count:      -1
Last checked:             Tue Mar 27 00:36:36 2012
Check interval:           31104000 (12 months)
Next check after:         Thu Mar 21 23:36:36 2013
Lifetime writes:          1119 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Journal inode:            8
First orphan inode:       34371
Default directory hash:   tea
Directory Hash Seed:      1e9d689f-15fe-4c0d-aaba-9d323049c7f4
Journal backup:           inode blocks

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Adam Williamson]

On Sat, 2012-11-03 at 01:07 +0100, Reindl Harald wrote:
>  Am 03.11.2012 00:58, schrieb Adam Williamson:
>  > Microsoft don't really expect you to upgrade Windows. They expect you to
>  > buy a computer with Windows X on it, use it for three years, then throw
>  > it away and buy a new computer with Windows Y on it. Red Hat expects
>  > something similar for RHEL - they don't expect people to upgrade systems
>  > from RHEL 5 to RHEL 6 on the fly. Corporations spend *years* planning OS
>  > migrations, which usually involve buying new hardware, not upgrading
>  > existing systems. This is an implicit acknowledgment that upgrades are
>  > just not a great way to do things. I don't think we can realistically
>  > expect Fedora to do it massively better. If you're going to do stable
>  > releases of your operating system, it just doesn't make a lot of sense
>  > to make people upgrade every twelve months. If you're going to have
>  > stable releases, you should maintain them long enough that people don't
>  > really rely on the upgrade function. That seems to be how the big boys
>  > do it. If we can't do that, are the stable releases really achieving
>  > much?
>  
>  look below, i prove you the opposite 
Please keep in mind the overall argument I'm making here. I'm not
interested in trivial point-scoring. I have machines that have been
upgraded for a long time too. Your mail doesn't really speak to the
higher level questions here.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Reindl Harald]

Am 03.11.2012 01:09, schrieb Adam Williamson:
>  On Sat, 2012-11-03 at 01:07 +0100, Reindl Harald wrote:
> > Am 03.11.2012 00:58, schrieb Adam Williamson:
> >> Microsoft don't really expect you to upgrade Windows. They expect you to
> >> buy a computer with Windows X on it, use it for three years, then throw
> >> it away and buy a new computer with Windows Y on it. Red Hat expects
> >> something similar for RHEL - they don't expect people to upgrade systems
> >> from RHEL 5 to RHEL 6 on the fly. Corporations spend *years* planning OS
> >> migrations, which usually involve buying new hardware, not upgrading
> >> existing systems. This is an implicit acknowledgment that upgrades are
> >> just not a great way to do things. I don't think we can realistically
> >> expect Fedora to do it massively better. If you're going to do stable
> >> releases of your operating system, it just doesn't make a lot of sense
> >> to make people upgrade every twelve months. If you're going to have
> >> stable releases, you should maintain them long enough that people don't
> >> really rely on the upgrade function. That seems to be how the big boys
> >> do it. If we can't do that, are the stable releases really achieving
> >> much?
> >
> > look below, i prove you the opposite
>  
>  Please keep in mind the overall argument I'm making here. I'm not
>  interested in trivial point-scoring. I have machines that have been
>  upgraded for a long time too. Your mail doesn't really speak to the
>  higher level questions here 
the overall argument of MINE is Fedora IS stable
Fedora CAN be upgraded
Fedora has a good overall level of upgrades

these things have to be improved and not thrown away
by "we are doing it not good enough, so we stop doing it"

and i am sure one big improvement would be to relax
the meaning of a release-date, often it is OK and
there are no large blockers, sometimes it is not so
easy at that is the time where free software without
marketing bullshit have the valif option to say

WE DELAY THE NEXT VERSION TO A UNKNOWN POINT IN TIME
IT WILL HAPPEN WHEN IT IS READY FOR IT

in the meantime the current release would be maintained
only with real important updates like security as it is
done for F17/F17 now and ALL users would be happy

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[drago01]

On Sat, Nov 3, 2012 at 12:58 AM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  My position is that the people who use Fedora and the kind of people
> we
>  really _want_ to use Fedora can cope with it. 
Maybe the majority can maybe they can't. But as evident by this thread
even fedora *developers* don't want to deal with such stuff.
But rather get work done. Do you really think that users are that much
different?

>  Remember, I'm not
>  proposing it be as bad as Rawhide; we have the whole Bodhi karma process
>  to work with. I think it's plausible to design a process where people
>  only rarely have trouble with updates, even ones that are theoretically
>  pretty messy; about the same frequency they'd have had trouble with
>  upgrading our stable releases. 
That basically means you don't release anything and just release a
huge update every six months. Don't really see what this gains us
other then installation becoming an untested path.
The installation process and images have to be up2date though to be
able to deal with current hardware.

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Adam Williamson]

On Sat, 2012-11-03 at 10:52 +0100, drago01 wrote:
>  On Sat, Nov 3, 2012 at 12:58 AM, Adam Williamson
> <awilliam(a)redhat.com&gt; wrote:
>  > My position is that the people who use Fedora and the kind of people we
>  > really _want_ to use Fedora can cope with it.
>  
>  Maybe the majority can maybe they can't. But as evident by this thread
>  even fedora *developers* don't want to deal with such stuff. 
I think some of them were rather misunderstanding my point and my
suggestion, which was my fault for phrasing my initial mail in an overly
negative way (that I didn't realize until I read it back).

>  But rather get work done. Do you really think that users are that
> much
>  different? 
I don't think rolling release and getting work done are incompatible. As
I mentioned, I run Branched permanently on my desktop - so it rolls from
'pre-Alpha' state through to 'stable' state briefly and then back to
'pre-Alpha' again, on a constant loop - and I do almost all my work on
that. We could build a light rolling-release distro that was
substantially more reliable than that. Again, my fundamental point is
that we could achieve a sufficient level of reliability for Fedora's
purposes - the same level of reliability we currently achieve, which I
think the kinds of people we're talking about are happy with - on a
lighter release model than 'do a "stable release" every six months come
hell or high water' or 'three-track rolling, Debian style, with a very
slow-moving "stable" track'.

>  > Remember, I'm not
>  > proposing it be as bad as Rawhide; we have the whole Bodhi karma process
>  > to work with. I think it's plausible to design a process where people
>  > only rarely have trouble with updates, even ones that are theoretically
>  > pretty messy; about the same frequency they'd have had trouble with
>  > upgrading our stable releases.
>  
>  That basically means you don't release anything and just release a
>  huge update every six months. Don't really see what this gains us
>  other then installation becoming an untested path.
>  The installation process and images have to be up2date though to be
>  able to deal with current hardware. 
Eh? That's not what I said at all. What I said was that I think in a
well-managed rolling release model, users would actually run into
trouble only about as often as they already do anyway. I don't mean
they'd only get updates every six months, I mean they'd only get updates
which _broke stuff_ on average every six months. Or less.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Kevin Fenzi]

On Sat, 03 Nov 2012 09:26:43 -0700
Adam Williamson <awilliam(a)redhat.com&gt; wrote:

>  I don't think rolling release and getting work done are
> incompatible.
>  As I mentioned, I run Branched permanently on my desktop - so it
>  rolls from 'pre-Alpha' state through to 'stable' state briefly and
>  then back to 'pre-Alpha' again, on a constant loop - and I do almost
>  all my work on that. We could build a light rolling-release distro
>  that was substantially more reliable than that.  
But I think that might be a non representative case. Before branched
happens currently you get all the stuff like: Mass rebuilds, major
upgrades that take a bunch of work to get all done, etc. So, you might
not be considering them in your view above... but if we were rolling
then you would have to deal with new boost, or png changing, or rpm
format changing, etc, and there is seldom a way to cut these up into
smaller bits. 

So, in a rolling release when say png changes, we would have to push
all that change out to users in a big chud. They would have to do them
somewhat quickly if they wanted any updates that would be depending on
it/behind it. 

>  Again, my fundamental
>  point is that we could achieve a sufficient level of reliability for
>  Fedora's purposes - the same level of reliability we currently
>  achieve, which I think the kinds of people we're talking about are
>  happy with - on a lighter release model than 'do a "stable release"
>  every six months come hell or high water' or 'three-track rolling,
>  Debian style, with a very slow-moving "stable" track'. 
I'm not convinced. ;) 

In any case, I think we do need to look at release cycle changes or at
the very least Feature process revamp. 

kevin

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Bruno Wolff III]

On Sat, Nov 03, 2012 at 11:11:18 -0600,
   Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
> In any case, I think we do need to look at release cycle changes or at
> the very least Feature process revamp. 
And get comments from other than developers. Marketting might have serious 
concerns about the loss of exposure not having releases would result in.

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Jiri Eischmann]

----- Original Message -----
>  From: "Bruno Wolff III" <bruno(a)wolff.to&gt;
>  To: "Kevin Fenzi" <kevin(a)scrye.com&gt;
>  Cc: devel(a)lists.fedoraproject.org
>  Sent: Saturday, November 3, 2012 7:37:45 PM
>  Subject: Re: Rolling release model philosophy (was Re: Anaconda is totally	trashing the
> F18 schedule (was Re: f18:
>  how to install into a LVM	partitions (or RAID)))
>  
>  On Sat, Nov 03, 2012 at 11:11:18 -0600,
>     Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  >
>  >In any case, I think we do need to look at release cycle changes or
>  >at
>  >the very least Feature process revamp.
>  
>  And get comments from other than developers. Marketting might have
>  serious
>  concerns about the loss of exposure not having releases would result
>  in. 
This is a very valid argument. I understand this is a devel list, so we should stay on the
technical level, but if we discuss such broad changes that affect the whole project, we
should also take into account other aspects.

Switching to rolling release would have a *huge* negative impact on marketing! It's
releases what makes the fuzz and their announcements get beyond our current user base. We
would have no release parties, no codenames. We would lose the product. I wonder what
impact it would have on Fedora adoption by cloud providers. I think it's much more
understandable not only for them, but also for their customers to take Fedora 17 than some
monthly build.

I personally don't like the whole idea of switching to rolling release. Although I see
some pros, I see a lot of cons that would outweight the pros. I've come across a few
rolling release distributions (Debian Testing, Arch Linux, Gentoo,...) and I don't
think they work if you want to achieve some level of stability and predictability. I
rather see some changes in Rawhide so that it becomes a usable distribution that people
more interested in bleeding edge can use. Because now Rawhide does not even serve testing
purposes because almost no one is using it. It'd like to see its stability on the
level where Fedora branched is now (it's not a smooth experience, you should expect
problems, use skip-broken from time to time, but it's usable).

Jiri

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[mike cloaked]

On Sun, Nov 4, 2012 at 9:07 PM, Jiri Eischmann <jeischma(a)redhat.com&gt; wrote:

>  This is a very valid argument. I understand this is a devel list, so we
>  should stay on the technical level, but if we discuss such broad changes
>  that affect the whole project, we should also take into account other
>  aspects.
>
>  Switching to rolling release would have a *huge* negative impact on
>  marketing! It's releases what makes the fuzz and their announcements get
>  beyond our current user base. We would have no release parties, no
>  codenames. We would lose the product. I wonder what impact it would have on
>  Fedora adoption by cloud providers. I think it's much more understandable
>  not only for them, but also for their customers to take Fedora 17 than some
>  monthly build.
>
>  
Does anyone have any reliable statistics about the number of users who feel
that release parties and codenames are important to them?

There will no doubt be some people for whom the idea of running a
particular codenamed release is important - but there will also be others
for whom a high quality established linux distribution that is reliable and
up to date irrespective of its codename is more important. Marketing
feedback if it is possible to give the relative number of users in each
camp would be helpful here? Gathering such statistics is likely difficult
though.


>  I personally don't like the whole idea of switching to rolling
> release.
>  Although I see some pros, I see a lot of cons that would outweight the
>  pros. I've come across a few rolling release distributions (Debian Testing,
>  Arch Linux, Gentoo,...) and I don't think they work if you want to achieve
>  some level of stability and predictability. 

Arch linux is stable and reliable and predictable - I use it every day -
you need to ask users of the other distributions named whether users feel
they are similarly stable and predictable or not for the most part.

Does anyone have any relative user stats on the various distros?

Do any web sites gather stats which might indicate hit rates coming from
different distros?

These data are difficult to get so in the end a clear goal for any
distribution has to be agreed on and then executed - if Fedora wishes to go
to rolling Rawhide but a bit more stable that at present and it is possible
to do that - then developers must agree at least on some kind of overall
vote maybe?  In the end the users will guide whether the route taken is
being adopted widespread among the community.  You get some idea of users
interested from feedback to the devel list, or via bodhi I guess?

One other question that is hard to answer is whether a particular change in
direction is achievable since it depends on developers adopting it and
agreeing to work on it - inevitably some will not want to go to any new
route - but will the new direction excite other developers to come on board
that were not there before and make up any loss?

The way I see it is that the two routes are a bit like asking if people
like meat or fish for the main course at a meal - there will be a split
opinion - and there are good points about both!  Some people may be
allergic to one or other though!

Is there an objective list of pros and cons that can be judged without bias
in favour of rolling release or periodic releases so that a logical
weighing of the relative merits of both approaches can be considered? If
that goes in favour of rolling release then can it be achieved with the
tools available without too much effort? If new tools have to be built
within the Fedora Framework is there enough effort and willingness to build
them?

-- 
mike c

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Jiri Eischmann]

mike cloaked píše v Ne 04. 11. 2012 v 21:44 +0000:
>  On Sun, Nov 4, 2012 at 9:07 PM, Jiri Eischmann
> <jeischma(a)redhat.com&gt;
>  wrote:
>          
>          
>          This is a very valid argument. I understand this is a devel
>          list, so we should stay on the technical level, but if we
>          discuss such broad changes that affect the whole project, we
>          should also take into account other aspects.
>          
>          Switching to rolling release would have a *huge* negative
>          impact on marketing! It's releases what makes the fuzz and
>          their announcements get beyond our current user base. We would
>          have no release parties, no codenames. We would lose the
>          product. I wonder what impact it would have on Fedora adoption
>          by cloud providers. I think it's much more understandable not
>          only for them, but also for their customers to take Fedora 17
>          than some monthly build.
>          
>  
>  
>  Does anyone have any reliable statistics about the number of users who
>  feel that release parties and codenames are important to them?  
Release parties and codenames were just examples. It's about the buzz
around releases. You can check Google Trends where you find peaks in
number of searches for Fedora after every release. Or fp.org monthly
stats. You would lose reviews, that are usually published after
releases, because I don't see any reviews of rolling release
distributions by main magazines. Etc.

BTW this is not just about current Fedora users. Marketing is mainly
about potential users. 

>  There will no doubt be some people for whom the idea of running a
>  particular codenamed release is important - but there will also be
>  others for whom a high quality established linux distribution that is
>  reliable and up to date irrespective of its codename is more
>  important. Marketing feedback if it is possible to give the relative
>  number of users in each camp would be helpful here? Gathering such
>  statistics is likely difficult though.
>   
>          I personally don't like the whole idea of switching to rolling
>          release. Although I see some pros, I see a lot of cons that
>          would outweight the pros. I've come across a few rolling
>          release distributions (Debian Testing, Arch Linux, Gentoo,...)
>          and I don't think they work if you want to achieve some level
>          of stability and predictability. 
>  
>  
>  Arch linux is stable and reliable and predictable - I use it every day
>  - you need to ask users of the other distributions named whether users
>  feel they are similarly stable and predictable or not for the most
>  part. 
Well, as someone has already said here: stability and reliability are
relative terms. I used Arch Linux for a while and I didn't find it
stable and reliable on the level where I'd like to see Fedora. If you
have to read release notes before every update to make sure you know
what might break and how to fix it, then you're not using a system that
would be appealing to a large number of user. And Fedora has always been
aiming much broader audience than Gentoo or Arch. 

>  Does anyone have any relative user stats on the various distros?
>  
>  
>  Do any web sites gather stats which might indicate hit rates coming
>  from different distros? 
>  
>  
>  These data are difficult to get so in the end a clear goal for any
>  distribution has to be agreed on and then executed - if Fedora wishes
>  to go to rolling Rawhide but a bit more stable that at present and it
>  is possible to do that - then developers must agree at least on some
>  kind of overall vote maybe?  In the end the users will guide whether
>  the route taken is being adopted widespread among the community.  You
>  get some idea of users interested from feedback to the devel list, or
>  via bodhi I guess?
>  
>  
>  One other question that is hard to answer is whether a particular
>  change in direction is achievable since it depends on developers
>  adopting it and agreeing to work on it - inevitably some will not want
>  to go to any new route - but will the new direction excite other
>  developers to come on board that were not there before and make up any
>  loss?
>  
>  
>  The way I see it is that the two routes are a bit like asking if
>  people like meat or fish for the main course at a meal - there will be
>  a split opinion - and there are good points about both!  Some people
>  may be allergic to one or other though!
>  
>  
>  Is there an objective list of pros and cons that can be judged without
>  bias in favour of rolling release or periodic releases so that a
>  logical weighing of the relative merits of both approaches can be
>  considered? If that goes in favour of rolling release then can it be
>  achieved with the tools available without too much effort? If new
>  tools have to be built within the Fedora Framework is there enough
>  effort and willingness to build them?
>  
>  
>  -- 
>  mike c
>

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Mathieu Bridon]

On Monday, November 05, 2012 06:56 PM, Jiri Eischmann wrote:
>  mike cloaked píše v Ne 04. 11. 2012 v 21:44 +0000:
> > On Sun, Nov 4, 2012 at 9:07 PM, Jiri Eischmann <jeischma(a)redhat.com&gt;
> > wrote:
> >
> >
> >          This is a very valid argument. I understand this is a devel
> >          list, so we should stay on the technical level, but if we
> >          discuss such broad changes that affect the whole project, we
> >          should also take into account other aspects.
> >
> >          Switching to rolling release would have a *huge* negative
> >          impact on marketing! It's releases what makes the fuzz and
> >          their announcements get beyond our current user base. We would
> >          have no release parties, no codenames. We would lose the
> >          product. I wonder what impact it would have on Fedora adoption
> >          by cloud providers. I think it's much more understandable not
> >          only for them, but also for their customers to take Fedora 17
> >          than some monthly build.
> >
> >
> >
> > Does anyone have any reliable statistics about the number of users who
> > feel that release parties and codenames are important to them?
>
>  Release parties and codenames were just examples. It's about the buzz
>  around releases. You can check Google Trends where you find peaks in
>  number of searches for Fedora after every release. 
That just means our marketing is virtually inexistant between two releases.

A rolling release model would mean that our buzz would be lower than the 
peak values, but it would be constant.

Depending on how you look at it, it could be a net win.


-- 
Mathieu

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Nicu Buculei]

On 11/05/2012 01:13 PM, Mathieu Bridon wrote:
>  On Monday, November 05, 2012 06:56 PM, Jiri Eischmann wrote:
> > mike cloaked píše v Ne 04. 11. 2012 v 21:44 +0000:
> >>
> >> Does anyone have any reliable statistics about the number of users who
> >> feel that release parties and codenames are important to them?
> >
> > Release parties and codenames were just examples. It's about the buzz
> > around releases. You can check Google Trends where you find peaks in
> > number of searches for Fedora after every release.
>
>  That just means our marketing is virtually inexistant between two releases.
>
>  A rolling release model would mean that our buzz would be lower than the
>  peak values, but it would be constant. 
It does not work this way :)

The number of volunteers promoting Fedora is limited and their time is 
limited, do not expect them to promote Fedora 24 hours a day, 365 days a 
year, they will focus on important things, like the releases (but not only).

Also, is the matter of saturation: the general public has its own 
priorities, if you barrage them with a constant flux of Fedora related 
news, they will quickly become bored: what? yet another feature in 
Fedora? just like the other gazillion they make public every other day?

-- 
nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com

-- 
nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/
photography: http://photoblog.nicubunu.ro/

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[mike cloaked]

On Mon, Nov 5, 2012 at 10:56 AM, Jiri Eischmann <eischmann(a)redhat.com&gt;wrote:

>  Release parties and codenames were just examples. It's about the buzz
>  around releases. You can check Google Trends where you find peaks in
>  number of searches for Fedora after every release. Or fp.org monthly
>  stats. You would lose reviews, that are usually published after
>  releases, because I don't see any reviews of rolling release
>  distributions by main magazines. Etc.
>  
Here is one:
http://www.linuxuser.co.uk/features/under-the-hood-with-arch-and-gentoo

> From a few weeks ago! 

>  BTW this is not just about current Fedora users. Marketing is mainly
>  about potential users.
>  
Sure -

>  Well, as someone has already said here: stability and reliability are
>  relative terms. I used Arch Linux for a while and I didn't find it
>  stable and reliable on the level where I'd like to see Fedora. If you
>  have to read release notes before every update to make sure you know
>  what might break and how to fix it, then you're not using a system that
>  would be appealing to a large number of user. And Fedora has always been
>  aiming much broader audience than Gentoo or Arch.
>  
Generally speaking for arch linux you don't get "release notes" for
packages as such - and for the most part a regular update merely requires
the following command:

#pacman -Syu

then accept or reject running the set of updates that is offered. Not a big
deal - now and again there is an announcement on arch-announce (also on
their main web page) which says run the following command (or two!) before
the next update or similar - hardly a major hassle every few months.

It's true that for my Fedora boxes I just have to run:

#yum -y update

or

#yum update and then accept or reject the set of updates offered - much the
same really.

however for F16 which is current I don't have the latest KDE, or the latest
systemd, or the latest libreoffice etc - which I do on my arch boxes. For
any user that does not mind having KDE work OK but not with the latest
round of bug fixes and new features it is fine. Similar with the other
packages. Chrome is not offered as mainline by either distro but on Fedora
google has a yum repo - so I run the latest chrome just fine on F16 - and
in arch there is the latest via the AUR system so I run the latest chrome
there too. But I won't have to run any re-install on the arch boxes whereas
in order to keep my F16 boxes supported I will have to re-install around
the end of the year. I know there are constant reminders from people who
say they have never re-installed and just preupgrade but my own experience
with that around the F9 timeframe was really poor - and I ended up doing a
sequence of manual steps along with various yum upgrades/updates and kept a
box going through two releases before deciding that a clean install was
about the only sensible way forward at that time - maybe it is really quite
trouble free updating from one release to another these days - so maybe my
F16 boxes could be upgraded nice and easy to F17 and F18 with only a few
commands and a bit of a wait - but I am not convinced it is worth the risk
as one of them is a server!

So it is "horses for courses" - I have two courses and a number of horses
and so far none of the horses have died!

-- 
mike c

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Ben Cotton]

On Mon, Nov 5, 2012 at 5:56 AM, Jiri Eischmann <eischmann(a)redhat.com&gt; wrote:
>  Release parties and codenames were just examples. It's about the buzz
>  around releases. You can check Google Trends where you find peaks in
>  number of searches for Fedora after every release. Or fp.org monthly
>  stats. You would lose reviews, that are usually published after
>  releases, because I don't see any reviews of rolling release
>  distributions by main magazines. Etc.
>  
Documentation is another concern. It's hard to maintain static guides
with a rolling release. The Arch Wiki is a great resource to be sure,
but it's ever-changing and not easy to find old information if you're
not running with current. The guides that the Fedora Docs group
produce are a great resource for the community, and it would be a
major strain on our resources to keep up with rolling releases.

My personal opinion is that a rolling release might be nice (not nice
enough, apparently to use Rawhide, but that's more about laziness than
anything), but I'm not convinced it's what's best for the community at
large.

--
Ben Cotton
Fedora Docs Leader

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Alek Paunov]

On 03.11.2012 18:26, Adam Williamson wrote:
>  On Sat, 2012-11-03 at 10:52 +0100, drago01 wrote:
>
>  Eh? That's not what I said at all. What I said was that I think in a
>  well-managed rolling release model, users would actually run into
>  trouble only about as often as they already do anyway. I don't mean
>  they'd only get updates every six months, I mean they'd only get updates
>  which _broke stuff_ on average every six months. Or less.
>  
Adam, I think that the current "rolling release" discussion as many 
other "high interest" general ones in the recent months are pointless 
without some form of explicit definition and statistics of the current 
(and desired) distinct Fedora user profiles.

You mostly talk about the uncle Bob's profile (witch is the 2nd most 
present profile across the forums); Our vocal member Reinald belongs to 
one of the psychological subtypes of the "mad sysadmin" profile; Tom, 
which said yesterday that he would not be interested in rolling Fedora, 
into third profile, etc.

BTW, personally I think, the uncle Bob profile currently most suffers 
the lack of the real package manager interface (at least under Gnome, I 
do not have a clue for KDE) - I see this issue as one with even high 
priority for uncle Bob than the lack of smooth upgrade scenario.

So, my concrete proposal is to postpone all general discussions for a 
little, up to the moment when we describe as much as possible in detail 
let's say 16 Fedora user profiles and sub-profiles (at least on the 
wiki) and estimate somehow their population (may be along with the 
project leaders concept about the profiles witch Fedora actually is 
intended to seek for).

Without any data at hand to back the prioritization and approach variant 
efficiency/suitability claims, I think it looks impossible to be 
achieved any level of consensus (especially in that list, as you know 
far better than me).

Kind Regards,
Alek

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Alek Paunov]

On 03.11.2012 19:17, Alek Paunov wrote:
>  Adam, I think that the current "rolling release" discussion as many
>  other "high interest" general ones in the recent months are pointless
>  without some form of explicit definition and statistics of the current
>  (and desired) distinct Fedora user profiles.
>  
Just because I said "general ones" which might be somewhat misleading, 
several examples:

* The importance of Secure Boot workaround (in the proposed form)
* The amount of the negative impact of /tmp on ramfs feature
* The importance of a "Software Center" existence

etc.

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Simo Sorce]

On Sat, 2012-11-03 at 00:44 +0100, drago01 wrote:
>  > much lower levels of churn,
>  
>  No they actually have way higher levels of churn ... just think about
>  it ... in fedora we are talking about 6 months worth of chrun not 5+
>  years. Can't speak for Red Hat but maybe this is one of the reasons
>  why they don't support upgrades.
>   
nope, Adam is right, the level of churn is *a lot* lower.

Microsoft rarely changes existing components, and never breaks ABIs no
matter what, at most they add new stuff.

And when they do need to make a lower level change they design it in
early stages and then spend a lot of time testing even 3rd party apps to
make sure they don't break them all, and for more popular ones they even
built workarounds in the system so they don't break.

Also their package set is a lot smaller. They do not package a lot of
applications like we do. However the main differentiator is ABI
stability, MS simply has a *lot* less issues on upgrades because they
have an ABI stability that we can only dream of, in the FOSS world.

The only component that is comparable is the kernel. Almost everything
else in user space is just not comparable.

note that this is "also" our strength in some respect because it allows
the system to evolve a lot more quickly, but it also means upgrades are
simply going to break stuff, and that's not so great for desktop
environments and scare the hell off of 3rd party vendors.
You may notice we do not have many 3rd party vendors, I think ABI
instability is reason number, 1, 2 and 3 of why we can't have reliable
third parties with a community built OS.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Alek Paunov]

On 04.11.2012 19:25, Simo Sorce wrote:

>  note that this is "also" our strength in some respect
> because it allows
>  the system to evolve a lot more quickly, but it also means upgrades are 
Indeed.

>  simply going to break stuff, and that's not so great for desktop
>  environments and scare the hell off of 3rd party vendors.
>  You may notice we do not have many 3rd party vendors, I think ABI
>  instability is reason number, 1, 2 and 3 of why we can't have reliable
>  third parties with a community built OS.
>  
I agree completely with all your points.

A possibly viable alternative for the ABIs freezing (which we can not 
ensure anyway) is the C/C++/etc tooling - If we arm upstreams, packagers 
and 3rd parties with powerful source tools (API migration/checking), 
just like Google does internally, unsing the  Clang tooling, witch was 
developed exactly for this purpose.

The GCC/OpenJDK tooling development is not something appropriate as 
effort for the manpower of almost any upstream, but IMHO should be seen 
as important goal for relatively big player like Fedora.

Kind Regards,
Alek

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Simo Sorce]

On Sun, 2012-11-04 at 19:47 +0200, Alek Paunov wrote:
>  On 04.11.2012 19:25, Simo Sorce wrote:
>  
>  > note that this is "also" our strength in some respect because it allows
>  > the system to evolve a lot more quickly, but it also means upgrades are
>  
>  Indeed.
>  
>  > simply going to break stuff, and that's not so great for desktop
>  > environments and scare the hell off of 3rd party vendors.
>  > You may notice we do not have many 3rd party vendors, I think ABI
>  > instability is reason number, 1, 2 and 3 of why we can't have reliable
>  > third parties with a community built OS.
>  >
>  
>  I agree completely with all your points.
>  
>  A possibly viable alternative for the ABIs freezing (which we can not 
>  ensure anyway) is the C/C++/etc tooling - If we arm upstreams, packagers 
>  and 3rd parties with powerful source tools (API migration/checking), 
>  just like Google does internally, unsing the  Clang tooling, witch was 
>  developed exactly for this purpose.
>  
>  The GCC/OpenJDK tooling development is not something appropriate as 
>  effort for the manpower of almost any upstream, but IMHO should be seen 
>  as important goal for relatively big player like Fedora. 
Unfortunately it won't work, unless you are ready to also go and mark
reliable and unreliable upstreams, which is ... difficult.

The reason I say so is that I know for sure not all upstreams are
willing to maintain ABI compatibility. There are various degrees but
some go for absolute ABI compatibility at all costs (glibc) to "I'll
break the ABI on purpose (or because I don't care) at every upgrade
(won't try to name names).

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Alek Paunov]

On 05.11.2012 15:57, Simo Sorce wrote:
> >
> > A possibly viable alternative for the ABIs freezing (which we can not
> > ensure anyway) is the C/C++/etc tooling - If we arm upstreams, packagers
> > and 3rd parties with powerful source tools (API migration/checking),
> > just like Google does internally, unsing the  Clang tooling, witch was
> > developed exactly for this purpose.
> >
> > The GCC/OpenJDK tooling development is not something appropriate as
> > effort for the manpower of almost any upstream, but IMHO should be seen
> > as important goal for relatively big player like Fedora.
>
>  Unfortunately it won't work, unless you are ready to also go and mark
>  reliable and unreliable upstreams, which is ... difficult.
>
>  The reason I say so is that I know for sure not all upstreams are
>  willing to maintain ABI compatibility. There are various degrees but
>  some go for absolute ABI compatibility at all costs (glibc) to "I'll
>  break the ABI on purpose (or because I don't care) at every upgrade
>  (won't try to name names).
>  
My point was about the second group (dependency providers with evolving 
ABIs) and more specifically about the affected packages (their users - 
dependency consumers). When the consumers are short on resources or just 
don't really care so much about the current Fedora consistency, the 
problem naturally lands at the responsibility of the respective Fedora 
maintainers.

The whole dance would be sufficiently different if we provide the 
cooperative upstreams with powerful tools for aligning their projects 
with the current/prepared release "compound" ABI.

IMO, this means Fedora VMs (not necessarily sponsored by the project, I 
am sure that the Cloud SIG has enough magic at hand to orchestrate 
community/upstreams provided instances) and preinstalled compiler 
plugins based tooling - easy to use instruments for checking and fixing 
their sources according the release environment state.

The above applies also for the third parties (propriety software vendors 
and these with open source licenses but not so open style of 
development) - they probably will spent few dozens of hours to "lint", 
once we provide them with ready to use "login and type 'make'"
environment.

Of course, not any upstream would be willing to cooperate - in this case 
we will have to handle the issue with our own resources, but again the 
tooling can reduce the time spent by the packagers with an order of 
magnitude.

Fedora is almost always the First, once we start doing this proactive 
"Upstreams alignment" technology and effort, maybe other Linux OS 
vendors would join too.

Kind Regards,
Alek

New release cycle proposal (was Rolling release model philosophy (was ...))

[Matthieu Gautier]

Hello all,

I'm not a Fedora developer, nor package maintainer. I'm a French Fedora
Ambassador for a long time. (I should say "I was" cause I don't do to
many things last time, just wake up every 6 months for Fedora releases
and other events).
I'm also a developer but that's not about Fedora.

While reading this thread, an idea came to me about the Fedora release
cycle.

First, while discussing with fedora users, from events, friends, and
parents (real Adam's uncle Bob), the following points can be inferred:
 - They like the blending edge part of Fedora.
 - They want stable releases.
Not always in the same time, it's depending of user profile. It seems a
little antagonist, but that's what they want.
(By the way, they are mostly happy with Fedora)

What I propose is a new release cycle: One release every year and a
"preview" (not sure of the name) release between them.
- Small features can come in whatever release.
- Big features (libc, anaconda, systemd, gnome3, wayland...) can come in
preview release only.
- FedoraN releases have a lifetime of 2 years.
- FedoraNPreview releases have a lifetime of 6 months.

For example, if we start from Fedora20 at beginning of 2014:
- Fedora20(jan 2014) is a stable release. (Fedora18 eol, actual way of
doing)
- Fedora21Preview(jul 2014) is an "unstable" release. (Fedora 19 eol)
- Fedora21(jan 2015) is a stable release. (Fedora21Preview eol, new way
of doing)
- Fedora22Preview(jul 2015)
- Fedora22(jan 2016) (Fedora22Preview and Fedora20 eol)
- Fedora23Preview(jul 2016)
- Fedora23(jan 2017) (Fedora23Preview and Fedora21 eol)
- ...

Preview version doesn't mean unstable. It means version as we have now,
but more tolerant to bug ("Here the new version of Fedora with latest
features. We make our best, but maybe not enough. You're aware of it.")
Stable version is mainly preview version stabilized plus other (small)
features.


For users:
- Users wanting stable (long time support) version can install it every
2 year.
- Users wanting new versions but stable can install it every year
- User wanting blending edge can install a version every 6 months

For devs:
Still a version every 6 months, new features can still be added. Just
one out of two versions has to be more stable (no big feature)

For QA:
Still a version every 6 months. More QA for stable versions

For Ambassadors/Marketing:
Still a version every 6 months. Nothing change.

For maintainers/packagers:
For now there are 4 versions at the same time: Fn-1, Fn to maintain and
Fn+1, Rawhide in dev
With my proposition:
- Between Fn and Fn+1prev: 2 versions (Fn-1, Fn) to maintain and 2
versions (Fn+1prev, rawhide) in dev
- Between Fnprev and Fn: 3 versions (Fn-2, Fn-1, Fnprev) to maintain and
1(2) version (Fn, rawhide) in dev
During 6 months, there is one version more to maintain, but changes
between Fnprev and Fn are not breaking stuff.

We could also create some king of "half end of life" : stable releases
get all updates for 1 year, and security updates only for the second
year. This could reduce maintainers' work.

This way we reach the two worlds:
- Users can chose the version they want (long time support, stable,
blending edge)
- Usual dev work for preview versions, but less QA (We have to admit it)
- Usual QA for stable version, but less dev
- Number of versions to maintain doesn't explode.
- We can have versions more rough, simplifying dev and still allowing
"real" user feedback.
- External editors could base their products on stable versions and skip
preview ones.

What do you think about this ?

Regards,
Matthieu Gautier.

New release cycle proposal (was Rolling release model philosophy (was ...))

[Peter Lemenkov]

Hello All.

2012/11/6 Matthieu Gautier <mgautier(a)fedoraproject.org&gt;:
>  For example, if we start from Fedora20 at beginning of 2014:
>  - Fedora20(jan 2014) is a stable release. (Fedora18 eol, actual way of
>  doing)
>  - Fedora21Preview(jul 2014) is an "unstable" release. (Fedora 19 eol)
>  - Fedora21(jan 2015) is a stable release. (Fedora21Preview eol, new way
>  of doing)
>  - Fedora22Preview(jul 2015)
>  - Fedora22(jan 2016) (Fedora22Preview and Fedora20 eol)
>  - Fedora23Preview(jul 2016)
>  - Fedora23(jan 2017) (Fedora23Preview and Fedora21 eol) 
So you not a maintainer but you still suggesting that we, maintainers,
should do 2 times more job by supporting several simultaneous Fedora
versions instead of 3 right now for more than two years. And that's
all just because you think it's a good idea to spend my personal time
on the rreleases I'm not using anymore.

How about NO?

https://gs1.wac.edgecastcdn.net/8019B6/data.tumblr.com/tumblr_mbfshfloal1...

-- 
With best regards, Peter Lemenkov.

New release cycle proposal (was Rolling release model philosophy (was ...))

[Matthieu Gautier]

Le 06/11/2012 19:48, Peter Lemenkov a écrit :
>  Hello All.
>
>  2012/11/6 Matthieu Gautier <mgautier(a)fedoraproject.org&gt;:
> > For example, if we start from Fedora20 at beginning of 2014:
> > - Fedora20(jan 2014) is a stable release. (Fedora18 eol, actual way of
> > doing)
> > - Fedora21Preview(jul 2014) is an "unstable" release. (Fedora 19 eol)
> > - Fedora21(jan 2015) is a stable release. (Fedora21Preview eol, new way
> > of doing)
> > - Fedora22Preview(jul 2015)
> > - Fedora22(jan 2016) (Fedora22Preview and Fedora20 eol)
> > - Fedora23Preview(jul 2016)
> > - Fedora23(jan 2017) (Fedora23Preview and Fedora21 eol)
>  So you not a maintainer but you still suggesting that we, maintainers,
>  should do 2 times more job by supporting several simultaneous Fedora
>  versions instead of 3 right now for more than two years. And that's
>  all just because you think it's a good idea to spend my personal time
>  on the rreleases I'm not using anymore. 
No, I never suggest that. Preview
versions have a timelife of 6mo
instead of 12.
Stable version have a lifetime of 24mo (12mo for regular updates)
instead of 12.

Regards,
Matthieu Gautier

>  How about NO?
>
>
> https://gs1.wac.edgecastcdn.net/8019B6/data.tumblr.com/tumblr_mbfshfloal1...
>

New release cycle proposal (was Rolling release model philosophy (was ...))

[Peter Lemenkov]

2012/11/6 Matthieu Gautier <mgautier(a)fedoraproject.org&gt;:
> > So you not a maintainer but you still suggesting that we,
> maintainers,
> > should do 2 times more job by supporting several simultaneous Fedora
> > versions instead of 3 right now for more than two years. And that's
> > all just because you think it's a good idea to spend my personal time
> > on the rreleases I'm not using anymore. 
>  No, I never suggest that. Preview versions have a timelife of 6mo
>  instead of 12.
>  Stable version have a lifetime of 24mo (12mo for regular updates)
>  instead of 12. 
Exactly what I'm saying - two times more job. So who's gonna pay us
for the time wasted on supporting distributions we're not using
personally?

I think you didn't get the maintainers motivation (except those RH
fellows whoi just did the job) - we're doing our part because we're
using Fedora daily. What you're suggesting isn't fun anymore. So
somebody should pay for that.
-- 
With best regards, Peter Lemenkov.

New release cycle proposal (was Rolling release model philosophy (was ...))

[Matthieu Gautier]

Le 06/11/2012 20:05, Peter Lemenkov a écrit :
>  2012/11/6 Matthieu Gautier <mgautier(a)fedoraproject.org&gt;:
> >> So you not a maintainer but you still suggesting that we, maintainers,
> >> should do 2 times more job by supporting several simultaneous Fedora
> >> versions instead of 3 right now for more than two years. And that's
> >> all just because you think it's a good idea to spend my personal time
> >> on the rreleases I'm not using anymore.
> > No, I never suggest that. Preview versions have a timelife of 6mo
> > instead of 12.
> > Stable version have a lifetime of 24mo (12mo for regular updates)
> > instead of 12.
>  Exactly what I'm saying - two times more job. So who's gonna pay us
>  for the time wasted on supporting distributions we're not using
>  personally?
>
>  I think you didn't get the maintainers motivation (except those RH
>  fellows whoi just did the job) - we're doing our part because we're
>  using Fedora daily. What you're suggesting isn't fun anymore. So
>  somebody should pay for that. 
Hum.. It should be some misunderstanding somewhere :

For security updates:
- First half of the year : 2 versions to maintain (+1 version in dev) =>
As usual
- Second half of the year : 3 versions to maintain (+1 version in dev)
=> Ok, more work, but definitively not 2 times more

For other updates:
- First half of the year : 1 version to maintain (+1 in dev) => Less work
- Second half of the year : 2 versions to maintain (+1 in dev) => As usual

*Regards*
Matthieu Gautier

New release cycle proposal (was Rolling release model philosophy (was ...))

[Peter Lemenkov]

2012/11/6 Matthieu Gautier <mgautier(a)fedoraproject.org&gt;:

>  Hum.. It should be some misunderstanding somewhere : 
Definitely. Please stop talking about things you have no idea about.


-- 
With best regards, Peter Lemenkov.

New release cycle proposal (was Rolling release model philosophy (was ...))

[Pierre-Yves Chibon]

On Tue, 2012-11-06 at 22:24 +0300, Peter Lemenkov wrote:
>  2012/11/6 Matthieu Gautier <mgautier(a)fedoraproject.org&gt;:
>  
>  > Hum.. It should be some misunderstanding somewhere :
>  
>  Definitely. Please stop talking about things you have no idea about. 
You can also just show him where he is wrong rather than being pedantic.
After all everyone in the community is allowed to speak his mind. He has
an idea, he is sharing it, if you disagree explain why don't just say
"This is crap, you have no idea what you're talking about, stfu"

Pierre

New release cycle proposal (was Rolling release model philosophy (was ...))

[Aleksandar Kurtakov]

One have to say the hard truth - only the latest fedora release is supported by many
maintainers because that's what they/we use.

Alexander Kurtakov
Red Hat Eclipse team

----- Original Message -----
>  From: "Matthieu Gautier"
> <mgautier(a)fedoraproject.org&gt;
>  To: devel(a)lists.fedoraproject.org
>  Sent: Tuesday, November 6, 2012 9:19:41 PM
>  Subject: Re: New release cycle proposal (was Rolling release model philosophy	(was ...))
>  
>  Le 06/11/2012 20:05, Peter Lemenkov a écrit :
>  > 2012/11/6 Matthieu Gautier <mgautier(a)fedoraproject.org&gt;:
>  >>> So you not a maintainer but you still suggesting that we,
>  >>> maintainers,
>  >>> should do 2 times more job by supporting several simultaneous
>  >>> Fedora
>  >>> versions instead of 3 right now for more than two years. And
>  >>> that's
>  >>> all just because you think it's a good idea to spend my personal
>  >>> time
>  >>> on the rreleases I'm not using anymore.
>  >> No, I never suggest that. Preview versions have a timelife of 6mo
>  >> instead of 12.
>  >> Stable version have a lifetime of 24mo (12mo for regular updates)
>  >> instead of 12.
>  > Exactly what I'm saying - two times more job. So who's gonna pay us
>  > for the time wasted on supporting distributions we're not using
>  > personally?
>  >
>  > I think you didn't get the maintainers motivation (except those RH
>  > fellows whoi just did the job) - we're doing our part because we're
>  > using Fedora daily. What you're suggesting isn't fun anymore. So
>  > somebody should pay for that.
>  
>  Hum.. It should be some misunderstanding somewhere :
>  
>  For security updates:
>  - First half of the year : 2 versions to maintain (+1 version in dev)
>  =>
>  As usual
>  - Second half of the year : 3 versions to maintain (+1 version in
>  dev)
>  => Ok, more work, but definitively not 2 times more
>  
>  For other updates:
>  - First half of the year : 1 version to maintain (+1 in dev) => Less
>  work
>  - Second half of the year : 2 versions to maintain (+1 in dev) => As
>  usual
>  
>  *Regards*
>  Matthieu Gautier
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

New release cycle proposal (was Rolling release model philosophy (was ...))

[Jóhann B. Guðmundsson]

On 11/06/2012 07:54 PM, Aleksandar Kurtakov wrote:
>  One have to say the hard truth - only the latest fedora release is
> supported by many maintainers because that's what they/we use.
>
>  Alexander Kurtakov
>  Red Hat Eclipse team 
Please read and follow the mailinglist guidelines...

JBG

New release cycle proposal (was Rolling release model philosophy (was ...))

[Jason Brooks]

On 11/06/2012 10:55 AM, Matthieu Gautier wrote:

>  No, I never suggest that. Preview versions have a timelife of 6mo
>  instead of 12.
>  Stable version have a lifetime of 24mo (12mo for regular updates)
>  instead of 12. 
The cycle would have to go: stable, preview, preview, stable, and so on 
to avoid maintaining more than two releases at a time.

If it went back and forth between stable and preview, you'd have three 
supported releases at once in the second half of year two.

>  Regards,
>  Matthieu Gautier
>
> >
> > How about NO?
> >
> >
> https://gs1.wac.edgecastcdn.net/8019B6/data.tumblr.com/tumblr_mbfshfloal1...
> >
>  

-- 

@jasonbrooks

New release cycle proposal (was Rolling release model philosophy (was ...))

[Mark Bidewell]

oddly this looks a lot like the Ubuntu release cycle if you replace stable
with LTS


On Tue, Nov 6, 2012 at 2:16 PM, Jason Brooks <jbrooks(a)redhat.com&gt; wrote:

>  On 11/06/2012 10:55 AM, Matthieu Gautier wrote:
>
>   No, I never suggest that. Preview versions have a timelife of 6mo
> > instead of 12.
> > Stable version have a lifetime of 24mo (12mo for regular updates)
> > instead of 12.
> >
>
>  The cycle would have to go: stable, preview, preview, stable, and so on to
>  avoid maintaining more than two releases at a time.
>
>  If it went back and forth between stable and preview, you'd have three
>  supported releases at once in the second half of year two.
>
>
> > Regards,
> > Matthieu Gautier
> >
> >
> >> How about NO?
> >>
> >> https://gs1.wac.edgecastcdn.**net/8019B6/data.tumblr.com/**
> >>
> tumblr_mbfshfloal1rpdotto1_**1280.jpg<https://gs1.wac.edgecastcdn.net/...
> >>
> >>
> >
>
>  --
>
>  @jasonbrooks
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>
> https://admin.fedoraproject.**org/mailman/listinfo/devel<https://admin...



-- 
Mark Bidewell
http://www.linkedin.com/in/markbidewell

New release cycle proposal (was Rolling release model philosophy (was ...))

[Matthieu Gautier]

Le 06/11/2012 20:19, Mark Bidewell a écrit :
>  oddly this looks a lot like the Ubuntu release cycle if you replace
>  stable with LTS 
Ubuntu LTS in about 5 years lifetime. Other releases have a lifetime of
18mo.
For now, there is 5 maintained ubuntu versions at the same time (the
older is from 2008)

As far as I understand the fp, this is not what we want to (and can) do.

>      The cycle would have to go: stable, preview, preview, stable, and
>      so on to avoid maintaining more than two releases at a time.
>
>      If it went back and forth between stable and preview, you'd have
>      three supported releases at once in the second half of year two.
>  
Yes, but I didn't find better ;)
This will make a stable release every 1.5 year. It will be complicated
to mix with a lifetime of 2 years.
And extend the lifetime to 3 years is not a good solution (and will be
refused anyway).

Matthieu.

New release cycle proposal (was Rolling release model philosophy (was ...))

[Reindl Harald]

Am 06.11.2012 19:48, schrieb Peter Lemenkov:
>  Hello All.
>  
>  2012/11/6 Matthieu Gautier <mgautier(a)fedoraproject.org&gt;:
> > For example, if we start from Fedora20 at beginning of 2014:
> > - Fedora20(jan 2014) is a stable release. (Fedora18 eol, actual way of
> > doing)
> > - Fedora21Preview(jul 2014) is an "unstable" release. (Fedora 19 eol)
> > - Fedora21(jan 2015) is a stable release. (Fedora21Preview eol, new way
> > of doing)
> > - Fedora22Preview(jul 2015)
> > - Fedora22(jan 2016) (Fedora22Preview and Fedora20 eol)
> > - Fedora23Preview(jul 2016)
> > - Fedora23(jan 2017) (Fedora23Preview and Fedora21 eol)
>  
>  So you not a maintainer but you still suggesting that we, maintainers,
>  should do 2 times more job by supporting several simultaneous Fedora
>  versions instead of 3 right now for more than two years. And that's
>  all just because you think it's a good idea to spend my personal time
>  on the rreleases I'm not using anymore 
it would be enough to push LARGE changes like UsrMove / systemd / grub2
only every SECOND release as we current have and the following release
should bring only smaller changes and PLOISH the features of the last
release

this way you would even have LESS work and pressure and the distribution
would become more stable and bugfree at all becasue currently sometimes
people do simply now know where to start and how to finish because the
next BIG change is starting and a half year is very short

New release cycle proposal (was Rolling release model philosophy (was ...))

[Jason Brooks]

On 11/06/2012 10:34 AM, Matthieu Gautier wrote:
>  Hello all,
>
>  I'm not a Fedora developer, nor package maintainer. I'm a French Fedora
>  Ambassador for a long time. (I should say "I was" cause I don't do to
>  many things last time, just wake up every 6 months for Fedora releases
>  and other events).
>  I'm also a developer but that's not about Fedora.
>
>  While reading this thread, an idea came to me about the Fedora release
>  cycle.
>
>  First, while discussing with fedora users, from events, friends, and
>  parents (real Adam's uncle Bob), the following points can be inferred:
>    - They like the blending edge part of Fedora.
>    - They want stable releases.
>  Not always in the same time, it's depending of user profile. It seems a
>  little antagonist, but that's what they want.
>  (By the way, they are mostly happy with Fedora)
>
>  What I propose is a new release cycle: One release every year and a
>  "preview" (not sure of the name) release between them.
>  - Small features can come in whatever release.
>  - Big features (libc, anaconda, systemd, gnome3, wayland...) can come in
>  preview release only.
>  - FedoraN releases have a lifetime of 2 years.
>  - FedoraNPreview releases have a lifetime of 6 months. 
It's an interesting idea -- right now, at any one time, there are two 
supported releases: the latest and the latest minus one, both with 13 mo 
life spans.

If you want to move fast, you're always going to be on the latest 
release (or the alpha of latest +1).

If you don't want to move fast, chances are that latest -1 isn't slow 
enough to satisfy you.

For those who upgrade each release (or sooner), a 6mo life span for the 
latest release wouldn't matter. Those who don't want to upgrade every 
six months might well appreciate the two year life span.

>  For example, if we start from Fedora20 at beginning of 2014:
>  - Fedora20(jan 2014) is a stable release. (Fedora18 eol, actual way of
>  doing)
>  - Fedora21Preview(jul 2014) is an "unstable" release. (Fedora 19 eol)
>  - Fedora21(jan 2015) is a stable release. (Fedora21Preview eol, new way
>  of doing)
>  - Fedora22Preview(jul 2015)
>  - Fedora22(jan 2016) (Fedora22Preview and Fedora20 eol)
>  - Fedora23Preview(jul 2016)
>  - Fedora23(jan 2017) (Fedora23Preview and Fedora21 eol)
>  - ...
>
>  Preview version doesn't mean unstable. It means version as we have now,
>  but more tolerant to bug ("Here the new version of Fedora with latest
>  features. We make our best, but maybe not enough. You're aware of it.")
>  Stable version is mainly preview version stabilized plus other (small)
>  features.
>
>
>  For users:
>  - Users wanting stable (long time support) version can install it every
>  2 year.
>  - Users wanting new versions but stable can install it every year
>  - User wanting blending edge can install a version every 6 months
>
>  For devs:
>  Still a version every 6 months, new features can still be added. Just
>  one out of two versions has to be more stable (no big feature)
>
>  For QA:
>  Still a version every 6 months. More QA for stable versions
>
>  For Ambassadors/Marketing:
>  Still a version every 6 months. Nothing change.
>
>  For maintainers/packagers:
>  For now there are 4 versions at the same time: Fn-1, Fn to maintain and
>  Fn+1, Rawhide in dev
>  With my proposition:
>  - Between Fn and Fn+1prev: 2 versions (Fn-1, Fn) to maintain and 2
>  versions (Fn+1prev, rawhide) in dev
>  - Between Fnprev and Fn: 3 versions (Fn-2, Fn-1, Fnprev) to maintain and
>  1(2) version (Fn, rawhide) in dev
>  During 6 months, there is one version more to maintain, but changes
>  between Fnprev and Fn are not breaking stuff.
>
>  We could also create some king of "half end of life" : stable releases
>  get all updates for 1 year, and security updates only for the second
>  year. This could reduce maintainers' work.
>
>  This way we reach the two worlds:
>  - Users can chose the version they want (long time support, stable,
>  blending edge)
>  - Usual dev work for preview versions, but less QA (We have to admit it)
>  - Usual QA for stable version, but less dev
>  - Number of versions to maintain doesn't explode.
>  - We can have versions more rough, simplifying dev and still allowing
>  "real" user feedback.
>  - External editors could base their products on stable versions and skip
>  preview ones.
>
>  What do you think about this ?
>
>  Regards,
>  Matthieu Gautier.
>  

-- 

@jasonbrooks

New release cycle proposal (was Rolling release model philosophy (was ...))

[Peter Lemenkov]

Hello

2012/11/6 Jason Brooks <jbrooks(a)redhat.com&gt;:
>  For those who upgrade each release (or sooner), a 6mo life span for
> the
>  latest release wouldn't matter. Those who don't want to upgrade every six
>  months might well appreciate the two year life span. 
They should pay for RHEL.
-- 
With best regards, Peter Lemenkov.

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Bruno Wolff III]

On Fri, Nov 02, 2012 at 16:32:00 -0700,
   Adam Williamson <awilliam(a)redhat.com&gt; wrote:
> On Sat, 2012-11-03 at 00:18 +0100, drago01 wrote:
>
> In a rolling release model, everyone deals with foo-1.0 to foo-2.0, then
> a week later they deal with bar-1.0 to bar-2.0, then a week later they
> deal with monkeys-1.0 to monkeys-2.0...in a 'stable' release model,
> everyone gets to deal with foo, bar, monkeys and five hundred other
> changes all at once. Which is chaos on a stick. 
A key difference though is that with actual releases people can do the upgrade 
at a good time for them to do it. With a rolling release bad things can 
happen at especially inconvenient time.

I'd rather see us do a better job with rawhide so that more people use it and 
a better job at making upgrades go smoother so that people just trying 
to get stuff done with Fedora have a better experience.

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Michael Scherer]

Le samedi 03 novembre 2012 à 07:46 -0500, Bruno Wolff III a écrit :

>  I'd rather see us do a better job with rawhide so that more
> people use it and 
>  a better job at making upgrades go smoother so that people just trying 
>  to get stuff done with Fedora have a better experience. 
Then the question is "Why people do not use rawhide", and "how can we
fix the issue so people use it". Maybe that's just perception, maybe
there is real recurrent issue to fix one way or another.

I do not run it, so I cannot judge, but I think the first step to fix
something is to know the exact problems to fix. If the issue is "too
much breakage", how can we ensure the most annoying issues are prevented
( I am pretty confident in autoQA personnaly ) ?

And also, if rawhide start to be more used, we should ensure if doesn't
divde the community in 2 groups ( as I have seen some people complain on
others distributions that stable release are neglected because devs run
"$dev_distro" and not the stable release )

-- 
Michael Scherer

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Adam Williamson]

On Sun, 2012-11-04 at 00:26 +0100, Michael Scherer wrote:
>  Le samedi 03 novembre 2012 à 07:46 -0500, Bruno Wolff III a écrit :
>  
>  > I'd rather see us do a better job with rawhide so that more people use it and 
>  > a better job at making upgrades go smoother so that people just trying 
>  > to get stuff done with Fedora have a better experience.
>  
>  Then the question is "Why people do not use rawhide", and "how can we
>  fix the issue so people use it". Maybe that's just perception, maybe
>  there is real recurrent issue to fix one way or another.
>  
>  I do not run it, so I cannot judge, but I think the first step to fix
>  something is to know the exact problems to fix. If the issue is "too
>  much breakage", how can we ensure the most annoying issues are prevented
>  ( I am pretty confident in autoQA personnaly ) ? 
We have on our todo list to 'enforce' the existing autoqa tests, for
depcheck and upgrade path, but we're a little short on people ATM and
everyone keeps getting roped into validation testing. I think enforcing
depcheck for Rawhide would be going a bit far, though, because then
you'd have to use a side tag to do soname bumps, so we kind of have a
problem there: we can't blindly reject dependency-breaking changes to
Rawhide, but that's the kind of thing that usually causes problems in
Rawhide...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Rawhide

[Kevin Fenzi]

So, I have been thinking about rawhide. 

I agree identifying the problems/issues would be good, and I think
there's something we can do to help with that: 

Get a nice group of at least 10 or so folks who are active on this list
to agree to run it full time on their main machine. 

As we get close to F18 release, I am considering moving my full time
laptop to rawhide. If I can get a group of folks to do likewise we can
at least identify issues faster and help each other as they come up. 

Additionally, if some number of these folks who pledge to run rawhide
full time were provenpackagers we could just go in and fix things as
they hit (or soon after) instead of waiting a while for fixes to go
out. 

I've run a rawhide vm/test machine here for many years. It's hit it's
share of problems, but none were insurmountable. Some of them might
have been for folks who were not more experienced tho, so increasing
communication around rawhide can only help, IMHO. 

Additional thoughts to help rawhide: 

- It's been suggested before, but could we practically keep N and N-1
  packages in rawhide repos? Then 'yum downgrade' becomes much more
  handy. Repodata size and mirror size might shoot that down though. 

- Autoqa could perhaps help out, but I am not holding my breath. ;) 

- Anaconda folks haven't wanted rawhide installer images as they cause
  people to report bugs on things when not ready, etc. However, could
  we build nightly cloud images at least? Those could help test things
  and won't require hitting the installer path. 

- I'm sure there's more ideas to improve it... 

I really think if we get a pool of savvy folks running it day to day we
should at least be able to identify the pain points. In my experience
with my test machine, rawhide has been pretty boring for the last two
cycles, if we can continue to make it so, perhaps the rolling release
folks might be able to find it usable. 

kevin

Rawhide

[Sandro Mani]

On 04.11.2012 01:32, Kevin Fenzi wrote:
>  So, I have been thinking about rawhide.
>
>  I agree identifying the problems/issues would be good, and I think
>  there's something we can do to help with that:
>
>  Get a nice group of at least 10 or so folks who are active on this list
>  to agree to run it full time on their main machine.
>
>  As we get close to F18 release, I am considering moving my full time
>  laptop to rawhide. If I can get a group of folks to do likewise we can
>  at least identify issues faster and help each other as they come up.
>
>  Additionally, if some number of these folks who pledge to run rawhide
>  full time were provenpackagers we could just go in and fix things as
>  they hit (or soon after) instead of waiting a while for fixes to go
>  out.
>
>  I've run a rawhide vm/test machine here for many years. It's hit it's
>  share of problems, but none were insurmountable. Some of them might
>  have been for folks who were not more experienced tho, so increasing
>  communication around rawhide can only help, IMHO.
>
>  Additional thoughts to help rawhide:
>
>  - It's been suggested before, but could we practically keep N and N-1
>     packages in rawhide repos? Then 'yum downgrade' becomes much more
>     handy. Repodata size and mirror size might shoot that down though.
>
>  - Autoqa could perhaps help out, but I am not holding my breath. ;)
>
>  - Anaconda folks haven't wanted rawhide installer images as they cause
>     people to report bugs on things when not ready, etc. However, could
>     we build nightly cloud images at least? Those could help test things
>     and won't require hitting the installer path.
>
>  - I'm sure there's more ideas to improve it...
>
>  I really think if we get a pool of savvy folks running it day to day we
>  should at least be able to identify the pain points. In my experience
>  with my test machine, rawhide has been pretty boring for the last two
>  cycles, if we can continue to make it so, perhaps the rolling release
>  folks might be able to find it usable.
>
>  kevin
>
>  
While I'm not (yet) a package maintainer, I'm a regular reader of 
various fedora lists, and I've been using exclusively rawhide on my 
machine (Lenovo T400) for the past year, for anything from normal 
desktop usage to various scientific/programming stuff, in particular 
C++/Qt/OpenGL, some Gtk and also AVR microcontroller stuff. I though I'd 
briefly summarize my experiences:
- The experience greatly depends on the desktop environment. Very early 
Gnome development packages are released to the wild (and hence end up in 
rawhide) very soon, which can cause major problems. On the other hand, 
KDE for instance only releases builds starting from usually quite usable 
betas. While previous rawhide installations on Gnome were often quite 
challenging to maintain, I've had very few DE-related issues in the past 
year as a KDE user.
- My rule number one is: never reboot before any important presentations 
:) I've had the occasional boot-related issue. While enforcing=0 was 
often part of the solution, systemd and dracut related issues were the 
most difficult ones to work-around to have the system booting again.
- I always exclude the kernel from the updates, and usually only update 
to kernel-*-rc3+ without debugging options (simply because KDE is 
terribly sluggish with debugging options).
- Broken dependencies are occasionally somewhat of a pain, one issue 
which already came up on this list a while ago is the occasional version 
discrepancy between branched and rawhide. In general, I end up 
rebuilding a couple of packages a week manually to have all updates 
apply (have written a nice rebuild.sh script for that;)). Occasionally, 
some manual patching is necessary.
- I have clean_requirements_on_remove = 1 in yum.conf, and also have 
installed yum-plugin-show-leaves, which makes it fairly easy to keep the 
installation tidy.

I guess that's about it. In general I must say that I've found rawhide 
to be definitely more than just usable!

Sandro

Rawhide

[Bill Nottingham]

Sandro Mani (manisandro(a)gmail.com) said: 
>  >- It's been suggested before, but could we practically keep N
> and N-1
>  >   packages in rawhide repos? Then 'yum downgrade' becomes much more
>  >   handy. Repodata size and mirror size might shoot that down though. 
The compose process currently can pull either the latest package, or
*all* packages in its inheritance. Pulling just one more would be More Code.
(Not saying the code couldn't be written, but it's not a 'simple' fix.)

Also, repo size, repodata size, etc. You get the drill.

Bill

Rawhide

[Bruno Wolff III]

On Sat, Nov 03, 2012 at 18:32:20 -0600,
   Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
> Additionally, if some number of these folks who pledge to run rawhide
> full time were provenpackagers we could just go in and fix things as
> they hit (or soon after) instead of waiting a while for fixes to go
> out. 
I'm in proven packagers and have been using rawhide on my main desktop 
for a while. (Sometimes I follow branched, but I plan to use rawhide 
going forward.) That's what I use for day to day stuff at home.

> - It's been suggested before, but could we practically keep N and
> N-1
>   packages in rawhide repos? Then 'yum downgrade' becomes much more
>   handy. Repodata size and mirror size might shoot that down though. 
If you want that you can just enable them in addition. That can cause 
problems if versions in FN or FN-1 are higher than in rawhide. I have 
done that for a while this release to get gnome updates early.

> - Anaconda folks haven't wanted rawhide installer images as they
> cause
>   people to report bugs on things when not ready, etc. However, could
>   we build nightly cloud images at least? Those could help test things
>   and won't require hitting the installer path. 
Once you are using rawhide, you generally don't do installs unless you 
specifically want to test them.

> I really think if we get a pool of savvy folks running it day to day
> we
> should at least be able to identify the pain points. In my experience
> with my test machine, rawhide has been pretty boring for the last two
> cycles, if we can continue to make it so, perhaps the rolling release
> folks might be able to find it usable. 
I get occasional kernel problems. Sometimes there are boot issues. When 
there are soname issues, I sometimes have to choose between running the 
current packages or uninstalling some things I use.

I had some theming issues not too long ago, but that affected both rawhide 
and branched, so I saw it on all of my machines.

Rawhide

[Panu Matilainen]

On 11/04/2012 02:32 AM, Kevin Fenzi wrote:
>  So, I have been thinking about rawhide.
>
>  I agree identifying the problems/issues would be good, and I think
>  there's something we can do to help with that:
>
>  Get a nice group of at least 10 or so folks who are active on this list
>  to agree to run it full time on their main machine.
>
>  As we get close to F18 release, I am considering moving my full time
>  laptop to rawhide. If I can get a group of folks to do likewise we can
>  at least identify issues faster and help each other as they come up.
>
>  Additionally, if some number of these folks who pledge to run rawhide
>  full time were provenpackagers we could just go in and fix things as
>  they hit (or soon after) instead of waiting a while for fixes to go
>  out.
>
>  I've run a rawhide vm/test machine here for many years. It's hit it's
>  share of problems, but none were insurmountable. Some of them might
>  have been for folks who were not more experienced tho, so increasing
>  communication around rawhide can only help, IMHO.
>
>  Additional thoughts to help rawhide:
>
>  - It's been suggested before, but could we practically keep N and N-1
>     packages in rawhide repos? Then 'yum downgrade' becomes much more
>     handy. Repodata size and mirror size might shoot that down though. 
Setting keepcache=1 in yum.conf helps somewhat: 'yum downgrade' wont 
work but it'll ensure you do have something to downgrade to, even if it 
has to be done manually.

>  - Autoqa could perhaps help out, but I am not holding my breath. ;) 
Yeh, autoqa can't do a whole lot when its builds often intentionally 
dependencies break (eg soname bumps). Unless such builds were required 
to be done in a staging area - this is *possible* already but not much 
used. It'd have to be reasonably convenient for the developers though, 
IIRC this requires rel-eng intervention currently.

Another means to achieve dependency sanity could be a separate 
rawhide-derived repository, where packages can only enter (and would 
automatically do so) once their dependencies are satisfied.
Or perhaps more akin to the common fedora workflow: make rawhide builds 
initially enter a rawhide-testing repo, from which they "graduate" to 
the actual rawhide once defined criteria (such as dependency closure) is 
met.

The broken dependencies report from branched makes me cringe every 
single time I see it: packages with broken dependencies should really 
not be allowed to enter it at all. Rawhide as it is now is a different
story, but if we expect people to actually use it then it should be kept 
in a saner state. yum's --skip-broken helps but its not really up to the 
task for the massive, constant brokenness of rawhide.

All that easier said than done of course. And would mean we end up with 
even more repositories, not less.

>  - Anaconda folks haven't wanted rawhide installer images as they cause
>     people to report bugs on things when not ready, etc. However, could
>     we build nightly cloud images at least? Those could help test things
>     and won't require hitting the installer path. 
Anaconda has a pretty special status then, nobody else can exempt 
themselves from rawhide. Installer images *are* obviously different from 
everything else in many ways but still... if images are only ever 
getting generated for branched, it means lost opportunities for finding 
and fixing bugs *before* entering branched stage. This is yet another 
case (and I assume to no small degree, a consequence) of the skewed 
situation where actual development ends up occurring in branched stage.

This very much relates to Jesse's comment early in the anaconda-thread:
(http://lists.fedoraproject.org/pipermail/devel/2012-October/173247.html)

"I think we need to give developers more time for feature integration
after the feature freeze."

I can easily understand anaconda wanting (and needing, really) to be 
exempt from early rawhide stages, but there should (I think) be a 
reasonable period before branch-point where images are being built. 
Making that possible (and sane for anaconda developers) requires changes 
to how things are done though, there can be no anaconda-breaking 
features (or other changes) crash-landing in the very last minute then.

>  - I'm sure there's more ideas to improve it... 
Increased communication couldn't hurt: soname bumps are fairly well 
communicated, other kinds of breakage could use similar announcements. 
Some people do it already (kudos to them), but I think we should see 
more of that. Besides "world is going to break tomorrow or the day 
after" heads-ups, it should help overall planning if we had some kind of 
"in this cycle, we're planning to do ... with package(set) X" summaries 
from maintainer(-group)s / SIGs. Even if its just "nothing beyond basic 
bugfixes expected", it'd mean people relying on that particular package 
would know they have one less thing to worry about. Perhaps such 
plan-summaries at beginning of development cycle could/should be 
mandated for critical path packages.
The feature process is supposed (I guess) to provide some of this 
coordination and communication but its far too heavy-weight for many 
things and at least to me, far too detached from the day-to-day 
development work. And it certainly does not have a place for "no big 
changes expected" information, except for not being a feature, but as it 
is that means absolutely nothing...

	- Panu -

Rawhide

[Jesse Keating]

On 11/04/2012 01:31 AM, Panu Matilainen wrote:
>  Yeh, autoqa can't do a whole lot when its builds often intentionally
>  dependencies break (eg soname bumps). Unless such builds were required
>  to be done in a staging area - this is *possible* already but not much
>  used. It'd have to be reasonably convenient for the developers though,
>  IIRC this requires rel-eng intervention currently. 
The long term plan with AutoQA was to have a staging area.

build -> stage -> AutoQA -> rawhide.

If your package passes autoqa, it goes into rawhide.  If it fails, the 
dev can override and send it on anyway, or try again with a newer build.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!

Rawhide

[Vít Ondruch]

Dne 4.11.2012 10:31, Panu Matilainen napsal(a):
>  On 11/04/2012 02:32 AM, Kevin Fenzi wrote:
> >
> > - Autoqa could perhaps help out, but I am not holding my breath. ;)
>
>  Yeh, autoqa can't do a whole lot when its builds often intentionally 
>  dependencies break (eg soname bumps). Unless such builds were required 
>  to be done in a staging area - this is *possible* already but not much 
>  used. It'd have to be reasonably convenient for the developers though, 
>  IIRC this requires rel-eng intervention currently. 
And rel-engs actively prohibits staging as much as they can  [1], where 
it should be encouraged IMO.

Vit


[1] https://fedorahosted.org/rel-eng/ticket/4580

Rawhide

[Jesse Keating]

On 11/06/2012 03:35 AM, Vít Ondruch wrote:
>  And rel-engs actively prohibits staging as much as they can  [1], where
>  it should be encouraged IMO.
>
>  Vit
>
>
>  [1] https://fedorahosted.org/rel-eng/ticket/4580 

Additional tags have a high cost to the infrastructure and every user of 
said infrastructure.  It creates more newRepo tasks which take 
significant time to complete, and since they are resource intensive only 
a few can be done at once.  This means that newRepo tasks get delayed 
farther and people waiting for buildroot updates have to wait longer, 
and longer, and longer.  This is why extra tags/roots are used sparingly 
for more intensive updates than what you're requesting here.

-- 
Help me fight child abuse: http://tinyurl.com/jlkcourage

- jlk

Rawhide

[Dan Horák]

Jesse Keating píše v Út 06. 11. 2012 v 10:48 -0800: 
>  On 11/06/2012 03:35 AM, Vít Ondruch wrote:
>  >
>  > And rel-engs actively prohibits staging as much as they can  [1], where
>  > it should be encouraged IMO.
>  >
>  > Vit
>  >
>  >
>  > [1] https://fedorahosted.org/rel-eng/ticket/4580
>  
>  
>  Additional tags have a high cost to the infrastructure and every user of 
>  said infrastructure.  It creates more newRepo tasks which take 
>  significant time to complete, and since they are resource intensive only 
>  a few can be done at once.  This means that newRepo tasks get delayed 
>  farther and people waiting for buildroot updates have to wait longer, 
>  and longer, and longer.  This is why extra tags/roots are used sparingly 
>  for more intensive updates than what you're requesting here. 
but there is a solution - learn koji use multiple repos, in cases like
this one you will have one repo that is tied to fX tag (large, but
changed only when "fedora" changes) and another to the side tag (this
will be very small one, can be changed more often), koji will then
generate a mock config with 2 repos and you are done


Dan

Rawhide

[Vít Ondruch]

Dne 7.11.2012 08:08, Dan Horák napsal(a):
>  Jesse Keating píše v Út 06. 11. 2012 v 10:48 -0800:
> > On 11/06/2012 03:35 AM, Vít Ondruch wrote:
> >> And rel-engs actively prohibits staging as much as they can  [1], where
> >> it should be encouraged IMO.
> >>
> >> Vit
> >>
> >>
> >> [1] https://fedorahosted.org/rel-eng/ticket/4580
> >
> > Additional tags have a high cost to the infrastructure and every user of
> > said infrastructure.  It creates more newRepo tasks which take
> > significant time to complete, and since they are resource intensive only
> > a few can be done at once.  This means that newRepo tasks get delayed
> > farther and people waiting for buildroot updates have to wait longer,
> > and longer, and longer.  This is why extra tags/roots are used sparingly
> > for more intensive updates than what you're requesting here.
>  but there is a solution - learn koji use multiple repos, in cases like
>  this one you will have one repo that is tied to fX tag (large, but
>  changed only when "fedora" changes) and another to the side tag (this
>  will be very small one, can be changed more often), koji will then
>  generate a mock config with 2 repos and you are done
>
>
>  Dan
>  
In combination with 
https://admin.fedoraproject.org/pkgdb/acls/name/createrepo_c it would be 
outstanding.


Vit

Rawhide

[Jesse Keating]

On 11/07/2012 01:02 AM, Vít Ondruch wrote:
>  Dne 7.11.2012 08:08, Dan Horák napsal(a):
> > Jesse Keating píše v Út 06. 11. 2012 v 10:48 -0800:
> >> On 11/06/2012 03:35 AM, Vít Ondruch wrote:
> >>> And rel-engs actively prohibits staging as much as they can  [1], where
> >>> it should be encouraged IMO.
> >>>
> >>> Vit
> >>>
> >>>
> >>> [1] https://fedorahosted.org/rel-eng/ticket/4580
> >>
> >> Additional tags have a high cost to the infrastructure and every user of
> >> said infrastructure.  It creates more newRepo tasks which take
> >> significant time to complete, and since they are resource intensive only
> >> a few can be done at once.  This means that newRepo tasks get delayed
> >> farther and people waiting for buildroot updates have to wait longer,
> >> and longer, and longer.  This is why extra tags/roots are used sparingly
> >> for more intensive updates than what you're requesting here.
> > but there is a solution - learn koji use multiple repos, in cases like
> > this one you will have one repo that is tied to fX tag (large, but
> > changed only when "fedora" changes) and another to the side tag (this
> > will be very small one, can be changed more often), koji will then
> > generate a mock config with 2 repos and you are done
> >
> >
> > Dan
> >
>
>  In combination with
>  https://admin.fedoraproject.org/pkgdb/acls/name/createrepo_c it would be
>  outstanding.
>
>
>  Vit 
If the solution was so simple, don't you think it would have been solved 
long ago?  The majority of time isn't spent in the createrepo task, it's 
in the database queries to figure out through inheritance what all 
builds should be in that createrepo run.  That's what puts stress on the 
entire system.

-- 
Help me fight child abuse: http://tinyurl.com/jlkcourage

- jlk

Rawhide

[Michael Scherer]

Le samedi 03 novembre 2012 à 18:32 -0600, Kevin Fenzi a écrit :
>  So, I have been thinking about rawhide. 
>  
>  I agree identifying the problems/issues would be good, and I think
>  there's something we can do to help with that: 
>  
>  Get a nice group of at least 10 or so folks who are active on this list
>  to agree to run it full time on their main machine. 
>  
>  As we get close to F18 release, I am considering moving my full time
>  laptop to rawhide. If I can get a group of folks to do likewise we can
>  at least identify issues faster and help each other as they come up. 
>
>  Additionally, if some number of these folks who pledge to run rawhide
>  full time were provenpackagers we could just go in and fix things as
>  they hit (or soon after) instead of waiting a while for fixes to go
>  out.  
+1 

>  I've run a rawhide vm/test machine here for many years. It's
> hit it's
>  share of problems, but none were insurmountable. Some of them might
>  have been for folks who were not more experienced tho, so increasing
>  communication around rawhide can only help, IMHO. 
>  
>  Additional thoughts to help rawhide: 
>  
>  - It's been suggested before, but could we practically keep N and N-1
>    packages in rawhide repos? Then 'yum downgrade' becomes much more
>    handy. Repodata size and mirror size might shoot that down though.  
Have a system like this :
http://snapshot.debian.org/

could surely help.

Source code is here :
http://anonscm.debian.org/gitweb/?p=mirror/snapshot.debian.org.git;a=tree

( pylons + some ruby and fuse to have a snapshot view on the fs )

>  - Autoqa could perhaps help out, but I am not holding my breath. ;) 
>  
>  - Anaconda folks haven't wanted rawhide installer images as they cause
>    people to report bugs on things when not ready, etc. However, could
>    we build nightly cloud images at least? Those could help test things
>    and won't require hitting the installer path.  
Nightly cloud image could even be started ( and customized by guestfish
) and we could see if they boot. That would surely help to detect
regressions earlier.

>  - I'm sure there's more ideas to improve it... 
>  
>  I really think if we get a pool of savvy folks running it day to day we
>  should at least be able to identify the pain points. In my experience
>  with my test machine, rawhide has been pretty boring for the last two
>  cycles, if we can continue to make it so, perhaps the rolling release
>  folks might be able to find it usable.  
Not to mention people could just dual boot in case of issues.

-- 
Michael Scherer

Rawhide

[Matthew Miller]

On Sat, Nov 03, 2012 at 06:32:20PM -0600, Kevin Fenzi wrote:
>  Get a nice group of at least 10 or so folks who are active on this
> list
>  to agree to run it full time on their main machine.  
I did for years. On F18 right now, but I'm willing to go back to all Rawhide
all the time.

Here's some important background reading on this topic if you haven't seen
it already: https://lwn.net/Articles/506831/ (Jonathan Corbet's "Left by
Rawhide" article.)


>  - It's been suggested before, but could we practically keep N and
> N-1
>    packages in rawhide repos? Then 'yum downgrade' becomes much more
>    handy. Repodata size and mirror size might shoot that down though.  
Speaking as a former mirror person, I don't think the mirrors care that
much. The size would grow, but the traffic and churn would be about the
same, since it's nothing _new_, just slower deletion.


>  - Anaconda folks haven't wanted rawhide installer images as they
> cause
>    people to report bugs on things when not ready, etc. However, could
>    we build nightly cloud images at least? Those could help test things
>    and won't require hitting the installer path.  
Yes, nightly cloud images. Working on getting the non-nightly ones building
and functional first, but having them automatically built nightly would be
great. We can't, reasonably, push them into EC2 nightly, but I'd love to see
this image go into one of the internal clouds nightly and then we can script
up automatic tests against that.



-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

Rawhide

[Jonathan Dieter]

On Sun, 2012-11-04 at 09:21 -0500, Matthew Miller wrote:
>  On Sat, Nov 03, 2012 at 06:32:20PM -0600, Kevin Fenzi wrote:
>  > - It's been suggested before, but could we practically keep N and N-1
>  >   packages in rawhide repos? Then 'yum downgrade' becomes much more
>  >   handy. Repodata size and mirror size might shoot that down though. 
>  
>  Speaking as a former mirror person, I don't think the mirrors care that
>  much. The size would grow, but the traffic and churn would be about the
>  same, since it's nothing _new_, just slower deletion. 
Not necessarily commenting on whether this whole idea is good or not,
but how hard would it be to just have the N release and updates
repositories enabled at the same time as the Rawhide repository?

Jonathan

Rawhide

[Matthew Miller]

On Sun, Nov 04, 2012 at 05:04:40PM +0200, Jonathan Dieter wrote:
>  > > - It's been suggested before, but could we practically
> keep N and N-1
>  > >   packages in rawhide repos? Then 'yum downgrade' becomes much more
>  > >   handy. Repodata size and mirror size might shoot that down though. 
>  > Speaking as a former mirror person, I don't think the mirrors care that
>  > much. The size would grow, but the traffic and churn would be about the
>  > same, since it's nothing _new_, just slower deletion.
>  Not necessarily commenting on whether this whole idea is good or not,
>  but how hard would it be to just have the N release and updates
>  repositories enabled at the same time as the Rawhide repository? 
Here, "N" is _package release_, not Fedora release.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

Rawhide

[Jonathan Dieter]

On Sun, 2012-11-04 at 10:13 -0500, Matthew Miller wrote:
>  On Sun, Nov 04, 2012 at 05:04:40PM +0200, Jonathan Dieter wrote:
>  > Not necessarily commenting on whether this whole idea is good or not,
>  > but how hard would it be to just have the N release and updates
>  > repositories enabled at the same time as the Rawhide repository?
>  
>  Here, "N" is _package release_, not Fedora release. 
Ah.  Ok, that makes sense then.

Jonathan

Rawhide

[Dodji Seketeli]

Kevin Fenzi <kevin(a)scrye.com&gt; a écrit:

>  Get a nice group of at least 10 or so folks who are active on this
> list
>  to agree to run it full time on their main machine.    
Amen brother.  Count me in that group if this ever happens. 

I already run rawhide on a dedicated box for daily duties like email,
web browsing etc.  I have another box with a stable fedora release for
day to day hacking.  I switch between the two using a KVM swith (the
real hardware, you know, not the kernel virtualization thingy).

It seems to me that if more Fedora Hackers were running Rawhide all the
time, the delay we are seeing now in F18 could have been at least
predicted a long time ago.  The thing is, everybody is damn busy with
his own work/life schedule so we cannot force this on people.

Just having a dedicated Rawhide Swat Team of die hard volunteers who
could spot issues early, file more bugs, gently push for fixes in
Rawhide and last but not least build a kind of "esprit de corps" among
those who suffer Rawhide breakages for the greater good would be a great
start, IMHO.

Who knows, with time, these fine fellows could even inspire more Fedora
Hackers to actually test their builds on Rawhide.  We can dream.  :-)

>  Additionally, if some number of these folks who pledge to run
> rawhide
>  full time were provenpackagers we could just go in and fix things as
>  they hit (or soon after) instead of waiting a while for fixes to go
>  out.  
[+1] + vigorous nodding.

>  I've run a rawhide vm/test machine here for many years. It's
> hit it's
>  share of problems, but none were insurmountable. Some of them might
>  have been for folks who were not more experienced tho, so increasing
>  communication around rawhide can only help, IMHO.  
Could we have a rawhide-list for this?  I know fighting proliferation of
mailing list is a good thing, but practically speaking, being able to
quickly scan a mailing list before doing a yum update can help a
Rawhider evaluate in advance the odds of his risking to be unable to
reboot his machine or not.  :-)

>  Additional thoughts to help rawhide: 
>
>  - It's been suggested before, but could we practically keep N and N-1
>    packages in rawhide repos? Then 'yum downgrade' becomes much more
>    handy. Repodata size and mirror size might shoot that down though. 
>
>  - Autoqa could perhaps help out, but I am not holding my breath. ;) 
>
>  - Anaconda folks haven't wanted rawhide installer images as they cause
>    people to report bugs on things when not ready, etc. However, could
>    we build nightly cloud images at least? Those could help test things
>    and won't require hitting the installer path. 
>
>  - I'm sure there's more ideas to improve it... 
>  
  - I'd add, having a way for some provenpackagers of the Rawhide Swat
  Team to temporarily blacklist a (set of) package, if it appears to
  significantly break something; so that people doing yum update on
  Rawhide won't brick their system because of well know issue waiting to
  be solved.

-- 
		Dodji

Rawhide

[Nicolas Mailhot]

Le Lun 5 novembre 2012 10:45, Dodji Seketeli a écrit :

>  Just having a dedicated Rawhide Swat Team of die hard volunteers who
>  could spot issues early, file more bugs, gently push for fixes in
>  Rawhide and last but not least build a kind of "esprit de corps" among
>  those who suffer Rawhide breakages for the greater good would be a great
>  start, IMHO. 
There is already a pool of rawhide users.
Rawhide bugs are already reported.

The problem is not here, the problem is maintainers that deliberately
ignore bugs with rawhide in them (usual excuse and motto are "Rawhide eats
babies", "I'll test when Rawhide is more stable", no empathy for other
maintainers that can not test because your problem is breaking their test
process). They hope the problems will go away before branch time, and then
cry they get too little time to fix stuff after branching when the very
same problems hit alpha testers, or badger the reporters to file a new
report at branch time without even checking the information that was
provided before and assuming it is necessarily stale.

All the systemd problems were reported in Rawhide way before they hit
branched. If they did hit branched it's not because reporting was lacking,
but because there was a lack of social pressure not to let Rawhide rot
(with easily predictable consequences).

When systemd inclusion was deferred in stable because it was not ready and
no service had been migrated there was *no* effort I could see to fix the
problem in Rawhide and systemd hit the next branch time with all the
problems that justified initial deferring intact.

Someone wrote in this thread that Gnome updates were painful in branched.
Well they are horrific in Rawhide. If there was some effort to make them
only painful in Rawhide they would not be horrific in branched. (this is
called a 'virtuous circle').

IMHO it was a huge mistake to synchronise Fedora releases with GNOME
releases instead of synchronising Fedora branch times with GNOME release
times. That's idiotic and means there is no time Fedora-side to do any QA
and fixing before pushing a new GNOME release to users.

(two high-visibility examples anyone can understand, not necessarily the
worst offenders and systemd people at least seem to have improved their
workflow a little over time)

Adding time to the end of the circle is compounding the problem, not
fixing it.

-- 
Nicolas Mailhot

Rawhide

[Jaroslav Reznik]

----- Original Message -----
>  
>  Le Lun 5 novembre 2012 10:45, Dodji Seketeli a écrit :
>  
>  > Just having a dedicated Rawhide Swat Team of die hard volunteers
>  > who
>  > could spot issues early, file more bugs, gently push for fixes in
>  > Rawhide and last but not least build a kind of "esprit de corps"
>  > among
>  > those who suffer Rawhide breakages for the greater good would be a
>  > great
>  > start, IMHO.
>  
>  There is already a pool of rawhide users.
>  Rawhide bugs are already reported.
>  
>  The problem is not here, the problem is maintainers that deliberately
>  ignore bugs with rawhide in them (usual excuse and motto are "Rawhide
>  eats
>  babies", "I'll test when Rawhide is more stable", no empathy for
>  other
>  maintainers that can not test because your problem is breaking their
>  test
>  process). They hope the problems will go away before branch time, and
>  then
>  cry they get too little time to fix stuff after branching when the
>  very
>  same problems hit alpha testers, or badger the reporters to file a
>  new
>  report at branch time without even checking the information that was
>  provided before and assuming it is necessarily stale.
>  
>  All the systemd problems were reported in Rawhide way before they hit
>  branched. If they did hit branched it's not because reporting was
>  lacking,
>  but because there was a lack of social pressure not to let Rawhide
>  rot
>  (with easily predictable consequences).
>  
>  When systemd inclusion was deferred in stable because it was not
>  ready and
>  no service had been migrated there was *no* effort I could see to fix
>  the
>  problem in Rawhide and systemd hit the next branch time with all the
>  problems that justified initial deferring intact. 
This is a problem - when developers do not work first in Rawhide and
do not push back to branched (or push into branched from Rawhide if
it's on time). We talked about it in the last Board meeting, one idea
was to block in Bodhi any updates where Rawhide version < update
version.

>  Someone wrote in this thread that Gnome updates were painful in
>  branched.
>  Well they are horrific in Rawhide. If there was some effort to make
>  them
>  only painful in Rawhide they would not be horrific in branched. (this
>  is
>  called a 'virtuous circle').
>  
>  IMHO it was a huge mistake to synchronise Fedora releases with GNOME
>  releases instead of synchronising Fedora branch times with GNOME
>  release
>  times. That's idiotic and means there is no time Fedora-side to do
>  any QA
>  and fixing before pushing a new GNOME release to users. 
I think there's some sync between GNOME and Fedora releases - I already
proposed F19 schedule - 3.7.90 is a week before branching, and before
Alpha, 3.8.0 release precedes Features 100% complete and thus it goes
to Beta. Or are you talking about having final even before branching?
The current process allows us to influence (in some extend) development
of GNOME based on Alpha release etc. And yeah, it's probably not enough.

>  (two high-visibility examples anyone can understand, not necessarily
>  the
>  worst offenders and systemd people at least seem to have improved
>  their
>  workflow a little over time)
>  
>  Adding time to the end of the circle is compounding the problem, not
>  fixing it. 
Another thing would be use more the GIT workflow while building stuff
for Rawhide. For example - it takes quite a lot of time to build the
whole KDE stack for Rawhide and of course, this leads to breakage -
and if upstream decides to push back release when we're in the middle
(it happened) we were screwed. So use own build target, merge/push
to Rawhide once it's done. Question is how demanding would this 
behaviour be for infrastructure (if used more often by more teams,
or even required by a policy).

R.
 
>  --
>  Nicolas Mailhot
>  
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

Rawhide

[Panu Matilainen]

On 11/05/2012 01:12 PM, Jaroslav Reznik wrote:
>  ----- Original Message -----
> >
> > Le Lun 5 novembre 2012 10:45, Dodji Seketeli a écrit :
> >
> >> Just having a dedicated Rawhide Swat Team of die hard volunteers
> >> who
> >> could spot issues early, file more bugs, gently push for fixes in
> >> Rawhide and last but not least build a kind of "esprit de corps"
> >> among
> >> those who suffer Rawhide breakages for the greater good would be a
> >> great
> >> start, IMHO.
> >
> > There is already a pool of rawhide users.
> > Rawhide bugs are already reported.
> >
> > The problem is not here, the problem is maintainers that deliberately
> > ignore bugs with rawhide in them (usual excuse and motto are "Rawhide
> > eats
> > babies", "I'll test when Rawhide is more stable", no empathy for
> > other
> > maintainers that can not test because your problem is breaking their
> > test
> > process). They hope the problems will go away before branch time, and
> > then
> > cry they get too little time to fix stuff after branching when the
> > very
> > same problems hit alpha testers, or badger the reporters to file a
> > new
> > report at branch time without even checking the information that was
> > provided before and assuming it is necessarily stale.
> >
> > All the systemd problems were reported in Rawhide way before they hit
> > branched. If they did hit branched it's not because reporting was
> > lacking,
> > but because there was a lack of social pressure not to let Rawhide
> > rot
> > (with easily predictable consequences).
> >
> > When systemd inclusion was deferred in stable because it was not
> > ready and
> > no service had been migrated there was *no* effort I could see to fix
> > the
> > problem in Rawhide and systemd hit the next branch time with all the
> > problems that justified initial deferring intact.
>
>  This is a problem - when developers do not work first in Rawhide and
>  do not push back to branched (or push into branched from Rawhide if
>  it's on time). We talked about it in the last Board meeting, one idea
>  was to block in Bodhi any updates where Rawhide version < update
>  version. 
+1

Changes really need go to rawhide first and then where applicaple, 
pulled to branches. If it feels painful, that's quite possibly a symptom 
of being out of sync with the development window. The current situation 
where branched tree gets ALL the attention when present is much like 
flipping back and forth between left- and right-handed traffic rules: 
much chaos, many collisions and lost bits and pieces ensues.

> > Someone wrote in this thread that Gnome updates were painful in
> > branched.
> > Well they are horrific in Rawhide. If there was some effort to make
> > them
> > only painful in Rawhide they would not be horrific in branched. (this
> > is
> > called a 'virtuous circle').
> >
> > IMHO it was a huge mistake to synchronise Fedora releases with GNOME
> > releases instead of synchronising Fedora branch times with GNOME
> > release
> > times. That's idiotic and means there is no time Fedora-side to do
> > any QA
> > and fixing before pushing a new GNOME release to users.
>
>  I think there's some sync between GNOME and Fedora releases - I already
>  proposed F19 schedule - 3.7.90 is a week before branching, and before
>  Alpha, 3.8.0 release precedes Features 100% complete and thus it goes
>  to Beta. Or are you talking about having final even before branching?
>  The current process allows us to influence (in some extend) development
>  of GNOME based on Alpha release etc. And yeah, it's probably not enough. 
Its easy to see why eg GNOME wants to sync with Fedora the way its 
currently done, but such massive packageset updates in branched 
invalidate much of the earlier testing.

The stabilization period (ie going from alpha to final through X number 
of intermediate steps) of a distribution and upstream software projects 
are fairly different in nature: In a software project its about fixing 
regressions and bugs in newly introduced features. A distribution 
stabilization is about integrating the hundreds and thousands of 
individual components to something coherent, and doing that is not 
really possible if the components keep radically changing.

	- Panu -

Rawhide

[Bruno Wolff III]

On Mon, Nov 05, 2012 at 06:12:59 -0500,
   Jaroslav Reznik <jreznik(a)redhat.com&gt; wrote:
> ----- Original Message -----
>
> This is a problem - when developers do not work first in Rawhide and
> do not push back to branched (or push into branched from Rawhide if
> it's on time). We talked about it in the last Board meeting, one idea
> was to block in Bodhi any updates where Rawhide version < update
> version. 
In some cases there aren't even rawhide builds. Branched builds are being 
inherited into rawhide once they hit the branched stable release.

Rawhide

[Peter Robinson]

On Mon, Nov 5, 2012 at 1:14 PM, Bruno Wolff III <bruno(a)wolff.to&gt; wrote:

>  On Mon, Nov 05, 2012 at 06:12:59 -0500,
>    Jaroslav Reznik <jreznik(a)redhat.com&gt; wrote:
>
> > ----- Original Message -----
> >
> > This is a problem - when developers do not work first in Rawhide and
> > do not push back to branched (or push into branched from Rawhide if
> > it's on time). We talked about it in the last Board meeting, one idea
> > was to block in Bodhi any updates where Rawhide version < update
> > version.
> >
>
>  In some cases there aren't even rawhide builds. Branched builds are being
>  inherited into rawhide once they hit the branched stable release.
>  
Yep which causes major problems if something they depend on is bumped on
rawhide as the inheritance just breaks a lot of stuff.

Peter

Rawhide

[Nicolas Mailhot]

Le Lun 5 novembre 2012 12:12, Jaroslav Reznik a écrit :
>  ----- Original Message -----
> >
> > Le Lun 5 novembre 2012 10:45, Dodji Seketeli a écrit : 
> > Someone wrote in this thread that Gnome updates were painful in
> > branched.
> > Well they are horrific in Rawhide. If there was some effort to make
> > them
> > only painful in Rawhide they would not be horrific in branched. (this
> > is
> > called a 'virtuous circle').
> >
> > IMHO it was a huge mistake to synchronise Fedora releases with GNOME
> > releases instead of synchronising Fedora branch times with GNOME
> > release
> > times. That's idiotic and means there is no time Fedora-side to do
> > any QA
> > and fixing before pushing a new GNOME release to users.
>
>  I think there's some sync between GNOME and Fedora releases - I already
>  proposed F19 schedule - 3.7.90 is a week before branching, and before
>  Alpha, 3.8.0 release precedes Features 100% complete and thus it goes
>  to Beta. Or are you talking about having final even before branching?
>  The current process allows us to influence (in some extend) development
>  of GNOME based on Alpha release etc. And yeah, it's probably not enough. 
You proposal may work *if* GNOME people take care to respect it. Otherwise
— yes the nuclear option is to only distribute GNOME releases that were
ready at branch time and could be stabilised during all the Fedora test
releases. It may seem excessive but the current
it-says-it-is-stable-push-it-to-users-without-testing policy has not been
good for both of the projects I think.

-- 
Nicolas Mailhot

Rawhide

[Matthias Clasen]

On Mon, 2012-11-05 at 17:04 +0100, Nicolas Mailhot wrote:

>  You proposal may work *if* GNOME people take care to respect it.
> Otherwise
>  — yes the nuclear option is to only distribute GNOME releases that were
>  ready at branch time and could be stabilised during all the Fedora test
>  releases. It may seem excessive but the current
>  it-says-it-is-stable-push-it-to-users-without-testing policy has not been
>  good for both of the projects I think. 
Not sure what you are trying to say - looking at the current blocker but
list, I see barely any GNOME bug there.

Rawhide

[Jesse Keating]

On 11/05/2012 01:33 PM, Matthias Clasen wrote:
>  On Mon, 2012-11-05 at 17:04 +0100, Nicolas Mailhot wrote:
>
> > You proposal may work *if* GNOME people take care to respect it. Otherwise
> > — yes the nuclear option is to only distribute GNOME releases that were
> > ready at branch time and could be stabilised during all the Fedora test
> > releases. It may seem excessive but the current
> > it-says-it-is-stable-push-it-to-users-without-testing policy has not been
> > good for both of the projects I think.
>
>  Not sure what you are trying to say - looking at the current blocker but
>  list, I see barely any GNOME bug there.
>  
<tongue_in_cheek>That might be because nobody can get past the installer 
to test any of the GNOME bits.</tongue_in_cheek>

-- 
Help me fight child abuse: http://tinyurl.com/jlkcourage

- jlk

Rawhide

[Matthew Miller]

On Mon, Nov 05, 2012 at 01:58:05PM -0800, Jesse Keating wrote:
>  <tongue_in_cheek>That might be because nobody can get past the
>  installer to test any of the GNOME bits.</tongue_in_cheek> 
Heh. In seriousness, I've been running F18 GNOME on my laptop and, while I
have a number of annoyances with some design decisions (some patched up by
shell extensions, some not), it seems pretty solid with not very many
outright bugs.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

Rawhide

[M. Edward (Ed) Borasky]

On Mon, Nov 5, 2012 at 2:06 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  On Mon, Nov 05, 2012 at 01:58:05PM -0800, Jesse Keating wrote:
> > <tongue_in_cheek>That might be because nobody can get past the
> > installer to test any of the GNOME bits.</tongue_in_cheek>
>
>  Heh. In seriousness, I've been running F18 GNOME on my laptop and, while I
>  have a number of annoyances with some design decisions (some patched up by
>  shell extensions, some not), it seems pretty solid with not very many
>  outright bugs. 
Yeah - I shifted my laptop from Fedora 17 GNOME 3 to Fedora 18 TC7
GNOME 3 Saturday and it's behaving very well. I'm doing a lot of
testing with Virtual Machine Manager building all sorts of VMs and so
far the only thing that's bitten me is some bizarre issue with Lubuntu
12.10.

-- 
Twitter: http://twitter.com/znmeb; Computational Journalism Publishers
Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/

How the Hell can the lion sleep with all those people singing "A weem
oh way!" at the top of their lungs?

Rawhide

[Nicolas Mailhot]

Le Lun 5 novembre 2012 22:33, Matthias Clasen a écrit :
>  On Mon, 2012-11-05 at 17:04 +0100, Nicolas Mailhot wrote:
>
> > You proposal may work *if* GNOME people take care to respect it.
> > Otherwise
> > — yes the nuclear option is to only distribute GNOME releases that were
> > ready at branch time and could be stabilised during all the Fedora test
> > releases. It may seem excessive but the current
> > it-says-it-is-stable-push-it-to-users-without-testing policy has not
> > been
> > good for both of the projects I think.
>
>  Not sure what you are trying to say - looking at the current blocker but
>  list, I see barely any GNOME bug there. 
Maybe because people have stopped filling them ?

I can reliably make dconf and gnome-settings eat all system cpu and make
the computer unusable short of an hard reset, have been able to do so for
months, reported it once or twice, the reports were closed each time with
unhelpful comments (do not care about rawhide/if it's misbehaving, it's
because something else makes it misbehave — even though the only thing
running is the gnome shell) so now I don't bother reporting at all (and
that's not the only problem, only the most critical and coe one I see)

When I have testing cycles to spare I send reports to Dan Walsh who does
run rawhide and does make something with the reports I fill.

Bottom line, GNOME has been very successful in discouraging messengers it
didn't like, that does not make it any less broken unfortunately.

-- 
Nicolas Mailhot

Rawhide

[Dodji Seketeli]

"Nicolas Mailhot" <nicolas.mailhot(a)laposte.net&gt; a écrit:

>  Le Lun 5 novembre 2012 10:45, Dodji Seketeli a écrit :
>
> > Just having a dedicated Rawhide Swat Team of die hard volunteers who
> > could spot issues early, file more bugs, gently push for fixes in
> > Rawhide and last but not least build a kind of "esprit de corps" among
> > those who suffer Rawhide breakages for the greater good would be a great
> > start, IMHO.
>
>  There is already a pool of rawhide users. 
I know, I am one those.  And I feel alone.  Us poor Rawhide users could
"Unite", communicate, heck, commiserate!  At least on a psychological
standpoint, that'd be a progress, IMHO.

>  Rawhide bugs are already reported. 
I haven't said that no Rawhide bugs were reported.


You know what, I got some Rawhide bugs fixed by maintainers who don't
seem to be running Rawhide themselves.  And I find that a good step
already.  Just having a little bit more of that could be "nice".

I see this Fedora business as a best-effort, love-ridden task.  I don't
think the kind of problem we are talking about can be solved by a
magical formula; so I am inclined to accept any improvement, even tiny
little ones.  :-)

>  The problem is not here, 
I respectfully disagree.  A part of the problem could be addressed by
having a more organized and visible group of Rawhiders who can help each
other, grow the group by inspiring more Fedora Hackers to join, help
follow the status of particular bugs that are filled, etc ...

>  the problem is maintainers that deliberately
>  ignore bugs with rawhide in them (usual excuse and motto are "Rawhide eats
>  babies", "I'll test when Rawhide is more stable", no empathy for
> other
>  maintainers that can not test because your problem is breaking their test
>  process). 
I obviously agree with you that this is a problem.  Of course.  One
could say that the root cause of the problem is that these maintainers
don't have enough time to advance both their short term agendas (hack on
the features they are aiming for), and the medium to long term agenda of
the Greater Community.  We can argue about this endlessly.  And we can
also start getting those who are already Rawhiders to unite, try to help
themselves and promote their view as something good for the general
interest of our community at large.

>  All the systemd problems were reported in Rawhide way before they
> hit
>  branched. If they did hit branched it's not because reporting was lacking,
>  but because there was a lack of social pressure not to let Rawhide rot
>  (with easily predictable consequences). 
I don't know if *all* of systemd problems were reported, and am not
going to argue about it.  But I know that the systemd issues that
temporarily prevented me to boot Rawhide at some point got resolved
(indirectly at least) in Rawhide.

I think there is room to be optimistic without requiring every single
Fedora developer to run Rawhide.  If at some point we could have one
developer per group working on critical packages (e.g, one developer of
the kernel group, one of GNOME, one for base os stuff, one for the virt
subsystem, etc) to be in the Rawhide Swat Team, it would be just
*great*.  Of course, those of us who want to run Rawhide w/o hacking on
critical packages are welcome too, and they can be hugely helpful.

And I like to believe that we could achieve that by mean of love.  :)

Cheers.

-- 
		Dodji

Rawhide

[Michael Scherer]

On Mon, Nov 05, 2012 at 10:45:00AM +0100, Dodji Seketeli wrote:
>  Kevin Fenzi <kevin(a)scrye.com&gt; a écrit: 
 
>  > Additionally, if some number of these folks who pledge to run
> rawhide
>  > full time were provenpackagers we could just go in and fix things as
>  > they hit (or soon after) instead of waiting a while for fixes to go
>  > out. 
>  
>  [+1] + vigorous nodding. 
Having proven packagers using more their powers seems a good idea in the long run.
( work for the perl-sig, worked for years for Mandriva, and I think if there is issues,
this
could be deal on a case per case basis  )

>    - I'd add, having a way for some provenpackagers of the Rawhide
> Swat
>    Team to temporarily blacklist a (set of) package, if it appears to
>    significantly break something; so that people doing yum update on
>    Rawhide won't brick their system because of well know issue waiting to
>    be solved. 
Technically, that could be done by reusing bodhi and enough person to give -1 karma.

Another solution could be a yum plugin that will get the blacklist from the wiki or 
somewhere, or that would pull it from fedora-people whatever.

-- 
Michael Scherer

Rawhide

[Kevin Fenzi]

On Mon, 05 Nov 2012 10:45:00 +0100
Dodji Seketeli <dodji(a)seketeli.org&gt; wrote:

...snip...

>  Could we have a rawhide-list for this?  I know fighting
> proliferation
>  of mailing list is a good thing, but practically speaking, being able
>  to quickly scan a mailing list before doing a yum update can help a
>  Rawhider evaluate in advance the odds of his risking to be unable to
>  reboot his machine or not.  :-) 
I thought about that, but I don't think another list is something do so
lightly. How about rawhide folks add a [rawhide] to their email
subjects here to make them easy to filter out/see. 

I'd personally love to see more signal here in this list. 

kevin

Rawhide

[Matthew Miller]

On Mon, Nov 05, 2012 at 07:27:06AM -0700, Kevin Fenzi wrote:
>  I thought about that, but I don't think another list is something
> do so
>  lightly. How about rawhide folks add a [rawhide] to their email
>  subjects here to make them easy to filter out/see. 
>  I'd personally love to see more signal here in this list.  
If anything, *this* should be the rawhide list. Maybe the more useful thing
would be for there to be a separate list for long naval-gazing(*) threads
about Fedora processes, strategy, and future?



* not that there's anything wrong with that.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

Rawhide

[Dodji Seketeli]

Kevin Fenzi <kevin(a)scrye.com&gt; a écrit:

>  On Mon, 05 Nov 2012 10:45:00 +0100
>  Dodji Seketeli <dodji(a)seketeli.org&gt; wrote:
>
>  ...snip...
>
> > Could we have a rawhide-list for this?  I know fighting proliferation
> > of mailing list is a good thing, but practically speaking, being able
> > to quickly scan a mailing list before doing a yum update can help a
> > Rawhider evaluate in advance the odds of his risking to be unable to
> > reboot his machine or not.  :-)
>
>  I thought about that, but I don't think another list is something do so
>  lightly. How about rawhide folks add a [rawhide] to their email
>  subjects here to make them easy to filter out/see.  
Right.  That would work for me too.

>  I'd personally love to see more signal here in this list. 
Go Rawhiders!  :)

-- 
		Dodji

Rawhide

[M. Edward (Ed) Borasky]

On Sat, Nov 3, 2012 at 5:32 PM, Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  So, I have been thinking about rawhide.
>
>  I agree identifying the problems/issues would be good, and I think
>  there's something we can do to help with that:
>
>  Get a nice group of at least 10 or so folks who are active on this list
>  to agree to run it full time on their main machine.
>
>  As we get close to F18 release, I am considering moving my full time
>  laptop to rawhide. If I can get a group of folks to do likewise we can
>  at least identify issues faster and help each other as they come up.
>
>  Additionally, if some number of these folks who pledge to run rawhide
>  full time were provenpackagers we could just go in and fix things as
>  they hit (or soon after) instead of waiting a while for fixes to go
>  out.
>
>  I've run a rawhide vm/test machine here for many years. It's hit it's
>  share of problems, but none were insurmountable. Some of them might
>  have been for folks who were not more experienced tho, so increasing
>  communication around rawhide can only help, IMHO.
>
>  Additional thoughts to help rawhide:
>
>  - It's been suggested before, but could we practically keep N and N-1
>    packages in rawhide repos? Then 'yum downgrade' becomes much more
>    handy. Repodata size and mirror size might shoot that down though.
>
>  - Autoqa could perhaps help out, but I am not holding my breath. ;)
>
>  - Anaconda folks haven't wanted rawhide installer images as they cause
>    people to report bugs on things when not ready, etc. However, could
>    we build nightly cloud images at least? Those could help test things
>    and won't require hitting the installer path.
>
>  - I'm sure there's more ideas to improve it...
>
>  I really think if we get a pool of savvy folks running it day to day we
>  should at least be able to identify the pain points. In my experience
>  with my test machine, rawhide has been pretty boring for the last two
>  cycles, if we can continue to make it so, perhaps the rolling release
>  folks might be able to find it usable.
>
>  kevin
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel 
I have two machines - an ancient workstation (Athlon64 X2 with 4 GB of
RAM) and a one-year-old laptop. I would certainly consider running
Rawhide on the workstation but no way am I running it on the laptop as
my *primary* partition.

That said, I am running F18 beta TC7 on both the workstation and the
laptop as my main distro now and everything seems to be fine. The
workstation still has a Beefy Miracle partition but I haven't used it
in over a week and I'll most likely blow it away. Perhaps I can put
Rawhide on it if it will help the efforts for F18.



-- 
Twitter: http://twitter.com/znmeb; Computational Journalism Publishers
Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/

How the Hell can the lion sleep with all those people singing "A weem
oh way!" at the top of their lungs?

Rawhide

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

For the most part I always run Rawhide.  Except for a few weeks after branch.
 I like to find the SELinux issues early...


> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iEYEARECAAYFAlCX6x4ACgkQrlYvE4MpobMk+wCgmPTaltWIIXgo3Roi/SHzBbRc
> 2i0AmwUCK1Ts3Q0AIX3ESr4gqPlvuyRn
> =TFKv
> -----END PGP SIGNATURE-----

Rawhide

[Till Maas]

On Sat, Nov 03, 2012 at 06:32:20PM -0600, Kevin Fenzi wrote:
>  So, I have been thinking about rawhide. 
>  
>  I agree identifying the problems/issues would be good, and I think
>  there's something we can do to help with that: 
>  
>  Get a nice group of at least 10 or so folks who are active on this list
>  to agree to run it full time on their main machine.  
Rawhide is not intended to be used for anything important and with any
security sensitive data because the used packages are not signed.
Whenever I asked to get Rawhide packages signed I was also told that it
is, because of Rawhide's use case. Everybody using Rawhide for example
to maintainer Fedora packages is endangering the Fedora project.

Nevertheless, I still believe it would be better if Fedora started to
provide signed packages directly from Koji including Rawhide to end this
problem. But looking at the current fedup code it seems that Fedora is
going to be the first distribution that abandons package security more
and more instead of trying to improve it. As far as I know starting with
preupgrade doing insecure updates were promoted and now they are going
to be made mandatory (except for the unsupported yum update method).

Regards
Till

Rawhide

[Nicolas Mailhot]

Le Lun 5 novembre 2012 18:55, Till Maas a écrit :

>  Rawhide is not intended to be used for anything important and with
> any
>  security sensitive data because the used packages are not signed. 
Alas

>  Whenever I asked to get Rawhide packages signed I was also told that
> it
>  is, because of Rawhide's use case. Everybody using Rawhide for example
>  to maintainer Fedora packages is endangering the Fedora project. 
And everyone not using Rawhide to maintain Fedora packages is contributing
to the regular release slips and to the lack of stability of Fedora
releases (because QA time is eaten up by development that is supposed to
have started in Rawhide).

Signing rawhide would be cheap compared to the costs induced by the
current situation.

-- 
Nicolas Mailhot

Rawhide

[Kevin Fenzi]

On Mon, 5 Nov 2012 18:55:51 +0100
Till Maas <opensource(a)till.name&gt; wrote:

>  Rawhide is not intended to be used for anything important and with
> any
>  security sensitive data because the used packages are not signed.
>  Whenever I asked to get Rawhide packages signed I was also told that
>  it is, because of Rawhide's use case. Everybody using Rawhide for
>  example to maintainer Fedora packages is endangering the Fedora
>  project. 
I am pretty sure there was a plan to make koji sign packages. I don't
know what the status of it is however. 

I would personally love to see koji sign all official builds with a
"This was built in koji" key. 

>  Nevertheless, I still believe it would be better if Fedora started
> to
>  provide signed packages directly from Koji including Rawhide to end
>  this problem.  
I agree. Any koji folks have any ideas on the status of this feature
request? 

Oh look: 
https://fedorahosted.org/koji/ticket/203

Looks like there are patches there... anyone able to test or provide
more feedback to get it moving?

>  But looking at the current fedup code it seems that
>  Fedora is going to be the first distribution that abandons package
>  security more and more instead of trying to improve it. As far as I
>  know starting with preupgrade doing insecure updates were promoted
>  and now they are going to be made mandatory (except for the
>  unsupported yum update method). 
Please file bugs/patches? 

I'd like fedup to verify packages if it doesnt already. I'm sure others
would too. 

kevin

Rawhide

[Bruno Wolff III]

On Mon, Nov 05, 2012 at 11:32:07 -0700,
   Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
> I would personally love to see koji sign all official builds with a
> "This was built in koji" key. 
If the same key is used regardless of release that could allow for hard 
links to builds inherited from another release. That could speed up 
mirroring.

Rawhide

[Matthew Miller]

On Mon, Nov 05, 2012 at 11:32:07AM -0700, Kevin Fenzi wrote:
>  > Fedora is going to be the first distribution that abandons
> package
>  > security more and more instead of trying to improve it. As far as I know
>  > starting with preupgrade doing insecure updates were promoted and now
>  > they are going to be made mandatory (except for the unsupported yum
>  > update method).
>  Please file bugs/patches? 
>  I'd like fedup to verify packages if it doesnt already. I'm sure others
>  would too.  
Er, yes. Very much.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

Rawhide

[Dennis Gilmore]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El Mon, 5 Nov 2012 11:32:07 -0700
Kevin Fenzi <kevin(a)scrye.com&gt; escribió:
>  On Mon, 5 Nov 2012 18:55:51 +0100
>  Till Maas <opensource(a)till.name&gt; wrote:
>  
>  > Rawhide is not intended to be used for anything important and with
>  > any security sensitive data because the used packages are not
>  > signed. Whenever I asked to get Rawhide packages signed I was also
>  > told that it is, because of Rawhide's use case. Everybody using
>  > Rawhide for example to maintainer Fedora packages is endangering
>  > the Fedora project.
>  
>  I am pretty sure there was a plan to make koji sign packages. I don't
>  know what the status of it is however. 
>  
No one is working on it at all. Im actually kind of against the idea.
as things currently stand we would instantly double the disk we need
for /mnt/koji all the key would give us is a yes this build was done as
a real build in koji. the security of the gpg key would be less since
we need to have automated processes able to access the key. the value
of the signed rpm is less.  it also opens up another attack vector that
"could" be exploited.  we would need to sign the metadata or still
resign all the rpms which each has associated costs. signing the
metadata means someone will need to manually do it at the end of a
package push process. in the case of branched or rawhide if we signed
its metadata could be hours until someone wakes up to sign the
metadata. or changing when the runs happen. so that it lands later. 

to me the big issue becomes we cant trust the key as much, since its
either open or the password to unlock it is stored in plain text
somewhere so that it can be unlocked  or rpms automatically signed. the
only way to really have it work right would reduce the security and
trust in the key. all we would gain is a way to distinguish an offical
build vs a scratch build in koji or a build someone did to mimic our
environment.

>  I would personally love to see koji sign all official builds with a
>  "This was built in koji" key. 
>  
>  > Nevertheless, I still believe it would be better if Fedora started
>  > to provide signed packages directly from Koji including Rawhide to
>  > end this problem. 
>  
>  I agree. Any koji folks have any ideas on the status of this feature
>  request? 
>  
>  Oh look: 
>  https://fedorahosted.org/koji/ticket/203
>  
>  Looks like there are patches there... anyone able to test or provide
>  more feedback to get it moving?
>  
AFAIK the patches are not at all tested, ive not looked to see if it
would mean we end up using twice the disk we use today or not. it would
also prevent the ability to reclaim disk by purging the signed copy of
the rpm easily. since all rpms would be signed with the same key. we
then would need to either not have our gpg keys expire  or have
processes to resign everything and  switch over to new keys or some
other transitiion method.

>  > But looking at the current fedup code it seems that
>  > Fedora is going to be the first distribution that abandons package
>  > security more and more instead of trying to improve it. As far as I
>  > know starting with preupgrade doing insecure updates were promoted
>  > and now they are going to be made mandatory (except for the
>  > unsupported yum update method).
>  
>  Please file bugs/patches? 
>  
>  I'd like fedup to verify packages if it doesnt already. I'm sure
>  others would too. 
>  
I would think that fedup should force the verification of packages. as
long as its not rawhide they are all signed and can be verified.

Dennis
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
>
> iEYEARECAAYFAlCYl4EACgkQkSxm47BaWfeK4gCfTZFs9k1cJscCVJuaElPe5jFK
> 9oMAoK1xnwjEx9kQdQFt7XHKHcaNTd74
> =52Ak
> -----END PGP SIGNATURE-----
>

Rawhide

[Colin Walters]

On Mon, 2012-11-05 at 22:52 -0600, Dennis Gilmore wrote:
>  all we would gain is a way to distinguish an offical
>  build vs a scratch build in koji or a build someone did to mimic our
>  environment. 
I think what people mainly want here is a means to protect against
man-in-the-middle attacks between the build server and their machines.

This could be solved equivalently with SSL, but the problem with that is
of course that Fedora relies heavily on a volunteer mirror network, and
not many of them have it enabled; at least, trying to do s/http/https/
on some of the links in
http://mirrors.fedoraproject.org/publiclist/Fedora/development/x86_64/
got me 1 out of 10.

Rawhide

[Jesse Keating]

On 11/05/2012 09:55 AM, Till Maas wrote:
>  Nevertheless, I still believe it would be better if Fedora started
> to
>  provide signed packages directly from Koji including Rawhide to end this
>  problem. 
That's been an accepted proposal for a while now, just needs somebody to 
work on it.

http://fedoraproject.org/wiki/Koji_Build_Autosign_Proposal

-- 
Help me fight child abuse: http://tinyurl.com/jlkcourage

- jlk

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Bruno Wolff III]

On Sun, Nov 04, 2012 at 00:26:08 +0100,
   Michael Scherer <misc(a)zarb.org&gt; wrote:
> Le samedi 03 novembre 2012 à 07:46 -0500, Bruno Wolff III a écrit :
>
> I do not run it, so I cannot judge, but I think the first step to fix
> something is to know the exact problems to fix. If the issue is "too
> much breakage", how can we ensure the most annoying issues are prevented
> ( I am pretty confident in autoQA personnaly ) ? 
Well one issue is packagers not doing rawhide builds. This has two issues. 
One is that rawhide doesn't pick up fixes in updates-testing so doesn't get 
the latest updates. The other is that the packages aren't built against 
rawhide libraries which can cause breakage when libraries change.

> And also, if rawhide start to be more used, we should ensure if
> doesn't
> divde the community in 2 groups ( as I have seen some people complain on
> others distributions that stable release are neglected because devs run
> "$dev_distro" and not the stable release ) 
In Fedora's case the problem is reversed. Rawhide doesn't get enough attention.

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Simo Sorce]

On Sat, 2012-11-03 at 00:18 +0100, drago01 wrote:
>  On Sat, Nov 3, 2012 at 12:04 AM, Adam Williamson
> <awilliam(a)redhat.com&gt; wrote:
>  > [...]
>  > * Upgrading every year, with an unreliable upgrade process, is not
>  > something you have to do with a proper stable OS
>  
>  I am not sure why you call it unreliable ... I *never* reinstall
>  unless I really had to (moving one installation from i386 to x86_64). 
On one machine I did upgrade from i386 -> x86_64 just for fun.
Sure I had to drop in single user 3-4 times and manually install some
rpm but eventually I got it done (it was a VM ;)

>  Otherwise I always upgrade using either anaconda back in the days
> and
>  then preupgrade.
>  
>  There is some weird attitude that "upgrades don't work anyway people
>  should just reinstall". Not only is a reinstall a lot more work it is
>  just not something you could ask from a user to do every 6-12 months. 
it would be nice to squash 2 release cycles and use the gained time to
make a better upgrade process imo.

>  Technically there is no difference between an upgrade and package
>  updates just the package set is larger, it just makes dealing with
>  stuff like usrmove easier. If an update from foo-1.0 to foo-2.0 breaks
>  the whole system it will regardless whether you upgrade from FN-1 to
>  FN or doing a "yum update" in a rolling release. 
+1

however there is a difference, sometime many little changes over time
can run much smoother than one big change at once where you go tfrom pkg
release N-10 to N

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Adam Williamson]

On Fri, 2012-11-02 at 16:04 -0700, Adam Williamson wrote:

>  My fundamental argument is there's a bit of a
>  disconnect between our release process - which is sort of aping the way
>  a stable general-purpose OS would be released, but on fast-forward and
>  with far fewer resources - and our actual goals for the project and the
>  standards we really enforce. We don't _need_ the heavy, constant release
>  cycle we currently employ in order to deliver the good things we already
>  currently deliver. 
Sorry, couldn't resist one more note on this; again with the emphasis on
'big picture' and 'historical perspective' that I like, I think it's
interesting to consider that the development schedule we use at present
is still more or less what Red Hat Linux was using, what, a decade ago?
I've been using Linux since around that time - 2000/2001 - and the 'six
month stable release cycle' was the norm even _then_. Yet back then
'Linux' was a far smaller world than it is now and far more static. In
recent releases the level of change has been, put into perspective,
frenetic. We seem to do massive rewrites on one fundamental chunk of
infrastructure after another. udev was considered a massive change back
in the day, which distros took years to adjust to; now we seem to toss
out bits of the bedrock on a weekly basis (hyperbole again, I know). We
seem to have been rewriting the whole cluster of systemd+udev
+udisks/DeviceKit+PolicyKit+dracut+plymouth+ConsoleKit - that whole ball
of wax - more or less constantly for several years (you may notice two
of the components in that list have been introduced and thrown away
within that space of time...one of them has been obsoleted *twice*), the
churn in that stack is crazy. We re-wrote the installer's storage code,
stopped for twenty seconds to take a breath, then introduced a new
bootloader and switched to GPT disk labels at the same time for an
encore. Now we're rewriting the entire installer UI...and we're planning
to switch to a revolutionary new filesystem whose userspace implications
have barely been mapped out...for the next release (I know this isn't an
official plan yet, but it's the stated intention of the btrfs devs). We
did the big change to kernel modesetting for graphics drivers. We
introduced PulseAudio. GNOME 3 and KDE 4 showed up. In the meantime
we've written and introduced an entire virtualization stack into the
distro, and added all kinds of other ambitious new features. And I'm
sure I'm not even scratching the surface. It kind of feels like for the
last five years we've been rewriting more or less the entire
distribution from top to bottom every few months (and this applies
outside of Fedora, albeit to a lesser extent, as well). It could be
memory playing tricks on me, but I'm pretty sure we didn't have anything
like that churn rate back when the six month release cycle became the de
facto 'industry standard' a decade or more ago.

This doesn't necessarily link into the 'rolling release model' argument
at all, it just seemed like an interesting perspective to keep in mind
in relation to the overall questions we're looking at here.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Simo Sorce]

On Fri, 2012-11-02 at 16:04 -0700, Adam Williamson wrote:
>  On Fri, 2012-11-02 at 16:31 -0600, Kevin Fenzi wrote:
>  > On Fri, 02 Nov 2012 15:17:02 -0700
>  > Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  > 
>  > ..snip...
>  > 
>  > > If you're using a Fedora release today you're _already_ fighting OS
>  > > bugs more often than most people do, I'd say. I disagree with drago's
>  > > assertion that my description was of people who use Rawhide. It was
>  > > not intended to be, and it was drawn from the experience of me and
>  > > other people who do not run Rawhide. I almost never run Rawhide, only
>  > > Branched.
>  > 
>  > Perhaps you have your head too much in the Branched world right now?
>  
>  Not really. I think I have my head more in the 'real' world than some
>  Fedora folks do though ;)
>  
>  I usually run Branched on my desktop and current stable (F-N) on my
>  laptop. How stable is that? Well, the sound on my laptop broke with F17.
>  For several months. It only got fixed because I took the bug upstream
>  and then ensured the fix got ported down into Fedora...that's the
>  experience that *someone who knows how to get people to fix his bugs*
>  has with our product. Imagine the experience a normal person has. 
Some time it is a bit painful, but on average it's ok, I've seen the
same kind of issues on any OS, imagine how nice it is to report a bug
like that to Microsoft or Apple ... in most cases you get back a: ask
your sound cared/laptop retailer ... and they will blame their OEM
and  ... if you are lucky they already solved it otherwise tough luck.

>  Sure, like I said in another mail, we've got better at that than
> before.
>  But as I also said in the same mail, you still have to do a version
>  upgrade every twelve months. That alone is ridiculous for a 'stable'
>  operating system.
>  
>  I don't think we destabilize things - in the sense of 'you update and
>  your machine stops working' very often within a single one of our stable
>  releases. That isn't my point, really. My points are more: 
I think you are confusing stable with LTS.

Stable means upgrade won't break what works, it doesn't mean that we
will fix all the known bugs and it also doesn't mean we maintain it
forever.
It does mean that it would be nice if upgrades were relatively smooth
and just plain possible.
And if you use a rolling developer model where upgrades *must* be
graceful, then you should get that for free, however you will need to do
a little bit more work to put stuff in development, just dumping the
latest upstream master tree snapshot and hoping it works won't cut it.
At the very least you need to do a smoke test upgrading from the
previous one.

>  * Upgrading every year, with an unreliable upgrade process, is not
>  something you have to do with a proper stable OS 
On some stable OSs you cannot upgrade *at all*. It is true that some OSs
are maintained for longer time. A short release cycle puts a lot more
emphasis on working updates, but to be honest I haven't had huge issues
with Fedora, no more than I used to with debian/ubuntu
There are some cases were it went south on some releases and I had to
manually handle it. But then if that's a problem we could simply create
a /home partition by default and users can choose to reinstall just the
OS and keep the /home intact.
For a desktop that should be ok in all cases where you fear an upgrade
would be too dangerous.

>  * We do not insist on a level of polish or lack of functional
> regression
>  in our stable releases which is any way consistent with a true
>  productized general purpose OS 
Maybe if we cut stable releases to 1 we can improve this ?

The only real reason we maintain N-2 is that forcing a 6mo update on
everyone is just ridiculous, but a 1y cycle seems reasonable enough, and
with a rolling devel release there would be less reason for frequent
stable releases.

>  I'm as well placed as anyone to know _exactly_ what we as a
> project are
>  happy with signing off on as a final release, and based on my experience
>  working on, using, and doing user support for various distributions and
>  operating systems, I'm happy to maintain that that level is nowhere near
>  a level suitable for a general-purpose stable OS. Our standard for a
>  final release is, broadly, that the installer works pretty well, there
>  are no giant booboos on the desktop, and you can run the updater. We
>  don't care if a feature that was introduced in the previous release is
>  completely broken, unless it affects the critical path, we just say 'fix
>  it with an update'. We don't hold releases for cosmetic bugs, even
>  really obvious ones. We don't hold releases for usability issues. These
>  are all things that serious grown-up operating systems do. 
I think this is ok, and also the reason why most people wait a month
after GA, it is usually fixed by then because *finally* developers moved
on the new "stable" release, discovered all the bigger issues, and fixed
them. It means that stable isn't really stable enough for less technical
users until 1mo after release but that is ok IMO.

>  That's fine. My posts have a general negative tone just based on
> the way
>  I'm constructing my argument, but it's important to realize I don't
>  think this is a _problem_. I think what we achieve is roughly what many
>  people who run Fedora want. But we _only_ achieve that level, and we
>  really don't need this unwieldy system of maintaining four releases at a
>  time to achieve it. 
I agree I find the current scheme a bit silly too.

>   My fundamental argument is there's a bit of a
>  disconnect between our release process - which is sort of aping the way
>  a stable general-purpose OS would be released, but on fast-forward and
>  with far fewer resources - and our actual goals for the project and the
>  standards we really enforce. We don't _need_ the heavy, constant release
>  cycle we currently employ in order to deliver the good things we already
>  currently deliver. 
+1 really

>  Anyway, I think the point is mashed into the ground by now, so
> I'll
>  stop. My proposal is more about trying to get people thinking at a
>  fundamental level than it is necessarily something I actually expect the
>  project to adopt wholesale - I just want to make the point that, in
>  designing whatever changes we may make to our processes, we should keep
>  a realistic view of what Fedora is actually _for_, and not over-engineer
>  things. 
I think you should push your vision forward instead, I am sure on board
reducing the number of releases and silly work, and having a better
development version that more people can really use.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Šimon Lukašík]

On 11/03/2012 12:30 AM, Simo Sorce wrote:
>  On Fri, 2012-11-02 at 16:04 -0700, Adam Williamson wrote:
> > * Upgrading every year, with an unreliable upgrade process, is not
> > something you have to do with a proper stable OS
>  
>  On some stable OSs you cannot upgrade *at all*. It is true that some OSs
>  are maintained for longer time. A short release cycle puts a lot more
>  emphasis on working updates, but to be honest I haven't had huge issues
>  with Fedora, no more than I used to with debian/ubuntu
>  There are some cases were it went south on some releases and I had to
>  manually handle it. But then if that's a problem we could simply create
>  a /home partition by default and users can choose to reinstall just the
>  OS and keep the /home intact.
>  For a desktop that should be ok in all cases where you fear an upgrade
>  would be too dangerous.
>  
> > * We do not insist on a level of polish or lack of functional regression
> > in our stable releases which is any way consistent with a true
> > productized general purpose OS
>  
>  Maybe if we cut stable releases to 1 we can improve this ?
>  
>  The only real reason we maintain N-2 is that forcing a 6mo update on
>  everyone is just ridiculous, but a 1y cycle seems reasonable enough, and
>  with a rolling devel release there would be less reason for frequent
>  stable releases.
>   
I like where this is going, here is another view or counter proposal to
rolling updates.

Currently, each Fedora release is kept alive for 13(+/-) months. There
were dozens of threads about shortening or prolonging period -- but I am
not sure if something like the following has been ever discussed:

Each N-th Fedora release -- where N%3==1 -- is alive for 7 months.
Each N-th Fedora release -- where N%3==2 -- is alive for 7 months.
Each N-th Fedora release -- where N%3==0 -- is alive for 19 months.

Additionally, maintainers might be encouraged to push their system wide
changes into N%3==1. As well as they might be encouraged to make the
Fedora N%3==0 their best bread.

--
Simon Lukasik

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Tom Lane]

Simon Lukasik <isimluk(a)fedoraproject.org&gt; writes:
>  Currently, each Fedora release is kept alive for 13(+/-) months.
> There
>  were dozens of threads about shortening or prolonging period -- but I am
>  not sure if something like the following has been ever discussed: 
>  Each N-th Fedora release -- where N%3==1 -- is alive for 7 months.
>  Each N-th Fedora release -- where N%3==2 -- is alive for 7 months.
>  Each N-th Fedora release -- where N%3==0 -- is alive for 19 months. 
>  Additionally, maintainers might be encouraged to push their system
> wide
>  changes into N%3==1. As well as they might be encouraged to make the
>  Fedora N%3==0 their best bread. 
Wouldn't that just encourage 99% of average users to ignore the
short-lived releases?  It would sure be a damn tempting approach for me.
(Personally, all I want out of Fedora is a stable platform to get my
work done on, and the less often I have to reinstall, the better.)

I think what you'd have using the short-lived releases is just the same
kind of brave souls who are willing to run rawhide or pre-release
branched systems.  And there aren't that many of them, so you'd get
little QA, which would help to ensure those releases remain buggy, thus
creating a nasty feedback loop that further helps to drive away people
whose main interest is not in helping to debug the system.  Eventually
the short-lived releases would just be rawhide-with-a-different-name.

			regards, tom lane

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Reindl Harald]

Am 04.11.2012 17:05, schrieb Tom Lane:
>  Simon Lukasik <isimluk(a)fedoraproject.org&gt; writes:
> > Currently, each Fedora release is kept alive for 13(+/-) months. There
> > were dozens of threads about shortening or prolonging period -- but I am
> > not sure if something like the following has been ever discussed:
>  
> > Each N-th Fedora release -- where N%3==1 -- is alive for 7 months.
> > Each N-th Fedora release -- where N%3==2 -- is alive for 7 months.
> > Each N-th Fedora release -- where N%3==0 -- is alive for 19 months.
>  
> > Additionally, maintainers might be encouraged to push their system wide
> > changes into N%3==1. As well as they might be encouraged to make the
> > Fedora N%3==0 their best bread.
>  
>  Wouldn't that just encourage 99% of average users to ignore the
>  short-lived releases?  It would sure be a damn tempting approach for me.
>  (Personally, all I want out of Fedora is a stable platform to get my
>  work done on, and the less often I have to reinstall, the better.) 
why is it not considered to change the release cycle from 6 to 12 months?

for large changes this would be daramtically less pressure to any contributor
and give time to polish the changes instead release them in hurry as often
happended (systemd, GNOME3 as examples)

IMHO there could be something done for non-destructive updates like
LibreOffice as for the kernel which is a recent one since a really
long time and it works mostly good

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Šimon Lukašík]

On 11/04/2012 05:05 PM, Tom Lane wrote:
>  Simon Lukasik <isimluk(a)fedoraproject.org&gt; writes:
> > Currently, each Fedora release is kept alive for 13(+/-) months. There
> > were dozens of threads about shortening or prolonging period -- but I am
> > not sure if something like the following has been ever discussed:
>  
> > Each N-th Fedora release -- where N%3==1 -- is alive for 7 months.
> > Each N-th Fedora release -- where N%3==2 -- is alive for 7 months.
> > Each N-th Fedora release -- where N%3==0 -- is alive for 19 months.
>  
> > Additionally, maintainers might be encouraged to push their system wide
> > changes into N%3==1. As well as they might be encouraged to make the
> > Fedora N%3==0 their best bread.
>  
>  Wouldn't that just encourage 99% of average users to ignore the
>  short-lived releases?  It would sure be a damn tempting approach for me.
>  (Personally, all I want out of Fedora is a stable platform to get my
>  work done on, and the less often I have to reinstall, the better.)
>   
If You are suggesting that the majority of our users would prefer
stability over features......well, in that case we may have something to
think about.

>  I think what you'd have using the short-lived releases is just
> the same
>  kind of brave souls who are willing to run rawhide or pre-release
>  branched systems.  And there aren't that many of them, so you'd get
>  little QA, which would help to ensure those releases remain buggy, thus
>  creating a nasty feedback loop that further helps to drive away people
>  whose main interest is not in helping to debug the system.  Eventually
>  the short-lived releases would just be rawhide-with-a-different-name.
>  
>  			regards, tom lane

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Nikos Roussos]

Tom Lane <tgl(a)redhat.com&gt; wrote:
> Simon Lukasik <isimluk(a)fedoraproject.org&gt; writes:
> > Currently, each Fedora release is kept alive for 13(+/-) months.
> There
> > were dozens of threads about shortening or prolonging period -- but I
> am
> > not sure if something like the following has been ever discussed:
>
> > Each N-th Fedora release -- where N%3==1 -- is alive for 7 months.
> > Each N-th Fedora release -- where N%3==2 -- is alive for 7 months.
> > Each N-th Fedora release -- where N%3==0 -- is alive for 19 months.
>
> > Additionally, maintainers might be encouraged to push their system
> wide
> > changes into N%3==1. As well as they might be encouraged to make the
> > Fedora N%3==0 their best bread.
>
> Wouldn't that just encourage 99% of average users to ignore the
> short-lived releases?  It would sure be a damn tempting approach for
> me.
> (Personally, all I want out of Fedora is a stable platform to get my
> work done on, and the less often I have to reinstall, the better.) 
99% is an overestimation. Personally I would prefer to update every 6 months just to have
all the latest stuff, but if I support an organization with many Fedora installations I
would choose the  N%3==0 release, which would provide me only security updates after 7
months.

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Przemek Klosowski]

On 11/02/2012 07:04 PM, Adam Williamson wrote:

>  Sure, like I said in another mail, we've got better at that than
> before.
>  But as I also said in the same mail, you still have to do a version
>  upgrade every twelve months. That alone is ridiculous for a 'stable'
>  operating system.
>  
This is an important point---it makes it difficult to deploy Fedora for 
other people. When the end-of-support comes, it usually means having to 
reinstall, because upgrade can take unbounded time, if problems pop up. 
Additionally, in my experience, a reinstall often results in a better 
configuration, free of grandfathered suboptimal settings.

I keep thinking about a scheme to roll over an EOL Fedora into a closest 
possible CENTOS. It's not trivial because I can't just look for the 
CENTOS that matches the original Fedora release, because of the 
subsequent updates. It would have to look at the as-is system and try to 
figure out the best matching CENTOS release. I am thinking about a 
sum-of-squared-differences-like distance metric: calculate sum over all 
packages of (installed_version - CENTOS_X_version)^2, for several 
CENTOS_X versions, and chose the one giving the smallest value. Of 
course some packages (glibc, kernel) would have a higher weight, but 
that could be incorporated (\sum_i((v1_i-v2_i)^2/wght_i)).

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Jóhann B. Guðmundsson]

On 11/05/2012 05:28 PM, Przemek Klosowski wrote:
>  On 11/02/2012 07:04 PM, Adam Williamson wrote:
>
> > Sure, like I said in another mail, we've got better at that than before.
> > But as I also said in the same mail, you still have to do a version
> > upgrade every twelve months. That alone is ridiculous for a 'stable'
> > operating system.
> >
>
>  This is an important point---it makes it difficult to deploy Fedora 
>  for other people. When the end-of-support comes, it usually means 
>  having to reinstall, because upgrade can take unbounded time, if 
>  problems pop up. Additionally, in my experience, a reinstall often 
>  results in a better configuration, free of grandfathered suboptimal 
>  settings.
>
>  I keep thinking about a scheme to roll over an EOL Fedora into a 
>  closest possible CENTOS. It's not trivial because I can't just look 
>  for the CENTOS that matches the original Fedora release, because of 
>  the subsequent updates. It would have to look at the as-is system and 
>  try to figure out the best matching CENTOS release. I am thinking 
>  about a sum-of-squared-differences-like distance metric: calculate sum 
>  over all packages of (installed_version - CENTOS_X_version)^2, for 
>  several CENTOS_X versions, and chose the one giving the smallest 
>  value. Of course some packages (glibc, kernel) would have a higher 
>  weight, but that could be incorporated (\sum_i((v1_i-v2_i)^2/wght_i)). 
Well I personally would rather have centos and other rhel clones unite 
to support a lts release of Fedora instead since it does not take more 
then a missing sysadmin or rhel business decision to more or less render 
those community incapacitated....

JBG

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

>  From: "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt;
>  
>  On 11/05/2012 05:28 PM, Przemek Klosowski wrote:
>  > On 11/02/2012 07:04 PM, Adam Williamson wrote:
>  >
>  >> Sure, like I said in another mail, we've got better at that than 
before.
>  >> But as I also said in the same mail, you still have to do a
> version
>  >> upgrade every twelve months. That alone is ridiculous for a 'stable'
>  >> operating system.
>  >>
>  >
>  > This is an important point---it makes it difficult to deploy Fedora 
>  > for other people. When the end-of-support comes, it usually means 
>  > having to reinstall, because upgrade can take unbounded time, if 
>  > problems pop up. Additionally, in my experience, a reinstall often 
>  > results in a better configuration, free of grandfathered suboptimal 
>  > settings.
>  >
>  > I keep thinking about a scheme to roll over an EOL Fedora into a 
>  > closest possible CENTOS. It's not trivial because I can't just look 
>  > for the CENTOS that matches the original Fedora release, because of 
>  > the subsequent updates. It would have to look at the as-is system and 
>  > try to figure out the best matching CENTOS release. I am thinking 
>  > about a sum-of-squared-differences-like distance metric: calculate sum  
>  > over all packages of (installed_version - CENTOS_X_version)^2,
> for 
>  > several CENTOS_X versions, and chose the one giving the smallest 
>  > value. Of course some packages (glibc, kernel) would have a higher 
>  > weight, but that could be incorporated (\sum_i((v1_i-v2_i)^2/wght_i)).
>  
>  Well I personally would rather have centos and other rhel clones unite 
>  to support a lts release of Fedora instead since it does not take more 
>  then a missing sysadmin or rhel business decision to more or less render  
>  those community incapacitated.... 
+1

This is exactly why I've never adopted one of them.  Like the concept, but 
fear such situations.  I'd love to have a LTS for my servers and have 
something like a rolling Fedora release for *my* workstations.  Other 
workstations that I help support, perhaps something in between.

--
John Florian

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[mike cloaked]

On Fri, Nov 2, 2012 at 10:31 PM, Kevin Fenzi <kevin(a)scrye.com&gt; wrote:

>  On Fri, 02 Nov 2012 15:17:02 -0700
>  Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>
>  ..snip...
>
>  In my experience, in the last few years, Fedora stable releases have
>  become much more stable. My "stable" boxes here at home I have not
>  really had to poke at since I upgraded them to Fedora 17. I apply
>  updates every few days and things keep working along fine.
>
>  In previous cycles there were some real nasty brown paper bag type
>  blowups that required me to do things to downgrade or tweak to keep my
>  stable version working, that (knock on wood) hasn't happened in f16/f17
>  in my experence.
>
>  I realize there are bugs and problems that hit, but I think the stable
>  updates policy has helped keep those down. (Cue KevinK to come in and
>  shout and tell me how wrong I am, etc etc)
>
>  I'm personally -1 to any kind of rolling release beyond rawhide.
>
>  
There are distributions where a rolling release works very well indeed.
 Perhaps I could inject a couple of lines to think about since I use both
Fedora and Archlinux:

In Fedora what is maintained are 1) Two current releases with stable
updates repos for each. 2) Updates-testing repos for both current stable
releases
and 3) Rawhide where volunteer users can expect potential major breakages
periodically. That is five repos of packages.

In Fedora to keep up to date users need a complete re-install either every
year or every six months on every machine that runs Fedora.

In Archlinux there are two repos - [core] and [testing] - once packages
have been QA tested in [testing] then developers can move packages to
[core] when they feel there is minimal risk of major failure for users of
the stable repos.

In Archlinux to keep up to date users need never do a full re-install again
- but there are occasional periods when configs need to be tinkered with or
manual commands entered as root when a major package upgrade takes place
such as glibc or one or two major packages but this is only occasional.
Provided users keep monitoring the news announcements where manual
intervention is required then they have a system where virtually all major
packages are upstream current or close to that.

A complete re-install takes some hours for each machine (or indeed a yum
preupgrade or similar as well) - manual intervention for the occasional
major update to packages in arch linux takes some minutes usually at most.

For users responsible for a significant number of machines having a rolling
release knowing that all major packages are upstream current or close to
that is a major advantage, and time saving, compared to Fedora's need for
major upgrade of the system or re-install.

Fedora is a bit simpler to install for less experienced users but for
experienced linux admins an arch install is not a major issue.

Both Fedora and Archnlinux are generally cutting edge if they are kept
updated - but the effort to keep updated is very different.

Others may wish to compare Fedora with other distributions also - but one
thought I had was that in Archlinux there are only two repos to maintain -
whilst in Fedora it is 5 repos! One might wonder whether there is less
effort needed to keep up to date by the developers in Arch or Fedora - I
don't have the answer to that question but the devs have more knowledge
about effort needed to maintain all of this to make a proper comparison?

Some discussion and thought about these issues are pertinent to the
discussion in this thread.

-- 
mike c

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Adam Williamson]

On Sat, 2012-11-03 at 11:28 +0000, mike cloaked wrote:

>  Others may wish to compare Fedora with other distributions also -
> but
>  one thought I had was that in Archlinux there are only two repos to
>  maintain - whilst in Fedora it is 5 repos! One might wonder whether
>  there is less effort needed to keep up to date by the developers in
>  Arch or Fedora - I don't have the answer to that question but the devs
>  have more knowledge about effort needed to maintain all of this to
>  make a proper comparison? 
Thanks, Mike, that's a great illustration of the point I was trying to
make: the Arch model sounds much like what I was trying to suggest for
Fedora, a simple two-track 'devel' and 'stable' model with QA between
the tracks. And as you point out, on the face of it it appears to
involve much less drudgery for maintainers. I have never run Arch, but I
do get the general impression it provides a sufficiently reliable
experience for the kinds of users Fedora and Arch have.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[mike cloaked]

On Sat, Nov 3, 2012 at 4:29 PM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:

>  On Sat, 2012-11-03 at 11:28 +0000, mike cloaked wrote:
>
>  > Others may wish to compare Fedora with other distributions also - but
>  > one thought I had was that in Archlinux there are only two repos to
>  > maintain - whilst in Fedora it is 5 repos! One might wonder whether
>  > there is less effort needed to keep up to date by the developers in
>  > Arch or Fedora - I don't have the answer to that question but the devs
>  > have more knowledge about effort needed to maintain all of this to
>  > make a proper comparison?
>
>  Thanks, Mike, that's a great illustration of the point I was trying to
>  make: the Arch model sounds much like what I was trying to suggest for
>  Fedora, a simple two-track 'devel' and 'stable' model with QA between
>  the tracks. And as you point out, on the face of it it appears to
>  involve much less drudgery for maintainers. I have never run Arch, but I
>  do get the general impression it provides a sufficiently reliable
>  experience for the kinds of users Fedora and Arch have.
>
>  
Indeed Adam - I guess the choice for running a rolling release or periodic
stable releases, with updates for some support period, is a choice that the
collective developers need to make, and which then developers are happy to
work with or move to where they feel comfortable.

Having said that, it is clear that both Archlinux and Fedora are mainstream
distributions each with significant numbers of users who treat their
installs with sufficient confidence to use their systems on a day to day
basis as a stable platform. Some Fedora people also run with the
updates-testing repo enabled (or in the case or arch with [testing]
enabled) and are ready to fix problems as they arise with occasional
not-completely-stable updates from time to time.

I have only been running archlinux on three machines for less than a year
but I am pretty happy with the way updates arrive and delighted that, when
major upgrades of desktop packages are released upstream, it is not too
long before they are tested and released to [core] so it is nice to have
the very latest KDE for example, and the latest kernel pretty well too. For
Fedora more recently kernels have been superbly close to upstream for all
releases which I am sure must be valued by the user community.

Nevertheless I am also clear that archlinux with its rolling release model
works and works very well indeed. There have been issues occasionally with
Archlinux with things like glibc, and the /usr move but the vast majority
of users have survived with a combination of clear announcement guides as
well as good wiki entries plus mailing list discussions to help with
individual cases which may have been slightly unusual use cases - such as
one user who had not updated at all for many many months and then did a
huge update which included several key upgrades where an interaction
between the order of manual interventions made things a little messy.

So my personal experience of arch has been a very positive one - there are
differences - for example in arch selinux is not centrally supported -
whereas Fedora has been a prime developer for selinux and the vital policy
packages that go with it and included as default for several releases.
However the ease of maintenance means that for the machines I run with arch
make life easier for me, and with careful config settings I have not come
up against a security problem. Everyone has a free choice.

Arch has also recently moved to systemd as its default init system which
was in fact a reasonably simple process to convert to from initscripts -
(it took about 10 minutes once you had read the documentation!) - the
advantage for arch users is that systemd is the latest upstream or pretty
close to - whereas systemd for F16 is somewhat behind current upstream.

I guess that there is likely to always be a split in opinion of the
developers whenever there is a major fork in philosophy options possible
for which way to go in the future - but in the end one way or another a
decision must be taken when everyone's views have been considered - for an
established distribution there is often inertia against change - and many
will see the change as needing more work than people feel may be possible -
nevertheless in this case demonstrably archlinux works - so it is certainly
possible to have a rolling release model and it already exists.It is simply
a philosophy choice as to which model to work with. As to whether Fedora
would wish to change or not is entirely up to those who do the hard work
writing code and keeping all the tools and packages in working order. So
such discussions as in this thread are important - and at the end of the
day people doing the developing need to be on board with the philosophy of
the distribution or work where they feel comfortable.

There have been long discussions previously and at that time the consensus
was to keep the status quo - I guess people will continue to periodically
go through the thought processes and come to a view for which way from that
point in time to move on... and it may remain the status quo - but may move
on to something new - after all systemd had long discussions too - but it
was adopted in the end!  Selinux had long discussions but in the end was
adopted.

Just a few thoughts to add to the discussion!

-- 
mike c

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Michael Scherer]

Le samedi 03 novembre 2012 à 09:29 -0700, Adam Williamson a écrit :
>  On Sat, 2012-11-03 at 11:28 +0000, mike cloaked wrote:
>  
>  > Others may wish to compare Fedora with other distributions also - but
>  > one thought I had was that in Archlinux there are only two repos to
>  > maintain - whilst in Fedora it is 5 repos! One might wonder whether
>  > there is less effort needed to keep up to date by the developers in
>  > Arch or Fedora - I don't have the answer to that question but the devs
>  > have more knowledge about effort needed to maintain all of this to
>  > make a proper comparison?
>  
>  Thanks, Mike, that's a great illustration of the point I was trying to
>  make: the Arch model sounds much like what I was trying to suggest for
>  Fedora, a simple two-track 'devel' and 'stable' model with QA between
>  the tracks. And as you point out, on the face of it it appears to
>  involve much less drudgery for maintainers. I have never run Arch, but I
>  do get the general impression it provides a sufficiently reliable
>  experience for the kinds of users Fedora and Arch have. 
Unfortunately, we do not have enough people doing QA for the model to
work. Each time I run fedora-easy-karma on branched, I have the feeling
to see always the same names ( ie, you and kevin ). I would be
interested to see some stats about this, because the difference between
a unused software and one who have no bug is thin.

And I am doubting that changing the release model will suddenly make
people do QA.

-- 
Michael Scherer

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Panu Matilainen]

On 11/04/2012 12:17 PM, Michael Scherer wrote:
>  Le samedi 03 novembre 2012 à 09:29 -0700, Adam Williamson a écrit :
> > On Sat, 2012-11-03 at 11:28 +0000, mike cloaked wrote:
> >
> >> Others may wish to compare Fedora with other distributions also - but
> >> one thought I had was that in Archlinux there are only two repos to
> >> maintain - whilst in Fedora it is 5 repos! One might wonder whether
> >> there is less effort needed to keep up to date by the developers in
> >> Arch or Fedora - I don't have the answer to that question but the devs
> >> have more knowledge about effort needed to maintain all of this to
> >> make a proper comparison?
> >
> > Thanks, Mike, that's a great illustration of the point I was trying to
> > make: the Arch model sounds much like what I was trying to suggest for
> > Fedora, a simple two-track 'devel' and 'stable' model with QA
> between
> > the tracks. And as you point out, on the face of it it appears to
> > involve much less drudgery for maintainers. I have never run Arch, but I
> > do get the general impression it provides a sufficiently reliable
> > experience for the kinds of users Fedora and Arch have.
>
>  Unfortunately, we do not have enough people doing QA for the model to
>  work. Each time I run fedora-easy-karma on branched, I have the feeling
>  to see always the same names ( ie, you and kevin ). I would be
>  interested to see some stats about this, because the difference between
>  a unused software and one who have no bug is thin.
>
>  And I am doubting that changing the release model will suddenly make
>  people do QA.
>  
Adam's point is that reducing the number of branches requiring QA should 
permit more thorough QA with the scarce resources available, resources 
which currently are spread too wide and too thin with the current model.

	- Panu -

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Tom Lane]

Panu Matilainen <pmatilai(a)laiskiainen.org&gt; writes:
>  On 11/04/2012 12:17 PM, Michael Scherer wrote:
> > And I am doubting that changing the release model will suddenly make
> > people do QA. 
>  Adam's point is that reducing the number of branches requiring QA
> should 
>  permit more thorough QA with the scarce resources available, resources 
>  which currently are spread too wide and too thin with the current model. 
I understand his hope that it would help, but TBH I think it would make
things worse not better.  Consider:

* Currently, we get barely-adequate QA on the frontmost Fedora branch
and none to speak of on the back branches.  (Certainly for my packages,
the standard update cycle is "push update to testing, wait however long
bodhi makes me wait, push to stable" because nobody ever adds any karma
except maybe in the latest branch.)  That's tolerable, actually, because
you're not supposed to push anything but low-risk bugfix updates into
the back branches.  If you think it needs testing you probably shouldn't
be pushing it there.

* In a rolling release model, however, major changes are supposed to
eventually get pushed into all the branches.  Each time one gets pushed
further back, an appropriate amount of QA would need to get done, if you
want to have any expectation of not breaking that branch.  This looks
like *more* QA to me, not less.

The core problem I see here is that in a rolling-release environment,
there's nothing to ensure that major multiple-package-affecting changes
hit the "stable" branches in a consistent order.  That means that each
time you push one back, you are creating a unique new package set with a
unique new set of potential issues, and that's why QA would actually be
needed.  Now it's easy to see how to avoid that: force consistency.
But that idea leads you right back to the series-of-releases approach
that we have now.

			regards, tom lane

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Tom Lane]

Adam Williamson <awilliam(a)redhat.com&gt; writes:
>  On Fri, 2012-11-02 at 17:53 -0400, Tom Lane wrote:
> > I've seen a whole lot of user demand for *more* stable versions of
> > Fedora.  I've seen none whatever for less stable versions. 
>  Perhaps I ought to be more clear. I think we can maintain the level
> of
>  *actual* stability our current 'stable' releases provide with a model
>  such as I describe, while substantially reducing the amount of resources
>  we're wasting at least _theoretically_ maintaining up to four releases
>  at once (currently, 16, 17, 18 and 19). 
Well, maybe, but yeah you weren't very clear about that.  In any case,
I'm not seeing how we handle things like library ABI breaks with a
rolling release model ... at least not without more work, rather than
less, than we have now.

>  If you're using a Fedora release today you're _already_
> fighting OS bugs
>  more often than most people do, I'd say. 
I don't buy that really.  I hit very few bugs in Fedora -- fewer than
in OS X for instance.  Possibly this is because I use it as a headless
server as much as possible, and thus avoid bugs in the desktop-related
code.  As a development platform it's remarkably stable.  (Now
admittedly, I never run rawhide, and generally wait till a month after
"official release" before updating my main workstation to a new Fedora
version.  But with those simple precautions, it is very stable.)

			regards, tom lane

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Brian Pepple]

On Fri, Nov 2, 2012 at 6:17 PM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  If you're using a Fedora release today you're _already_
> fighting OS bugs
>  more often than most people do, I'd say. I disagree with drago's
>  assertion that my description was of people who use Rawhide. It was not
>  intended to be, and it was drawn from the experience of me and other
>  people who do not run Rawhide. I almost never run Rawhide, only
>  Branched. 
Really? I don't remember the last time I had some kind of breakage in
my stable branch machines. Now, in the development branches that's a
different story, but that's to be somewhat expected due to the daily
churn there.

Later,
/B
--
Brian Pepple <bpepple(a)fedoraproject.org&gt;

https://fedoraproject.org/wiki/User:Bpepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E

Rolling release model philosophy

[Michael Ekstrand]

On 11/02/2012 04:53 PM, Tom Lane wrote:
>  Adam Williamson <awilliam(a)redhat.com&gt; writes:
> > On Fri, 2012-11-02 at 21:07 +0100, drago01 wrote:
> >> I disagree with that. Fedora releases had some small regression
> >> introduced via updates from time but is is *very* usable as a stable
> >> operating system.
>  
> > I disagree. It's usable by the kind of people who use Fedora.
>  
>  Uh, no.  What you describe is usable by the kind of people who use
>  rawhide.  Which is what, 1% of our user base?  If that.
>  
>  Abandoning any pretense of having stable releases will eliminate a huge
>  fraction of the user community.  For sure it will eliminate *me*.  I'm
>  not in the business of fighting OS bugs every single day, and I will not
>  be forced into that business.  I have other things that I'm more
>  productive at. 
+1. One of the major reasons I came to Fedora (after a long tour that
took me through Slackware, Gentoo, Debian Testing, Ubuntu, with brief
stints elsewhere) is that it has releases. Real releases, with most
major changes happening with the new release.

I ran Debian Testing for several years, and encountered a problem. I was
spending too time paying attention to changes and new software
developments, and when they might hit my system, at the expense of
getting work done.

It's purely selfish, my psychology, etc., but I personally basically
need a release, so I can batch up all my "ooh, what's this shiny new
thing?" tendencies in a few days twice a year, rather than an hour here
and an hour there.

Having used Fedora now since F15, I've personally found the releases to
be quite reliable and usable, with just enough software updating over
their lifecycle to keep my laptop rather comfortable. And better than my
brief previous Fedora experience back around F9, when every other kernel
update broke my wireless card[1].

Best,
- Michael

1. Literally. Whether or not my wireless networking worked toggled with
each kernel update with remarkable consistency. I'm glad things are
better now.

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Simo Sorce]

On Fri, 2012-11-02 at 13:22 -0700, Adam Williamson wrote:
>  On Fri, 2012-11-02 at 21:07 +0100, drago01 wrote:
>  > Well your point basically is "we can't/don't ship anything that is
>  > stable so we should give up on that."
>  
>  More or less, yes.
>  
>  > I disagree with that. Fedora releases had some small regression
>  > introduced via updates from time but is is *very* usable as a stable
>  > operating system.
>  
>  I disagree. It's usable by the kind of people who use Fedora. Who like
>  shiny cutting-edge stuff and don't mind dealing with wonkiness
>  constantly. I wouldn't dream of putting any regular person on a Fedora
>  install, quite frankly. 
I do not know in what dreamland you live.

My wife has been running on Fedora since forever, and except some pain
points when we do an upgrade (usually every 2 release) all works just
fine.

If you are advocating for making fedora completely unusable please let
me know in advance so I can start doing my Red Hat work on some other
Linux distro ... I am sure you can read the irony ...


>   It's easy to get into a perspective bubble where
>  Fedora looks normal, but it isn't. It is not a stable general-purpose
>  operating system and it's absurd to represent it as such. I wouldn't put
>  Fedora 17 on my uncle Bob's computer (I don't have an uncle Bob, this is
>  just your hackneyed old 'regular person' example) and say 'there's your
>  computer'. How many of us would? Even if you get a good Fedora release
>  and don't hit problems with updates - which we don't do a _bad_ job of
>  these days, admittedly - our releases really aren't quality general
>  purpose OSes (we let all kinds of weirdnesses go into our releases which
>  a serious user-facing OS would never let go), and after 12 months, you
>  have to do an upgrade, which has about a 50/50 chance of exploding,
>  let's face it. That's not a convincing stable general purpose operating
>  system.
>  
>  It's telling that when you meet 'normal people' who are running Fedora,
>  they're usually using Fedora N-5, which hasn't had security updates for
>  a year and a half. That's how 'normal people' use their computers - they
>  don't upgrade every year and find it _fun_ to fix the upgrade process
>  when it explodes. I don't think we're serving the (few) 'normal people'
>  who run Fedora in this fashion very well, frankly. They'd probably be
>  better off with something else. 
No normal people run on N-1/N-2 and feel the pain points when they
switch to (a month or 2 old) N once N-2 goes out

>  I realize my point of view here is somewhat radical, but you need
> the
>  lunatic fringe around to keep people on their toes, I've always
>  thought. ;) 
I understand you surfing hyperbole here, but keep in mind that no users
means no developers.
Yes some people like to play with all cutting edge, but most people want
to "use" their distro too.

If it is too painful to stabilize every 6 months, may be we should
change to a rolling release for development, and cut stables only once a
year, to be maintained for 1 year only, I would totally love something
like that as long as the development version is more something like
debian testing/experimental than our current rawhide.

>  > Compare it to "always cutting edge" like rawhide ...
> you can't get any
>  > work done with that. It keeps breaking almost every second day.
>  
>  Well, that's why I said two streams. One would be what Rawhide is now
>  and the other would be pretty much branched/stable level. 
rawhide would need to get a little bit more stable to be usable even by
developers in this scheme, doesn't need to be perfect but you can;t have
upgrades that break booting for most people (corner cases always exist
it's development). Currently there is ton of stuff that doesn't even
build until late in the release cycle.

>   On a broad
>  conceptual level - there's several ways of doing this, of course. But my
>  basic point is that the three stream idea works for a project like
>  Debian, which has a conservative approach to everything and is able,
>  over a very long timeframe, to produce something that actually *is* a
>  stable operating system. It's not appropriate to a project like Fedora,
>  which really isn't doing that. How often have we said we don't have the
>  people interested in doing LTS releases, for instance? That's the kind
>  of work you need to maintain a true 'stable' tier in a three-tier
>  system. It's boring maintenance of long-dead code, and that's not
>  generally what Fedora people are interested in. How many maintainers
>  right now are doing a convincing job of maintaining F16? How many people
>  are testing the updates? How many Fedora packagers wake up in the
>  morning and think 'hey, what I really want to do today is carefully test
>  and backport specific fixes to the F16 branches of my packages'? 
Yes this is too much, but we *do* get updates for critical issues, and
not necessarily in form of a rebase.
If we cut the maintenance to one release (instead of the 2 we have now)
and switch development to a rolling release that is usable I agree with
you we can get something reasonable.

Keep in mind that most people are *perfectly* ok with no updates, as
long as we still care for security updates and really only critical
bugfixes I think a lot of people would be happy to run on a 'stable'
release that really is just a frozen development release that had a
month or two of stabilization (just like we do now) and then is left
mostly untouched.

>  > So things aren't perfect now they aren't as bad as you
> paint them to
>  > be. The current anaconda mess is just a project management failure ...
>  > nothing else really.
>  
>  The current anaconda mess is an example I used in my post, but it's not
>  the only one. I've been thinking along these lines for a long while, not
>  related to any particular fire. It's a general perspective. 
There is something I like in what you say, but sound extremist.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Nikos Roussos]

On Fri, 2012-11-02 at 13:22 -0700, Adam Williamson wrote:

>  > I disagree with that. Fedora releases had some small regression
>  > introduced via updates from time but is is *very* usable as a stable
>  > operating system.
>  
>  I disagree. It's usable by the kind of people who use Fedora. Who like
>  shiny cutting-edge stuff and don't mind dealing with wonkiness
>  constantly. 
I mind. So do many Fedora users and contributors, who want a shiny
*stable* leading edge (not bleeding edge) linux distribution.


>  I wouldn't dream of putting any regular person on a Fedora
>  install, quite frankly. It's easy to get into a perspective bubble where
>  Fedora looks normal, but it isn't. It is not a stable general-purpose
>  operating system and it's absurd to represent it as such. 
I understand that "regular users" are not Fedora's main target, but it
is a general-purpose operating system in the sense that it can be used
by people who want to have a stable working environment with all the
latest things from the Open Source world.

In that sense, and from my point of view, if we had to rethink our
release model and dedicate time and energy on a new approach, it would
make more sense to have an extended support release (providing only
security updates after 13 months) which is vital for the enterprise
desktop market. Of course this is not in contradiction with having a
rolling release model alongside, but I didn't know if we have enough
human capacity to do them both.

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Reindl Harald]

Am 03.11.2012 11:35, schrieb Nikos Roussos:

>  In that sense, and from my point of view, if we had to rethink our
> release model and dedicate time and energy on a
>  new approach, it would make more sense to have an extended support release (providing
> only security updates after
>  13 months) which is vital for the enterprise desktop market. 
THAT would make sense if there is a upgrade path between two LTS
releases - let's say the cycle is two years there would be 4
"normal" release cycles and if features with the impact of
systemd are startet after the release of a LTS you have the
full 2 years to polish it AND many users would also use
the current leading edge releases to be first

a comination of both would be really perfect

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Henrique Junior]

2012/11/3 Nikos Roussos <comzeradd(a)fedoraproject.org&gt;

>  **
>  On Fri, 2012-11-02 at 13:22 -0700, Adam Williamson wrote:
>
>  > I disagree with that. Fedora releases had some small regression
>  > introduced via updates from time but is is *very* usable as a stable
>  > operating system.
>
>  I disagree. It's usable by the kind of people who use Fedora. Who like
>  shiny cutting-edge stuff and don't mind dealing with wonkiness
>  constantly.
>
>   I mind. So do many Fedora users and contributors, who want a shiny
>  *stable* leading edge (not bleeding edge) linux distribution.
>
>
>   I wouldn't dream of putting any regular person on a Fedora
>  install, quite frankly. It's easy to get into a perspective bubble where
>  Fedora looks normal, but it isn't. It is not a stable general-purpose
>  operating system and it's absurd to represent it as such.
>
>   I understand that "regular users" are not Fedora's main target, but it is
>  a general-purpose operating system in the sense that it can be used by
>  people who want to have a stable working environment with all the latest
>  things from the Open Source world.
>
>  In that sense, and from my point of view, if we had to rethink our release
>  model and dedicate time and energy on a new approach, it would make more
>  sense to have an extended support release (providing only security updates
>  after 13 months) which is vital for the enterprise desktop market. Of
>  course this is not in contradiction with having a rolling release model
>  alongside, but I didn't know if we have enough human capacity to do them
>  both.
>
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  
The guys behind openSUSE created a good approach with Tumbleweed. By adding
this repo users can opt-in to the (semi)rolling model.
Tumbleweed is more like a pool where updated, stable, non disruptive
software can be installed and I was able to talk to the guy who created
Tumbleweed some time ago. He said that it is easy to maintain and takes
only a few minutes a day to check things.
It is difficult, for example, to understand why we have to wait until the
next release to have LibreOffice 3.6, since this seems an non disruptive
update that could bring major improvements in the productivity of users who
rely on office suites to work.

-- 
Henrique "LonelySpooky" Junior
http://about.me/henriquejunior

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[drago01]

On Sat, Nov 3, 2012 at 12:37 PM, Henrique Junior <henriquecsj(a)gmail.com&gt; wrote:

>  It is difficult, for example, to understand why we have to wait until
> the
>  next release to have LibreOffice 3.6, since this seems an non disruptive
>  update that could bring major improvements in the productivity of users who
>  rely on office suites to work. 
Well that's because we do not make a clear distinction between
"operating system" and applications.

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Adam Williamson]

On Sat, 2012-11-03 at 09:37 -0200, Henrique Junior wrote:

>  The guys behind openSUSE created a good approach with Tumbleweed. By
>  adding this repo users can opt-in to the (semi)rolling model.
>  Tumbleweed is more like a pool where updated, stable, non disruptive
>  software can be installed and I was able to talk to the guy who
>  created Tumbleweed some time ago. He said that it is easy to maintain
>  and takes only a few minutes a day to check things.
>  It is difficult, for example, to understand why we have to wait until
>  the next release to have LibreOffice 3.6, since this seems an non
>  disruptive update that could bring major improvements in the
>  productivity of users who rely on office suites to work. 
I don't think that *adding* tracks is an approach that is going to solve
any of our problems, though it might add convenience for a small set of
users. We need to be making things simpler, not more complex. :)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Nikos Roussos]

Adam Williamson <awilliam(a)redhat.com&gt; wrote:
> On Sat, 2012-11-03 at 09:37 -0200, Henrique Junior wrote:
>
> > The guys behind openSUSE created a good approach with Tumbleweed. By
> > adding this repo users can opt-in to the (semi)rolling model.
> > Tumbleweed is more like a pool where updated, stable, non disruptive
> > software can be installed and I was able to talk to the guy who
> > created Tumbleweed some time ago. He said that it is easy to maintain
> > and takes only a few minutes a day to check things.
> > It is difficult, for example, to understand why we have to wait until
> > the next release to have LibreOffice 3.6, since this seems an non
> > disruptive update that could bring major improvements in the
> > productivity of users who rely on office suites to work.
>
> I don't think that *adding* tracks is an approach that is going to
> solve
> any of our problems, though it might add convenience for a small set of
> users. We need to be making things simpler, not more complex. :) 
And in many cases it's simpler to have security updates for an LTS Fedora version than
upgrading X workstations every 6 or 12 months.

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Adam Williamson]

On Sun, 2012-11-04 at 02:12 +0200, Nikos Roussos wrote:
>  
>  Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  >On Sat, 2012-11-03 at 09:37 -0200, Henrique Junior wrote:
>  >
>  >> The guys behind openSUSE created a good approach with Tumbleweed. By
>  >> adding this repo users can opt-in to the (semi)rolling model.
>  >> Tumbleweed is more like a pool where updated, stable, non disruptive
>  >> software can be installed and I was able to talk to the guy who
>  >> created Tumbleweed some time ago. He said that it is easy to maintain
>  >> and takes only a few minutes a day to check things.
>  >> It is difficult, for example, to understand why we have to wait until
>  >> the next release to have LibreOffice 3.6, since this seems an non
>  >> disruptive update that could bring major improvements in the
>  >> productivity of users who rely on office suites to work.
>  >
>  >I don't think that *adding* tracks is an approach that is going to
>  >solve
>  >any of our problems, though it might add convenience for a small set of
>  >users. We need to be making things simpler, not more complex. :)
>  
>  And in many cases it's simpler to have security updates for an LTS Fedora version
> than upgrading X workstations every 6 or 12 months. 
I meant 'simpler for developers', not 'simpler for users'. This is,
after all, the developer list :)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Matthew Miller]

On Sat, Nov 03, 2012 at 12:35:08PM +0200, Nikos Roussos wrote:
>  I understand that "regular users" are not Fedora's main
> target, but it
>  is a general-purpose operating system in the sense that it can be used
>  by people who want to have a stable working environment with all the
>  latest things from the Open Source world. 
While "regular users" are not Fedora's main target, our target user base
assumes a "general productivity user", including these characteristics:

  We expect the majority of users to be interested in a set of general
  productivity tasks. These tasks are usually non-technical in nature. They
  involve communication and the creation, storage, location, and viewing of
  content. They are common to both novice and experts alike, and we should
  deliver a platform that allows users to engage in these tasks without
  interruption or disruption.

Which I think supports your position. (Leading edge, not bleeding edge.)


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Matej Cepl]

On Fri, 02 Nov 2012 13:22:21 -0700, Adam Williamson wrote:
>  I disagree. It's usable by the kind of people who use Fedora. Who
> like
>  shiny cutting-edge stuff and don't mind dealing with wonkiness
>  constantly. I wouldn't dream of putting any regular person on a Fedora
>  install, quite frankly. It's easy to get into a perspective bubble where
>  Fedora looks normal, but it isn't. It is not a stable general-purpose
>  operating system and it's absurd to represent it as such. I wouldn't put
>  Fedora 17 on my uncle Bob's computer (I don't have an uncle Bob, this is
>  just your hackneyed old 'regular person' example) and say 'there's your
>  computer'. How many of us would? Even if you get a good Fedora release 
Completely agree with Adam ... I was working on the solution for my 
family (both my wife and kids are on Linux, of course). After having my 
wife on Fedora for some time and listening to her constant complaints 
about awful amount of updates she doesn't care for and doesn't want to 
have installed all the time (BTW, could somebody fix PackageKit updates 
so that it actually can keep system updated for a long period of time 
without needed intervention on the command line from time to time?). In 
the end I have switched her to CentOS+EPEL+some-rpmfusion-packages-which-
were-not-avaliable and she is a very happy lady. Updates are reasonable 
and system will hopefully hold together for a long time.

Best,

Matěj

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Jóhann B. Guðmundsson]

On 11/02/2012 07:56 PM, Adam Williamson wrote:
>  Anyway, we've rather torpedo'ed the feature process
> discussion now, and
>  I'm sorry about that :/. Hence the topic change. But while we're blue
>  sky thinking about massive release process changes, I think it's worth
>  keeping a firm grasp on what Fedora is really about and what it's
>  capable of achieving. 
I argue that we should have one "rolling release" which users would be 
forced to upgrade to every 9 months or so ( following browsers example ) 
and one "stable" release ( valid for 2 maybe 3 years ) for those in the 
community that want something they dont constantly having to upgrade to 
and can deploy on their servers. ( ofcourse to have a stable release we 
first and foremost would need maintainers willing to maintain the 
distribution for that time, epel could maybe be simply dropped for that ).

JBG

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Matej Cepl]

On Fri, 02 Nov 2012 20:55:38 +0000, Jóhann B. Guðmundsson wrote:
>  and one "stable" release ( valid for 2 maybe 3 years ) for
> those in the
>  community that want something they dont constantly having to upgrade to
>  and can deploy on their servers. ( ofcourse to have a stable release we
>  first and foremost would need maintainers willing to maintain the
>  distribution for that time, epel could maybe be simply dropped for that
>  ). 
That's called CentOS, and I am not sure what sense it makes it to 
recreate the same thing again ... if anything than we should concentrate 
more on EPEL, so everything required is covered.

Matěj

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Ralf Corsepius]

On 11/05/2012 01:11 AM, Matěj Cepl wrote:
>  On Fri, 02 Nov 2012 20:55:38 +0000, Jóhann B. Guðmundsson wrote:
> > and one "stable" release ( valid for 2 maybe 3 years ) for those in the
> > community that want something they dont constantly having to upgrade to
> > and can deploy on their servers. ( ofcourse to have a stable release we
> > first and foremost would need maintainers willing to maintain the
> > distribution for that time, epel could maybe be simply dropped for that
> > ).
>
>  That's called CentOS, 
Nope ... CentOS/RHEL is a different end of extremes.

7 years+ life-time, no API changes, etc.

What is lacking is a middle ground between "Fedora" and "CentOS".

Something with a life-time of "~2 years", with API increments etc.

Ralf

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Matej Cepl]

On Mon, 05 Nov 2012 13:53:37 +0100, Ralf Corsepius wrote:
> > That's called CentOS,
>  Nope ... CentOS/RHEL is a different end of extremes.
>  
>  7 years+ life-time, no API changes, etc. 
>  What is lacking is a middle ground between "Fedora" and
> "CentOS".
>  
>  Something with a life-time of "~2 years", with API increments etc. 
I am not saying that you are completely wrong, because you are not, but I 
would remind you that this thread started (at least for me) with adamw 
admission that we are not managing well even 13-month-distro, so I am 
afraid we don't have a luxury to think about ~2 years one at all.

Moreover, RHEL/CentOS is not a Debian/stable, i.e, it is not 100% frozen 
(no API changes is just for kernel and core libraries, IIRC), and there 
are (especially in desktop land) some rebases, so I found it for my 
wife's usecase pretty useful. Looking at her computer I see 
firefox-10.0.10-1.el6_3.i686.rpm and 
libreoffice-3.4.5.2-16.1.el6_3.i686 ... certainly not a bleeding edge,  
but not unusably old.

On the top of that, the past is not an indicator of the future (and I DO 
NOT say anything about the future ... NDA, not talking for my employer, 
etc.) but new releases of RHEL usually come in some ~2-3 years you 
desired, so if you are willing to reinstall with every new RHEL/CentOS 
(or with version x.1, which is quite common), then that could be your 
desired system.

Just saying,

Matěj

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Renich Bon Ciric]

I think we could, just for fun if you like, pursue making a good plan of
how the transition would be and what changes should be done.

Consider it objectively. 

What changes would have to be done the OS?
What changes in infrastructure?
What tools do we need?

This could be a good exercise. The wiki might be a nice place to do it.
How about that?

As a sysadmin, I'd love to be able to update to a certain point in time.
Like in git, you can just checkout a tag... Wouldn't it be awesome to be
able to update to a certain tag? Heh, one could even have spin tags,
hehe. 

Also, having the package manager give you warnings, pointers,
suggestions and general messages would rock. 

I'm just sayin' ;)
-- 
Renich Bon Ciric <renich(a)woralelandia.com&gt;

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Kamil Paral]

>  The entire QA team (and the entire anaconda team, for that matter)
> is
>  currently spending virtually all its time trying to help bash the new
>  anaconda into something vaguely resembling shape for a fairly
>  arbitrary
>  release deadline, so we can ship something called 'the Fedora 18
>  stable
>  release' without *completely* corpsing Jimmy Fallon-style as we do
>  the
>  release announcement ("suuuure, this is a stable release..." *giggle*
>  *giggle* *guffaw* *full-blown laughing fit*). We've barely looked at
>  the
>  desktop or the update mechanism or anything else. Stuff in Fedora
>  regresses all over the place...there all sorts of weirdness in how
>  fairly basic bits of our OS work, like updates and login and various
>  other crap. We can't really look in a mirror and say that, say,
>  Fedora
>  17 is a serious stable operating system release by any reasonable
>  definition. It's a stable Fedora release, and we all know what that
>  is.
>  We had a feature for a smooth boot process back in F12, remember?
>  where
>  everything was polished and had the same background and you didn't
>  see
>  any mode transitions? How's that working these days? It was supposed
>  to
>  be a feature of our operating system. We almost got it done for one
>  release, and have been consistently regressing it ever since. That's
>  not
>  what stable, mature operating systems do. 
Adam is telling the inconvenient truth here, and I agree. We really shouldn't pretend
that Fedora is a "stable OS". Unfortunately none of Linux distributions really
is (now talking about desktop distributions, not server ones).

But... the fact we're doing a poor job doesn't mean that some "general
users" are not using Fedora happily. They may the lucky ones (no update breakages) or
they have a power-user friend who help them from time to time. If we cut them off
completely, I'm afraid Fedora would become a niche distribution, with just a fraction
of its previous user base. I think that wouldn't be a good outcome. But I agree we
need to simplify things and decrease the currently required resources (QA, package
maintainers, releng, etc) so that the quality can go up.

My idea would be to have two releases:

== Fedora Stable ==

* A release for general users with low volume of security fixes and important bug fixes.
** Bug fixes would be pushed monthly and QA would be performed on this monthly batch of
updates.

* Released every 18 months, supported for 18+2 months (2 months to give people time to
upgrade to the next Fedora Stable).
** Why 18 months? Because for general users it is annoying to upgrade every year, but OTOH
our package maintainers wouldn't probably like supporting 2-year-old packages. 18
months is still an increase from current 12 months of support, but if we stop releasing
two parallel stable releases, we can make the support longer with the same energy spent.
** Just one stable release instead of two. Can anyone tell me a compelling argument for
having two stable releases (F16, F17) in parallel? I don't see any. The current model
probably evolved because we wanted new software fast, but upgrading every 6 months would
discourage a lot of users. Let's be honest - yes, it will contain old packages and
yes, it is intended for conservative users. For the other group we will have Fedora
Rolling.

* More reliable upgrades, although less convenient for power users. Instead of current way
of often-broken system upgrades, our upgrade tool would install a clean system, remount
/home, and try to install all GUI applications that the user had manually installed in his
previous system.
** General user wouldn't see a difference, but we could achieve much higher upgrade
success rate.
** Power users would have to manually transfer /etc changes, add custom repos, etc. But if
you need to do that only once every 18 months, it's not so bad. Also, a lot of power
users would use Fedora Rolling instead, so they would not be affected at all. Some power
users can even do unsupported yum upgrades (as many of them do now), so they won't be
affected by it either.

* There would probably have to be a stabilization period before new Fedora Stable is
released. So Branched release would exist for a short time. But it would be e.g. 3 months
every 18 months, instead of current 3 months every 6 months. Also, with Fedora Rolling
being generally working (as opposed to current Rawhide), the period could be much shorter:
1-2 months.

== Fedora Rolling ==

* Rolling release similar to Fedora Branched, but with higher quality standards. This
would target Linux power users wanting leading-edge software.
** Bodhi karma would be used for issuing updates. Because a lot of people would be using
Fedora Rolling, the quality would be higher than current Fedora Branched (where just a
tiny number of people actually run it and report problems).

* Big disruptive changes (like usrmove or sysv->systemd) would be allowed to happen
just in a concrete time slots, e.g. once a quarter.
** A special tool would be required, because not every change can be performed using just
RPM packaging.
** The changes would be heavily tested by QA beforehand.
** Further package updates would be blocked until you finish the disruptive change.

* Installer images would be released as needed. For example after a big disruptive change
happens, we would release a new installer image so that folks don't have to install
the system and then immediately go through the disruptive change.
** This process would also allow Anaconda devs to continuously work on the installer and
update it continuously with core system changes. Currently they can't work on Rawhide
because "Rawhide is just broken". Fedora Rolling would allow them that.
** Transitions Fedora Stable -> Fedora Rolling wouldn't probably be officially
supported, the same issue as for usual upgrades - too many things can go wrong.

== Appendix ==

Q: What would happen to Rawhide?
A: There might be technical reasons why we need a repository for pushing bleeding-edge
broken packages. If there is such reason, Rawhide would stay, but we would make clear it
is just a _repository_ full of bleeding-edge packages, but it is not a _release_. So it is
not intended to be run, it just a repo for fixing building problems.

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Bruno Wolff III]

On Mon, Nov 05, 2012 at 08:35:53 -0500,
   Kamil Paral <kparal(a)redhat.com&gt; wrote:
> My idea would be to have two releases:
>
> == Fedora Stable ==
>
> * A release for general users with low volume of security fixes and important bug fixes.
> ** Bug fixes would be pushed monthly and QA would be performed on this monthly batch of
> updates. 
Some packages need more than bug fix updates (unless you are taking a very 
broad view of what a bug is). We haven't done a very good job of having 
a consistent interpretation with the current update policy. Giving the 
proposal below, this will be a more important issue than it is now.

> * Released every 18 months, supported for 18+2 months (2 months to
> give people time to upgrade to the next Fedora Stable).
> ** Why 18 months? Because for general users it is annoying to upgrade every year, but OTOH
> our package maintainers wouldn't probably like supporting 2-year-old packages. 18
> months is still an increase from current 12 months of support, but if we stop releasing
> two parallel stable releases, we can make the support longer with the same energy spent.
We are going to take a marketing hit doing this.

> ** Just one stable release instead of two. Can anyone tell me a
> compelling argument for having two stable releases (F16, F17) in parallel? I don't see
> any. The current model probably evolved because we wanted new software fast, but upgrading
> every 6 months would discourage a lot of users. Let's be honest - yes, it will contain
> old packages and yes, it is intended for conservative users. For the other group we will
> have Fedora Rolling. 
We provide extra flexibility in letting users decide when they want to do 
upgrades to stay in support. It's not only letting them use a release for 
about a year if they want, but also to do the upgrade at a time where they 
can conveniently deal with any issues.

> * More reliable upgrades, although less convenient for power users.
> Instead of current way of often-broken system upgrades, our upgrade tool would install a
> clean system, remount /home, and try to install all GUI applications that the user had
> manually installed in his previous system. 
This seems to be independent of the proposal to have only one stable release. 
This tool is still not going to be able to do magic and there will be config 
things that still need to be redone. Third party repos will still be an issue.

> ** General user wouldn't see a difference, but we could achieve
> much higher upgrade success rate. 
Maybe.

> ** This process would also allow Anaconda devs to continuously work on
> the installer and update it continuously with core system changes. Currently they
> can't work on Rawhide because "Rawhide is just broken". Fedora Rolling would
> allow them that. 
I don't think that is the issue. They work in branched because they don't 
have the man power to also be working in rawhide at the same time and since 
anaconda is sensitive to the version of other packages, they want to be 
developing against what's going to be in the next release.

Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Kamil Paral]

>  >* A release for general users with low volume of security fixes
> and
>  >important bug fixes.
>  >** Bug fixes would be pushed monthly and QA would be performed on
>  >this monthly batch of updates.
>
>  Some packages need more than bug fix updates (unless you are taking a
>  very
>  broad view of what a bug is). We haven't done a very good job of
>  having
>  a consistent interpretation with the current update policy. Giving
>  the
>  proposal below, this will be a more important issue than it is now. 
You are right, some types of packages would deserve more frequent updates even if they are
not just bugfixes. Typically end-user applications like Firefox or LibreOffice, if there
is no major UI/functionality change. Fedora Stable is intended for conservative users, but
it's still Fedora, so reasonable minor changes would be fine.

>  >* Released every 18 months, supported for 18+2 months (2 months to
>  >give people time to upgrade to the next Fedora Stable).
>  >** Why 18 months? Because for general users it is annoying to
>  >upgrade every year, but OTOH our package maintainers wouldn't
>  >probably like supporting 2-year-old packages. 18 months is still an
>  >increase from current 12 months of support, but if we stop
>  >releasing two parallel stable releases, we can make the support
>  >longer with the same energy spent.
>
>  We are going to take a marketing hit doing this. 
Probably yes.

But, to tell the truth, we're getting a lot of marketing by postpoing F18 as well.
There might be a lot of other ways to do marketing.

>  >** Just one stable release instead of two. Can anyone tell me a
>  >compelling argument for having two stable releases (F16, F17) in
>  >parallel? I don't see any. The current model probably evolved
>  >because we wanted new software fast, but upgrading every 6 months
>  >would discourage a lot of users. Let's be honest - yes, it will
>  >contain old packages and yes, it is intended for conservative
>  >users. For the other group we will have Fedora Rolling.
>
>  We provide extra flexibility in letting users decide when they want
>  to do
>  upgrades to stay in support. It's not only letting them use a release
>  for
>  about a year if they want, but also to do the upgrade at a time where
>  they
>  can conveniently deal with any issues. 
That's a good argument. Currently they have 7 months to do the upgrade. With my
proposal, they have 2 months. Unless they want to run a system without security patches
for some time. So maybe we could extend the time we provide security patches?

>  >* More reliable upgrades, although less convenient for power users.
>  >Instead of current way of often-broken system upgrades, our upgrade
>  >tool would install a clean system, remount /home, and try to
>  >install all GUI applications that the user had manually installed
>  >in his previous system.
>
>  This seems to be independent of the proposal to have only one stable
>  release. 
Right.

>  This tool is still not going to be able to do magic and there will
> be
>  config
>  things that still need to be redone. Third party repos will still be
>  an issue. 
It's a clean installation, I don't think it needs any magic. Also third-party
repos are not a problem, we just ignore them and they won't influence the new system.
People will add them manually again once in 18 months.

>  >** This process would also allow Anaconda devs to continuously
> work
>  >on the installer and update it continuously with core system
>  >changes. Currently they can't work on Rawhide because "Rawhide is
>  >just broken". Fedora Rolling would allow them that.
>
>  I don't think that is the issue. They work in branched because they
>  don't
>  have the man power to also be working in rawhide at the same time and
>  since
>  anaconda is sensitive to the version of other packages, they want to
>  be
>  developing against what's going to be in the next release.
>  
Yes, but this would reduce the surprise moment when Fedora is being Branched and Anaconda
team discovers that 1337 things changed in Rawhide since the last stable release.

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Ian Malone]

On 1 November 2012 17:33, Michael Cronenworth <mike(a)cchtml.com&gt; wrote:
>  Adam Williamson wrote:
> > I didn't want to throw this grenade into the debate, but now someone
> > else has, I'll just note that I was in favour of this before and I'm
> > still in favour of it now. :) Rolling release is a model that makes
> > clear sense for a distribution with the goals that Fedora has.
>
>  I've wanted to write up a blog post about my plan for a rolling release,
>  but I'll post a snip-it here.
>
>  Fedora Rawhide - stays as is... it is a rolling release
>
>  Fedora Feature - think of it as F18 beta right now
>
>  Fedora Stable - think of it as F16/F17 right now
>
>  People choose the branch level at install time. Of course, like now,
>  people can override this in the future with a change of fedora-release
>  or yum --releasever. However, per-package updates from another branch
>  level might not be something everyone can agree on how to handle, so it
>  might be wise to limit support of it at first.
>
>  Workflow:
>  A shiny new feature is introduced in Rawhide. Things go boom. Not many
>  people are hurt by this. Once it has been given a few band-aids the
>  feature could be submitted to Fedora Feature. After some hardening and
>  polishing the feature could finally be pushed to Fedora Stable.
>  
How does this work with things like Anaconda? In a rolling model
(assuming you can do other major upgrades without reinstalling, if not
there's less point anyway), people aren't going to be reinstalling so
it could easily trickle through to stable before getting serious use.

How does it work with major changes like UsrMove? It might never have
been done...

-- 
imalone
http://ibmalone.blogspot.co.uk

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Michael Cronenworth]

Ian Malone wrote:
>  How does this work with things like Anaconda? In a rolling model
>  (assuming you can do other major upgrades without reinstalling, if not
>  there's less point anyway), people aren't going to be reinstalling so
>  it could easily trickle through to stable before getting serious use. 
Installer images could remain at a 6 month interval, or change to a 12
month interval, or be spun after a major feature reaches one of the
branch levels. There is more flexibility in a rolling release model to
ship a installer image.

The QA group would retain their duties in testing as they do so today.
In fact, it might make QA a stronger group as today they can only focus
on Rawhide/Branched releases. Very little QA time is spent on N+1 or
even N releases. Lacking a "version" tag doesn't mean things will go
untouched. The only way features would advance down a branch level is if
they received approval from FESCo/QA.

>  
>  How does it work with major changes like UsrMove? It might never have
>  been done... 
How does it [something similar] work with Gentoo or Debian? :)

In the case of major file system changes, and not just package updates,
a distribution upgrade tool (fedup?) would be required. Yum would need
to gain the smarts to see "distribution updates" as well as regular
packages. Such a feature existed on my Nokia N900 phone (Debian) to
upgrade it to new major releases without reflashing or command-line usage.

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Dennis Gilmore]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El Wed, 31 Oct 2012 10:59:54 -0700
Jesse Keating <jkeating(a)j2solutions.net&gt; escribió:
>  On 10/31/2012 09:56 AM, Toshio Kuratomi wrote:
>  > * Jesse Keating, Jeremy Katz, and others who helped shape the
>  > current policy and theory of our release schedule felt that the 6
>  > month release cycle was fine but that certain features were going
>  > to take longer to develop. Those would need to be developed and not
>  > enter into Fedora until they were close enough that they could be
>  > completed during that cycle.
>  >    - No matter what we do to try and increase the development cycle
>  > within a release, there's always going to be issues that take
>  > longer than the release that we need to deal with.  Perhaps, we
>  > just need to be better about making people follow this model.
>  
>  I'm not entirely sure what I felt then, but I'm certainly open to a 
>  longer release cycle.  In fact I'm very much in favor of one, one
>  that puts more time between "feature complete" and the actual alpha
>  release. All too often we see features crash land right at the
>  deadline, and any software that has to integrate across a lot of
>  pieces (like anaconda) gets stuck trying to account for all these
>  changes in a very limited time frame, only to be hindered quickly by
>  a freeze process.
>  
I really do not object to a longer release cycle.  I am also open to
making feature freeze being 4-6 weeks before Alpha change freeze. The
risk we run is people land new features anyway. but we run that today.
We always have a run of things late. People need to land changes
earlier  the bigger the change the earlier it needs to land.  Maybe it
wont be a popular idea but having feature freeze at previous release
time is needed. What I am thinking is:

Branch as we do, which opens up development for next release same as
we do today, so in the current cycle when we branched off f18, f19
features needed to start landing so all that would be taken for f18 is
bug fix and integration fixes.  when we release f18 we hit F19 feature
freeze.  that then will give us close to 3 months to do most of the
integration fixing and stabalising.  we then rinse and repeat.  It
would mean that we need to start making rawhide installable again,
though thats something that seems to be inevitable, we could do weekly
snapshot test composes. I am willing from the releng side to do the
work needed.


>  I think we need to give developers more time for feature integration
>
>  after the feature freeze.
>  
I am all for giving developers more time to integrate with other
features.


Dennis
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
>
> iEYEARECAAYFAlCXRykACgkQkSxm47BaWfdGrgCgh+nK7OKFhPLSu+VQV9XXTyYb
> j4kAniud8lfIuGEouw3Ib3yHy4gc8+bK
> =Zu8Z
> -----END PGP SIGNATURE-----
>

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[drago01]

On Mon, Nov 5, 2012 at 5:57 AM, Dennis Gilmore <dennis(a)ausil.us&gt; wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  El Wed, 31 Oct 2012 10:59:54 -0700
>  Jesse Keating <jkeating(a)j2solutions.net&gt; escribió:
> > On 10/31/2012 09:56 AM, Toshio Kuratomi wrote:
> > > * Jesse Keating, Jeremy Katz, and others who helped shape the
> > > current policy and theory of our release schedule felt that the 6
> > > month release cycle was fine but that certain features were going
> > > to take longer to develop. Those would need to be developed and not
> > > enter into Fedora until they were close enough that they could be
> > > completed during that cycle.
> > >    - No matter what we do to try and increase the development cycle
> > > within a release, there's always going to be issues that take
> > > longer than the release that we need to deal with.  Perhaps, we
> > > just need to be better about making people follow this model.
> >
> > I'm not entirely sure what I felt then, but I'm certainly open to a
> > longer release cycle.  In fact I'm very much in favor of one, one
> > that puts more time between "feature complete" and the actual alpha
> > release. All too often we see features crash land right at the
> > deadline, and any software that has to integrate across a lot of
> > pieces (like anaconda) gets stuck trying to account for all these
> > changes in a very limited time frame, only to be hindered quickly by
> > a freeze process.
>
>  I really do not object to a longer release cycle.  I am also open to
>  making feature freeze being 4-6 weeks before Alpha change freeze. The
>  risk we run is people land new features anyway. but we run that today.
>  We always have a run of things late. People need to land changes
>  earlier  the bigger the change the earlier it needs to land.  Maybe it
>  wont be a popular idea but having feature freeze at previous release
>  time is needed. What I am thinking is:
>
>  Branch as we do, which opens up development for next release same as
>  we do today, so in the current cycle when we branched off f18, f19
>  features needed to start landing so all that would be taken for f18 is
>  bug fix and integration fixes.  when we release f18 we hit F19 feature
>  freeze. 
That does not work because we do not have unlimited resources ... you
can't expect people to work on F19 features at the same time while
they are trying to get F18 ready for release.
Honestly I don't think that the current issues have anything to do
with the schedule but more with the way we handled the anaconda
feature. We should just fix that and not try to make random changes
all over the place.

Basically there should not be any "this cannot be reverted" (there is
no such thing really) features. If it is evident before the feature
freeze that a given feature would not be ready in time we have to punt
it to the next release PERIOD.

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Aleksandar Kurtakov]

----- Original Message -----
>  From: "drago01" <drago01(a)gmail.com&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Sent: Monday, November 5, 2012 9:39:54 AM
>  Subject: Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how	to install
> into a LVM partitions (or
>  RAID))
>  
>  On Mon, Nov 5, 2012 at 5:57 AM, Dennis Gilmore <dennis(a)ausil.us&gt;
>  wrote:
>  > -----BEGIN PGP SIGNED MESSAGE-----
>  > Hash: SHA1
>  >
>  > El Wed, 31 Oct 2012 10:59:54 -0700
>  > Jesse Keating <jkeating(a)j2solutions.net&gt; escribió:
>  >> On 10/31/2012 09:56 AM, Toshio Kuratomi wrote:
>  >> > * Jesse Keating, Jeremy Katz, and others who helped shape the
>  >> > current policy and theory of our release schedule felt that the
>  >> > 6
>  >> > month release cycle was fine but that certain features were
>  >> > going
>  >> > to take longer to develop. Those would need to be developed and
>  >> > not
>  >> > enter into Fedora until they were close enough that they could
>  >> > be
>  >> > completed during that cycle.
>  >> >    - No matter what we do to try and increase the development
>  >> >    cycle
>  >> > within a release, there's always going to be issues that take
>  >> > longer than the release that we need to deal with.  Perhaps, we
>  >> > just need to be better about making people follow this model.
>  >>
>  >> I'm not entirely sure what I felt then, but I'm certainly open to
>  >> a
>  >> longer release cycle.  In fact I'm very much in favor of one, one
>  >> that puts more time between "feature complete" and the actual
>  >> alpha
>  >> release. All too often we see features crash land right at the
>  >> deadline, and any software that has to integrate across a lot of
>  >> pieces (like anaconda) gets stuck trying to account for all these
>  >> changes in a very limited time frame, only to be hindered quickly
>  >> by
>  >> a freeze process.
>  >
>  > I really do not object to a longer release cycle.  I am also open
>  > to
>  > making feature freeze being 4-6 weeks before Alpha change freeze.
>  > The
>  > risk we run is people land new features anyway. but we run that
>  > today.
>  > We always have a run of things late. People need to land changes
>  > earlier  the bigger the change the earlier it needs to land.  Maybe
>  > it
>  > wont be a popular idea but having feature freeze at previous
>  > release
>  > time is needed. What I am thinking is:
>  >
>  > Branch as we do, which opens up development for next release same
>  > as
>  > we do today, so in the current cycle when we branched off f18, f19
>  > features needed to start landing so all that would be taken for f18
>  > is
>  > bug fix and integration fixes.  when we release f18 we hit F19
>  > feature
>  > freeze.
>  
>  That does not work because we do not have unlimited resources ... you
>  can't expect people to work on F19 features at the same time while
>  they are trying to get F18 ready for release.
>  Honestly I don't think that the current issues have anything to do
>  with the schedule but more with the way we handled the anaconda
>  feature. We should just fix that and not try to make random changes
>  all over the place.
>  
>  Basically there should not be any "this cannot be reverted" (there is
>  no such thing really) features. If it is evident before the feature
>  freeze that a given feature would not be ready in time we have to
>  punt
>  it to the next release PERIOD. 
Looks like this issue comes to every project(pretty similar thing happened in Eclipse for
4.x). What happens if Anaconda devs say they can no long maintain the old version and they
will spend all their time on the new one? Will there some magic happen and someone else
will step in to do the changes in anaconda for the new dracut (mentioned in the thread)?
Or we will revert dracut and systemd and etc. to their f17 version making no point in even
having new release maybe?
I agree we fail but sometimes you can not just revert and the better idea looks like when
some such low level changes happen it is better to just accept it and make the release a
bit longer from the beginning.

Alexander Kurtakov

>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Panu Matilainen]

On 11/05/2012 09:39 AM, drago01 wrote:
>  On Mon, Nov 5, 2012 at 5:57 AM, Dennis Gilmore
> <dennis(a)ausil.us&gt; wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > El Wed, 31 Oct 2012 10:59:54 -0700
> > Jesse Keating <jkeating(a)j2solutions.net&gt; escribió:
> >> On 10/31/2012 09:56 AM, Toshio Kuratomi wrote:
> >>> * Jesse Keating, Jeremy Katz, and others who helped shape the
> >>> current policy and theory of our release schedule felt that the 6
> >>> month release cycle was fine but that certain features were going
> >>> to take longer to develop. Those would need to be developed and not
> >>> enter into Fedora until they were close enough that they could be
> >>> completed during that cycle.
> >>>     - No matter what we do to try and increase the development cycle
> >>> within a release, there's always going to be issues that take
> >>> longer than the release that we need to deal with.  Perhaps, we
> >>> just need to be better about making people follow this model.
> >>
> >> I'm not entirely sure what I felt then, but I'm certainly open to a
> >> longer release cycle.  In fact I'm very much in favor of one, one
> >> that puts more time between "feature complete" and the actual alpha
> >> release. All too often we see features crash land right at the
> >> deadline, and any software that has to integrate across a lot of
> >> pieces (like anaconda) gets stuck trying to account for all these
> >> changes in a very limited time frame, only to be hindered quickly by
> >> a freeze process.
> >
> > I really do not object to a longer release cycle.  I am also open to
> > making feature freeze being 4-6 weeks before Alpha change freeze. The
> > risk we run is people land new features anyway. but we run that today.
> > We always have a run of things late. People need to land changes
> > earlier  the bigger the change the earlier it needs to land.  Maybe it
> > wont be a popular idea but having feature freeze at previous release
> > time is needed. What I am thinking is:
> >
> > Branch as we do, which opens up development for next release same as
> > we do today, so in the current cycle when we branched off f18, f19
> > features needed to start landing so all that would be taken for f18 is
> > bug fix and integration fixes.  when we release f18 we hit F19 feature
> > freeze.
>
>  That does not work because we do not have unlimited resources ... you
>  can't expect people to work on F19 features at the same time while
>  they are trying to get F18 ready for release. 
If/when the "real work" behind a feature has been done early enough, 
getting from Fedora alpha to final consists of just a few bugfixes that 
can only be found with sufficiently large test-audience. That's very 
different from the way things some things land: known very incomplete 
work submitted at very last minute, followed by a mad scramble to try 
and scrape it to somehow acceptable state in time. It's avoidable by 
simply resisting the urge to slip stuff in on the last minute, the 
release cycle is short enough that world does not end if you postpone 
something to the next release.

>  Honestly I don't think that the current issues have anything to
> do
>  with the schedule but more with the way we handled the anaconda
>  feature. We should just fix that and not try to make random changes
>  all over the place.
>
>  Basically there should not be any "this cannot be reverted" (there is
>  no such thing really) features. If it is evident before the feature
>  freeze that a given feature would not be ready in time we have to punt
>  it to the next release PERIOD. 
No disagreement there - features with no feasible contingency plan 
should be treated very cautiously and if accepted anyway, should have 
stricter completeness-requirements and much earlier deadlines than 
easily reversible things.

	- Panu -

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Martin Sivak]

Hi,

>  If/when the "real work" behind a feature has been done
> early enough,
>  getting from Fedora alpha to final consists of just a few bugfixes 
Ah well.. only if everybody else did this so all the dependencies are stable.
In which case you just moved the development freeze to earlier date. No improvement..

>  > Basically there should not be any "this cannot be
> reverted" (there
>  > is
>  > no such thing really) features. If it is evident before the feature
>  > freeze that a given feature would not be ready in time we have to
>  > punt
>  > it to the next release PERIOD. 
Then there will be no possibility of major rewrites ever. Because some
changes just take more than few months to execute and supporting a branch
with very old (anaconda's GUI first commit in git is from 1999) codebase
takes a lot of manpower.

And to use drago's words: We do not have unlimited resources.

When Gnome decides they are not fixing bugs for Gnome2 and put all resources
to fixing Gnome3, you can wait, because most apps still depend on the mostly stable
Gnome2 anyway and the bugs are not show stoppers, merely annoyances.

When we do this in anaconda, you can't just use the older release, because
other components are changing underneath us and the old release will break.

So you will write bugs and RFEs for us to fix in the old branch so you meet your
release deadline and mostly nobody will be testing the new branch.
One release later at the alpha time.. we will get into the same issue of not being ready.

We will take the heat whatever model we choose.

So we have chosen. When this is done, we will have UI which has sane
API and is separated from the other internal components and that will allow
us to maintain the installer and firstboot in much better and easier way.

Martin

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Dennis Gilmore]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El Mon, 5 Nov 2012 08:39:54 +0100
drago01 <drago01(a)gmail.com&gt; escribió:
>  On Mon, Nov 5, 2012 at 5:57 AM, Dennis Gilmore
> <dennis(a)ausil.us&gt;
>  wrote:
>  > -----BEGIN PGP SIGNED MESSAGE-----
>  > Hash: SHA1
>  >
>  > El Wed, 31 Oct 2012 10:59:54 -0700
>  > Jesse Keating <jkeating(a)j2solutions.net&gt; escribió:
>  >> On 10/31/2012 09:56 AM, Toshio Kuratomi wrote:
>  >> > * Jesse Keating, Jeremy Katz, and others who helped shape the
>  >> > current policy and theory of our release schedule felt that the 6
>  >> > month release cycle was fine but that certain features were going
>  >> > to take longer to develop. Those would need to be developed and
>  >> > not enter into Fedora until they were close enough that they
>  >> > could be completed during that cycle.
>  >> >    - No matter what we do to try and increase the development
>  >> > cycle within a release, there's always going to be issues that
>  >> > take longer than the release that we need to deal with.
>  >> > Perhaps, we just need to be better about making people follow
>  >> > this model.
>  >>
>  >> I'm not entirely sure what I felt then, but I'm certainly open to a
>  >> longer release cycle.  In fact I'm very much in favor of one, one
>  >> that puts more time between "feature complete" and the actual alpha
>  >> release. All too often we see features crash land right at the
>  >> deadline, and any software that has to integrate across a lot of
>  >> pieces (like anaconda) gets stuck trying to account for all these
>  >> changes in a very limited time frame, only to be hindered quickly
>  >> by a freeze process.
>  >
>  > I really do not object to a longer release cycle.  I am also open to
>  > making feature freeze being 4-6 weeks before Alpha change freeze.
>  > The risk we run is people land new features anyway. but we run that
>  > today. We always have a run of things late. People need to land
>  > changes earlier  the bigger the change the earlier it needs to
>  > land.  Maybe it wont be a popular idea but having feature freeze at
>  > previous release time is needed. What I am thinking is:
>  >
>  > Branch as we do, which opens up development for next release same as
>  > we do today, so in the current cycle when we branched off f18, f19
>  > features needed to start landing so all that would be taken for f18
>  > is bug fix and integration fixes.  when we release f18 we hit F19
>  > feature freeze.
>  
>  That does not work because we do not have unlimited resources ... you
>  can't expect people to work on F19 features at the same time while
>  they are trying to get F18 ready for release.
>  Honestly I don't think that the current issues have anything to do
>  with the schedule but more with the way we handled the anaconda
>  feature. We should just fix that and not try to make random changes
>  all over the place.
>  
When you doing the major work earlier the work to get the polish and
fix the unforeseen issues is smaller, i don't envisage that it needs
more resources just a change in focus and how we do things.

>  
>  Basically there should not be any "this cannot be reverted" (there is
>  no such thing really) features. If it is evident before the feature
>  freeze that a given feature would not be ready in time we have to punt
>  it to the next release PERIOD.
>  
realistically most features cant be reverted easily.  and people will
do and say anything to not have them reverted. often the work to punt
the brokenness is the same as to fix it. the sooner we freeze features
the more time we have to fix the fallout. 

Dennis
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
>
> iEYEARECAAYFAlCYm7QACgkQkSxm47BaWfftyQCguB9b7tonxviCmXo957I2ZCY3
> gZcAn0DoZ/bnNmJdyURL0It69dbUSBp6
> =V+xv
> -----END PGP SIGNATURE-----
>

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Kevin Kofler]

Adam Williamson wrote:
>  I'd recommend asking dcantrell, as he has some good points on
> this
>  topic. I broadly agree with him that it might well be more or less
>  impossible to smoothly handle a major rewrite of anaconda in our current
>  development process. CCing to make sure he sees this. 
There's only one sane conclusion to draw from that: There MUST NOT be a 
major rewrite of Anaconda, EVER. That it was allowed to happen for F18 was a 
major mistake.

Anaconda is the least tested component in Fedora (most people test it at 
most once every 6 months) and arguably the most critical (because it is 
required to get Fedora up and running at all). The less it changes, the 
better!

        Kevin Kofler

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Adam Williamson]

On Thu, 2012-11-01 at 03:09 +0100, Kevin Kofler wrote:
>  Adam Williamson wrote:
>  > I'd recommend asking dcantrell, as he has some good points on this
>  > topic. I broadly agree with him that it might well be more or less
>  > impossible to smoothly handle a major rewrite of anaconda in our current
>  > development process. CCing to make sure he sees this.
>  
>  There's only one sane conclusion to draw from that: There MUST NOT be a 
>  major rewrite of Anaconda, EVER. That it was allowed to happen for F18 was a 
>  major mistake.
>  
>  Anaconda is the least tested component in Fedora (most people test it at 
>  most once every 6 months)  
Offsetting this is the fact that the QA team tests it massively,
massively more than we test any other component.

anaconda is certainly far more heavily tested than any niche package in
the distro - the scientific tools, obscure desktops, apps not many
people use etc. It's clearly absurd to say it's the least tested
component.

>  and arguably the most critical (because it is 
>  required to get Fedora up and running at all). The less it changes, the 
>  better! 
This is the path to stagnation: it's old code, but we're too scared to
change it. The older it gets, the more scared we get. And then you wake
up and it's 2012 and your business still runs on a System/38 mainframe.
That's not what Fedora is supposed to be about.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[David Cantrell]

On Wed, Oct 31, 2012 at 07:17:30PM -0700, Adam Williamson wrote:
>  On Thu, 2012-11-01 at 03:09 +0100, Kevin Kofler wrote:
>  > Adam Williamson wrote:
>  > > I'd recommend asking dcantrell, as he has some good points on this
>  > > topic. I broadly agree with him that it might well be more or less
>  > > impossible to smoothly handle a major rewrite of anaconda in our current
>  > > development process. CCing to make sure he sees this.
>  > 
>  > There's only one sane conclusion to draw from that: There MUST NOT be a 
>  > major rewrite of Anaconda, EVER. That it was allowed to happen for F18 was a 
>  > major mistake.
>  > 
>  > Anaconda is the least tested component in Fedora (most people test it at 
>  > most once every 6 months) 
>  
>  Offsetting this is the fact that the QA team tests it massively,
>  massively more than we test any other component.
>  
>  anaconda is certainly far more heavily tested than any niche package in
>  the distro - the scientific tools, obscure desktops, apps not many
>  people use etc. It's clearly absurd to say it's the least tested
>  component.
>  
>  > and arguably the most critical (because it is 
>  > required to get Fedora up and running at all). The less it changes, the 
>  > better!
>  
>  This is the path to stagnation: it's old code, but we're too scared to
>  change it. The older it gets, the more scared we get. And then you wake
>  up and it's 2012 and your business still runs on a System/38 mainframe.
>  That's not what Fedora is supposed to be about. 
Just so we're all on the same page, the System/38 was not a mainframe in the
sense that the s390 and s390x architectures are mainframes.  It was a
descendant of the System/360 and the ancestor to the AS/400.

And if your business *is* running on an s390x mainframe in 2012 and you
haven't tried Fedora on it, check out the secondary arch project:

    http://fedoraproject.org/wiki/Architectures/s390x

-- 
David Cantrell <dcantrell(a)redhat.com&gt;
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Allan Day]

Hi all,

It's important to recognise the negative effects of delays to the
release. Upstream projects are reliant on the Fedora release process to get
updates out to their users. GNOME released version 3.6 on 26 September. It
was a big release and contained major improvements to our user experience.
We did a marketing push to promote it. We want our users to be using that
upgrade as soon as possible: 3.4 simply isn't as good.

It is also in Fedora's interests to ensure that the user experience is as
good as possible, of course. A one month delay is a whole month in which
Fedora users could have been experiencing something better.

Finally, there are many people who are impatient to be using the latest
GNOME release (and other upstream releases, I guess). Right now you can get
it on Ubuntu or on Arch - people might just choose to use a different
distro if they want the latest and greatest, or if they are frustrated by
the constant delays.

Allan Day

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Matthew Garrett]

On Thu, Nov 01, 2012 at 02:25:39PM +0000, Allan Day wrote:

>  It's important to recognise the negative effects of delays to
> the
>  release. Upstream projects are reliant on the Fedora release process to get
>  updates out to their users. GNOME released version 3.6 on 26 September. It
>  was a big release and contained major improvements to our user experience.
>  We did a marketing push to promote it. We want our users to be using that
>  upgrade as soon as possible: 3.4 simply isn't as good. 
If we had something we could ship, we'd ship it. We don't. That's 
unfortunate, but talking about how undesirable release slips are does 
nothing to help improve that situation. We know they're undesirable, but 
so far nobody has proposed a workable solution that actually makes them 
less likely to happen in future without massively compromising other 
parts of the project.

-- 
Matthew Garrett | mjg59(a)srcf.ucam.org

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Martin Langhoff]

On Thu, Nov 1, 2012 at 10:25 AM, Allan Day <allanpday(a)gmail.com&gt; wrote:
>  It's important to recognise the negative effects of delays to the
> release. 
OLPC is downstream of F18, and planning to ship an "OLPC OS" version
13.1.0 first week of December 2012 (approx); which will be based on
F18.

We are not affected by Anaconda issues, as our OS is a pre-installed
image, but continued churn does hit us hard.

We control this somewhat by freezing our view of Fedora's repos. Most
of our packages are in Fedora (with exceptions like kernel and BIOS)
-- where we maintain/comaintain quite a few components (Sugar Desktop,
etc).

OLPC development team is watching closely any schedule changes affecting Fedora.

cheers,


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

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jóhann B. Guðmundsson]

On 11/01/2012 02:09 AM, Kevin Kofler wrote:
>  Anaconda is the least tested component in Fedora (most people test it
> at
>  most once every 6 months) and arguably the most critical (because it is
>  required to get Fedora up and running at all). The less it changes, the
>  better! 
This is not right in fact we probably test the installer way more then 
any other component.
And quite frankly I feel we are dedicating way to much time testing it 
each release cycle
( This release cycle being an exception of course due to the rewrite but 
generally we should not have to spend so much time testing Anaconda each 
release cycle )

JBG

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[drago01]

On Tue, Oct 30, 2012 at 7:08 PM, Tom Lane <tgl(a)redhat.com&gt; wrote:
>  It's time somebody asked this, so ...
>
>  Adam Williamson <awilliam(a)redhat.com&gt; writes:
> > What is missing from TC6 and will be added in the next build is the
> > ability to choose to reformat the partition. If you do not want to
> > reformat it, this is not a problem for you.
>
>  It appears to me that anaconda is months away from being shippable.
>  It's still got major features that are incomplete (one example above,
>  but there are more), and I don't seem to be able to do anything at all
>  with it without hitting serious bugs.
>
>  How is it that we're even considering shipping this version for F18?
>  For any other package, we'd be telling the maintainer to hold off
>  till F19.  The rest of us don't get to be doing major feature
>  development post-beta-freeze. 
https://fedorahosted.org/fesco/ticket/944

FESCo dismissed this as "insane" even though it was the only
reasonable thing to do.

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Marcela Mašláňová]

On 10/30/2012 07:53 PM, drago01 wrote:
>  On Tue, Oct 30, 2012 at 7:08 PM, Tom Lane <tgl(a)redhat.com&gt;
> wrote:
> > It's time somebody asked this, so ...
> >
> > Adam Williamson <awilliam(a)redhat.com&gt; writes:
> >> What is missing from TC6 and will be added in the next build is the
> >> ability to choose to reformat the partition. If you do not want to
> >> reformat it, this is not a problem for you.
> >
> > It appears to me that anaconda is months away from being shippable.
> > It's still got major features that are incomplete (one example above,
> > but there are more), and I don't seem to be able to do anything at all
> > with it without hitting serious bugs.
> >
> > How is it that we're even considering shipping this version for F18?
> > For any other package, we'd be telling the maintainer to hold off
> > till F19.  The rest of us don't get to be doing major feature
> > development post-beta-freeze.
>
>  https://fedorahosted.org/fesco/ticket/944
>
>  FESCo dismissed this as "insane" even though it was the only
>  reasonable thing to do.
>  
You replied to yourself by the ticket. Maybe you studied the anaconda 
code and you are able to do qualified estimation of time to fix all 
bugs. I'm not, so I've taken information from anaconda team.

The non existing contingency plan was wrong thing to do and it must be 
taken more seriously for features since F-19.

Marcela

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Toshio Kuratomi]

On Wed, Oct 31, 2012 at 01:25:36PM +0100, Marcela Mašláňová wrote:
>  On 10/30/2012 07:53 PM, drago01 wrote:
>  >On Tue, Oct 30, 2012 at 7:08 PM, Tom Lane <tgl(a)redhat.com&gt; wrote:
>  >>It's time somebody asked this, so ...
>  >>
>  >>Adam Williamson <awilliam(a)redhat.com&gt; writes:
>  >>>What is missing from TC6 and will be added in the next build is the
>  >>>ability to choose to reformat the partition. If you do not want to
>  >>>reformat it, this is not a problem for you.
>  >>
>  >>It appears to me that anaconda is months away from being shippable.
>  >>It's still got major features that are incomplete (one example above,
>  >>but there are more), and I don't seem to be able to do anything at all
>  >>with it without hitting serious bugs.
>  >>
>  >>How is it that we're even considering shipping this version for F18?
>  >>For any other package, we'd be telling the maintainer to hold off
>  >>till F19.  The rest of us don't get to be doing major feature
>  >>development post-beta-freeze.
>  >
>  >https://fedorahosted.org/fesco/ticket/944
>  >
>  >FESCo dismissed this as "insane" even though it was the only
>  >reasonable thing to do.
>  >
>  
>  You replied to yourself by the ticket. Maybe you studied the anaconda
>  code and you are able to do qualified estimation of time to fix all
>  bugs. I'm not, so I've taken information from anaconda team.
>  
>  The non existing contingency plan was wrong thing to do and it must
>  be taken more seriously for features since F-19.
>   
One way to deal with non-esitent contingency plans would be that they must
be feature complete and testable before merging.  (instead of at Alpha).
There would need to be additional policy about when they needed to be
merged.  I could see, for instance, that they'd have to be merged when
rawhide branched as that is the time when development of the new release
starts and allows people to rapidly say, ready: everyone else adjust your
code or not-ready: pull that change out and recognize how that's going to
hobble changes to anything else for the cycle.

-Toshio

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Pierre-Yves Chibon]

On Wed, 2012-10-31 at 08:15 -0700, Toshio Kuratomi wrote:
>  On Wed, Oct 31, 2012 at 01:25:36PM +0100, Marcela Mašláňová wrote:
>  > The non existing contingency plan was wrong thing to do and it must
>  > be taken more seriously for features since F-19.
>  > 
>  One way to deal with non-esitent contingency plans would be that they must
>  be feature complete and testable before merging.  (instead of at Alpha).
>  There would need to be additional policy about when they needed to be
>  merged.  I could see, for instance, that they'd have to be merged when
>  rawhide branched as that is the time when development of the new release
>  starts and allows people to rapidly say, ready: everyone else adjust your
>  code or not-ready: pull that change out and recognize how that's going to
>  hobble changes to anything else for the cycle. 
We could push as in, features are no longer targeted for a given release
(as in the wiki page does not mention the Fedora release in which this
feature will appear). They are developed on their way (allowing long
time planning) and when ready merge into rawhide right after the
branching, this would be when a feature is tagged for the release.
Benefits, feature can be tested in rawhide right after the branching,
more time to discuss the feature as they are not proposed for a given
release but in a generic way and hopefully enough time between it is
merged into rawhide and the branching for the next release to be able to
revert the feature if desired.

Pierre

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jóhann B. Guðmundsson]

On 10/30/2012 06:08 PM, Tom Lane wrote:
>  How is it that we're even considering shipping this version for
> F18?
>  For any other package, we'd be telling the maintainer to hold off
>  till F19.  The rest of us don't get to be doing major feature
>  development post-beta-freeze. 
That's what I have been asking this whole time and no one from FESCO 
bothered to answer.

What's the rush shipping it now? Why not delay-it until F19 when it has 
further stabilized?

The distribution upgrade tool just got submitted for reviewed yesterday 
and we are in FREEZE!

And just to be sure that everything breaks FESCO accepts [3] feature 
happening in the same development cycle ( wtf ).

So in QA not only have we been dealing with the newUI but also the fact 
once the installer actually works it might not install the correct bits 
for due to the packaging rework <sigh>

JBG

1. https://bugzilla.redhat.com/show_bug.cgi?id=871604
2 .https://bugzilla.redhat.com/show_bug.cgi?id=871605
3. http://fedoraproject.org/wiki/Features/ReworkPackageGroups

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Richard W.M. Jones]

On Wed, Oct 31, 2012 at 09:50:51AM +0000, "Jóhann B. Guðmundsson" wrote:
>  On 10/30/2012 06:08 PM, Tom Lane wrote:
>  >How is it that we're even considering shipping this version for F18?
>  >For any other package, we'd be telling the maintainer to hold off
>  >till F19.  The rest of us don't get to be doing major feature
>  >development post-beta-freeze.
>  
>  That's what I have been asking this whole time and no one from FESCO
>  bothered to answer.
>  
>  What's the rush shipping it now? Why not delay-it until F19 when it
>  has further stabilized? 
One might also ask, what's the rush getting F18 out?  Why not
just declare that as a one-off it's going to be a 9 month cycle.

(libvirt/libguestfs/selinux integration could certainly use that time ...)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top

Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Jóhann B. Guðmundsson]

On 10/31/2012 09:57 AM, Richard W.M. Jones wrote:
>  On Wed, Oct 31, 2012 at 09:50:51AM +0000, "Jóhann B.
> Guðmundsson" wrote:
> > On 10/30/2012 06:08 PM, Tom Lane wrote:
> >> How is it that we're even considering shipping this version for F18?
> >> For any other package, we'd be telling the maintainer to hold off
> >> till F19.  The rest of us don't get to be doing major feature
> >> development post-beta-freeze.
> > That's what I have been asking this whole time and no one from FESCO
> > bothered to answer.
> >
> > What's the rush shipping it now? Why not delay-it until F19 when it
> > has further stabilized?
>  One might also ask, what's the rush getting F18 out?  Why not
>  just declare that as a one-off it's going to be a 9 month cycle.
>
>  (libvirt/libguestfs/selinux integration could certainly use that time ...) 
Given the current state of F18 I agree let's lengthen this release cycle 
up to 9 months and arguably we should lengthen the whole development 
cycle to 9 months from now on.

JBG

Maybe highlight release-slipping features? (was: Re: Anaconda is totally trashing the F18 schedule)

[Scott Schmit]

On Wed, Oct 31, 2012 at 09:59:55AM +0000, "Jóhann B. Guðmundsson" wrote:
>  Given the current state of F18 I agree let's lengthen this
> release
>  cycle up to 9 months and arguably we should lengthen the whole 
                    
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  development cycle to 9 months from now on. 
 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I'm not sure that helps -- then people just get more ambitious with
their features and then what? Slow the release cycle down more?

Remember, the whole point of regular, strict-timed releases is to keep
things moving.

What it appears we have is a development process where all features are
optional in a given release except for Anaconda and any other feature
accepted with no executable contingency plan (and there's usually at
least one each release).

I'm not certain that that's an entirely *bad* thing.  Some Features are
necessarily big & disruptive and that always brings with it a risk of
unexpected problems--shying away from those changes means you never do
anything significant.

IIRC, a Feature being big and impossible to revert isn't typically a
surprise to at least one person on FESCo--I think more than once I've
heard someone say "well, we knew that wasn't a contingency plan we could
actually execute, but we had to do this."  But they may be (and
sometimes have been) a surprise to others.

Maybe we need to highlight those features that don't have a realistic
contingency plan (the work to revert and re-test is greater than the
work to complete) and call them out as "Critical Features" that we are
committing to slipping a release for if they don't work well, rather
than to revert them.

I'm not terribly familiar with the release criteria, so this is
something of a stab, but I suspect these Features from recent versions
would be considered critical:
* F15: Gnome3
* F15: GCC46
* F15: systemd
* F16: Gnome3.2
* F16: grub2
* F17: GCC47
* F17: Gnome3.4
* F17: UsrMove
* F18: Gnome3.6
* F18: New Installer UI

Also, with an explicit recognition of a Feature being critical, the
planning process would naturally involve discussions like:
* Should this Feature block the release?
* Are we biting off too much in this release?
* Can these features be broken into smaller, less-disruptive pieces?
* This feature is going to need targeted testing
* Hey, wait a minute, that's no ordinary Feature!
* Hey, wait a minute, if we revert that at the last second, it'll blow
  the testing schedule!

Plus, in the big swamp of features we've been getting, it's harder to
lose track of a critical feature that doesn't pop out of the list.

And I'm not saying we don't do this already--systemd is a perfect
example.  Everybody knew that it would slip the release if it didn't
work and everyone (systemd developers included) worked to ensure that
the impact was no greater than it needed to be, and pushed it out a
release when it was recognized that it would be too disruptive for F14.

On the other hand, New Installer UI seems to have slipped through the
cracks.

Just an idea...

-- 
Scott Schmit

Maybe highlight release-slipping features?

[Marcela Mašláňová]

On 10/31/2012 12:38 PM, Scott Schmit wrote:
>  On Wed, Oct 31, 2012 at 09:59:55AM +0000, "Jóhann B.
> Guðmundsson" wrote:
> > Given the current state of F18 I agree let's lengthen this release
> > cycle up to 9 months and arguably we should lengthen the whole
>                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > development cycle to 9 months from now on.
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>  I'm not sure that helps -- then people just get more ambitious with
>  their features and then what? Slow the release cycle down more?
>
>  Remember, the whole point of regular, strict-timed releases is to keep
>  things moving.
>
>  What it appears we have is a development process where all features are
>  optional in a given release except for Anaconda and any other feature
>  accepted with no executable contingency plan (and there's usually at
>  least one each release).
>
>  I'm not certain that that's an entirely *bad* thing.  Some Features are
>  necessarily big & disruptive and that always brings with it a risk of
>  unexpected problems--shying away from those changes means you never do
>  anything significant.
>
>  IIRC, a Feature being big and impossible to revert isn't typically a
>  surprise to at least one person on FESCo--I think more than once I've
>  heard someone say "well, we knew that wasn't a contingency plan we could
>  actually execute, but we had to do this."  But they may be (and
>  sometimes have been) a surprise to others.
>
>  Maybe we need to highlight those features that don't have a realistic
>  contingency plan (the work to revert and re-test is greater than the
>  work to complete) and call them out as "Critical Features" that we are
>  committing to slipping a release for if they don't work well, rather
>  than to revert them.
>
>  I'm not terribly familiar with the release criteria, so this is
>  something of a stab, but I suspect these Features from recent versions
>  would be considered critical:
>  * F15: Gnome3
>  * F15: GCC46
>  * F15: systemd
>  * F16: Gnome3.2
>  * F16: grub2
>  * F17: GCC47
>  * F17: Gnome3.4
>  * F17: UsrMove
>  * F18: Gnome3.6
>  * F18: New Installer UI
>
>  Also, with an explicit recognition of a Feature being critical, the
>  planning process would naturally involve discussions like:
>  * Should this Feature block the release?
>  * Are we biting off too much in this release?
>  * Can these features be broken into smaller, less-disruptive pieces?
>  * This feature is going to need targeted testing
>  * Hey, wait a minute, that's no ordinary Feature!
>  * Hey, wait a minute, if we revert that at the last second, it'll blow
>     the testing schedule!
>  
Well, we (FESCo) usually talk more about disruptive changes. The problem 
is that our opinions on what is disruptive and what is not can differ. 
Also if we have for one meeting more than 10 features then is very hard 
to really review the whole feature with all possible dependencies.
I believe we need to act according that in next release.

Marcela

>  Plus, in the big swamp of features we've been getting, it's
> harder to
>  lose track of a critical feature that doesn't pop out of the list.
>
>  And I'm not saying we don't do this already--systemd is a perfect
>  example.  Everybody knew that it would slip the release if it didn't
>  work and everyone (systemd developers included) worked to ensure that
>  the impact was no greater than it needed to be, and pushed it out a
>  release when it was recognized that it would be too disruptive for F14.
>
>  On the other hand, New Installer UI seems to have slipped through the
>  cracks.
>
>  Just an idea...
>
>
>

Maybe highlight release-slipping features? (was: Re: Anaconda is totally trashing the F18 schedule)

[Matthew Miller]

On Wed, Oct 31, 2012 at 07:38:27AM -0400, Scott Schmit wrote:
>  > Given the current state of F18 I agree let's lengthen this
> release
>  > cycle up to 9 months and arguably we should lengthen the whole
>                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  > development cycle to 9 months from now on.
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  I'm not sure that helps -- then people just get more ambitious with
>  their features and then what? Slow the release cycle down more?
>  Remember, the whole point of regular, strict-timed releases is to keep
>  things moving. 
+1 to this. With a 6 month cycle, if something isn't ready, slipping isn't
usually earth-shattering.

What I think we need is:

- more cross-cycle planning.
- a more functional rawhide which people can actually develop against.


>  Maybe we need to highlight those features that don't have a
> realistic
>  contingency plan (the work to revert and re-test is greater than the
>  work to complete) and call them out as "Critical Features" that we are
>  committing to slipping a release for if they don't work well, rather
>  than to revert them. 
+1 to this too.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Dario Lesca]

Il giorno mar, 30/10/2012 alle 10.40 -0700, Adam Williamson ha scritto:
>  You indicated at the start of this side-thread that you wanted to
> use
>  an existing partition without re-formatting it. You can do so just
>  fine with TC6 or other Beta builds. If you re-use a partition in TC6
>  it will be re-used without being re-formatted. 
>  What is missing from TC6 and will be added in the next build is the
>  ability to choose to reformat the partition. If you do not want to
>  reformat it, this is not a problem for you. 
Ok, now is clear enough.

When I re-install f18 on a f18 or f17 for test it, I format some FS
(/boot, / and /var) and do not format other FS (/home and /opt)

Since the new interface partitioning anaconda is quite different (and,
IMHO, for now, less intuitive) from the previous interface, I could not
understand when the FS was formatted and when not.

Thanks for reply
 
-- 
Dario Lesca - sip:[e-mail]
(Inviato dal mio Linux Fedora 17 Gnome3)

[Adam Williamson]

On Tue, 2012-10-16 at 15:29 +0200, Dario Lesca wrote:
>  Hi, I have download the last Fedora-18-Beta-TC4 to do some tests
>
> http://dl.fedoraproject.org/pub/alt/stage/18-Beta-TC4/Fedora/x86_64/iso/F...
>  
>  How to install it on a empty disk and use LVM (or create a software
>  RaID)?
>  
>  From the new disk manager anaconda panel I did not understand how to
>  create a new LVM partition and root and swap volume.
>  
>  Is this features not yet supported or I have lost some HOWTO? 
When you pick a disk and hit Continue, check the box that says something
about 'let me customize' before hitting the next Continue. That gets you
into the custom partitioning mode, which you need to use for LVM or RAID
(non-custom partitioning no longer allows LVM).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net