Proposal for branching policy towards KF5

[Torgny Nyblom]

On Thursday 25 July 2013 18.24.50 Michael Pyne wrote:
> On Thu, July 25, 2013 22:44:47 Albert Astals Cid wrote:
> > El Dimecres, 24 de juliol de 2013, a les 23:05:55, Michael Pyne va 
escriure:
> > > On Fri, July 19, 2013 00:21:21 you 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 (*)
> > > > :
> > > > 
> > > > - the development branch for their next feature release (based on
> > > > Qt5/KF5)
> > > > will be "master".
> > > > - *before* this happens, however, kdesrc-build / kde-build-metadata /
> > > > projects.kde.org will need to be improved so that tools (kdesrc-build
> > > > and
> > > > possibly build.kde.org) can automatically select "the latest Qt4-based
> > > > branch" (i.e. master everywhere and 4.11 for the workspace repos), on
> > > > demand. This would also be the opportunity to implement "latest
> > > > *stable*
> > > > branch" which is 4.11 for most modules right now, but could be at some
> > > > point 4.12 for most and 4.11 for 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.
> > > 
> > > Back on topic, I have made an initial draft specification [1] for what
> > > this
> > > logical module group layer would look like.
> > > 
> > > In addition, there is a sample JSON file in the kde-build-metadata git
> > > repository, called "logical-module-structure" that one can view to get a
> > > feel for the proposed syntax/semantics.
> 
> snip
> 
> > > A point of concern is that currently we already have a concept similar
> > > to
> > > this, for i18n. It's possible to specify in the projects.kde.org
> > > management
> > > interface a "stable" or "trunk" branch for translation purposes. I don't
> > > know the translation infrastructure well enough to see how this proposal
> > > would impact that feature; I assume we'd want to move scripty (&
> > > friends)
> > > over to using this at some point if we go through with it, but it's
> > > probably easy enough to keep both techniques on whatever release
> > > checklist
> > > we're using now.
> > 
> > [I18N_HAT] I'd appreciate if you guys decide on something :D Not so long
> > ago we had to write support for the projects.kde.org branches thing when
> > we already had our nice set of scripts and now you say we'll have to
> > build support for something different? It's good that we never removed
> > our internal scripts and they are the authoritative source, that way
> > removing the projects.kde.org support is trivial :D [/I18N_HAT]
> 
> Well it would certainly be possible to *keep* support for whatever you're
> doing now with projects.kde.org, that isn't going away at this point. But
> since the concept is complementary, it would make sense to try to end up on
> one solution.
> 
> At least this way it should be easier to fixup the branches for groups of
> modules at a time! ;)
> 
> I'm not familiar with the i18n scripts at this point but I would volunteer
> to help with any needed porting.
> 
> > > > At this point I think this still needs a green light from the release
> > > > team,
> > > > though.
> > > 
> > > They are now CC'ed for review.
> > > 
> > > One clarification I should make is that I also received a recommendation
> > > to
> > > investigate migrating our current dependency data into this new JSON
> > > file
> > > if possible.
> > 
> > You mean something like kde-build-metadata? Neither i18n nor releasing
> > uses
> > that file.
> 
> Kind of (dependency data is one part of kde-build-metadata). It is true that
> neither requires dependency info.
> 
> In the event, some prototyping of the result of making *all* of our deps go
> in the file is rather unsatisfactory so I'll be dropping that for now (the
> hard work is already done in case we decide to investigate later though).
> > Basically from release I don't see how that affects us, we use the data
> > from the release-tools module that is de-coupled from what you mention,
> > no?
> dependency-data would not affect you at all.
> 
> The 'logical module groups' might play a role in the release process after a
> release is done, but shouldn't have any further role for tagging that I can
> see. i18n is covered above.

Wouldn't this be nice to have as the source of branch info for the releases? 
One place to have this information instead of duplicate it for each tool/user?

/Regards
Torgny

> 
> Regards,
>  - Michael Pyne