Date: Wed, 16 Oct 1996 16:15:47 -0500 (CDT) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: dg@root.com Cc: freebsd-hackers@freebsd.org Subject: Re: IP bugs in FreeBSD 2.1.5 Message-ID: <199610162115.QAA28661@brasil.moneng.mei.com> In-Reply-To: <199610162033.NAA09356@root.com> from "David Greenman" at Oct 16, 96 01:33:46 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I think this whole thread has degenerated to an amazingly low level. Of
Agreed.
> course you are nothing like Charles, and of course what Jordan meant in his
:-)
> original comment was that you aren't a FreeBSD release engineer and never
> have been. What release-engineering duties you have during your day job has
> very little to do with the release engineering that we do with FreeBSD. The
> defining difference being that in a company, the boss tells you how it will
> be, and in FreeBSD it's however we think we can do it with the least pain (the
(not particularly true, at least in my case: I design and implement and my
boss is not really involved. I am directly responsible for meeting the
needs of the application programmers, and can choose to do so in whatever
manner I deem appropriate.)
> pain being balanced between the amount of effort it takes and the acceptable
> product quality level). We do the best we can and I believe we have struck a
> good balance and have put out several good releases to show for it.
Hi David,
I do respect and understand that. However, please bear in mind that I have
been along for the ride since the very early days... and during that time,
I have seen the importance of the release procedure diminish gradually.
Now Jordan is stating that the release procedure (as it has historically
been) has been declared *discontinued*.
Part of the reason several good releases have been put out is because they
have each successively built upon the foundation laid by the previous
release. I have a hard time accepting this as proof that the current
release process is adequate: a release process is designed to wring out
the bugs in a release, and if the bug rate is unusually low to begin with,
the release process does not necessarily need to be rigorous.
I am not sure that I have as much confidence in this sort of paradigm when
2.2R is released. That is why I am raising this issue NOW.
> In actual fact, we have been doing alpha/beta/gamma releases. With every
> near-release SNAP that Jordan has done in the past releases, he has indicated
> that a certain SNAP should be considered the "alpha" candidate, or the "beta"
Then why not formalize it and call them ALPHA, and BETA? I do not see why
this necessarily has to cause more work for Jordan, but it does provide
the rest of us with some benefits.
1) It's easier to see what is going on.
2) Feature freeze means increased stability as you progress from A->R
3) Well defined time frames mean that I have a chance to test -A and still
report back during the -A period before -B is released. I would think
it would be a bit easier on Jordan too.
> candidate, etc. What we have stopped doing is organize a large release testing
> team. We simply don't have the resources to manage it and more importantly,
> haven't found enough interested people to participate. If YOU want to do this,
> then that would be great and I'm sure it would help the product quality in
> the final release.
I am _ALWAYS_ happy to test a version that is on the release path. I
cannot give it a comprehensive work out, nobody can, but I can test it
thoroughly in the environments which I have available to me. I have
_ALWAYS_ had this policy and have done my best to follow it.
It has, however, become difficult to differentiate random SNAP's from
things that might be worthy of testing. As I recall, I was not aware of
2.1.5R's impending release even two weeks before the release. This is
not particularly helpful to either you or me.
(I do not wish to test random SNAP's because, the way I understand it,
they were mainly designed to give needful users early access to new
features, and provide more exposure for -current.)
I don't think this should be such a big deal.
Perhaps someone would explain how it is more difficult to follow a formal
release methodology to me. I do not see it being more complex than
(perhaps) changing the release name, calling a feature freeze, doing
A/B/{G/,}R releases, and showing a little discipline.
Is that really more difficult than the current SNAP procedure? I think
it should be mainly a matter of additional formality, not additional
work for the RE. Am I wrong?
Someone help me understand...
And regardless, of course I am happy to continue testing release path
candidates. I just need to be able to spot them.
Thanks,
... Joe
-------------------------------------------------------------------------------
Joe Greco - Systems Administrator jgreco@ns.sol.net
Solaria Public Access UNIX - Milwaukee, WI 414/546-7968
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610162115.QAA28661>