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, [email protected], http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5
