[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Proposal for branching policy towards KF5
From:       Thomas_Lübking <thomas.luebking () gmail ! com>
Date:       2013-07-21 9:13:43
Message-ID: 43b81b6e-09e9-4a3c-945b-628e42b85083 () gmail ! com
[Download RAW message or body]

On Sonntag, 21. Juli 2013 05:04:10 CEST, Michael Pyne wrote:
> On Fri, July 19, 2013 00:21:21 David Faure wrote:
> > After more live discussion with Sebas and Marco plus Aaron over a video
> > chat, we came up with the following setup for the workspace repos (*) :
> > 
> > Adding a similar generic selection for qt5/kf5, we would end up giving 3
> > options to people who compile from sources: stable, 
> > latest-qt4, or qt5/kf5-
> > based. ...
> 
> > <implementation>
> > Michael: I see two ways this could be done in kdesrc-build. 
> > Either with the
> > selection layers being defined by the projects XML and some 
> > additional magic
> > in branch selection to allow for these new names, or with a much more
> > low-tech solution: 3 available files to include from 
> > kdesrc-buildrc, like ...
> 
> Well there's a 3rd method as well, which is to add a separate 
> metadata file to 
> the kde-build-metadata repository which maps each git repository to its 
> appropriate branch for each of the 3 categories.


git symbolic-ref refs/heads/NEXT refs/heads/master
or for workspace/libs
git symbolic-ref refs/heads/NEXT refs/heads/KDE/4.11

eventually also
git symbolic-ref refs/heads/CURRENT refs/heads/KDE/4.11

and then at some point
git symbolic-ref --delete refs/heads/CURRENT
git symbolic-ref refs/heads/CURRENT refs/heads/KDE/4.12

But i don't know how this will exactly behave on remote/local conditions (ie. whether \
you get a local symref if the remote is one)

Cheers,
Thomas


[prev in list] [next in list] [prev in thread] [next in thread]