    http://www.PostgreSQL.org/~wieck/

    The  new developers globe is updated with all photos I got so
    far.  Still missing are:

        Andrew Martin
        Bruce Momjian
        Byron Nikolaidis
        Constantin Teodorescu
        Edmund Mergl
        Goran Thyni
        Hiroshi Inoue
        Massimo dal Zotto
        Michael Meskes
        Tatsuo Ishii
        Thomas Lockhart
        Tom Lane

    Since I don't expect that we get all of them soon, I reverted
    and took out the photos from the text part again.

    Who  should  maintain  this page finally? If it's me, I would
    and update the content of the main site now. If not, tell  me
    who and when to transfer.

    BTW:  There are alot of files on the main site where cvs stat
    doesn't tell up-to-date. Some are locally  modified  but  not
    committed, some need a merge.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #



Sat, 30 Oct 1999 17:33:00 +0200 (MET DST)
wieck@debis.com (Jan Wieck)
missing mugshots
>     http://www.PostgreSQL.org/~wieck/
> 
>     The  new developers globe is updated with all photos I got so
>     far.  Still missing are:
> 
>         Andrew Martin
>         Bruce Momjian
>         Byron Nikolaidis
>         Constantin Teodorescu
>         Edmund Mergl
>         Goran Thyni
>         Hiroshi Inoue
>         Massimo dal Zotto
>         Michael Meskes
>         Tatsuo Ishii
>         Thomas Lockhart
>         Tom Lane

OK, mine is attached.  As I mentioned on the phone, I was waiting for a
haircut, but it seems it is not coming soon enough.  Here is a recent
photo I liked.

> 
>     Since I don't expect that we get all of them soon, I reverted
>     and took out the photos from the text part again.
> 
>     Who  should  maintain  this page finally? If it's me, I would
>     and update the content of the main site now. If not, tell  me
>     who and when to transfer.

If you would be willing to, that would be great.

> 
>     BTW:  There are alot of files on the main site where cvs stat
>     doesn't tell up-to-date. Some are locally  modified  but  not
>     committed, some need a merge.

You mean files on the site that are not in cvs, or are newer than the
cvs copies.  Either Vince or I did that, I suppose.  How did you find
which ones they were?  Vince, any ideas?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
Sat, 30 Oct 1999 11:50:27 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] missing mugshots
Bruce Momjian wrote:

> >
> >     BTW:  There are alot of files on the main site where cvs stat
> >     doesn't tell up-to-date. Some are locally  modified  but  not
> >     committed, some need a merge.
>
> You mean files on the site that are not in cvs, or are newer than the
> cvs copies.  Either Vince or I did that, I suppose.  How did you find
> which ones they were?  Vince, any ideas?

    [wieck@hub] ~pgsql/ftp/www/html > cvs stat |& less

    The  locally  modified  ones don't seem to be a problem to me
    since they are what's  visible  outside  and  simply  need  a
    commit.

    But  the  ones  telling  Needs Merge are!  This status means,
    that the working file is a locally modified copy of an  older
    revision  in  the  CVS.  A cvs update would try to merge both
    modifications into the new working file and this is  required
    before a commit! Let's take devel-contrib.html as an example:

    [wieck@hub] ~pgsql/ftp/www/html > cvs stat devel-contrib.html
    ===================================================================
    File: devel-contrib.html        Status: Needs Merge

       Working revision:    1.29    Mon Mar 29 16:43:09 1999
       Repository revision: 1.44    /usr/local/cvsroot/www/html/devel-contrib.html,v
       Sticky Tag:          (none)
       Sticky Date:         (none)
       Sticky Options:      (none)

    The last cvs  update  brought  the  working  copy  (that  one
    actually  on  the  web site) into sync with 1.29. Since then,
    there have been 15 commits  from  other  working  directories
    plus  local modifications to the file. Looking at the diff it
    seems that the authors (momjian and vev :-) have  a  checkout
    of  the repository on their home system, commit modifications
    there and instead of checking them out on the main site  they
    just  copy  their  working files onto the site, ignoring that
    the main site  is  another  working  directory  of  the  same
    repository. That's just what I guess from what I see.

    Just  to  be complete (don't know if there are any) the state
    Needs Patch means, that the working file is an unmodified one
    needing a cvs update because there where modifications to the
    CVS from somewhere else.

    To fix this situation I think we should first commit the ones
    that are modified locally via

        cvs commit <file>

    and do a

        cvs update <file>

    for any one that needs a patch.

    Finally  we  have  all  those left that need a merge. I'm not
    sure, but can we say that what's  actually  on  the  site  is
    correct?  If so, we could take the files one by one, move the
    actual file out of the way and do a

        cvs update <file>

    This will checkout the file  in  the  state,  the  repository
    thinks  is correct.  Then we move back what we know is actual
    and do a commit. After this move-update-moveback  cvs  thinks
    it's  a locally modified one and the new cvs revision is then
    what anybody can see on the web.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #



Sat, 30 Oct 1999 18:30:27 +0200 (MET DST)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] missing mugshots
Thus spake Jan Wieck
>     The  new developers globe is updated with all photos I got so

