Dropped doxygen

[Brian J. Tarricone]

On Thu, 12 Feb 2004, Olivier FOURDAN wrote:

> 1) Do we include configure, Makefiles and docbook documentation in CVS

i personally think we shouldn't.  while i don't want to say "everyone 
else doesn't do it, so we shouldn't either," i do somewhat feel that 
way.  the fact of the matter is that most other projects do not include 
these files in their CVS (offhand, actually, i can't think of any 
project that does besides xfce), and i happen to believe that, all else 
being equal, the majority tends to follow the easiest/best option.

pros (to keeping the files in CVS): barriers to users using CVS are 
lowered somewhat.  compilation time is shortened a little right after a 
checkout since the auto* tools take a while to run usually.  the release 
manager doesn't have to worry about making sure all the required files 
are there.

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.

> 2) Do we exclude them all

in general, yes.  everything generated by the standard auto* tools need 
not be included.  if there's something specialised that most people 
can't be expected to have installed, then sure, keep a generated copy of 
that in CVS.  i'd say don't include the gtk-doc stuff (unless it really 
is that difficult to set up).  keep a copy of the full docs on 
http://xfce.org, generated against CVS.  this should update itself (or 
on demand).  people that are developing apps against xfce libs probably 
should be doing so against CVS anyway (and should backport to stable if 
they feel like it).

> 3) Shouldn't we switch to subversion ? :)
> (Ok, question #3 is definitely another matter :)

hehe, here's a big one.  i think the question that is more important is: 
"does CVS currently address our needs, and, if so, are there any 
problems with CVS that we are specifically having that would justify 
putting work into moving to something else?"  for me, the answer is no, 
but i'm obviously not a heavy user (yet).  i've had a local CVS 
repository on my machine for a few years now that i've used for various 
things, and i've never had problems with it.  most people don't have 
subversion installed on their machines.  is there the option of a 
svn->cvs gateway (for checkouts, at least)?  i wouldn't necessarily jump 
to subversion, anyway.  i've heard some good things about arch 
(http://wiki.gnuarch.org/), tho i'm by no means an expert on the merits 
of the various systems out there.

	-brian