git workflow draft

[Ben Cooksley]

On Thu, Feb 17, 2011 at 10:31 AM, Stephen Kelly <steveire at gmail.com> wrote:
> Michael Pyne wrote:
>
>> An easy way to solve duplicates is to disable sending commit mails for
>> branches other than master, but I personally dislike that solution as it
>> would result in mailing lists like #kde-commits not receiving any emails
>> until the branch is fully landed on master. (I hate to say it, but imagine
>> a security mistake on ksslsocket.cpp in commit 88 of a 121-commit rebase
>> branch -- is everyone on #kde-commits going to review that deeply into the
>> commit chain?)
>
> If someone writes 100 commits and pushes them without review then that's a
> social problem. First of all I can't imagine a clean branch that could be so
> big. Surely that would end up being a 10 commit push, some more work, a
> push, some refactoring, a push, a feature, a push, more refactoring, a
> feature, a push, etc. Do we really think that having large topic branches
> which contain really only one topic that makes sense only to push in one go
> will be a normal situation?
>
> People who are interested in ksslsocket will see the commits.
>
>> In addition as Andreas Pakulat mentioned in a response to a
>> rebase-workflow in kde-scm-interest, this completely deletes the fact that
>> the development happened in a branch at all (we could simply retain the
>> old solid/make-it-cool ref so we don't lose that history, but that would
>> make the repository correspondingly larger).
>
> The assumption that all of the history is useful to have by definition was
> called into question. I suggested creating useful history so that all
> history in the release branches is useful.
>
>> A lot of this debate hinges on how we want email-based review to work
>> however (to be clear, kde-commits is not the only recipient of email for
>> each git commit, the CIA.vc web service also receives email for each
>> commit). If we want to avoid huge email bombs then we need to either use a
>> merge-based workflow in general, or have some other technical solution to
>> allow for a rebase-based workflow, such as your idea regarding lumping
>> everything into a simple notification email (although this means CIA.vc
>> and possibly things like Commit Filter wouldn't work... :( )
>
> I guess we're writing emails at the same time here, but just to have it in
> another place, I don't see 'email bombs' being a problem, but a convenient
> grouping of stuff I'm interested in, and stuff I'm not interested in in
> bigger lumps.

Ah, you clearly have no understanding of the damage a "flood" or
"email bomb" causes.
Prior to git.kde.org being made available for mainstream use, in the
1st generation of hooks, a flood occurred.

This flood completely filled ktown's email queue, preventing any
kde.org email from being delivered until sysadmin destroyed the
offending emails from the queue. For the emails that were delivered,
it caused many bug reports to be altered, creating even more traffic,
and placed an enormous amount of stress upon CIA, which took many
hours for it to recover from, and blocked notifications for all other
open source projects which use CIA for several hours.

The effects of an email bomb can be extremely dangerous. They cannot
be permitted to occur under any circumstances.

>
> Another important point I think is that 'topic branches' will not
> necessarily be normal, but exceptional. Most KDE developers are used to
> commit early commit often, and that might translate into 'push early, push
> often', so we'll end up seeing 2 or 3 commit pushes and very few monsters. I
> rarely push more than 10 commits and very rarely if ever have pushed more
> than 20.
>
>
>
>

Regards,
Ben Cooksley
KDE Sysadmin