Date: Fri, 6 Jan 2006 14:22:17 +0100 From: Stijn Hoop <stijn@win.tue.nl> To: Tobias Roth <roth@iam.unibe.ch> Cc: ports@freebsd.org Subject: Re: Portupgrade confused about editors/emacs Message-ID: <20060106132217.GD79296@pcwin002.win.tue.nl> In-Reply-To: <20060106131231.GC14967@droopy.unibe.ch> References: <834B3A07-EC76-4645-8E1B-7ABEA4EC999A@submonkey.net> <43BE57E9.9060507@rogers.com> <43BE61C9.9060502@ebs.gr> <43BE63E7.4060209@rogers.com> <20060106124508.GB14967@droopy.unibe.ch> <20060106125428.GC79296@pcwin002.win.tue.nl> <20060106131231.GC14967@droopy.unibe.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
--4jXrM3lyYWu4nBt5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 06, 2006 at 02:12:31PM +0100, Tobias Roth wrote: > On Fri, Jan 06, 2006 at 01:54:28PM +0100, Stijn Hoop wrote: > > > > A perfect example of this is the recent RCng commits to 6-STABLE. T= he=20 > > > > ports are clearly not ready for this, yet its been committed and le= ft.=20 > > > > Now many ports refuse to work. This clearly breaks POLA. > > >=20 > > > I agree to the RCng example. How long was it in -CURRENT? Two weeks? > > > Then MFC it over the christmas season, when there is a high probabili= ty > > > that maintainers of affected ports might not be around to fix the mes= s? > > > Not good. > >=20 > > Well, it is -STABLE. Despite the name, the -STABLE charter has always > > been 'it might have some bumps when MFCing large features but it > > should be OK to run it'. >=20 > Stuff is MFCed to -STABLE once it has received widespread enough testing > and is considered stable. As the outcome shows, this was clearly not the > case with the RCng stuff. That may certainly be the case. It could also be that everyone running -CURRENT did not use these broken ports, and that Doug did not receive any bug reports for over a week, so he thought it was stable enough. > > If you need absolute stability (like you seem > > to indicate by all of your loudly screaming posts), run -SECURITY (ie > > RELENG_6_0). Furthermore, implement some kind of test system where you > > can see what changes will do to your setup _before_ you run them in > > production. Even with -SECURITY you might be the first to run into > > some unanticipated problem; no-one can guarantee that something works > > on all weird setups in the wild. >=20 > I do not need education on FreeBSD release engineering. However if you > claim that untested and therefore possibly broken things should be > MFCed, then maybe you do? After all, what's CURRENT for if things get > MFCed untested? To be sure, the paragraph above was directed more to mr. Jakubik, who seemed to be more in a fit about "all of this" than you. I apologize for the confusion, and I agree I could have worded this better. I also do not claim untested things might be merged; I simply tried to point out that there is no real set of tests that catches all the broken stuff right now, especially for system startup things. Now, a FreeBSD regression test system would be very nice, and maybe could have caught things like this. But it's also not implemented yet (and it might be too hard to implement ever), so therefore I was suggesting that you do your regression tests yourself. > > Note also that lots of people don't have issues (ie me), and that Doug > > en Brooks have been totally responsive to all reports, from where I > > can see. >=20 > This (at least from my part) was not critique on the responsivenes, > but on the time and nature of the MFC. I claim it was not long enough in > CURRENT to be MFCed. And since it was known beforehand that the change > will possibly affect many port maintainers who will then have to adapt > their ports, the time of the MFC was was badly chosen. If I commit or > MFC something that I can fix myself during holiday season, that's ok. > But if I commit something that needs the help of many people, in case it > breaks, the holiday season is a bad moment to commit. That is totally true, and I agree that a longer wait time might have prevented some of the breakage, or at least waiting until the holidays were over. > Also, solutions to the whole localpkg discussion are under discussion > for at least 1.5 years now. If Doug wouldn't had commited his work to > CURRENT, the discussion could still drag on and on. So in that respect, I > welcome that he ended the discussion with a commit of an implementation= =20 > to CURRENT. But such a much discussed change should not go to STABLE so > quickly. I still do believe that it was tested a lot by Doug and others before it was merged; they simply did not catch all edge cases yet, which is what people are running into right now. I am not convinced that a longer wait time would have caught all those edge cases however. Do you agree that it would be impractical to test all ports with an rc.d script before a merge? Thanks for the constructive response. --Stijn --=20 "A mouse is a device used to point at the xterm you want to type in." -- Kim Alm, alt.sysadmin.recovery --4jXrM3lyYWu4nBt5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDvm8JY3r/tLQmfWcRAiX3AJ9GIxD4/kk/nWlT83zunMlC5yqUOgCfZc6R XNENMYOgo4KhQrMOssDhf1A= =9VXp -----END PGP SIGNATURE----- --4jXrM3lyYWu4nBt5--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060106132217.GD79296>