ALERT: KDElibs (at least) 4.8.4 is actually 4.8.80+
Jorge Manuel B. S. Vicetto
jmbsvicetto at gentoo.org
Mon Jun 11 00:18:29 UTC 2012
-----BEGIN PGP SIGNED MESSAGE-----
On 10-06-2012 19:35, Friedrich W. H. Kossebau wrote:
> Am Sonntag, 10. Juni 2012, 20:17:56 schrieb Wulf C. Krueger:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> On 10.06.2012 15:27, Albert Astals Cid wrote:
>>>> - - Before announcing the tarballs, build the whole thing at
>>>> least once.
>>> We do that, that's why we have a week before the release where
>>> packagers get access to pre-release tarballs.
>> No, that's for us packagers to "do our thing". What you give us
>> should, as a rule, build and install properly. Of course, we'll
>> notify you if things are broken but that should be the exception,
>> not the rule.
>> Nor should offloading the burden of QA to us be the rule. You
>> shouldn't just throw untested tarballs at our feet and hope for
>> the best.
> Hm. Somebody needs to be the first/one to test the tarballs. Who
> should that be? And what environment should she/he use? And should
> all other packagers simply wait until a first packager has tried to
> create packages from the tarballs?
If we (a downstream source distribution, in our case, Gentoo) did the
same you're suggesting, then we would just "blindly" update our
ebuilds (source recipes) from the previous release and throw them to
our users. Afterall, someone needs to be the first one trying to build
the tarballs, right?
As you say, someone needs to be the first one building the tarballs. I
think KDE needs to implement at least 2 changes to the release process:
1. do the CI work that is finally on the way (this should include at
least weekly builds of the current release branch and master)
2. after building the tarballs and before pushing them to packagers,
the release team should have more than 1 member and system building
the tarballs to ensure they're complete, all present and at least build.
> With regard to QA, all the tarballs are created from snapshots of
> the branches that the developers build from, all the time. So if
> there are problems they ideally would have already been found (and
> fixed) by the developers. Just that developers have usually not the
> exact build environment which there is for a package build, which
> is also different for each distribution.
As we continue to see on every new release, there are still some
issues that slip by. I'm glad to see the Jenkins work and hope that
will help increasing the QA of the tarballs for the future.
> Take the problems Rex today reported for kdesdk and Fedora as
> example. E.g. I build kdesdk once a week or so. Never saw his
> problem. And surely no other kdesdk developer has. Some things only
> turn up at packaging time, for a given distribution setup.
> Please also remember that the size and complexity of the software
> released as KDE SC has become quite large compared to KDE3 times,
> so a few more issues at release times are to be expected. Surely
> still everyone would like 0 issues :)
I would expect most distribution packagers to be well aware of the
size and complexity of KDE SC.
In our case (Gentoo), frequently 1 or 2 developers do the work of
bumping *all* kde packages for a release (284 ebuilds for 4.8.4).
> For the dependencies on not-released versions, that is indeed
> something that is annoying, should not have happened and should
> have been catched before. But as I understood Allen & Co. are
> working on a system to improve in that area, right?
>> Riiiight. It's all my perception only and KDE has no issues at
>> all. ;-)
> Nobody claims there are no issues. There are indeed quite a few.
> But it's simply nobody but us (and for me packagers are part of the
> KDE community, why else would they care for KDE software) who needs
> to fix them, as these are all our itches :)
> Cheers Friedrich _______________________________________________
> release-team mailing list release-team at kde.org
Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the release-team