Re: Patch application - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: Patch application |
Date | |
Msg-id | 200103192039.PAA28281@candle.pha.pa.us Whole thread Raw |
In response to | Re: Patch application (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Patch application
|
List | pgsql-hackers |
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I think it is time to start giving people official responsibility for > > certain areas of the code. > > This strikes me as overly formalistic, and more likely to lead to > arteriosclerosis than any improvement in code quality. Particularly > with a breakdown such as you have proposed, which would likely mean > asking multiple people to approve any given patch. > > I think the procedural error in this past weekend's contrib mess was > simply that you didn't pay attention to the fact that Oleg's patch was > based on an out-of-date copy of the contrib module. You should have > either merged the changes or bounced it back to Oleg for him to do so. > > Insisting on CVS $Header$ or $Id$ markers in all code files might help > to detect this kind of error --- but nothing will help if you are > willing to overwrite other people's changes simply because you didn't > recall the reason for them at the moment. I understand the formalistic problem, and maybe I overstated its formality, but it seems it would be good to maintain a list for two reasons: 1) With formalize experts in various areas, if someone replies to an email, the recipient can clearly know this person is an expert in that area. It also helps focus attention on certain people for development assistance. 2) The number of patches that I apply that need fixing by someone else is getting more frequent. The most recent patch is just one of many that had to be cleaned up for various reasons. I reviewed the patch and still didn't see the intent of the Makefile change. In this case, the CVS logs would have helped, but in others there is a design goal that I just can not comprehend. Looking at the list, I feel I would have to contact someone before making any changes to these areas. Even if I can get the patch applied properly, I doubt I would do it the _right_ way. Sometimes it is just that the style of the patcher doesn't match the style in our sources. Maybe we don't have to make it required, but plain patches from people I don't know really need some review. Perhaps I can attach the patch to the PATCHES list when I apply it so people can see exactly what was changed. Aren't people upset about the minor fixes they have to make to patches I apply? Is it easier to just clean up things rather than find/apply the patches? For example, almost any change to an SGML file seems to require Peter E to fix some part of it, usually the markup. Is that OK, Peter? Most of the interfaces require an interface expert's comment I would think. --------------------------------------------------------------------------- Makefiles/configure Peter E. psql Peter E. Jdbc Peter M. Odbc Hiroshi? Ecpg Michael Python D'Arcy Optimizer Tom Lane Rewrite Jan Locking Tom Cache Tom Date/Time Thomas Pl/PgSQL Jan SGML Peter E,Thomas WAL Vadim, Tom FAQ/TODO Bruce Regression PeterE? Multibyte Tatsuo GIST Oleg -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
pgsql-hackers by date: