Dropped doxygen

[Benedikt Meurer]

Brian J. Tarricone wrote:
> On Thu, 12 Feb 2004, Olivier FOURDAN wrote:
> 
> 
>>1) Do we include configure, Makefiles and docbook documentation in CVS
> 
> cons: it's a pain for the developers in general.  if i make an 
> auto*-related change, and have to rerun autogen.sh, until i commit, my 
> cvs diff output is cluttered with a lot of random crap, and, unless i 
> specify files carefully, the patches i make for testing are cluttered (i 
> ended up making a script to generate all my xfdesktop patches, which, 
> obviously, has to change as i touch different files).  worse, if i 
> make a change, and someone else does, and they commit the changes, when 
> i do a cvs update, my files may not (probably won't) match, and CVS will 
> do a merge, and conflicts are quite easy here and annoying.
> 
> overall, i think most of the pros are unimportant.  i think that the 
> average user that is likely to install our CVS versions has the know-how 
> and ability to have appropriate versions of the auto* tools on their 
> system.  also, i think it's not necessarily a bad thing to raise the 
> barrier to CVS use a little.  as xfce gets more popular, more people are 
> going to want the latest-and-greatest, and if the CVS-usage barrier is 
> low, a lot of people are going to use it.  not only does this put a bit 
> of load on the CVS server (CVS is not a terribly efficient protocol), 
> but we end up with the unenviable position of having to support CVS 
> almost as if it were a release version.  i really think the only people 
> that need to have CVS readily available to them are the people that 
> intend to _test_ the new stuff in xfce, not the people that just want to 
> play with the newest stuff (tho that is a side bonus, if you're willing 
> to keep the pieces when things break).  and i think all of the people 
> that fit this description should have up-to-date versions of the auto* 
> tools on their systems.
> 
> the only remaining issue is that it makes more work for the release 
> manager.  two solutions.  1) make the maintainer of each module 
> responsible for generating a release tarball of their module on demand 
> (tho perhaps the release maintainer will go ahead and branch the entire 
> tree, and the module owners are expected to generate the release tarball 
> off this branch).  2) the release manager can come up with a bunch of 
> scripts that checks out a fresh copy from CVS, runs a modified 
> autogen.sh that disables maintainer mode and doesn't run configure, then 
> removes a few unnecessary files and makes a release tarball.  personally 
> i think the time investment required for either (1) or (2) is less than 
> that required to constantly update and commit the CVS-stored 
> autogenerated files.
> 
> ok, that was really long-winded.  sorry about that.

And there is another contra: If I change anything in the m4 stuff, I have to 
sync that manually in all modules. This is a very disturbing and very erranous 
task (having to do stupid things, makes people behave so). For example, the 
KDE people have a single CVS module 'kde-common', that contains most of the 
autotools stuff, which makes it easy to maintain in a single place.

> 	-brian

Benedikt

BTW: I like edscotts idea, to have a quickly rotating release scheme, since I 
know many xfce users that like to track recent Xfce version, but lack the time 
to track CVS (which is usually subject to breakage :-). Atleast making 
snapshot releases of the tree once a month could help.

-- 
NetBSD Operating system:                       http://www.NetBSD.org/
pkgsrc "Work in progress":                  http://pkgsrc-wip.sf.net/
XFce desktop environment:                        http://www.xfce.org/
German Unix-AG Association:                   http://www.unix-ag.org/
os-network:                                 http://www.os-network.de/

OpenPGP Key: http://www.home.unix-ag.org/bmeurer/#gpg