What is the git workflow for kdelibs ?

[Aurélien Gâteau]

On Thu, 01 Nov 2012 12:05:51 +0100, David Faure wrote:
> 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....)

Don't worry, you are not alone :)

>> 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.

Having to merge each one-liner at a time would indeed be painful, but
this is not what I suggest: the reminders would be sent with a delay of
1 or 2 days, making it possible for you to do one single merge for a 
few
one-liners without getting reminded.
On the other hand, if you committed a one-liner more than 2 days ago 
and
it has not been merged, the reminder would make sure it eventually gets
in.

Aurélien