Workflow Idea for 4.10

[Stephen Kelly]

Alexander Neundorf wrote:

> On Friday 16 March 2012, Kevin Ottens wrote:
>> Hello,
>> 
>> On Wednesday 14 March 2012 14:38:19 Aaron J. Seigo wrote:
>> > [...]
>> > this is what really piques my interest: merge based workflow.
>> > 
>> > an integration branch would be fantastic. that branch should rebase
>> > periodically off of master and only be used to merge feature branches.
>> > this branch would largely take the place of current master: where
>> > development "happens". feature branches should be merged into
>> > integration on a regular basis and developers and testers should track
>> > this integration branch in their day-to-day usage
>> > 
>> > integration should always be open to feature branch merging. master
>> > should only be open for feature merge when not in freeze, however.
>> > 
>> > when in freeze, either a stabilization branch could be made off of
>> > master for this purpose (probably a very good idea for larger fixes)
>> > which is then merged down in master at known good points .. or ..
>> > master is opened for bug fixes directly in those periods. the latter is
>> > probably not as "good" from a stability POV, but may be more reasonable
>> > and less of a workload for people doing the actual work.
>> > 
>> > so what i'm interested in hearing is what sort of branch management
>> > scheme would work for people. i'm happy to maintain either an
>> > integration or the master branch (but not both).
>> > [...]
>> > 
>> > note that the methods being (slowly) adopted for frameworks devel are
>> > also moving in the direction noted above.
>> 
>> I'd just like to add my 0.02€ here.
>> 
>> I've been thinking about the git workflow to be used in KDE Frameworks in
>> the future. Based on observations and discussions with current and future
>> frameworks maintainer, I think that it would be a mistake to force a
>> single workflow for all the frameworks. I'm not 100% sure what the final
>> solution will be but it's likely to end up being a short list of blessed
>> workflows: 1) Full game, one branch per feature with review time in an
>> integration/testing branch before hitting master;
>>  2) Intermediate, one branch per feature with merge in master after
>> reviewers/maintainer validation;
>>  3) Easy, features directly developped in master[1].
> 
> Sounds good.
> But OTOH, having one workflow for KDE frameworks (i.e. not even all of KDE
> SC) would be also a really good thing to have. It will make contributing
> easier. Would 2) be an option for KDE frameworks ?
> 

:/

Am I the only person who values browsable history? Repositories where you 
can run gitk and see something useful.

What Aaron proposed is exactly what CMake does. The result is that if you 
run gitk, you can't see the actual patches. If you run gitk --first-parent 
on master you *only* see merges, so the only information you can see is the 
name of the branch that got merged (which is in the git commit message), not 
the actual patch, and to see the patches in a topic you have to know the 
name of the topic.

You can't just browse the commits, so you can't practically do post-commit 
review with gitk, as I do. Using email for that really doesn't work for me 
for one thing. If I want to look at commits that I vaguely know exist but I 
don't know which topic branch it came from, I should be able to browse fot 
that. I have the git repo in front of me, so I should be able to use it 
without jumping through too many hoops.

We're going to have small repos after splitting, not large ones. Having a 
branch and a merge per patch commit in small repos is way overkill. Let's 
have readable history instead please.

My vote is for 3 (for frameworks in general at least), and if people want to 
create branches like the actions or colors ones we currently have, lets do 
that in scratch or personal repos.

They can be rebased/squashed to readable patches when the learning about how 
to create a framework by a contributor is done (that's not useful history). 

The actions branch should all be squashed into one commit because originally 
the contributor didn't realize the steps that are needed to make a split 
(move the files, update some include_directories, give the new framework a 
name which doesn't have kdeui in it, rename the deprecated and export 
macros). Currently none of those commits actually build because they don't 
do all of the necessary steps and even the tip of the branch isn't complete 
because the export macros haven't been changed. Once the branch is fixed to 
build, I will squash and rebase it to origin/frameworks to commit.

The colors branch also contains lots of commits with typos, fixes for typos, 
adding missing files, removing stuff from CMake files which should have been 
removed in previous commits, etc, so I will also fix/squash/rebase that one 
when it's ready, but likely into more commits.

Note that I say I'll do the rebase. I'm not expecting anyone else to have to 
know how to do it. (In CMake, despite using a new branch for everything they 
do sometimes request rebases to that the commits are clean).

I think people think that if they're committing in a branch which is not 
master, that they are 'free' and their commits don't have to build, and that 
all that matters is that the end result actually gets merged, but that's not 
really true. We should have history which is both readable and buildable 
imo. 

Part of the way we get to that is by not encouraging everyone to make lots 
of branches, encouraging people to have branches in scratch repos if they 
want to have a branch, and encouraging people to submit to master self 
contained patches which build instead.

Making commits that don't build and making mistakes is understandable of 
course especially for new people (and I sometimes make commits that don't 
build too), but we should at least aim higher.

Thanks,

Steve.