[Kde-extra-gear] Evaluation of the extragear tarball releases.

[Charles Connell]

On Saturday 12 January 2008 09:58:09 pm Eike Hein wrote:
> Aaron J. Seigo wrote:
> > the tag should be done on a branch; and translations are done on
> > branches, right? hopefully that's true even in extragear.
>
> (This is long, but please do read it until the end. It
> contains a counter-proposal to the rollups.)
>
>
> It's not, actually. My impression is that the majority of
> Extragear applications, certainly the ones I've been wor-
> king on (Konversation, Yakuake) and the ones that see re-
> gular releases (say, Amarok) package translations from
> trunk. What we do is notify kde-i18n-doc that we're going
> into string freeze, at which point the translators finish
> the translations in trunk, and then all languages that
> make the cut get put into the tarball on release day.
>
> Some applications may use the 'stable' branch for trans-
> lations, but that extra complication of maintaining multi-
> ple branches is simply not required for all applications,
> and has the major downside that most translators are very
> confused as soon as there's more than one copy of the
> language files around as communication breaks down almost
> immediately.
>
> To be honest, I've never seen the value of this exercise
> to try and do rollups alongside KDE releases:
>
> 1) Our apps (meaning those I work on and the people I
>     work on them with) are in Extragear precisely because
>     we don't want to follow the KDE release schedule.
Not necessarily. Everybody, please don't base a decision just on my pet 
project's needs, but I will outline them anyways, in case others have the 
same issues. I consider myself the maintainer of the Kopete Cryptography 
plugin currently residing in extragear. It used to be in kdenetwork along 
with the rest of Kopete, but feature development forced me to depend on 
libkleo, which is provided by kdepim. Rather than have Kopete require kdepim 
just for one little thing, we moved Cryptography to Extragear. It is still a 
part of Kopete, (unfortunately without a kdepim release, it's not released 
right not), but it's just not in the trunk. I want the Cryptography plugin to 
be released every time a new version of Kopete is released (aka every time 
KDE does a releaese), since users consider the plugin to be an important 
feature of Kopete. There should be no Linux distribution that goes by that 
has Kopete without the Cryptography plugin, if at all possible. It is not an 
unnecessary addition, it is an important part that is just in a different 
module so that it can require whatever dependency it wants to.

Is this the wrong use of Extragear? I don't think so. I was always under the 
understand that simultaneous releases were to be expected from many extragear 
apps.

>
> 2) Being incorporated into rollup tarballs inbetween our
>     own releases strikes me as a pointless exercise because
>     distributions are going to go for the latest version
>     in any case, and I perceive the audience of people who
>     are hunting for tarballs on their own and then prefer
>     a rollup rather than an app-specific one as very limi-
>     ted.
>
> 3) Those Extragear developers who for some reason do not
>     want to do their own releases but prefer for the re-
>     lease-team to publish them through the rollup tarballs
>     are not off the hook simply because of that: Regular
>     maintainer release duties like updating release mate-
>     rials, Extragear websites and version numbers for the
>     app still apply.
>
> 4) Rolling your own tarball of your Extragear app used
>     to be trivial in the KDE 3 days thanks to the svn2dist
>     script, and Toma has recently published a similar hel-
>     per for KDE 4 Extragear. That means that the steps out-
>     lined in '3' are pretty much the only real work one
>     has to do for a basic release - the rest is automated
>     - and doesn't change with or without rollups.
>
>     (Admittedly, doing e.g. a Konversation release takes
>     me roughly an evening because I do build and basic
>     usage tests with a variety of compiler versions on a
>     variety of CPU architectures and with a span of KDE
>     versions - but I doubt that the rollups saw that kind
>     of scrutiny (correct me if I'm wrong). And the things
>     I do that aren't covered by the svn2dist script, such
>     as running a battery of validation tests on the trans-
>     lation files and generating the list of languages to
>     be included based on a coverage threshold I've made
>     scripts for, too, and nothing prevents us from giving
>     Extragear maintainers such tools.)
>
>
> Now, the one advantage I see to the rollups is actually
> not a property of their nature as rollups at all: It
> gives Extragear applications a download location inside
> the KDE infrastructure, which is not the case right now.
> If you do roll your own releases, you have to set up and
> maintain a site elsewhere so distributions and users have
> a source for your app, and suspect that's the *real*
> reason why some people want the release-team to do the
> releases for them.
>
>
> I'd like to see the rollup mess be dropped instead for
> the correct fix to be implemented:
>
> a) Continue to make rolling your own tarball of your Ex-
>     tragear application trivial by offering maintainers
>     the necessary tools in the form of handy scripts.
>
> b) Allow Extragear teams to publish and host these re-
>     lease tarballs on ftp.kde.org, turning their page on
>     http://extragear.kde.org into the authoritative
>     source for the application if they so desire. Users
>     and distributions alike can scan the Extragear page
>     for new versions to be released, and fetch the
>     sources from the site - no other homepages required.
>
> If we can get it to the point where an Extragear main-
> tainer who doesn't want to spend significant effort on
> his own infrastructure only needs to run a few simple
> scripts to roll a tarball and publish the release on
> the Extragear pages, we (a) avoid the rollup mess and
> (b) remove the reasons why maintainers want the release
> team to do the work for them.
I'll gladly make my own tarballs, but I need to have my code in 
ftp://ftp.kde.org/pub/kde/stable/4.0.0/src/, so that it doesn't fall by the 
wayside of the big releases.

>
>
> Regards,
> Eike Hein, hein at kde.org
>

So my opinion is:
Allow for extragear developers to release tarballs with main KDE releases and 
with main KDE version numbers, and also allow for independent releases. 
Basically, the way it works now is perfect, the only real flaw is the method 
of communication of what to release and how. As I suggested, we should have a 
script-readable text file so that all of the developer's wishes can be 
automatically respected, and any disputes go back to that file.

- Charles Connell (who is a relatively new developer, so he should probably 
not be taken overly seriously.)