[gentoo-dev] Re: openrc: oldnet vs newnet

[Duncan]

William Hubbs posted on Mon, 20 Sep 2010 13:07:44 -0500 as excerpted:

> On Mon, Sep 20, 2010 at 10:52:23AM -0700, Joshua Saddler wrote:
>> On Mon, 20 Sep 2010 11:16:08 -0500
>> William Hubbs <williamh@g.o> wrote:
>>
>> > All,
>> >
>> > I want to start a new thread since the discussion on openrc is
>> > centering on whether we should use oldnet, newnet, or keep both.
>>
>> Use "oldnet." Why?
>>
>> 1. We already have a migration guide setup for it:
>>
>> http://www.gentoo.org/doc/en/openrc-migration.xml
>>
>> Keeping "oldnet" will greatly reduce the time needed to change all our
>> other docs, since I can use it as a reference, without needing write a
>> completely new migration guide for "oldnet" and *then* still have to
>> change all our other docs.
>>
>> 2. Users are already accustomed to doing things via "oldnet," since
>> they've been using OpenRC and following this guide for two years now,
>> since 2008.
>
> I'm fine with it being the default for stable for now.
>
> However, I do think that once we stabilize it, we can learn something
> from parts of newnet, and possibly use what it was trying to do.

[I noticed that only the two bugs were still open a couple days ago, with 
one being documentation, with effectively an "after *" dependency, and 
wondered when these threads might appear. =:^) The below is my opinion, 
yes, but it's also intended as a bit of a high-level summary of what I've 
seen on the two threads so far.  It seems to me this is most likely where 
things are headed, so if people disagree, perhaps they better post.]

Keeping oldnet the default and only documented method, does seem to be the 
most pragmatic/practical solution.

Given nightmorph's indication that he's not interested in redoing the docs 
twice, or documenting both methods, that does mean we're keeping oldnet 
for the foreseeable future, probably as long as we keep openrc, and 
there's no clear/foreseeable plan to migrate from it, so... .

The implication is even if we don't immediately drop newnet support for 
those that are already using it, it'll be undocumented, untested for 
network package bumps, and therefore unsupported.  In practice, anything 
in /that/ status eventually dies, so by implication, a decision to make 
oldnet the default and only documented version ultimately means newnet 
will become less and less practical to run as it requires more and more 
specific installation support and workarounds to keep it up and running.  
However, if we keep newnet around as a masked USE flag until it's no 
longer worth continuing, it'll give people already using it time to switch 
back, and/or to build up their own site scripts as workarounds, as newnet 
gradually gets more and more stale and broken.

It's worth noting here that newnet is a part of openrc, which has only 
been in ~arch.  There's nothing wrong with running ~arch, I run it myself, 
but one thing those running it do need to be prepared for, is change, 
change that in some cases means rolling back to older setups.  As such, I 
don't believe the status of anyone already switched to newnet is of 
particular concern -- it's a risk they took, that they at least should 
have known was a risk.  I don't believe we /need/ to leave newnet as a USE 
flag on their account, masked or unmasked, but given the functionality is 
there already, it doesn't hurt to leave it there, masked, for those that 
use it, to give them time to either switch back or build their own network 
scripts, as they wish.

Meanwhile, as you (williamh) rightfully mention, just because we decide to 
settle on oldnet only for documentation and support, doesn't mean there's 
nothing in newnet worth learning from and possibly pulling into oldnet.  
Nothing in the above says oldnet won't continue to grow and change.  In 
fact, that alone would ultimately destine it for the same fate as we're 
discussing for newnet.  So yes, let's certainly borrow from newnet where 
it makes sense, and continue to adapt and change oldnet to modern tools 
and ways of doing things.  Nothing wrong with that!

Finally, I'm not sure it absolutely needs it, but for clarity-sake and to 
avoid second-guessing and debate continuing long past the point of 
usefulness, I believe a council vote on the issue is appropriate.  I don't 
know where we are in the meeting cycle, but it seems to me that barring 
some special-case exception, a vote in 10 days or so should be plenty of 
time for folks to make their opinions known, so the first meeting after 
that looks to be appropriate for a vote, to me.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman