Date: Fri, 6 Jan 2006 14:57:28 +0100 From: Tobias Roth <roth@iam.unibe.ch> To: Stijn Hoop <stijn@win.tue.nl> Cc: ports@freebsd.org Subject: Re: Portupgrade confused about editors/emacs Message-ID: <20060106135728.GD14967@droopy.unibe.ch> In-Reply-To: <20060106132217.GD79296@pcwin002.win.tue.nl> 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> <20060106132217.GD79296@pcwin002.win.tue.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 06, 2006 at 02:22:17PM +0100, Stijn Hoop wrote: > > 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. I agree that the lack of response can be very frustrating. Even bug reports are better than nothing, as they show that people care about ones work. > 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. I also agree. It's hard to test systematically. All the more reason to let it linger in -CURRENT a while longer before MFCing. > 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. The project to improve regression testing already exists, as I just have found out: http://www.freebsd.org/projects/ideas/#p-regression Of course I agree that not everything can be tested, and that a good integration/production system is very important. Nobody who does not have such a system in place should be allowed to whine when things break badly on production machines. > > > 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. > > > > 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 > > 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? Yes, I do. And the fact that most production machines don't run -STABLE or -CURRENT, as you already have pointed out, surely didn't help to get the new features widely tested. And having ports-related things not differ too much between -STABLE and -CURRENT is also a good thing, that would be one argument for a quick MFC. > Thanks for the constructive response. likewise. greets, t.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060106135728.GD14967>