Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes
"Bernhard R. Link" <email@example.com> writes:
> * Russ Allbery <firstname.lastname@example.org> [130504 00:32]:
>> The way to ensure that builds in non-clean environments work properly
>> is to devise a method for testing them, and to do those tests on a
>> regular basis and turn test failures into bugs.
> Noone is speaking about non-clean environments, but only about
> non-minimal, non-artifical ones.
That's what I mean by "non-clean."
>> Trying to get at this testing indirectly by putting conditions on
>> initial archive uploads doesn't really accomplish the goal. It's a
>> very random and scattershot way of testing that already doesn't work
>> for any of us who use pbuilder and cowbuilder already.
> That's why I think maintainers should not only build in pbuilders and
> cowbuilders, but give their packages some actual testing.
We can think maintainers "should" do a lot of things. The reality of
software development is that if you don't test it, it doesn't happen. We
can ask every maintainer to set up a test procedure for this, and some of
them even will. But many of them won't. If we want to support this
feature across the project, and I agree that I would like us to, then we
need to test it across the project and turn the failures into bugs,
rejects, or some other sort of feedback.
This is similar to the argument for continuous integration systems. Yes,
the benefit is marginal if the developers always run the unit tests before
every commit (and there aren't a lot of environment- or architecture-
sensitive properties in the code). If you have developers that always do
that, you may not need continuous integration. If your developers are
like most of us and are not actually that good at maintaining that level
of discipline, continuous integration takes care of that for them.
Remembering a checklist of things to do with each upload is the sort of
thing computers are much better at doing than people.
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>