Am 3. Mai 2013 20:15:37 schrieb Cristian Rodríguez <crrodriguez@opensuse.org>:

El 02/05/13 05:17, Stephan Kulow escribió:

...

Hi,

After Maximilian put quite some effort into fixing packages, we're down to 28 failures. As Max is on vacation the next weeks, it would be great if someone could target the remains and we can finally update:

http://s.kulow.org/3C - or if you prefer the long link:

https://build.opensuse.org/project/monitor?utf8=%E2%9C%93&commit=Filter%3A&f...

...

Greetings, Stephan

I fixed many of the listed packages, however submissions were rejected, the changelog police thinks nicer change entries are more important than getting stuff building, the priorities seem to be placed somewhere else.

I will not resubmit any change. someone else will have to deal with it.

Can you pass around some sr numbers? Seems like there is room for review-team debate. Would be great if you as a frequent submitter could express your concerns to the team.

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sam, 2013-05-04 at 17:05 +0200, Marcus Rueckert wrote:

[[[ - Fix build with automake 1.13 ]]]

is really better than

[[[ - added patch foo-1.1_automake_1.13.patch: Fix build with automake 1.13 by disabling -Werror ]]]

first message: i have *no* idea what you did. i would need to dig through the history to find that out. While you might still know what you did this week. will you still remember what you did in a few weeks or months? I doubt it.

changes entries are a very important communication channel to users, fellow packagers and yourself in a few months. take the time for proper communication.

I very much agree with Marcus on that one... .changes entries serve multiple purposes, one of them being documentation and aid for other packagers. The entire openSUSE Review team is not the strictest when it comes to this; frankly, I have seen many things passed through which I would likely have rejected; A simple "Fix build" just does not mean anything in a .changes entry. The packaging guidelines are surely not complete in this repsect, but they do carry a bunch of good hints of what should be done and what should not be done... One of the guidelines is to mention patch addition and removal by patch name (it really helps when you have to dig through various errors and finding our when a patch was dropped, or when it was added). In all fairness for Christian though: this is where the devel prj maintainers can surely help out more than they do: if somebody goes through hundreds of packages to fix this kind of issues, I'd argue that the devel prj maintainers can close an eye or two once in a while and support those mass-fixups by helping correct whatever they see is wrong. And only then submit the package to Factory (so the factory review team will be the 3rd pair of eye already... usually, you would have to believe that there can't be much wrong anymore at this time). Dominiqe -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 05/05/13 15:39, Cristian Morales Vega escribió:

The problem is that some maintainers perhaps really don't know what the patch is about.

Do maintainers for example need explanation for this single line spec file change ? mkdir -p m4 I hope everybody understands what mkdir does. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sunday 2013-05-05 22:07, Cristian Morales Vega wrote:

...

Do maintainers for example need explanation for this single line spec file change ?

mkdir -p m4

I hope everybody understands what mkdir does.

What they may (wrongly) understand is that it works both with and without that line.

When ACLOCAL_AMFLAGS is used in Makefile.am, it will not work without that line. So just better create it, either by way of mkdir, or by creating a dummy m4/.gitignore or something through the patch. 09:28 ares07:~/code/libhx > autoreconf -fi aclocal: error: couldn't open directory 'm4': No such file or directory autoreconf: aclocal failed with exit status: 1 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday 2013-05-06 09:31, Ludwig Nussel wrote:

...

When ACLOCAL_AMFLAGS is used in Makefile.am, it will not work without that line. So just better create it, either by way of mkdir, or by creating a dummy m4/.gitignore or something through the patch.

09:28 ares07:~/code/libhx > autoreconf -fi aclocal: error: couldn't open directory 'm4': No such file or directory autoreconf: aclocal failed with exit status: 1

I wonder why autoreconf -i doesn't just create the directory.

autoreconf itself probably cannot determine that m4 needs to be created; libtoolize is one of the few that can create the m4 directory (as is gettextize), but those run after aclocal, and aclocal wants to look in m4 by way of aclocal -I m4 (if specified). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2013-05-05 20:39:07 +0100, Cristian Morales Vega wrote:

On 5 May 2013 12:47, Dimstar / Dominique Leuenberger <dimstar@opensuse.org> wrote:

...

In all fairness for Christian though: this is where the devel prj maintainers can surely help out more than they do: if somebody goes through hundreds of packages to fix this kind of issues, I'd argue that the devel prj maintainers can close an eye or two once in a while and support those mass-fixups by helping correct whatever they see is wrong. And only then submit the package to Factory (so the factory review team will be the 3rd pair of eye already... usually, you would have to believe that there can't be much wrong anymore at this time).

The problem is that some maintainers perhaps really don't know what the patch is about. You receive the request, you see that in the devel project is building correctly. Perhaps you even check in openSUSE:Factory. But how are you supposed to know about openSUSE:Factory:Staging:Automake? You don't follow automake development. From what you know the "new automake" the changelog is talking about is the one in openSUSE:Factory. And since it's building correctly in there surely the submitter is wrong... SR declined.

you exactly describe *why* we need more verbose changes entry. *you* as maintainer *should* understand the change after reviewing it. if the current changes entry doesnt do that - reject is the right reaction. and I am not sure i would agree with "the devel project maintainer can add the more verbose changes entry" the submitter to the devel project can do it. Especially for such systematic changes like this, it is easy to have a template for changes entries. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org