[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-release-team
Subject:    Re: [Kde-extra-gear] Evaluation of the extragear tarball releases.
From:       Tom Albers <tomalbers () kde ! nl>
Date:       2008-01-12 23:52:36
Message-ID: 2407360.oTnAOhnENj () kde ! nl
[Download RAW message or body]

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.

Toma



_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


[prev in list] [next in list] [prev in thread] [next in thread]