no pb encountered ( mga4 - 32 bit )

CC: (none) => mageia

no pb encountered ( mga4 - 64 bit )

validating

Could sysadmin please requested pkg from core/updates_testing to core/updates

Thankyou!

Keywords: (none) => validated_update
Whiteboard: MGA4-32-OK => MGA4-32-OK MGA4-64-OK
CC: (none) => sysadmin-bugs

Atilla, please provide a more verbose advisory, see e.g. https://bugs.mageia.org/show_bug.cgi?id=12385#c2

Keywords: validated_update => (none)
CC: (none) => remi
Whiteboard: MGA4-32-OK MGA4-64-OK => MGA4-32-OK MGA4-64-OK feedback

(In reply to Rémi Verschelde from comment #4)
> Atilla, please provide a more verbose advisory, see e.g.
> https://bugs.mageia.org/show_bug.cgi?id=12385#c2

Gladly, 
This update not brings much for users:
- Added missing manpage

For packaging side:
- Fixes for make dist and make distcheck
- Fix distcheck: Add option to disable icon cache.

References:
https://github.com/mate-desktop/mozo/compare/mate-menu-editor-1.6.0...mate-menu-editor-1.6.1

Thank you.

Frankly, this changelog does not seem enough to me to warrant an update. Remember that an update must have a real added value for users (security fix, bugfix). 

Every update brings risks and overhead:
- even with such a changelog, you don't know what could be broken in the new package (see mate-file-archiver 1.6.1 that introduced a bug)
- it uses mirror space and bandwidth. Not everybody can download lots of updates, so every update must have real added value to make up for that.
- it gives work to QA team and sysadmins

And I suspect there will be a 1.6.2 soon. We could probably have grouped the updates into one. This is usually what we do for projects with infrequent updates: depending on the changelog, decide whether we must push the update ASAP or can skip it until the next one.

Imagine that some project has a bugfix update every week. We wouldn't push updates to it every week. We would find some compromise, depending on the amount and severity of the bugs fixed. Maybe one update every 2 month (and that's a lot already). 

However, since this very update is part of a MATE series and testing is complete, we'll push it.

Not blaming, just trying to improve things for next time :)

If you thought of a new MATE update next week, forget it, unless really critical :)

(In reply to Samuel VERSCHELDE from comment #6)
> Frankly, this changelog does not seem enough to me to warrant an update.
> Remember that an update must have a real added value for users (security
> fix, bugfix). 
> 
> Every update brings risks and overhead:
> - even with such a changelog, you don't know what could be broken in the new
> package (see mate-file-archiver 1.6.1 that introduced a bug)
> - it uses mirror space and bandwidth. Not everybody can download lots of
> updates, so every update must have real added value to make up for that.
> - it gives work to QA team and sysadmins
> 
> And I suspect there will be a 1.6.2 soon. We could probably have grouped the
> updates into one. This is usually what we do for projects with infrequent
> updates: depending on the changelog, decide whether we must push the update
> ASAP or can skip it until the next one.
> 
> Imagine that some project has a bugfix update every week. We wouldn't push
> updates to it every week. We would find some compromise, depending on the
> amount and severity of the bugs fixed. Maybe one update every 2 month (and
> that's a lot already). 
> 
> However, since this very update is part of a MATE series and testing is
> complete, we'll push it.
> 
> Not blaming, just trying to improve things for next time :)
> 
> If you thought of a new MATE update next week, forget it, unless really
> critical :)


You may right. That's why i'm hesitating to push an update for mate-file-manager released two days ago. 

mate-file-archiver issue is my fault. I missed to test it with rpm packages, which i usually use it to see rpm contents. Overall, message well received! Thank you for this comment.

(In reply to Atilla ÃNTAÅ from comment #7)
> (In reply to Samuel VERSCHELDE from comment #6)
> mate-file-archiver issue is my fault. I missed to test it with rpm packages,
> which i usually use it to see rpm contents. Overall, message well received!
> Thank you for this comment.

Yep, in "you don't know what could be broken", there's a double issue :)
- bugs from upstream
- packaging bugs from the packager

(in my comment 7, s/infrequent/frequent/ I just learned the real meaning of infrequent :))

Advisory uploaded, please push to 4 core/updates.

Keywords: (none) => validated_update
Whiteboard: MGA4-32-OK MGA4-64-OK => MGA4-32-OK MGA4-64-OK advisory

nuked the build specific changelog part...

it has no place in an update advisory...

Update pushed:
http://advisories.mageia.org/MGAA-2014-0038.html

Status: NEW => RESOLVED
CC: (none) => tmb
Resolution: (none) => FIXED