Re: [AD] CVS access to Allegro

[Shawn Hargreaves <shawn@xxxxxxxxxx>]

George Foot <george.foot@xxxxxxxxxx> writes:
> After playing with CVS very briefly, it seems a great system and I'm 
> wondering why we still aren't using it. :)

I think we need to be: otherwise it causes way too much disruption each 
time I get distracted with Real Life stuff :-)

> There was a lot of positive discussion about it last year, but Shawn 
> suggested that things were moving around too much for it to work well 
> in CVS.  More recently he suggested using it again, if someone would 
> set it up, to take away the importance of WIP releases -- there 
> wouldn't be any hurry any more because anyone who wants to can checkout 
> the latest up-to-date version using CVS.

Even releasing WIP versions becomes trivial once you have CVS: anyone can 
do that whenever just by running a few scripts. The way I see it, the big 
benefit of this would be that you can all go on writing stuff, and 
getting new versions out to other people, without being held up just 
because one single maintainer doesn't happen to be around at the moment. 
ie. it allows multiple maintainers, which removes any dependency on a 
single person...

> The only standing issue I can think of is that there's no networked DOS 
> version of CVS.  There is a Win32 version, though

I very much doubt that anyone is using straight DOS for their net access, 
because in addition to no networking CVS, there is a striking lack of 
good email clients and web browsers :-) Certainly I think that anyone 
likely to submit patches to Allegro will already be booting into Windows 
just to send off their email (Am I right? Now prove me wrong, someone :-)

Anyway, there'd probably only be a few people (offhand I'd say you, me, 
Michael Bukin, Peter Wang, and Isaac Cruz) who'd need CVS write access. 
Too many and it would just get confusing, plus it's useful to make sure 
that every change is filtered through someone who has a more detailed 
understanding of the whole codebase, and who can make sure it fits in 
with established coding style, updates all the relevant documentation, 
etc. So most contributors would carry on posting patches (the difference 
being that more people than just myself would be able to apply those 
patches to the official version), and for everyone else CVS would just be 
a way of getting access to the bang-up-to-the-minute latest codebase, or 
if they really couldn't manage CVS, they can always go on grabbing the 
more intermittent WIP versions by http or ftp.

> If most people approve, then, I can register Allegro at SourceForge, 
> add various people as admins and developers, and start keeping an 
> up-to-date CVS tree there.

I think we need to do this. In addition to SourceForge, though, the 
people who provided the space for the WIP's on SunSite Denmark offered to 
set us up a CVS there if we ever wanted one, so that's an alternative 
option if some people feel that Sourceforge is a bit too Borglike :-)
I don't much care either way.

As far as getting it set up is concerned, I've made a few little tweaks 
to my local version since 3.9.32, plus have a todo directory holding 
about 4 megs of patches and emails :-) So we should certainly make sure 
my local version gets used as the starting point, or perhaps better, get 
the CVS ready to go, me make an effort to get this lot of patches dealt 
with and sort out a 3.9.33, and then seed the CVS with that release 
version, and switch over to using it for all future changes. It would be 
a shame if any of these patches got lost during the crossover!

> People posting patches here would have to indicate whether it had 
> already been added to CVS or not, and people commiting CVS changes 
> should still post patches here -- the idea there is that people who 
> want to keep using `diff' to make patches and `patch' to apply them can 
> go ahead, while other people can use CVS instead.

For people with CVS write access, that's easy: any changes should be 
committed to CVS and posted as a patch at the same time. For other people 
it's a bit tricker, though. They'd just post a patch to the mailing list 
like at present, but at that point one of the maintainers needs to take 
over this patch and basically do to it the same thing that I do at the 
moment (hem and haw a bit, mumble, decide whether it's a good idea, 
consider whether there might be any alternative ways to do the same 
thing, check whether it conflicts with anything else or will introduce 
any portability troubles, munge the code about until it looks pretty, and 
then apply it). The only really hairy thing here is, if there is more 
than one maintainer, how do we decide who is in charge of doing that to 
each patch? It could be by program area (eg. Michael does X stuff), or we 
could take it in turns, or perhaps just whoever gets to it first could 
post a quick "thanks, it's under consideration" that would serve both to 
let the poster know it's been received, and to let the other maintainers 
know that it is being dealt with. I really don't know what would work 
best here: ideally something simple and flexible enough not to be a pain, 
but it would be a shame if we ever get patches being lost through nobody 
applying them, or several people trying to apply the same patch at the 
same time...



-- 
Shawn Hargreaves - shawn@xxxxxxxxxx - http://www.talula.demon.co.uk/
"A binary is barely software: it's more like hardware on a floppy disk."