git workflow draft

[Alexander Neundorf]

On Monday 22 August 2011, Jeremy Whiting wrote:
> On Tue, Feb 15, 2011 at 10:51 AM, Aaron J. Seigo <aseigo at kde.org> 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