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 <[email protected]> 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
