Date: Fri, 22 Jun 2001 04:25:07 -0500 From: Mike Meyer <mwm@mired.org> To: "David A. Panariti" <davep@who.net> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Staying *really stable* in FreeBSD Message-ID: <15155.3827.672353.34621@guru.mired.org> In-Reply-To: <200106220409.f5M49b429872@baloo.ne.mediaone.net> References: <20010622012040E.jkh@osd.bsdi.com> <006c01c0fac8$b55f0380$94cba8c0@xena> <200106220409.f5M49b429872@baloo.ne.mediaone.net>
next in thread | previous in thread | raw e-mail | index | archive | help
David A. Panariti <davep@who.net> types: > All I'm saying is that it would be nice for there to be a tag that > identifies the source that is considered to be the most stable with > the most conservative sets of changes applied. And that at any time > that tag can be used. That's exactly what the RELENG_X_Y tags are. They are the conservative set of patches from the release. Having multiple different tags lets users decide when they want to make the very unstable jump from one -RELEASE + security fixes to the next. Given the recently announced release schedule: Jordan Hubbard <jkh@osd.bsdi.com> types: > 2001-08-20: FreeBSD 4.4 release date > 2001-11-11: FreeBSD 5.0 release date [EARLY ACCESS] > 2001-12-15: FreeBSD 4.5 release date > 2002-03-15: FreeBSD 5.1 release date [GENERAL ACCESS] > 2002-04-20: FreeBSD 4.6 release date > 2002-07-15: FreeBSD 5.2 release date [BEGIN -STABLE] What is your magic tag going to be tracking on January 1st? 5.0 or 4.5? Do we need three versions of your new tag for this: one for SUPER_STABLE (tracks to 4.6 before jumping to 5.2), one for GENERAL_STABLE (jumps from 4.5 to 5.1) and one for RELEASE_STABLE (from 4.4 to 5.0)? > This is exactly the same as using RELENG_X_Y and changing it by hand > as needed. A person interested in doing this kind of tracking will > follow the mailing list, make decisions on when to cvsup, etc. They > just won't edit the supfile. This is the way I'd like to stay > "stable." For me, this is the best mix of stability, security and > access to new features. There is one critical difference between what you've described and the way things are - who decides what "as needed" is. The way things are, that's done by the person responsible for the system running the software, which is as it should be. You're trying to push that responsibility off on the release engineer. If you really want that kind of facility, you should either provide it yourself or pay someone to provide it for you. Your assumption that someone interested in doing this kind of tracking will follow the mailing list, etc. is also wrong. The fact that we have a FAQ entry for -BETA/-RC/-STABLE is enough to demonstrate that. Here you have people tracking incremental changes and getting confused by what is no more than a name change. What you're proposing is something that would make the process of tracking something - which should track a series of incremental changes - suddenly include changes that are most distinctly *not* incremental. This will cause much worse problems than regular mailstorms over nothing, which is why it's a Bad Idea(TM) and generating a lot of resistance. > This is way too much discussion about way too simple of an idea. It's generating discussion becuase it's a Bad Idea(TM). <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. 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?15155.3827.672353.34621>