On 2010-09-03 20:22:53 +0200, Lubos Lunak wrote:
On Friday 03 of September 2010, Marcus Rueckert wrote:
On 2010-09-03 19:27:15 +0200, Lubos Lunak wrote:
This does not yet address the entire lifecycle of the patch. For this, every touched patch needs to be mentioned, by filename, in the .changes file.
I really dislike the fact that the changelogs of our packages include from users' point of view completely irrelevant developer information. If the build service is not good enough for this on its own, it at least shouldn't be in the package's changelog.
it has to be in the changelog to find out when and why a patch got removed.
No, it doesn't have to be. It is just that the build service as a revision control system loses even to CVS. I may be a snooty developer, but I find it rather sad to repeatedly do manually something that a machine could do.
this information is also interesting for users when they want to find out why a fix/feature got removed.
I'm sure they're all dying to find out things like "Add libsoprano-devel Require to libkde4-devel", "package baselibs.conf", "refresh patch to compile on factory" (all real examples), or, with this new policy, something along the lines of "drop nepomuk-final.diff patch, included upstream".
yes. one of the users are reviewer of submissions. they really like to know why you removed the patch. maybe also other packager on the same package. and the whole thing should also work without getting an obs account (if that is even enough, see below) to look up why the patch got added/removed.
trust me ... walking down the history to find out when a patch got removed and then guessing why is no fun. I had to do that more than once already.
I've done that countless times with code in some repository. Noticeably less painful than figuring it out from changelogs.
"less *.changes" -> /foo.patch is much faster than hunting through osc log? maybe autobuild (because the patch got added/removed before the obs times) if you see some need to automated the work for yourself, then feel free. but for communication with users and other packagers those extra informations are very helpful. and trust me i see hundreds of packages every week. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org