Proposal for branching policy towards KF5

Aaron J. Seigo aseigo at kde.org
Fri Jul 19 11:56:39 BST 2013


On Friday, July 19, 2013 01:39:47 Michael Jansen wrote:
> I would like to mention that this is only a solution for scripts. It does
> not keep consistency for humans and all scripts outside of kde. And
> consistency is normally only needed for humans.

As Martin noted, it’s not possible to keep every single workflow 100% in place 
when we are experiencing changes in development.

For instance: the consistent place for merging features into 'next' is master 
(previously: trunk); and the consistent place for bugfixes is in the stable 
branch. The proposals that attempted to make things better for people building 
from master changed that around so that master is not for features and 
mainline moves to some other branch. That is a loss of consistency in our most 
important workflow: development.

Yes, something will end up changing. We are optimizing this change in kde-
workspace for development practices. We’ll keep careful track of well it works 
and then be able to apply that experience (positive or negative)  to other 
modules in the future. In our discussion the other day, we defined some metrics 
we will be watching to measure success by.

We are also paying attention to the needs of those who do build from master 
and will work on improving the tooling to minimize the disruption for people 
who build from git master. For those who don’t use that tooling, we’realso  
going to ensure that there are clear error messages when someone builds master 
against a 4.x environment telling them what’s going on and  which branch they 
should be  using.

Note that this “master means different things in different modules” issue is  
unnavoidable at some point: unless we wait for every single application 
(including in extragear) to port to Qt5/Frameworks5 before making master Qt5 
based modules that are already ported, there will be differences between the 
modules as to what is in master. The work we do in kde-workspace to make this 
as easy as we can for people who build from master can be applied to these 
future situations as well.

Those who build from tarballs or from the stable branches aren’t affected by 
this, so the challenges are thankfully limited.

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130719/d1ef1b35/attachment.sig>


More information about the kde-core-devel mailing list