Re: [FreeCiv-Java] Status

[Esben Haabendal Soerensen <ehs@xxxxxxxxxxxxxx>]

On 6 Nov 1998, John Goerzen wrote:

> Esben Haabendal Soerensen <ehs@xxxxxxxxxxxxxx> writes:
> 
> > Hi (John)
> > 
> > Did you incorporate my changes ?
> > I could not find a v0.005 on software.complete.org.
> 
> I've got everything except the networking code incorportated.  I ran
> out of time when I was working on it.  I should have something up on
> Saturday.

Great, but I will not be able to do anything before next weekend.
I will head for London tomorrow.  Then on monday I will be attending
the Sun Technology Day!!! hehe

> > I am a little confused about how this patch thingy is meant
> > to work paralel to the CVS.
> 
> OK.  Basically, here's what happens.  I do have CVS archive here, but
> you don't need to know (or care) about it.
> 
> All that you have to do is make a diff with the changes you suggest,
> and mail the diff to the mailing list.  I will then examine it and
> apply it and make a new release.  (Checking it into my local CVS tree, 
> but again, this is hidden.)  You do not need to do anything with the
> $Id$ tags when making a diff.

But i DO no about cvs.

I can see that you have adopted the same strategy for code management
as freeciv.  But there are other ways.

Some of the big Open Source projects actually accepts public checkin.
But that might not be nesesary, but I see no reason why more people
should be able to incorporate source into the source tree.

All this diff and patch maneuvers seems like a lot of extra adminstration,
that could be better solved by a better design.  If we make a good
OO Java design we should be able to give out authority for different
parts of the code, and then enabling these to directly incorporate
new features to the source tree without having to involve a central
manager.

Ok, I see that you continue this discussion below, so I will give
more comments on this below.

> > It seems like you (freeciv dudes) use sending patchfiles much
> > more than comitting to CVS.  Why is that ?
> 
> This is done for the same reasons that the Linux kernel people do.
> Namely:

Luckily there are several differences between the Linux kernel
and the freeciv java client.  Size being one, complexity being
another and hopefully the freeciv java client will have a uniquely
clean modular OO design.

>  * It's easier to discuss patches sent in e-mail.
>    It's easy to have a thread discussing whether or not a given
>    approach is best in e-mail, but not so in CVS.

We could use several branches.  One for development and one for
the officially stable version.

>  * It allows peer review before comitting patches to the program.
>    This helps to preempt bugs.

Multiple branches.

>  * It eliminates the need to have a dedicated CVS server, which can
>    be a security liability in some cases.

Well, this is not an option here, is it ? ;-)
You already have a CVS server, and if this is a problem we can use
the CVS server at sunsite.auc.dk

>  * It is easier for people to follow the changes (for some)

I can't see how this is true.  CVS is great for tracing changes.

> > It seems like a much more tedious task than doing a cvs commit.
> 
> For the person that's doing the CVS (me), yes.  For you, it's no more
> difficult.

I think it is.  CVS is so easy and nice to work with.  It is much
easier to commit and update with cvs than using diff and patch combined
with a zillion email attachments.
Reverting to older versions or peeking in older versions is also
very easy in CVS.

> > Another question:  Who has write access to the freeciv cvs ?
> > Anyone ?
> 
> I would suppose Mitch and David.  I don't know for sure.

Per answered this :-)
Who else is on this list ?

> > As I see it our current phase is the design and framework coding phase
> > (phase 1), and in this phase it seems like a good idea that we are only
> > us two.  If we were o many people we would never get a proposal out there 
> > :-)
> 
> There are more people on the list than just the two of us.
> 
> (PS to those of you reading: feel free to participate in the coding if 
> you'd like!)
> 
> > But for this phase to proceed as quickly as possible I think we should
> > use the CVS server as the distribution method.
> > No need to send patch files around, when we are only us two.
> 
> This is a valid point, in the early development stage, the patch
> method could indeed slow us down.  I hadn't thought of that.
>
> I will see if I can work something up by the time you're able to work
> on it some more next week.  I apologize for the delay, there have been 
> some unexpected events in the last 1.5 weeks that have really cut into 
> my development time.

So, will you setup a cvs account for me ?
If/when this becomes a problem we can just change to using diff/patch
with some central manager(s).

> > This might result in a lot of commits, and the cvs root might be
> > littered with minor versions, but we could just start over again
> > when we begin the next phase.
> 
> I don't care if there are lots of commits.  That's good, actually.
> After all, it's my disk that would get full, not yours :-)

Yeah, and diskspace come really cheap these days.

I promise two report anything interesting I see/hear on the
Sun Technology Day ;-)

-- 
/Esben  (bart@xxxxxxxxxxxxxx)

: But for some things, Perl just isn't the optimal choice.

(yet)   :-)
             -- Larry Wall in <199702221943.LAA20388@xxxxxxxx>