ALERT: KDElibs (at least) 4.8.4 is actually 4.8.80+

Manuel Tortosa manutortosa at
Sun Jun 10 19:27:50 UTC 2012

El Diumenge, 10 de juny de 2012, a les 20:49:51, Wulf C. Krueger va escriure:
> > Feel free to wait until the packages are released publicly. That
> > way you'll have packages that work
> [...]
> > There is not a single untested tarball in any semipublic site.
> > There are untested tarballs in a private site.
> I think these two answers summarize nicely albeit with a very sad
> outcome what QA means to KDE.

I think you don't undestand what is KDE

KDE is a global opensource community, involving developers, artists, 
translators, packagers, distros shipping the project's WorkSpaces, so I am 
kde, YOU are KDE and Albert is KDE.

If you don't understand that KDE is more than a bunch of developers creating a 
set of woskspaces and applications, then everything will fail.

> >> No, you don't. You just told me you expect us to do your QA,
> >> your testing and, ideally, sort your stuff out (including,
> >> according to some, informing individual project leads).
> >> Disrespectful.
> > 
> > us and you is we

And of course i expect this too, the opensource community acts as a whole, a 
developer codes, a packager test the tarballs and finds issues and prepares the 
packages for the distro X and finally the users test the packages and reports 
bug upsgream.

> And that's another issue: No! You are the KDE upstream. We are
> downstream, the KDE packagers for the distributions.
> Yes, we'll gladly help you out but we're not here to do upstream's
> job. I assure you, we all have enough to do with our distro development.

He is KDE upstream, you are kde downstream, i live in the middle of both 
worlds. He, you, me , we are KDE.

> Let's put this thread to rest, though. I think we can both safely
> agree we have completely and seemingly irreconcilable points of view
> about QA and upstream/downstream roles.
> Since I seem to be the only packager seeing things the way I do (I
> guess others would have chimed in otherwise), I'll go back to lurking
> in here.

Obviously there's none perfect QA procedure and every project knows how 
comlicated is sometimes to get hands helping

Why we don't join efforts? 


More information about the release-team mailing list