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

[Eike Hein]

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.

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.


Regards,
Eike Hein, hein at kde.org