Date: Mon, 17 Mar 1997 13:58:18 -0600 From: Richard Wackerbarth <rkw@dataplex.net> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: stable@FreeBSD.ORG Subject: Re: -current and -stable mailing lists Message-ID: <l03010d01af534ac91082@[208.2.87.4]> In-Reply-To: <8785.858624268@time.cdrom.com> References: Your message of "Mon, 17 Mar 1997 11:34:55 CST." <l03010d00af533005c68e@[208.2.87.4]>
next in thread | previous in thread | raw e-mail | index | archive | help
>> The "problem" is that some of the entrenched people who get the dictate >> what happens understand the distinctions but fail to the able to see the >> situation from the point-of-view of the "general public". They prefer THEIR > >This can be a valid criticism at times, but also be very clear on the >fact that the "public" ALSO has a dozen different interpretations of >many of our actions to choose from, and trying to figure out just >which of many possible interpretations will cause the least confusion >is no easy task. Here I do not disagree. That is why I recommend that we try to stay away from short labels which carry various semantic interpretations. Given a paragragh rather than simply 8 characters makes it much to clearly communicate. >So we picked poor names for our branches. We blew it. It's not that >hard to do in an evolutionary environment like this one, Hindsight is always better :-) > but now >rather than continue to natter on for another dozen rounds about how >terrible the current naming scheme is, I really would prefer to see >the "general public" answer these two simple questions: > > a) Would the confusion caused by an abrupt name change > exceed the confusion caused by the current conventions? > > b) Assuming that the answer to (a) is no and now you've got > carte blanche to change things, what names would you choose > to describe the 3 tracks of development (mostly quiescent, > current release track, bleeding edge development) which you > feel would most adequately convey their purpose to the > layperson? Explain your rationale for each choice. 1) Sticking your head in the sand and claiming that you cannot see a problem is not a valid solution. As others have noted, we, at the present time, have only two names for three "animals." We clearly need to change either 2.2 or 3.0 away from "current". 2) Moving 2.2 onto "stable" is, in itself, confusing. (Where does 2.1 go? Contrary to the desires of some, it isn't quite dead yet.) 3) I would NOT use "current" to designate the head of the deveplopment branch. As noted, it is too ambiguous. 4) I would carry discussion about each generation of the system under its unique, permanent name. From the time that the development tree is branched until there is ABSOLUTELY no support for it, the branch would be known by its identifier, eg 2.2. 5) As each system progresses through its life cycle, various aliases might be used to designate the its level of progress. However, I would consider them just aliases and have them redirect to the underlying numeric designation. This strategy avoids the abrupt "pull out the rug" type of change that occurs if "X" (stable?) changes from 2.1 to 2.2. I can see some argument for failing to assign a number to the head of the development branch because it does not really change when a new branch is created. However, any name chosen for that should convey the extreme cutting edge of development nature of this "animal". IMHO, the people who should be dealing with this "branch" have a much better understanding of the total picture and can reasonably be expected to deal with any name, whether it has "meaning" or is simply a "codeword". 6) I would propose that, as a transition, "current" can alias to both 2.2 and 3.0. As users become accustomed to the new name, it can be phased out. The nice thing about my proposed solution is that Majordomo can take care of the immediate change and nobody encounters an abrupt disruption. Duplicate the "current" mailing list into both 2.2 and 3.0. Alias "current" to forward its message to both lists. Publish the change and encourage the use of the more restrictive lists. After some time, phase out the alias.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?l03010d01af534ac91082>