[Mageia-dev] [changelog] [RPM] cauldron core/release kdenlive-0.8.2-1.mga2

[Angelo Naselli]

> If shit happen, then 151 bugs is IMHO a rather serious diarrhea.
Ok i get your point here.

> > The point is not why we released, but why not to update it.
> 
> My point is "why do we do the work twice".
Because developers are not perfect and even if they do their best
they always make mistakes (to avoid any war, me first).
Let's have a look at gnome bugzilla and check our mga 1 evolution:
http://tinyurl.com/dyydha9
Then our kmail:
http://tinyurl.com/crwo8wp
So if we look at those tables we should avoid to ship them to prevent
any update or trust them and eventually fix something, following their
develop or their releases. In any case now they are in (and maybe a crash
can make our mails to be lost)...

Thanks God we avoid kmail2 but i seem to recall it was in for a while...
maybe mikala was so good to avoid to have it in mga1, i'm not very happy
using it in cauldron(not to say mdv 2011)... maybe i won't in mga2... 
or maybe upstream team fixes a lot of bugs before... 
but that could be an mga2 story :)

> In case people didn't notice, there was a thread about "there is too
> much update". Some stuff are unavoidable, like security updates.
but they ask also ISOSs with updates to dowload once....
Anyway we could also quote people that in past asked for updates that never 
came.
 
> Some others could be avoided. And shipping a update is more costly ( it
> involve more people and a more complex process ) than shiping a proper
> package in the first place.
That requires more test in cauldron... bug you know well that end-user bugs
come not before betas for the most....

> So the best way to ensure less updates is to find why we do need to
> update in the first place. IE, how could have we prevented it.
i don't think less updates is right anyway, i think we should update in a 
right manner... which means more tests, more answers from reporters
and hopefully a good cover test -and yes it costs-. 

> And if we were not able to detect regression in the first place, how can
> we make sure that the update will fix something ?
I agree it's not always easy, but i take this thread to tell a problem i'm
looking these days, hplip and more probably ghostscript packages,
in mga1 i can't print photos -they are printed darker using a lot of ink-, 
is it blocking? Maybe no, but it is for me -and my purse- and for other people 
that reported it -one is using mandriva 2010.1 for that only-. 
Now I'm studying how to fix it (it works in cauldron now),  but i know already
that i cannot upgrade ghostscript and hplip, so great... the problem is solved
then.
I mean if someone, like me, spends his time to fix some but can't do an update
that is time lost, and what's worst the bug still stays opened...
Is that good?
I think we should always consider case by case, but also the story a potencial
update had... 


-- 
	Angelo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/mageia-dev/attachments/20111109/8ede312e/attachment.asc>