One thing I notice is that mine and the server share a pin (reasonable
as we are in the same place) but the way it is presented is a little
confusing.  It will get more confusing as time goes on and we get more
than one person in the same city.  At least in this case it's obvious that
the server didn't work on stuff.  There should be a cleaner delineation
between people sharing the same location.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

Sat, 30 Oct 1999 16:42:32 -0400 (EDT)
"D'Arcy" "J.M." Cain <darcy@druid.net>
Re: [HACKERS] missing mugshots
>
> Thus spake Jan Wieck
> >     The  new developers globe is updated with all photos I got so
>
> One thing I notice is that mine and the server share a pin (reasonable
> as we are in the same place) but the way it is presented is a little
> confusing.  It will get more confusing as time goes on and we get more
> than one person in the same city.  At least in this case it's obvious that
> the server didn't work on stuff.  There should be a cleaner delineation
> between people sharing the same location.

Hmmmm,

    does that mean the server is only close to you, not where you
    are?

    From the wording in the original page "...  and  location  of
    hub.org"  I  assumed  that  it is the SAME location, not just
    another one in Toronto.  Therefore I just colored the  pin  a
    little  different. But if it's a separate location it must be
    a separate pin with it's own popup.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #



Sat, 30 Oct 1999 22:48:13 +0200 (MET DST)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] missing mugshots

On 30-Oct-99 Jan Wieck wrote:
> Bruce Momjian wrote:
> 
>> >
>> >     BTW:  There are alot of files on the main site where cvs stat
>> >     doesn't tell up-to-date. Some are locally  modified  but  not
>> >     committed, some need a merge.
>>
>> You mean files on the site that are not in cvs, or are newer than the
>> cvs copies.  Either Vince or I did that, I suppose.  How did you find
>> which ones they were?  Vince, any ideas?
> 
>     [wieck@hub] ~pgsql/ftp/www/html > cvs stat |& less
> 
>     The  locally  modified  ones don't seem to be a problem to me
>     since they are what's  visible  outside  and  simply  need  a
>     commit.
> 
>     But  the  ones  telling  Needs Merge are!  This status means,
>     that the working file is a locally modified copy of an  older
>     revision  in  the  CVS.  A cvs update would try to merge both
>     modifications into the new working file and this is  required
>     before a commit! Let's take devel-contrib.html as an example:
> 
>     [wieck@hub] ~pgsql/ftp/www/html > cvs stat devel-contrib.html
>     ===================================================================
>     File: devel-contrib.html        Status: Needs Merge
> 
>        Working revision:    1.29    Mon Mar 29 16:43:09 1999
>        Repository revision: 1.44    /usr/local/cvsroot/www/html/devel-contrib.html,v
>        Sticky Tag:          (none)
>        Sticky Date:         (none)
>        Sticky Options:      (none)
> 
>     The last cvs  update  brought  the  working  copy  (that  one
>     actually  on  the  web site) into sync with 1.29. Since then,
>     there have been 15 commits  from  other  working  directories
>     plus  local modifications to the file. Looking at the diff it
>     seems that the authors (momjian and vev :-) have  a  checkout
>     of  the repository on their home system, commit modifications
>     there and instead of checking them out on the main site  they
>     just  copy  their  working files onto the site, ignoring that
>     the main site  is  another  working  directory  of  the  same
>     repository. That's just what I guess from what I see.

Must have been a long time ago.  Can I just do a cvs release or 
something like that?  I do all my work on hub.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH   email: vev@michvhf.com   flame-mail: /dev/null
  # include <std/disclaimers.h>       Have you seen http://www.pop4.net?
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================



Sat, 30 Oct 1999 16:58:53 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: [HACKERS] missing mugshots
Vince Vielhaber wrote:

