This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Suggested 'plan of attack'


This is just a scheduling idea I'm throwing out to Mark.

For each branch (or other big destabilizing stage 1 type change) which 
is ready to merge, put it on the end of a list:
B-I-B
cp-parser
PCH
?-branch

For each branch, have a set period devoted to merging the branch:
First one or two days when only the branch merging person can commit to 
the trunk or branch, so they can get it done right.

Then a two to four day period of bug fixing only.

Then a short period open for all 'stage-2-worthy' patches (to relieve 
patch list pileups).  During this period, the 'next' branch will be 
updated to the new trunk so that it will be able to merge fairly 
cleanly.  Other live branches will also probably want to update from the 
trunk.

Repeat for each branch until you run out of branches ready to merge.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]