Re: make check gives 258 errors

[Jordi Gutiérrez Hermoso]

Moving this discussion to the maintainers' list, where it belongs.

2012/4/14 Sergei Steshenko <address@hidden>:
>
>
> --- On Sat, 4/14/12, Jordi Gutiérrez Hermoso <address@hidden> wrote:
>
>> From: Jordi Gutiérrez Hermoso <address@hidden>
>> Subject: Re: make check gives 258 errors
>> To: "Sergei Steshenko" <address@hidden>
>> Cc: "Muhali" <address@hidden>, address@hidden
>> Date: Saturday, April 14, 2012, 5:30 PM
>> 2012/4/14 Sergei Steshenko <address@hidden>:
>> >
>> >
>> > --- On Fri, 4/13/12, Jordi Gutiérrez Hermoso <address@hidden>
>> wrote:
>> >
>> >> From: Jordi Gutiérrez Hermoso <address@hidden>
>> >> Subject: Re: make check gives 258 errors
>> >> To: "Muhali" <address@hidden>
>> >> Cc: address@hidden
>> >> Date: Friday, April 13, 2012, 5:48 PM
>> >> On 13 April 2012 18:18, Muhali <address@hidden>
>> >> wrote:
>> >> > I have noticed that I get 258 errors from
>> 'make check'
>> >> with the current tip,
>> >> > as compared to 2 errors from a few weeks ago.
>> >>
>> >> Discussions of the development branch really belong
>> on the
>> >> development list.
>> >
>> > No, Jordi, it's quite OK that such topics are discussed
>> in this end users list.
>>
>> End users shouldn't be running the development version
>> unless they
>> want to be involved in development.
>>
>> Development sucks, so fix it in the development list. Not in
>> the help
>> list. Stop cursing the darkness, and light some candles in
>> the
>> development list.
>
> The candles are simple and well known: _first_ test, only them commit changes 
> (if the tests were run successfully).

People make mistakes. This is inevitable. Someone on the development
branch pushed a bad commit. These things happen; that's what a
development branch is for, for making mistakes. A few commits later,
the mistake got fixed. In the meantime, somebody noticed the mistake
and complained about it to the wrong mailing list, and you have called
us all kindergarteners for making a mistake.

If you really want to help to catch this sort of problem earlier, you
can help us setup Octave on Hydra. The GNU project has access to Hydra
which can help with autobuilding the Octave tree.

    http://www.gnu.org/software/devel.html

Since doing the things you want to do are so easy to do, you should
have no difficulty in sending us the appropriate recipe for building
Octave on Hydra:

    http://savannah.gnu.org/projects/hydra-recipes/

> If end users are not supposed to run development sources, disable public read 
> access to the repository.

Every end user is potentially a developer, so we can and should let
anyone read our source tree. If you're not willing to participate in
development, however, then you shouldn't be using the development
sources, where people make mistakes and things change rapidly.

- Jordi G. H.