Request: remove libkactivites from kdelibs (in experimental/)

[Aaron J. Seigo]

On Monday, November 14, 2011 10:35:16 Thomas Friedrichsmeier wrote:
> My main focus of development is on a KDE-based application, not kdelibs. But
> every once in a while, I find a bug in kdelibs, and I want to contribute a
> fix. And every once in a blue moon, I want to contribute a small feature.
> For such sporadic contributions, the ratio of time spent on producing a
> patch versus time spent on figuring out how to get the patch into kdelibs
> is not a good one. Back in the good old days, this basically meant reading
> up on any freezes in effect. With the move to git, and now with frameworks
> efforts, the complexity has increased, considerably.

the complexity will eventually subside. right now it's something like:

* until further notice, if it is a bug fix, put it into KDE/4.7 and it will 
get merged forward into frameworks

* if it is a feature, do it in a branch off of frameworks and when it is 
ready, it can be merged in

it is complex because we currently have to juggle between 4.x freezes, 
frameworks progress and the evolving state of that effort in a branch. it's a 
transition period that we all want to be as _short_ as possible so we can get 
back to simple.

in future it will be:

* bug fixes can always be applied to the stable branch; these will get merged 
into master.

* features can be opened at any time in a feature branch and merge into the 
testing branch when they are ready for testing by your fellow developers. when 
it is ready for merging, it'll get merged into master.

notice the lack of discussion there about freezes. all you'll need to know as 
a casual contributor is where feature branches come off of and what the latest 
stable branch is, and whether your addition is a bug fix or a feature.

for casual contributors, this should be very low-barrier-to-entry. you 
shouldn't even need to consult the release schedule for things like feature 
freezes :)

> All relevant information is available somewhere, but having to search
> through half a dozen places (techbase.kde.org, community.kde.org,
> kde-core-devel, kde- cvs-announce, blogs, dot, ...) is downright painful.
> Esp., if some of those places are littered with outdated and misleading
> bits.

completely agreed.
 
> So, what I would love to see is _one_ short up-to-date page with just the
> most relevant info along the lines of:

that is one of the primary reasons we're getting together on irc later this 
month. it is quite clear to everyone that this is sorely needed, and so we're 
going to make this thing along with some other supporting information for 
frameworks ...

--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- 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/20111114/317b5740/attachment.sig>