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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
