Request: remove libkactivites from kdelibs (in experimental/)
Thomas Friedrichsmeier
thomas.friedrichsmeier at ruhr-uni-bochum.de
Mon Nov 14 09:35:16 GMT 2011
Hi,
On Monday 14 November 2011, Aaron J. Seigo wrote:
> besides kde-core-devel, it was also blogged by a number of attendees, so
> planetkde.org readership was in the loop. there was a story on dot.kde.org,
> so dot.kde.org readership was in the loop. there's documentation on
> community.kde.org. hell, it even made it to slashdot (ok, that last one is
> NOT a good test ;)
>
> so we most certainly did communicate. you didn't catch it, and i agree
> that that sucks. but it is not because the communication didn't happen in
> all the most appropriate places. the only thing we could have done more
> for you is to track you down personally, and that's just not a realistic
> expectation.
to throw in my two cents: I don't think the problem is the _amount_ of
communication. But personally, I'm dearly missing a _central_ place with a
plain summary of the most important status information about kdelibs.
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.
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.
So, what I would love to see is _one_ short up-to-date page with just the most
relevant info along the lines of:
- You want to contribute a bug fix with no API changes, and no string changes:
Commit to branch X. Additionally, merging your commit into branch Y would
[not] be helpful but/and is [not] necessary.
- You want to contribute a bug fix with no API changes, but changes in i18n
strings: Please wait until MM.DD.YYYY
- You want to do X: Commit to branch Z
- For non-trivial patches, please get your code reviewed, first:
git.reviewboard.kde.org
- Here are some links to current background information on plans and
schedules: X, Y, Z, and here's a step-by-step guide on pushing patches to
kdelibs with git.
Ideally, this page would be linked from
http://quickgit.kde.org/?p=kdelibs.git&a=summary , if that is possible.
Ideally, also, git would point we to it, when my push fails for some reason.
Regards
Thomas
-------------- 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/0ca103f3/attachment.sig>
More information about the kde-core-devel
mailing list