<br><br><div class="gmail_quote">On Tue, Feb 15, 2011 at 10:51 AM, Aaron J. Seigo <span dir="ltr"><<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
hi all....<br>
<br>
so after the meeting on Sunday, here is where we are in terms of a draft<br>
workflow. more complete meeting minutes can be seen here:<br>
<br>
<a href="http://titanpad.com/SnJwFW2iXL" target="_blank">http://titanpad.com/SnJwFW2iXL</a><br>
<br>
the goal of the meeting was to come up with a draft of a mutually agreeable<br>
git workflow for kdelibs and kde-runtime. the hope is that this can become a<br>
template for the rest of the SC modules (kde-workspace will follow the kdelibs<br>
workflow, for instance), as well as as many other KDE projects as possible.<br>
this is to help ensure a general continuity to how we work across KDE.<br>
<br>
Topic Branches<br>
=============<br>
<br>
All new development should happen in a branch. Git makes branches very cheap<br>
and they can be local or remote. There are few if any really good reasons not<br>
to use branches, so development directly in master should be generally<br>
discouraged.<br>
<br>
Topic / feature branches should be public and pushed to the main repository<br>
where they are easy for others to find and collaborate on. They should start<br>
as a branch off of master. We do not want git to become, even unintentionally,<br>
a road to segregated, private development at the expense of our collaboration<br>
as a community. With public branches in a shared repository, even a git pull<br>
will inform of new development that is happening. Git then becomes an<br>
important piece of our development communication with each other: a new branch<br>
means new activity.<br>
<br>
Only features / topics that are intended from the state to be merged with<br>
master should end up in the main repository, however. More experimental and/or<br>
long term efforts (an example presented was the kconfig refactor leading up to<br>
4.0) should start in a personal clone, and when/if the work crosses the border<br>
into "this is realistically going to be merged with master" it can be moved<br>
into a branch in the main repository.<br>
<br>
After merge with master, topic branches should be deleted from the main<br>
repository.<br>
<br>
Branch Naming: if a branch is specific to a subproject, e.g. solid, specify it<br>
in the branch name such as "solid/udevbackend". This will make it easier to<br>
use git branch listings (along with grep, etc) to pick out branches of<br>
interest based on the project in question. If there is not a sepcific<br>
subproject that it belongs to, give it a good descriptive name such as<br>
"pluggable-kconfig".<br>
<br>
No branches should be prefixed with "KDE"; we consider that a reserved name.<br>
Nor topic should branches be numeric in nature (such as a version number) as<br>
those are reserved for actual release branches. (Sys admin at the meeting<br>
indicated that it is likely they will eventually put a push hook in place that<br>
prevents such "incorrectly" named branches.)<br></blockquote><div><br>Was this decided upon at some point? I got conflicting stories from sysadmin and other developers. Yesterday after migrating kdeaccessibility to git I was asked by a sysadmin to rename the X.Y branches to KDE/X.Y I think concensus and consistency are important here. Was there a decision that the official branches should be named X.Y? Is that documented somewhere (I spent some time looking, but didn't find it). If not we should reach concensus and also fix the repositories that are not following this standard sooner than later imo. This will help greatly in the long run.<br>
<br>Thoughts, opinions, etc.<br>Jeremy<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Branch names should not include the committer name as we have git log and it<br>
will help discourage "ego coding" where one person has overt "ownership" of<br>
the branch. This is still a team effort after all :)<br>
<br>
"Dead" branches: on every maor every release, a check will be done on branches<br>
in the main repository. Any branches that have not seen any work done on them<br>
in the last <TBD: 12? 18?> months will be deleted. Deleted branches are<br>
backed up automatically on <a href="http://git.kde.org" target="_blank">git.kde.org</a>, so work will be retrievable. This will<br>
keep our branch count sane over the years.<br>
<br>
Open questions / topics for further discovery:<br>
<br>
* documenting best practices for keeping a topic branch in sync with<br>
master, keeping in mind that later a merge from the topic branch to master<br>
needs to be done and the git history sould be kept as clean as possible<br>
<br>
* process for announcing that a branch is ready to be merged so as to<br>
gather feedback (particularly important for the shared "crown jewels" in<br>
kdelibs); this is something like a "kdereview 2.0" though on the level of<br>
feature branches.<br>
<br>
* topic branches and our release cycle: is it acceptable to create a new<br>
topic branch even when we are in feature freeze?<br>
<br>
* more advanced workflows involving, e.g., an integration branch is not<br>
something we seem equipped for right now as it brings overhead and additional<br>
coordination with it. Perhaps in the future though ....<br>
<br>
* best practice "recipes" for merging, e.g. using "git merge --log"<br>
<br>
Bugfixes<br>
=======<br>
The big question here was forward-porting vs. backporting. Backporting has the<br>
advantage that it is what we do currently and people run and test master more.<br>
Forward-porting ensures that all bug fixes in the stable release branch end up<br>
in the master branch and it is easier to test against a branch with fewer<br>
changes (e.g. new features). It will take discipline either way: two bug fixes<br>
we found in 4.6 that weren't in master.<br>
<br>
Merge is prefered over cherry-pick: it cleans up the git history a bit; each<br>
commit is only there once instead of the cloned commits created by cherry-<br>
pick.<br>
<br>
The two methods (forward vs backward ports) are not mutually exclusive: on the<br>
contrary, backporting commits that made it into master can make it easier for<br>
the next person who wants to merge the stable branch into master.<br>
<br>
Generally, we will encourage people to develop and test bug fixes against the<br>
stable branch and forward port them by way of a merge into master. Due to the<br>
obvious cases for exceptions, this will not be a "hard and fast" rule.<br>
<br>
Documenting best practices considerations<br>
==================================<br>
<br>
There is a lot we need to document. The above needs to be refined, fleshed out<br>
and turned into point-by-point documentation. There are many pages on Techbase<br>
that need updating as a result of moving from svn to git as well. I'll<br>
organize and hopefully also host a docu day on irc for this specifically once<br>
the dust settles a bit more.<br>
<br>
<br>
We'll need to have further discussion on these topics and your feedback is<br>
welcome. Questions as well as answers are valuable, as both will help define<br>
what needs to be further defined and documented.<br>
<font color="#888888"><br>
--<br>
Aaron J. Seigo<br>
humru othro a kohnu se<br>
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43<br>
<br>
KDE core developer sponsored by Qt Development Frameworks<br>
</font></blockquote></div><br>