[Bug-gnu-arch] [bug #5101] Major use case: accept / reject patches (a la Linux)

[nobody]

=================== BUG #5101: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=5101&group_id=4899

Changes by: Damien Elmes <address@hidden>
Date: Sat 09/06/2003 at 13:12 (GMT)

------------------ Additional Follow-up Comments ----------------------------
For a real life example, look no further than arch - this is exactly how arch 
development proceeds.



I'm not sure a bug report will help much, though - it really just needs someone 
to "sit down and do it". I made some initial work towards some a quick primer 
for arch (http://repose.cx/ArchPrimer.html) but have been too busy with other 
things recently to polish it off and look at getting it integrated into the 
tutorial. If you're already familiar with arch, just bite the bullet and write 
it :-)



This model is probably a good selling point for arch, too. The tutorial could 
probably do with a rough overview of how it works (without the explicit 
commands to confuse the matter), in a section near the start entitled something 
like "Why arch?". Or maybe there's a section like that already, and I just 
missed it first time around.



=================== BUG #5101: FULL BUG SNAPSHOT ===================


Submitted by: tjl                     Project: GNU arch -- a revision control 
system
Submitted on: Sat 09/06/2003 at 12:57
Category:  tla documentation          Severity:  5 - Major                  
Bug Group:  small feature idea        Resolution:  None                     
Status:  Open                         Release:  1.1pre5                     
Fixed Release:                        Merge Request?:  None                 
Your Archive Name:                    Your Archive Location:                
Assigned to:  None                    

Summary:  Major use case: accept / reject patches (a la Linux)

Original Submission:  One really important use case that's not documented well:



One project manager, several coders. Coders submit changes to project manager, 
project manager may 

1) accept as is

2) reject completely

3) accept, given some further work on the patch ("document this function, do 
this thing in a different way ...")



Now, the problem is how to make this work cleanly in arch.



The problem is mostly related to the handling of the coders' trees and patch 
logs. Somewhat similar to "cherrypicking changes" but in a different way.



The coders want to 1) keep their own changes they're working on , 2) stay up to 
date with project manager's version



Documenting how to make this model work in the docs would be *REAL* nice. ;)



(background: I lead the fenfire (fenfire.org) project and we're planning to 
move to using tla for versioning and would like to use the model I outlined 
above)

Follow-up Comments
*******************

-------------------------------------------------------
Date: Sat 09/06/2003 at 13:12       By: resolve
For a real life example, look no further than arch - this is exactly how arch 
development proceeds.



I'm not sure a bug report will help much, though - it really just needs someone 
to "sit down and do it". I made some initial work towards some a quick primer 
for arch (http://repose.cx/ArchPrimer.html) but have been too busy with other 
things recently to polish it off and look at getting it integrated into the 
tutorial. If you're already familiar with arch, just bite the bullet and write 
it :-)



This model is probably a good selling point for arch, too. The tutorial could 
probably do with a rough overview of how it works (without the explicit 
commands to confuse the matter), in a section near the start entitled something 
like "Why arch?". Or maybe there's a section like that already, and I just 
missed it first time around.


CC list is empty


No files currently attached


For detailed info, follow this link:
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=5101&group_id=4899

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/