Re: Evaluation of the extragear tarball releases.

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

_______________________________________________
Kde-extra-gear mailing list
Kde-extra-gearkde.org

https://mail.kde.org/mailman/listinfo/kde-extra-gear

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

_______________________________________________
Kde-extra-gear mailing list
Kde-extra-gearkde.org

https://mail.kde.org/mailman/listinfo/kde-extra-gear

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

(This is long, but please do read it until the end. It
contains a counter-proposal to the rollups.)


It's not, actually. My impression is that the majority of
Extragear applications, certainly the ones I've been wor-
king on (Konversation, Yakuake) and the ones that see re-
gular releases (say, Amarok) package translations from
trunk. What we do is notify kde-i18n-doc that we're going
into string freeze, at which point the translators finish
the translations in trunk, and then all languages that
make the cut get put into the tarball on release day.

Some applications may use the 'stable' branch for trans-
lations, but that extra complication of maintaining multi-
ple branches is simply not required for all applications,
and has the major downside that most translators are very
confused as soon as there's more than one copy of the
language files around as communication breaks down almost
immediately.

To be honest, I've never seen the value of this exercise
to try and do rollups alongside KDE releases:

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.

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.

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.

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.

    (Admittedly, doing e.g. a Konversation release takes
    me roughly an evening because I do build and basic
    usage tests with a variety of compiler versions on a
    variety of CPU architectures and with a span of KDE
    versions - but I doubt that the rollups saw that kind
    of scrutiny (correct me if I'm wrong). And the things
    I do that aren't covered by the svn2dist script, such
    as running a battery of validation tests on the trans-
    lation files and generating the list of languages to
    be included based on a coverage threshold I've made
    scripts for, too, and nothing prevents us from giving
    Extragear maintainers such tools.)


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.
If you do roll your own releases, you have to set up and
maintain a site elsewhere so distributions and users have
a source for your app, and suspect that's the *real*
reason why some people want the release-team to do the
releases for them.


I'd like to see the rollup mess be dropped instead for
the correct fix to be implemented:

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.

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.

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.


Regards,
Eike Hein, heinkde.org


_______________________________________________
Kde-extra-gear mailing list
Kde-extra-gearkde.org

https://mail.kde.org/mailman/listinfo/kde-extra-gear

On Saturday 12 January 2008 09:58:09 pm Eike Hein wrote:
> Aaron J. Seigo wrote:
> > the tag should be done on a branch; and
translations are done on
> > branches, right? hopefully that's true even in
extragear.
>
> (This is long, but please do read it until the end. It
> contains a counter-proposal to the rollups.)
>
>
> It's not, actually. My impression is that the majority
of
> Extragear applications, certainly the ones I've been
wor-
> king on (Konversation, Yakuake) and the ones that see
re-
> gular releases (say, Amarok) package translations from
> trunk. What we do is notify kde-i18n-doc that we're
going
> into string freeze, at which point the translators
finish
> the translations in trunk, and then all languages that
> make the cut get put into the tarball on release day.
>
> Some applications may use the 'stable' branch for
trans-
> lations, but that extra complication of maintaining
multi-
> ple branches is simply not required for all
applications,
> and has the major downside that most translators are
very
> confused as soon as there's more than one copy of the
> language files around as communication breaks down
almost
> immediately.
>
> To be honest, I've never seen the value of this
exercise
> to try and do rollups alongside KDE releases:
>
> 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.
Not necessarily. Everybody, please don't base a decision
just on my pet 
project's needs, but I will outline them anyways, in case
others have the 
same issues. I consider myself the maintainer of the Kopete
Cryptography 
plugin currently residing in extragear. It used to be in
kdenetwork along 
with the rest of Kopete, but feature development forced me
to depend on 
libkleo, which is provided by kdepim. Rather than have
Kopete require kdepim 
just for one little thing, we moved Cryptography to
Extragear. It is still a 
part of Kopete, (unfortunately without a kdepim release,
it's not released 
right not), but it's just not in the trunk. I want the
Cryptography plugin to 
be released every time a new version of Kopete is released
(aka every time 
KDE does a releaese), since users consider the plugin to be
an important 
feature of Kopete. There should be no Linux distribution
that goes by that 
has Kopete without the Cryptography plugin, if at all
possible. It is not an 
unnecessary addition, it is an important part that is just
in a different 
module so that it can require whatever dependency it wants
to.

Is this the wrong use of Extragear? I don't think so. I was
always under the 
understand that simultaneous releases were to be expected
from many extragear 
apps.

>
> 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.
>
> 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.
>
> 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.
>
>     (Admittedly, doing e.g. a Konversation release
takes
>     me roughly an evening because I do build and basic
>     usage tests with a variety of compiler versions on
a
>     variety of CPU architectures and with a span of
KDE
>     versions - but I doubt that the rollups saw that
kind
>     of scrutiny (correct me if I'm wrong). And the
things
>     I do that aren't covered by the svn2dist script,
such
>     as running a battery of validation tests on the
trans-
>     lation files and generating the list of languages
to
>     be included based on a coverage threshold I've
made
>     scripts for, too, and nothing prevents us from
giving
>     Extragear maintainers such tools.)
>
>
> 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.
> If you do roll your own releases, you have to set up
and
> maintain a site elsewhere so distributions and users
have
> a source for your app, and suspect that's the *real*
> reason why some people want the release-team to do the
> releases for them.
>
>
> I'd like to see the rollup mess be dropped instead for
> the correct fix to be implemented:
>
> 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.
>
> 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.
>
> 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.
I'll gladly make my own tarballs, but I need to have my code
in 
ftp://ftp.kde.org/pub/kde/stable/4.0.0/src/, so that it
doesn't fall by the 
wayside of the big releases.

>
>
> Regards,
> Eike Hein, heinkde.org
>

So my opinion is:
Allow for extragear developers to release tarballs with main
KDE releases and 
with main KDE version numbers, and also allow for
independent releases. 
Basically, the way it works now is perfect, the only real
flaw is the method 
of communication of what to release and how. As I suggested,
we should have a 
script-readable text file so that all of the developer's
wishes can be 
automatically respected, and any disputes go back to that
file.

- Charles Connell (who is a relatively new developer, so he
should probably 
not be taken overly seriously.)



_______________________________________________
Kde-extra-gear mailing list
Kde-extra-gearkde.org

https://mail.kde.org/mailman/listinfo/kde-extra-gear

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

_______________________________________________
Kde-extra-gear mailing list
Kde-extra-gearkde.org

https://mail.kde.org/mailman/listinfo/kde-extra-gear