Date: Fri, 22 Jun 2001 12:21:02 -0400 From: "David A. Panariti" <davep@who.net> To: freebsd-stable@FreeBSD.ORG Subject: Re: Staying *really stable* in FreeBSD Message-ID: <200106221621.f5MGL2435108@baloo.ne.mediaone.net>
next in thread | raw e-mail | index | archive | help
Ok, last try. I'm not trying to push responsibility off on anyone. There will be in infinitesmal amount of work involved. The tag points to the RELENG_X_Y tag with the highest X primarily and the highest Y secondarily. That's it. No more. If someone has decided to create a new RELENG_X_Y then no one makes a decision to move the "magic" tag. There is an algorithm. That's why it is too simple to waste time on. I've seen a lot of traffic from people who don't like the instability of STABLE. Then someone mentioned tracking RELENG_4_3 then moving to RELENG_4_4_RELEASE, then to RELENG_4_4. I thought this sounded like nice compromise of features vs stability. Then I thought, wouldn't it be nice if it was automatic? If a computer can do it, I don't want to waste my time on it. Hence the email. It is just another way for people to track sources in some way they are comfortable with. The delta of changes is not the issue, it is their *stability*. If people don't want to track this tag, then they don't have to. I don't track - -CURRENT, but I don't think it shouldn't be allowed to exist. I thought that if two people wanted something like this, then more might, and it might prevent some tracking problems. No version change confusion: "I'm tracking MAGIC_VERSION and uname -a shows that. No - -RC/BETA/etc confusion. And, hey, it compiles. And works. No need to send mail to find out how to fix it. The fact that most people talk about -STABLE unqualified with a version number and that the name of this list is freebsd-stable, again unqualified with a version number, seems to imply that people think in terms of a single stable stream of changes to FreeBSD. I think it would be nice to tag that stream of stable changes with a single tag. Again, people would be free to ignore it and track any RELENG_X_Y they choose, or any other tag they choose. The only issue I see is when a RELENG_X_Y appears after an RELENG_X+1_Z has begun. My choice is highest X wins. Since the RELENG_X_Y branches are considered most stable, then RELENG_X_Y must be as *stable* as RELENG_X+1_Z, and the tie breaker for me is more features and so a move the the X+1 version. A personal preference, I admit. Like I said before, I would be more than happy to do it myself, if I had programmatic access to all tags. Here's an "AI" program to make the "decision": #!/usr/bin/env perl @sv = sort(@ARGV); print @sv[$#sv], "\n"; exit(0) Once again, this is why it is too trivial to type so much about. This may be a bad and stupid idea, but if so, please attack it from a position of understanding what it is, not something else. And regardless, this is a stream *I* would track, so it is not 100% wrong. regards, davep (random, but appropriate, sig:) - -- Howe's Law: Everyone has a scheme that will not work. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106221621.f5MGL2435108>