3 p.m.
Today at FESCo meeting [1] it was decided to slip Fedora 18
Beta release by *two* weeks to give the Installer team,
the new upgrade tool and Secure Boot time to finish and
polish these features to meet our release quality standards.
As a result, Fedora 18 Beta will be pushed out by two weeks,
the development is re-opened, with tentative Change Deadline
on Nov 13. Fedora 18 Beta release is now Nov 27. Anyone with
objections to enter Beta freeze on Nov 13 can file a ticket
with FESCo on the Nov 12/13 and it will be discussed in the
ticket or on special meeting.
Final Change deadline is rescheduled to Dec 18 with final
Fedora 18 release on 2013 Jan 08 [2].
The Go/No-Go meeting on Thursday, Nov 08 is cancelled.
Please, work on your blocker bugs and help testing the
Fedora 18, so we will be able to release in the beginning
of January.
[1]
http://meetbot.fedoraproject.org/fedora-meeting/2012-11-07/fesco.2012-11-...
[2] https://fedoraproject.org/wiki/Releases/18/Schedule
Thanks
Jaroslav
_______________________________________________
test-announce mailing list
test-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
7:52 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Jaroslav Reznik <jreznik <at> redhat.com> writes:
Final Change deadline is rescheduled to Dec 18 with final
Fedora 18 release on 2013 Jan 08 [2].
I know everyone is going to hate me for saying this, but wouldn't it make sense
to just forget about F-18 and go for F-19 instead? After all, F-19 feature
submission deadline will probably be only a few weeks after F-18 release (as it
stands now, unless it slips again).
--
Bojan
9:07 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Oh my goodness. This is the highest amount of slippage I've seen in quite
some time. What is wrong with Fedora? The slippage is getting worse each
and every single release. I love Fedora and all, but this is absolutely
ridiculous...
On Wed, Nov 7, 2012 at 7:52 PM, Bojan Smojver <bojan(a)rexursive.com> wrote:
Jaroslav Reznik <jreznik <at> redhat.com> writes:
> Final Change deadline is rescheduled to Dec 18 with final
> Fedora 18 release on 2013 Jan 08 [2].
I know everyone is going to hate me for saying this, but wouldn't it make
sense
to just forget about F-18 and go for F-19 instead? After all, F-19 feature
submission deadline will probably be only a few weeks after F-18 release
(as it
stands now, unless it slips again).
--
Bojan
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
9:35 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
I dont think anything is "wrong" with Fedora, but I do think we need to have
reasonable expectations for systems that are put together with lots of moving parts.
Delays are not rediculous, they are just the nature of complex systems.
Nobody is forcing anyone to hurt furry animals while the release is getting together. Its
a little sad and dissapointing, but thats about it.
I'm happy the QA team has enough sway to ensure that a release is sweet, and not
rough-edged.
I think people remember the rough edges way longer than the 'it just worked'
stuff.
:)
On 8/11/12 12:37 PM, Conan Kudo (ニール・ゴンパ) wrote:
Oh my goodness. This is the highest amount of slippage I've seen
in quite some time. What is wrong with Fedora? The slippage is getting worse each and
every single release. I love Fedora and all, but this is absolutely ridiculous...
On Wed, Nov 7, 2012 at 7:52 PM, Bojan Smojver <bojan(a)rexursive.com
<mailto:bojan@rexursive.com>> wrote:
Jaroslav Reznik <jreznik <at> redhat.com <http://redhat.com>>
writes:
> Final Change deadline is rescheduled to Dec 18 with final
> Fedora 18 release on 2013 Jan 08 [2].
I know everyone is going to hate me for saying this, but wouldn't it make sense
to just forget about F-18 and go for F-19 instead? After all, F-19 feature
submission deadline will probably be only a few weeks after F-18 release (as it
stands now, unless it slips again).
--
Bojan
--
devel mailing list
devel(a)lists.fedoraproject.org <mailto:devel@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/devel
9:55 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Wed, 2012-11-07 at 21:07 -0600, Conan Kudo (ニール・ゴンパ) wrote:
Oh my goodness. This is the highest amount of slippage I've seen
in
quite some time. What is wrong with Fedora?
The new anaconda UI and related features are more or less entirely the
cause of the slip. Secure boot support is also not done yet (waiting on
the signature for shim to get sorted out by legal), though I don't know
whether FESCo yet absolutely decided that has to be in for Beta.
The slippage is getting worse each and every single release. I love
Fedora and all, but this is absolutely ridiculous...
It isn't, if you look at the facts, the slips for the last few releases
have been fairly similar and there's no pattern of them getting longer.
This release is special because of the major anaconda change, which it's
turning out after the fact could have been organized better (hindsight
is 20/20).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
11:04 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 8, 2012 at 5:55 AM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Wed, 2012-11-07 at 21:07 -0600, Conan Kudo (ニール・ゴンパ) wrote:
> Oh my goodness. This is the highest amount of slippage I've seen in
> quite some time. What is wrong with Fedora?
The new anaconda UI and related features are more or less entirely the
cause of the slip. Secure boot support is also not done yet (waiting on
the signature for shim to get sorted out by legal), though I don't know
whether FESCo yet absolutely decided that has to be in for Beta.
> The slippage is getting worse each and every single release. I love
> Fedora and all, but this is absolutely ridiculous...
It isn't, if you look at the facts, the slips for the last few releases
have been fairly similar and there's no pattern of them getting longer.
This release is special because of the major anaconda change, which it's
turning out after the fact could have been organized better (hindsight
is 20/20).
Has anyone (FESCo) considered pushing Anaconda rewrite to F19 and ship
F18 w/ the old Anaconda?
I just tried the latest TC and while Anaconda did give me a working
F18 installation, the experience is still rather raw (Can't say the I
met major bugs, though).
... With all the testing resources pushing toward Anaconda, its very
likely that breakage in (many) other components may go unnoticed.
- Gilboa
12:16 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, 2012-11-08 at 07:04 +0200, Gilboa Davara wrote:
On Thu, Nov 8, 2012 at 5:55 AM, Adam Williamson
<awilliam(a)redhat.com> wrote:
>
> On Wed, 2012-11-07 at 21:07 -0600, Conan Kudo (ニール・ゴンパ) wrote:
> > Oh my goodness. This is the highest amount of slippage I've seen in
> > quite some time. What is wrong with Fedora?
>
> The new anaconda UI and related features are more or less entirely the
> cause of the slip. Secure boot support is also not done yet (waiting on
> the signature for shim to get sorted out by legal), though I don't know
> whether FESCo yet absolutely decided that has to be in for Beta.
>
> > The slippage is getting worse each and every single release. I love
> > Fedora and all, but this is absolutely ridiculous...
>
> It isn't, if you look at the facts, the slips for the last few releases
> have been fairly similar and there's no pattern of them getting longer.
> This release is special because of the major anaconda change, which it's
> turning out after the fact could have been organized better (hindsight
> is 20/20).
>
Has anyone (FESCo) considered pushing Anaconda rewrite to F19 and ship
F18 w/ the old Anaconda?
Yes. Several times. The last one just last week. We probably don't need
to go over that again.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
11:31 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Adam Williamson wrote:
The new anaconda UI and related features are more or less entirely
the
cause of the slip.
This shows that those changes should not have been done, or at least not in
this way.
Secure boot support is also not done yet (waiting on the signature
for
shim to get sorted out by legal), though I don't know whether FESCo yet
absolutely decided that has to be in for Beta.
And Restricted Boot support just needs to go away!
Kevin Kofler
11:56 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 08, 2012 at 06:31:20AM +0100, Kevin Kofler wrote:
Adam Williamson wrote:
> The new anaconda UI and related features are more or less entirely the
> cause of the slip.
This shows that those changes should not have been done, or at least not in
this way.
It turns out that software development is hard. It's especially hard
when you have a hugely complicated system with no central management and
no real incentive for most of the skilled workers to cooperate on
sections of the project that influence each other. It's nigh-near
impossible when you have the same set of people tasked to simultaneously
stabalise an upcoming release and do the development work for the
forthcoming release. The miracle isn't that Anaconda is taking longer
than desirable. It's that it's as close to finished as it is.
> Secure boot support is also not done yet (waiting on the
signature for
> shim to get sorted out by legal), though I don't know whether FESCo yet
> absolutely decided that has to be in for Beta.
And Restricted Boot support just needs to go away!
Sure, who wants new computers.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
6:58 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 05:56 AM, Matthew Garrett wrote:
It turns out that software development is hard. It's especially
hard
when you have a hugely complicated system with no central management and
no real incentive for most of the skilled workers to cooperate on
sections of the project that influence each other. It's nigh-near
impossible when you have the same set of people tasked to simultaneously
stabalise an upcoming release and do the development work for the
forthcoming release. The miracle isn't that Anaconda is taking longer
than desirable. It's that it's as close to finished as it is.
Is it not just time to form a "CoreOS" SIG which include Anaconda, the
storage developers, The kernel, Dracut,/Systemd/Udev, and arguably
selinux and the network guys as well to ensure "proper" communication of
changes between teams responsible for "core" ( installation/boot/network
handling ) functionality within the project?
JBG
8:31 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 08, 2012 at 12:58:59PM +0000, "Jóhann B. Guðmundsson" wrote:
Is it not just time to form a "CoreOS" SIG which include
Anaconda,
the storage developers, The kernel, Dracut,/Systemd/Udev, and
arguably selinux and the network guys as well to ensure "proper"
communication of changes between teams responsible for "core" (
installation/boot/network handling ) functionality within the
project?
What kind of structure would you imagine such a SIG having? Who would be
taking overall responsibility?
--
Matthew Garrett | mjg59(a)srcf.ucam.org
8:48 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 02:31 PM, Matthew Garrett wrote:
On Thu, Nov 08, 2012 at 12:58:59PM +0000, "Jóhann B.
Guðmundsson" wrote:
> Is it not just time to form a "CoreOS" SIG which include Anaconda,
> the storage developers, The kernel, Dracut,/Systemd/Udev, and
> arguably selinux and the network guys as well to ensure "proper"
> communication of changes between teams responsible for "core" (
> installation/boot/network handling ) functionality within the
> project?
What kind of structure would you imagine such a SIG having?
Sorry not following?
I assume this ( and related mailinglist ) would be the place where they
manage and coordinate changes relevant to the "CoreOS" (
Installation/bootup etc ) of the Fedora distribution in current and
future releases to better coordinate implement feature relate to the
"CoreOS"
Who would be
taking overall responsibility?
I assume that SIG answers to BOARD/FESCO as do every other one and they
themselves decide among themselves how their own SIG governing structure
will be.
JBG
9:08 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 03:48 PM, "Jóhann B. Guðmundsson" wrote:
On 11/08/2012 02:31 PM, Matthew Garrett wrote:
> On Thu, Nov 08, 2012 at 12:58:59PM +0000, "Jóhann B. Guðmundsson" wrote:
>
>> Is it not just time to form a "CoreOS" SIG which include Anaconda,
>> the storage developers, The kernel, Dracut,/Systemd/Udev, and
>> arguably selinux and the network guys as well to ensure "proper"
>> communication of changes between teams responsible for "core" (
>> installation/boot/network handling ) functionality within the
>> project?
> What kind of structure would you imagine such a SIG having?
Sorry not following?
I assume this ( and related mailinglist ) would be the place where they
manage and coordinate changes relevant to the "CoreOS" (
Installation/bootup etc ) of the Fedora distribution in current and
future releases to better coordinate implement feature relate to the
"CoreOS"
> Who would be
> taking overall responsibility?
>
I assume that SIG answers to BOARD/FESCO as do every other one and they
themselves decide among themselves how their own SIG governing structure
will be.
JBG
Correct me if I'm wrong, but SIGs don't have a leader, they decide about
changes together. Core SIG is nice idea, but changes in Core should be
already discussed here and it's not happening. How would you change it?
Marcela
9:32 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 08, 2012 at 02:48:26PM +0000, "Jóhann B. Guðmundsson" wrote:
On 11/08/2012 02:31 PM, Matthew Garrett wrote:
>What kind of structure would you imagine such a SIG having?
Sorry not following?
I assume this ( and related mailinglist ) would be the place where
they manage and coordinate changes relevant to the "CoreOS" (
Installation/bootup etc ) of the Fedora distribution in current and
future releases to better coordinate implement feature relate to the
"CoreOS"
Management requires managers. Creating a SIG doesn't magically cause
communication or coordination to happen.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
9:40 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 8, 2012 at 9:32 AM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
On Thu, Nov 08, 2012 at 02:48:26PM +0000, "Jóhann B.
Guðmundsson" wrote:
> On 11/08/2012 02:31 PM, Matthew Garrett wrote:
> >What kind of structure would you imagine such a SIG having?
>
> Sorry not following?
>
> I assume this ( and related mailinglist ) would be the place where
> they manage and coordinate changes relevant to the "CoreOS" (
> Installation/bootup etc ) of the Fedora distribution in current and
> future releases to better coordinate implement feature relate to the
> "CoreOS"
Management requires managers. Creating a SIG doesn't magically cause
communication or coordination to happen.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
In theory, having a dedicated group of a certain size makes it easier to
manage and delegate tasks, but whether that works in practice is somewhat
debatable.
9:50 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 04:40 PM, Conan Kudo (ニール・ゴンパ) wrote:
On Thu, Nov 8, 2012 at 9:32 AM, Matthew Garrett
<mjg59(a)srcf.ucam.org
<mailto:mjg59@srcf.ucam.org>> wrote:
On Thu, Nov 08, 2012 at 02:48:26PM +0000, "Jóhann B. Guðmundsson" wrote:
> On 11/08/2012 02:31 PM, Matthew Garrett wrote:
> >What kind of structure would you imagine such a SIG having?
>
> Sorry not following?
>
> I assume this ( and related mailinglist ) would be the place where
> they manage and coordinate changes relevant to the "CoreOS" (
> Installation/bootup etc ) of the Fedora distribution in current and
> future releases to better coordinate implement feature relate to the
> "CoreOS"
Management requires managers. Creating a SIG doesn't magically cause
communication or coordination to happen.
--
Matthew Garrett | mjg59(a)srcf.ucam.org <mailto:mjg59@srcf.ucam.org>
--
devel mailing list
devel(a)lists.fedoraproject.org <mailto:devel@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/devel
In theory, having a dedicated group of a certain size makes it easier to
manage and delegate tasks, but whether that works in practice is
somewhat debatable.
As I said SIGs don't have a leader. You can't force people to do the
work if they don't wish to. You can ask them to communicate changes and
make them more visible for other projects.
Marcela
11:02 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 08, 2012 at 16:50:25 +0100,
Marcela Mašláňová <mmaslano(a)redhat.com> wrote:
As I said SIGs don't have a leader. You can't force people to
do the
work if they don't wish to. You can ask them to communicate changes
and make them more visible for other projects.
That depends on the SIG. It can certainly help in many cases to have a
recognized leader.
10 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 08, 2012 at 03:32:57PM +0000, Matthew Garrett wrote:
On Thu, Nov 08, 2012 at 02:48:26PM +0000, "Jóhann B.
Guðmundsson" wrote:
> On 11/08/2012 02:31 PM, Matthew Garrett wrote:
> >What kind of structure would you imagine such a SIG having?
>
> Sorry not following?
>
> I assume this ( and related mailinglist ) would be the place where
> they manage and coordinate changes relevant to the "CoreOS" (
> Installation/bootup etc ) of the Fedora distribution in current and
> future releases to better coordinate implement feature relate to the
> "CoreOS"
Management requires managers. Creating a SIG doesn't magically cause
communication or coordination to happen.
Correct. Someone has to take the lead to ensure the process actually
happens.
--
David Cantrell <dcantrell(a)redhat.com>
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
10:06 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 8, 2012 at 10:00 AM, David Cantrell <dcantrell(a)redhat.com>wrote:
On Thu, Nov 08, 2012 at 03:32:57PM +0000, Matthew Garrett wrote:
> On Thu, Nov 08, 2012 at 02:48:26PM +0000, "Jóhann B. Guðmundsson" wrote:
> > On 11/08/2012 02:31 PM, Matthew Garrett wrote:
> > >What kind of structure would you imagine such a SIG having?
> >
> > Sorry not following?
> >
> > I assume this ( and related mailinglist ) would be the place where
> > they manage and coordinate changes relevant to the "CoreOS" (
> > Installation/bootup etc ) of the Fedora distribution in current and
> > future releases to better coordinate implement feature relate to the
> > "CoreOS"
>
> Management requires managers. Creating a SIG doesn't magically cause
> communication or coordination to happen.
Correct. Someone has to take the lead to ensure the process actually
happens.
Maybe since FESCO works with the Feature Wrangler on features, maybe each
Feature
should have a designated FESCO member that watches, nags, pokes,
assists, etc? Call it a Feature Patron or something.
-J
--
David Cantrell <dcantrell(a)redhat.com>
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
http://cecinestpasunefromage.wordpress.com/
------------------------------------------------
in your fear, seek only peace
in your fear, seek only love
-d. bowie
9:59 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 08, 2012 at 12:58:59PM +0000, "Jóhann B. Guðmundsson" wrote:
On 11/08/2012 05:56 AM, Matthew Garrett wrote:
>It turns out that software development is hard. It's especially hard
>when you have a hugely complicated system with no central management and
>no real incentive for most of the skilled workers to cooperate on
>sections of the project that influence each other. It's nigh-near
>impossible when you have the same set of people tasked to simultaneously
>stabalise an upcoming release and do the development work for the
>forthcoming release. The miracle isn't that Anaconda is taking longer
>than desirable. It's that it's as close to finished as it is.
Is it not just time to form a "CoreOS" SIG which include Anaconda,
the storage developers, The kernel, Dracut,/Systemd/Udev, and
arguably selinux and the network guys as well to ensure "proper"
communication of changes between teams responsible for "core" (
installation/boot/network handling ) functionality within the
project?
Whatever we call it, I agree that we need a formal process to make sure all
of these components are on the same page and aware of what each other is
doing.
--
David Cantrell <dcantrell(a)redhat.com>
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
9:58 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 08, 2012 at 05:56:31AM +0000, Matthew Garrett wrote:
On Thu, Nov 08, 2012 at 06:31:20AM +0100, Kevin Kofler wrote:
> Adam Williamson wrote:
> > The new anaconda UI and related features are more or less entirely the
> > cause of the slip.
>
> This shows that those changes should not have been done, or at least not in
> this way.
It turns out that software development is hard. It's especially hard
when you have a hugely complicated system with no central management and
no real incentive for most of the skilled workers to cooperate on
sections of the project that influence each other. It's nigh-near
impossible when you have the same set of people tasked to simultaneously
stabalise an upcoming release and do the development work for the
forthcoming release. The miracle isn't that Anaconda is taking longer
than desirable. It's that it's as close to finished as it is.
Thanks, Matthew. I'd also like to clarify some misunderstandings I've heard
directly or indirectly from other people. These are paraphrases of what
I've heard.
1) "The installer team did not anticipate the amount of work required."
Not true. As with our other major changes, we new it would be absolutely
impossible to deliver all functionality in a single release. So from the
beginning we were planning to stage the newui work across multiple releases.
This is _in addition_ to other components undergoing major and fundamental
changes.
For the newui work, initial discussions started at FUDCon Tempe, through the
year, and then again at FUDCon Blacksburg. After that, more design work
continued, soliciting for user feedback as much as possible.
This is why we began communicating our work early and involving groups like
Fedora QA as early as possible. Our false assumption was that we were all
on the same page as to what would and would not be ready for F-18. To me it
seems a lot of these slips are caused by things we thought everyone knew we
could push to F-19 but really we wanted in F-18. So that's communication
and setting expectations. We can do better with that in the future.
2) "Just stop everything, move newui to F-19, and ship the F-17 installer."
This just delays what we are going through right now until the F-19 cycle.
We need to identify the failings at some point and work to improve/change
them.
This also assumes the F-17 installer will work as a drop-in for F-18, which
it won't. So where should we be spending our engineering resources?
3) "The new installer should have been tested more!"
I completely agree! Which is why we were getting early test builds done
during the F-17 cycle and working to get people testing the installer then.
The main problem is that no one _wants_ to test the installer. It's a
utility. A necessary step to getting Fedora on your system. Testing it
isn't sexy to a lot of people. We can't force people to test it, we can
only make it available and ask for help.
And to those early testers who have helped and provide useful feedback,
thank you!
4) "Anaconda releases shouldn't be tied so closely to Fedora releases."
Well, ok, but it is. No matter how distant we make the installer from a
distribution release, we're always going to be tied to the release process.
That's where people use it.
The biggest impact this has for us is that our real test and development
cycle happens between the devel freeze and RC. Most people don't notice it
because we are not doing things like newui, but that's how it's been for
years. It works ok for maintenance, but large scale things like this become
more visible and people get frustrated.
--
David Cantrell <dcantrell(a)redhat.com>
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
10:32 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 03:58 PM, David Cantrell wrote:
Not true. As with our other major changes, we new it would be
absolutely
impossible to deliver all functionality in a single release.
What exactly prevented the Anaconda from implementing Anaconda 2.0 in a
F19 or later when it was fully complete?
Or if I rephrase why could not the community continue to use Anaconda in
it's form that it existed in F17 until the "new installer" was
*completly* done?
JBG
10:37 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 08, 2012 at 04:32:29PM +0000, "Jóhann B. Guðmundsson" wrote:
Or if I rephrase why could not the community continue to use
Anaconda in it's form that it existed in F17 until the "new
installer" was *completly* done?
Because nobody in the community did the work to make the F17 Anaconda
work in F18?
--
Matthew Garrett | mjg59(a)srcf.ucam.org
10:48 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 04:37 PM, Matthew Garrett wrote:
On Thu, Nov 08, 2012 at 04:32:29PM +0000, "Jóhann B.
Guðmundsson" wrote:
> Or if I rephrase why could not the community continue to use
> Anaconda in it's form that it existed in F17 until the "new
> installer" was *completly* done?
Because nobody in the community did the work to make the F17 Anaconda
work in F18?
No I assume everyone expected the Anaconda developers to handle that if
not they would have asked for assistance in that regard and outlined the
steps necessary to do so which I assume would have been minimal if
necessary et all since I expect the installer to be able to work on
packages in F16 or F17 or F18 for that matter hence the installer would
be unchanged while the package set he is installing would only change.
Is my assumption wrong in that regard as in the installer in F17 could
not have been used and if so why?
JBG
12:24 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 08, 2012 at 04:48:52PM +0000, "Jóhann B. Guðmundsson" wrote:
No I assume everyone expected the Anaconda developers to handle that
if not they would have asked for assistance in that regard and
outlined the steps necessary to do so which I assume would have been
minimal if necessary et all since I expect the installer to be able
to work on packages in F16 or F17 or F18 for that matter hence the
installer would be unchanged while the package set he is installing
would only change.
The Anaconda developers have clearly been working on the assumption that
F18 would ship the F18 Anaconda. Why would they have also been working
on supporting the F17 Anaconda on F18?
Is my assumption wrong in that regard as in the installer in F17
could not have been used and if so why?
Your assumption is incorrect. Anaconda is very tightly tied to various
system components.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
10:30 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 08:48 AM, "Jóhann B. Guðmundsson" wrote:
>
No I assume everyone expected the Anaconda developers to handle that if
not they would have asked for assistance in that regard and outlined the
steps necessary to do so which I assume would have been minimal if
necessary et all since I expect the installer to be able to work on
packages in F16 or F17 or F18 for that matter hence the installer would
be unchanged while the package set he is installing would only change.
Is my assumption wrong in that regard as in the installer in F17 could
not have been used and if so why?
A significant amount of work had to be done to the newui code base
(which was largely developed and tested on F17) to get it to work in an
F18 environment. To get the F17 code base to work in an F18 environment
would have taken even more work, and that would would have had to be
done twice. Once for the F17 code base, once for the F18 code base. We
just don't have that many developers, so newui would be delayed again,
and we'd have to do the same thing again for F19. Meanwhile any feature
that requires installer interaction would have to either be punted, or
coded twice, and noted in a growing list of things to re-check after the
newui cut over to ensure it didn't break the new feature.
Anaconda is increasingly dependent upon the environment around it, which
has a tendency to change in unexpected and weird ways between releases.
Much of anaconda development work is reacting to subtle bugs that
arise in previously working code, being detective to figure out what has
changed in the environment and why and what the new rules on the ground
are so that we can make things work again.
We operate in a space that people don't think about, and that doesn't
get any real attention on a running system. When people make changes to
the pre-root environment they think it's fairly isolated and that
changes can happen with impunity, because runtime will be fine. Runtime
people make changes but think it's fine if their own stack continues to
work with the change or their stack is updated to work with the change,
but Anaconda is left broken.
We are not plug-n-play.
--
Jesse Keating
Fedora -- Freedom² is a feature!
11:06 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 04:37 PM, Matthew Garrett wrote:
On Thu, Nov 08, 2012 at 04:32:29PM +0000, "Jóhann B.
Guðmundsson" wrote:
> Or if I rephrase why could not the community continue to use
> Anaconda in it's form that it existed in F17 until the "new
> installer" was *completly* done?
Because nobody in the community did the work to make the F17 Anaconda
work in F18?
This also touches on "Who's responsible for an feature"
Just recently FESCO decided *for* Kay that he was responsible to ensure
the migration related docs and what not kept working for the name change
of configuration files that takes place in systemd ( which was not even
a feature ) Applying the same logic here the Anaconda developers
themselves would have been responsible keeping the "old code" working
until the new one was ready to completely replace it.
JBG
1.https://fedorahosted.org/fesco/ticket/963#comment:13
11:14 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 8 November 2012 10:06, "Jóhann B. Guðmundsson" <johannbg(a)gmail.com>
wrote:
On 11/08/2012 04:37 PM, Matthew Garrett wrote:
>
> On Thu, Nov 08, 2012 at 04:32:29PM +0000, "Jóhann B. Guðmundsson" wrote:
>
>> Or if I rephrase why could not the community continue to use
>> Anaconda in it's form that it existed in F17 until the "new
>> installer" was *completly* done?
>
> Because nobody in the community did the work to make the F17 Anaconda
> work in F18?
>
This also touches on "Who's responsible for an feature"
Just recently FESCO decided *for* Kay that he was responsible to ensure the
migration related docs and what not kept working for the name change of
configuration files that takes place in systemd ( which was not even a
feature ) Applying the same logic here the Anaconda developers themselves
would have been responsible keeping the "old code" working until the new one
was ready to completely replace it.
Your problem is that you are assuming a lot of things without actually
doing any legwork to find out what anaconda does. Anaconda does a lot
of probing of hardware which changes when kernels change. Anaconda
requires changes when dracut changes APIs. Every release requires
changes in what is blacklisted and what is not blacklisted. It
requires dealing with the usual multiple changes in python apis and
such. It has other changes due to EFI or secure boot or other
features. None of them are trivial and doing them in parallel is
usually not possible.
--
Stephen J Smoogen.
"Don't derail a useful feature for the 99% because you're not in it."
Linus Torvalds
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd
11:20 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 05:14 PM, Stephen John Smoogen wrote:
On 8 November 2012 10:06, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com> wrote:
> On 11/08/2012 04:37 PM, Matthew Garrett wrote:
>> On Thu, Nov 08, 2012 at 04:32:29PM +0000, "Jóhann B. Guðmundsson"
wrote:
>>
>>> Or if I rephrase why could not the community continue to use
>>> Anaconda in it's form that it existed in F17 until the "new
>>> installer" was *completly* done?
>> Because nobody in the community did the work to make the F17 Anaconda
>> work in F18?
>>
> This also touches on "Who's responsible for an feature"
>
> Just recently FESCO decided *for* Kay that he was responsible to ensure the
> migration related docs and what not kept working for the name change of
> configuration files that takes place in systemd ( which was not even a
> feature ) Applying the same logic here the Anaconda developers themselves
> would have been responsible keeping the "old code" working until the new
one
> was ready to completely replace it.
>
Your problem is that you are assuming a lot of things without actually
doing any legwork to find out what anaconda does. Anaconda does a lot
of probing of hardware which changes when kernels change. Anaconda
requires changes when dracut changes APIs. Every release requires
changes in what is blacklisted and what is not blacklisted. It
requires dealing with the usual multiple changes in python apis and
such. It has other changes due to EFI or secure boot or other
features. None of them are trivial and doing them in parallel is
usually not possible.
Not that your response is relate to who's responsible for making those
changes, but is that not a fundamental flaw in the installer and it's
design?
JBG
11:30 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 8 November 2012 10:20, "Jóhann B. Guðmundsson" <johannbg(a)gmail.com>
wrote:
> Your problem is that you are assuming a lot of things without
actually
> doing any legwork to find out what anaconda does. Anaconda does a lot
> of probing of hardware which changes when kernels change. Anaconda
> requires changes when dracut changes APIs. Every release requires
> changes in what is blacklisted and what is not blacklisted. It
> requires dealing with the usual multiple changes in python apis and
> such. It has other changes due to EFI or secure boot or other
> features. None of them are trivial and doing them in parallel is
> usually not possible.
Not that your response is relate to who's responsible for making those
changes, but is that not a fundamental flaw in the installer and it's
design?
Dude.. that is just reality. EVERY installer out there has to deal
with the fact that nearly every motherboard, BIOS, EFI, and OEM does
something to the hardware which makes it a one-off in some way that
the installer has to deal with. Even Apple hardware ends up with a
long list of if/then somewhere because mother board runs will end up
changing something somewhere that needs to be caught because the old
code won't work there.
The flaw is that computers are hard. People who want easy should just
stick to installing to virtual machines (even then you end up with a
long list of exceptions somewhere).
--
Stephen J Smoogen.
"Don't derail a useful feature for the 99% because you're not in it."
Linus Torvalds
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd
11:41 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 05:30 PM, Stephen John Smoogen wrote:
On 8 November 2012 10:20, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com> wrote:
>> Your problem is that you are assuming a lot of things without actually
>> doing any legwork to find out what anaconda does. Anaconda does a lot
>> of probing of hardware which changes when kernels change. Anaconda
>> requires changes when dracut changes APIs. Every release requires
>> changes in what is blacklisted and what is not blacklisted. It
>> requires dealing with the usual multiple changes in python apis and
>> such. It has other changes due to EFI or secure boot or other
>> features. None of them are trivial and doing them in parallel is
>> usually not possible.
>
> Not that your response is relate to who's responsible for making those
> changes, but is that not a fundamental flaw in the installer and it's
> design?
Dude.. that is just reality. EVERY installer out there has to deal
with the fact that nearly every motherboard, BIOS, EFI, and OEM does
something to the hardware which makes it a one-off in some way that
the installer has to deal with. Even Apple hardware ends up with a
long list of if/then somewhere because mother board runs will end up
changing something somewhere that needs to be caught because the old
code won't work there.
The flaw is that computers are hard. People who want easy should just
stick to installing to virtual machines (even then you end up with a
long list of exceptions somewhere).
Bro...
It should be sufficient to just tell/point the installer to use new
packages while still retain the same functionality/support as it did for
F17
( unless of course there is some serious fundamental design flaw in the
installer which makes him dependent on same package set he's installing )
JBG
12:37 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 8, 2012 at 11:11 PM, "Jóhann B. Guðmundsson" <johannbg(a)gmail.com
wrote:Bro...
"It should be sufficient to just tell/point the installer to use new
packages while still retain the same functionality/support as it did for F17
( unless of course there is some serious fundamental design flaw in the
installer which makes him dependent on same package set he's installing )"
Umm. It doesn't work like that. Installers have a lot of system
dependencies and when those dependencies change in various ways, installers
have to be modified just to keep up with the changes for the exact same
feature set.
Rahul
1:40 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 06:37 PM, Rahul Sundaram wrote:
On Thu, Nov 8, 2012 at 11:11 PM, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com <mailto:johannbg@gmail.com>> wrote:Bro...
"It should be sufficient to just tell/point the installer to use new
packages while still retain the same functionality/support as it did
for F17
( unless of course there is some serious fundamental design flaw in
the installer which makes him dependent on same package set he's
installing )"
Umm. It doesn't work like that. Installers have a lot of system
dependencies and when those dependencies change in various ways,
installers have to be modified just to keep up with the changes for
the exact same feature set.
I assume you are only referring to anaconda here or do you have any
other installer you can point to that behaves like this?
Pointing out how the installer currently works does not change my
opinion on the fact that if an installer ( any installer ) cannot run on
his own bits isolated from the package set he is about install is a
design flaw and is something that should be corrected ( from my pov ).
JBG
1:56 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, Nov 9, 2012 at 1:10 AM, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com>wrote:
I assume you are only referring to anaconda here or do you have
any
other installer you can point to that behaves like this?
Pointing out how the installer currently works does not change my opinion
on the fact that if an installer ( any installer ) cannot run on his own
bits isolated from the package set he is about install is a design flaw and
is something that should be corrected ( from my pov ).
Your pov is flawed. Not the design which does apply to all the mainstream
Linux distribution installers and not just Anaconda. Really, you
shouldn't be even arguing about this at all.
Rahul
2:02 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 07:56 PM, Rahul Sundaram wrote:
or do you have any other installer you can point to that behaves
like this?
Pointing out how the installer currently works does not change my
opinion on the fact that if an installer ( any installer ) cannot
run on his own bits isolated from the package set he is about
install is a design flaw and is something that should be corrected
( from my pov ).
Your pov is flawed. Not the design which does apply to all the
mainstream Linux distribution installers and not just Anaconda.
Really, you shouldn't be even arguing about this at all.
If my pov is flawed then why do you not enlighten me and explain to me
what causes the dependency in the installer environment with the release
and why these have to be tied together?
JBG
3:26 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 8 November 2012 13:02, "Jóhann B. Guðmundsson" <johannbg(a)gmail.com>
wrote:
On 11/08/2012 07:56 PM, Rahul Sundaram wrote:
>
> or do you have any other installer you can point to that behaves like
> this?
>
> Pointing out how the installer currently works does not change my opinion
> on the fact that if an installer ( any installer ) cannot run on his own
> bits isolated from the package set he is about install is a design flaw and
> is something that should be corrected ( from my pov ).
>
>
Your pov is flawed. Not the design which does apply to all the mainstream
Linux distribution installers and not just Anaconda. Really, you
shouldn't be even arguing about this at all.
If my pov is flawed then why do you not enlighten me and explain to me what
causes the dependency in the installer environment with the release and why
these have to be tied together?
I have tried 3 times. It is clear that my ability to do so is
incapable of reaching you. I am sorry, but I have done my best.. and
now I am done.
--
Stephen J Smoogen.
"Don't derail a useful feature for the 99% because you're not in it."
Linus Torvalds
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd
3:34 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 09:26 PM, Stephen John Smoogen wrote:
On 8 November 2012 13:02, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com> wrote:
> On 11/08/2012 07:56 PM, Rahul Sundaram wrote:
>> or do you have any other installer you can point to that behaves like
>> this?
>>
>> Pointing out how the installer currently works does not change my opinion
>> on the fact that if an installer ( any installer ) cannot run on his own
>> bits isolated from the package set he is about install is a design flaw and
>> is something that should be corrected ( from my pov ).
>>
>>
>
> Your pov is flawed. Not the design which does apply to all the mainstream
> Linux distribution installers and not just Anaconda. Really, you
> shouldn't be even arguing about this at all.
>
>
> If my pov is flawed then why do you not enlighten me and explain to me what
> causes the dependency in the installer environment with the release and why
> these have to be tied together?
I have tried 3 times. It is clear that my ability to do so is
incapable of reaching you. I am sorry, but I have done my best.. and
now I am done.
Given the obvious fact that you cannot even realize that this was not
directed at you but Rahul it's no wonder you cant and there is no need
for you to do so since David Lehman is managing to do that just fine...
2:12 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 08, 2012 at 07:40:47PM +0000, "Jóhann B. Guðmundsson" wrote:
Pointing out how the installer currently works does not change my
opinion on the fact that if an installer ( any installer ) cannot
run on his own bits isolated from the package set he is about
install is a design flaw and is something that should be corrected (
from my pov ).
Patches that cleanly decouple Anaconda from the entire software stack
that it runs on top of would probably be received with open arms, but
nobody who works on it has any idea how to implement them.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
2:19 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Matthew Garrett (mjg59(a)srcf.ucam.org) said:
Patches that cleanly decouple Anaconda from the entire software stack
that it runs on top of would probably be received with open arms, but
nobody who works on it has any idea how to implement them.
In fact, this is what has been done in anaconda over the past couple of
releases - Anaconda migrated from having its own boot and init
infrastructure to using system-provided items such as dracut and systemd.
But that's complicated work, and while you're doing that migration, you're
doing a lot of arbitration as to what bits are in generic dracut, what
bits are in generic systemd, and what bits remain in anaconda. And during
that process, you are *very* tied to the version of the underlying system,
until the work is fully complete and there is a defined separation of
features into each layer.
This, incidentally, also is why running the F17 installer on F19 isn't
practical.
Bill
3:08 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 8, 2012 at 9:19 PM, Bill Nottingham <notting(a)redhat.com> wrote:
Matthew Garrett (mjg59(a)srcf.ucam.org) said:
> Patches that cleanly decouple Anaconda from the entire software stack
> that it runs on top of would probably be received with open arms, but
> nobody who works on it has any idea how to implement them.
In fact, this is what has been done in anaconda over the past couple of
releases - Anaconda migrated from having its own boot and init
infrastructure to using system-provided items such as dracut and systemd.
But that's complicated work, and while you're doing that migration, you're
doing a lot of arbitration as to what bits are in generic dracut, what
bits are in generic systemd, and what bits remain in anaconda. And during
that process, you are *very* tied to the version of the underlying system,
until the work is fully complete and there is a defined separation of
features into each layer.
This, incidentally, also is why running the F17 installer on F19 isn't
practical.
Well not practical maybe ... impossible no.
In fact making an isolated image using F17 components and installer to
use it to install F18 should work. SB would be an issue though because
the old anaconda does not know anything about it,
3:30 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 8, 2012 at 4:08 PM, drago01 <drago01(a)gmail.com> wrote:
> This, incidentally, also is why running the F17 installer on F19
isn't
> practical.
Well not practical maybe ... impossible no.
In fact making an isolated image using F17 components and installer to
use it to install F18 should work. SB would be an issue though because
the old anaconda does not know anything about it,
I'm fairly sure the new anaconda doesn't know about Secure Boot either.
There's really no reason it would have to. All of that is handled by
shim, grub2, and the kernel.
josh
3:32 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 8, 2012 at 10:30 PM, Josh Boyer <jwboyer(a)gmail.com> wrote:
On Thu, Nov 8, 2012 at 4:08 PM, drago01 <drago01(a)gmail.com>
wrote:
>> This, incidentally, also is why running the F17 installer on F19 isn't
>> practical.
>
> Well not practical maybe ... impossible no.
> In fact making an isolated image using F17 components and installer to
> use it to install F18 should work. SB would be an issue though because
> the old anaconda does not know anything about it,
I'm fairly sure the new anaconda doesn't know about Secure Boot either.
There's really no reason it would have to. All of that is handled by
shim, grub2, and the kernel.
I'd assume it has to know when to install shim and when not? (No idea
have not cheched the code).
3:43 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 8, 2012 at 4:32 PM, drago01 <drago01(a)gmail.com> wrote:
On Thu, Nov 8, 2012 at 10:30 PM, Josh Boyer <jwboyer(a)gmail.com>
wrote:
> On Thu, Nov 8, 2012 at 4:08 PM, drago01 <drago01(a)gmail.com> wrote:
>>> This, incidentally, also is why running the F17 installer on F19 isn't
>>> practical.
>>
>> Well not practical maybe ... impossible no.
>> In fact making an isolated image using F17 components and installer to
>> use it to install F18 should work. SB would be an issue though because
>> the old anaconda does not know anything about it,
>
> I'm fairly sure the new anaconda doesn't know about Secure Boot either.
> There's really no reason it would have to. All of that is handled by
> shim, grub2, and the kernel.
I'd assume it has to know when to install shim and when not? (No idea
have not cheched the code).
Shim is installed on all EFI machines afaik. So anaconda knows about
EFI vs. BIOS perhaps, but not about Secure Boot.
josh
4:50 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 8, 2012 at 10:43 PM, Josh Boyer <jwboyer(a)gmail.com> wrote:
On Thu, Nov 8, 2012 at 4:32 PM, drago01 <drago01(a)gmail.com>
wrote:
> On Thu, Nov 8, 2012 at 10:30 PM, Josh Boyer <jwboyer(a)gmail.com> wrote:
>> On Thu, Nov 8, 2012 at 4:08 PM, drago01 <drago01(a)gmail.com> wrote:
>>>> This, incidentally, also is why running the F17 installer on F19
isn't
>>>> practical.
>>>
>>> Well not practical maybe ... impossible no.
>>> In fact making an isolated image using F17 components and installer to
>>> use it to install F18 should work. SB would be an issue though because
>>> the old anaconda does not know anything about it,
>>
>> I'm fairly sure the new anaconda doesn't know about Secure Boot either.
>> There's really no reason it would have to. All of that is handled by
>> shim, grub2, and the kernel.
>
> I'd assume it has to know when to install shim and when not? (No idea
> have not cheched the code).
Shim is installed on all EFI machines afaik. So anaconda knows about
EFI vs. BIOS perhaps, but not about Secure Boot.
OK.
8:15 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, 2012-11-08 at 15:19 -0500, Bill Nottingham wrote:
Matthew Garrett (mjg59(a)srcf.ucam.org) said:
> Patches that cleanly decouple Anaconda from the entire software stack
> that it runs on top of would probably be received with open arms, but
> nobody who works on it has any idea how to implement them.
In fact, this is what has been done in anaconda over the past couple of
releases - Anaconda migrated from having its own boot and init
infrastructure to using system-provided items such as dracut and systemd.
But that's complicated work, and while you're doing that migration, you're
doing a lot of arbitration as to what bits are in generic dracut, what
bits are in generic systemd, and what bits remain in anaconda. And during
that process, you are *very* tied to the version of the underlying system,
until the work is fully complete and there is a defined separation of
features into each layer.
This, incidentally, also is why running the F17 installer on F19 isn't
practical.
I think this whole subthread took a crazy left turn a ways back and is
_way_ into the weeds by now.
I'd put things more strongly than Bill: what's been happening in
anaconda lately is the precise opposite of what Johann suggests, and
that's exactly the right direction.
We don't want to have an installer stack that's completely independent
of the rest of the distro. I don't think anyone would take patches to do
that, really. We've been trying to do exactly the opposite.
Let's look at the practical examples. anaconda used to have its own
partition inspection code, its own loader stage, and its own network
management code and UI. Over the last few years, all of those have very
deliberately been killed and replaced with bits of the main distro. The
partition stuff was replaced by libparted; the loader was replaced by
dracut; and the network code was replaced by NetworkManager.
Again, this isn't an accident, it's a very deliberate plan. One of the
whole points of the Fedora philosophy is that we're supposed to share
and reuse work and code as much as possible. We're not supposed to write
five independent versions of everything at all. The fact that anaconda
team had to maintain their own loader (which did pretty much what dracut
does), their own partition code (which did pretty much what parted does)
and their own network code (which did pretty much what NetworkManager
does, only not as well) was a problem, not an advantage. It meant we
were duplicating a whole bunch of effort to get inconsistent results.
anaconda team was wasting time maintaining a bunch of network code that
wasn't as good as NetworkManager in the first place (ditto for the other
two examples).
The overall strategy of the anaconda team has been to try and reduce
their maintenance burden; they'd reached a point where they were almost
running full tilt just to stand still - they had so much unique code to
maintain that it took almost all their resources just to keep it working
and up to date. They couldn't work on actually improving anaconda, it
was the best they could do just to keep it at the level it was at.
So they deliberately went out and aimed to reduce that burden, and using
existing code like dracut, NM and parted was just a part of that plan.
newUI is another part of that plan - it's a lot of work now, but the aim
is that it's less of a maintenance burden than the old UI code when it's
done. The ultimate goal is that an anaconda team with the same resources
will be able to devote much less time to just keeping a giant codebase
working, and more time to enhancing a smaller codebase.
So no, our installer absolutely is not independent from the rest of the
distro, it's not intended to be and it shouldn't be. It's deliberately
designed to reuse components of the distribution as much as possible,
and the goal is if anything to increase this over time, not decrease it.
The maintenance burden of adjusting to changes in those components it
depends on is non-zero - which is where we came into this side track -
but that's not a problem. It's non-zero, but it's much lower than
duplicating all those components from scratch, only worse.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:32 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Adam Williamson wrote:
Let's look at the practical examples. anaconda used to have its
own
partition inspection code, its own loader stage, and its own network
management code and UI. Over the last few years, all of those have very
deliberately been killed and replaced with bits of the main distro. The
partition stuff was replaced by libparted; the loader was replaced by
dracut; and the network code was replaced by NetworkManager.
(Don't forget the depsolving, replaced by the yum API.)
As a result, Anaconda's memory usage has skyrocketed over the years. I
remember the days where Anaconda would happily install with 128 MiB RAM, and
where even that was already a lot compared to previous releases. Of course,
some of the increase is due to a larger work set (more packages to install),
but a lot of it is due to changes in Anaconda itself too.
Kevin Kofler
1:43 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, 2012-11-09 at 07:32 +0100, Kevin Kofler wrote:
Adam Williamson wrote:
> Let's look at the practical examples. anaconda used to have its own
> partition inspection code, its own loader stage, and its own network
> management code and UI. Over the last few years, all of those have very
> deliberately been killed and replaced with bits of the main distro. The
> partition stuff was replaced by libparted; the loader was replaced by
> dracut; and the network code was replaced by NetworkManager.
(Don't forget the depsolving, replaced by the yum API.)
As a result, Anaconda's memory usage has skyrocketed over the years. I
remember the days where Anaconda would happily install with 128 MiB RAM, and
where even that was already a lot compared to previous releases. Of course,
some of the increase is due to a larger work set (more packages to install),
but a lot of it is due to changes in Anaconda itself too.
It hasn't really 'skyrocketed'. We cited 512MB for several releases,
bumped it to 768MB for F15/F16 (IIRC), got it back down to 512MB for
F17, and it's back up to 768MB or 1GB for F18 atm because everyone has
more important stuff to do than optimize the RAM usage right now. But
it's not been rising crazily or anything. I think the last time someone
took a deep look at RAM use during install - during F17 cycle when we
got it back down to 512MB - it turned out a lot of the usage happened
during package install and wasn't really to do with anaconda at all.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
4:21 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 2012-11-09, 07:43 GMT, Adam Williamson wrote:
It hasn't really 'skyrocketed'. We cited 512MB for
several releases,
bumped it to 768MB for F15/F16 (IIRC), got it back down to 512MB for
F17, and it's back up to 768MB or 1GB for F18 atm because everyone has
more important stuff to do than optimize the RAM usage right now. But
it's not been rising crazily or anything. I think the last time someone
took a deep look at RAM use during install - during F17 cycle when we
got it back down to 512MB - it turned out a lot of the usage happened
during package install and wasn't really to do with anaconda at all.
I understand and accept that now everybody in the anaconda-land is busy
with something else, but let it not slip our attention how absolutely
crazy it is when the installation program requires twice as much (or
more) of the resources than all programs running on the computer
combined. I have here a server with RHEL-6 which I had to upgrade to
512MB just to be able to install a system on it. Now it has plenty of
free RAM even with some bulky PHP apps (e.g., Zarafa) which is wasted.
With the spread of virtual machines, it seems to be even more obvious.
Wasn’t one of the advantages of VMs the fact that you can slice more
small machines on one computer?
Best,
Matěj
8:30 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, Nov 09, 2012 at 11:21:07AM +0100, Matej Cepl wrote:
On 2012-11-09, 07:43 GMT, Adam Williamson wrote:
> It hasn't really 'skyrocketed'. We cited 512MB for several releases,
> bumped it to 768MB for F15/F16 (IIRC), got it back down to 512MB for
> F17, and it's back up to 768MB or 1GB for F18 atm because everyone has
> more important stuff to do than optimize the RAM usage right now. But
> it's not been rising crazily or anything. I think the last time someone
> took a deep look at RAM use during install - during F17 cycle when we
> got it back down to 512MB - it turned out a lot of the usage happened
> during package install and wasn't really to do with anaconda at all.
I understand and accept that now everybody in the anaconda-land is busy
with something else, but let it not slip our attention how absolutely
crazy it is when the installation program requires twice as much (or
more) of the resources than all programs running on the computer
combined. I have here a server with RHEL-6 which I had to upgrade to
512MB just to be able to install a system on it. Now it has plenty of
free RAM even with some bulky PHP apps (e.g., Zarafa) which is wasted.
With the spread of virtual machines, it seems to be even more obvious.
Wasn’t one of the advantages of VMs the fact that you can slice more
small machines on one computer?
Yes, that is an advantage, but that shouldn't be slicing up one computer in
to multiple very underpowered smaller computers.
Just to cite similar complaints I see from time to time... It irritates me
that people think it's a problem that in 2012 they can't install in a VM
that is allocated with 256M of RAM. Allocate a reasonable amount, start
over. Your host system for multiple VMs in 2012 should not have 1G of
memory.
--
David Cantrell <dcantrell(a)redhat.com>
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
9:15 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, Nov 09, 2012 at 09:30:14AM -0500, David Cantrell wrote:
> Wasn’t one of the advantages of VMs the fact that you can slice
more
> small machines on one computer?
Yes, that is an advantage, but that shouldn't be slicing up one computer in
to multiple very underpowered smaller computers.
Why not? That's incredibly useful.
Just to cite similar complaints I see from time to time... It
irritates me
that people think it's a problem that in 2012 they can't install in a VM
that is allocated with 256M of RAM. Allocate a reasonable amount, start
over. Your host system for multiple VMs in 2012 should not have 1G of
memory.
What about my host system for 500 VMs?
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
10:57 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 07:15 AM, Matthew Miller wrote:
On Fri, Nov 09, 2012 at 09:30:14AM -0500, David Cantrell wrote:
>> Wasn’t one of the advantages of VMs the fact that you can slice more
>> small machines on one computer?
> Yes, that is an advantage, but that shouldn't be slicing up one computer in
> to multiple very underpowered smaller computers.
Why not? That's incredibly useful.
> Just to cite similar complaints I see from time to time... It irritates me
> that people think it's a problem that in 2012 they can't install in a VM
> that is allocated with 256M of RAM. Allocate a reasonable amount, start
> over. Your host system for multiple VMs in 2012 should not have 1G of
> memory.
What about my host system for 500 VMs?
Use elastic allocation. It takes a lot of ram to say "please depsolve
these 40 packages" which turns into "install these 250 (minimal)
packages". So in order to handle that kind of task (once), allocate a
large amount of ram. Once that task is complete, the actual work the
image will be doing may require a lot less ram, so you can scale down
what you allocate to that guest.
--
Jesse Keating
Fedora -- Freedom² is a feature!
12:02 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, Nov 09, 2012 at 08:57:05AM -0800, Jesse Keating wrote:
>>Just to cite similar complaints I see from time to time...
It irritates
>>me that people think it's a problem that in 2012 they can't install in a
>>VM that is allocated with 256M of RAM. Allocate a reasonable amount,
>>start over. Your host system for multiple VMs in 2012 should not have 1G
>>of memory.
>What about my host system for 500 VMs?
Use elastic allocation. It takes a lot of ram to say "please
depsolve these 40 packages" which turns into "install these 250
(minimal) packages". So in order to handle that kind of task
(once), allocate a large amount of ram. Once that task is complete,
the actual work the image will be doing may require a lot less ram,
so you can scale down what you allocate to that guest.
Which is of course what everyone is doing. I was replying to the broader
theme (small VMs are useless) out of context, probably because it was early
in the morning.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
10:33 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 2012-11-09, 14:30 GMT, David Cantrell wrote:
Just to cite similar complaints I see from time to time... It
irritates me that people think it's a problem that in 2012 they can't
install in a VM that is allocated with 256M of RAM. Allocate
a reasonable amount, start over. Your host system for multiple VMs in
2012 should not have 1G of memory.
Does it really irritate you? Those are strong words ... anyway.
I will risk your irritation, anger, maybe even rage (after all, their
impact is limited over IRC) and let me ask:
a) Why installer requires 2-4 times more memory than any other program
running on my computer (and the software you use on it could be a good
example of SOHO server)?
b) What awesome and breathtaking functionality I've got in anaconda
since EL-5 that I have to pay for it with this increase of hardware
requirements? (and let me remind you again about those 500 VMs)
I don't think these question are in any way inappropriate or too
offensive, are they?
Best,
Matěj
11:06 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 08:33 AM, Matej Cepl wrote:
a) Why installer requires 2-4 times more memory than any other
program
running on my computer (and the software you use on it could be a good
example of SOHO server)?
Because anaconda links into a large amount of runtime stuff, that
normally runs isloated and so it /looks/ like our memory usage is
balooned, when in reality the entire system has balooned, we're just
getting the blame.
b) What awesome and breathtaking functionality I've got in
anaconda
since EL-5 that I have to pay for it with this increase of hardware
requirements? (and let me remind you again about those 500 VMs)
I don't think these question are in any way inappropriate or too
offensive, are they?
Hey it's free software. Feel free to take EL5's anaconda code base and
make it work for F19. If it's good enough, maybe you can convince FESCo
to replace anaconda with your project as the official installer for Fedora.
I wish you luck!
--
Jesse Keating
Fedora -- Freedom² is a feature!
1:32 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 2012-11-09, 17:06 GMT, Jesse Keating wrote:
Because anaconda links into a large amount of runtime stuff, that
normally runs isloated and so it /looks/ like our memory usage is
balooned, when in reality the entire system has balooned, we're just
getting the blame.
Right, that looks possible. I still wonder why installer needs MORE
memory than running server with couple of servers, Apache, MySQL, and
some application servers (Zarafa, Status.net, dspam, wordpress)? But
following in this argument would probably require more detailed analysis
than I am willing and able to provide, so let me close this argument
here.
Matěj
1:45 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 11:32 AM, Matej Cepl wrote:
On 2012-11-09, 17:06 GMT, Jesse Keating wrote:
> Because anaconda links into a large amount of runtime stuff, that
> normally runs isloated and so it /looks/ like our memory usage is
> balooned, when in reality the entire system has balooned, we're just
> getting the blame.
Right, that looks possible. I still wonder why installer needs MORE
memory than running server with couple of servers, Apache, MySQL, and
some application servers (Zarafa, Status.net, dspam, wordpress)? But
following in this argument would probably require more detailed analysis
than I am willing and able to provide, so let me close this argument
here.
Matěj
I don't think I'm necessarily disagreeing with you. I don't think
anybody on the Anaconda team is happy with the current memory usage.
That said, we've had very very very little time to pursue fixing this
particular issue.
--
Jesse Keating
Fedora -- Freedom² is a feature!
4:37 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 2012-11-09, 19:45 GMT, Jesse Keating wrote:
I don't think I'm necessarily disagreeing with you. I
don't think
anybody on the Anaconda team is happy with the current memory usage.
That said, we've had very very very little time to pursue fixing this
particular issue.
I said in my first post in this thread that I completely understand that
anaconda team is busy with something more important. Just to make it
clear.
Matěj
11:15 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, Nov 09, 2012 at 05:33:05PM +0100, Matej Cepl wrote:
On 2012-11-09, 14:30 GMT, David Cantrell wrote:
> Just to cite similar complaints I see from time to time... It
> irritates me that people think it's a problem that in 2012 they can't
> install in a VM that is allocated with 256M of RAM. Allocate
> a reasonable amount, start over. Your host system for multiple VMs in
> 2012 should not have 1G of memory.
Does it really irritate you? Those are strong words ... anyway.
I will risk your irritation, anger, maybe even rage (after all, their
impact is limited over IRC) and let me ask:
a) Why installer requires 2-4 times more memory than any other program
running on my computer (and the software you use on it could be a good
example of SOHO server)?
The installer's memory footprint is largely bound by the size of the
package set. So, for example, a yum "upgrade" will take more ram -
because there are effectively twice as many packages involved.
There may be ways to reduce how much of that needs to be kept in ram
at a time, but those are things for yum/rpmlib - they're not anaconda
changes.
b) What awesome and breathtaking functionality I've got in
anaconda
since EL-5 that I have to pay for it with this increase of hardware
requirements? (and let me remind you again about those 500 VMs)
Most of the "increase of hardware requirements" has been related to the
package set, rather than by anaconda getting significantly bigger. There
are some cases where we've grown the install images, and despite your
implication they tend to be directly related to additional
functionality. As a matter of fact, recently we've worked hard to make
the install image and working set of the installer *smaller*.
As for what functionality you've gotten since, say, the last time we had
a major UI change, here's a small sample just off the top of my head:
- BIOS-RAID boot
- encrypted boot
- uefi support on x86
- iscsi boot support
- multipath support
- using NetworkManager
- wireless networking support
- ssh support in the installer
- "kickstart generation" mode
- jlk's new improved non-graphical mode
- 3TB disk support
There's a full(er) list of what our team has been doing here:
http://fedoraproject.org/wiki/Anaconda/Features
I don't think these question are in any way inappropriate or too
offensive, are they?
Actually, yeah, when you question our competence and the utility of what
we're doing, that is a bit offensive.
--
Peter
11:57 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 07:15 PM, Peter Jones wrote:
On Fri, Nov 09, 2012 at 05:33:05PM +0100, Matej Cepl wrote:
> On 2012-11-09, 14:30 GMT, David Cantrell wrote:
>> Just to cite similar complaints I see from time to time... It
>> irritates me that people think it's a problem that in 2012 they can't
>> install in a VM that is allocated with 256M of RAM. Allocate
>> a reasonable amount, start over. Your host system for multiple VMs in
>> 2012 should not have 1G of memory.
>
> Does it really irritate you? Those are strong words ... anyway.
>
> I will risk your irritation, anger, maybe even rage (after all, their
> impact is limited over IRC) and let me ask:
>
> a) Why installer requires 2-4 times more memory than any other program
> running on my computer (and the software you use on it could be a good
> example of SOHO server)?
The installer's memory footprint is largely bound by the size of the
package set. So, for example, a yum "upgrade" will take more ram -
because there are effectively twice as many packages involved.
There may be ways to reduce how much of that needs to be kept in ram
at a time, but those are things for yum/rpmlib - they're not anaconda
changes.
Except that rpm (and yum) use a lot LESS memory these days than they did
in the RHEL-5 era, which I think was used as a comparison here. That's
not where all the memory has gone, quite the contrary.
- Panu -
12:08 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 09:57 AM, Panu Matilainen wrote:
Except that rpm (and yum) use a lot LESS memory these days than they did
in the RHEL-5 era, which I think was used as a comparison here. That's
not where all the memory has gone, quite the contrary.
While that may be true, the amount of ram (free -m) used during an
install *triples* when we get to the desolve and package install phase.
In my most recent test the "used" number went from roughly 550m just
before the packages step to 1645 during.
--
Jesse Keating
Fedora -- Freedom² is a feature!
1:18 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Am 09.11.2012 19:08, schrieb Jesse Keating:
On 11/09/2012 09:57 AM, Panu Matilainen wrote:
>
> Except that rpm (and yum) use a lot LESS memory these days than they did
> in the RHEL-5 era, which I think was used as a comparison here. That's
> not where all the memory has gone, quite the contrary.
While that may be true, the amount of ram (free -m) used during an install *triples* when
we get to the desolve and
package install phase. In my most recent test the "used" number went from
roughly 550m just before the packages
step to 1645 during
NO
i did a lot of yum-upgrades F16->F17 in the last weeks on a lot
of VM's with exactly 512 MB RAM without any single problem
so no, there is no reason anaconda needs more ressources because
all of this machines was full operating while the upgrade was
running (httpd, mysqld, asterisk, hlyfax....)
3:53 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 08:08 PM, Jesse Keating wrote:
On 11/09/2012 09:57 AM, Panu Matilainen wrote:
>
> Except that rpm (and yum) use a lot LESS memory these days than they did
> in the RHEL-5 era, which I think was used as a comparison here. That's
> not where all the memory has gone, quite the contrary.
While that may be true, the amount of ram (free -m) used during an
install *triples* when we get to the desolve and package install phase.
In my most recent test the "used" number went from roughly 550m just
before the packages step to 1645 during.
Hmm, not sure how meaningful the 'free' output is for memory use
(process RSS is what I look at), but that is just way, way, way off. The
depsolve + install stage obviously does need a very non-trivial amount
of memory that anaconda wouldn't have required up to that point, but we
should be talking about a *couple* of hundred megs at most for normal
Fedora install/upgrade cases.
The one testcase I have at hand is a 3103 package install of F16 x86_64
DVD contents into an empty chroot. That's roughly the double the size of
an avegare/default installation, and the memory peak for that set when
installing with rpm is circa 100M resident size (RSS). Yum does add a
fair share of overhead but even if it doubled or tripled the memory use
(its been a while since I last looked and dont remember offhand), its
still nowhere near a gigabyte of additional memory.
Probably the biggest anaconda memory requirement jump I recall around
Fedora 15 had to do with the overall layout changes (moving to one big
initrd or something like that), not the actual anaconda process memory
requirements. That's when I last looked at this and provided patches to
save memory in the package installation area... but perhaps I should
look at it again.
- Panu -
1:20 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 2012-11-09, 17:15 GMT, Peter Jones wrote:
The installer's memory footprint is largely bound by the size of
the
package set. So, for example, a yum "upgrade" will take more ram -
because there are effectively twice as many packages involved.
I see that. Couldn’t be there a way how to somehow overcome this
problem? Just a bit of brainstorming, don’t shoot me too much for being
silly.
a) it could be that anaconda could just provide some kind of profiles
instead of exact selection of individual packages and the lists of
required packages for such profiles could be then precompiled in
advance and provided on the installation medium (and for kickstart
you could precompile it on a separate machine)?
b) installation could be done just from a limited set of packages
(something similar to what we used to have in Fedora Core, for
example) and the final installation of packages would be done
post-installation from the full set?
We do that effectively with LiveCD installations anyway, don’t we?
Well, at least mostly ... certainly people can download additional
packages from Internet. Do users do that or do they typically install
just what’s on CD/USB?
Do people typically do detailed selection of packages (including
obscure ones) in anaconda, or do they do (what I do, so I am biased)
detailed final selection of packages on the already installed
system?
Actually, yeah, when you question our competence and the utility of
what we're doing, that is a bit offensive.
Did I say a word about your competence? I really didn’t mean to do that.
For one, I am quite sure that you are way better programmers than I am,
so I have not much to say about anybody’s competence.
I just wondered (and I still wonder a little, see above) about the
necessity of using 2-4 times more RAM for what me (yes, that could be
part of the problem, I don’t need/use most of the advanced/enterprise
functionality in anaconda) seems like doing exactly the same as before.
From the user’s point of view, it is just cost/benefit ratio ... what
I've got for the cost of increased hardware requirements. But yes, it
could be because I just don’t need advanced functionality. So I was just
trying to get to the bottom of it.
Best,
Matěj
2:31 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
El Fri, 9 Nov 2012 17:33:05 +0100
Matej Cepl <mcepl(a)redhat.com> escribió:
On 2012-11-09, 14:30 GMT, David Cantrell wrote:
> Just to cite similar complaints I see from time to time... It
> irritates me that people think it's a problem that in 2012 they
> can't install in a VM that is allocated with 256M of RAM. Allocate
> a reasonable amount, start over. Your host system for multiple VMs
> in 2012 should not have 1G of memory.
Does it really irritate you? Those are strong words ... anyway.
I will risk your irritation, anger, maybe even rage (after all, their
impact is limited over IRC) and let me ask:
a) Why installer requires 2-4 times more memory than any other
program running on my computer (and the software you use on it could
be a good example of SOHO server)?
My email client uses around 2gb of ram firefox usually is using between
512Mb and 1Gb your statement for me is false.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlChXKcACgkQkSxm47BaWfegdwCgvRcXX2yvWVjcX7Ih7dm5lub/
MUAAn26pii5vJ6UVeR19YPt86BKCwQv6
=IOdA
-----END PGP SIGNATURE-----
2:59 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Once upon a time, Dennis Gilmore <dennis(a)ausil.us> said:
El Fri, 9 Nov 2012 17:33:05 +0100
Matej Cepl <mcepl(a)redhat.com> escribió:
> a) Why installer requires 2-4 times more memory than any other
> program running on my computer (and the software you use on it could
> be a good example of SOHO server)?
My email client uses around 2gb of ram firefox usually is using between
512Mb and 1Gb your statement for me is false.
Read the message, especially "SOHO server". Most people are not running
email clients and Firefox on servers.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
9:19 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 2012-11-12 12:59, Chris Adams wrote:
Once upon a time, Dennis Gilmore <dennis(a)ausil.us> said:
> El Fri, 9 Nov 2012 17:33:05 +0100
> Matej Cepl <mcepl(a)redhat.com> escribió:
> > a) Why installer requires 2-4 times more memory than any other
> > program running on my computer (and the software you use on it
> could
> > be a good example of SOHO server)?
>
> My email client uses around 2gb of ram firefox usually is using
> between
> 512Mb and 1Gb your statement for me is false.
Read the message, especially "SOHO server". Most people are not
running
email clients and Firefox on servers.
That doesn't make it a sensible argument or target. My IRC proxy VM
sits there using about 20MB of RAM. That's a perfectly useful
installation of Fedora. So should our target be to fit our sophisticated
graphical installer in 20MB of RAM, something it hasn't managed for at
least a decade? Really?
This thread continues to get more absurd. Everyone agrees it would be
good to make the installer as efficient as possible. It is open source
code. Check it out from git and go to work. Patches to
anaconda-devel-list. The anaconda team is aware that memory usage could
be optimized; however, you may have noticed they're a _tad_ busy with
other things too. Is there anything more to say in this thread? Given
that no silly usage / historical comparisons anyone can make are going
to magically result in a halving of the RAM use of the installer?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
10:47 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Mon, 2012-11-12 at 19:19 -0800, Adam Williamson wrote:
This thread continues to get more absurd. Everyone agrees it would be
good to make the installer as efficient as possible. It is open source
code. Check it out from git and go to work. Patches to
anaconda-devel-list. The anaconda team is aware that memory usage could
be optimized; however, you may have noticed they're a _tad_ busy with
other things too. Is there anything more to say in this thread? Given
that no silly usage / historical comparisons anyone can make are going
to magically result in a halving of the RAM use of the installer?
One more thing Adam, is that people just need to *chill out*, continue
to help test and find bugs as much as possible *before* the final
release, to help make it as pleasant as possible when it does go Gold.
Who the hell cares if it slips a little or we take a tad longer to fix
something up cause it's a major deal? Not like we can't run it *now* as
is and use it currently as we wait. If you can't handle things as done
now, go find something else more stable, or just use gold releases and
don't worry bout testing and dealing with stuff. Wait for official
releases and quit complaining about this or that. Hell this stuff is
all free, why the hell am I gonna complain?
SMH...Just my $.02, am done. Ok more coffee now :)
--
Mike Chambers
Madisonville, KY
"Best little town on Earth!"
4:41 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, Nov 09, 2012 at 09:30:14AM -0500, David Cantrell wrote:
On Fri, Nov 09, 2012 at 11:21:07AM +0100, Matej Cepl wrote:
> On 2012-11-09, 07:43 GMT, Adam Williamson wrote:
> > It hasn't really 'skyrocketed'. We cited 512MB for several
releases,
> > bumped it to 768MB for F15/F16 (IIRC), got it back down to 512MB for
> > F17, and it's back up to 768MB or 1GB for F18 atm because everyone has
> > more important stuff to do than optimize the RAM usage right now. But
> > it's not been rising crazily or anything. I think the last time someone
> > took a deep look at RAM use during install - during F17 cycle when we
> > got it back down to 512MB - it turned out a lot of the usage happened
> > during package install and wasn't really to do with anaconda at all.
>
> I understand and accept that now everybody in the anaconda-land is busy
> with something else, but let it not slip our attention how absolutely
> crazy it is when the installation program requires twice as much (or
> more) of the resources than all programs running on the computer
> combined. I have here a server with RHEL-6 which I had to upgrade to
> 512MB just to be able to install a system on it. Now it has plenty of
> free RAM even with some bulky PHP apps (e.g., Zarafa) which is wasted.
> With the spread of virtual machines, it seems to be even more obvious.
> Wasn’t one of the advantages of VMs the fact that you can slice more
> small machines on one computer?
Yes, that is an advantage, but that shouldn't be slicing up one computer in
to multiple very underpowered smaller computers.
Just to cite similar complaints I see from time to time... It irritates me
that people think it's a problem that in 2012 they can't install in a VM
that is allocated with 256M of RAM. Allocate a reasonable amount, start
over. Your host system for multiple VMs in 2012 should not have 1G of
memory.
You're very wrong here. Memory is *the* key limiting resource for
VMs, particularly when people want to pack as many VMs into a system
as possible. If the minimum required for an OS goes from 256 -> 512MB,
then the number of VMs that can be run per host (more than) halves.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
4:57 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Sat, Nov 10, 2012 at 11:41 AM, Richard W.M. Jones <rjones(a)redhat.com> wrote:
On Fri, Nov 09, 2012 at 09:30:14AM -0500, David Cantrell wrote:
> On Fri, Nov 09, 2012 at 11:21:07AM +0100, Matej Cepl wrote:
> > On 2012-11-09, 07:43 GMT, Adam Williamson wrote:
> > > It hasn't really 'skyrocketed'. We cited 512MB for several
releases,
> > > bumped it to 768MB for F15/F16 (IIRC), got it back down to 512MB for
> > > F17, and it's back up to 768MB or 1GB for F18 atm because everyone has
> > > more important stuff to do than optimize the RAM usage right now. But
> > > it's not been rising crazily or anything. I think the last time
someone
> > > took a deep look at RAM use during install - during F17 cycle when we
> > > got it back down to 512MB - it turned out a lot of the usage happened
> > > during package install and wasn't really to do with anaconda at all.
> >
> > I understand and accept that now everybody in the anaconda-land is busy
> > with something else, but let it not slip our attention how absolutely
> > crazy it is when the installation program requires twice as much (or
> > more) of the resources than all programs running on the computer
> > combined. I have here a server with RHEL-6 which I had to upgrade to
> > 512MB just to be able to install a system on it. Now it has plenty of
> > free RAM even with some bulky PHP apps (e.g., Zarafa) which is wasted.
> > With the spread of virtual machines, it seems to be even more obvious.
> > Wasn’t one of the advantages of VMs the fact that you can slice more
> > small machines on one computer?
>
> Yes, that is an advantage, but that shouldn't be slicing up one computer in
> to multiple very underpowered smaller computers.
>
> Just to cite similar complaints I see from time to time... It irritates me
> that people think it's a problem that in 2012 they can't install in a VM
> that is allocated with 256M of RAM. Allocate a reasonable amount, start
> over. Your host system for multiple VMs in 2012 should not have 1G of
> memory.
You're very wrong here. Memory is *the* key limiting resource for
VMs, particularly when people want to pack as many VMs into a system
as possible. If the minimum required for an OS goes from 256 -> 512MB,
then the number of VMs that can be run per host (more than) halves.
Yeah but the amount of memory needed for installation is hardly
relevant here .. you install once (with a higher memory allocation)
and scale down afterwards.
And once you have a working image you can reuse it for other installations.
So the VMs are not really much of an issue here.
6:11 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Am 10.11.2012 11:57, schrieb drago01:
Yeah but the amount of memory needed for installation is hardly
relevant here .. you install once (with a higher memory allocation)
and scale down afterwards.
yeah this works for you and me me
the average user will say "WTF, throw away this crap" and take ubuntu
that is the real life which happens if previous working things are
replaced without care
but hey, some mistakes in F15/F16/F17 may lead that Fedora loses
the "noob users" and after that it could be considered satisfy
power users more again and reduce the "do it the windows way"
2:41 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Le Sam 10 novembre 2012 11:57, drago01 a écrit :
Yeah but the amount of memory needed for installation is hardly
relevant here .. you install once (with a higher memory allocation)
and scale down afterwards.
Does not work with organisations that charge projects their top vm
resource use (yes they exist)
--
Nicolas Mailhot
4:11 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Sat, Nov 10, 2012 at 2:41 AM, Richard W.M. Jones <rjones(a)redhat.com> wrote:
[snip]
You're very wrong here. Memory is *the* key limiting resource
for
VMs, particularly when people want to pack as many VMs into a system
as possible. If the minimum required for an OS goes from 256 -> 512MB,
then the number of VMs that can be run per host (more than) halves.
Rich.
It's worse than that - you generally only have *half* of your host's
RAM to give to all the guests. Any more and all kinds of Heck breaks
loose on a desktop.
--
Twitter: http://twitter.com/znmeb; Computational Journalism Publishers
Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/
How the Hell can the lion sleep with all those people singing "A weem
oh way!" at the top of their lungs?
11:33 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, 2012-11-09 at 11:21 +0100, Matej Cepl wrote:
On 2012-11-09, 07:43 GMT, Adam Williamson wrote:
> It hasn't really 'skyrocketed'. We cited 512MB for several releases,
> bumped it to 768MB for F15/F16 (IIRC), got it back down to 512MB for
> F17, and it's back up to 768MB or 1GB for F18 atm because everyone has
> more important stuff to do than optimize the RAM usage right now. But
> it's not been rising crazily or anything. I think the last time someone
> took a deep look at RAM use during install - during F17 cycle when we
> got it back down to 512MB - it turned out a lot of the usage happened
> during package install and wasn't really to do with anaconda at all.
I understand and accept that now everybody in the anaconda-land is busy
with something else, but let it not slip our attention how absolutely
crazy it is when the installation program requires twice as much (or
more) of the resources than all programs running on the computer
combined. I have here a server with RHEL-6 which I had to upgrade to
512MB just to be able to install a system on it. Now it has plenty of
free RAM even with some bulky PHP apps (e.g., Zarafa) which is wasted.
With the spread of virtual machines, it seems to be even more obvious.
Wasn’t one of the advantages of VMs the fact that you can slice more
small machines on one computer?
If you're doing that, it's pretty trivial to use pre-built images.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
5:52 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Adam Williamson wrote:
It hasn't really 'skyrocketed'. We cited 512MB for
several releases,
bumped it to 768MB for F15/F16 (IIRC), got it back down to 512MB for
F17, and it's back up to 768MB or 1GB for F18 atm because everyone has
more important stuff to do than optimize the RAM usage right now. But
it's not been rising crazily or anything.
These were the numbers for RHL 9:
http://www.gurulabs.com/downloads/RELEASE-NOTES-RHL9.html
| Memory:
| - Minimum for text-mode: 64MB
| - Minimum for graphical: 128MB
| - Recommended for graphical: 192MB
So, since Fedora has existed, Anaconda's memory requirements have increased
by at least an order of magnitude! How's that NOT "skyrocketing"?
Kevin Kofler
6:30 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Sat, 2012-11-10 at 00:52 +0100, Kevin Kofler wrote:
Adam Williamson wrote:
> It hasn't really 'skyrocketed'. We cited 512MB for several releases,
> bumped it to 768MB for F15/F16 (IIRC), got it back down to 512MB for
> F17, and it's back up to 768MB or 1GB for F18 atm because everyone has
> more important stuff to do than optimize the RAM usage right now. But
> it's not been rising crazily or anything.
These were the numbers for RHL 9:
http://www.gurulabs.com/downloads/RELEASE-NOTES-RHL9.html
| Memory:
| - Minimum for text-mode: 64MB
| - Minimum for graphical: 128MB
| - Recommended for graphical: 192MB
So, since Fedora has existed, Anaconda's memory requirements have increased
by at least an order of magnitude! How's that NOT "skyrocketing"?
RHL 9 came out in 2003. That's *nine years ago*. In 2003, an expensive
system from Dell - cost price UKP 1314, that's nearly $2k in U.S. money
- came with 512MB of RAM.
http://www.trustedreviews.com/Dell-Dimension-8300-3-0GHz-Ultimate-Christm...
A U.S. model with 1GB of RAM cost $3,600:
http://www.pcmag.com/article2/0,2817,1135791,00.asp
I can't find any reviews of more modest configs on the front page of
Google, but it seems reasonable to assume a 'typical' system shipped in
2003 would've had maybe 256MB-512MB of RAM.
The most expensive stock config I can find from Dell today - comparable
to the two systems listed above - is
http://configure.us.dell.com/dellstore/config.aspx?oc=dddapy1&model_i...
(interestingly, model 8500 - has Dell had a single model line all this time?), which costs
$1050 - half as much as the 2003 system, not even adjusted for inflation - and comes with
24GB of RAM. That's 48 times as much, for those keeping score at home. That blows our
measly 5-or-7 times increase in RAM requirements out of the water. We appear to be
effectively reducing our memory requirements over time, considered as a percentage of the
typical RAM allocation of an off-the-shelf system.
Even a more modest 'typical' Dell desktop -
https://www.dell.com/us/p/inspiron-660/pd - comes with 6GB at the most
basic configuration (comparable to 256MB for a 2003 basic desktop, I'd
guess - so a 24x ratio), or 8GB (32x ratio) at a moderate config (only
$599).
You're being pretty absurd comparing 2003 requirements to 2012
requirements without allowing at all for hardware inflation.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
7:49 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Adam Williamson wrote:
You're being pretty absurd comparing 2003 requirements to 2012
requirements without allowing at all for hardware inflation.
People thinking like you are the reason why entire villages in China and
Africa are huge heavily-polluted landfills of electronic scrap material.
Kevin Kofler
8:01 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Sat, 2012-11-10 at 02:49 +0100, Kevin Kofler wrote:
Adam Williamson wrote:
> You're being pretty absurd comparing 2003 requirements to 2012
> requirements without allowing at all for hardware inflation.
People thinking like you are the reason why entire villages in China and
Africa are huge heavily-polluted landfills of electronic scrap material.
That's so stupid it barely merits a response. But I'll humour you.
We improve the ability of our hardware so we can improve the ability of
our software. When designing modern software it does not make sense to
design to the capabilities of a Commodore PET. A PC from nine years ago
really is not a terribly different case.
We are not designing an OS to be used to extend the life of ancient
hardware for re-use in the developing world. That is a fine goal, but it
is not really Fedora's goal. Our goal includes Features and First - i.e.
we are pushing the envelope of what is possible. In doing this it is
clearly appropriate to target the capabilities of contemporary hardware,
not hardware built before George W. Bush's second term in office began.
Modern software does not use more resources than old software because
it's 'bloated' or because modern coders are lazy. It just uses the
greater resources available to do better stuff. This is why hardware
engineers work to make more resources available in the _first_ place. We
could now list all the capabilities of modern code that code from 2003
didn't have, but I really, really don't see the point.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
10:52 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/10/2012 02:01 AM, Adam Williamson wrote:
On Sat, 2012-11-10 at 02:49 +0100, Kevin Kofler wrote:
> Adam Williamson wrote:
>> You're being pretty absurd comparing 2003 requirements to 2012
>> requirements without allowing at all for hardware inflation.
> People thinking like you are the reason why entire villages in China and
> Africa are huge heavily-polluted landfills of electronic scrap material.
Kevin manufactures today don't built hardware to last more then 3 years
tops and actually the industry is moving towards to make them unfixable
as well
( cheaper to jus throw it away and give you a new one )
I think Germany is actually the only country that holds high standards
in that regards
( as in requiring manufactures to build appliance that lasts )
That's so stupid it barely merits a response. But I'll humour
you.
We improve the ability of our hardware so we can improve the ability of
our software. When designing modern software it does not make sense to
design to the capabilities of a Commodore PET. A PC from nine years ago
really is not a terribly different case.
We are not designing an OS to be used to extend the life of ancient
hardware for re-use in the developing world. That is a fine goal, but it
is not really Fedora's goal. Our goal includes Features and First - i.e.
we are pushing the envelope of what is possible. In doing this it is
clearly appropriate to target the capabilities of contemporary hardware,
not hardware built before George W. Bush's second term in office began.
Modern software does not use more resources than old software because
it's 'bloated' or because modern coders are lazy. It just uses the
greater resources available to do better stuff. This is why hardware
engineers work to make more resources available in the _first_ place. We
could now list all the capabilities of modern code that code from 2003
didn't have, but I really, really don't see the point.
Adam You seem to be failing to realize we have gone full circle now ;)
( think arm devices )
JBG
12:42 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Jóhann B. Guðmundsson wrote:
Kevin manufactures today don't built hardware to last more then 3
years
tops and actually the industry is moving towards to make them unfixable
as well
( cheaper to jus throw it away and give you a new one )
I think Germany is actually the only country that holds high standards
in that regards
( as in requiring manufactures to build appliance that lasts )
My main computer is from 2003 and still works fine. My notebook from 2008
obviously also still works (and I intend to use it until at least 2018 if it
keeps working), and in fact even my old laptop from 1998 still technically
works, too, I just stopped using it, and the evergrowing memory requirements
of software have a lot to do with that (as does the lack of care given to
drivers like s3virge).
Kevin Kofler
12:39 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Adam Williamson wrote:
On Sat, 2012-11-10 at 02:49 +0100, Kevin Kofler wrote:
> Adam Williamson wrote:
> > You're being pretty absurd comparing 2003 requirements to 2012
> > requirements without allowing at all for hardware inflation.
>
> People thinking like you are the reason why entire villages in China and
> Africa are huge heavily-polluted landfills of electronic scrap material.
That's so stupid it barely merits a response. But I'll humour you.
How's it stupid? A computer can easily last a decade or more. The computer
I'm typing this message on is from 2003. Why should we have to replace our
hardware every few months?
And I didn't invent or exaggerate the story about the villages in China and
Africa either. I've seen several documentaries about it on TV. Just use a
search engine and I'm sure you'll find articles on the Internet about the
problem.
We improve the ability of our hardware so we can improve the ability
of
our software. When designing modern software it does not make sense to
design to the capabilities of a Commodore PET. A PC from nine years ago
really is not a terribly different case.
You need to care about older hardware if you want to reduce the pollution of
our environment and the plundering of our planet's resources (copper,
aluminium, gold, rare metals etc.). "This is last year's hardware, just
throw it away" just doesn't cut it.
We are not designing an OS to be used to extend the life of ancient
hardware for re-use in the developing world. That is a fine goal, but it
is not really Fedora's goal. Our goal includes Features and First - i.e.
we are pushing the envelope of what is possible.
This is not only about the developing world! Most of the scrap in those
landfill villages in China and Africa originates from the so-called
"developed" world, i.e. Europe and North America! WE need to stop replacing
our hardware for no reason every couple years!
In doing this it is clearly appropriate to target the capabilities
of
contemporary hardware, not hardware built before George W. Bush's second
term in office began.
And I respectfully disagree, for both ecologic and economic reasons.
Modern software does not use more resources than old software
because
it's 'bloated' or because modern coders are lazy. It just uses the
greater resources available to do better stuff. This is why hardware
engineers work to make more resources available in the _first_ place. We
could now list all the capabilities of modern code that code from 2003
didn't have, but I really, really don't see the point.
I fail to see those capabilities in the case of Anaconda, or more precisely,
I don't see it having anywhere near 10 times the features it had in 2003!
Kevin Kofler
10:22 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/10/2012 01:30 AM, Adam Williamson wrote:
On Sat, 2012-11-10 at 00:52 +0100, Kevin Kofler wrote:
> Adam Williamson wrote:
> So, since Fedora has existed, Anaconda's memory requirements
have increased
> by at least an order of magnitude! How's that NOT "skyrocketing"?
You're being pretty absurd comparing 2003 requirements to 2012
requirements without allowing at all for hardware inflation.
You seem to be missing the increasing amount of aging netbooks, laptops
and tablets.
Also you seem to be ignoring the fact of Windows XP being about to be
discontinued, for which at least some users will be looking for a
substitute OS, when they realize Win 8's HW requirements are too
demanding for their HW or when they realize Win 8 doesn't meet their
personal needs.
Some of them certainly will consider switching to Linux, but will it be
Fedora? Provided this discussion, my guess is no.
Ralf
10:36 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Sat, 2012-11-10 at 05:22 +0100, Ralf Corsepius wrote:
On 11/10/2012 01:30 AM, Adam Williamson wrote:
> On Sat, 2012-11-10 at 00:52 +0100, Kevin Kofler wrote:
>> Adam Williamson wrote:
>> So, since Fedora has existed, Anaconda's memory requirements have increased
>> by at least an order of magnitude! How's that NOT "skyrocketing"?
> You're being pretty absurd comparing 2003 requirements to 2012
> requirements without allowing at all for hardware inflation.
You seem to be missing the increasing amount of aging netbooks, laptops
and tablets.
Also you seem to be ignoring the fact of Windows XP being about to be
discontinued, for which at least some users will be looking for a
substitute OS, when they realize Win 8's HW requirements are too
demanding for their HW or when they realize Win 8 doesn't meet their
personal needs.
Some of them certainly will consider switching to Linux, but will it be
Fedora? Provided this discussion, my guess is no.
Look, I like a good argument as much as anyone else, but this is
ludicrous. Are you just replying to me for the sake of scoring a point?
Or are you seriously suggesting that a sensible direction for Fedora is
to consider the requirements of nine year old hardware and attempt to
adjust our software to match? Is this really what you would like us to
do, or are you just compulsively contradicting whatever you can? Because
I'm not interested in a back and forth point scoring match.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
11:40 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/10/2012 05:36 AM, Adam Williamson wrote:
On Sat, 2012-11-10 at 05:22 +0100, Ralf Corsepius wrote:
> On 11/10/2012 01:30 AM, Adam Williamson wrote:
>> On Sat, 2012-11-10 at 00:52 +0100, Kevin Kofler wrote:
>>> Adam Williamson wrote:
>
>>> So, since Fedora has existed, Anaconda's memory requirements have
increased
>>> by at least an order of magnitude! How's that NOT
"skyrocketing"?
>
>> You're being pretty absurd comparing 2003 requirements to 2012
>> requirements without allowing at all for hardware inflation.
>
> You seem to be missing the increasing amount of aging netbooks, laptops
> and tablets.
>
> Also you seem to be ignoring the fact of Windows XP being about to be
> discontinued, for which at least some users will be looking for a
> substitute OS, when they realize Win 8's HW requirements are too
> demanding for their HW or when they realize Win 8 doesn't meet their
> personal needs.
>
> Some of them certainly will consider switching to Linux, but will it be
> Fedora? Provided this discussion, my guess is no.
Look, I like a good argument as much as anyone else, but this is
ludicrous. Are you just replying to me for the sake of scoring a point?
No. I feel
Fedora is going down the drain, with the installer's demands
and Fedora's upgrade mechanisms being a major factor contributing to this.
Or are you seriously suggesting that a sensible direction for Fedora
is
to consider the requirements of nine year old hardware and attempt to
adjust our software to match?
No.
I am pointing out that what you are calling "9 year old" hardware is not
unlike the hardware to be found on 4-2 year old netbooks/laptops/tablets
etc. and consider ignoring this hardware to be a mistake.
I am also pointing out, that there is a larger group of potential future
Linux users out there (Win XP users), to whom Fedora has not much to offer.
Is this really what you would like us to
do, or are you just compulsively contradicting whatever you can?
Neither. I am
simply deeply convinced that one of Linux traditional
domains and key feature had been "not being as resource demanding" as
competing OSes and that loosing it "just because that's the way it is"
is a severe long term mistake.
Ralf
11:50 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Sat, 2012-11-10 at 06:40 +0100, Ralf Corsepius wrote:
> Is this really what you would like us to
> do, or are you just compulsively contradicting whatever you can?
Neither. I am simply deeply convinced that one of Linux traditional
domains and key feature had been "not being as resource demanding" as
competing OSes and that loosing it "just because that's the way it is"
is a severe long term mistake.
It's a good thing that I didn't actually suggest that then, isn't it?
Linux still performs far better than Windows on low resource machines.
The fact that all hardware marches on over time doesn't change that. I'm
running four server boxes on a VM host which has 4GB of RAM. I used to
fit them in 1.5GB, and still could if I had to. I wouldn't want to try
that with Windows.
I'm not saying we should just design to whatever the latest Alienware
state of the art box is. All I said was that Kevin was taking things to
extremes by citing the requirements of a nine year old release. Unless
you think Kevin's post was a perfectly sensible one and I was wrong to
call BS on it...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
11:58 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Sat, 2012-11-10 at 06:40 +0100, Ralf Corsepius wrote:
I am pointing out that what you are calling "9 year old"
hardware is not
unlike the hardware to be found on 4-2 year old netbooks/laptops/tablets
etc. and consider ignoring this hardware to be a mistake.
BTW, for the factual record, only the very first generation of the very
first netbook ever created - the Eee 700-701 - had 512MB of RAM. The 702
G and then the 900 series onwards all had 1GB of RAM or more. So our
current, completely unoptimized, 'bloated' anaconda in a pre-Beta build
can safely and happily install on every extant netbook except the very
first, famously underpowered generation. Our current stable release can
install on any netbook ever shipped.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
2:21 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
* Adam Williamson [10/11/2012 08:36] :
BTW, for the factual record, only the very first generation of the very
first netbook ever created - the Eee 700-701 - had 512MB of RAM.
Not even that. I have an Eee701 and I replaced the 512MB stick
of RAM with a 2GB one a while ago.
Emmanuel
12:17 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Sat, 2012-11-10 at 06:40 +0100, Ralf Corsepius wrote:
> Look, I like a good argument as much as anyone else, but this
is
> ludicrous. Are you just replying to me for the sake of scoring a point?
No. I feel Fedora is going down the drain, with the installer's
demands
and Fedora's upgrade mechanisms being a major factor contributing to this.
BTW, here's an interesting note on the '9 years' angle.
So we know a mid-high end system in 2003 had 512MB of RAM. We know that
RHL in 2003 required 128MB of RAM for graphical installation. Right now
- 9 years later - we know that our current stable Fedora requires 512MB;
in other words, it can still install to that mid-high end system from
2003 (a Pentium 4 with 512MB of RAM) and probably run fine, using say
LXDE.
Now let's rewind time to 2003. Our current stable Red Hat Linux release,
RHL 9, requires 128MB of RAM for graphical installation. Can it install
on a mid-high end system from 9 years ago, 1994?
It's a bit hard to find references, but a post at
http://www.quartertothree.com/game-talk/showthread.php?t=11638 suggests
the following specs for a 'Midrange 1994' system:
40MHz Intel 486DX2
8MB RAM (whatever type was used back then)
500MB hard drive
1MB SVGA-capable graphics card
3.5" floppy drive (although I'll probably cheat and add a CD-ROM drive)
Windows 3.11
That more or less accords with my memory. I recall that when Doom came
out, which was in 1993, my father had recently purchased a very high-end
system, which was a 33MHz 486DX with a whopping 16MB of RAM; I'm fairly
sure I recall that a more standard config at that time was 4MB. So let's
be generous and say that a mid-high end config in 1994 was 16MB of RAM.
So could our 2003 stable release, Red Hat Linux 9, install on a system
from nine years previously? It could not. It required eight times more
memory than a nine year old system had.
So right now, we are doing substantially *better* at supporting old
systems than we were in 2003.
How's that?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:56 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, 2012-11-09 at 22:17 -0800, Adam Williamson wrote:
So right now, we are doing substantially *better* at supporting old
systems than we were in 2003.
Oh, god, I'm pulling a Kevin with this list spamming, but this is just
too glorious not to post. I couldn't resist taking a trip in the wayback
machine. Here we are in Fedoraland, 2003:
https://lists.fedoraproject.org/pipermail/devel/2003-December . What do
we find?
Well, we find someone complaining that everything's just too bloated:
https://lists.fedoraproject.org/pipermail/devel/2003-December/047891.html
"curious that 3 of these 4 things have to do with reducing code
footprint. I guess you can infer that either I have too much old
hardware, or bloat has become an issue, or I suppose that I'm just
totally off-base here"
This provokes a huge thread which goes firing off in all sorts of
directions, during which people including Seth Vidal and Jesse Keating
have a passionate debate about exactly what ought to be included in a
minimal install:
https://lists.fedoraproject.org/pipermail/devel/2003-December/048318.html
"Ah but the barebones system won't include yum. The absolute must
include stuff will be a command line rpm capable of installing rpms
from a CD or such. Barebones means barebones."
The same thread - such a damn goldmine! - also features a debate about
whether we really want to support all these pesky legacy systems with
386 CPUs. Bill Nottingham seems to have been firmly on my side all these
years:
https://lists.fedoraproject.org/pipermail/devel/2003-December/047967.html
"I'm not sure that scaling back the requirements that much is something
that fits the model of always moving forward with new technology."
And - diving back in the thread, but I saved the very best for last -
someone complaining about how damn bloated our memory requirements have
gotten, and why can't they install on their perfectly good old hardware:
https://lists.fedoraproject.org/pipermail/devel/2003-December/047907.html
"Why must I waste min 64 megs ram on an old gateway box, I like the idea
of able to bare bones install on 32 megs ram or less, i have a 486 gw
box ran for years, no need to upgrade it for what it does, still runs a
VERY ancient version of RH because it has 8 megs ram and nothing since
rh6 will install, to put a modern OS on it i could put slackware, but
why slackware, when RH should do this as it used to, a text install
should use SFA as it doesnt need gui.."
Well, you know, it's all about memory usage in the package installation
process, as Seth points out:
https://lists.fedoraproject.org/pipermail/devel/2003-December/048089.html
Meanwhile, our trusty European punctuation-less shit-stirrer (sound
familiar, anyone?) is still saying we suck if we can't support minimal
memory installs, and we should be better than 'winbloze':
https://lists.fedoraproject.org/pipermail/devel/2003-December/048553.html
"But what about the main point in question, if we can do it with upto
RH6, we can do it now with current slackware, so why cant we do a basic
text install in fedora with piddly amount of ram, I mean, this is linux
afterall, not winbloze :)"
And someone is making Kevin's argument, although not accusing anyone of
being the cause of environmental devastation in China:
https://lists.fedoraproject.org/pipermail/devel/2003-December/047977.html
"Moving technology forward doesn't HAVE to mean being in a race with
memory, cpu, and disk producing companies. We want to scale small
as well as large, and I'm not strictly opposed to making this
available if we can figure out how to do it without making life
significantly harder for us."
Justin Forbes - Justin! - is around, and being as forward thinking as
usual:
https://lists.fedoraproject.org/pipermail/devel/2003-December/047892.html
"Concurrent FC2 releases for x86_64 and i386."
Fedora: plus ca change, plus c'est la meme fucking chose. And the same
people, even.
Truly, Ralf, Fedora is "going down the drain".
This is gonna keep me amused for the next week easy. :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:59 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Adam Williamson wrote:
Oh, god, I'm pulling a Kevin with this list spamming, but this is
just
too glorious not to post. I couldn't resist taking a trip in the wayback
machine. Here we are in Fedoraland, 2003:
https://lists.fedoraproject.org/pipermail/devel/2003-December . What do
we find?
This just proves my point: Creeping biggerism has been a problem for many
years, and by its cumulative nature, the longer it goes on, the worse a
problem it is!
Kevin Kofler
1:03 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Sat, 10 Nov 2012 19:59:22 +0100
Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Adam Williamson wrote:
> Oh, god, I'm pulling a Kevin with this list spamming, but this is
> just too glorious not to post. I couldn't resist taking a trip in
> the wayback machine. Here we are in Fedoraland, 2003:
> https://lists.fedoraproject.org/pipermail/devel/2003-December .
> What do we find?
This just proves my point: Creeping biggerism has been a problem for
many years, and by its cumulative nature, the longer it goes on, the
worse a problem it is!
I think most folks eyes have glazed over at this point.
Can we drop this thread now?
If you have a concrete proposal to put forward, write it up.
If you have actual measurements for memory use or concrete ways to
reduce it, please let us know.
(this is the general "you" or "all of yall" (if in texas) not just
Kevin).
kevin
3:19 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Oh by the way:
Adam Williamson wrote:
Meanwhile, our trusty European punctuation-less shit-stirrer (sound
familiar, anyone?) is still saying we suck if we can't support minimal
memory installs, and we should be better than 'winbloze':
https://lists.fedoraproject.org/pipermail/devel/2003-December/048553.html
Since when is it acceptable on this list to direct ad-hominem attacks
against an entire continent?
Kevin Kofler
5:15 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Dne 18/11/12 22:19, Kevin Kofler napsal(a):
> Meanwhile, our trusty European punctuation-less shit-stirrer
(sound
> familiar, anyone?) is still saying we suck if we can't support minimal
> memory installs, and we should be better than 'winbloze':
>
> https://lists.fedoraproject.org/pipermail/devel/2003-December/048553.html
Since when is it acceptable on this list to direct ad-hominem attacks
against an entire continent?
I don't think you read it correctly ... its European as an adjective
characterizing one human being living on our continent, not the
continent as whole (or all its inhabitants).
Matěj
5:43 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Matej Cepl wrote:
Dne 18/11/12 22:19, Kevin Kofler napsal(a):
>> Meanwhile, our trusty European punctuation-less shit-stirrer (sound
>> familiar, anyone?) is still saying we suck if we can't support minimal
>> memory installs, and we should be better than 'winbloze':
>>
>> https://lists.fedoraproject.org/pipermail/devel/2003-
December/048553.html
>
> Since when is it acceptable on this list to direct ad-hominem attacks
> against an entire continent?
I don't think you read it correctly ... its European as an adjective
characterizing one human being living on our continent, not the
continent as whole (or all its inhabitants).
The context (e.g. the fact that the author of the Dec 2003 message is not
involved in the current discussion at all) clearly implies that being
European is somehow related to being a "punctuation-less shit-stirrer", an
association I object to!
Kevin Kofler
6:29 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Mon, 2012-11-19 at 00:43 +0100, Kevin Kofler wrote:
Matej Cepl wrote:
> Dne 18/11/12 22:19, Kevin Kofler napsal(a):
>>> Meanwhile, our trusty European punctuation-less shit-stirrer (sound
>>> familiar, anyone?) is still saying we suck if we can't support minimal
>>> memory installs, and we should be better than 'winbloze':
>>>
>>> https://lists.fedoraproject.org/pipermail/devel/2003-
December/048553.html
>>
>> Since when is it acceptable on this list to direct ad-hominem attacks
>> against an entire continent?
>
> I don't think you read it correctly ... its European as an adjective
> characterizing one human being living on our continent, not the
> continent as whole (or all its inhabitants).
The context (e.g. the fact that the author of the Dec 2003 message is not
involved in the current discussion at all) clearly implies that being
European is somehow related to being a "punctuation-less shit-stirrer", an
association I object to!
No, Matej has it right. I was perhaps unsubtly suggesting that one of
the many parallels between the situation circa 2003 and the situation
circa 2012 appeared to be that, at both times, there was a person on the
list who had a tendency to post needlessly controversial stuff, without
much punctuation, who happened to be European...
(btw, though people seem to keep forgetting, *I'm* European. And Harald,
I don't live in the U.S.)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
11:36 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/18/2012 04:19 PM, Kevin Kofler wrote:
Oh by the way:
Adam Williamson wrote:
> Meanwhile, our trusty European punctuation-less shit-stirrer (sound
> familiar, anyone?) is still saying we suck if we can't support minimal
> memory installs, and we should be better than 'winbloze':
>
> https://lists.fedoraproject.org/pipermail/devel/2003-December/048553.html
Since when is it acceptable on this list to direct ad-hominem attacks
against an entire continent?
You can call me a prude if you want, but I would have chosen the wording
differently, even though I didn't read Adam's words as offensive.
BTW, the OP was apparently from Australia (ausics.net). It did occur to
me that it could have been Adam's self-deprecation---is Adam Australian
by any chance?
2:06 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Tue, 2012-11-20 at 12:36 -0500, Przemek Klosowski wrote:
On 11/18/2012 04:19 PM, Kevin Kofler wrote:
> Oh by the way:
>
> Adam Williamson wrote:
>> Meanwhile, our trusty European punctuation-less shit-stirrer (sound
>> familiar, anyone?) is still saying we suck if we can't support minimal
>> memory installs, and we should be better than 'winbloze':
>>
>> https://lists.fedoraproject.org/pipermail/devel/2003-December/048553.html
>
> Since when is it acceptable on this list to direct ad-hominem attacks
> against an entire continent?
You can call me a prude if you want, but I would have chosen the wording
differently, even though I didn't read Adam's words as offensive.
BTW, the OP was apparently from Australia (ausics.net). It did occur to
me that it could have been Adam's self-deprecation---is Adam Australian
by any chance?
I was kinda hoping to just let that die a quiet death, but since this
thread has been thoroughly revived - I would've worded it differently if
I'd thought about it at all, and I'm sorry for that, it was a silly way
to put things. That thread was getting ridiculous and I was badly
stressed out from Beta work. Sorry to anyone who was offended by what I
wrote for any reason. I was really just trying to draw a humorous
comparison between fedora-devel circa 2003 and fedora-devel now (it
really was uncanny how similar the two threads were), but it got a bit
negative. Sorry about that.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:34 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Tue, Nov 20, 2012 at 9:06 PM, Adam Williamson <awilliam(a)redhat.com>wrote:
I was kinda hoping to just let that die a quiet death, but since
this
thread has been thoroughly revived - I would've worded it differently if
I'd thought about it at all, and I'm sorry for that, it was a silly way
to put things. That thread was getting ridiculous and I was badly
stressed out from Beta work. Sorry to anyone who was offended by what I
wrote for any reason. I was really just trying to draw a humorous
comparison between fedora-devel circa 2003 and fedora-devel now (it
really was uncanny how similar the two threads were), but it got a bit
negative. Sorry about that.
Adam, thank for your great work at Fedora QA, They is a lot of negativity
on this list
and it is not very helpful or constructive.
Tim
1:01 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Adam Williamson wrote:
Or are you seriously suggesting that a sensible direction for Fedora
is
to consider the requirements of nine year old hardware and attempt to
adjust our software to match?
Why not? High-end hardware should have a lifespan of at least a decade. It
obviously won't be high-end anymore by then, but it does the job.
Kevin Kofler
1:38 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, Nov 9, 2012 at 8:22 PM, Ralf Corsepius <rc040203(a)freenet.de> wrote:
On 11/10/2012 01:30 AM, Adam Williamson wrote:
>
> On Sat, 2012-11-10 at 00:52 +0100, Kevin Kofler wrote:
>>
>> Adam Williamson wrote:
>> So, since Fedora has existed, Anaconda's memory requirements have
>> increased
>> by at least an order of magnitude! How's that NOT "skyrocketing"?
> You're being pretty absurd comparing 2003 requirements to 2012
> requirements without allowing at all for hardware inflation.
You seem to be missing the increasing amount of aging netbooks, laptops and
tablets.
Also you seem to be ignoring the fact of Windows XP being about to be
discontinued, for which at least some users will be looking for a substitute
OS, when they realize Win 8's HW requirements are too demanding for their HW
or when they realize Win 8 doesn't meet their personal needs.
Some of them certainly will consider switching to Linux, but will it be
Fedora? Provided this discussion, my guess is no.
Ralf
Here in Portland, Oregon, "obsolete" computers end up at a recycling /
reuse outfit called FreeGeek. They do in fact rebuild them with Linux,
and IIRC it's Ubuntu.
--
Twitter: http://twitter.com/znmeb; Computational Journalism Publishers
Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/
How the Hell can the lion sleep with all those people singing "A weem
oh way!" at the top of their lungs?
1:45 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, 2012-11-09 at 23:38 -0800, M. Edward (Ed) Borasky wrote:
On Fri, Nov 9, 2012 at 8:22 PM, Ralf Corsepius
<rc040203(a)freenet.de> wrote:
> On 11/10/2012 01:30 AM, Adam Williamson wrote:
>>
>> On Sat, 2012-11-10 at 00:52 +0100, Kevin Kofler wrote:
>>>
>>> Adam Williamson wrote:
>
>
>>> So, since Fedora has existed, Anaconda's memory requirements have
>>> increased
>>> by at least an order of magnitude! How's that NOT
"skyrocketing"?
>
>
>> You're being pretty absurd comparing 2003 requirements to 2012
>> requirements without allowing at all for hardware inflation.
>
>
> You seem to be missing the increasing amount of aging netbooks, laptops and
> tablets.
>
> Also you seem to be ignoring the fact of Windows XP being about to be
> discontinued, for which at least some users will be looking for a substitute
> OS, when they realize Win 8's HW requirements are too demanding for their HW
> or when they realize Win 8 doesn't meet their personal needs.
>
> Some of them certainly will consider switching to Linux, but will it be
> Fedora? Provided this discussion, my guess is no.
>
> Ralf
Here in Portland, Oregon, "obsolete" computers end up at a recycling /
reuse outfit called FreeGeek. They do in fact rebuild them with Linux,
and IIRC it's Ubuntu.
Same outfit here, and they also use Ubuntu, but it's nothing to do with
system requirements, just broader hardware support through non-free
drivers and the simple fact that it's the most popular desktop
general-user distro. Ubuntu 12.04 cites 384MB minimum for a 32-bit
install and 512MB minimum for a 64-bit install:
https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop#System...
so they're very close to us.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
1:03 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Adam Williamson wrote:
Same outfit here, and they also use Ubuntu, but it's nothing to
do with
system requirements, just broader hardware support through non-free
drivers and the simple fact that it's the most popular desktop
general-user distro. Ubuntu 12.04 cites 384MB minimum for a 32-bit
install and 512MB minimum for a 64-bit install:
https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop#System...
so they're very close to us.
The fact that even *Ubuntu*, of all distros, requires less RAM than we do
should ring a HUGE alarm bell!
Kevin Kofler
3:39 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 2012-11-10, 19:03 GMT, Kevin Kofler wrote:
The fact that even *Ubuntu*, of all distros, requires less RAM than
we
do should ring a HUGE alarm bell!
That’s unfortunate side-effect of rpm having file dependencies ... the
matrix of possible dependencies apt-get has to resolve is by the order
of magnitude smaller. And IIRC need for RAM required for depsolving is
exponentially dependent on the number of dependencies. OTOH, file
dependencies make some thinks incredibly more simple.
Matěj
10:40 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/10/2012 12:30 AM, Adam Williamson wrote:
You're being pretty absurd comparing 2003 requirements to 2012
requirements without allowing at all for hardware inflation.
My hp pavilion came out of the box with 2GB ram bought last year ago and
tablets and various other devices aren't that high on memory...
JBG
10:46 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Sat, 2012-11-10 at 04:40 +0000, "Jóhann B. Guðmundsson" wrote:
On 11/10/2012 12:30 AM, Adam Williamson wrote:
> You're being pretty absurd comparing 2003 requirements to 2012
> requirements without allowing at all for hardware inflation.
My hp pavilion came out of the box with 2GB ram bought last year ago and
tablets and various other devices aren't that high on memory...
That's 1.2GB more than it needs. So what's your point? We support 2GB
devices. Just fine. We support 1GB devices.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
10:56 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/10/2012 04:46 AM, Adam Williamson wrote:
On Sat, 2012-11-10 at 04:40 +0000, "Jóhann B. Guðmundsson"
wrote:
> On 11/10/2012 12:30 AM, Adam Williamson wrote:
>> You're being pretty absurd comparing 2003 requirements to 2012
>> requirements without allowing at all for hardware inflation.
> My hp pavilion came out of the box with 2GB ram bought last year ago and
> tablets and various other devices aren't that high on memory...
That's 1.2GB more than it needs. So what's your point? We support 2GB
devices. Just fine. We support 1GB devices.
*cough* tmpfs *cough*
Not that I have been bitten by or explicitly looking at it but depending
how close to upstream systemd Anaconda is an % percentage of that ram is
being reserved else where ;)
JBG
11:12 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Sat, 2012-11-10 at 04:56 +0000, "Jóhann B. Guðmundsson" wrote:
On 11/10/2012 04:46 AM, Adam Williamson wrote:
> On Sat, 2012-11-10 at 04:40 +0000, "Jóhann B. Guðmundsson" wrote:
>> On 11/10/2012 12:30 AM, Adam Williamson wrote:
>>> You're being pretty absurd comparing 2003 requirements to 2012
>>> requirements without allowing at all for hardware inflation.
>> My hp pavilion came out of the box with 2GB ram bought last year ago and
>> tablets and various other devices aren't that high on memory...
> That's 1.2GB more than it needs. So what's your point? We support 2GB
> devices. Just fine. We support 1GB devices.
*cough* tmpfs *cough*
Not that I have been bitten by or explicitly looking at it but depending
how close to upstream systemd Anaconda is an % percentage of that ram is
being reserved else where ;)
dude, seriously. you of anyone should know how many install tests I run
per cycle. I run most of them in a 1GB VM. I went to 2GB for alpha
because debug kernels chew RAM, but I've been using 1GB ever since. I'm
not throwing around numbers like 6GB because I think our installer
should require 6GB of RAM, I was making a specific point to kevin.
I recognize the contradiction impulse because I'm guilty of it myself
too sometimes. it's fun to read a mail, see '6GB', cut out all the
context and point and yell HAHA I HAVE A SYSTEM WITH 2GB SO YOU'RE
WRONG!
But it's not _helping_ anything. It's not signal. It's just noise. I
didn't say 'you need 6GB of RAM to install Fedora'. I said to Kevin
'you're comparing the minimum requirements from a time when 256MB of RAM
was a standard desktop configuration to a time when 6GB is a standard
desktop configuration'. Replies that just look at a number and go 'haha
I have this other number!' are not helping anyone with anything. It's
just more of the noise that plagues this list. Keep the wider topic in
mind and make sure your arguments contribute to it.
It is also not helping to say 'hey I vaguely remember this other topic
that came up which was something to do with memory so I'll make an
assertion I can't actually back up'. If you think tmpfs-by-default might
be affecting anaconda's memory use, you know what you can do? Go run an
anaconda install, check if it actually uses a tmpfs, and check how much
RAM that uses. This is not beyond your capabilities. You could do that,
and report your results, and that would be signal, not noise. Saying 'oh
hey but tmpfs!' is not signal, it is noise.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:41 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/10/2012 05:12 AM, Adam Williamson wrote:
But it's not_helping_ anything. It's not signal. It's
just noise. I
didn't say 'you need 6GB of RAM to install Fedora'. I said to Kevin
'you're comparing the minimum requirements from a time when 256MB of RAM
was a standard desktop configuration to a time when 6GB is a standard
desktop configuration'. Replies that just look at a number and go 'haha
I have this other number!' are not helping anyone with anything. It's
just more of the noise that plagues this list. Keep the wider topic in
mind and make sure your arguments contribute to it.
You mean like you say old hw is not relevant and all new hw has gigs of
ram failing to realize that we have actually gone a full circle and now
the market is filled with arm devices with small memory?
How much memory did the devices we just gave to contributors in
selective states and country's?
Heck this spring I took an farmers laptop from 2003 which had 192 mb of
ram tor out the disk because I could not install Fedora directly to it
put it into another laptop that had more memory, installed Fedora LXDE (
which ran just fine once installed ) put it back in the old laptop
hooked it up to an Ethernet cable ( from his home to his barn )
configured it to bootup, auto login and open a specific web page so the
farmer could use his old laptop to go to the nations sheep registry and
register how much each lamb weighted.
He could not afford a tabled even if he could he would never have taken
it in the filth in the barn, had this old laptop laying around that
still worked hence it was reused to serve one specific task to make his
life easier.
And if memory servers me correct there were people in the community that
work with refurbishing old hardware and shipping it third world
country's to be reused with Fedora on it.
So there is actually valid strong point in shrinking the anaconda's
memory usage but you are right I dont have time to "shrink" anaconda's
memory usage I doubt that you have it either and neither do the anaconda
developers themselves hence no point in debating this any further and
those that can help shrink anaconda's memory usage should rather spent
their time on helping them or wwoods beating anaconda or fedup in usable
state hence there is no point in continuing this discussion any further...
JBG
JBG
11:46 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Once upon a time, "Jóhann B. Guðmundsson" <johannbg(a)gmail.com> said:
*cough* tmpfs *cough*
Not that I have been bitten by or explicitly looking at it but depending
how close to upstream systemd Anaconda is an % percentage of that ram is
being reserved else where ;)
Where is it being "reserved"? Hint: not tmpfs.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
10:54 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 08:43 AM, Adam Williamson wrote:
It hasn't really 'skyrocketed'. We cited 512MB for
several releases,
bumped it to 768MB for F15/F16 (IIRC), got it back down to 512MB for
F17, and it's back up to 768MB or 1GB for F18 atm because everyone has
more important stuff to do than optimize the RAM usage right now. But
it's not been rising crazily or anything. I think the last time someone
took a deep look at RAM use during install - during F17 cycle when we
got it back down to 512MB - it turned out a lot of the usage happened
during package install and wasn't really to do with anaconda at all.
I still don't get it.
If just depsolving requires so much memory, then it's maybe an option,
to add an 'express lane' to anaconda, to install all files listed in an
explicit file list and also to skip dependency checking.
That file list could be included for the three/four/ten typical usage
scenarios. I assume, this is just one scenario "minimum install".
Does rpm -i --nodeps really take so much memory? (Yes, there's a risk to
install a system with unsolved dependencies, and I currently ignore this
fact)
Or does anaconda require much memory when running headless (e.g. when
working on a kickstart file?) If not, we may want to put some energy
into kickstart-creator?
--
Matthias Runge <mrunge(a)matthias-runge.de>
<mrunge(a)fedoraproject.org>
3:21 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 02:15 AM, Adam Williamson wrote:
I'd put things more strongly than Bill: what's been happening
in
anaconda lately is the precise opposite of what Johann suggests, and
that's exactly the right direction.
I question if that's the right direction since I cant for the love of me
figure out how they are going to be able to revert the installer if it
becomes necessary in the future which this release cycle has proven that
it *has* to be able to do that.
So care to explain to me since you are such an Anaconda expert how they
are going to do that since none of the Anaconda developers have been
able so far or even outline to me how they *plan* to support that in the
near future ...
Not maintaining the installer on three branches also takes away the
ability to release updated GA release with updated Anaconda which people
from the community have wanted and been doing themselves on their own
and there is a demand for it as well ( less demand after the Anaconda
developers introduced the ability to install updates directly if you
have network connection but demand never the less )
And as Tom has pointed out them floating on an cloud like some golden
child through our process where the rules that *every* other maintainer
and component have to follow is not fair now is it.
If we would have been given the ability to tell them to come back in F19
when the installer was more complete we would have but you know as well
as I do that they gave us no option to do so...
JBG
7:48 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, 2012-11-08 at 18:15 -0800, Adam Williamson wrote:
Again, this isn't an accident, it's a very deliberate plan. One of the
whole points of the Fedora philosophy is that we're supposed to share
and reuse work and code as much as possible. We're not supposed to write
five independent versions of everything at all. The fact that anaconda
team had to maintain their own loader (which did pretty much what dracut
does), their own partition code (which did pretty much what parted does)
and their own network code (which did pretty much what NetworkManager
does, only not as well) was a problem, not an advantage. It meant we
were duplicating a whole bunch of effort to get inconsistent results.
anaconda team was wasting time maintaining a bunch of network code that
wasn't as good as NetworkManager in the first place (ditto for the other
two examples).
The overall strategy of the anaconda team has been to try and reduce
their maintenance burden; they'd reached a point where they were almost
running full tilt just to stand still - they had so much unique code to
maintain that it took almost all their resources just to keep it working
and up to date. They couldn't work on actually improving anaconda, it
was the best they could do just to keep it at the level it was at.
So they deliberately went out and aimed to reduce that burden, and using
existing code like dracut, NM and parted was just a part of that plan.
newUI is another part of that plan - it's a lot of work now, but the aim
is that it's less of a maintenance burden than the old UI code when it's
done. The ultimate goal is that an anaconda team with the same resources
will be able to devote much less time to just keeping a giant codebase
working, and more time to enhancing a smaller codebase.
So no, our installer absolutely is not independent from the rest of the
distro, it's not intended to be and it shouldn't be. It's deliberately
designed to reuse components of the distribution as much as possible,
and the goal is if anything to increase this over time, not decrease it.
The maintenance burden of adjusting to changes in those components it
depends on is non-zero - which is where we came into this side track -
but that's not a problem. It's non-zero, but it's much lower than
duplicating all those components from scratch, only worse.
I agree 100% that it is right for the installer to use the system
infrastructure for the things it needs to do. That is a much needed and
very welcome change.
I still think there would be room for shrinking both code base and the
system dependencies if the installer focused on its core responsibility
- getting the bits on disk. That is an important and very high-risk
operation - why do we need to complicate the program doing it by also
making it responsible for creating users, configuring firewalls,
timezones, etc etc ? Those are all things that can (and imo should) be
done in the much safer and easier-to-debug post-install environment.
Maybe that is a design discussion for a different installer, anaconda
has always been a 'fat' installer, and it doesn't look like that is
going change.
8:47 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Le Ven 9 novembre 2012 14:48, Matthias Clasen a écrit :
I still think there would be room for shrinking both code base and
the
system dependencies if the installer focused on its core responsibility
- getting the bits on disk. That is an important and very high-risk
operation - why do we need to complicate the program doing it by also
making it responsible for creating users, configuring firewalls,
timezones, etc etc ? Those are all things that can (and imo should) be
done in the much safer and easier-to-debug post-install environment.
Only if you forget about all the automated mass installation processes
where you do absolutely want to feed a kickstart to the installer and have
it configure everything in one go.
--
Nicolas Mailhot
8:56 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, 09 Nov 2012, Nicolas Mailhot wrote:
Le Ven 9 novembre 2012 14:48, Matthias Clasen a écrit :
> I still think there would be room for shrinking both code base and the
> system dependencies if the installer focused on its core responsibility
> - getting the bits on disk. That is an important and very high-risk
> operation - why do we need to complicate the program doing it by also
> making it responsible for creating users, configuring firewalls,
> timezones, etc etc ? Those are all things that can (and imo should) be
> done in the much safer and easier-to-debug post-install environment.
Only if you forget about all the automated mass installation processes
where you do absolutely want to feed a kickstart to the installer and have
it configure everything in one go.
The simple fact that you are feeding kickstart
file to a single entity
does not mean this entity cannot outsource actual tasks to others and
run them later, be it post-install phase in the actual installer's
session or after (a simulated) reboot.
Input interface change is not needed for backend changes. If all you are
interested is 'one go' installer from perspective of the feeding
kickstart files, it would still be the same.
--
/ Alexander Bokovoy
11:07 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 06:56 AM, Alexander Bokovoy wrote:
The simple fact that you are feeding kickstart file to a single
entity
does not mean this entity cannot outsource actual tasks to others and
run them later, be it post-install phase in the actual installer's
session or after (a simulated) reboot.
Input interface change is not needed for backend changes. If all you are
interested is 'one go' installer from perspective of the feeding
kickstart files, it would still be the same.
What anaconda is doing is taking that kickstart input and feed it into
run-time tools in a way that those tools can do what we want them to do.
Except those tools change over time, and their inputs change over time,
so anaconda breaks over time just in trying to take data in one place
and feed it into another.
Isn't software fun?
--
Jesse Keating
Fedora -- Freedom² is a feature!
11:01 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 05:48 AM, Matthias Clasen wrote:
I still think there would be room for shrinking both code base and
the
system dependencies if the installer focused on its core responsibility
- getting the bits on disk. That is an important and very high-risk
operation - why do we need to complicate the program doing it by also
making it responsible for creating users, configuring firewalls,
timezones, etc etc ? Those are all things that can (and imo should) be
done in the much safer and easier-to-debug post-install environment.
Because when you are only installing the minimal package set (which
means no x) then the post-install configuration tools don't really exist
to do those necessary steps, nor do people want to have an automated
install, which then halts at first boot to prompt a user to configure a
bunch of stuff necessary to make the machine work right.
--
Jesse Keating
Fedora -- Freedom² is a feature!
11:11 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 05:01 PM, Jesse Keating wrote:
On 11/09/2012 05:48 AM, Matthias Clasen wrote:
> I still think there would be room for shrinking both code base and the
> system dependencies if the installer focused on its core responsibility
> - getting the bits on disk. That is an important and very high-risk
> operation - why do we need to complicate the program doing it by also
> making it responsible for creating users, configuring firewalls,
> timezones, etc etc ? Those are all things that can (and imo should) be
> done in the much safer and easier-to-debug post-install environment.
Because when you are only installing the minimal package set (which
means no x) then the post-install configuration tools don't really
exist to do those necessary steps, nor do people want to have an
automated install, which then halts at first boot to prompt a user to
configure a bunch of stuff necessary to make the machine work right.
Well the argue can be made that If you are doing a minimal install it
kinda indicates you actually know what you are doing ( which means you
will probably change whatever was set afterwards ) so the system should
just default to use sane working defaults which should come with the
relevant package when it's installed even set some default password.
But if we continue to look at minimal install which post-install
configuration files is Anaconda explicitly touching?
JBG
11:47 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 09:11 AM, "Jóhann B. Guðmundsson" wrote:
Well the argue can be made that If you are doing a minimal install
it
kinda indicates you actually know what you are doing ( which means you
will probably change whatever was set afterwards ) so the system should
just default to use sane working defaults which should come with the
relevant package when it's installed even set some default password.
Pretty sure having a default root password in some package in Fedora is
a non-starter.
The point of doing an (automated) install (which can be minimal, or at
least start with minimal and build upon that with only exactly the
needed functionality) is so that you can do the install unattended,
reboot the machine and put it into production, unattended.
But if we continue to look at minimal install which post-install
configuration files is Anaconda explicitly touching?
root auth and firewall config are the main ones. Note that we don't
have any UI for firewall config either, so not really a lot of code
duplication.
--
Jesse Keating
Fedora -- Freedom² is a feature!
2:24 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, 2012-11-09 at 09:47 -0800, Jesse Keating wrote:
> But if we continue to look at minimal install which
post-install
> configuration files is Anaconda explicitly touching?
root auth and firewall config are the main ones. Note that we don't
have any UI for firewall config either, so not really a lot of code
duplication.
Also bootloader configuration and network configuration, no?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
2:33 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 12:24 PM, Adam Williamson wrote:
On Fri, 2012-11-09 at 09:47 -0800, Jesse Keating wrote:
>> But if we continue to look at minimal install which post-install
>> configuration files is Anaconda explicitly touching?
>
> root auth and firewall config are the main ones. Note that we don't
> have any UI for firewall config either, so not really a lot of code
> duplication.
Also bootloader configuration and network configuration, no?
Network yes. Bootloader config isn't necessarily something you can
delay until after the install :)
--
Help me fight child abuse: http://tinyurl.com/jlkcourage
- jlk
3:14 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, 2012-11-09 at 12:33 -0800, Jesse Keating wrote:
On 11/09/2012 12:24 PM, Adam Williamson wrote:
> On Fri, 2012-11-09 at 09:47 -0800, Jesse Keating wrote:
>
>>> But if we continue to look at minimal install which post-install
>>> configuration files is Anaconda explicitly touching?
>>
>> root auth and firewall config are the main ones. Note that we don't
>> have any UI for firewall config either, so not really a lot of code
>> duplication.
>
> Also bootloader configuration and network configuration, no?
>
Network yes. Bootloader config isn't necessarily something you can
delay until after the install :)
Sorry, I may have lost some context. I thought the question was just
'what does anaconda touch', not 'what does anaconda touch that we could
possibly move to post-install'.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
8:32 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 08, 2012 at 06:15:55PM -0800, Adam Williamson wrote:
On Thu, 2012-11-08 at 15:19 -0500, Bill Nottingham wrote:
> Matthew Garrett (mjg59(a)srcf.ucam.org) said:
> > Patches that cleanly decouple Anaconda from the entire software stack
> > that it runs on top of would probably be received with open arms, but
> > nobody who works on it has any idea how to implement them.
>
> In fact, this is what has been done in anaconda over the past couple of
> releases - Anaconda migrated from having its own boot and init
> infrastructure to using system-provided items such as dracut and systemd.
> But that's complicated work, and while you're doing that migration,
you're
> doing a lot of arbitration as to what bits are in generic dracut, what
> bits are in generic systemd, and what bits remain in anaconda. And during
> that process, you are *very* tied to the version of the underlying system,
> until the work is fully complete and there is a defined separation of
> features into each layer.
>
> This, incidentally, also is why running the F17 installer on F19 isn't
> practical.
I think this whole subthread took a crazy left turn a ways back and is
_way_ into the weeds by now.
I'd put things more strongly than Bill: what's been happening in
anaconda lately is the precise opposite of what Johann suggests, and
that's exactly the right direction.
We don't want to have an installer stack that's completely independent
of the rest of the distro. I don't think anyone would take patches to do
that, really. We've been trying to do exactly the opposite.
Let's look at the practical examples. anaconda used to have its own
partition inspection code, its own loader stage, and its own network
management code and UI. Over the last few years, all of those have very
deliberately been killed and replaced with bits of the main distro. The
partition stuff was replaced by libparted; the loader was replaced by
dracut; and the network code was replaced by NetworkManager.
Again, this isn't an accident, it's a very deliberate plan. One of the
whole points of the Fedora philosophy is that we're supposed to share
and reuse work and code as much as possible. We're not supposed to write
five independent versions of everything at all. The fact that anaconda
team had to maintain their own loader (which did pretty much what dracut
does), their own partition code (which did pretty much what parted does)
and their own network code (which did pretty much what NetworkManager
does, only not as well) was a problem, not an advantage. It meant we
were duplicating a whole bunch of effort to get inconsistent results.
anaconda team was wasting time maintaining a bunch of network code that
wasn't as good as NetworkManager in the first place (ditto for the other
two examples).
Just as a clarification here.... anaconda has used libparted for a very long
time. It is one piece of the larger storage backend code. The libparted
changes that came with our storage backend rewrite a number of years ago was
that we began relying on libparted to do more for us.
I'll also point out that we both own the parted component in Fedora and are
upstream contributors and co-maintainers.
The overall strategy of the anaconda team has been to try and reduce
their maintenance burden; they'd reached a point where they were almost
running full tilt just to stand still - they had so much unique code to
maintain that it took almost all their resources just to keep it working
and up to date. They couldn't work on actually improving anaconda, it
was the best they could do just to keep it at the level it was at.
So they deliberately went out and aimed to reduce that burden, and using
existing code like dracut, NM and parted was just a part of that plan.
newUI is another part of that plan - it's a lot of work now, but the aim
is that it's less of a maintenance burden than the old UI code when it's
done. The ultimate goal is that an anaconda team with the same resources
will be able to devote much less time to just keeping a giant codebase
working, and more time to enhancing a smaller codebase.
So no, our installer absolutely is not independent from the rest of the
distro, it's not intended to be and it shouldn't be. It's deliberately
designed to reuse components of the distribution as much as possible,
and the goal is if anything to increase this over time, not decrease it.
The maintenance burden of adjusting to changes in those components it
depends on is non-zero - which is where we came into this side track -
but that's not a problem. It's non-zero, but it's much lower than
duplicating all those components from scratch, only worse.
--
David Cantrell <dcantrell(a)redhat.com>
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
10:47 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 12:19 PM, Bill Nottingham wrote:
Matthew Garrett (mjg59(a)srcf.ucam.org) said:
> Patches that cleanly decouple Anaconda from the entire software stack
> that it runs on top of would probably be received with open arms, but
> nobody who works on it has any idea how to implement them.
In fact, this is what has been done in anaconda over the past couple of
releases - Anaconda migrated from having its own boot and init
infrastructure to using system-provided items such as dracut and systemd.
But that's complicated work, and while you're doing that migration, you're
doing a lot of arbitration as to what bits are in generic dracut, what
bits are in generic systemd, and what bits remain in anaconda. And during
that process, you are *very* tied to the version of the underlying system,
until the work is fully complete and there is a defined separation of
features into each layer.
This, incidentally, also is why running the F17 installer on F19 isn't
practical.
Bill
Not to mention that while making this migration and after, when system
tools /change their api/ or /change their command line arguments/ it
means that the installer is suddenly broken again.
--
Jesse Keating
Fedora -- Freedom² is a feature!
10:43 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 11:40 AM, "Jóhann B. Guðmundsson" wrote:
Pointing out how the installer currently works does not change my
opinion on the fact that if an installer ( any installer ) cannot run on
his own bits isolated from the package set he is about install is a
design flaw and is something that should be corrected ( from my pov ).
I think you're talking about booting an F17 kernel, using an F17 content
initrd and stage2 (F17 version dracut, systemd, udev, polkit, dbus,
parted, lvm, ext/btrfs/xfs tools, glibc, yum, rpm, selinux, grub,
etc...) and just point it at a newer repository of packages.
While that has some obvious issues, like new hardware doesn't work with
old kernel/syslinux/grub/udev/etc..., there are further issues as some
configuration has to happen within the installed system, which means
knowing how things like firewall config, network config, mount options,
root auth configuration, selinux, bootloader config and so on.
So no, it's not really possible to isolate the installer environment
such that you can plug and play with different package sets and expect
things to work.
If you think this is some kind of design flaw, then knock yourself out
redesigning it.
--
Jesse Keating
Fedora -- Freedom² is a feature!
10:57 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 04:43 PM, Jesse Keating wrote:
While that has some obvious issues, like new hardware doesn't work
with old kernel/syslinux/grub/udev/etc...,
It's not like it always works in that area anyway
there are further issues as some configuration has to happen within
the installed system, which means knowing how things like firewall
config, network config, mount options, root auth configuration,
selinux, bootloader config and so on.
Last time I checked the configuration of those files have remained the
same for years if we put that aside how is Anaconda supposed to be
reverted in the future what's the plan you guys have here, which
direction are you guys taking in regards to that?
JBG
11:13 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 08:57 AM, "Jóhann B. Guðmundsson" wrote:
On 11/09/2012 04:43 PM, Jesse Keating wrote:
>
> While that has some obvious issues, like new hardware doesn't work
> with old kernel/syslinux/grub/udev/etc...,
It's not like it always works in that area anyway
Right, computers don't always work, so lets give up, and go shopping right?
> there are further issues as some configuration has to happen within
> the installed system, which means knowing how things like firewall
> config, network config, mount options, root auth configuration,
> selinux, bootloader config and so on.
Last time I checked the configuration of those files have remained the
same for years if we put that aside how is Anaconda supposed to be
reverted in the future what's the plan you guys have here, which
direction are you guys taking in regards to that?
JBG
The inputs to the tools doing the configuration of those tools has
changed over time. We don't want to duplicate code by having our own
pile of config parsers and writers, we want to rely on the same tools
that userlands are using.
As far as Anaconda reverted in the future, I'm confused as to when/where
this became a requirement.
--
Jesse Keating
Fedora -- Freedom² is a feature!
11:15 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 05:13 PM, Jesse Keating wrote:
As far as Anaconda reverted in the future, I'm confused as to
when/where this became a requirement.
It never was up to this point you know the usual attitude of "let's
cross that bridge when we get there" and this release cycle has proven
that it's necessary
JBG
11:35 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, Nov 09, 2012 at 09:13:32AM -0800, Jesse Keating wrote:
As far as Anaconda reverted in the future, I'm confused as to
when/where this became a requirement.
I think he's saying this because:
1) Features have a section for contingency plans.
2) In this particular case, we're slipping schedule because the NewUI
feature has a point where there stopped being a contingency plan. We
passed that point before being aware of all of these issues that need to
be fixed in order to release Fedora.
Being stricter about having viable contingency plans for features like
this (ones that require coordination and can potentially block us if they
aren't done/done correctly) is one possible way to address this type of
situation in the future.
Others are to alter the "time-based" release philosophy for certain
features (We are going to have Feature X in Fedora 19. If it isn't ready,
we're going to slip the release date until it is done.) To only let in
a feature with no contingency plan only when it is code complete and can be
evaluated outside of the Fedora tree first (anaconda devs state that they do
not actually have the manpower to implement this style of solution).
-Toshio
- Note: I considered adding "have a longer release cycle" to the list of
alternatives but it's not clear that we wouldn't still get into this
situation (FESCo/releng/QA finding out at beta freeze that Feature X lacks
certain capabilities that are considered essential while the team
responsible for the feature had considered that it was something that
could safely be put off until the next release. Being unable to revert
the feature at that point and so having to code the missing capabilities
on a rushed schedule at that point.)
11:49 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 09:35 AM, Toshio Kuratomi wrote:
On Fri, Nov 09, 2012 at 09:13:32AM -0800, Jesse Keating wrote:
>
> As far as Anaconda reverted in the future, I'm confused as to
> when/where this became a requirement.
>
I think he's saying this because:
1) Features have a section for contingency plans.
2) In this particular case, we're slipping schedule because the NewUI
feature has a point where there stopped being a contingency plan. We
passed that point before being aware of all of these issues that need to
be fixed in order to release Fedora.
Being stricter about having viable contingency plans for features like
this (ones that require coordination and can potentially block us if they
aren't done/done correctly) is one possible way to address this type of
situation in the future.
Others are to alter the "time-based" release philosophy for certain
features (We are going to have Feature X in Fedora 19. If it isn't ready,
we're going to slip the release date until it is done.) To only let in
a feature with no contingency plan only when it is code complete and can be
evaluated outside of the Fedora tree first (anaconda devs state that they do
not actually have the manpower to implement this style of solution).
-Toshio
- Note: I considered adding "have a longer release cycle" to the list of
alternatives but it's not clear that we wouldn't still get into this
situation (FESCo/releng/QA finding out at beta freeze that Feature X lacks
certain capabilities that are considered essential while the team
responsible for the feature had considered that it was something that
could safely be put off until the next release. Being unable to revert
the feature at that point and so having to code the missing capabilities
on a rushed schedule at that point.)
In that context the plan would have had to be do all the "bring the code
base forward into the next Fedora environment" work twice.
--
Jesse Keating
Fedora -- Freedom² is a feature!
11:52 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, Nov 09, 2012 at 09:49:00AM -0800, Jesse Keating wrote:
On 11/09/2012 09:35 AM, Toshio Kuratomi wrote:
>On Fri, Nov 09, 2012 at 09:13:32AM -0800, Jesse Keating wrote:
>>
>>As far as Anaconda reverted in the future, I'm confused as to
>>when/where this became a requirement.
>>
>I think he's saying this because:
>
>1) Features have a section for contingency plans.
>2) In this particular case, we're slipping schedule because the NewUI
> feature has a point where there stopped being a contingency plan. We
> passed that point before being aware of all of these issues that need to
> be fixed in order to release Fedora.
>
>Being stricter about having viable contingency plans for features like
>this (ones that require coordination and can potentially block us if they
>aren't done/done correctly) is one possible way to address this type of
>situation in the future.
>
>Others are to alter the "time-based" release philosophy for certain
>features (We are going to have Feature X in Fedora 19. If it isn't ready,
>we're going to slip the release date until it is done.) To only let in
>a feature with no contingency plan only when it is code complete and can be
>evaluated outside of the Fedora tree first (anaconda devs state that they do
>not actually have the manpower to implement this style of solution).
>
>-Toshio
>
>- Note: I considered adding "have a longer release cycle" to the list of
> alternatives but it's not clear that we wouldn't still get into this
> situation (FESCo/releng/QA finding out at beta freeze that Feature X lacks
> certain capabilities that are considered essential while the team
> responsible for the feature had considered that it was something that
> could safely be put off until the next release. Being unable to revert
> the feature at that point and so having to code the missing capabilities
> on a rushed schedule at that point.)
>
>
>
In that context the plan would have had to be do all the "bring the
code base forward into the next Fedora environment" work twice.
Correct. But while this is a problem for the anaconda team, it may be the
least-bad for Fedora overall. Then again, there might be an alternative
that is even better.
-Toshio
3:11 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 05:35 PM, Toshio Kuratomi wrote:
On Fri, Nov 09, 2012 at 09:13:32AM -0800, Jesse Keating wrote:
> As far as Anaconda reverted in the future, I'm confused as to
> when/where this became a requirement.
>
I think he's saying this because:
1) Features have a section for contingency plans.
2) In this particular case, we're slipping schedule because the NewUI
feature has a point where there stopped being a contingency plan. We
passed that point before being aware of all of these issues that need to
be fixed in order to release Fedora.
Being stricter about having viable contingency plans for features like
this (ones that require coordination and can potentially block us if they
aren't done/done correctly) is one possible way to address this type of
situation in the future.
Others are to alter the "time-based" release philosophy for certain
features (We are going to have Feature X in Fedora 19. If it isn't ready,
we're going to slip the release date until it is done.) To only let in
a feature with no contingency plan only when it is code complete and can be
evaluated outside of the Fedora tree first (anaconda devs state that they do
not actually have the manpower to implement this style of solution).
-Toshio
- Note: I considered adding "have a longer release cycle" to the list of
alternatives but it's not clear that we wouldn't still get into this
situation (FESCo/releng/QA finding out at beta freeze that Feature X lacks
certain capabilities that are considered essential while the team
responsible for the feature had considered that it was something that
could safely be put off until the next release. Being unable to revert
the feature at that point and so having to code the missing capabilities
on a rushed schedule at that point.)
Actually the more I think about it the more I come to the conclusion
that "time-based" release is not the right way for the project but a
"feature-based" release is.
We just just have feature submission deadline, feature approval
deadline, then we work on approved features until they are done and then
give releng/marketing x time to prepare for release. that means we can
have 5 month release cycle or 7 or 9 month release cycle which gives us
the flexibility to integrate features properly into the release before
delivering into the hands of our end users and we don't have to worry
about "contingency plans" anymore
JBG
3:21 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, 2012-11-09 at 21:11 +0000, "Jóhann B. Guðmundsson" wrote:
On 11/09/2012 05:35 PM, Toshio Kuratomi wrote:
> On Fri, Nov 09, 2012 at 09:13:32AM -0800, Jesse Keating wrote:
>> As far as Anaconda reverted in the future, I'm confused as to
>> when/where this became a requirement.
>>
> I think he's saying this because:
>
> 1) Features have a section for contingency plans.
> 2) In this particular case, we're slipping schedule because the NewUI
> feature has a point where there stopped being a contingency plan. We
> passed that point before being aware of all of these issues that need to
> be fixed in order to release Fedora.
>
> Being stricter about having viable contingency plans for features like
> this (ones that require coordination and can potentially block us if they
> aren't done/done correctly) is one possible way to address this type of
> situation in the future.
>
> Others are to alter the "time-based" release philosophy for certain
> features (We are going to have Feature X in Fedora 19. If it isn't ready,
> we're going to slip the release date until it is done.) To only let in
> a feature with no contingency plan only when it is code complete and can be
> evaluated outside of the Fedora tree first (anaconda devs state that they do
> not actually have the manpower to implement this style of solution).
>
> -Toshio
>
> - Note: I considered adding "have a longer release cycle" to the list of
> alternatives but it's not clear that we wouldn't still get into this
> situation (FESCo/releng/QA finding out at beta freeze that Feature X lacks
> certain capabilities that are considered essential while the team
> responsible for the feature had considered that it was something that
> could safely be put off until the next release. Being unable to revert
> the feature at that point and so having to code the missing capabilities
> on a rushed schedule at that point.)
Actually the more I think about it the more I come to the conclusion
that "time-based" release is not the right way for the project but a
"feature-based" release is.
We just just have feature submission deadline, feature approval
deadline, then we work on approved features until they are done and then
give releng/marketing x time to prepare for release. that means we can
have 5 month release cycle or 7 or 9 month release cycle which gives us
the flexibility to integrate features properly into the release before
delivering into the hands of our end users and we don't have to worry
about "contingency plans" anymore
Well, both models have been in use in the software industry for decades,
and there are generally agreed pros and cons to both. The biggest cons
of feature-based schedules are that the release cycles tend to get
longer and longer because no-one feels any urgency to ship and instead
just start packing in more and more features, and that users don't have
a reliable schedule to follow in planning their deployments. Of course,
if we delay our supposedly-time-based-releases too much and too often,
we can wind up with all the cons of both approaches and none of the
pros...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
3:35 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 09:21 PM, Adam Williamson wrote:
> We just just have feature submission deadline, feature approval
> >deadline, then we work on approved features until they are done and then
> >give releng/marketing x time to prepare for release. that means we can
> >have 5 month release cycle or 7 or 9 month release cycle which gives us
> >the flexibility to integrate features properly into the release before
> >delivering into the hands of our end users and we don't have to worry
> >about "contingency plans" anymore
Well, both models have been in use in the software industry for decades,
and there are generally agreed pros and cons to both. The biggest cons
of feature-based schedules are that the release cycles tend to get
longer and longer because no-one feels any urgency to ship and instead
just start packing in more and more features, and that users don't have
a reliable schedule to follow in planning their deployments. Of course,
if we delay our supposedly-time-based-releases too much and too often,
we can wind up with all the cons of both approaches and none of the
pros...
I'm pretty sure we can bring fourth the whip if that turns out to be the
case or simply say that an release can be no longer then X months or a
full year and the only one way we can find out is to take the leap for 3
releases and if feature-based release is not the case we scrap it and
return back to the time-based one or merge the experience from both and
come up with some kind of hybrid between both of these
JBG
6:04 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Toshio Kuratomi wrote:
Being stricter about having viable contingency plans for features
like
this (ones that require coordination and can potentially block us if they
aren't done/done correctly) is one possible way to address this type of
situation in the future.
And it's the right way. I'd go as far as saying that features with no
(viable) contingency plan should be blanket-rejected.
Kevin Kofler
2:40 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, 2012-11-08 at 17:20 +0000, "Jóhann B. Guðmundsson" wrote:
On 11/08/2012 05:14 PM, Stephen John Smoogen wrote:
> On 8 November 2012 10:06, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com> wrote:
>> On 11/08/2012 04:37 PM, Matthew Garrett wrote:
>>> On Thu, Nov 08, 2012 at 04:32:29PM +0000, "Jóhann B. Guðmundsson"
wrote:
>>>
>>>> Or if I rephrase why could not the community continue to use
>>>> Anaconda in it's form that it existed in F17 until the "new
>>>> installer" was *completly* done?
>>> Because nobody in the community did the work to make the F17 Anaconda
>>> work in F18?
>>>
>> This also touches on "Who's responsible for an feature"
>>
>> Just recently FESCO decided *for* Kay that he was responsible to ensure the
>> migration related docs and what not kept working for the name change of
>> configuration files that takes place in systemd ( which was not even a
>> feature ) Applying the same logic here the Anaconda developers themselves
>> would have been responsible keeping the "old code" working until the
new one
>> was ready to completely replace it.
>>
> Your problem is that you are assuming a lot of things without actually
> doing any legwork to find out what anaconda does. Anaconda does a lot
> of probing of hardware which changes when kernels change. Anaconda
> requires changes when dracut changes APIs. Every release requires
> changes in what is blacklisted and what is not blacklisted. It
> requires dealing with the usual multiple changes in python apis and
> such. It has other changes due to EFI or secure boot or other
> features. None of them are trivial and doing them in parallel is
> usually not possible.
Not that your response is relate to who's responsible for making those
changes, but is that not a fundamental flaw in the installer and it's
design?
No. It is an inevitable consequence of the feature set demanded of the
Fedora OS installer.
If thing A must be able to set up and configure thing B and thing B
changes in ways directly related to said configuration, how can you
reasonably expect thing A to continue to be able to configure thing B
without corresponding changes? Magic?
2:47 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 08:40 PM, David Lehman wrote:
No. It is an inevitable consequence of the feature set demanded of
the
Fedora OS installer.
If thing A must be able to set up and configure thing B and thing B
changes in ways directly related to said configuration, how can you
reasonably expect thing A to continue to be able to configure thing B
without corresponding changes? Magic?
I'm all for magic but I would expect specific configuration package(s)
and or a configuration template tailored for the component being install
which the installer might use or the package himself would simply do it
post install.
Are there any specific use case where that would not suffice?
JBG
3:39 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, 2012-11-08 at 20:47 +0000, "Jóhann B. Guðmundsson" wrote:
On 11/08/2012 08:40 PM, David Lehman wrote:
> No. It is an inevitable consequence of the feature set demanded of the
> Fedora OS installer.
>
> If thing A must be able to set up and configure thing B and thing B
> changes in ways directly related to said configuration, how can you
> reasonably expect thing A to continue to be able to configure thing B
> without corresponding changes? Magic?
I'm all for magic but I would expect specific configuration package(s)
and or a configuration template tailored for the component being install
which the installer might use or the package himself would simply do it
post install.
Are there any specific use case where that would not suffice?
One example of such a configuration package used to be
system-config-firewall. Where is it now? What would happen if the
installer were still calling "lokkit" to set up the firewall? It
wouldn't work because the way that's handled has changed.
11:17 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 12:47 PM, "Jóhann B. Guðmundsson" wrote:
On 11/08/2012 08:40 PM, David Lehman wrote:
> No. It is an inevitable consequence of the feature set demanded of the
> Fedora OS installer.
>
> If thing A must be able to set up and configure thing B and thing B
> changes in ways directly related to said configuration, how can you
> reasonably expect thing A to continue to be able to configure thing B
> without corresponding changes? Magic?
I'm all for magic but I would expect specific configuration package(s)
and or a configuration template tailored for the component being install
which the installer might use or the package himself would simply do it
post install.
Are there any specific use case where that would not suffice?
JBG
You're focused on packages. How about filesystems? That stuff changes
way more often than one would like. LVM? How often do we have to
update the command line arguments we pass to do things? --force --force
--noIreallymeanit BTRFS? That's all still in development so the tools
are changing rapidly.
What about actually getting packages into the filesystem. yum api
changes with time, and our use of yum means we have to change our code
to work with the API as well. Boot loaders? yeah, go ahead and install
the grub package, see what it does in the %post scripts. Oh, you
actually want to /configure/ the machine to boot? Well that takes work,
work that has to change because /grub/ changes.
I can keep going, but is it really necessary?
--
Jesse Keating
Fedora -- Freedom² is a feature!
11:29 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 05:17 PM, Jesse Keating wrote:
I can keep going, but is it really necessary?
I argue yes maybe not here but having a wikipage under the anaconda name
space which mention all the package and configuration files change that
can directly affect the installer and how would be necessary for Feature
wranglers/Fesco/QA to look at.
Having a page like that might have prevented fesco from approving [1]
which I'm pretty sure put added a bit of load on top of your guys work
1.http://fedoraproject.org/wiki/Features/ReworkPackageGroups
5:27 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 8, 2012 at 9:40 PM, David Lehman <dlehman(a)redhat.com> wrote:
On Thu, 2012-11-08 at 17:20 +0000, "Jóhann B. Guðmundsson"
wrote:
> On 11/08/2012 05:14 PM, Stephen John Smoogen wrote:
> > On 8 November 2012 10:06, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com> wrote:
> >> On 11/08/2012 04:37 PM, Matthew Garrett wrote:
> >>> On Thu, Nov 08, 2012 at 04:32:29PM +0000, "Jóhann B.
Guðmundsson" wrote:
> >>>
> >>>> Or if I rephrase why could not the community continue to use
> >>>> Anaconda in it's form that it existed in F17 until the
"new
> >>>> installer" was *completly* done?
> >>> Because nobody in the community did the work to make the F17 Anaconda
> >>> work in F18?
> >>>
> >> This also touches on "Who's responsible for an feature"
> >>
> >> Just recently FESCO decided *for* Kay that he was responsible to ensure the
> >> migration related docs and what not kept working for the name change of
> >> configuration files that takes place in systemd ( which was not even a
> >> feature ) Applying the same logic here the Anaconda developers themselves
> >> would have been responsible keeping the "old code" working until
the new one
> >> was ready to completely replace it.
> >>
> > Your problem is that you are assuming a lot of things without actually
> > doing any legwork to find out what anaconda does. Anaconda does a lot
> > of probing of hardware which changes when kernels change. Anaconda
> > requires changes when dracut changes APIs. Every release requires
> > changes in what is blacklisted and what is not blacklisted. It
> > requires dealing with the usual multiple changes in python apis and
> > such. It has other changes due to EFI or secure boot or other
> > features. None of them are trivial and doing them in parallel is
> > usually not possible.
>
> Not that your response is relate to who's responsible for making those
> changes, but is that not a fundamental flaw in the installer and it's
> design?
No. It is an inevitable consequence of the feature set demanded of the
Fedora OS installer.
If thing A must be able to set up and configure thing B and thing B
changes in ways directly related to said configuration, how can you
reasonably expect thing A to continue to be able to configure thing B
without corresponding changes? Magic?
Well, perhaps thing B shouldn't have been changed incompatibly in the
first place. I realize that's an ideal that is impossible to achieve,
but we are rather cavalier about changing interfaces without adequate
notification.
I've been told that the F18 Anaconda work was for some time done on a
single rawhide snapshot; after ~2 months the snapshot was updated -
and it took weeks to get Anaconda working again against the new one.
That sounds rather bad. Yes, anaconda is special, but it is not
_that_ special; if updating for core platform changes (without any
major known change happening in the mean time) requires weeks of work
on anaconda, there will be other software that will require weeks of
work to update.
Mirek
5:55 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, 2012-11-09 at 12:27 +0100, Miloslav Trmač wrote:
On Thu, Nov 8, 2012 at 9:40 PM, David Lehman
<dlehman(a)redhat.com> wrote:
> On Thu, 2012-11-08 at 17:20 +0000, "Jóhann B. Guðmundsson" wrote:
>> On 11/08/2012 05:14 PM, Stephen John Smoogen wrote:
>> > On 8 November 2012 10:06, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com> wrote:
>> >> On 11/08/2012 04:37 PM, Matthew Garrett wrote:
>> >>> On Thu, Nov 08, 2012 at 04:32:29PM +0000, "Jóhann B.
Guðmundsson" wrote:
>> >>>
>> >>>> Or if I rephrase why could not the community continue to use
>> >>>> Anaconda in it's form that it existed in F17 until the
"new
>> >>>> installer" was *completly* done?
>> >>> Because nobody in the community did the work to make the F17
Anaconda
>> >>> work in F18?
>> >>>
>> >> This also touches on "Who's responsible for an feature"
>> >>
>> >> Just recently FESCO decided *for* Kay that he was responsible to ensure
the
>> >> migration related docs and what not kept working for the name change
of
>> >> configuration files that takes place in systemd ( which was not even a
>> >> feature ) Applying the same logic here the Anaconda developers
themselves
>> >> would have been responsible keeping the "old code" working
until the new one
>> >> was ready to completely replace it.
>> >>
>> > Your problem is that you are assuming a lot of things without actually
>> > doing any legwork to find out what anaconda does. Anaconda does a lot
>> > of probing of hardware which changes when kernels change. Anaconda
>> > requires changes when dracut changes APIs. Every release requires
>> > changes in what is blacklisted and what is not blacklisted. It
>> > requires dealing with the usual multiple changes in python apis and
>> > such. It has other changes due to EFI or secure boot or other
>> > features. None of them are trivial and doing them in parallel is
>> > usually not possible.
>>
>> Not that your response is relate to who's responsible for making those
>> changes, but is that not a fundamental flaw in the installer and it's
>> design?
>
> No. It is an inevitable consequence of the feature set demanded of the
> Fedora OS installer.
>
> If thing A must be able to set up and configure thing B and thing B
> changes in ways directly related to said configuration, how can you
> reasonably expect thing A to continue to be able to configure thing B
> without corresponding changes? Magic?
Well, perhaps thing B shouldn't have been changed incompatibly in the
first place. I realize that's an ideal that is impossible to achieve,
but we are rather cavalier about changing interfaces without adequate
notification.
I've been told that the F18 Anaconda work was for some time done on a
single rawhide snapshot; after ~2 months the snapshot was updated -
and it took weeks to get Anaconda working again against the new one.
That sounds rather bad. Yes, anaconda is special, but it is not
_that_ special; if updating for core platform changes (without any
major known change happening in the mean time) requires weeks of work
on anaconda, there will be other software that will require weeks of
work to update.
I'm afraid anaconda _is that_ special. AFAICT there is no other
piece of
code that directly interacts with dracut, systemd, Network Manager, gtk3
(and GObject introspection) and many other components that change quite
often. If there is such code, I'd be happy to look at how its developers
handle such changes and take a lecture from them.
--
Vratislav Podzimek
Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic
11:46 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, Nov 09, 2012 at 12:55:30PM +0100, Vratislav Podzimek wrote:
On Fri, 2012-11-09 at 12:27 +0100, Miloslav Trmač wrote:
>
> I've been told that the F18 Anaconda work was for some time done on a
> single rawhide snapshot; after ~2 months the snapshot was updated -
> and it took weeks to get Anaconda working again against the new one.
>
> That sounds rather bad. Yes, anaconda is special, but it is not
> _that_ special; if updating for core platform changes (without any
> major known change happening in the mean time) requires weeks of work
> on anaconda, there will be other software that will require weeks of
> work to update.
I'm afraid anaconda _is that_ special. AFAICT there is no other piece of
code that directly interacts with dracut, systemd, Network Manager, gtk3
(and GObject introspection) and many other components that change quite
often. If there is such code, I'd be happy to look at how its developers
handle such changes and take a lecture from them.
Other projects would handle something like this by having a subset of people
working on a branch that kept the existing UI but was updating to fix issues
with dependencies. The NewUI feature work would be done by a different
subset of people on a separate branch and be merged in only when it was
ready.
David Cantrell has mentioned the reasons that he doesn't think that would
work for anaconda -- I'll list them here so no one reads my message without
that information as well:
* Doing it this way would slow down anaconda development
* Anaconda lacks the manpower to maintain two separate development heads
-Toshio
11:20 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 03:27 AM, Miloslav Trmač wrote:
Well, perhaps thing B shouldn't have been changed incompatibly in
the
first place. I realize that's an ideal that is impossible to achieve,
but we are rather cavalier about changing interfaces without adequate
notification.
I've been told that the F18 Anaconda work was for some time done on a
single rawhide snapshot; after ~2 months the snapshot was updated -
and it took weeks to get Anaconda working again against the new one.
That sounds rather bad. Yes, anaconda is special, but it is not
_that_ special; if updating for core platform changes (without any
major known change happening in the mean time) requires weeks of work
on anaconda, there will be other software that will require weeks of
work to update.
You won't find much disagreement in the installer team. Fedora changes,
and it changes fast, and it changes without a lot of notice,
cooperation, or coordination. Anaconda suffers a lot because of this,
and Fedora users/testers suffer a lot because Anaconda breaks a lot. We
are often the advanced scout who first encounters a major change.
--
Jesse Keating
Fedora -- Freedom² is a feature!
5:16 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 8, 2012 at 5:32 PM, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com> wrote:
On 11/08/2012 03:58 PM, David Cantrell wrote:
>
> Not true. As with our other major changes, we new it would be absolutely
> impossible to deliver all functionality in a single release.
What exactly prevented the Anaconda from implementing Anaconda 2.0 in a F19
or later when it was fully complete?
Or if I rephrase why could not the community continue to use Anaconda in
it's form that it existed in F17 until the "new installer" was *completly*
done?
Well, FESCo _did_ approve the plan to move to F18 with no contingency
plan. The blame here is on FESCo, not on Anaconda.
Yes, it was a major error; we could have at that point insisted on
keeping the F17 implementation working, and it probably would have
been easier at that point to maintain two branches than to backport
nobody-knows-what now.
Mirek
10:35 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 03:58 PM, David Cantrell wrote:
I completely agree! Which is why we were getting early test builds
done
during the F-17 cycle and working to get people testing the installer then.
The main problem is that no one_wants_ to test the installer. It's a
utility. A necessary step to getting Fedora on your system. Testing it
isn't sexy to a lot of people. We can't force people to test it, we can
only make it available and ask for help.
And to those early testers who have helped and provide useful feedback,
thank you!
Testing is also extremely time consuming since the actual install time
takes so long. ( ca 1 hour if doing manual install on a physical hw ).
So I say the faster you can install the more testing you expose to the
installer...
JBG
5:14 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 8, 2012 at 4:58 PM, David Cantrell <dcantrell(a)redhat.com> wrote:
2) "Just stop everything, move newui to F-19, and ship the F-17
installer."
This just delays what we are going through right now until the F-19 cycle.
We need to identify the failings at some point and work to improve/change
them.
(Completely hypothetical at this point)
Yes, from the point of view of the Anaconda team - but from the point
of view of the other teams, it would have allowed to ship _their_
features to users.
Mirek
11:17 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Matthew Garrett wrote:
On Thu, Nov 08, 2012 at 06:31:20AM +0100, Kevin Kofler wrote:
> And Restricted Boot support just needs to go away!
Sure, who wants new computers.
Restricted Boot can and should be disabled by the user in the firmware.
Kevin Kofler
11:29 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, 2012-11-09 at 06:17 +0100, Kevin Kofler wrote:
Matthew Garrett wrote:
> On Thu, Nov 08, 2012 at 06:31:20AM +0100, Kevin Kofler wrote:
>> And Restricted Boot support just needs to go away!
>
> Sure, who wants new computers.
Restricted Boot can and should be disabled by the user in the firmware.
This week, in pointless reheated arguments...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:06 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
I've now done half a dozen F18 multi-boot installs and I must say it's
a miracle I haven't over-written something I wanted to keep. The thing
that would make it usable for me would be very simple - just put the
partition names on the labeling so I know what's going to end up
where! The rest of the installer is fine but the partitioner needs
either a user interface redesign or extensive documentation.
On Wed, Nov 7, 2012 at 9:31 PM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Adam Williamson wrote:
> The new anaconda UI and related features are more or less entirely the
> cause of the slip.
This shows that those changes should not have been done, or at least not in
this way.
> Secure boot support is also not done yet (waiting on the signature for
> shim to get sorted out by legal), though I don't know whether FESCo yet
> absolutely decided that has to be in for Beta.
And Restricted Boot support just needs to go away!
Kevin Kofler
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Twitter: http://twitter.com/znmeb; Computational Journalism Publishers
Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/
How the Hell can the lion sleep with all those people singing "A weem
oh way!" at the top of their lungs?
1:44 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Wed, 2012-11-07 at 22:06 -0800, M. Edward (Ed) Borasky wrote:
I've now done half a dozen F18 multi-boot installs and I must say
it's
a miracle I haven't over-written something I wanted to keep. The thing
that would make it usable for me would be very simple - just put the
partition names on the labeling so I know what's going to end up
where! The rest of the installer is fine but the partitioner needs
either a user interface redesign or extensive documentation.
This is already planned.
https://bugzilla.redhat.com/show_bug.cgi?id=855646
It seems to have got rather lost in the shuffle, though, I kind of
expected it to be implemented by now. I'll check in with dlehman whether
it just dropped off his list or what.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
1:48 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
"M. Edward (Ed) Borasky" <znmeb(a)znmeb.net> writes:
I've now done half a dozen F18 multi-boot installs and I must say
it's
a miracle I haven't over-written something I wanted to keep. The thing
that would make it usable for me would be very simple - just put the
partition names on the labeling so I know what's going to end up
where! The rest of the installer is fine but the partitioner needs
either a user interface redesign or extensive documentation.
Indeed, it's *spectacularly* bad. Aside from the point you make, I find
that it doesn't show you what actions have already been chosen: as soon
as you select any of the inadequately-labeled existing partitions, that
partition disappears completely from the display. So at the end of the
process, all you have to go on is a display of the partitions you've
*not* selected to be mounted and/or overwritten. Want to double-check
your choices before you push the big red button? Good luck with that.
I do like the functionality of showing you the former/existing usage
of each partition, but that ought to be an annotation on something
that's laid out more like the old display. As is, it's unhelpful to
the point of being outright dangerous.
regards, tom lane
2:42 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, 2012-11-08 at 02:48 -0500, Tom Lane wrote:
"M. Edward (Ed) Borasky" <znmeb(a)znmeb.net> writes:
> I've now done half a dozen F18 multi-boot installs and I must say it's
> a miracle I haven't over-written something I wanted to keep. The thing
> that would make it usable for me would be very simple - just put the
> partition names on the labeling so I know what's going to end up
> where! The rest of the installer is fine but the partitioner needs
> either a user interface redesign or extensive documentation.
Indeed, it's *spectacularly* bad. Aside from the point you make, I find
that it doesn't show you what actions have already been chosen: as soon
as you select any of the inadequately-labeled existing partitions, that
partition disappears completely from the display.
If you actually mean that you click on it and it disappears from the
list, that's a bug. That's not intentional. I've seen that with btrfs
subvols; that case ought to be fixed in 18.27 IIRC. If you're seeing a
different case, please report it.
partitions shouldn't disappear from the list on the left unless and
until you actually choose to delete them.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
4:42 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
M. Edward (Ed) Borasky píše v St 07. 11. 2012 v 22:06 -0800:
I've now done half a dozen F18 multi-boot installs and I must say
it's
a miracle I haven't over-written something I wanted to keep. The thing
that would make it usable for me would be very simple - just put the
partition names on the labeling so I know what's going to end up
where! The rest of the installer is fine but the partitioner needs
either a user interface redesign or extensive documentation.
Yes, I just did partitioning in the current F18 and I must say it's a
piece of "art". I had old partitions on the disk and wanted to
preserve /home. I don't think I'm an inexperienced user because I've
done countless installations of different systems, but I completely
failed to do what I wanted to do with the new Anaconda. And even Fedora
QA guys, who heavily test it, had hard times to figure out how to do it.
We can't expect any miracle improvements in Anaconda for F18, so we'll
have to live with what we have now. But we'll need some serious
usability testing for F19. And frankly lots of polishing, too, because
let's face it, the current Anaconda is not a pleasure for eyes (but that
bugs me the least about it right now).
Jiri
On Wed, Nov 7, 2012 at 9:31 PM, Kevin Kofler
<kevin.kofler(a)chello.at> wrote:
> Adam Williamson wrote:
>> The new anaconda UI and related features are more or less entirely the
>> cause of the slip.
>
> This shows that those changes should not have been done, or at least not in
> this way.
>
>> Secure boot support is also not done yet (waiting on the signature for
>> shim to get sorted out by legal), though I don't know whether FESCo yet
>> absolutely decided that has to be in for Beta.
>
> And Restricted Boot support just needs to go away!
>
> Kevin Kofler
>
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
--
Twitter: http://twitter.com/znmeb; Computational Journalism Publishers
Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/
How the Hell can the lion sleep with all those people singing "A weem
oh way!" at the top of their lungs?
4:54 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, 2012-11-08 at 11:42 +0100, Jiri Eischmann wrote:
M. Edward (Ed) Borasky píše v St 07. 11. 2012 v 22:06 -0800:
> I've now done half a dozen F18 multi-boot installs and I must say it's
> a miracle I haven't over-written something I wanted to keep. The thing
> that would make it usable for me would be very simple - just put the
> partition names on the labeling so I know what's going to end up
> where! The rest of the installer is fine but the partitioner needs
> either a user interface redesign or extensive documentation.
Yes, I just did partitioning in the current F18 and I must say it's a
piece of "art". I had old partitions on the disk and wanted to
preserve /home. I don't think I'm an inexperienced user because I've
done countless installations of different systems, but I completely
failed to do what I wanted to do with the new Anaconda. And even Fedora
QA guys, who heavily test it, had hard times to figure out how to do it.
We can't expect any miracle improvements in Anaconda for F18, so we'll
have to live with what we have now.
Actually, there are rather a lot in 18.27, with more to come...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:16 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, 2012-11-08 at 06:31 +0100, Kevin Kofler wrote:
Adam Williamson wrote:
> The new anaconda UI and related features are more or less entirely the
> cause of the slip.
This shows that those changes should not have been done, or at least not in
this way.
I think it's widely agreed by now that they could have been done better,
the question is now exactly how we can improve the process.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
4:44 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
----- Original Message -----
On Thu, 2012-11-08 at 06:31 +0100, Kevin Kofler wrote:
> Adam Williamson wrote:
> > The new anaconda UI and related features are more or less
> > entirely the
> > cause of the slip.
>
> This shows that those changes should not have been done, or at
> least not in
> this way.
I think it's widely agreed by now that they could have been done
better,
the question is now exactly how we can improve the process.
We have bigger issue with features that are OUT OF the process,
not communicated at all. If you take a look on New Installer UI,
it fits current design, it was a late as the scope was bigger
than Anaconda team thought but it's there.
But the new upgrade process - it should be standalone feature,
we missed dracut feature, same for LVM in Anaconda (again, not
UI), live medias etc. So most of the problems were caused not by
proposed/accepted features but by real features we weren't aware of.
How to avoid it? Honestly I don't know. What can help is to
make Feature process easier, so more people would participate
as it's all about feature visibility, offload FESCo from
that self-contained/leaf packages and give them time to work
on critical path ones...
https://fedorahosted.org/fesco/ticket/896#comment:9
Jaroslav
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
4:55 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, 2012-11-08 at 05:44 -0500, Jaroslav Reznik wrote:
----- Original Message -----
> On Thu, 2012-11-08 at 06:31 +0100, Kevin Kofler wrote:
> > Adam Williamson wrote:
> > > The new anaconda UI and related features are more or less
> > > entirely the
> > > cause of the slip.
> >
> > This shows that those changes should not have been done, or at
> > least not in
> > this way.
>
> I think it's widely agreed by now that they could have been done
> better,
> the question is now exactly how we can improve the process.
We have bigger issue with features that are OUT OF the process,
not communicated at all. If you take a look on New Installer UI,
it fits current design, it was a late as the scope was bigger
than Anaconda team thought but it's there.
But the new upgrade process - it should be standalone feature,
we missed dracut feature, same for LVM in Anaconda (again, not
UI), live medias etc. So most of the problems were caused not by
proposed/accepted features but by real features we weren't aware of.
How to avoid it? Honestly I don't know.
Well, a more stringent review process for the New UI feature would
likely have identified this problem ahead of time.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
6:42 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 8, 2012 at 4:55 AM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Thu, 2012-11-08 at 05:44 -0500, Jaroslav Reznik wrote:
> ----- Original Message -----
> > On Thu, 2012-11-08 at 06:31 +0100, Kevin Kofler wrote:
> > > Adam Williamson wrote:
> > > > The new anaconda UI and related features are more or less
> > > > entirely the
> > > > cause of the slip.
> > >
> > > This shows that those changes should not have been done, or at
> > > least not in
> > > this way.
> >
> > I think it's widely agreed by now that they could have been done
> > better,
> > the question is now exactly how we can improve the process.
>
> We have bigger issue with features that are OUT OF the process,
> not communicated at all. If you take a look on New Installer UI,
> it fits current design, it was a late as the scope was bigger
> than Anaconda team thought but it's there.
>
> But the new upgrade process - it should be standalone feature,
> we missed dracut feature, same for LVM in Anaconda (again, not
> UI), live medias etc. So most of the problems were caused not by
> proposed/accepted features but by real features we weren't aware of.
>
> How to avoid it? Honestly I don't know.
Well, a more stringent review process for the New UI feature would
likely have identified this problem ahead of time.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
My problem isn't that the cycles are longer, it's that Fedora as a project
hasn't gotten better at scheduling releases.
I know that over the years, Anaconda has been rewritten at nearly all
levels, and that the UI part is pretty much one of the few things left from
the older codebase. With the experience that the Fedora team has and that
Red Hat has with developing UI code in Python, I'm still surprised that
estimating the challenges of rewriting the UI and beating it into shape for
release wasn't fully possible.
I know that software development is hard. Software Engineering is an
extremely difficult process. I just thought that with all the wonderful,
experienced people here, Fedora as a whole would have had a better idea of
how *hard* this would be and properly account for it.
The other problem is that it continues to make Fedora as a project look
bad. I've talked to people who use Fedora (who aren't involved in the
project in any form or fashion), and it's a rather annoying pain point that
they *don't know when to expect the next Fedora release*. The fact that
we've cultivated that expectation is highly disappointing for a project
that does the traditional biannual stable release model. It's a pretty
large motivator to keep talking about moving to the rolling release model.
And yes, I've read all the threads, and I know all the reasons.
Regardless of all that, we need to be better about communicating that we
use a feature-based release scheme as opposed to a time-based release
scheme. There are trade-offs to both approaches, but at least with clear
communication, we set the right expectations.
6:56 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
[snip]
The other problem is that it continues to make Fedora as a project look
bad. I've talked to people who use Fedora (who aren't involved in the
I disagree.
It is far better to have the release slipped in order to fix blocker bugs. We
have a nice QA and this improves the Fedora quality.
Of course, this time it is an exception and don't have to be seen on an other
way. That does not prevent us to work on a better release schedule of course, if
we can find a better solution.
project in any form or fashion), and it's a rather annoying pain
point that
they *don't know when to expect the next Fedora release*. The fact that
Fedora is a leading GNU/Linux distribution. Lot of people are waiting for the
last Fedora release to get the best of the Free and Open Source software.
We are not a comercial product dealing with licence updates and other things.
Lot of people love Fedora but don't like to update every year.. But they did.
Because this is how we manage to lead the effort, to move forward.
Sometimes, you hit a red light. This is where you can evaluate your community
and see how strong you are to react, and see what decision you take.
Changing the release cycle would take time and change the whole perspective.
Moving back to the old Anaconda would take time. Every schedule change take
time. What we actually need is to move forward as soon as possible, but
smoothly.
The real question is how can we (devs not yet anaconda contributors) help the
Anaconda team if do-able, *now*.
[snip]
Regardless of all that, we need to be better about communicating that
we
use a feature-based release scheme as opposed to a time-based release
scheme. There are trade-offs to both approaches, but at least with clear
communication, we set the right expectations.
I agree, communication helps to prevent many issues.
--
Kévin Raymond
(Shaiton)
7:37 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 12:42 PM, Conan Kudo (ニール・ゴンパ) wrote:
The other problem is that it continues to make Fedora as a project
look bad
How Fedora looks is in the hands of the beholder.
While you see the delayed release as a negative thing I see it as a
positive and a strong thing since from where I'm standing I would rather
have us delay until deemed ready and release something usable in the
hands of our end user base rather then chasing down and be fixed on
releasing on some arbitrary release date no matter how broken ( or not
broken ) it is...
JBG
11:44 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, 2012-11-08 at 06:42 -0600, Conan Kudo (ニール・ゴンパ) wrote:
Regardless of all that, we need to be better about communicating
that
we use a feature-based release scheme as opposed to a time-based
release scheme. There are trade-offs to both approaches, but at least
with clear communication, we set the right expectations.
We don't, really. The schedule is still broadly time-based. For other
recent releases, there has been substantial pressure to push the release
once the slip reached 3 weeks, regardless of quality. And we absolutely
don't wait for all features to be 'done' to ship a release. 18 isn't
getting delayed because newUI is a Feature and it's not Done, but
because newUI is a feature _that happens to be a rewrite of the
installer_, the most critical part of the distribution. Even the most
time-focused people on Board, FESCo, QA etc teams have been agreed that
what we've had so far is just not shippable from a quality POV. 18 isn't
held up because its features aren't done, it's held up because we just
can't ship something with the current bug set and lack of an upgrade
mechanism.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:43 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Adam Williamson wrote:
lack of an upgrade mechanism.
Yum is an upgrade mechanism. Now you may run into issues with SELinux this
time around, but that is just yet another example of how enabling SELinux by
default was a major mistake, and thankfully there are workarounds (doing the
upgrade with SELinux in permissive rather than enforcing mode probably being
the safest one, or just disabling SELinux and keeping it that way, of
course).
Kevin Kofler
1:45 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, 2012-11-09 at 07:43 +0100, Kevin Kofler wrote:
Adam Williamson wrote:
> lack of an upgrade mechanism.
Yum is an upgrade mechanism. Now you may run into issues with SELinux this
time around, but that is just yet another example of how enabling SELinux by
default was a major mistake, and thankfully there are workarounds (doing the
upgrade with SELinux in permissive rather than enforcing mode probably being
the safest one, or just disabling SELinux and keeping it that way, of
course).
It's not one of our supported upgrade mechanisms, and there appears to
be no chance of that changing. Please don't warm over that argument
again. The messaging and optics of saying 'yum is a supported upgrade
mechanism, but just for F18 beta! We'll have a new mechanism for F18
final! Which won't have been tested much at all! And yum will be evil
again! So use it now! But don't use it again ever!' really suck. Which
is why no-one wants to do it.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
6:12 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Adam Williamson wrote:
It's not one of our supported upgrade mechanisms, and there
appears to
be no chance of that changing.
That's the whole problem. Why is our most reliable upgrade mechanism not
"supported"?
Please don't warm over that argument again.
Why not?
The messaging and optics of saying 'yum is a supported upgrade
mechanism,
but just for F18 beta! We'll have a new mechanism for F18 final! Which
won't have been tested much at all! And yum will be evil again! So use it
now! But don't use it again ever!' really suck. Which is why no-one wants
to do it.
Which is why we shouldn't do it. Instead, we should say that yum is the
supported upgrade mechanism for F18 (postponing fedup to F19 or releasing it
as a tech preview for F18 depending on how things go) and that it will
remain a supported alternative in the future if it works out.
Kevin Kofler
6:24 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Am 10.11.2012 01:12, schrieb Kevin Kofler:
Adam Williamson wrote:
> It's not one of our supported upgrade mechanisms, and there appears to
> be no chance of that changing.
That's the whole problem. Why is our most reliable upgrade mechanism not
"supported"?
> Please don't warm over that argument again.
Why not?
i too do not understand why YUM is not the primary supported method
* it works much more relieable in most acses
* it gives better control
the arguments "after released updates you do not have a tested
migration path" is invalid - two months after the release you
also do NOT have a tested migration path because you got updates
for the previews version - this affects preupgrade also as update
with DVD
with the DVD method you even have NO WAY to fix issues because
the ISO images keep static and the installed OS gets updates
instead waste time for preupgrade or whatever replacemanet the
time could be spent for improvements in the yum upgrade-howto
6:31 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Sat, 2012-11-10 at 01:12 +0100, Kevin Kofler wrote:
Adam Williamson wrote:
> It's not one of our supported upgrade mechanisms, and there appears to
> be no chance of that changing.
That's the whole problem. Why is our most reliable upgrade mechanism not
"supported"?
> Please don't warm over that argument again.
Why not?
Because it's a complete and utter waste of time to keep reanimating the
argument without making any different points. You make your points
again, the other side makes its points again, nothing changes and you
have all wasted your time. Why bother?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
7:19 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Could you provide a link to that discussion?
Thanks
2012/11/9 Adam Williamson <awilliam(a)redhat.com>
On Sat, 2012-11-10 at 01:12 +0100, Kevin Kofler wrote:
> Adam Williamson wrote:
> > It's not one of our supported upgrade mechanisms, and there appears to
> > be no chance of that changing.
>
> That's the whole problem. Why is our most reliable upgrade mechanism not
> "supported"?
>
> > Please don't warm over that argument again.
>
> Why not?
Because it's a complete and utter waste of time to keep reanimating the
argument without making any different points. You make your points
again, the other side makes its points again, nothing changes and you
have all wasted your time. Why bother?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
7:44 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Sat, 2012-11-10 at 01:19 +0000, Carl G wrote:
Could you provide a link to that discussion?
Oh, god, it's been dragged up at least three times that I remember. I
don't really want to spend my afternoon dredging my archives to find the
precise links, but I'd recommend browsing the results of the search
string "yum upgrade kofler
site:https://lists.fedoraproject.org/pipermail/devel/";. One result of
this is
https://lists.fedoraproject.org/pipermail/devel/2012-January/161819.html , which was
probably the last time Kevin brought it up. If you go back further I'm sure you'll
find many more.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
10:43 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/10/2012 01:19 AM, Carl G wrote:
Could you provide a link to that discussion?
pick a release cycle and go through the mailinglist archives.
It's one of those topics that resurface on each of them so you should
not have a hard time finding something in each of them...
JBG
10:37 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/10/2012 12:12 AM, Kevin Kofler wrote:
Adam Williamson wrote:
> >It's not one of our supported upgrade mechanisms, and there appears to
> >be no chance of that changing.
That's the whole problem. Why is our most reliable upgrade mechanism not
"supported"?
For the first QA got completely bypass in that decision if we should
"officially support" upgrades in the first place but left with cleaning
up that mess ( its no way we could have covered every package installed
combination in the project ) when that pandora box was open, we actual
have testers that do yum upgrades and report any mistakes and it's
thanks to them that it works as smooth as it does and this release cycle
we even discussed adjusted the criteria to cover either or ( yum
upgrade/preupgrade or fedup ).
The fact remains however that we cant "properly" support it until we
default to btrfs and implement the ability for our userbase to fall back
to an snapshot that was taken before upgrade for our users to fallback
on encase shit hits the fan. ( despite whom ever made that decision to
official support it )
I however neither upgrade nor recommend upgrades because I have better
things to do with my time than spending hours cleaning up after the
upgrades and rather choose to have my /home on separated partitions and
do fresh install and reuse it once I have fixed Gnome not being able to
properly handle upgrades within Gnome itself for my user account ( which
takes half an hour hour tops to fix )
JBG
10:08 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 08, 2012 at 02:55:19AM -0800, Adam Williamson wrote:
On Thu, 2012-11-08 at 05:44 -0500, Jaroslav Reznik wrote:
> ----- Original Message -----
> > On Thu, 2012-11-08 at 06:31 +0100, Kevin Kofler wrote:
> > > Adam Williamson wrote:
> > > > The new anaconda UI and related features are more or less
> > > > entirely the
> > > > cause of the slip.
> > >
> > > This shows that those changes should not have been done, or at
> > > least not in
> > > this way.
> >
> > I think it's widely agreed by now that they could have been done
> > better,
> > the question is now exactly how we can improve the process.
>
> We have bigger issue with features that are OUT OF the process,
> not communicated at all. If you take a look on New Installer UI,
> it fits current design, it was a late as the scope was bigger
> than Anaconda team thought but it's there.
>
> But the new upgrade process - it should be standalone feature,
> we missed dracut feature, same for LVM in Anaconda (again, not
> UI), live medias etc. So most of the problems were caused not by
> proposed/accepted features but by real features we weren't aware of.
>
> How to avoid it? Honestly I don't know.
Well, a more stringent review process for the New UI feature would
likely have identified this problem ahead of time.
I think this is part of a well-needed overhaul of the feature process
anyway, but yes, review earlier would have caught a lot of these details and
not surprised people.
See, it goes back to communication and setting expectations. :)
--
David Cantrell <dcantrell(a)redhat.com>
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
10:07 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 08, 2012 at 05:44:41AM -0500, Jaroslav Reznik wrote:
----- Original Message -----
> On Thu, 2012-11-08 at 06:31 +0100, Kevin Kofler wrote:
> > Adam Williamson wrote:
> > > The new anaconda UI and related features are more or less
> > > entirely the
> > > cause of the slip.
> >
> > This shows that those changes should not have been done, or at
> > least not in
> > this way.
>
> I think it's widely agreed by now that they could have been done
> better,
> the question is now exactly how we can improve the process.
We have bigger issue with features that are OUT OF the process,
not communicated at all. If you take a look on New Installer UI,
it fits current design, it was a late as the scope was bigger
than Anaconda team thought but it's there.
The scope was not a surprise to us, we knew from the beginning when we
started this that the delivery of all newui work would have to be staged
across multiple Fedora releases. The key was getting groups like Fedora QA
and FESCo involved early so that they understood and would help us agree on
what list of items should be priority #1, followed by priority #2, and so
on.
I think we had a lot of people in on that, but we didn't really fully
communicate it well enough to each other. That can be improved in the
future.
But the new upgrade process - it should be standalone feature,
we missed dracut feature, same for LVM in Anaconda (again, not
UI), live medias etc. So most of the problems were caused not by
proposed/accepted features but by real features we weren't aware of.
Perhaps. I think there is also a problem with a lack of what a feature
actually is in Fedora.
In both of these examples, we could argue either way that they are features
or not. It's a new upgrade tool, yes, but it's really just moving the
responsibility of upgrades to somewhere else. So what's the feature? If
upgrades are the feature, we're not really changing anything are we? We're
changing how they're done but you're still getting an upgrade in the end.
Or is the feature the fact that new code is arriving and old code is
leaving?
Likewise with the LVM concern. I completely see the argument from the
storage team's perspective. The entirety of LVM is a feature. But I also
see it from my team's perspective...we're really just changing a default
option in our code. So what's the feature here? Who should own defaults
and policy decisions?
It's complicated, but not impossible.
[Also, these questions are intended as an example for how I can see both
sides of the arguments, *not* catalysts for actual new arguments.]
--
David Cantrell <dcantrell(a)redhat.com>
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
11:04 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 08, 2012 at 11:07:08AM -0500, David Cantrell wrote:
On Thu, Nov 08, 2012 at 05:44:41AM -0500, Jaroslav Reznik wrote:
> But the new upgrade process - it should be standalone feature,
> we missed dracut feature, same for LVM in Anaconda (again, not
> UI), live medias etc. So most of the problems were caused not by
> proposed/accepted features but by real features we weren't aware of.
Perhaps. I think there is also a problem with a lack of what a feature
actually is in Fedora.
https://fedoraproject.org/wiki/Features/Policy/Definitions#Definition_of_...
In both of these examples, we could argue either way that they are
features
or not. It's a new upgrade tool, yes, but it's really just moving the
responsibility of upgrades to somewhere else. So what's the feature? If
upgrades are the feature, we're not really changing anything are we? We're
changing how they're done but you're still getting an upgrade in the end.
Or is the feature the fact that new code is arriving and old code is
leaving?
Ignoring your entirely legitimate questions, but applying the existing
feature definition, the change to the way we upgrade is a Feature:
1) highly user visible changes (beyond artwork or theme changes)
* User no longer performs an upgrade by downloading the DVD/netinstall
and booting from that. The user now runs a tool from the previous
release.
2) improvements or changes that require non-trivial cross-package
integration
* A new package is needed to support upgrades.
* This new package must be done in the same release cycle as the anaconda
release that removes internal support for performing upgrades.
* This test is poorly worded for this sub-reason but the improvement also
requires non-trivial cross-team integration. The QA team needs to be
aware that anaconda no longer does upgrades, that preupgrade no longer
works, and that fedup performs that role. They need to have time to
adjust their tests to account for the new tool and to figure out how
all that fits together in their release testing.
3) exciting new capabilities we can trumpet fedora having[...]improvements
that are Fedora specific
* This is a partial answer to your question about new code arriving and
old code leaving. The answer is that yes, new code may be a feature if
we (Fedora contributors) are doing the work.
4) significant enough that if not completed properly or without a proper
backup plan could delay the release
* As we're seeing now ;-)
5) noteworthy enough to call out in the release notes
* Most of our features fit this even if they don't fit the other criteria
above. Only a relative few, like the libboost upgrades that change ABI
don't fit this. Anything that fits criteria 1) should also fit here.
Likewise with the LVM concern. I completely see the argument from
the
storage team's perspective. The entirety of LVM is a feature. But I also
see it from my team's perspective...we're really just changing a default
option in our code. So what's the feature here? Who should own defaults
and policy decisions?
1) highly user visible changes (beyond artwork or theme changes)
* Possibly. I'm unclear as to precisely what has changed here. If it's
just the default but the user can select custom partitioning and is
able to use LVM there, then this is less valid. If it is no longer
possible to customize the install to use LVM then this is very valid.
2) improvements or changes that require non-trivial cross-package
integration
* This test is poorly worded for this case but it is where I'd want to
include this sort of thing if our Feature process for F19 doesn't get
a drastic overhaul. The change implemented by anaconda has a major
impact on how the work the storage team is doing is presented. Thus it
needs to be coordinated with them.
* We have had many past features that were about changing defaults and
many that were about changing defaults in the installer (for instance,
btrfs by default). These were required to be features and one of the
reasons was that it required code in anaconda to be changed to enable
them. It could be a trivial code change within anaconda but the
anaconda team would need to know about it so that they wouldn't be
surprised that the default was changing or that the code would need to
be changed at all to effect that.
4) significant enough that if not completed properly or without a proper
backup plan could delay the release
* This one is hard to apply here. Due to the release criteria, any
changes to anaconda fall under this. So tis definitely applies to the
code changes. The question is whether it applies to the case for LVM
as a separate Feature from anaconda NewUI.
As for the question: "Who should own defaults and policy decisions?" -- the
answer there is FESCo. For many pieces of software, defaults can be changed
without going to FESCo. Unfortunately, for anaconda (and to a lesser
extent, the kernel and other core pieces of the OS), many of the defaults
that it implements are essential pieces of implementation of other Features
by other teams which hits Feature criteria #2. Since anaconda (and the
kernel and a few other core pieces of the OS) are something that all user's
of the OS have to interact with, changes to default can have an effect on
how the user perceives fedora as a whole which hits Feature criteria #1.
It's not fair that so many of the changes you'd want to do to your software
are going to need to be decided (or at least evaluated) by FESCo whereas
oter pieces of software never have to be reviewed but it seems to reflect
the reality of how central anaconda is to defining what the Fedora
Distribution is.
-Toshio
11:17 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 05:04 PM, Toshio Kuratomi wrote:
> >
1) highly user visible changes (beyond artwork or theme changes)
* Possibly. I'm unclear as to precisely what has changed here. If it's
just the default but the user can select custom partitioning and is
able to use LVM there, then this is less valid. If it is no longer
possible to customize the install to use LVM then this is very vali
The Anaconda version in the latest smoke test ( and few before that )
actually brings the ability to choose to use standard partitioning (
ext4 only ), lvm and btrfs so the whole "lvm not being the default"
discussion was kinda needless since a) this is not a regression from F17
( the installer offered to do that in F17 ) b) It's equally hard/easy
for those that want or do not want lvm to simply choose to use or not
use the lvm layout.
I honestly am not so sure they actually had to specifically get
"approval" to make the change from the storage developers,community or
fesco for that matter...
JBG
1:31 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, 2012-11-08 at 11:07 -0500, David Cantrell wrote:
In both of these examples, we could argue either way that they are
features
or not. It's a new upgrade tool, yes, but it's really just moving the
responsibility of upgrades to somewhere else. So what's the feature? If
upgrades are the feature, we're not really changing anything are we? We're
changing how they're done but you're still getting an upgrade in the end.
Or is the feature the fact that new code is arriving and old code is
leaving?
Yes. This is _absolutely_ a feature. A complete rewrite of a core and
non-optional component cannot be done ad hoc without planning. One
blindingly obvious reason for this in the current situation is that
we're still thrashing around trying to figure out how to build and ship
the initramfs that fedup needs. This is exactly the kind of thing that
needs to go through the feature process so that the relevant groups -
releng, infra - know about it. I don't believe they even knew about the
problem until about two weeks ago.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
2:14 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 08, 2012 at 11:31:18AM -0800, Adam Williamson wrote:
we're still thrashing around trying to figure out how to build
and ship
the initramfs that fedup needs.
"we" are? I see approximately nobody offering assistance in that
respect. Anyway, it obviously gets built by Lorax, just like everything
else under images.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
4:48 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, 8 Nov 2012 20:14:05 +0000
Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
On Thu, Nov 08, 2012 at 11:31:18AM -0800, Adam Williamson wrote:
> we're still thrashing around trying to figure out how to build and
> ship the initramfs that fedup needs.
"we" are? I see approximately nobody offering assistance in that
respect.
If it would make you feel better, I can stop building test images,
updating test repos, testing fedup, writing documentation, answering
questions in bugzilla as best I can and attempting to help coordinate.
I'm obviously not helping in the least and it sounds like my time would
be better spent elsewhere. It'd certainly take things off my plate and
then you can do the work.
My skill set is not infinite. Sure, I could drop everything that I'm
doing in an attempt to wrap my head around how dracut and systemd are
used during upgrades so that I can help write the code needed for
fedup. However, I suspect that it would not only be incredibly
inefficient and slow down any testing efforts I'm involved in but I
would probably ask so many questions that I would just slow down the
development process. That sounds like a great plan.
Anyway, it obviously gets built by Lorax, just like
everything else under images.
Which is why I've gotten multiple answers on how the initramfs is going
to be generated, what it's going to look like and there's nothing
written about it in the official docs. It's so obvious, the answer
hasn't been consistent over time, releng has had very little idea of
what's going on and to the best of my knowledge, almost nothing has been
written down about the process.
Look, I realize that Will is getting the short end of the stick here
but there's not a whole lot that I, Adam or most of the rest of the QA
folks can do about that at the moment. We don't have the needed skills
right now and there are other things that need to be done outside fedup
development before F18 can be released. The best thing we can do right
now is to continue supporting development via testing, filing bugs and
coordination.
I'm doing my best to help in any way that I can so that Will (and anyone
else capable of helping with development) can focus on getting the stuff
done that he seems to be uniquely qualified for. Adam and _many_ other
people are working really hard to test F18, file bugs and help make
sure that when F18 is released, it's something we can all be proud of.
Asserting that we aren't helping in any way is incredibly insulting and
in my opinion, rather naive. I realize that I don't write code that gets
shipped with Fedora and I realize that through some eyes, that's what
happens when you have no talent or useful skills. If that's what you
want to think, go for it; you wouldn't be the first person to think so
and I sincerely doubt that you'd be the last.
Tim
5 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 08, 2012 at 03:48:31PM -0700, Tim Flink wrote:
On Thu, 8 Nov 2012 20:14:05 +0000
Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
> "we" are? I see approximately nobody offering assistance in that
> respect.
If it would make you feel better, I can stop building test images,
updating test repos, testing fedup, writing documentation, answering
questions in bugzilla as best I can and attempting to help coordinate.
I'm obviously not helping in the least and it sounds like my time would
be better spent elsewhere. It'd certainly take things off my plate and
then you can do the work.
Oh man I'm sorry - I meant other than you and Will, and I'm hugely sorry
that it sounded like I didn't think you were being useful here. I really
really don't want to make it seem like I don't appreciate all of that.
But we do have many people who are nominally active in writing code who
are doing absolutely nothing here.
Asserting that we aren't helping in any way is incredibly
insulting and
in my opinion, rather naive. I realize that I don't write code that gets
shipped with Fedora and I realize that through some eyes, that's what
happens when you have no talent or useful skills. If that's what you
want to think, go for it; you wouldn't be the first person to think so
and I sincerely doubt that you'd be the last.
Again, my wholehearted apologies. That wasn't my intention.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
5:39 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, 8 Nov 2012 23:00:42 +0000
Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
On Thu, Nov 08, 2012 at 03:48:31PM -0700, Tim Flink wrote:
> On Thu, 8 Nov 2012 20:14:05 +0000
> Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
> > "we" are? I see approximately nobody offering assistance in that
> > respect.
>
> If it would make you feel better, I can stop building test images,
> updating test repos, testing fedup, writing documentation, answering
> questions in bugzilla as best I can and attempting to help
> coordinate. I'm obviously not helping in the least and it sounds
> like my time would be better spent elsewhere. It'd certainly take
> things off my plate and then you can do the work.
Oh man I'm sorry - I meant other than you and Will, and I'm hugely
sorry that it sounded like I didn't think you were being useful here.
I really really don't want to make it seem like I don't appreciate
all of that. But we do have many people who are nominally active in
writing code who are doing absolutely nothing here.
That may be true but that isn't true of everyone. I understand your
frustration, I just think it was directed at the wrong person who
happened to say "we". Adam isn't doing much with fedup at the moment but
I'm not doing much anaconda testing at the moment, either and it's not
a coincidence.
I'm of the opinion that more widespread testing of fedup isn't really
going to help right now until a couple of bugs are fixed. I'm not
blaming anyone; we are where we are and the blame game is counter
productive right now. I just don't see the point in creating more noise
than we need to at the moment.
When it's ready, I'm certain that plenty of QA (and not-always-qa) folks
will be testing fedup.
> Asserting that we aren't helping in any way is incredibly
insulting
> and in my opinion, rather naive. I realize that I don't write code
> that gets shipped with Fedora and I realize that through some eyes,
> that's what happens when you have no talent or useful skills. If
> that's what you want to think, go for it; you wouldn't be the first
> person to think so and I sincerely doubt that you'd be the last.
Again, my wholehearted apologies. That wasn't my intention.
No worries. We're all in this boat together, wherever it ends up. I
think that I'm with most people here in hoping that the boat ends up
at a good release without more slipping :)
Tim
8:02 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, 2012-11-08 at 16:39 -0700, Tim Flink wrote:
On Thu, 8 Nov 2012 23:00:42 +0000
Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
> On Thu, Nov 08, 2012 at 03:48:31PM -0700, Tim Flink wrote:
> > On Thu, 8 Nov 2012 20:14:05 +0000
> > Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
> > > "we" are? I see approximately nobody offering assistance in that
> > > respect.
> >
> > If it would make you feel better, I can stop building test images,
> > updating test repos, testing fedup, writing documentation, answering
> > questions in bugzilla as best I can and attempting to help
> > coordinate. I'm obviously not helping in the least and it sounds
> > like my time would be better spent elsewhere. It'd certainly take
> > things off my plate and then you can do the work.
>
> Oh man I'm sorry - I meant other than you and Will, and I'm hugely
> sorry that it sounded like I didn't think you were being useful here.
> I really really don't want to make it seem like I don't appreciate
> all of that. But we do have many people who are nominally active in
> writing code who are doing absolutely nothing here.
That may be true but that isn't true of everyone. I understand your
frustration, I just think it was directed at the wrong person who
happened to say "we". Adam isn't doing much with fedup at the moment but
I'm not doing much anaconda testing at the moment, either and it's not
a coincidence.
Sorry for introducing the confusion. When I said 'we' I was thinking of
'anaconda team and QA team' - as Tim pointed out, he's been working more
or less exclusively on testing, debugging, documenting, co-ordinating
and generally helping out with fedup for the last week or so. I and the
rest of the QA team have been working on anaconda testing and keeping
the test day cycle going. Division of labour :)
Aside from that - I can understand your frustration that you think
people are chinwagging and not helping, but my point is kind of that you
(anaconda team) have brought that on yourselves. You regret the lack of
contribution, and dcantrell talks about problems with communication: one
of the main points of the feature process is precisely to act as a hub
for communication and contribution. If fedup had gone through the
feature process, people would have known about it, and if the feature
description had been done correctly, people would have known far earlier
that we needed to figure out stuff like packaging for F16 and F17,
generation and shipping of the initramfs, and so on.
We wouldn't have wound up in the situation we're in now where Will is
tied to his desk frantically coding the thing and Tim - who has no
official standing - is trying to prod other groups into action to deal
with things like documentation and testing and providing the appropriate
infrastructure for building and shipping various bits of the framework,
while simultaneously trying to make sure he actually knows what needs
doing and is prodding the right people in the right direction (which
involves bugging Will, who would rather just be coding). If fedup had
been run through the feature process, FESCo - which has a lot more
prominence and weight - would have done that weeks or months ago, and
all the groups ought to have been on board and known what they needed to
do. Everyone would still have had their own idea on what color the
initramfs bikeshed should be, but they would also have known what color
FESCo had decided it was going to be, and they would be working together
to paint it that color, even if they were grumbling the whole time that
it was a stupid color and their idea for the color was way better.
No-one would be able to play the 'well we have no idea what the hell is
going on, no-one told us' card. That's how Fedora works when it's
working right; we all still think our plan is the best one, but we work
on the plan that got agreed on anyway. If we don't use the position and
oomph of a group like FESCo to agree on a plan ahead of time (however
fractious the process of agreement is), we wind up in this mess; the
buck-passing and chinwagging is kind of just an inevitable outcome when
the decisions aren't made sufficiently clearly and sufficiently far
ahead of time.
I'm of the opinion that more widespread testing of fedup
isn't really
going to help right now until a couple of bugs are fixed. I'm not
blaming anyone; we are where we are and the blame game is counter
productive right now. I just don't see the point in creating more noise
than we need to at the moment.
When it's ready, I'm certain that plenty of QA (and not-always-qa) folks
will be testing fedup.
> > Asserting that we aren't helping in any way is incredibly insulting
> > and in my opinion, rather naive. I realize that I don't write code
> > that gets shipped with Fedora and I realize that through some eyes,
> > that's what happens when you have no talent or useful skills. If
> > that's what you want to think, go for it; you wouldn't be the first
> > person to think so and I sincerely doubt that you'd be the last.
>
> Again, my wholehearted apologies. That wasn't my intention.
No worries. We're all in this boat together, wherever it ends up. I
think that I'm with most people here in hoping that the boat ends up
at a good release without more slipping :)
Amen!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
8:47 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 08, 2012 at 06:02:10PM -0800, Adam Williamson wrote:
Aside from that - I can understand your frustration that you think
people are chinwagging and not helping, but my point is kind of that you
(anaconda team) have brought that on yourselves.
I'm not on the Anaconda team. That's my point. When bugs threaten the
release of the distribution then *everyone* involved in the distribution
should be willing to work on them, not just insist that it's up to the
developers currently working on it. I've just spent two days of vacation
working on this because it's clear that more developer contribution
would be useful and because I actually want us to release Fedora 18.
We're not obliged to sit here pointing at a sinking ship when we could
do something to avoid that ship from sinking.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
2:15 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, 2012-11-09 at 14:47 +0000, Matthew Garrett wrote:
On Thu, Nov 08, 2012 at 06:02:10PM -0800, Adam Williamson wrote:
> Aside from that - I can understand your frustration that you think
> people are chinwagging and not helping, but my point is kind of that you
> (anaconda team) have brought that on yourselves.
I'm not on the Anaconda team. That's my point. When bugs threaten the
release of the distribution then *everyone* involved in the distribution
should be willing to work on them, not just insist that it's up to the
developers currently working on it. I've just spent two days of vacation
working on this because it's clear that more developer contribution
would be useful and because I actually want us to release Fedora 18.
We're not obliged to sit here pointing at a sinking ship when we could
do something to avoid that ship from sinking.
Correction accepted - I tend to think of you as an honorary member
because you always pop up in #anaconda :) But my point stands too: there
would have been much more co-operation and contribution if fedup had
gone through the feature process correctly, as that is one thing the
feature process achieves.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
11:35 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 11:31 AM, Adam Williamson wrote:
Yes. This is_absolutely_ a feature. A complete rewrite of a core
and
non-optional component cannot be done ad hoc without planning. One
blindingly obvious reason for this in the current situation is that
we're still thrashing around trying to figure out how to build and ship
the initramfs that fedup needs. This is exactly the kind of thing that
needs to go through the feature process so that the relevant groups -
releng, infra - know about it. I don't believe they even knew about the
problem until about two weeks ago.
I think the unfortunate thing here is that we're trying to use "Feature"
to handle cross team coordination.
--
Help me fight child abuse: http://tinyurl.com/jlkcourage
- jlk
2:05 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, Nov 09, 2012 at 09:35:42AM -0800, Jesse Keating wrote:
On 11/08/2012 11:31 AM, Adam Williamson wrote:
>Yes. This is_absolutely_ a feature. A complete rewrite of a core and
>non-optional component cannot be done ad hoc without planning. One
>blindingly obvious reason for this in the current situation is that
>we're still thrashing around trying to figure out how to build and ship
>the initramfs that fedup needs. This is exactly the kind of thing that
>needs to go through the feature process so that the relevant groups -
>releng, infra - know about it. I don't believe they even knew about the
>problem until about two weeks ago.
I think the unfortunate thing here is that we're trying to use
"Feature" to handle cross team coordination.
Why unfortunate? That is one of the two issues the Feature Process was
created to address.
If it's unfortunate because the two issues the feature process attempts to
solve don't really have as much in common as once thought, that's cool and
probably the number one thing that everyone would like to fix -- I'm just
checking that you don't have some other idea in mind.
-Toshio
2:34 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 12:05 PM, Toshio Kuratomi wrote:
On Fri, Nov 09, 2012 at 09:35:42AM -0800, Jesse Keating wrote:
> On 11/08/2012 11:31 AM, Adam Williamson wrote:
>> Yes. This is_absolutely_ a feature. A complete rewrite of a core and
>> non-optional component cannot be done ad hoc without planning. One
>> blindingly obvious reason for this in the current situation is that
>> we're still thrashing around trying to figure out how to build and ship
>> the initramfs that fedup needs. This is exactly the kind of thing that
>> needs to go through the feature process so that the relevant groups -
>> releng, infra - know about it. I don't believe they even knew about the
>> problem until about two weeks ago.
>
> I think the unfortunate thing here is that we're trying to use
> "Feature" to handle cross team coordination.
>
Why unfortunate? That is one of the two issues the Feature Process was
created to address.
If it's unfortunate because the two issues the feature process attempts to
solve don't really have as much in common as once thought, that's cool and
probably the number one thing that everyone would like to fix -- I'm just
checking that you don't have some other idea in mind.
Don't have anything else in mind.
--
Jesse Keating
Fedora -- Freedom² is a feature!
2:21 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, 2012-11-09 at 09:35 -0800, Jesse Keating wrote:
On 11/08/2012 11:31 AM, Adam Williamson wrote:
> Yes. This is_absolutely_ a feature. A complete rewrite of a core and
> non-optional component cannot be done ad hoc without planning. One
> blindingly obvious reason for this in the current situation is that
> we're still thrashing around trying to figure out how to build and ship
> the initramfs that fedup needs. This is exactly the kind of thing that
> needs to go through the feature process so that the relevant groups -
> releng, infra - know about it. I don't believe they even knew about the
> problem until about two weeks ago.
I think the unfortunate thing here is that we're trying to use "Feature"
to handle cross team coordination.
It may not be the best possible system, but I'm fairly confident it
would have worked better than what we actually did. Which, for fedup,
appears to have been 'nothing'. Until Tim started trying to actually
test fedup, I believe there had no attempt by any party to consider what
work other parties might have to do to make fedup fly.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:49 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
David Cantrell wrote:
The scope was not a surprise to us, we knew from the beginning when
we
started this that the delivery of all newui work would have to be staged
across multiple Fedora releases. The key was getting groups like Fedora
QA and FESCo involved early so that they understood and would help us
agree on what list of items should be priority #1, followed by priority
#2, and so on.
Planned regressions are just plain unacceptable. The rewrite should never
have entered Rawhide before being ready (or expected to be ready by that
release's Alpha). Either maintain a stable branch in parallel, or if you
can't do that, don't do the rewrite at all!
Kevin Kofler
12:51 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, 2012-11-09 at 07:49 +0100, Kevin Kofler wrote:
David Cantrell wrote:
> The scope was not a surprise to us, we knew from the beginning when we
> started this that the delivery of all newui work would have to be staged
> across multiple Fedora releases. The key was getting groups like Fedora
> QA and FESCo involved early so that they understood and would help us
> agree on what list of items should be priority #1, followed by priority
> #2, and so on.
Planned regressions are just plain unacceptable. The rewrite should never
have entered Rawhide before being ready (or expected to be ready by that
release's Alpha). Either maintain a stable branch in parallel, or if you
can't do that, don't do the rewrite at all!
And you are of course offering to help to either:
1) Patch the regressions
2) maintain the stable branch in parallel with the development branch
(with all the arguments which have been mentioned earlier on this list
as to why this was not done)
Thank you Kevin!
Pierre
5:11 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 8, 2012 at 5:07 PM, David Cantrell <dcantrell(a)redhat.com> wrote:
On Thu, Nov 08, 2012 at 05:44:41AM -0500, Jaroslav Reznik wrote:
> We have bigger issue with features that are OUT OF the process,
> not communicated at all. If you take a look on New Installer UI,
> it fits current design, it was a late as the scope was bigger
> than Anaconda team thought but it's there.
The scope was not a surprise to us, we knew from the beginning when we
started this that the delivery of all newui work would have to be staged
across multiple Fedora releases.
It _was_ probably a surprise to some of us in FESCo.
If you look at the NewInstallerUI feature, there's very little
indication that there is a plan to stage things across releases -
there is only a single mention of F19 related to a feature that is
really not that important for the average Fedora user.
I suppose what happened here was, that the Anaconda team knew that
they want to do a multi-release transition, "it was obvious", so it
wasn't really emphasized anywhere - and anyone reading the feature
page didn't find anything wrong about it.
OTOH FESCo started with the assumption that F18 needs to ship with
"the expected functionality", and seeing the feature, "it was
obvious"
that the Anaconda team was proposing the feature within these
constraints.
So nobody even noticed the difference basically until the predecessor
of the detailed https://fedoraproject.org/wiki/Anaconda/Work_List page
was created.
However, I'm not sure that we can solve this kind of disconnect by a
process change.
Mirek
6:16 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Miloslav Trmač wrote:
However, I'm not sure that we can solve this kind of disconnect
by a
process change.
How about a general policy that planned regressions are not acceptable
unless explicitly approved by FESCo? Any feature that you want to remove
(temporarily or permanently) MUST be spelled out on the feature page.
Kevin Kofler
7:43 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Sat, Nov 10, 2012 at 01:16:55AM +0100, Kevin Kofler wrote:
> However, I'm not sure that we can solve this kind of
disconnect by a
> process change.
How about a general policy that planned regressions are not acceptable
unless explicitly approved by FESCo? Any feature that you want to remove
(temporarily or permanently) MUST be spelled out on the feature page.
Here's the problem: if this is the requirement for a feature, then
regressions will just be done as "it's not a feature, it's just the new
version of upstream project X!"
That doesn't buy anyone anything.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
8:23 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Matthew Miller wrote:
On Sat, Nov 10, 2012 at 01:16:55AM +0100, Kevin Kofler wrote:
> > However, I'm not sure that we can solve this kind of disconnect by a
> > process change.
> How about a general policy that planned regressions are not acceptable
> unless explicitly approved by FESCo? Any feature that you want to remove
> (temporarily or permanently) MUST be spelled out on the feature page.
Here's the problem: if this is the requirement for a feature, then
regressions will just be done as "it's not a feature, it's just the new
version of upstream project X!"
That doesn't buy anyone anything.
But they wouldn't be able to claim a misunderstanding as now and FESCo would
have a standing for requesting a reversion. Plus, in this case, Anaconda
isn't an "upstream project" in the first place, we are upstream.
Kevin Kofler
10:21 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 06:23 PM, Kevin Kofler wrote:
But they wouldn't be able to claim a misunderstanding as now and
FESCo would
have a standing for requesting a reversion. Plus, in this case, Anaconda
isn't an "upstream project" in the first place, we are upstream.
Fedora is just one of the downstream users of Anaconda. It is incorrect
to assume that the upstream Anaconda development can be dictated solely
by Fedora, any more than upstream RPM development can be dictated solely
by Fedora.
--
Jesse Keating
Fedora -- Freedom² is a feature!
1:21 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Jesse Keating wrote:
Fedora is just one of the downstream users of Anaconda. It is
incorrect
to assume that the upstream Anaconda development can be dictated solely
by Fedora, any more than upstream RPM development can be dictated solely
by Fedora.
If you want to be truly independent of Fedora, you need to do your
development elsewhere and only import finished and fully working upstream
releases into Rawhide (which need to be testable by Alpha and 100% complete
by Beta), as for any other upstream project in the critical path.
As long as you (ab)use Rawhide to do upstream development and alpha-testing
in, Fedora WILL dictate how you do development.
Kevin Kofler
6:31 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Nov 10, 2012, at 11:21 AM, Kevin Kofler wrote:
Jesse Keating wrote:
> Fedora is just one of the downstream users of Anaconda. It is incorrect
> to assume that the upstream Anaconda development can be dictated solely
> by Fedora, any more than upstream RPM development can be dictated solely
> by Fedora.
If you want to be truly independent of Fedora, you need to do your
development elsewhere and only import finished and fully working upstream
releases into Rawhide (which need to be testable by Alpha and 100% complete
by Beta), as for any other upstream project in the critical path.
As long as you (ab)use Rawhide to do upstream development and alpha-testing
in, Fedora WILL dictate how you do development.
Sorry, that's not a hard requirement of any other upstream, and KDE/Gnome have
frequently used snapshots in rawhide/branched.
But nice try.
--jlk
12:01 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Sat, 10 Nov 2012, Jesse Keating wrote:
On Nov 10, 2012, at 11:21 AM, Kevin Kofler wrote:
> Jesse Keating wrote:
>> Fedora is just one of the downstream users of Anaconda. It is incorrect
>> to assume that the upstream Anaconda development can be dictated solely
>> by Fedora, any more than upstream RPM development can be dictated solely
>> by Fedora.
>
> If you want to be truly independent of Fedora, you need to do your
> development elsewhere and only import finished and fully working upstream
> releases into Rawhide (which need to be testable by Alpha and 100% complete
> by Beta), as for any other upstream project in the critical path.
>
> As long as you (ab)use Rawhide to do upstream development and alpha-testing
> in, Fedora WILL dictate how you do development.
>
Sorry, that's not a hard requirement of any other upstream, and KDE/Gnome have
frequently used snapshots in rawhide/branched.
Jesse,
To be fair - gnome/kde importing something into rawhide/branched
that's not finished doesn't shut down everyone else's ability to test the
distro....
I think it is disingenuous to talk about another distro using anaconda
- b/c the only other one that does, directly, is rhel - and they're
downstream of fedora, too. That doesn't mean things can be dictated - but
it does mean that breaking/delaying fedora is not something that should be
done lightly.
I think holding anaconda to higher standards is not a ridiculous
concept. For years the requirement for yum and rpm (even in rawhide) has
been 'never commit something so broken it cannot be used to revert itself'.
but I'm positive that this conversation is long past the point of
productivity so...
-sv
10:16 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/11/2012 10:01 PM, Seth Vidal wrote:
Jesse,
To be fair - gnome/kde importing something into rawhide/branched
that's not finished doesn't shut down everyone else's ability to test
the distro....
I think it is disingenuous to talk about another distro using anaconda -
b/c the only other one that does, directly, is rhel - and they're
downstream of fedora, too. That doesn't mean things can be dictated -
but it does mean that breaking/delaying fedora is not something that
should be
done lightly.
I think holding anaconda to higher standards is not a ridiculous
concept. For years the requirement for yum and rpm (even in rawhide) has
been 'never commit something so broken it cannot be used to revert itself'.
but I'm positive that this conversation is long past the point of
productivity so...
I can't disagree with this message. I'll also point out that we didn't
have a lot of choices for F18. We could either leave the existing
anaconda package there (which was completely broken) or import the
partially functional newUI code base. We went with the option that
would provide the most functionality, which was the newUI code base.
--
Jesse Keating
Fedora -- Freedom² is a feature!
10:45 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Mon, Nov 12, 2012 at 5:16 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
On 11/11/2012 10:01 PM, Seth Vidal wrote:
>
>
> Jesse,
> To be fair - gnome/kde importing something into rawhide/branched
> that's not finished doesn't shut down everyone else's ability to test
> the distro....
>
>
> I think it is disingenuous to talk about another distro using anaconda -
> b/c the only other one that does, directly, is rhel - and they're
> downstream of fedora, too. That doesn't mean things can be dictated -
> but it does mean that breaking/delaying fedora is not something that
> should be
> done lightly.
>
> I think holding anaconda to higher standards is not a ridiculous
> concept. For years the requirement for yum and rpm (even in rawhide) has
> been 'never commit something so broken it cannot be used to revert
> itself'.
>
> but I'm positive that this conversation is long past the point of
> productivity so...
I can't disagree with this message. I'll also point out that we didn't have
a lot of choices for F18. We could either leave the existing anaconda
package there (which was completely broken) or import the partially
functional newUI code base. We went with the option that would provide the
most functionality, which was the newUI code base.
And there was a third option ... port over the old anaconda to the F18
changes. (so you'd have less changes).
10:49 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/12/2012 08:45 AM, drago01 wrote:
And there was a third option ... port over the old anaconda to the
F18
changes. (so you'd have less changes).
Which would have taken just about as long to get working, and would
delay the newui move further.
But that's OK, you can keep banging that drum.
--
Jesse Keating
Fedora -- Freedom² is a feature!
10:58 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Mon, Nov 12, 2012 at 5:49 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
On 11/12/2012 08:45 AM, drago01 wrote:
>
> And there was a third option ... port over the old anaconda to the F18
> changes. (so you'd have less changes).
Which would have taken just about as long to get working, and would delay
the newui move further.
How so? You'd have to just port over the other layers to work with the
new stuff and in F19 focus on the UI.
Now you had to do both at the same time with the same amount of man power.
But that's OK, you can keep banging that drum.
Yeah I know that something like that would be coming back but well ...
we can't change what happened and unfortunately can't even learn from
the mistakes made because the "everything else is impossible"
attitude.
11:08 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/12/2012 08:58 AM, drago01 wrote:
How so? You'd have to just port over the other layers to work
with the
new stuff and in F19 focus on the UI.
Now you had to do both at the same time with the same amount of man power.
Changes in the dracut environment broke assumptions in the runtime
environment. Code in newUI is different from old code in some of the
same areas, which means doing the work twice instead of once. Not to
mention porting forward all the other bits of F17's anaconda that
doesn't work with F18's userland tools/apis.
--
Jesse Keating
Fedora -- Freedom² is a feature!
11:18 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Mon, Nov 12, 2012 at 05:58:01PM +0100, drago01 wrote:
How so? You'd have to just port over the other layers to work
with the
new stuff and in F19 focus on the UI.
Now you had to do both at the same time with the same amount of man power.
I haven't looked at the new code, but I've spent a _lot_ of time with the
old. I don't think the new UI is just a re-skinning, but is a redesign of
the program's more fundamental architecture. It now supports a "hub and
spoke" model for option selection followed by a second stage where choices
are applied, where as the old model was based around linear steps. That
makes it harder to separate the changes, and I think it very reasonable to
assume that a lot of the backend work would have to have been done twice.
Now, having gone through this, the program is more ready for future
adaptation. Maybe in another decade we'll need another big redesign, but
until then, the current work will make it *more* possible to develop future
Anaconda improvements in Rawhide in parallel with a stable maintenance
branch.
At least, that's my interested-outsider view here.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
11:51 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Seg, 2012-11-12 at 08:49 -0800, Jesse Keating wrote:
On 11/12/2012 08:45 AM, drago01 wrote:
> And there was a third option ... port over the old anaconda to the F18
> changes. (so you'd have less changes).
Which would have taken just about as long to get working, and would
delay the newui move further.
But that's OK, you can keep banging that drum.
and 2 weeks are enough ? or you will need more time ?
I don't mind postpone a release , but I prefer one postpone of 4 weeks
than 4 of one week ...
Thanks,
--
Sérgio M. B.
12:26 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 8 Nov 2012 07:35, "Kevin Kofler" <kevin.kofler(a)chello.at> wrote:
Adam Williamson wrote:
> The new anaconda UI and related features are more or less entirely the
> cause of the slip.
This shows that those changes should not have been done, or at least not
in
this way.
Hindsight is a fabulous thing, I suspect the anaconda developers would
agree with you looking back. Its a large body of code dependent on a lots
of pieces.
> Secure boot support is also not done yet (waiting on the
signature for
> shim to get sorted out by legal), though I don't know whether FESCo yet
> absolutely decided that has to be in for Beta.
And Restricted Boot support just needs to go away!
And with it will go Fedora's ability to support a lot of new hardware
moving forward and I don't believe that's good for anyone. The developers
have done a lot of work to make it easily handle a vast amount of use cases
and I think its great the work they've done. The hardware is coming so its
pointless for us to stick our heads in the sand.
Besides this thread is a about beta slip. Not pros and cons of already
approved feature.
Peter
Peter
12:59 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Peter Robinson wrote:
And with it will go Fedora's ability to support a lot of new
hardware
moving forward and I don't believe that's good for anyone. The developers
have done a lot of work to make it easily handle a vast amount of use
cases and I think its great the work they've done. The hardware is coming
so its pointless for us to stick our heads in the sand.
You know as well as me that Restricted Boot can be disabled by the user.
Kevin Kofler
9:44 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 08, 2012 at 06:31:20AM +0100, Kevin Kofler wrote:
Adam Williamson wrote:
> The new anaconda UI and related features are more or less entirely the
> cause of the slip.
This shows that those changes should not have been done, or at least not in
this way.
We did that for a long time on change requests in the installer and it got
to the point where we just needed to make the move.
The key problems I see are communication and expectations.
--
David Cantrell <dcantrell(a)redhat.com>
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
11:29 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Conan Kudo (ニール・ゴンパ) wrote:
Oh my goodness. This is the highest amount of slippage I've seen
in quite
some time. What is wrong with Fedora? The slippage is getting worse each
and every single release. I love Fedora and all, but this is absolutely
ridiculous...
One factor is that QA has become stricter (and testing has improved). E.g.,
in the past, the KDE spin didn't even have to work at all! The criteria for
the GNOME ("Desktop") spin have also become much tighter. Of course
delivering something that actually works takes time. I don't believe going
back to just shipping what's there on release day even if it has major
defects is a good idea.
Another factor is that the Anaconda developers are doing more and more risky
changes, we had the storage rewrite recently, and now in F18 there's the UI
rewrite (which also touches the storage code yet again, along with much
other backend code, it's not a UI-only change).
Kevin Kofler
12:26 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 8 Nov 2012 07:30, "Kevin Kofler" <kevin.kofler(a)chello.at> wrote:
Conan Kudo (ニール・ゴンパ) wrote:
> Oh my goodness. This is the highest amount of slippage I've seen in
quite
> some time. What is wrong with Fedora? The slippage is getting
worse each
> and every single release. I love Fedora and all, but this is absolutely
> ridiculous...
One factor is that QA has become stricter (and testing has improved).
E.g.,
in the past, the KDE spin didn't even have to work at all! The
criteria
for
the GNOME ("Desktop") spin have also become much tighter.
Of course
delivering something that actually works takes time. I don't believe going
back to just shipping what's there on release day even if it has major
defects is a good idea.
Another factor is that the Anaconda developers are doing more and more
risky
changes, we had the storage rewrite recently, and now in F18
there's the
UI
rewrite (which also touches the storage code yet again, along with
much
other backend code, it's not a UI-only change).
The storage rewrite happened back in the f12/13 timeframe. Hardly recent.
3:21 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
----- Original Message -----
Conan Kudo (ニール・ゴンパ) wrote:
> Oh my goodness. This is the highest amount of slippage I've seen in
> quite
> some time. What is wrong with Fedora? The slippage is getting worse
> each
> and every single release. I love Fedora and all, but this is
> absolutely
> ridiculous...
One factor is that QA has become stricter (and testing has improved).
E.g.,
in the past, the KDE spin didn't even have to work at all! The
criteria for
the GNOME ("Desktop") spin have also become much tighter. Of course
delivering something that actually works takes time. I don't believe
going
back to just shipping what's there on release day even if it has
major
defects is a good idea.
As someone pointed out in yesterday meeting - Fedora is becoming more
a combo of time/feature based distribution. You can still see the
relict of more time based times in schedule (that definitely has to
be cleaned) - you will see RC composes there, set for the specific
date, now we do RC composes when the blocker bug list is clean etc.,
in F18 when the required features are there (not saying we would not
wait for upgrades for example even in earlier times, probably yep).
And now we are getting to the "release when it's done" area where we
haven't been before and we are unsure how to react - is six months
cycle what is our goal (time based), is delivering all features in
a high quality our goal (and thus the schedule is here more for a
guidance), is it now having all features we planned in release?
I'm really happy we have a dedicated Fedora QA team, we do not blindly
release something we believe it's going to work but actually no one
tried it (as we used to do before not only for KDE spin). On the
other hand, we should be clear what's our goal. I'm not fighting for
schedules for schedules as schedules are nice and you know, you can
schedule schedules:) But definitely we have to do something with this
schizophrenia (smaller slips to make plan, schedule bigger slips to
be sure we deliver what we want to deliver).
Jaroslav
Another factor is that the Anaconda developers are doing more and
more risky
changes, we had the storage rewrite recently, and now in F18 there's
the UI
rewrite (which also touches the storage code yet again, along with
much
other backend code, it's not a UI-only change).
Kevin Kofler
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
5:03 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 8, 2012 at 10:21 AM, Jaroslav Reznik <jreznik(a)redhat.com> wrote:
As someone pointed out in yesterday meeting - Fedora is becoming
more
a combo of time/feature based distribution.
I don't think that's really the case.
The important thing about a time-based schedule is that at some point
you _stop accepting new features_ (and we do have that), not that
there is a 100% reliable time when the GA release happens (which we
don't have).
The only way to have a 100% reliable GA release date would be to have
a development process that guarantees no regressions, so that no
surprises ever happen. (Some projects do have that - full test
coverage and "continuous integration" running the tests after every
commit - but we obviously don't, and probably never will.)
Mirek
(The problem with feature-based schedules is that if you plan features
A, B, C, and to release when all of them are done, and A becomes
significantly delayed, causing a slip in the schedule. In the
meantine, somebody else starts working on D, adds it to the release...
and when A is done, D is delayed, causing a next slip. IIRC emacs
11:10 a.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, Nov 09, 2012 at 12:03:23PM +0100, Miloslav Trmač wrote:
On Thu, Nov 8, 2012 at 10:21 AM, Jaroslav Reznik
<jreznik(a)redhat.com> wrote:
> As someone pointed out in yesterday meeting - Fedora is becoming more
> a combo of time/feature based distribution.
I don't think that's really the case.
The important thing about a time-based schedule is that at some point
you _stop accepting new features_ (and we do have that), not that
there is a 100% reliable time when the GA release happens (which we
don't have).
It might all be definitions but that still sounds like a description of
a feature-based release model. F19 will have Feature X, Y, and Z. If
feature X isn't ready yet, we slip our release date until it's ready.
A time-based release would say we're releasing on YYYY-MM-DD. If feature
X isn't ready to go into the release that's being shipped on that date, the
feature is removed.
In the time-based release model, you still have schedule slips as you either
fix things at the last minute or you invoke plans to revert an incomplete
feature and those plans end up running longer than you thought. But in
either scheduling case, you are intending to hit as close to your scheduled
release date as possible and choices like "plough ahead with X or revert X"
are evaluated on which is likely to slip the release date the least.
-Toshio
5:07 p.m.
New subject: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, 2012-11-08 at 01:52 +0000, Bojan Smojver wrote:
I know everyone is going to hate me for saying this, but wouldn't
it make sense
to just forget about F-18 and go for F-19 instead? After all, F-19 feature
submission deadline will probably be only a few weeks after F-18 release (as it
stands now, unless it slips again).
After reading through the discussion, it seems that a new feature that
has to do with rewriting Anaconda has caused larger than expected
workload on developers. Given that, wouldn't it make even more sense to
just skip F-18 and let developers work in piece on F-19 instead?
Don't get me wrong, I love upgrading to new Fedora releases. But, if it
so happens that the big changes cannot be done in time, maybe hard
working developers deserve a break from the breakneck release schedule?
--
Bojan
4206
days inactive
4220
days old
211 comments
52 participants
participants (52)
-
Adam Williamson -
Alexander Bokovoy -
Bill Nottingham -
Bojan Smojver -
Bruno Wolff III -
Carl G -
Chris Adams -
David Cantrell -
David Lehman -
Dennis Gilmore -
drago01 -
Emmanuel Seyman -
Gilboa Davara -
Jaroslav Reznik -
Jesse Keating -
Jesse Keating -
Jiri Eischmann -
Jon Ciesla -
Josh Boyer -
Jóhann B. Guðmundsson -
Kevin Fenzi -
Kevin Kofler -
Kévin Raymond -
M. Edward (Ed) Borasky -
Marcela Mašláňová -
Matej Cepl -
Matthew Garrett -
Matthew Miller -
Matthias Clasen -
Matthias Runge -
Mike Chambers -
Miloslav Trmač -
Neal Gompa -
Nicolas Mailhot -
Panu Matilainen -
Peter Jones -
Peter Robinson -
Pierre-Yves Chibon -
Przemek Klosowski -
Rahul Sundaram -
Ralf Corsepius -
Reindl Harald -
Richard W.M. Jones -
Seth Vidal -
Stephen John Smoogen -
Sérgio Basto -
The Quen -
Tim Flink -
Tim Lauridsen -
Tom Lane -
Toshio Kuratomi -
Vratislav Podzimek