Re: Patch application

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Patch application
Дата
Msg-id 200103192039.PAA28281@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: Patch application  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Patch application  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Lamar Owen
Дата:
Сообщение: Re: Do you plan an RPM release of beta 6
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Patch application