Op zaterdag 15 januari 2011 11:24:52 schreef Cazzaniga Sandro: > Le 15/01/2011 11:08, Remy CLOUARD a écrit : > > Here’s a proposal: > > Patches must be named in a very explicit manner to make it very clear to > > what version it was originally applied. To that end, a patch needs to > > follow the convention of > > > > [package_name]-[version]-[description].patch: > > * [package_name] is the name of the package it applies against, such > > as 'shadow-utils' or 'gnupg' > > * [version] is the version of the program this patch was developed > > against, such as 1.0. The name of the patch should not change, even > > when it is rediffed, because the version allow to see in a blink since > > when this patch has been there. If you happen to see a patch that does > > not apply anymore, and rediff it, ask the package maintainer if it has > > been sent upstream, and why it hasn’t been merged, and send it > > upstream if you think it should be merged. > > * [description] is a short description of the patch's purpose. > > > > Example: foo-1.0-fix-str-fmt.patch for a patch that fixes string format > > errors > > I'm okay for naming patches as you say. It's clean and clear, we > understand well what a mistake they correspond.
i disagree with the patch naming: if you rediff a patch, i assume you test it out too, which means it was 'developped' for the current version, and i would like people to start using this version. ie: rediffing is development too.
