Peter Eisentraut píše v pá 03. 07. 2009 v 09:19 +0300:
> On Friday 03 July 2009 05:16:41 Robert Haas wrote:
> > On Thu, Jul 2, 2009 at 3:42 PM, Zdenek Kotala<Zdenek.Kotala@sun.com> wrote:
> > > Josh Berkus píše v st 01. 07. 2009 v 17:21 -0700:
> > >> Folks,
> > >>
> > >> There's been a lot of discussion/argument around how to handle the last
> > >> commitfest, but there seems to be a total consensus that we want to have
> > >> the first CF on July 15th.
> > >
> > > Can we add flags like bump catalog version, bump page layout version,
> > > modify AM for each patch? It should help to track pg_upgrade changes.
> >
> > That's not a bad idea, and it wouldn't be hard to add various flags
> > and things to the CommitFest app I wrote, but how would we maintain
> > the information and keep it correct? It seems like there might be a
> > danger that patch authors wouldn't know whether or not they were doing
> > those things. Also, how would we handle changes by committers, who
> > don't always go through the CommitFest process?
>
> I think this information could be computed automatically, if someone cared
> enough. It shouldn't be necessary to bother every single participant in the
> process with this.
I think that developer is responsible for his patch. He should know what
he doing. When he will send a patch and see checkbox like "modified AM?"
then he should know what he modified? It is also warning for commiter
that catalog version has to be bumped during a commit.
I don't see any method how to check automatically. Something could be
possible - like structure checker. But when meaning of data is going to
be different.
Zdenek
