shirish शिरीष posted on Wed, 07 Mar 2012 20:40:10 +0530
as excerpted:
> 2012/3/7 Duncan <1i5t5.duncan@xxxxxxx>:
>> Please CC further followups to
>> shirish शिरीष <shirishag75@xxxxxxxxx>
>> shirish शिरीष posted on Wed, 07 Mar 2012 17:11:10 +0530
>> as excerpted:
>>> Ok, now the thing is Debian sid has just started on the road to KDE SC
>>> 4.7 . While I'm not a KDE User I do use quite a few of the KDE tools
>>> and more specifically games esp. Kshinshen and palapeli.
>>>
>>> In most GNU/Linux distributions that I have played with there is a
>>> concept called changelogs where one can read what changes, new
>>> features,bug-fixes etc. were done to a program once a new version is
>>> out.
>> As to your changelog question... just what level of detail are you
>> after? There's several change-following options [but] none of them
>> correspond exactly to the traditional changelog.
>>
>> At the low detail end, [kde-sc release announcements]
>> At the high detail end, there's the version-control-system (most of kde
>> is now on git, but some modules remain on svn/subversion, AFAIK) commit
>> logs.
>> In between these, there's the more or less weekly kde commit-digests
>> There's also PlanetKDE [and] the individual developer blogs.
>> Finally, most individual kde projects have their own home pages, but
>> these tend toward general project information more than changelogs or
>> the like.
>>
>> Of all these, I'd suggest the individual developer blogs
>> Links in no particular order:
>>
>> http://dot2.kde.org/
>>
>> http://www.planetkde.org/
>>
>> http://www.kde.org/
>>
>> http://www.kde.org/community/
>>
>> http://techbase.kde.org/Contribute#News_and_Mail_Sources
>>
>> http://techbase.kde.org/Getting_Started/Sources
>
> Ok, first I am just a user, not a packager but a user who wants to use
> whatever utilities come as part of the upgrade cycle to use it the best
> way I can. Because there is no documentation to know what the changes
> happened between KDE SC 4.6 and KDE SC 4.7,at least for the couple of
> utilities/games I have mentioned above I have no idea .
You're right. It has been a bit of a problem for me, too, not just for
kde BTW, but for some other packages as well. FWIW, that's one of the
reasons I switched to the live-git version for some things -- I was
following them closely enough and finding bugs often enough that it was
just simpler to go directly to git, read the commit logs straight from
there, and be able to bisect down to the individual commit level when
necessary to trace a bug.
But of course being end-user build-from-sources is one of gentoo's main
defining characteristics and it's a much smaller step from already
building from versioned source tarballs to building directly from git,
than it is from the typical bin-distro prepackaged binaries (with build-
time-bits like headers split off into separate -dev packages). I love
the extra control over dependencies, etc, that building from source
provides even when building from straight-up versioned tarballs, and
DEFINITELY take advantage of the fact that I'm already building from
source to insert my own patches into a package here and there as well.
But I recognize the fact that it's not for everyone.
> On palapeli I have been following Stefan majewsky's blog as he writes
> about palapeli http://majewsky.wordpress.com/ although the developer in
> question does not write much :(
Yes. That's actually how I discovered palapeli and exactly the sort of
thing I had in mind when I recommended following individual developer
blogs. I was following planetkde at the time, and came across a number
of his blog entries about palapeli. It was at a rather earlier stage of
development at the time, and I was able to follow it thru his blog as
carried by planetkde as it matured.
Similarly with asegio's blog and plasma, plus some of the other kde stuff
like phonon and its backends.
But over time I decided I was spending too much time reading feeds, and
while I was definitely finding some of the stuff from planetkde useful,
there was way more that I wasn't interested in, so I eventually dropped
it. But it remains an excellent way to discover individual kde blogs,
which generally have their own feeds.
> I am at wits end to find the developers name of the people behind
> kshisen for games.kde.org does not list either kshisen or palapeli in
> its offerings (Guess the website is outdated or something) .
Outdated or non-existent formal documentation (and a website is really
part of that documentation) is a general problem in FLOSS. It's much
more fun to hack on the code than to document the package, and since much
of FLOSS is volunteer and much of the paid development is self-directed,
documentation, websites, etc, often lag behind. For independent
projects, the web site is often the main interface to the world, so it
generally isn't allowed to get /too/ far behind and often carries
changelogs and the like, but subprojects under a bigger project such as
kde tend to lack the same motivation to keep their sub-project pages
current, or to do reasonably full changelogs at all... thus this thread.
> Later I did find some of the people's names who had contributed to
> kshisen but not where I expected. It is in
> /usr/share/doc/kshisen/copyright but it also has copyrights of all the
> other games mashed into it, this perhaps I will follow will the Debian
> Developer involved because this is curious as well.
>
> Btw who's working on it or is kshisen orphaned for the copyright only
> lists things till 2k7 and nothing after that
My guess is that it was considered reasonably mature at that point, and
that's likely when it was added to kdegames.
Unfortunately, getting drawn into the main kde software collection tends
to anonymize a project, sometimes effectively killing much further
development even as it exposes the project to a much larger userbase.
That's one reason why a number of kde-based independent projects have
chosen to stay independent. Think of amarok, k3b, kaffeine, etc. The
most notable exception to this would be plasma, but that's different,
both because it's critical kde infrastructure as the desktop "face" of
kde, and because its lead developer, asegio, is a naturally dominant
leader that is one of the major public and private driving force
personalities behind kde as it is today.
I believe observation of that is one of the driving forces between the kde
frameworks initiative, aka kde5, remodularizing and giving individual
subprojects back some of their independence, delinking the release
cycles, etc, to allow projects that want to "clock" faster release cycles
to do just that. With the kde4 infrastructure base maturing now, and
planned to be carried forward into kde5/frameworks without the disruption
of the early kde4 cycle, firming up the core platform API/ABI into a now
mature and slower changing base framework upon which the more independent
subprojects can more rapidly evolve as they're no longer held to the six-
month feature-release cycle of kde4, is seen to be a good thing.
Anyway, even if subproject development continues apace, unfortunately
formerly "good" changelogs and the like often disappear into the larger
SCM infrastructure. Hopefully the kde5/kde-frameworks thing will help to
correct that, too.
> As far as the community digests are concerned the only thing I have to
> say is wow for the web-page is pretty nice and interactive to boot, my
> congratulations to the devs. behind it, and while its good/great to look
> at it does not tell me what's really happening with the games I asked
> about above.
The commit digests should have the data you want, but admittedly, it's
going to be buried in data from a bunch of other subprojects you're
rather less interested in. I run a kde desktop here, and already have
that problem, as I won't touch kdepim after their akonadification, don't
have koffice/caligra installed, and don't need the full music database
management of amarok so don't have it installed either, so the signal to
noise ratio, for the signal I'm actually /interested/ in, is already
rather low. If you're only interested in a couple lower profile apps,
it'd be MUCH lower still, to the point that following the commit digests
really isn't going to be a productive use of your time, even if the info
you're looking for IS there, which it should be.
> What I did found even more curiouser is that kshisen is not part of the
> kdegames offering but listed separately, anybody has any idea behind
> that. Is kshisen part of the KDEgames offerings or not ?
It's part of the kdegames module, but as kde continues to break apart
their formerly huge monolithic modules into smaller individual pieces,
keeping only the common libs, etc, core, it's quite possible that game is
already split off from the others. If it's not already, there's a fair
chance it will be within a year or so, as the development focus shifts to
kde frameworks.
FWIW, since gentoo's source based, I have the tarballs here, just
checked, and can confirm that kshisen is part of the kdegames tarball, at
least thru 4.8.1 so likely thru 4.8.*. But as I said, kde's in a gradual
process of breaking up those big huge monolithic tarballs, with more and
more individually packaged tarballs being shipped in place of the big
monolithic ones, so I'd not be surprised at all to see that change in the
future.
> Lastly it seems KDE is going through a svn -> git migration . Does
> anybody know when that migration started ?
Yes, I mentioned that, but you might have missed it. Either that or this
question builds on my mention, I don't know which.
But to answer it...
The biggest and most disruptive svn -> git upgrades occurred in the 4.6
timeframe. That actually caused some regressions in what was supposed to
be a bugfix-only series with 4.6.1 and 4.6.2 at least, as a few of the
subprojects were pulled from the wrong repo for the release tarballs and
weren't in release shape, and others had stabilization patches committed
to the wrong one, etc, during the transition. But they waited until
after the big 4.6.0 to start and were either done with the hairy bits or
had better coordinated the management thereof by 4.6.4, so things settled
down quite a bit by then.
However, that's just the biggest and most disruptive changes. Earlier,
various individual subprojects had switched to git, first on gitorious or
github, then to kde's own git infrastructure as it became clear how happy
the early switchers were with git and kde setup its own git repos with an
intent to switch. Amarok was an early switcher, and I think some of the
new-for-kde4 projects actually started on git -- they never had an svn
repo to convert from, at least not a public one.
I'm not absolutely sure on current status, but from the bits and pieces
I've picked up, the general migration is finished, now. There's still
some bits on svn -- apparently svn works better for the l10n (l, 10
chars, n, aka localization, aka all the translations) folks and they have
no immediate plans to switch, and there's probably a few other niches
that haven't switched yet, but AFAIK the majority of kde is now on git,
with the main switchover as I said during 4.6, and a few stragglers
picked up in the 4.7 timeframe. What remains, AFAIK anyway, may not
actually switch from svn, at least in the kde4 timeframe. I could
speculate that the kde5/kde-frameworks upgrade might pick up most of the
remainder, but have no real facts to back that up, except that it /has/
been repeatedly noted by various kde projects that the switch to git
tends to dramatically increase both community involvement and the
/quality/ of community involvement, and to note the obvious
infrastructure benefits of standardizing on a single SCM, whatever it may
be. 4.6.1 thru 4.6.3 had
(FWIW, I've personally noted that effect with git as well. I follow WAY
more live-git packages than I EVER would live-svn, and am MUCH more
active in bisecting bugs down to individual commits, etc, thus increasing
both the quality and quantity of my bug reporting, as well as often
getting the reports in during development, so the bugs never see release
at all. That's for kde and other projects, including the kernel and
gentoo's native init system, openrc. For kde, in the lead-up to the kde
4.8, for the first time I ran the betas and rcs, but not the live-git
versions, mainly because I didn't want to bother with svn and I figured
with some of kde still on svn I'd have to due to the interlinked nature
of the modules, But I've been thinking about trying the switch to the
4.8 live branch, and then to the 4.9 live branch when the time comes, and
may well try it, at least to see how much of the kde I actually install
does require svn, these days. If I can get away with git only, I may
switch more or less permanently to the live branches, tho kde's big
enough and I'm dependent enough on it I'm still reluctant to try
trunk/master HEAD, just yet.)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
