Re: Poject bootstraping script in Developer Guide

[Muhammad Alkarouri <malkarouri at yahoo dot co dot uk>]

On ن, 2004-04-05 at 01:19, Behdad Esfahbod wrote:
> Since Elzubeir updated the developer guide to allow developers
> *choose between* Makefile.cvs and autogen.sh, I feel like arguing

Huh? Elzubeir didn't do that, at least in public. I don't think that
committing a new version of developer guide to CVS is a public
announcement.
The developer guide at the site is still at revision 1.3. No
announcement for the new version happened.

I believe we all have the right to argue. Otherwise the resulting
document should not be binding.

Alas, my discussion about compatibility with the current numbering has
not even warrented a reply. If that was so stupid, please tell me so.

Another point, Behdad. As long as there is a standard or a decision
already taken we should abide by it. If it needs a change we need some
discussion, or at least a notification before changing.
The Makefile.cvs existing in the bicon cvs was not in anybody's way, I
think, so you needn't have removed it before explaining your point.
Especially that the 'will be' developer's guide did not give us a
./bootstrap option, without a Makefile.cvs/autogen.sh.

>   * Indentation:  I must confess Arabeyes is the first place I
> see it says "The use of spaces should be avoided at all costs.
> Instead, TABS should be used."  At least in Python, TABS should
> be avoided.  In Linux kernel, all tabs are welcome, in almost any

Probably you didn't note the python exception in the next line in the
developer guide, but I got your point.

>   - Makefile.cvs MUST be used with KDE projects, at least those
> that rely on kdeadmin.
> 
>   - autogen.sh MUST be used with GNOME projects, at least those
> generated by Glade.

In other words, contributions to existing external projects should
conform to the relevent coding standards, rather than Arabeyes'.

> And now the documentation:
> 
> 5. Project Documentation:
> 
>   * Well, many people like RCS headers, that doesn't look bad,
> but I don't think it should be a mandatory thing either.

Second that.

> 
>   * Doxygen style source code doc:  Many projects simply do not
> accept Doxygen.  GNOME people have their own system which is very
> similar to Doxygen.  Donno about KDE.  But again, Java and Python
> have their own systems.  And I myself am lasier than doing
> Doxygen.
> 

Also speaking about other standards. I definitely prefer to use python
documentation style when using python. Contributions to external
projects should also conform to the relevant standards.

>   * Manpages:  They are old and being kinda deprecated.  The
> format is evil and other stuff.  Many (GNU) recommends info
> pages, but they are not necessarily easier to write.  For
> example, GNU FriBidi is asked to have info pages instead of man.

Man pages are old, but they have not been _successfully_ deprecated (if
you get what I mean). I wouldn't require info pages as a must, a mention
is probably worth it.


Sorry everyone for that long message about a subject that has already
been discussed before. Specially as it seems that discussion now is
futile.

Regards,

Muhammad Alkarouri