> Must have been a long time ago.  Can I just do a cvs release or
> something like that?  I do all my work on hub.

    I don't know about such a command. And the real problem seems
    to me that there  are  multiple  maintainers  that  treat  it
    differently.

    The  content  provided on the net should NOT be a checked out
    working copy. Any maintainter of the files should  have  it's
    own  checkout local, ideally at a location where a web server
    can present it (like an apache virtual host).  The  files  on
    the  web site should be updated automatically by CVS rules at
    commit time.

    In this setup, one could test changes local until anything is
    O.K.  and  do  a  commit  that automatically presents all the
    changes at once to the world.

    An advance is, that if you want to do heavy modifications  to
    a couple of files, you could do a

        cvs admin -l <file> [...]

    and  be  sure,  noone else can do a commit until you're done.
    Well, another user  could  explicitly  break  the  lock  with
    another "cvs admin -l", but then you, as the original locker,
    are notified via mail about it.  If you ensure that there  is
    at  least  a little modification in the locked file (adding a
    space somewhere immediately after locking it), you  are  sure
    that  the  next  commit  will checkin a new revision. At this
    time, the lock implicitly is done and the  file  is  unlocked
    again. Otherwise you must do an explicit

        cvs admin -u <file> [...]

    to  release the lock with no changes made. And that bears the
    risk of forgetting locks.

    I'll play around a little with CVS rules (don't know  exactly
    how to set them up but I know that they exist). Will tell you
    later if this is something worth to try.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #



Sun, 31 Oct 1999 01:35:58 +0200 (MET DST)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] missing mugshots

On 31-Oct-99 Jan Wieck wrote:
> Vince Vielhaber wrote:
> 
>> Must have been a long time ago.  Can I just do a cvs release or
>> something like that?  I do all my work on hub.
> 
>     I don't know about such a command. And the real problem seems
>     to me that there  are  multiple  maintainers  that  treat  it
>     differently.
> 
>     The  content  provided on the net should NOT be a checked out
>     working copy. Any maintainter of the files should  have  it's
>     own  checkout local, ideally at a location where a web server
>     can present it (like an apache virtual host).  The  files  on
>     the  web site should be updated automatically by CVS rules at
>     commit time.
> 
>     In this setup, one could test changes local until anything is
>     O.K.  and  do  a  commit  that automatically presents all the
>     changes at once to the world.
> 
>     An advance is, that if you want to do heavy modifications  to
>     a couple of files, you could do a
> 
>         cvs admin -l <file> [...]
> 
>     and  be  sure,  noone else can do a commit until you're done.
>     Well, another user  could  explicitly  break  the  lock  with
>     another "cvs admin -l", but then you, as the original locker,
>     are notified via mail about it.  If you ensure that there  is
>     at  least  a little modification in the locked file (adding a
>     space somewhere immediately after locking it), you  are  sure
>     that  the  next  commit  will checkin a new revision. At this
>     time, the lock implicitly is done and the  file  is  unlocked
>     again. Otherwise you must do an explicit
> 
>         cvs admin -u <file> [...]
> 
>     to  release the lock with no changes made. And that bears the
>     risk of forgetting locks.
> 
>     I'll play around a little with CVS rules (don't know  exactly
>     how to set them up but I know that they exist). Will tell you
>     later if this is something worth to try.

Congrats Jan.  You lost me.  AFAIK that's how the website works - at least
as long as I've been maintaining it.  The thing that's not maintained that
way is the news and announcements which I maintain via a web based tool.
Bruce and Tom (Lockhart) maintain the docs pages.  Or am I missing something
totally obvious?

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH   email: vev@michvhf.com   flame-mail: /dev/null
  # include <std/disclaimers.h>       Have you seen http://www.pop4.net?
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================



Sat, 30 Oct 1999 20:19:50 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: [HACKERS] missing mugshots
Thus spake Jan Wieck
> > One thing I notice is that mine and the server share a pin (reasonable
> > as we are in the same place) but the way it is presented is a little
> > confusing.  It will get more confusing as time goes on and we get more
> > than one person in the same city.  At least in this case it's obvious that
> > the server didn't work on stuff.  There should be a cleaner delineation
> > between people sharing the same location.
> 
> Hmmmm,
> 
>     does that mean the server is only close to you, not where you
>     are?
> 
>     From the wording in the original page "...  and  location  of
>     hub.org"  I  assumed  that  it is the SAME location, not just
>     another one in Toronto.  Therefore I just colored the  pin  a
>     little  different. But if it's a separate location it must be
>     a separate pin with it's own popup.

I just assumed that there wasn't enough room to stick two pins in the same
city.  Well, we aren't in exactly the same place.  However, I connect
directly to the system that provides hub.org it's bandwidth so logically
we are next door neighbours.

However, it really is a different place but, as I said, we have to
deal with when we get big enough that one city might get crowded.
Why not just have the popup be a list of developers rather than one
and allow for more than one.

Then again, more pins looks better.  In any case, perhaps the server
should have its own pin.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

