subject:"Re\: 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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

2012-11-10 Thread Kevin Fenzi

On Sat, 10 Nov 2012 19:59:22 +0100
Kevin Kofler kevin.kof...@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


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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_requirements
 
 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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

2012-11-10 Thread Nicolas Mailhot


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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

2012-11-10 Thread Matej Cepl

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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

2012-11-10 Thread M. Edward (Ed) Borasky

On Sat, Nov 10, 2012 at 2:41 AM, Richard W.M. Jones rjo...@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?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

2012-11-10 Thread Jesse Keating


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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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 jrez...@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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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 dcantr...@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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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 dcantr...@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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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
johan...@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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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 dleh...@redhat.com wrote:
 On Thu, 2012-11-08 at 17:20 +, 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 johan...@gmail.com 
  wrote:
  On 11/08/2012 04:37 PM, Matthew Garrett wrote:
  On Thu, Nov 08, 2012 at 04:32:29PM +, 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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

2012-11-09 Thread Vratislav Podzimek

On Fri, 2012-11-09 at 12:27 +0100, Miloslav Trmač wrote:
 On Thu, Nov 8, 2012 at 9:40 PM, David Lehman dleh...@redhat.com wrote:
  On Thu, 2012-11-08 at 17:20 +, 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 johan...@gmail.com 
   wrote:
   On 11/08/2012 04:37 PM, Matthew Garrett wrote:
   On Thu, Nov 08, 2012 at 04:32:29PM +, 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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

2012-11-09 Thread Matthias Clasen

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. 


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

2012-11-09 Thread David Cantrell

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 (mj...@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 dcantr...@redhat.com
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

2012-11-09 Thread Matthew Garrett

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 | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

2012-11-09 Thread Nicolas Mailhot


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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

2012-11-09 Thread Alexander Bokovoy


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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

2012-11-09 Thread David Cantrell

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 dcantr...@redhat.com
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

2012-11-09 Thread Matthew Miller

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  ☁☁☁  mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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 (mj...@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!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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 jrez...@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 -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


pgpBWG3oStbhC.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

2012-11-09 Thread Peter Jones

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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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.)



pgpnpzwv48BiP.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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


pgpqxuuszzi2x.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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


pgptwVnwzfGBC.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

2012-11-09 Thread Panu Matilainen


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 -

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

2012-11-09 Thread Matthew Miller

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  ☁☁☁  mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

2012-11-09 Thread Reindl Harald



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)



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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


pgpddXPKmjxMr.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

On Fri, 2012-11-09 at 14:47 +, 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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

On Fri, 2012-11-09 at 21:11 +, 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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 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-Christmas-Bundle_Desktop-PC_review

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=dddapy1model_id=xps-8500c=usl=ens=dhscs=19
(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

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27