On Tue, 2016-02-02 at 08:25 +0100, Michael Ströder wrote:
1. Some reviewers insist on adding a lot of lines to .changes files claiming that there are common practices to do so. But many packages do this differently. And personally I think it's plain wrong to add all upstream changes to fit into .changes when simply updating to a new upstream release.
The big problem is that packagers are just too lazy to UNDERSTAND and READ what is written in the release announcemnts. So the review team has to do the job for you! Not seldom there is stuff written about new features that can be enabled if this and that is added as a build dep. Or other interesting stuff. It's not about COPYING it in, but actually putting in what is important to know about the release... if you copy, that's fine, BUT: take the time to read and understand the implications of the update. A pkg update is done in 30 seconds - doing it proper and understanding what other changes need to be done, takes a bit more time (I for one use the diff of 'old' and 'new' configure.ac to update build dependencies for example... does it take time? yes. Does it improve quality? Maybe not 'obvious' when I just rely that stuff in Factory is there as I expect it to be... but if my packages are branched, they don't just fail in weird ways for missing deps - or worse: silently disable features which nobody understands why. Packaging takes brain, just as many other task does... where upstream specifies well enough the deps, even ideas like the automatic perl and ruby updaters are doable... so updating them becomes a 0s task, and STILL conforms to the packaging guidelines... so if a BOT can do it: wht can't you? Too boring? Write a bot for your packages. Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org