On 10/28/2012 06:41 PM, Dimstar / Dominique Leuenberger wrote:
On Sun, 2012-10-28 at 14:38 -0300, Cristian Rodríguez wrote:
That information should be retrived from a different source, just like upstream changelogs. either from the SCM history, rpm metadata or something automated and yet to be developed, where the OBS knows a new patch has been added and stores such information for everybody to see, without bothering packages with meaningless tasks.
The OBS knows but your other fellow packagers have no clue what that patch is for if there is no patch tag.
I know you know better than that Christian.. BUT: OBS is not really a VCS... you know, I know.. everybody knows.. let's stop claiming the opposite.
It is so absurd that complyng with this rules takes more time than actually fixing a problem.
Packaging is a task of it's own... and, considering that I can update an entire gnome stack in < 2 days (which is ~ 200 packages!) I don't think those 'rules' are that difficult to honor... in fact, they just ask you to write down what you do... I know, documentation is NOT exactly what devs like.. but without it, we're just lost.
I would actually advocate that even in devel projects of packages that are part of factory. if the submitted package has patches and the patches are not neither tagged in the spec, nor have a header that briefly describes the purpose of the patch should be declined until they meet the patching guidelines. Because if I as a contributor would like to update the package either to a newer version or fixing some broken build; if there are no patch tags in the spec or no header in the patch, I am spending time to figure out what does that patch do and in newer versions why the patch fails. In my opinion following patch guidelines is not bureaucracy nor absurd but courtesy towards other contributors. Togan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org