A Cry For Sanity

[Andrew John Hughes]

2008/6/26 Andrew Haley <aph at redhat.com>:
> Andrew John Hughes wrote:
>> 2008/6/26 Andrew Haley <aph at redhat.com>:
>>> Andrew John Hughes wrote:
>>>> 2008/6/26 Andrew Haley <aph at redhat.com>:
>>>>> Andrew John Hughes wrote:
>>>>>> Is there a particular reason we keep generated files (configure,
>>>>>> aclocal.m4, Makefile.in) in the repository?  I ideally like to remove
>>>>>> them for the following reasons:
>>>>> It's much easier for a person who just wants to download and build
>>>>> not to have to regenerate the auto* scripts.  autotools are notoriously
>>>>> sensitive to having the exact versions installed.  If we check in the
>>>>> generated scripts they do not have to run auto* locally.  It's about
>>>>> lowering the barrier to entry: if we don't check in the generated
>>>>> scripts it'll be much harder for people to get started.
>>>>>
>>>> It's this sensitivity that also swings it the other way from me; I've
>>>> had to be selective
>>>> on which systems I alter IcedTea to avoid drastically changing the autogenerated
>>>> files due to version changes in the autotools.
>>> So what?  As long as the files still work that doesn't matter.  No-one
>>> needs to look at the diffs between autogenerated files.
>>
>> But they became a problem when the real diffs are obscured and we don't have
>> any other form of patch announcement than Mercurial commit messages.
>
> That's a fair point.  We are not handling patch mailings well.
>
>>>> As for people getting started, hacking on IcedTea pretty much
>>>> requires having the autotools as most of the changes are to
>>>> Makefile.am and configure.ac.  If you're just talking about
>>>> building, then that's why we have releases.
>
>>> That's a bad attitude problem: the source tree is for us developers,
>>> and mere mortals get to use the releases we've handed down from
>>> Mount Olympus.
>
>> I'm not going to anything like that extreme.  I'm merely pointing
>> out that someone choosing to go to the extra length of downloading
>> the code using a version-control tool and who is prepared to work
>> with the 'bleeding-edge' would probably expect a little more trouble
>> in doing so.  In the process, they would learn the skills needed to
>> contribute to the project itself.  In contrast, we spend a lot of
>> time perfecting a release as much as possible to ensure that there
>> is as little trouble as possible.
>
> Maybe.  That does sound to me like the "it's hard for us to develop,
> so it doesn't matter if it's hard for people to build too."
>

The intention was to make the common case the easiest, and the other cases
easy enough :)

>> This isn't about segregating users, but about making things easier
>> for the majority using a particular method of source code
>> distribution.  For a release, I believe this is end users and
>> distros who want to build the code with as little trouble as
>> possible.  With the code in the VCS, this is the developers and
>> prospective developers.
>
> OK, I'll give you this: if the *majority* of people who use Mercurial
> are those who have to regenerate and check in the results, then the
> generated scripts should go.
>

I believe that the majority by far are people actively hammering those
two files in the IcedTea repository rather than the 'common builder' who
just wants to download and try the latest and greatest.  We have very
little overhead in producing a release, so producing these regularly
and keeping the tree free of generated autotools files seems the best
option.

IcedTea is a fairly unique project.  Not many projects effectively result
in two files getting changed by just about each and every patch.  I think
this is also the cause of some VCS issues we have, but not all.

> Andrew.
>
>



-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8