Request: remove libkactivites from kdelibs (in experimental/)
Aaron J. Seigo
aseigo at kde.org
Mon Nov 14 10:34:30 GMT 2011
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
* 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
> 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
> 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
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...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel