Re: [HACKERS] Current sources?
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Current sources? |
Дата | |
Msg-id | 9258.896192241@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Current sources? (The Hermit Hacker <scrappy@hub.org>) |
Ответы |
Re: [HACKERS] Current sources?
|
Список | pgsql-hackers |
The Hermit Hacker <scrappy@hub.org> writes: > On Mon, 25 May 1998, David Gould wrote: >> - if the build and regression is good, then a snapshot is made into a >> "last known good" location. > Actually, ummm...I've been considering removing the snapshot's > altogether, now that anoncvs works. It may be worth pointing out that cvs allows anyone to retrieve *any* prior state of the code. This opens up a great number of options that a simple periodic snapshot does not. I think it's worth continuing the snapshot series for those who don't want to install cvs for some reason, but that probably won't be the primary access method anymore. The thing that I thought was worth adopting from David's list was the nightly automatic regression test run. Assuming that there are cycles to spare on the server, posting the results of a build and regression test attempt would help provide a reality check for everyone. (It'd be too bulky to send to the mailing lists, and not worth archiving anyway; perhaps the output could be put up as a web page at postgresql.org?) This sort of fiasco could be minimized if everyone got in the habit of running regression tests before submitting their patches. Here I have to disagree with Marc's opinion that it's not really important whether pre-alpha code works. If the tree is currently broken, that prevents everyone else from running regression tests on what *they* are doing, and consequently encourages the submission of even more code that hasn't been adequately tested. I would like to see a policy that you don't check in code until it passes regression test for you locally. We will still have failures because of (a) portability problems --- ie it works at your site, but not for someone else; and (b) unforeseen interactions between patches submitted at about the same time. But hopefully those will be relatively easy to track down if the normal state is that things mostly work. We might also consider making more use of cvs' ability to track multiple development branches. If several people need to cooperate on a large change, they could work together in a cvs branch until their mods are finished, allowing them to share development files without breaking the main branch for others. regards, tom lane
В списке pgsql-hackers по дате отправления: