Re: First CommitFest: July 15th
От | Zdenek Kotala |
---|---|
Тема | Re: First CommitFest: July 15th |
Дата | |
Msg-id | 1246648802.1228.54.camel@localhost обсуждение исходный текст |
Ответ на | Re: First CommitFest: July 15th (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: