On 05/01/2008, at 18:42, Klaus Heinz wrote:
Greg Troxel wrote:It might also make sense to have a machine-parseable format forrecording upstream tracking status in patch files, or to record that itis a pkgsrc change (e.g., examples/conf file installation). Then pkglint could warn when there isn't a recorded status for a patch._Very_ strongly seconded. From what I have seen, many patches just hard-code something appropriate for pkgsrc.In the case of patches for pkgsrc-specific reasons this is anavoidable andthe patch will always be there.
Even patches that seem pkgsrc-specific can often be generalized enough to be fed back to developers. One of such examples is the hardcoding of subdirectories under sysconfdir: some packages currently just mess with that, hardcoding other values, but a different approach is to rework the configure script and source code to make that subdirectory name configurable and then default to the current behavior. This way they easily get accepted by upstream :-) But it surely is more work on our part.
I guess similar approaches are applicable to other pkgsrc-specific situations.
IMO we must reduce the number of patches. Often it is not clear why a patchis even there. CVS history is often useless because updates to patches mostly belong to some general update of the package with a CVS messagelike "update of foo to verson x.y". What is the meaning of those changedpatches? Impossible to tell from CVS history.
Very true. And to make things worse, I think mkpatches doesn't preserve the names of the patches when it regenerates them. (Or if it does, then this is some developer's "fault" ;-)
Could we make it a "policy" to add a comment on top of each patch stating its purpose and "feedback status" (i.e. if it has been sent upstream or not, who is responsible for the process, where it is being tracked, etc.)?
-- Julio M. Merino Vidal <jmmv84%gmail.com@localhost>