Evaluation of the extragear tarball releases.

[Helio Chissini de Castro]

On Saturday 12 January 2008, Tom Albers wrote:
> Hi,
>
> For the rc2 and for the final release we've been creating tarballs of
> extragear applications. I've taken the time to evaluate this based on
> feedback with different packers. I will try to keep it short and to the
> point.
>
> 1)
> The tarballs are now pretty much ok, the software to create them is
> committed in playground[1], so everyone can make them, when I'm
> unavailable. The only point is to include the translated documentation in
> the tarball. It's not done, because there are currently no examples to work
> with.

Ok, great job.


> 2)
> The applications currently packaged[2] needs work. I discovered the
> following problems:
>
> Ok: kgraphviewer, kphotoalbum(?), kmldonkey, kopete-cryptography, kaider,
> rsibreak These applications seem maintained and ok. Although when kaider
> moves to trunk for the 4.1 release, there won't be any updates up to the
> release of 4.1.
>
> Unmaintained: kcoloredit, kfax, kiconedit, kpovmodeler, ligature
> These applications seem unmaintained (please correct me if I'm wrong!), I
> would like to remove them from the keg-release project. I would even like
> to suggest to Helio to contact the maintainers and remove them from
> extragear. I can do that too if wanted.

I can do it, i already did when i moved extragear from places in svn.
kpovmodeler is one that i really think is maintained in some way.

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

We need talk again with Joris, but remember, keg maintainers are free to do 
releases in between. We can push the same releases again in the launch, no 
issue.

> 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. I would like to suggest to use the same numbering as the
> kde release they are part of. I've to discuss with some people how to do
> that, but I can add something like 'setVersion(4.0.1)' to a cmake file, and
> try to use that in the kaboutdata and when it's not set use the 'old'
> value.  Any ideas (or help with the execution) would be great.

No, definitively i'm against use this. The applications should remain their 
own release number. That was thr original target of keg ans should stay this 
way.
We should find a better way to match the version with our releases, and not 
the other way.

> I will proceed with above in +/- two weeks if there are no objections.
Not so fast. This is not easy changes and as i stated above, i'm far from be 
ok with this huge changes without discussion be more open in keg list

Meeting at Mountain VIew ?

-- 
Helio Chissini de Castro
KDE Developer
Brasil/South America Primary Contact