Re: irc meeting for kdelibs git workflow
On Friday, February 4, 2011, you wrote: On Tuesday 01 February 2011, Aaron J. Seigo wrote: * 3rd party examples we can learn from: http://public.kitware.com/Wiki/Git/Workflow/Topic Qt? http://wiki.videolan.org/Git thanks; added to http://community.kde.org/20110213_GitWorkflowAgenda (feel free to add things yourselves as well :) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: irc meeting for kdelibs git workflow
On Wednesday 02 February 2011 09:19:29 Oswald Buddenhagen wrote: On Tue, Feb 01, 2011 at 01:37:26PM -0800, Aaron J. Seigo wrote: * adapting http://techbase.kde.org/Policies/SVN_Commit_Policy i'd suggest a look at http://qt.gitorious.org/qt/pages/CommitPolicy, in particular point 8 of the rules. the point it makes is independent from using git (in fact, we have a similar point already), except that with git it is so much easier to do that, so at least a certain percentage of people may actually adopt it. +1 to that, especially the commit template and more descriptive commit messages. In fact, attached is my attempt at such a template based on the Qt one. It's a bit verbose as it's intended as an educational tool, once people know what's expected they can delete all the comments in their local copy. If the Commit Digest guys want some tags added to make their life easier, now would be the time to speak up. John. # ---[ You MUST wrap all lines at 72 characters ]--| # # ---[ Please see http://techbase.kde.org/Policies/Commit_Policy ]-| # # ===[ Subject ]===| # ---[ One line only, short meaningful description to show in logs ]---| # ===[ Details ]===| # ---[ You MUST leave one blank line after Subject line ]--| # ---[ Describe what has changed and explain why it has changed ]--| # ===[ Fields ]| # ---[ Uncomment and edit as applicable ]--| # ---[ Add Feature to release changelog ] # ---[ Optionally close a wish in bugs.kde.org as implemented ] #FEATURE: optional bug number # # ---[ Close a bug in bugs.kde.org as fixed, with optional version ] #BUG: bug number #FIXED-IN: release version # # ---[ Copy commit message to a bug in bugs.kde.org ] #CCBUG: bug number # # ---[ Copy commit message to an email address ] #CCMAIL: email # # ---[ Close a review in reviewboard.kde.org as submitted ] #REVIEW: review number # # ---[ Advise documentation team of user visible changes in the gui ] #GUI: # # =|
Re: irc meeting for kdelibs git workflow
On Wed, Feb 2, 2011 at 08:45, John Layt wrote: On Wednesday 02 February 2011 09:19:29 Oswald Buddenhagen wrote: i'd suggest a look at http://qt.gitorious.org/qt/pages/CommitPolicy, in particular point 8 of the rules. the point it makes is independent from using git (in fact, we have a similar point already), except that with git it is so much easier to do that, so at least a certain percentage of people may actually adopt it. +1 to that, especially the commit template and more descriptive commit messages. In fact, attached is my attempt at such a template based on the Qt one. It's a bit verbose as it's intended as an educational tool, once people know what's expected they can delete all the comments in their local copy. I like it. Good work. Parker
Re: irc meeting for kdelibs git workflow
Zitat von John Layt johnl...@googlemail.com: On Wednesday 02 February 2011 09:19:29 Oswald Buddenhagen wrote: On Tue, Feb 01, 2011 at 01:37:26PM -0800, Aaron J. Seigo wrote: * adapting http://techbase.kde.org/Policies/SVN_Commit_Policy i'd suggest a look at http://qt.gitorious.org/qt/pages/CommitPolicy, in particular point 8 of the rules. the point it makes is independent from using git (in fact, we have a similar point already), except that with git it is so much easier to do that, so at least a certain percentage of people may actually adopt it. +1 to that, especially the commit template and more descriptive commit messages. In fact, attached is my attempt at such a template based on the Qt one. It's a bit verbose as it's intended as an educational tool, once people know what's expected they can delete all the comments in their local copy. If the Commit Digest guys want some tags added to make their life easier, now would be the time to speak up. John. I like it but would propose: # ===[ Subject ]===| # ---[ One line only, short meaningful description to show in logs ]---| # ===[ Details ]===| # ---[ Blank line above intentional. Do not remove ]--| # ---[ Describe what has changed and explain why it has changed ]--| It think that is more robust . Mike This message was sent using IMP, the Internet Messaging Program.
Re: irc meeting for kdelibs git workflow
On Wednesday 02 February 2011, Oswald Buddenhagen wrote: On Tue, Feb 01, 2011 at 01:37:26PM -0800, Aaron J. Seigo wrote: * adapting http://techbase.kde.org/Policies/SVN_Commit_Policy i'd suggest a look at http://qt.gitorious.org/qt/pages/CommitPolicy, in particular point 8 of the rules. the point it makes is independent from using git (in fact, we have a similar point already), except that with git it is so much easier to do that, so at least a certain percentage of people may actually adopt it. I don't see where this document describes the workflow to use with git. Alex
Re: irc meeting for kdelibs git workflow
On Tuesday 01 February 2011, Aaron J. Seigo wrote: hi everyone ... with git having finally arrived more-or-less, we find ourselves without a well defined work flow for kdelibs (and by extension other KDE repositories) i don't think we can or should hope and pray that our sysadmins will perform another magic trick and solve this for us, nor can we all just sit here looking at each other. so i'd like to suggest that we gather on irc in the near future and hammer this stuff out. weekends tend to be better for many it seems, so i've put up a doodle here: http://doodle.com/htgi56p8n2i7n3i8 where you can register your intention to attend and when you can. it covers this weekend and next. i can't attend this weekend, but that shouldn't stop others if this weekend is best for the majority. a draft agenda might look like: * 3rd party examples we can learn from: http://public.kitware.com/Wiki/Git/Workflow/Topic Short version of the cmake git workflow: * pull/update master * for any change, create a topic branch from master * work in the branch... * when done, merge the branch into next and push Once every week Brad and Dave from Kitware sit down and merge from next into master, to create a fresh master with the new stuff. I'm quite happy with that. I guess it doesn't work for KDE, or how could the merging from next into master be done ? Alex
Re: irc meeting for kdelibs git workflow
On Wednesday, February 2, 2011, Alexander Neundorf wrote: * for any change, create a topic branch from master * work in the branch... in cmake development, how do developers find each other's branches to check on works-in-progress, collaborate, etc? are they pushed to a shared repository somewhere, documented somewhere where they are easily found, ...? I guess it doesn't work for KDE, or how could the merging from next into master be done ? i don't know about kdelibs, but i'm going to end up doing that for large parts of kde-workspace. (though i'm hoping/expecting for help from others so that it's not just bottlenecking on me alone. :) so maybe it's not without hope that we find a few people who play the role of merge master for kdelibs as well. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: irc meeting for kdelibs git workflow
On Wednesday 02 February 2011, i...@michael-jansen.biz wrote: Zitat von John Layt johnl...@googlemail.com: On Wednesday 02 February 2011 09:19:29 Oswald Buddenhagen wrote: On Tue, Feb 01, 2011 at 01:37:26PM -0800, Aaron J. Seigo wrote: * adapting http://techbase.kde.org/Policies/SVN_Commit_Policy i'd suggest a look at http://qt.gitorious.org/qt/pages/CommitPolicy, in particular point 8 of the rules. the point it makes is independent from using git (in fact, we have a similar point already), except that with git it is so much easier to do that, so at least a certain percentage of people may actually adopt it. +1 to that, especially the commit template and more descriptive commit messages. In fact, attached is my attempt at such a template based on the Qt one. It's a bit verbose as it's intended as an educational tool, once people know what's expected they can delete all the comments in their local copy. If the Commit Digest guys want some tags added to make their life easier, now would be the time to speak up. John. I like it but would propose: # ===[ Subject ]===| # ---[ One line only, short meaningful description to show in logs ]---| # ===[ Details ]===| # ---[ Blank line above intentional. Do not remove ]--| # ---[ Describe what has changed and explain why it has changed ]--| It think that is more robust . I like it as well. How can I make sure calligra hackers get to see this when they try to commit? -- Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org
Re: irc meeting for kdelibs git workflow
Quoting Boudewijn Rempt b...@valdyas.org: I like it as well. How can I make sure calligra hackers get to see this when they try to commit? Just create a text file named .commit-template in your repo's root folder with the template :) Cheers, Artur ---
Re: irc meeting for kdelibs git workflow
Quoting Boudewijn Rempt b...@valdyas.org: I like it as well. How can I make sure calligra hackers get to see this when they try to commit? Ah and add: [commit] template = .commit-template to your git config file (I forgot this in the other mail :) Cheers, Artur PS: thanks Alexis :P ---
Re: irc meeting for kdelibs git workflow
On Wednesday, February 2, 2011, Boudewijn Rempt wrote: In calligra, i was surprised to see people taking to branching like pigs to muck or fish to water. yeah, they are awesome :) We now have 37 feature branches, of which several have merged to master after review already. There's a simple naming pattern that's become sort of the calligra culture already -- subproject_topic_commit-name interesting; we're doing similar in kde-workspace: commit-name/topic; most of the time it's clear from the topic what the subproject is, so we haven't yet felt the need for subproject in there. but then again, we're only on our fourth feature branch :) what i'm finding nice with commit-name/topic is that i can track things easily by person of origin: KDE/4.6 is official while aseigo/activitiesrunner is something i'm working on. i can see how putting the subproject in front of that can add another nice layer of grouping as well. hm.. we might end up borrowing that strategy :) -- and it all works out very well. Master is is everyone pushing their branches to the main repository, or keeping them in separate cloned repositories? for kde-workspace we're seriously considering using a shared clone (not quite a team clone, more like a communally abused personal clone ;) so that the commit hooks don't get run on feature branches until they are ready for merging (which is particularly a nuisance with commits that have BUG: in the log message) but so that we can keep our development still in one easy to find place. that would make master in the clone our integration branch, and master in kde- workspace our shipping branch. i'm still working out the amount of merge work that will end up making for us, though ... -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: irc meeting for kdelibs git workflow
On Wednesday, February 2, 2011, Boudewijn Rempt wrote: On Wednesday 02 February 2011, Aaron J. Seigo wrote: -- and it all works out very well. Master is is everyone pushing their branches to the main repository, or keeping them in separate cloned repositories? Yes, to the main repository. No public clones. We might have to rething that when we have a few hundred branches -- on the other hand, branches can be deleted when done with, or we can add a datestamp or something like that. i've operated under the assumption that we'd delete branches every so often. maybe once a year as a (literal?) spring cleaning, every branch older than a certain age that's been merged .. which implies keeping track of those branches .. hm... for kde-workspace we're seriously considering using a shared clone (not quite a team clone, more like a communally abused personal clone ;) so that the commit hooks don't get run on feature branches until they are ready for merging (which is particularly a nuisance with commits that have BUG: in the log message) but so that we can keep our development still in one easy to find place. Hm... yes -- the BUG keywoard can be tricky. We haven't encountered it yet, with people being very good about using CCBUG in the branches, and BUG in the merge commit message. yes, that's another approach i suppose... -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: irc meeting for kdelibs git workflow
On Wednesday 02 February 2011, Aaron J. Seigo wrote: On Wednesday, February 2, 2011, Alexander Neundorf wrote: * for any change, create a topic branch from master * work in the branch... in cmake development, how do developers find each other's branches to check on works-in-progress, collaborate, etc? The group of cmake developers is small. It's about 4 people at Kitware, and then mostly me and two other guys outside of Kitware who commit C++ sources I think (but there are more module maintainers). What we do mostly does not overlap, so e.g. I don't feel the need to check what e.g. Eric is doing currently. The cmake git stage is basically for announcing please merge this next week into master. For other things using github or gitorious is recommended. ...and maybe gerrit in the future. Bigger things which need coordination are discussed on the mailing list first. Since last year doing a patch release every three months is planned, features are discussed at the beginning of the period (the last time with an actual phone conference). So, not sure there is in this regard much to learn for KDE. Alex
