Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
sandeen at redhat.com
Wed Oct 31 14:34:45 UTC 2012
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 at 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.
More information about the devel