KDE/4.11 branched what to do with kde-workspace?

[Aaron J. Seigo]

On Friday, July 12, 2013 10:19:45 Andras Mantia wrote:
> On Thursday, July 11, 2013 07:41:37 AM Martin Gräßlin wrote:
> >  I agree that this is
> > 
> > something we learned from kdelibs that we need to keep the releases going
> > even  if they do not contain new features.
> 
> With kdelibs didn't we switch back to branch and tag it from master even
> though master is "closed" (which was not true due to some bugfixes)? It was

let’s strive for accuracy:

* master was never closed to bugfixes
* there were 2 main reasons the branched-kdelibs shifted back to master-
kdelibis:
	* people were too stubborn and too (willfully) uninformed to understand 
why this was a useful thing and just kept pelting it with stop energy at every 
possible opportunity.
	* it took so long to get frameworks 5 on track, that eventually the 
pressure simply won out

those two point played into each other.

this was a non-technical failure, so don’t look for technical justification 
from the kdelibs branch experience.

if your point is that people will again be stubborn and ignorant and sabotage 
the effort, then we can discuss how to avoid that.

> *older*. Ask David Faure how many times he got complaints to merge the
> branch to master...

had this actually been done according to the original plan, kdelibs would have 
remained at version 4.x (where x = 7?) and we would now be up to 4.7.<some 
relatively big number> and we’d never have merged into master. ever.

this was a mistake. we can learn from that. we don’t need to repeat mistakes 
made when we try again.

> For this reason I suggest to keep master as now and branch from there every
> time and for a bigger refactoring use a branch (yes, this is the opposite I

there’s a  problem with that. 

in 6-12 months time, we’ll need to merge all of that back into master. or, i 
suppose, abandon master forever. if  bug fixes continue on in master, it will 
be nightmare to do the merge as the PW2 code will have drifted signficantly in 
two ways: the code base is going to be reorganized (in a similar fashion to 
what is happening for frameworks 5 right  now) and the changes in some 
components will be significant making changes in the stable branch (be it 
master or not) completely innaplicable to the newer work.

thankfully, there’s an easier way to do this:

* do all stable releases from a stable branch
* make all bug fix changes in the stable branch
* do all individual refactorings in branches
* merge those branches down to master as they are ready
* release from master in a  year’s time and call it Plasma Workspaces 2 (or 
whatever)

the challenge with this is means people who aren’t actually doing the work 
need to be supportive in some pretty small ways, namely: be ok with drawing 
releases from the 4.11 branch.

that really can’t be too much to ask?

-- 
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/20130712/f57add5e/attachment.sig>