Re: [squid-core] squid-2 commit rules

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