Обсуждение: Re: [COMMITTERS] pgsql: Add: > o Add SQLSTATE severity to PGconn return status > >
Re: [COMMITTERS] pgsql: Add: > o Add SQLSTATE severity to PGconn return status > >
От
Alvaro Herrera
Дата:
Bruce Momjian wrote: > Add: > > > o Add SQLSTATE severity to PGconn return status > > > > http://archives.postgresql.org/pgsql-interfaces/2007-11/msg00015.php Why do we keep the TODO file with the source code? Wouldn't it make more sense to store it separately? -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Re: [COMMITTERS] pgsql: Add: > o Add SQLSTATE severity to PGconn return status > >
От
Bruce Momjian
Дата:
Alvaro Herrera wrote: > Bruce Momjian wrote: > > > Add: > > > > > o Add SQLSTATE severity to PGconn return status > > > > > > http://archives.postgresql.org/pgsql-interfaces/2007-11/msg00015.php > > Why do we keep the TODO file with the source code? Wouldn't it make > more sense to store it separately? No idea --- it has always been there because it relates directly to the source. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes: > Alvaro Herrera wrote: >> Why do we keep the TODO file with the source code? Wouldn't it make >> more sense to store it separately? > No idea --- it has always been there because it relates directly to the > source. I kinda like the fact that the diffs get posted to pgsql-committers; it provides an easy chance to complain if the TODO description is off base, which isn't too unusual. What I'd like to have taken out of CVS is all the FAQs ... I find the diff traffic on those to be noise. But others probably see that differently. regards, tom lane
Re: Re: [COMMITTERS] pgsql: Add: > o Add SQLSTATE severity to PGconn return status > >
От
Magnus Hagander
Дата:
On Fri, Mar 07, 2008 at 04:55:17PM -0500, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > Alvaro Herrera wrote: > >> Why do we keep the TODO file with the source code? Wouldn't it make > >> more sense to store it separately? > > > No idea --- it has always been there because it relates directly to the > > source. > > I kinda like the fact that the diffs get posted to pgsql-committers; > it provides an easy chance to complain if the TODO description is off > base, which isn't too unusual. I personally find that quite annoying :-) For each commit we get both the diff posted to committers, and the reply from Bruce saying "Added to TODO". Both of which also contani the actual text... Ok, you're going to be soooo surprised to hear this from me... But... How about we move it to the wiki. AFAIK we can still lock it down to who can edit it if we want to (which may for the TODO certainly be a good idea). You can still get diffs. I think you can get them in the mail if you want it (using watches), and I think you can also get it as an RSS feed. > What I'd like to have taken out of CVS is all the FAQs ... I find the > diff traffic on those to be noise. But others probably see that > differently. +1 (at least, I'd + more than 1 if I was allowed to) Once again, to the big surprise of a lot of people I'm sure, how about the wiki? //Magnus
On Tue, 11 Mar 2008, Magnus Hagander wrote: > How about we move it to the wiki. AFAIK we can still lock it down to who > can edit it if we want to You should confirm you can get the editing granularity you want before making too many plans here if this is important. The features for locking down things in Mediawiki are very limited. The Wiki philosophy here is that you could revert quite a few bad changes in the time it would take you to lock it down so those bad changes could never happen in the first place. Last time I checked vandalism and bad edits were not a problem on the developer's wiki. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
On Tue, 11 Mar 2008, Greg Smith wrote: > On Tue, 11 Mar 2008, Magnus Hagander wrote: >> How about we move it to the wiki. AFAIK we can still lock it down to who >> can edit it if we want to > > You should confirm you can get the editing granularity you want before making > too many plans here if this is important. The features for locking down > things in Mediawiki are very limited. Will answer my own question now: the main useful protection available here is Mediawiki's "full protection", which makes pages so they can only be edited by users with sysops privledges. So in order to make a protected page that, say, mainly Bruce was allowed to edit, he'd have to be elevated to a sysops account. This would also give him broader powers over the Wiki at large, which presumably the current sysopts would be OK with. And anybody else who was a sysop could do what they wanted to that page as well. Basically there's one relevant level of protection, and you get one group of sysops who can edit any protected page and have access to some other admin features; that's it as far as how finely you can break things down as I understand it. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Re: [COMMITTERS] pgsql: Add: > o Add SQLSTATE severity to PGconn return status > >
От
Gregory Stark
Дата:
"Greg Smith" <gsmith@gregsmith.com> writes: > Will answer my own question now: the main useful protection available here is > Mediawiki's "full protection", which makes pages so they can only be edited by > users with sysops privledges. So in order to make a protected page that, say, > mainly Bruce was allowed to edit, he'd have to be elevated to a sysops account. I thought we considered Bruce being the only person who could edit the TODO list more of a bug than a feature. Consider how many times we've had to play broken-telephone trying to explain what the key aspects to express in the items were. It would be simpler to agree that there's a TODO and then have the person who knows what the item is write it or fix Bruce's attempt than to have to go through one person who wasn't necessarily involved in the discussion. That's not to say we don't need designated maintainers to own specific pages. But that's more of a positive assertion that if nobody else is doing something they're responsible for getting it done rather than a negative assertion that nobody else should be helping. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support!