[development] bzr battle plan

[Gerhard Killesreiter]

Bèr Kessels wrote:

>Op vrijdag 25 november 2005 00:17, schreef Angie Byron:
>  
>
>>1. What are our major gripes about CVS and where has CVS failed us?
>>    
>>
>
>CVS forces everyone to keep patches in a queue up to date (revisions patch). 
>  
>

I fail to see how I wouldn't have to do that with any other tool. Are 
the merge algorithms so much better?

>CVS does nothing to help ease this pain.
>  
>

What do other systems do?

>CVS has a very hard to grok concept. It requires users to get a complete new 
>idea of file management. 
>
>  
>

Hmm, not really.

I have to admit that I hardly understand how CVS works, yet I am able to 
use it.

>>2. On the flip-side, what are some cool things about CVS that we like and
>>want to make sure the next package has?
>>    
>>
>
>The amount of tools available for it. Not only GUIS, also scripts and all 
>that.
>
>  
>
>>3. What types of development ventures have we embarked on in the past that
>>were difficult to do with CVS and patches?
>>    
>>
>
>Grouped efforts on a certain issue. Forms API indeed. 
>  
>

This would have been possible with CVS as well.

>Usability improvments. Most often a patch does not "explain" anything in 
>usability improvements, because patches are really "hardcore developers 
>communication".
>  
>

Well, code improvements are for hardcore developers to understand. I 
don't get the point you are trying to make.

>Distribution management. This has not even been tried. 
>
>  
>

Right. I actually question if this will work with Drupal and its current 
rather tight access to core cvs. if you want to make this access more 
open, you should discuss this and not your pet RCS.

>>4. What kinds of "Wouldn't it be cool if..?" scenarios could we think of
>>that would help ease development?
>>    
>>
>
>Manage distributions and "flavours" of Drupal. 
>Make a patch, then let it do its own pimping (instead of me going around IRC, 
>jabber, mail, bumping issues etc). 
>  
>

hä?

>Make it possible to let a patch linger in a queue for a while, yet it can 
>still be applied.
>  
>

See above, if there are changes in core, any RCS will have to merge it 
and might fail.

>Allow me to branch off (core) modules to work on that for
> * my own projects (yet someone might be interested in that work too)
> * improvement of a core project. Patches alone are unfit for large changes
> * Distributions. They might want slightly modified version of stuff. Or 
>additional files
>
>  
>

This can all be done with CVS, IIRC.
Making such erroneous claims won't really increase your chance to get 
any change through.

The improvements I'd be interested in is:

- web frontend for uploading new versions for translators and theme 
designers (if they wish to use it)
- being able to lock out other people from my projects or rather allow 
specific peopel write access to my projects.
- automatic testing of applicability of mailed/uploaded patches.
- also working offline and making patches against the main repository.

Those are some of the things that would _really_ help Drupal development 
because those refer to things we do all day. The forms API thing 
happened once in over four years and I don't see any such large changes 
coming up soon again (and it could have been done with CVS too).

So please: People who want us to change away from CVS to anywhere should 
provide _real_, _relevant_ use cases and advantages and not FUD.

Cheers,
    Gerhard