On 6.9.2010 11:10, Dominique Leuenberger wrote:
On 09/06/2010 at 10:49 AM, Michal Marek <mmarek@suse.cz> wrote: But your proposal makes this even less scalable and more painful. Packages with lots of patches are here to stay, the exercise should be to make their maintenance easier, not the opposite.
Are they??? Isn't the spirit of opensource to bring those patches back upstream? Having a package that is supposed to keep it's patches around just sounds broken.
For Factory, yes. But packages also need to be maintained after release, and not every upstream project has maintenance branches to follow. Anyway, even in Factory we have packages with lots of patches, and yes, it would be great if the number of patches reduced, but artificially making it hard to maintain large numbers of patches is not the solution.
The tag line is not only for scripts, that's for sure.. but also for other people hacking on your spec files (everybody should be able to touch every package, no?)
I'm not at all convinced that that a preamble interleaved with comments with cryptic tags is more convenient to work with, especially for outsiders. What's the problem with putting any metadata into the patch headers? This is what some other teams are already doing, it is easily extensible and the pairing of patches and metadata is straightforward. Or even better, let each time work the way they think is most efficient for them. I'm also not saying "all packages must have a patches.fixes.tar.bz2 and patches.suse.tar.bz2, this is going to be an autobuild rule starting next week".
Having the comment of the patch in the preamble helps understanding what a patch is for without switching to all the other 20 files in the folder. Additionally it helps the autobuild team to understand why a patch get's there.
Having good patch filenames helps you as well, the rest can live in the patch headers. The autobuild team has to review the patches themselves anyway. To me it really looks like the goal is to make Vincent's statistics work fast and reliable and anything else is secondary to that. Michal -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org