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

[Aaron J. Seigo]

On Saturday 12 January 2008, Tom Albers wrote:
> 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?

do we need to release apps in the main modules that haven't been touched since 
the last release? if the work is substantial then the real issue is 
automating the process so it's not.

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

the tag should be done on a branch; and translations are done on branches, 
right? hopefully that's true even in extragear.

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

they should name it the version of the application.

> By the internal version or by the version of kde it is shipped with? And

no. that makes no sense.

> what happens when the application does their own release? The version as

then the application number is bumped. the release tag would get moved at this 
point and the next extragear-with-kde release would include the new version 
as well. i don't see the issue?

> used by the distro has to be increasing for at least some distro's, so they
> (internal version/kde version) can not be mixed.

of course. tagging these applications with kde's version was never the plan, 
though.

-- 
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/e8824637/attachment-0001.pgp