Обсуждение: 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 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) #
> 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
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) #
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.
>
> 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) #
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 seenhttp://www.pop4.net? Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
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) #
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 seenhttp://www.pop4.net? Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
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.
> 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) #
> 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) #
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) #
> > 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, Pennsylvania19026
> 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, Pennsylvania19026