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

[Aaron J. Seigo]

On Saturday 12 January 2008, Eike Hein wrote:
> 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.

that is, of course, not relevant to the discussion in any material way.

> 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.

i used to think the same thing until i started sitting down, face to face, 
with some of the people who manage kde packages for various operating systems 
and going through the various apps they choose and don't choose and why they 
do or don't ... turns out a lot of people, including packagers, have no clue 
about the existence of many of our fine apps in extragear.

additionally, many packagers really don't like hunting across the open 
landscape for this app or that app. turns out a lot of them would like to 
package up a bunch of stuff all at once for a release. a big topic on the 
release team list is timing our releases better with downstreams. 

> 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.

you're missing out on some of the new apps in extragear which were actually 
quite insistent on being in KDE release packages specifically to avoid doing 
that. and if someone says, "well, that's the cost of being a kde app" i have 
to say in reply, "what, writing code isn't enough?" especially if have the 
opportunity to automate much of this work.

it's about lowering bars, not justifying the ones that exist.

> 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.

... and upload them somewhere, and remember there's a time to do them, and ... 
this is fine for you, but you aren't the only one in this boat. there are 
others. saying "it works for me" doesn't mean it works for everyone. if you 
don't see the value and are just fine with your apps remaining in extragear 
and not having any interaction with the rest of the world beyond what you 
yourself manage and push ... then just don't opt in for this service.

it's that simple.

you may not get the roll-up service, but i don't get why people who don't want 
it feel obliged to argue that nobody should therefore want to. =)

btw, this is not just about applications, but also add on components. i don't 
want every bloody widget for plasma in kdebase. i do want them in extragear. 
but i don't want every contributor to have to package their own plugins 
either. that'd just be insane. so we're doing it as a separate add on 
package. the great thing is that unlike kdeaddons or kdetoys or kdeutils or 
any of those other grab bags, this is a well focused module (plasma stuff 
only) and isn't presented in a way that distros feel like they need to 
include it to have the basics.

>     scripts for, too, and nothing prevents us from giving
>     Extragear maintainers such tools.)

yes, i think we should... keep lowering that bar =)

> 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.

that's part of it. it also allows them to ride the coat-tails of kde release 
marketing, it gives us a nice place to put things that will end up being near 
kde releases without being in kdebase (this is really important for plasma 
add-ons, btw) and shaves a few millimeters off the height of the bar we raise 
for getting a kde component "out there".

> 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.

i think this should happen regardless =)

> 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.

ditto.

> 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.

.. and don't get any of the marketing benefits, miss out on the nicety of a 
(even simulated) coordinated release which is a hot button topic in 
downstream these days ...

-- 
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 Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20080112/548105d5/attachment.pgp