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
