On Wednesday 14 October 2009 02:12:03 Eray Aslan wrote:
> On 14.10.2009 03:17, Mike Frysinger wrote:
> > On Tuesday 13 October 2009 19:30:52 Joshua Saddler wrote:
> >> All that to say, Tommy (et al), is that the idea of expecting users to
> >>  magically know everything and not to offer any documentation *in
> >> advance* . . . is a silly idea. Good lord, can you imagine the shitstorm
> >> the X11 team would have gone through if they'd tried *that* without
> >> first writing up xserver 1.5 and 1.6 migration guides?!
> >
> > we arent talking migrations that are forced onto everyone.  we're talking
> > about new code that users have to *opt in* for ("new net") that is only
> > available in unstable.  expecting everything in testing to be documented
> > up front is unreasonable.
> 
> While true in general, I cannot agree with you in this case.  This is
> not some random app we are talking about.  It is a change in init
> scripts that might render our servers inaccessible if things go wrong.
> Please bear in mind that we have servers operating in datacenters in
> other countries and network loss is the worst kind of bug you can
> inflict upon us.

people concerned with stability (i.e. headless dataservers) have no reason to 
be running unstable.  server instability here is self-inflicted.

> There is no documantation upstream.  At least we have some docs in g.o
> (kudos to whomever wrote it) but it is old (there is no mention of
> oldnet USE flag for example).  And IUSE="... +oldnet ..." is too fragile
> a solution.

there is to a degree -- read conf.d/network.  it might seem thin, but i think 
it's because "new" net is "supposed" to be thin.

> All I am saying is that this is a so important change that we should
> have gotten it right from the beginning.  Openrc should not have been
> unmasked without proper documentation.

always getting things right from the beginning is impossible.  problems are 
found and rectified and we move on.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to