Обсуждение: Re: [COMMITTERS] pgsql: Add: > o Add SQLSTATE severity to PGconn return status > >

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

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

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

"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!