Portupgrade confused about editors/emacs

[Tobias Roth]

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.