Sat, 30 Oct 1999 20:45:50 -0400 (EDT)
"D'Arcy" "J.M." Cain <darcy@druid.net>
Re: [HACKERS] missing mugshots
>     I'll play around a little with CVS rules (don't know  exactly
>     how to set them up but I know that they exist). Will tell you
>     later if this is something worth to try.

    Whow, never thought it would be that easy!

    If we place a tiny little script

    #!/bin/sh
    cd /home/projects/pgsql/ftp/www
    cvs update </dev/null >/dev/null 2>&1 &
    echo ""
    echo "Main WEBsite will be updated automatically."
    echo "The appropriate 'cvs update' is already waiting"
    echo "in background for your locks to be released."
    echo ""

    into  the  same directory it cd's to, we only need to add the
    line

    www -i /home/projects/pgsql/ftp/www/<script> www

    to the modules file in the CVSROOT and anyone  with  a  local
    checkout  must do a new checkout. Also we checkout the actual
    working directory of the real site again and  voila,  anytime
    someone does a commit a 'cvs update' is automatically started
    in the web sites root directory. It must run in background to
    avoid  a deadlock, so be it. The echo messages are visible to
    the one doing the commit, so it's just to  remind  that  he's
    doing something visible to the world.

    As  said,  anybody  should  WORK  in  his private checked out
    working directory at home. This would prevent side effects if
    multiple maintainers work on the real files.

    But  for very small changes, it would be O.K. to do it on the
    main site and commit  them  there,  because  the  cvs  update
    started in background would be a noop in fact.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #



Sun, 31 Oct 1999 02:55:01 +0200 (MET DST)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] missing mugshots
> Then again, more pins looks better.  In any case, perhaps the server
> should have its own pin.

    Not  allways,  at  least  if  more  than  50% of the area not
    occupied by water gets hidden by pins :-).

    Anyway, I'll make it a separate one and will work on the list
    approach  when  we  need it bacause of space shortage for new
    pins.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #



Sun, 31 Oct 1999 02:00:07 +0100 (MET)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] missing mugshots
Vince Vielhaber wrote:
> >
> >     I'll play around a little with CVS rules (don't know  exactly
> >     how to set them up but I know that they exist). Will tell you
> >     later if this is something worth to try.
>
> Congrats Jan.  You lost me.  AFAIK that's how the website works - at least
> as long as I've been maintaining it.  The thing that's not maintained that
> way is the news and announcements which I maintain via a web based tool.
> Bruce and Tom (Lockhart) maintain the docs pages.  Or am I missing something
> totally obvious?

Hmmm,

    maybe  I  lost  you,  but  then  again what you knew can't be
    right. The only CVSROOT files, where the module  www  occurs,
    are  the  history  and  the  loginfo.   And  loginfo  is just
    something that send's  logging  info  via  mail.  It  is  not
    intended  to  do  other automatic jobs, and the one entry for
    www    in    it    in    fact    only    sends    them     to
    committers@postgresql.org.

    If  it  works that way, it must be very tricky hidden and not
    implemented the way it should be. At least  it  doesn't  work
    anymore. I cannot imagine how it otherwise could be that from
    58 files in the www repository

    19 have state Up-to-Date
    24 have state Needs Merge
    and
     4 have state Locally Modified.

    And there are files, like overlib.*, that are totally unknown
    to the repository!


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #



Sun, 31 Oct 1999 02:23:55 +0100 (MET)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] missing mugshots
> Vince Vielhaber wrote:
> 
> > Must have been a long time ago.  Can I just do a cvs release or
> > something like that?  I do all my work on hub.
> 
>     I don't know about such a command. And the real problem seems
>     to me that there  are  multiple  maintainers  that  treat  it
>     differently.
> 
>     The  content  provided on the net should NOT be a checked out
>     working copy. Any maintainter of the files should  have  it's
>     own  checkout local, ideally at a location where a web server
>     can present it (like an apache virtual host).  The  files  on
>     the  web site should be updated automatically by CVS rules at
>     commit time.

I am sorry, but I am totally confused.

I have a cvs copy here.  I do cvs commits, and I ftp the files to the
web site when I make a change.  Yes, it would be nice to have cvs commit
automatically install them on the web site.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sat, 30 Oct 1999 22:04:47 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] missing mugshots
> >     I'll play around a little with CVS rules (don't know  exactly
> >     how to set them up but I know that they exist). Will tell you
> >     later if this is something worth to try.
> 
> Congrats Jan.  You lost me.  AFAIK that's how the website works - at least
> as long as I've been maintaining it.  The thing that's not maintained that
> way is the news and announcements which I maintain via a web based tool.
> Bruce and Tom (Lockhart) maintain the docs pages.  Or am I missing something
> totally obvious?

Yea, now we are both lost.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sat, 30 Oct 1999 22:05:26 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] missing mugshotsu