What is the git workflow for kdelibs ?

[David Faure]

On Wednesday 31 October 2012 10:14:20 Aurélien Gâteau wrote:
> Le mardi 30 octobre 2012 12:16:40 David Faure a écrit :
> > > Ok, thanks.
> > > Is this documented somewhere ?
> > 
> > No (I described it in an email some time ago, but it's not on any wiki)
> > If you have an idea for where we could document it, I will then push other
> > module maintainers to also write up the git workflow they want to see,
> > since I myself have the same question in other modules.
> > 
> > I think community.kde.org would be the right place (it's internal, it
> > doesn't affect KDE app devels outside of git.kde.org), but all I can see
> > about git is http://community.kde.org/Sysadmin/GitKdeOrgManual
> > which is more about the technical setup.
> > 
> > Maybe start a new webpage at the toplevel of community.kde.org?
> > GitWorkflowForEachModule? :-)
> 
> Would love such a page as well, but rather on techbase, as others suggested.

OK.
(seems I'm still confused about techbase vs community....)

> Additionally, when merging strategy is commit-to-stable then merge-into-
> master, it would be great if the document explicitly stated who is
> responsible for the merge-into-master step.
> I personally think it should be up to the person who commit to stable to
> merge into master. Unfortunately this is not how it works right now in
> kdelibs and I noticed people are expecting other repositories to work like
> kdelibs, as in someone is going to merge into master for them.

I see. Well, it's going to change in kdelibs anyway, as soon as we branch out 
other modules for 4.10, we'll reopen master, it will be less confusing to 
everyone.

And I agree about "the person who commit to stable to
merge into master" because solving conflicts in other people's code is not fun, 
and dangerous.

> We could gently push people into doing the merging with two changes:
> 
> Change #1 would be modifying the message you get when you push to a stable
> branch (the message which says "this commit is available at http://...") to
> include a reminder among the lines of "don't forget to merge this commit
> into master, see http://techbase.kde.org/... for more info"

Good idea.

> Change #2 would be a cron job which would periodically checks for unmerged
> commits and send emails to committers of unmerged commits which are older
> than 1 or 2 days.

Hmm, why not, but on the other hand there isn't much point in creating one 
merge commit for every trivial one-liner fix, it's ok to merge all of these in 
one go later on. I know I'm complicating things by saying that, basically 
dividing commits into "trivial" and "might create a conflict on merging", and 
it's sometimes difficult to know which is which.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5