This starts to become a dangerous path (Was: New Feature for kdelibs)

[Andreas Pakulat]

On 17.11.11 00:14:23, Scott Kitterman wrote:
> On 11/16/2011 11:31 AM, Aaron J. Seigo wrote:
> > On Tuesday, November 15, 2011 16:28:21 Scott Kitterman wrote:
> >> On 11/15/2011 04:08 PM, Thomas L�bking wrote:
> >>> If one wants a feature in future KDE versions and such fork wouldn't
> >>> exist, one would not add it at all rather than to the frameworks?
> >>> Doesn't make any sense to me, sorry.
> >>
> >> That's true, but the question is when.  For developers focused on more
> >> near term things than Frameworks, it's unlikely they'll help with
> >> Frameworks in order to get their feature out faster.  Are there any
> >> examples of people who started working on the Frameworks port because
> >> kdelibs 4.8 doesn't exist?
> > 
> > yes, though granted few, which is to be largely expected because frameworks is 
> > new and in addtion despite coming to this list with a _consensus decision_ by 
> > the _current maintainers and bulk of developers_ we have not received the kind 
> > of cooperation and support that one might be led to expect from the KDE 
> > community.
> > 
> > in any case, because i've been strict about this with libplasma2, people have 
> > contributed to the frameworks branch (though sporadically as frameworks is 
> > still fledgling).
> > 
> > beyond new people, it is just as important that this allows those of us who 
> > are working on it to do so without spending time forward porting. every time 
> > the KDE/4.7 branch changes, it slows us down as we then have to merge-and-fix 
> > (both into frameworks as well as master, btw). realize, as noted already, that 
> > as frameworks progresses these merges will become harder and more labor 
> > intensive.
> > 
> > with the "let things flow into KDE/4.7" approach, controlled or not, we not 
> > only lower incentive to work on frameworks but we make the efforts that are 
> > going into frameworks less efficient. the math is very evident from that point 
> > forward for what that means for frameworks.
> > 
> > again, we've walked this path before. we know how this turns out. we can 
> > improve how we do things.
> 
> I don't see how any of that couldn't be addressed equally well with a
> policy that said new features in kdelibs 4.x only after they are in
> frameworks.  I don't think anyone would object to that and it would
> avoid any negative impact on the people doing the bulk of the work on
> KDE Frameworks (which I agree is an important goal).

Just chiming in here: Actually it does. Unlike in svn as far as I
understood for the frameworks effort git merge is being used to
forward-merge 4.7 into frameworks. What you describe above indicates
that changes are done to frameworks and then cherry-picked back into 4.7
or not even cherry-picked by manually copied because things changed
around. Either case creates problems when merging 4.7 into frameworks
the next time, so the frameworks devs have to go around and fix the
conflicts. Thats one of the things they're trying to avoid as much as
they can, currently by enforcing no bigger changes (which new features
usually are) happen in 4.7.

Andreas