avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <j...@socialchange.net.au>
Subject Re: [VOTE] build process (for documentation)
Date Tue, 07 May 2002 01:19:06 GMT
On Mon, May 06, 2002 at 05:37:04PM +0100, Paul Hammant wrote:
> Jeff
...
> >Advantages of a CVS branch:
> > - casual users protected from half-implemented changes
> >
> We have precious few casual users.  We can suffer a blitz approach IMHO. 
>  It worked well with excalibur - many people dipped in and fixed things.

I think Pete had it all working before he committed.

> > - if Centipede files need to be checked into CVS, everyone doesn't need
> >   to download them till the system is stable. I'd imagine they'll
> >   change quite frequently, given Centipede's current rate of evolution.
> >
> We run the risk of fork.  Look at how much effort peter spent in Ant 
> encouraging myrmidon as Ant2 that was in a different directory (granted 
> not the same as a fork).  He almost burnt himself out.

I'm not following you. ant2 != myrmidon (yet). AFAIK the lobbying for
'ant2 == myrmidon' has not yet started, and may not be needed if Conor
and Peter can merge their proposals. And he's pretty sprightly still
<pokes Pete> ;P and I don't see anyone about to fork over a doc build
system.

> > - we don't 'commit' ourselves to a system that turns out to be
> >   unworkable. If it works; great, we'll move it to the head when it's
> >   done. If it doesn't, no loss; just abandon the branch.
> >
> That is a good point.  However the major changes are with xdocs and with 
> that we have notthing to lose.  To be honest though, the first commit of 
> Centipede capable build files should be 99% complete, not so?

I don't know. If so, great, let's commit on the head.

> > - we allow the possibility of alternative systems. If someone wants to
> >   try Maven, go ahead in another branch. We can defer the final
> >   decision till we see what really works. Both systems are still
> >   immature and we can't at this point make a definitive choice of which
> >   is better, which is what committing to the head implies.
> >
> Oh blimey.  A real bet on both sides option huh? ;-)

No, a cowardly refusal to bet on either side till I see it working ;P

...
> This is my big point.  If I was going it.  I'd work diigently on HEAD 
> and commit it when no functionality was lost.  I'd fire off an email 
> making the announcement.  If it goes ahead on a branch, I'd be pleased 
> when it reaches the same level of functionality.  Then I will ask "How 
> does it look Jeff?   If it is any good then merge +1 to HEAD..". 
>  Meaning I am sitatistically more likely to be a bystander when branches 
> are concerned.  And I am certainly an active person normally when it 
> comes to build files.

Again, it all depends on how quickly Leo or whoever can get it usable.
It's fine to inflict a 90% working system on users, but not a 10%, 30%,
50%, 70%.. gradually improving system.

I see what you're saying about 'statistically more likely to be a
bystander'. However, for a casual user to try out the branch, they'd
simply have to run './centipede.sh' or 'centipede.bat'. So uninterested
users are protected from a possibly-broken system, while interested
users are one command away from trying it out.


--Jeff
(who's arguing because he likes arguing ;) and doesn't reeeally mind
either way)


> Regards,
> 
> - Paul
> 

--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message