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

Tom Albers tomalbers at kde.nl
Sun Jan 13 00:52:36 CET 2008

Op Sunday 13 January 2008 00:06 schreef u:
> On Saturday 12 January 2008, Tom Albers wrote:
> > Unmaintained: kcoloredit, kfax, kiconedit, kpovmodeler, ligature
> > These applications seem unmaintained (please correct me if I'm wrong!), I
> kpovmodeler is *certainly* not unmaintained, and i don't know if all the 
> others really need that much additional work even if they aren't the best 
> apps in the world.
> how did you arrive at these conclusions?

I looked at the svn log briefly, as I said: correct me if i'm wrong. 

If an application has no changes for 7 months like some of the above have, I don't see why we should invest time in releasing them at every single patch release. We have made a release now, and we can make another one for the 4.1 for example for updated translations, but do we honestly need it every time?

> > Own release schedule: ktorrent
> > KTorrent has made his own beta release between te rc2 and final keg
> > tarballs we created. I think we should disable ktorrent from our release
> > process for now, untill they indicate they want to join again.
> i think we ought to be doing what we originally planned: teams can pop a tag 
> on their apps that indicates they'd like that revision to be packaged. it 
> pretty much resolves these kinds of issues completely.

No it does not. We can not do that as the translations are not in sync with that tag. You could argue to take the translation from that revision, but that does not hold as translators can transalate the app weeks or even months later and it *can* still be a valid translation to be shipped.

> > 3)
> > One of the bigger issues is the versioning. Because they are released with
> > the kde release the internal version number of the application should be
> > bumped as well. 
> only if they are shipping a new release. that's not guaranteed. the 
> tag-the-version approach helps resolve this issue nicely as well.

No, it does not. How should a packager name the release of the application? By the internal version or by the version of kde it is shipped with? And what happens when the application does their own release? The version as used by the distro has to be increasing for at least some distro's, so they (internal version/kde version) can not be mixed. 

I will reply to Helio with some more comments.


More information about the release-team mailing list