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/Fedo...
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
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.
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
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.
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
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.
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.
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/Fedo...
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:dario@solinos.it (Inviato dal mio Linux Fedora 17 Gnome3)
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/Fedo...
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.
- Click the + button near the bottom of the screen.
- Enter '/' for mountpoint and whatever size you want.
- Hit Confirm or Add or whatever the dialog button is.
- Select the new mountpoint on the left side of the screen.
- Click the + on the right side of the screen to edit the device options.
- 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.
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/Fedo...
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.
- Click the + button near the bottom of the screen.
- Enter '/' for mountpoint and whatever size you want.
- Hit Confirm or Add or whatever the dialog button is.
- Select the new mountpoint on the left side of the screen.
- Click the + on the right side of the screen to edit the device options.
- 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:dario@solinos.it (Inviato dal mio Linux Fedora 17 Gnome3)
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?
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.
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?
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.
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.
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?
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.
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.
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.
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@gmail.com Sometimes there's nothing left to do but crash and burn...or die trying. ========================================================================
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?
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@gmail.com Sometimes there's nothing left to do but crash and burn...or die trying. ========================================================================
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.
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?
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
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!!
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!
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
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
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:dario@solinos.it (Inviato dal mio Linux Fedora 17 Gnome3)
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
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
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.
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.
It's time somebody asked this, so ...
Adam Williamson awilliam@redhat.com 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
On Tue, 2012-10-30 at 14:08 -0400, Tom Lane wrote:
It's time somebody asked this, so ...
Adam Williamson awilliam@redhat.com 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.
On Tue, Oct 30, 2012 at 7:12 PM, Adam Williamson awilliam@redhat.com 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.
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.
On Tue, Oct 30, 2012 at 7:45 PM, Adam Williamson awilliam@redhat.com 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.
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
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
On 30 October 2012 18:45, Adam Williamson awilliam@redhat.com 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.
----- Original Message -----
From: "Richard Hughes" hughsient@gmail.com To: "Development discussions related to Fedora" devel@lists.fedoraproject.org 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@redhat.com 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.
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?
On Tue, Oct 30, 2012 at 10:58 PM, David Airlie airlied@redhat.com wrote:
----- Original Message -----
From: "Richard Hughes" hughsient@gmail.com To: "Development discussions related to Fedora" <
devel@lists.fedoraproject.org>
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@redhat.com 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@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
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
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.
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 -
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.
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.
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.
Adam Williamson awilliam@redhat.com 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
----- Original Message -----
Adam Williamson awilliam@redhat.com 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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.
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.
Tom Lane píše v St 31. 10. 2012 v 11:08 -0400:
Adam Williamson awilliam@redhat.com 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
On Tue, 2012-10-30 at 19:32 +0100, Gianluca Sforna wrote:
On Tue, Oct 30, 2012 at 7:12 PM, Adam Williamson awilliam@redhat.com 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
On Wed, Oct 31, 2012 at 10:27 AM, Vratislav Podzimek vpodzime@redhat.com 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@redhat.com 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.
On Wed, 2012-10-31 at 10:33 +0100, drago01 wrote:
On Wed, Oct 31, 2012 at 10:27 AM, Vratislav Podzimek vpodzime@redhat.com 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@redhat.com 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
On Wed, Oct 31, 2012 at 10:45 AM, Vratislav Podzimek vpodzime@redhat.com wrote:
On Wed, 2012-10-31 at 10:33 +0100, drago01 wrote:
On Wed, Oct 31, 2012 at 10:27 AM, Vratislav Podzimek vpodzime@redhat.com 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@redhat.com 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.
On Wed, Oct 31, 2012 at 10:33 AM, drago01 drago01@gmail.com wrote:
On Wed, Oct 31, 2012 at 10:27 AM, Vratislav Podzimek vpodzime@redhat.com 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.
On Wed, Oct 31, 2012 at 10:50 AM, Gianluca Sforna giallu@gmail.com wrote:
On Wed, Oct 31, 2012 at 10:33 AM, drago01 drago01@gmail.com wrote:
On Wed, Oct 31, 2012 at 10:27 AM, Vratislav Podzimek vpodzime@redhat.com 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).
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
On Wed, Oct 31, 2012 at 11:34 AM, Rahul Sundaram metherid@gmail.com 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
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
On Wed, Oct 31, 2012 at 7:54 AM, "Jóhann B. Guðmundsson" johannbg@gmail.com 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
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
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.
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
On Wed, Oct 31, 2012 at 7:54 AM, "Jóhann B. Guðmundsson" johannbg@gmail.com 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
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
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@vger.kernel.org
MD team list is: linux-raid@vger.kernel.org
The device mapper team list is: dm-devel@redhat.com
Each local file system has its list:
xfs@oss.sgi.com linux-btrfs@vger.kernel.org linux-nfs@vger.kernel.org linux-ext4@vger.kernel.org
SCSI issues are: linux-scsi@vger.kernel.org
S-ATA issues are: linux-ide@vger.kernel.org
Ric
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@vger.kernel.org
MD team list is: linux-raid@vger.kernel.org
The device mapper team list is: dm-devel@redhat.com
Each local file system has its list:
xfs@oss.sgi.com linux-btrfs@vger.kernel.org linux-nfs@vger.kernel.org linux-ext4@vger.kernel.org
SCSI issues are: linux-scsi@vger.kernel.org
S-ATA issues are: linux-ide@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
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@vger.kernel.org
MD team list is: linux-raid@vger.kernel.org
The device mapper team list is: dm-devel@redhat.com
Each local file system has its list:
xfs@oss.sgi.com linux-btrfs@vger.kernel.org linux-nfs@vger.kernel.org linux-ext4@vger.kernel.org
SCSI issues are: linux-scsi@vger.kernel.org
S-ATA issues are: linux-ide@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
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@vger.kernel.org
MD team list is: linux-raid@vger.kernel.org
The device mapper team list is: dm-devel@redhat.com
Each local file system has its list:
xfs@oss.sgi.com linux-btrfs@vger.kernel.org linux-nfs@vger.kernel.org linux-ext4@vger.kernel.org
SCSI issues are: linux-scsi@vger.kernel.org
S-ATA issues are: linux-ide@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
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
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. :)
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
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.
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
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.
Once upon a time, "Jóhann B. Guðmundsson" johannbg@gmail.com 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).
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@gmail.com 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
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
On Wed, Oct 31, 2012 at 10:50 AM, "Jóhann B. Guðmundsson" johannbg@gmail.com 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
----- Original Message -----
On Wed, Oct 31, 2012 at 10:50 AM, "Jóhann B. Guðmundsson" johannbg@gmail.com 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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
----- 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@gmail.com 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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&oldi...
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.
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
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.
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@redhat.com 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
On 31 October 2012 10:56, Toshio Kuratomi a.badger@gmail.com 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.)
Once upon a time, Stephen John Smoogen smooge@gmail.com 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).
On 31 October 2012 11:39, Chris Adams cmadams@hiwaay.net wrote:
Once upon a time, Stephen John Smoogen smooge@gmail.com 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.
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.
----- 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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.
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
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
On Thu, Nov 1, 2012 at 6:37 AM, Ralf Corsepius rc040203@freenet.de 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
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 -
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"....)
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?
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 -
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.
----- 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@fedoraproject.org
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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
----- 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Thu, Nov 1, 2012 at 7:10 PM, "Jóhann B. Guðmundsson" johannbg@gmail.com 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
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@fedoraproject.org
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Thu, Nov 1, 2012 at 7:34 PM, Matthew Miller mattdm@fedoraproject.org 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".
----- Original Message -----
On Thu, Nov 1, 2012 at 7:34 PM, Matthew Miller mattdm@fedoraproject.org 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Thu, Nov 1, 2012 at 7:45 PM, Jaroslav Reznik jreznik@redhat.com wrote:
----- Original Message -----
On Thu, Nov 1, 2012 at 7:34 PM, Matthew Miller mattdm@fedoraproject.org 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.
On Thu, 2012-11-01 at 19:50 +0100, drago01 wrote:
On Thu, Nov 1, 2012 at 7:45 PM, Jaroslav Reznik jreznik@redhat.com wrote:
----- Original Message -----
On Thu, Nov 1, 2012 at 7:34 PM, Matthew Miller mattdm@fedoraproject.org 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.
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.
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.
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
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.
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.
On Thu, Nov 1, 2012 at 2:45 PM, Jaroslav Reznik jreznik@redhat.com wrote:
----- Original Message -----
On Thu, Nov 1, 2012 at 7:34 PM, Matthew Miller mattdm@fedoraproject.org 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
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.
On Thu, Nov 1, 2012 at 7:34 PM, Matthew Miller mattdm@fedoraproject.org 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
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?
On Mon, Nov 5, 2012 at 7:34 PM, Matthew Miller mattdm@fedoraproject.org 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
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?
On Mon, Nov 5, 2012 at 8:38 PM, Matthew Miller mattdm@fedoraproject.org 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
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
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
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.
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
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.preset&am... 3.http://pkgs.fedoraproject.org/cgit/systemd.git/tree/90-default.preset
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.
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
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
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.
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...
On Thu, Nov 1, 2012 at 5:12 PM, Adam Williamson awilliam@redhat.com 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).
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
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.
On Thu, Nov 1, 2012 at 10:56 AM, Heiko Adams heiko.adams@gmail.com 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
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 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.
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.
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:
- level - rawhide-like repository, more or less anything goes
- 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".
- level - packages integrated and experience should be splendid :-)
However let's see how we'd handle systemd change with this system:
- 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.
- 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.
- 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:
- There are always multiple big changes happening in fedora. So even stable would see big updates on relatively frequent basis.
- 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
On Fri, Nov 2, 2012 at 9:03 AM, "Jóhann B. Guðmundsson" johannbg@gmail.com 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
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@gmail.com 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
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?
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
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.
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
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= johannbg@gmail.com 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
On 11/02/2012 04:25 PM, Tom Lane wrote:
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= johannbg@gmail.com 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
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= johannbg@gmail.com 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
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@redhat.com wrote:
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= johannbg@gmail.com 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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
On Fri, 02 Nov 2012 16:44:06 +0000 "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
On 11/02/2012 04:25 PM, Tom Lane wrote:
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= johannbg@gmail.com 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
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@gmail.com wrote:
On 11/02/2012 04:25 PM, Tom Lane wrote:
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= johannbg@gmail.com 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
On Fri, Nov 02, 2012 at 17:57:57 +0000, ""Jóhann B. Guðmundsson"" johannbg@gmail.com 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.
On Fri, Nov 2, 2012 at 12:57 PM, "Jóhann B. Guðmundsson" <johannbg@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@gmail.com wrote:
On 11/02/2012 04:25 PM, Tom Lane wrote:
=?UTF-8?B?**IkrDs2hhbm4gQi4gR3XDsG11bmRzc2**9uIg==?= johannbg@gmail.com 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@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel
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
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
----- Original Message -----
From: "Jóhann B. Guðmundsson" johannbg@gmail.com To: devel@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@gmail.com wrote:
On 11/02/2012 04:25 PM, Tom Lane wrote:
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= johannbg@gmail.com 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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
----- Original Message -----
From: "Jóhann B. Guðmundsson" johannbg@gmail.com To: devel@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Once upon a time, "Jóhann B. Guðmundsson" johannbg@gmail.com 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.
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@gmail.com wrote:
On 11/02/2012 04:25 PM, Tom Lane wrote:
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= johannbg@gmail.com 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
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
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@gmail.com wrote:
On 11/02/2012 04:25 PM, Tom Lane wrote:
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= johannbg@gmail.com 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
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@redhat.com To: devel@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@gmail.com wrote:
On 11/02/2012 04:25 PM, Tom Lane wrote:
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= johannbg@gmail.com 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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@redhat.com To: devel@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@gmail.com wrote:
On 11/02/2012 04:25 PM, Tom Lane wrote: > =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= > johannbg@gmail.com 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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@redhat.com To: devel@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@redhat.com To: devel@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@gmail.com wrote:
> On 11/02/2012 04:25 PM, Tom Lane wrote: >> =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= >> johannbg@gmail.com 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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@redhat.com To: devel@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@redhat.com To: devel@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@gmail.com wrote: > >> On 11/02/2012 04:25 PM, Tom Lane wrote: >>> =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= >>> johannbg@gmail.com 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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_Replying_t...
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@redhat.com To: devel@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@redhat.com To: devel@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@gmail.com wrote: >> >>> On 11/02/2012 04:25 PM, Tom Lane wrote: >>>> =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= >>>> johannbg@gmail.com 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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@redhat.com To: devel@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@redhat.com To: devel@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@gmail.com wrote: >>> >>>> On 11/02/2012 04:25 PM, Tom Lane wrote: >>>>> =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= >>>>> johannbg@gmail.com 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
-- devel mailing list devel@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
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
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
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
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
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!
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.
----- Original Message -----
From: "Vít Ondruch" vondruch@redhat.com To: devel@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@redhat.com To: devel@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@redhat.com To: devel@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@gmail.com wrote: >>> >>>> On 11/02/2012 04:25 PM, Tom Lane wrote: >>>>> =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= >>>>> johannbg@gmail.com 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Dne 6.11.2012 14:17, Aleksandar Kurtakov napsal(a):
----- Original Message -----
From: "Vít Ondruch" vondruch@redhat.com To: devel@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
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@redhat.com To: devel@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
On Tue, Nov 06, 2012 at 16:04:39 +0100, Ralf Corsepius rc040203@freenet.de 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.
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@redhat.com To: devel@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
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
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
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
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@redhat.com To: devel@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