From kde-core-devel Wed Oct 31 09:14:20 2012 From: =?ISO-8859-1?Q?Aur=E9lien_G=E2teau?= Date: Wed, 31 Oct 2012 09:14:20 +0000 To: kde-core-devel Subject: Re: What is the git workflow for kdelibs ? Message-Id: <71142996.k2xtDtxdWf () trinity> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=135167490612045 Le mardi 30 octobre 2012 12:16:40 David Faure a =E9crit : > > Ok, thanks. > > Is this documented somewhere ? >=20 > No (I described it in an email some time ago, but it's not on any wik= i) > 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. >=20 > 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. >=20 > 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 sugge= sted. Additionally, when merging strategy is commit-to-stable then merge-into= - master, it would be great if the document explicitly stated who is resp= onsible=20 for the merge-into-master step. I personally think it should be up to the person who commit to stable t= o =20 merge into master. Unfortunately this is not how it works right now in = kdelibs=20 and I noticed people are expecting other repositories to work like kdel= ibs, as=20 in someone is going to merge into master for them. 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 sta= ble=20 branch (the message which says "this commit is available at http://..."= ) to=20 include a reminder among the lines of "don't forget to merge this commi= t into=20 master, see http://techbase.kde.org/... for more info" Change #2 would be a cron job which would periodically checks for unmer= ged=20 commits and send emails to committers of unmerged commits which are old= er than=20 1 or 2 days. #1 is probably easy to do, #2 would require more work I assume, but sho= uldn't=20 be too difficult, something like this gives you the email addresses of = all=20 commiters of unmerged commits: git log --pretty=3D"%an <%ae>" origin/master..origin/KDE/4.9 \ | grep -v scripty@kde.org | sort | uniq Aur=E9lien