On lör, 2008-07-19 at 13:04 +0800, Adrian Chadd wrote: > On Sat, Jul 19, 2008, Amos Jeffries wrote: > > > >Well, who knows this stuff well enough to throw it up on the Wiki? > > > > > > > Yo. done finally. > > http://wiki.squid-cache.org/MergeProcedure > > Also, what should be done for the squid-2 merging?
A somewhat simpler procedure is used for squid-2, a bit based on what you think yourself of the code to be merged: 1. The merge should be well tested, isolated, documented and cleaned up etc. 2. The merge should only contain a specific change and not multiple unrelated changes. Unrelated changes should be broken up into separate commits each following their own path in this procedure. 3a. Larger or otherwise intrusive changes is sent to squid-dev for review. Ok for commit if there is a positive core response or no negative responses from anyone in a week. 3b. Smaller changes or changes you do not expect someone to say no on may be committed immediately. 4. If a change is later found to cause trouble and not obviously trivial to fix then it will be thrown out, waiting for someone to make a proper fix. Please try to not commit unfinished stuff needing more work to actually work the way intended. HEAD is not meant for development, that's supposed to done on branches.. If a follow up change (bugfix etc) is committed directly related to an earlier change please refer to the subject (first line) of the previous in the commit message. If you suspect that there will be a series of incremental commits relating to a specific feature or reorganisation then make the subject line easy to connect together by starting the title line with a short featurename: (i.e. "rproxy: header fixes") Add to the above the parts of the Suqid-3 procedure you think makes sense. Use of common sense is the main rule of conduct. Regards Henrik
signature.asc
Description: This is a digitally signed message part
