Proposal for branching policy towards KF5

[Michael Pyne]

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.
> 
> I see this as kind of layer on top of the actual branch names (an
> indirection, in other words).
> 
> This gives us consistency for everyone:
> * for contributors to a specific module, "master" is where new features
> should go
> * for people who compile many modules that are supposed to be working
> together, a "logical selection layer" can be selected, stable, latest-qt4,
> or qt5-kf5.

> <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
> we did with kf5-qt5-build-include, except that these files would only
> contain module- options (yet another reason for that feature to exist), not
> actual module definitions. The user's kdesrc-buildrc would still define
> which module he/she wants to build, but the included file would define
> which branch should be used for each module (unless overriden, of course).
> </implementation>

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.

This is a labor-intensive task, but it's easy to centrally-manage without 
having to rely on many different module maintainers or core developers for 
each git repository to update their own metadata in projects.kde.org (assuming 
we can get the sysadmins to add that).

In addition this would probably be easier to support for build.kde.org and the 
other non-kdesrc-build tools that use the current information in kde-build-
metadata.

We could probably significantly reduce the labor involved in maintenance by 
setting up defaults and then only specifying exceptions from the rule. The 
question will be how to group modules together.

This is definitely something that would need discussion with the sysadmins and 
Release Team to hash out the details and any process changes that might need 
to happen too (e.g. adding a tool to verify all modules in kde/* are actually 
described for each of the 3 categories and running before a release to make 
sure new modules are not inadvertently left out of the metadata).

I think we're getting to the point where it would be a good idea to document 
the metadata on our TechBase as well instead of just a README embedded within 
the directory.

By a strange coincidence I happen to be on vacation leave so I will try to be 
online to discuss on IRC, but failing that we can setup a separate thread on 
the relevant mailing lists to hash out details.

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130720/dff9dbb9/attachment.sig>