Re: more work required by new release system? (was re: CVS branch work best practices?

Derek Wright wrote:

> b) you can do all your new feature development in HEAD
and never have to 
> merge.  for the 4th time in 12 hours, RTFM:
> http://drupal.org/n
ode/17570#HEAD
OK, I stand corrected, but it'd probably be clearer to long
time contrib 
users if it said (in the section 'Use it for the "new
feature" branch for 
the current stable core') something along the lines of:

"long term  contrib users should note that this is in
effect the method 
generally used before the new release system was
implemented, you don't 
*have* to change the way you work with CVS"

> do 
> whatever you want, including what you've always done.
Honestly, even reading the documentation for about the 4th
time[1] it's not 
at all clear to me that you can effectively 'carry on as
usual' as far as 
CVS is concerned (obviously the web side is a little
different).

The documentation provides a very detailed explantion for
new users, perhaps 
what's lacking is 'what's changed' guide for 'long term'
contrib users?

>> tracking module updates if you're used to pulling
them from cvs.
> which, in practice, is tiny.
Several hours so far in my case.

> only a small minority of modules have more 
> branches than core does.
The problem is you have no way of knowing that without
surfing each project 
page and looking, and each time you do an update then it's
possible the 
module maintainer will have changed their working practice.
But...

> but, this is becoming less and less of an issue, thanks
to nedjo, merlin 
> and myself working on the "ask drupal.org if my
site is up-to-date 
> XML-RPC interface":
> http://drupal.org/node/4
8580
Indeed, I've installed release_monitor too. I can see that
this will get 
easier, which is why I didn't really go into it in the last
mail.

I'm also looking forward to your thoughts on:
http://drupal.org/node/
116131
and whether it's feasible, as you work through the backlog.

 > next time you run "cvs update" in the
 > top level of your modules directory,
I stopped working like that a while back, doing cvs export
on the handful of 
modules I actually use instead, so I can import into my svk
repo without all 
the CVS folders. But really I should sit down and work up a
script to strip 
out the CVS folders before import and just use cvs co...but
I'm rambling.

>> but you're making us all work harder, not true.
I stand (largely) corrected. Apologies for such a terrible
welcome back.


[1] In my defense I have to say I'm seriously sleep deprived
at the moment 
due to my young children.

-- 
Adrian Simmons (aka adrinux) <http://adrinux.perlu
cida.com>
e-mail <mailto:adrinuxperlucida.com>

On Feb 26, 2007, at 1:32 PM, Adrian Simmons wrote:

> The documentation provides a very detailed explantion
for new  
> users, perhaps what's lacking is 'what's changed' guide
for 'long  
> term' contrib users?

good idea.  if anyone wants to find the right spot in the
handbook  
for this and draft an initial version, i'd be happy to edit
it for  
correctness...

and yeah, i wrote the docs assuming people didn't know much.
 i  
figured the "old hands" could read the docs, see
how it was (or  
wasn't) different from what they usually do, and decide for 

themselves.  but, i can see why that wasn't necessarily the
best  
assumption on my part.  luckily, online docs can be easily
changed  
after the fact... it's not like i published a physical book
about the  
new release system or anything. ;)

> Apologies for such a terrible welcome back.

it could have been (much) worse. ;)

> I'm also looking forward to your thoughts on:
> http://drupal.org/node/
116131
> and whether it's feasible, as you work through the
backlog.

given enough work, just about anything is
"feasible".  after a very  
quick skim, i'm not convinced it's such a good idea, or the
best  
thing to spend time on, but i'll read more closely and reply
there.

-derek