From owner-freebsd-stable Fri May 10 17: 1:15 2002 Delivered-To: freebsd-stable@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-43.dsl.lsan03.pacbell.net [63.207.60.43]) by hub.freebsd.org (Postfix) with ESMTP id 1CA3A37B408 for ; Fri, 10 May 2002 17:01:10 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id AF78566DC9; Fri, 10 May 2002 17:01:09 -0700 (PDT) Date: Fri, 10 May 2002 17:01:09 -0700 From: Kris Kennaway To: "John T. Farmer" Cc: freebsd-stable@FreeBSD.ORG, kris@obsecurity.org Subject: Re: conf/11376 still suspended Message-ID: <20020510170109.A55363@xor.obsecurity.org> References: <20020509233557.A35087@xor.obsecurity.org> <200205101347.JAA21782@rapier.goldsword.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200205101347.JAA21782@rapier.goldsword.com>; from jfarmer@goldsword.com on Fri, May 10, 2002 at 09:47:30AM -0400 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 10, 2002 at 09:47:30AM -0400, John T. Farmer wrote: >=20 > On Thu, 9 May 2002 23:35:57 Kris Kennaway said: > > On Fri, May 10, 2002 at 09:27:33AM +0300, Dmitry A. Yanko wrote: > > > On Thu, May 09, 2002 at 03:49:45PM -0700, Kris Kennaway wrote: > > > > > Can anybody fix it before 4.6-RELEASE? > > > > This kind of request should be made _before_ code freeze, not after. > > > Ok, but look at the date of PR. > > > > I know it's been sitting there for a long time, my point was just that > > you're better off bugging people when we're not in the middle of a > > release cycle. Every time we go into code freeze people seem to come > > out of the woodwork asking for patches to be committed in time for the > > release of the version which was just frozen. >=20 > You are of course referring to the code freeze that was just=20 > announced as a "retro-alert." Dinging him for asking about progress=20 > on an old PR and using the release code freeze as the reason, well=20 > that's silly. He didn't know the freeze was in place until it was=20 > announced. It was announced after the tree was frozen. See a=20 > catch-22 here? The release schedule is advertised on the main page of the website; it's very prominently available information if you're looking for it. My only point was that people with PRs they want committed should do their lobbying EARLY in the release cycle, instead of at the 11th hour when it's about to be released, and there's essentially no chance of their request coming true. There are a number of cases in the past where someone would pop up just before the x.y release date for several releases in a row asking "Can someone commit my patches before the release of x.y?" And then disappear from view for 3 months until the next release, whereupon they would ask the same question over again. That's entirely the wrong way to achieve the goal, and you're just spinning your wheels. There's also the important point that -stable is entirely the wrong list to be asking on, because it's a technical support list and not a development list. Lobby developers to commit your changes early in the release cycle, so they can be committed to -current, tested, and merged on a leisurely schedule before the next release. A lot of the old stale patches in the PR database are old and stale because they are of poor technical quality or mysterious merit, and therefore they are unsuitable for committing in their present form. Code which contains hacks to work around poorly understood problems; which does not adequately describe the problem it's solving (e.g. giving test cases and a clear demonstration of the need for the code); which is too specific (i.e. only works for special cases but does not address the problem in generality); or which is poorly thought out or badly written, does not stand a good chance of being committed. The burden is at least partly on the contributer to make sure their contributions are of high enough standard to be included in FreeBSD. If you have old patches which have not been touched, firstly review the above list to see if it applies to your contribution, and take steps to clean it up if so (ask for suggestions on how to do this if you're not sure! You'll get more results this way). Then, if general mail to development mailing lists does not solicit a response from an interested committer, try to be proactive: identify individual committers who have done work in that or related areas, and email them directly about committing the patches. Kris --PNTmBPCT7hxwcZjr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE83F9FWry0BWjoQKURAqSPAJ4vnSKTwSVpueZPraHyH2sRtWn4OgCgpkMj qfpfxtmFm0el8qLLUCiOjuE= =5SPR -----END PGP SIGNATURE----- --PNTmBPCT7hxwcZjr-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message