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

[Eike Hein]

Tom Albers wrote:
> I thought there was a mechanism in place to do that. I will 
 > try to find out how that works/still exists and post it here.

Thanks.


> What is keeping you from that? Afaik you can request access 
> to the extragear pages if you are working there and make a 
> section for your website. Not sure what's wrong with that.

The misunderstanding comes from ripping the paragraph in two,
which was about the Extragear WWW infrastructure being inade-
quate in itself due to the lack of download hosting. The Ex-
tragear apps that do their own releases currently tend to
use an account at SourceForge or Berlios to host their tar-
balls, or fund their own server, which raises Aaron's infa-
mous barrier to rolling your own releases.

(Or rather strikes me as the only burden of work that the roll-
up process removes from the individual maintainer's shoulders,
since contrary to Aaron's last mail the release team does not
update Extragear pages, changelogs, version numbers and other
release materials for the maintainers (nor should they, imho).)


I'm also thinking that it might be a good idea to morph the
Extragear main portal page from app catalogue to version up-
date feed format, or at least put a box in that vein at the
top, to make it easier for users and distributors to stay
current on Extragear app releases, further reducing the need
for rollups because people can't find the tarballs or don't
learn about new versions independent of them.



>> 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.
> 
> The rollup is not a mess in any way, we are just figuring out 
> hat the best approach is and tune this bit by bit.

I'm sorry, but it still strikes me as a mess. For apps that
ever do their own release at any time, *also* being in the
rollups is simply pointless because distributions and/or
users care about having the latest version (and yes, I know
that it's opt-in and this doesn't happen automatically, but
maintainers being too lazy to sign up at Berlios to host
their own releases will make it reality); for apps that do
their own releases the right fix is to make it easier to do
so rather than bunching them up in rollups; add-on content
that is tied to particular KDE release should probably go
into a top-level hierarchy other than Extragear that is ex-
pressely designed for module rollups rather than try to im-
plement two very different ways of doing releases within
the same hierarchy.

I know it's opt-in, and that I have no other reason for
caring other than I think it's the wrong solution to the
problem(s) overall.


Regarding the argument of riding on the wave of marketing
that goes along with a new KDE release: It's a good point
on one hand, but on the other I'm not fully convinced that
coordinated releases might not even be damaging in that
being lumped in with a new KDE release might weaken inde-
pendent, per-application brands powered by KDE technology.

Being on a release schedule independent of KDE's gives
apps a better shot at developing an independent identity
and getting independent coverage. Look at how well Pidgin
has done vs. Kopete in the mindshare competition: I doubt
that would have happened if Pidgin would be perceived as
part of Gnome releases. Or that Amarok would be as popu-
lar if it were to be lumped in with KDE releases. (Yes,
it's opt-in and Amarok hasn't opted in, but I'm worried
more about future apps.)


> Toma

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