On 03/21/2013 09:50 AM, Togan Muftuoglu wrote:
On 03/21/2013 09:10 AM, Sascha Peilicke wrote:
In ms opinion it can't hurt if develprojects apply Factory review rules to some degree too. Since some reviewers are packagers too that aleeady happens, although it should be more forgiving than for Factory.
Agreed
The reason is I had a declination with a comment why I have not explained use of %ghost macro in a spec file, but a person who would have reviewed the rpm buildlogs for the package would realize the fact that rpmlint gives the following error.
Who seriously looks at buildlogs when reviewing requests?
I do and I would expect those who review requests do as well other wise why bother in the first place to generate a build log and rpmlint log. If the package doesnot build it is recommended to have a look at the build log. Well I would assume if it builds fine one still should look the logs and especially the rpmlint log
Well, we review packages building for multiple architectures and a plethora of distros. Of course I mostly care about openSUSE:Factory (i586,x86_64) but still. And yes, I look at the rpmlint log for that target too. And no, I don't look at any build-log. On a calm day, I review ~50 packages, I simply don't have the time and it makes no sense either. Packages that don't build are declined by 'factory-auto' already, packages that build are good enough. I doubt people would appreciate if we start commenting the fuzzy mess that build-logs are ;-)
non-ghost-in-var-run (Badness: 1000)
And the mentioning %ghost in changes file in IMHO is nonsense as the issue has nothing to the with the package but packaging itself and from the end users point of is just cosmetic.
Depends on the exact case. In general, I'd say put it into the changes file and let the user decide. Also, reviewers look there for reasons why changes happen. Trying to read packagers minds is usually consuming too much time, so such requests may easily get a Factory decline. We have ~50-200 requests per day fighting for attention. Those with concise changes and clear documentation win. And I refuse to spend much time on the others :-)
As an end user I look the changes most of the time to see what is changed in the package, not in the packaging process. But as the review team's workload I can understand your point.
You raised a valid point, it's always debatable what the user _really_ interests. Since only power-users seem to check RPM changelogs and everybody differs on appropriate content, I'd rather see some noise than miss some more important stuff. As an example, the whole UsrMerge topic was mostly a packaging issue. But it had quite some consequences on the user, so we documented that appropriately. Lastly, I tend to think that users wanting to now _only_ what changed in a particular upstream release will probably search the upstream homepage anyway.
I would prefer that we improve the Factory review documentation and use that as a recommendation. Less doubled work.
That is even better, can you point me the wiki page for this documentation
Thanks Togan
-- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org