Am 05.09.2010 14:13, schrieb Vincent Untz:
So you want to *duplicate* information just that the script can be kept a bit simpler?
I'm not saying we should duplicate it -- that's the worst solution. I'm just saying that, in my use case, both solution have ups and downs.
I agree there.
And you misread what I wrote since it's not "just" for a script. Having the tags in the spec files does help me too. Daily.
I can imagine that, but forcing every developer to do something (which is what a "policy" is doing) needs a bit more justification, IMO.
Normally opening a patch in my the editor (vim) is a matter of moving the cursor to the name of the patch and typing "gf", going back is '%'.
And when you have 5 patches and you want to have a quick overview of all of them, you open all files? :-) Having everything in the .spec file is faster in this case.
If we would have an agreement about the name of the tags in the patches, it wouldn't be difficult to write a command for osc that shows a nice overview about all patches. Imagine 50 patches (which is what we definitively have in some packages in openSUSE or in SLES at least at the time I worked for the company called Novell, so that's not a hypothetic scenario and no, I don't talk about the kernel or Samba which have their own patch management scripts). Then with the proposed 4 line tags that would be 250 lines of code in the spec file. I wouldn't call that "clear" but much more confusing than having the patch description inside the patches and some scripts to get the overview. Regards, Bernhard