Git Worflow, branch creation.

[Ben Cooksley]

2011/5/19 Aaron J. Seigo <aseigo at kde.org>:
> On Wednesday, May 18, 2011 22:08:00 Alexander Neundorf wrote:
>> From my side, I would strongly prefer to have one policy which is used at
>> least for all of KDE SC, (what was trunk/KDE/ before), if possible also for
>> kdesupport.
>
> agreed. and in working on this:
>
> http://techbase.kde.org/Development/Tutorials/Git/Feature_Development_Workflow
>
> that is our goal. to make something that we can propose to all of KDE. the
> above workflow documentation will change a lot before then as people offer
> input, we discuss at it face-to-face meetings (the above was the result of
> such a small gathering at Tokamak 5) and we actually try it out.
>
> what we do need and are still lacking is a writte nlist of requirements that
> all our stakeholders have so that we can craft a solution that meets them.
> right now the requirements are being passed around "orally" and that's
> probably not good. to that end, i've added a (perhaps temporary) Requirements
> section to the above wiki page:
>
> http://techbase.kde.org/Development/Tutorials/Git/Feature_Development_Workflow#Requirements

I see quite a few problems with that workflow:

First you are using a repository outside the main repository. Scratch
and clone repositories do not have email or CIA notification provided
to them due to both configuration issues and to the need to permit
those whose personal workflows depend on rebasing to work.

This means those who would normally do code reviews as it takes place,
as well as those who monitor the state of KDE such as the Commit
Digest are effectively kept out of the loop until it is pushed to the
final repository.

Second you are heavily advocating rebasing. This shouldn't be done in
public repositories as it:
- Inflates the size of the repository.
- Requires some Git magic to recover if the branch you are currently
using gets force pushed.
- Is detected as new commits by the hooks, which if you were to
operate in the main repository would cause re-notification of commits.

If you were to continue with your current workflow, then you would
likely need the assistance of Sysadmin everytime you wanted to merge a
significant feature which comprises of more than 100 commits into the
main repository. The hooks forbid pushes of more than 100 commits in
order to protect our infrastructure - and that of others such as CIA.

It also makes it harder to perform in place reviews as the code may
have changed significantly, demotivating those who would normally
perform in place review (these reviews predate Reviewboard existing -
and still continue to this day)

>
> please feel free to add items to it that may be missing.
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Development Frameworks
>

Please reconsider your proposed workflow.

Regards,
Ben Cooksley
KDE Sysadmin