Re: Issue Tracker Used? Git migration checklist.

[Fred Cooke <fred dot cooke at gmail dot com>]

A default set of permissions on a default git repo allows you to do
*anything* including delete *everything* (even if only temporarily)
:-) Clearly this is unwanted behaviour. As you say, a single master
branch would be sufficient for that repo, however allowing it to be
force pushed would be stupid IMO, and could easily create a mess.
Having a second staging repo is not inventing process, and neither
here nor there. It makes zero difference whether one is used or not,
except that the quality of the material entering would likely be
higher, and the rate slower, with a gatekeeper.

If you're not familiar with the kernel process, you may like to read
2.3 from this: http://kernel.org/doc/Documentation/development-process/2.Process

One major point of Git (and Hg and the like) is the distributed
nature, which means many things, not least of which free committing to
your own repo which is identical to the official one. Everyone can do
that, thus you no longer REQUIRE a large number of people with access
to a central repo, only a few who (very efficiently) take in changes
from those down stream of them.

This is all somewhat off topic anyway.

Fred.

On Fri, Oct 26, 2012 at 3:15 AM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Fri, 26 Oct 2012, Fred Cooke wrote:
>
>> Given such a single central master repository with no gatekeeper (bad
>> idea?) and many many committers, a hook would also be required to
>> prevent people from force pushing the golden copy. It'd  be much wiser
>> to have a shared repository that wasn't the public master, and the
>> golden copy that was pushed to by a trusted few from the shared one,
>> post review and perhaps clean up.
>
> Don't try to invent structures different from what's standard in GNU
> toolchain work, which is a shared repository everyone relevant can push
> to.  I'm presuming patch review practice is unchanged (i.e. patches posted
> to the most appropriate mailing lists for the projects using the shared
> toplevel, and reviewed there).  Configuration saying what pushes are
> allowed is part of what would need reviewing for the shared repository
> (this particular repository would be simple - no tags, no branches other
> than master needed, so no questions about permissions for deleting tags
> and branches, as all tagging and branching would continue to be done in
> the repositories for the substantive projects that import files from this
> repository for the shared toplevel).
>
> --
> Joseph S. Myers
> joseph@codesourcery.com