From kde-release-team Mon Aug 22 19:32:33 2011 From: Alexander Neundorf Date: Mon, 22 Aug 2011 19:32:33 +0000 To: kde-release-team Subject: Re: git workflow draft Message-Id: <201108222132.34140.neundorf () kde ! org> X-MARC-Message: https://marc.info/?l=kde-release-team&m=131404170631191 On Monday 22 August 2011, Jeremy Whiting wrote: > On Tue, Feb 15, 2011 at 10:51 AM, Aaron J. Seigo wrote: > > hi all.... > > > > so after the meeting on Sunday, here is where we are in terms of a draft > > > > workflow. more complete meeting minutes can be seen here: > > http://titanpad.com/SnJwFW2iXL > > > > the goal of the meeting was to come up with a draft of a mutually > > agreeable git workflow for kdelibs and kde-runtime. the hope is that > > this can become a > > template for the rest of the SC modules (kde-workspace will follow the > > kdelibs > > workflow, for instance), as well as as many other KDE projects as > > possible. this is to help ensure a general continuity to how we work > > across KDE. > > > > Topic Branches > > ============= > > > > All new development should happen in a branch. Git makes branches very > > cheap > > and they can be local or remote. There are few if any really good reasons > > not > > to use branches, so development directly in master should be generally > > discouraged. > > > > Topic / feature branches should be public and pushed to the main > > repository where they are easy for others to find and collaborate on. > > They should start > > as a branch off of master. We do not want git to become, even > > unintentionally, > > a road to segregated, private development at the expense of our > > collaboration > > as a community. With public branches in a shared repository, even a git > > pull > > will inform of new development that is happening. Git then becomes an > > important piece of our development communication with each other: a new > > branch > > means new activity. > > > > Only features / topics that are intended from the state to be merged with > > master should end up in the main repository, however. More experimental > > and/or > > long term efforts (an example presented was the kconfig refactor leading > > up to > > 4.0) should start in a personal clone, and when/if the work crosses the > > border > > into "this is realistically going to be merged with master" it can be > > moved into a branch in the main repository. > > > > After merge with master, topic branches should be deleted from the main > > repository. > > > > Branch Naming: if a branch is specific to a subproject, e.g. solid, > > specify it > > in the branch name such as "solid/udevbackend". This will make it easier > > to use git branch listings (along with grep, etc) to pick out branches > > of interest based on the project in question. If there is not a sepcific > > subproject that it belongs to, give it a good descriptive name such as > > "pluggable-kconfig". > > > > No branches should be prefixed with "KDE"; we consider that a reserved > > name. > > Nor topic should branches be numeric in nature (such as a version number) > > as > > those are reserved for actual release branches. (Sys admin at the meeting > > indicated that it is likely they will eventually put a push hook in place > > that > > prevents such "incorrectly" named branches.) > > 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? My vote goes to "KDE/X.Y", it is clearer what it means. > Is that documented somewhere (I spent some time looking, but didn't find > it). If not we should reach concensus Fully agree. > and also fix the repositories that are not > following this standard sooner than later imo. Fully agree. Alex _______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team