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