Thread: cvs problem
Marc, what's happens with cvs ? I still can't update: cvs server: failed to create lock directory for /projects/cvsroot/pgsql/contrib/pgstattuple' (/projects/cvsroot/pgsql/contrib/pgstattuple/#cvs.lock):Permission denied cvs server: failed to obtain dir lock in repository /projects/cvsroot/pgsql/contrib/pgstattuple' cvs [server aborted]: read lock failed - giving up Regards, Oleg _____________________________________________________________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
Oleg Bartunov <oleg@sai.msu.su> writes:
> what's happens with cvs ? I still can't update:
> cvs server: failed to create lock directory for /projects/cvsroot/pgsql/contrib/pgstattuple'
(/projects/cvsroot/pgsql/contrib/pgstattuple/#cvs.lock):Permission denied
> cvs server: failed to obtain dir lock in repository /projects/cvsroot/pgsql/contrib/pgstattuple'
> cvs [server aborted]: read lock failed - giving up
Hmm. That's a new directory that Tatsuo just created. I bet the
umask or group ID that the cvs server is running under is wrong.
regards, tom lane
should be fixed now ... On Mon, 1 Oct 2001, Oleg Bartunov wrote: > Marc, > > what's happens with cvs ? I still can't update: > > cvs server: failed to create lock directory for /projects/cvsroot/pgsql/contrib/pgstattuple' (/projects/cvsroot/pgsql/contrib/pgstattuple/#cvs.lock):Permission denied > cvs server: failed to obtain dir lock in repository /projects/cvsroot/pgsql/contrib/pgstattuple' > cvs [server aborted]: read lock failed - giving up > > Regards, > Oleg > _____________________________________________________________ > Oleg Bartunov, sci.researcher, hostmaster of AstroNet, > Sternberg Astronomical Institute, Moscow University (Russia) > Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ > phone: +007(095)939-16-83, +007(095)939-23-83 > >
Marc,
it worked, but now I'm again getting:
cvs server: failed to create lock directory for /projects/cvsroot/pgsql/contrib/pgcrypto/expected'
(/projects/cvsroot/pgsql/contrib/pgcrypto/expected/#cvs.lock):Permission denied
cvs server: failed to obtain dir lock in repository /projects/cvsroot/pgsql/contrib/pgcrypto/expected'
cvs [server aborted]: read lock failed - giving up
Seems, again wrong permissions
Regards,
Oleg
On Mon, 1 Oct 2001, Marc G. Fournier wrote:
>
> should be fixed now ...
>
>
> On Mon, 1 Oct 2001, Oleg Bartunov wrote:
>
> > Marc,
> >
> > what's happens with cvs ? I still can't update:
> >
> > cvs server: failed to create lock directory for /projects/cvsroot/pgsql/contrib/pgstattuple'
(/projects/cvsroot/pgsql/contrib/pgstattuple/#cvs.lock):Permission denied
> > cvs server: failed to obtain dir lock in repository /projects/cvsroot/pgsql/contrib/pgstattuple'
> > cvs [server aborted]: read lock failed - giving up
> >
> > Regards,
> > Oleg
> > _____________________________________________________________
> > Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
> > Sternberg Astronomical Institute, Moscow University (Russia)
> > Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
> > phone: +007(095)939-16-83, +007(095)939-23-83
> >
> >
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
Regards, Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
> Marc, > > it worked, but now I'm again getting: > > cvs server: failed to create lock directory for /projects/cvsroot/pgsql/contrib/pgcrypto/expected' (/projects/cvsroot/pgsql/contrib/pgcrypto/expected/#cvs.lock):Permission denied > cvs server: failed to obtain dir lock in repository /projects/cvsroot/pgsql/contrib/pgcrypto/expected' > cvs [server aborted]: read lock failed - giving up > > Seems, again wrong permissions Those are directories I just created. They have the same permission as all the other files here. Maybe there is a problem with CVS server creating stuff with the wrong permission. -- Bruce Momjian | http://candle.pha.pa.us pgman@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
On Mon, 1 Oct 2001, Bruce Momjian wrote: > > Marc, > > > > it worked, but now I'm again getting: > > > > cvs server: failed to create lock directory for /projects/cvsroot/pgsql/contrib/pgcrypto/expected' (/projects/cvsroot/pgsql/contrib/pgcrypto/expected/#cvs.lock):Permission denied > > cvs server: failed to obtain dir lock in repository /projects/cvsroot/pgsql/contrib/pgcrypto/expected' > > cvs [server aborted]: read lock failed - giving up > > > > Seems, again wrong permissions > > Those are directories I just created. They have the same permission as > all the other files here. Maybe there is a problem with CVS server > creating stuff with the wrong permission. Please also check things on the anoncvs server (if it's different). Take care, Bill
> Those are directories I just created. They have the same permission as
> all the other files here. Maybe there is a problem with CVS server
> creating stuff with the wrong permission.
From my experience, it is likely that you have a umask problem. Or there
is some other read/write permissions problem for group and other.
Please dive into the cvs repository and check the files (and directory,
which seems to be lacking group write permission) Bruce.
- Thomas
> > > Those are directories I just created. They have the same permission as > > all the other files here. Maybe there is a problem with CVS server > > creating stuff with the wrong permission. > > >From my experience, it is likely that you have a umask problem. Or there > is some other read/write permissions problem for group and other. > > Please dive into the cvs repository and check the files (and directory, > which seems to be lacking group write permission) Bruce. OK, I see: drwxrwxr-x 2 momjian pgsql 512 Oct 1 15:53 sql and in the SQL directory I see: -r--r--r-- 1 momjian pgsql 1843 Oct 1 12:12 blowfish.sql,v -r--r--r-- 1 momjian pgsql 600 Oct 1 12:12 crypt-blowfish.sql,v -r--r--r-- 1 momjian pgsql 547 Oct 1 12:12 crypt-des.sql,v -r--r--r-- 1 momjian pgsql 559 Oct 1 12:12 crypt-md5.sql,v -r--r--r-- 1 momjian pgsql 571 Oct 1 12:12 crypt-xdes.sql,v -r--r--r-- 1 momjian pgsql 1529 Oct 1 12:12 hmac-md5.sql,v -r--r--r-- 1 momjian pgsql 1536 Oct 1 12:12 hmac-sha1.sql,v -r--r--r-- 1 momjian pgsql 350 Oct 1 12:12 init.sql,v -r--r--r-- 1 momjian pgsql 694 Oct 1 12:12 md5.sql,v -r--r--r-- 1 momjian pgsql 1371 Oct 1 12:12 rijndael.sql,v -r--r--r-- 1 momjian pgsql 702 Oct 1 12:12 sha1.sql,v I don't know what else to look for. Ideas? -- Bruce Momjian | http://candle.pha.pa.us pgman@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
> > > Those are directories I just created. They have the same permission as > > all the other files here. Maybe there is a problem with CVS server > > creating stuff with the wrong permission. > > >From my experience, it is likely that you have a umask problem. Or there > is some other read/write permissions problem for group and other. > > Please dive into the cvs repository and check the files (and directory, > which seems to be lacking group write permission) Bruce. The one thing I can't check is the anoncvs directory. Not sure if that is the same as the CVS directory. -- Bruce Momjian | http://candle.pha.pa.us pgman@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
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> The one thing I can't check is the anoncvs directory. Not sure if that
> is the same as the CVS directory.
It is the anoncvs server that's broken. The committers don't seem to be
having any problem with accesses to the primary server. I suspect that
there's a umask or group-membership issue on the anoncvs machine only.
regards, tom lane
> > The one thing I can't check is the anoncvs directory. Not sure if that > > is the same as the CVS directory. > > It is the anoncvs server that's broken. The committers don't seem to be > having any problem with accesses to the primary server. I suspect that > there's a umask or group-membership issue on the anoncvs machine only. Ack! Before everyone under the sun claims to have found a problem: the user that the anon cvs pserver is running under can't create lock files in the src dirs inline w/ the code). A few things can happen: 1) Add the cvs pserver user to the pgsql group and add write privs to the dirs for the user (chmod -R g+w *) 2) Add a LockDir in the cvs config. cvs co CVSROOT cd CVSROOT echo "LockDir /tmp/cvsroot" >> config cvs ci -m "Adding a central lock dir to the anoncvs server"config mkdir /tmp/cvsroot chmod 1777 /tmp/cvsroot chown root.wheel /tmp/cvsroot I think that should do it... -sc -- Sean Chittenden
On Mon, 1 Oct 2001, Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > The one thing I can't check is the anoncvs directory. Not sure if that > > is the same as the CVS directory. > > It is the anoncvs server that's broken. The committers don't seem to be > having any problem with accesses to the primary server. I suspect that > there's a umask or group-membership issue on the anoncvs machine only. It seems you don't have to be new here to be a bit peeved about things;-( I'm peeved because I found instructions on how to checkout with anonymous CVS and did so a few times. I had a find old time finding and reporting problems (with the software). Then CVS stopped working because someone thought it a fine idea to reorganise the directory structure, to change the CVSROOT.No matter the user who had the old one stored on their computers. I've report it twice, pointing out that what I did before worked, and that I was doing coincided with what the web pagessaid. There was discussion that the web pages were wrong and who's job it was to fix. As an invited guest, I reckon it's the CVSrepository that is wrong. It's wrong because it's different from what worked before. Time to get your act together fellas.
On Mon, 1 Oct 2001, Bruce Momjian wrote: > > Marc, > > > > it worked, but now I'm again getting: > > > > cvs server: failed to create lock directory for /projects/cvsroot/pgsql/contrib/pgcrypto/expected' (/projects/cvsroot/pgsql/contrib/pgcrypto/expected/#cvs.lock):Permission denied > > cvs server: failed to obtain dir lock in repository /projects/cvsroot/pgsql/contrib/pgcrypto/expected' > > cvs [server aborted]: read lock failed - giving up > > > > Seems, again wrong permissions > > Those are directories I just created. They have the same permission as > all the other files here. Maybe there is a problem with CVS server > creating stuff with the wrong permission. Did you change versions of cvs (the software)? I had a little fiddle with it some time ago, and there was a change wherebythe newer version didn't do what I wanted.
On Tue, 2 Oct 2001, John Summerfield wrote: > On Mon, 1 Oct 2001, Tom Lane wrote: > > > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > The one thing I can't check is the anoncvs directory. Not sure if that > > > is the same as the CVS directory. > > > > It is the anoncvs server that's broken. The committers don't seem to be > > having any problem with accesses to the primary server. I suspect that > > there's a umask or group-membership issue on the anoncvs machine only. > > > It seems you don't have to be new here to be a bit peeved about things;-( > > > I'm peeved because I found instructions on how to checkout with anonymous CVS and did so a few times. > > I had a find old time finding and reporting problems (with the software). > > Then CVS stopped working because someone thought it a fine idea to reorganise the directory structure, to change the CVSROOT.No matter the user who had the old one stored on their computers. Gee, I didn't realize we were doing it just cuze "someone thought it a fine idea" > I've report it twice, pointing out that what I did before worked, and that I was doing coincided with what the web pagessaid. > > There was discussion that the web pages were wrong and who's job it was to fix. As an invited guest, I reckon it's theCVS repository that is wrong. It's wrong because it's different from what worked before. I just looked in cvs and it looks fine there. > Time to get your act together fellas. Gee, I didn't realize we were screwing off. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
On Monday 01 October 2001 07:33 pm, John Summerfield wrote: > It seems you don't have to be new here to be a bit peeved about things;-( [snip] > Time to get your act together fellas. This is open source John, not rocket science. (pun intended) Lighten up. The release will happen, regardless of minor server issues (that are being worked out right now, even as I write, by highly capable professionals, who, BTW, are doing this on a volunteer basis). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On Tue, 2 Oct 2001, Vince Vielhaber wrote: > On Tue, 2 Oct 2001, John Summerfield wrote: > > > On Mon, 1 Oct 2001, Tom Lane wrote: > > > > > > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > > The one thing I can't check is the anoncvs directory. Not sure if that > > > > is the same as the CVS directory. > > > > > > It is the anoncvs server that's broken. The committers don't seem to be > > > having any problem with accesses to the primary server. I suspect that > > > there's a umask or group-membership issue on the anoncvs machine only. > > > > > > It seems you don't have to be new here to be a bit peeved about things;-( > > > > > > I'm peeved because I found instructions on how to checkout with anonymous CVS and did so a few times. > > > > I had a find old time finding and reporting problems (with the software). > > > > Then CVS stopped working because someone thought it a fine idea to reorganise the directory structure, to change theCVSROOT. No matter the user who had the old one stored on their computers. > > Gee, I didn't realize we were doing it just cuze "someone thought it a > fine idea" Then why didn't you put it back the way it had been when it worked? When someone does a cvs login, cvs records the valuefor CVSROOT. You made everyone's cvs login fail. I don't see the sense in that. And then you diddle round endlessly instead of telling me what I had to do to fix YOUR mistake. I hope you're in better shape by beta time. And instead of componding the problem with rudeness, listen to it. You don't have to like the message or the language, butthere are reasons for both.
On Tue, 2 Oct 2001, Lamar Owen wrote: > On Monday 01 October 2001 07:33 pm, John Summerfield wrote: > > It seems you don't have to be new here to be a bit peeved about things;-( > [snip] > > Time to get your act together fellas. > > This is open source John, not rocket science. (pun intended) Hmm. Kids I was at school with were building rockets in their backyards. OSS is similarly a backyard affair. Awhere's the difference;-) > > Lighten up. The release will happen, regardless of minor server issues (that > are being worked out right now, even as I write, by highly capable > professionals, who, BTW, are doing this on a volunteer basis). I appreciate the volunteer point. However, a project in disarray is a project in disarray whether volunteer or not. And the discussion that followed my original report of the CVS problem looked to memore like finger-pointing than a realeffort to locate and fix the problem, or to help me on my way. I know I'm not well-known here, but I've made my contributions in other arenas where I'm stronger. PG isn't perfect - we all know that. Nor is the project administration. When there's a problem identified, someone has totake responsibility for fixing it, and someone has to ensure the person reporting the problem has a way forward. Changing the CVS repository so it doesn't work the same way any more isn't smart. Having wrong documentation isn't smart.Taking two weeks and NOT fixing a simple problem isn't smart. Giving wrong advice isn't smart. Test your advice - wherepossible I do. "Lighten up" isn't the right response. Examine your project. See what points I make have merit. Welcome criticism. You don't have to like the message you know;-)
On Thu, 4 Oct 2001, John Summerfield wrote: > I know I'm not well-known here, but I've made my contributions in other arenas where I'm stronger. > > PG isn't perfect - we all know that. Nor is the project administration. When there's a problem identified, someone hasto take responsibility for fixing it, and someone has to ensure the person reporting the problem has a way forward. > > > Changing the CVS repository so it doesn't work the same way any more isn't smart. Having wrong documentation isn't smart.Taking two weeks and NOT fixing a simple problem isn't smart. Giving wrong advice isn't smart. Test your advice - wherepossible I do. > > "Lighten up" isn't the right response. Examine your project. See what points > I make have merit. Welcome criticism. You don't have to like the message you know;-) Do you know why you're not well known? With the pissy attitude you're showing here more and more folks tend to just drop your email in the bit bucket - like this... *** PLONK *** Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
On Thu, 4 Oct 2001, John Summerfield wrote: > On Tue, 2 Oct 2001, Lamar Owen wrote: > > > > On Monday 01 October 2001 07:33 pm, John Summerfield wrote: > > > It seems you don't have to be new here to be a bit peeved about things;-( > > [snip] > > > Time to get your act together fellas. > > > > This is open source John, not rocket science. (pun intended) > > > > Lighten up. The release will happen, regardless of minor server issues (that > > are being worked out right now, even as I write, by highly capable > > professionals, who, BTW, are doing this on a volunteer basis). > > Changing the CVS repository so it doesn't work the same way any more > isn't smart. Having wrong documentation isn't smart. Taking two weeks > and NOT fixing a simple problem isn't smart. Giving wrong advice isn't > smart. Test your advice - where possible I do. > > "Lighten up" isn't the right response. Examine your project. See what points > I make have merit. Welcome criticism. You don't have to like the message you know;-) Actually, I think "Lighten up" was a reasonable response, given the tone of the message this was in response to which appears to be what Lamar was responding to. Besides, there's a far cry from a message of constructive criticism and the message this was in response to. The point that the documentation and reality need to match up is a good one, but saying that "It's wrong because it's different from what worked before" isn't reasonable. Saying, "This change is unfortunate and did it really have to happen and why? And the documentation and the server realities really have to match up. Perhaps changing the page first with a note of both configurations with an estimated time change for the server would have been better/the right way to do this" is reasonable.
> Changing the CVS repository so it doesn't work the same way any > more isn't smart. Having wrong documentation isn't smart. Taking > two weeks and NOT fixing a simple problem isn't smart. Giving > wrong advice isn't smart. Test your advice - where possible I > do. I will consider this point valid. When we changed CVS download steps, we should have updated the CVS web page right away. I did update the SGML version, but for other reasons, the web version didn't update and that caused great confusion. -- Bruce Momjian | http://candle.pha.pa.us pgman@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
...
> I hope you're in better shape by beta time.
Hi John. I would highly recommend taking a deep breath and coming back
in a couple of weeks. Things should have settled down by then and we
will have returned to your high standards of service and support. In the
meantime, folks are busy getting us there...
Regards.
- Thomas
On Wednesday 03 October 2001 07:53 pm, John Summerfield wrote: > On Tue, 2 Oct 2001, Lamar Owen wrote: > > On Monday 01 October 2001 07:33 pm, John Summerfield wrote: > > > Time to get your act together fellas. > > This is open source John, not rocket science. (pun intended) > Hmm. Kids I was at school with were building rockets in their backyards. > OSS is similarly a backyard affair. Awhere's the difference;-) But that's a _hobby_, not 'rocket science' -- and the pun was that there _is_ a rocket scientist among us.... Lots of us here are doing this as a hobby. > > Lighten up. The release will happen, regardless of minor server issues > > (that are being worked out right now, even as I write, by highly capable > > professionals, who, BTW, are doing this on a volunteer basis). > I appreciate the volunteer point. However, a project in disarray is a > project in disarray whether volunteer or not. Two weeks of disarray versus 5 years of soloid performance. You'd think a couple of weeks of temporary pain wouldn't be a big deal. > PG isn't perfect - we all know that. Nor is the project administration. > When there's a problem identified, someone has to take responsibility for > fixing it, and someone has to ensure the person reporting the problem has a > way forward. And the problem is being addressed. Patience is a good watchword. > "Lighten up" isn't the right response. Examine your project. See what > points I make have merit. Welcome criticism. You don't have to like the > message you know;-) No, I don't have to like the message. But the message can be phrased in a more polite way, as has been pointed out. You were just being a little too _serious_ about it, that's all. Give it a week or two, and things will be OK. The issues are in Vince and Marc's very capable hands -- but, as Marc said, this stuff has lived in the same place for >5 years -- and lots of interdependencies had to be addressed. And they _are_being addressed. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On Thu, 4 Oct 2001, Lamar Owen wrote: > On Wednesday 03 October 2001 07:53 pm, John Summerfield wrote: > > On Tue, 2 Oct 2001, Lamar Owen wrote: > > > On Monday 01 October 2001 07:33 pm, John Summerfield wrote: > > > > Time to get your act together fellas. > > > > This is open source John, not rocket science. (pun intended) > > > Hmm. Kids I was at school with were building rockets in their backyards. > > OSS is similarly a backyard affair. Awhere's the difference;-) > > But that's a _hobby_, not 'rocket science' -- and the pun was that there _is_ > a rocket scientist among us.... Lots of us here are doing this as a hobby. Well, I don't know the backgrounds of the folk here, any more than you know mine;-) And as far as I can tell, most open-source workers can properly be described as hobbyists. I know some get paid for their efforts, but not a lot. > > > Lighten up. The release will happen, regardless of minor server issues > > > (that are being worked out right now, even as I write, by highly capable > > > professionals, who, BTW, are doing this on a volunteer basis). > > > I appreciate the volunteer point. However, a project in disarray is a > > project in disarray whether volunteer or not. Well, remember I only arrived here in the past two weeks. What I've seen has not been reassuring. > > Two weeks of disarray versus 5 years of soloid performance. You'd think a > couple of weeks of temporary pain wouldn't be a big deal. > > > PG isn't perfect - we all know that. Nor is the project administration. > > When there's a problem identified, someone has to take responsibility for > > fixing it, and someone has to ensure the person reporting the problem has a > > way forward. > > And the problem is being addressed. Patience is a good watchword. It's hard to believe there's a serious effort being made to fix a problem when all the effort I can see has no apparent relationship to the problem. > > "Lighten up" isn't the right response. Examine your project. See what > > points I make have merit. Welcome criticism. You don't have to like the > > message you know;-) > > No, I don't have to like the message. But the message can be phrased in a > more polite way, as has been pointed out. You were just being a little too > _serious_ about it, that's all. Give it a week or two, and things will be I don't think I was being rude. It's true I'm no diplomat. I've criticised actions (and, I think, with considerable justice), but I've not actually criticised people. We all make mistakes, we should all be ready for them to be pointed out. > OK. The issues are in Vince and Marc's very capable hands -- but, as Marc > said, this stuff has lived in the same place for >5 years -- and lots of > interdependencies had to be addressed. And they _are_being addressed. And my point is that something moved. Something that many people (I don't know how many, but thousands wouldn't surprise me) depended on. I have over thirty years' experience in computing, many of them supporting users. That experiece tells me that making a change that inconveniences users is a mistake. If the change really must be made, do it so as to reduce the inconvenience as far as possible. From my other readinds I see that the PG team controls the entire disk layout. Given that, I can see no reason that the CVS tree needed to be changed in the way it was. I still think it should be made to work the old way; both ways, now, as there are people who depend on both structures.
On Thu, 4 Oct 2001, Stephan Szabo wrote: > of the message this was in response to which appears to be what Lamar was > responding to. Besides, there's a far cry from a message of constructive > criticism and the message this was in response to. The point that the > documentation and reality need to match up is a good one, but saying > that "It's wrong because it's different from what worked before" isn't > reasonable. Saying, "This change is unfortunate and did it really have > to happen and why? And the documentation and the server realities really > have to match up. Perhaps changing the page first with a note of both > configurations with an estimated time change for the server would have > been better/the right way to do this" is reasonable. > How many people use anonymouse CVS? Hundreds? Thousands? Tens of thousands? You must have been fixing a pretty serious problem to justify inconveniencing them all. And if it really is that serious, add a word of explanation (to forestall problem reports) and apology. That is the point of my complaint. If it was just me, I'd shrug my shoulders and (once I figured out how) get on with it.
On Fri, 5 Oct 2001, John Summerfield wrote: > I don't think I was being rude. It's true I'm no diplomat. I've > criticised actions (and, I think, with considerable justice), but I've > not actually criticised people. How can your criticisms be 'with considerable justice' (justification?) when you have no more then 2 weeks knowledge of the project and/or the ppl involved in it? For starters, this 'move' has been going on for more then 2 weeks now, and this last phase has been the one withthe most hiccups, as its also been the one with the most ppl affected ... > And my point is that something moved. Something that many people (I > don't know how many, but thousands wouldn't surprise me) depended on. I'd be surprised if most of what moved affected hundreds ... > I have over thirty years' experience in computing, many of them > supporting users. That experiece tells me that making a change that > inconveniences users is a mistake. If the change really must be made, > do it so as to reduce the inconvenience as far as possible. As you have only been here 2 weeks, what do you know about what did (or didn't) need to be done? Or about the work that went into making the whole change as painless as possible? CVS was the most painful, and there were forewarnings about it, to the extent that we made sure that those with changes to commit weren't affected before they changed ... "End users", IMHO, it should have been totally irrelevant too ... remove and re-check out the tree ... but, then again, I believe it was PeterE that even posted a 'how to change your CVS to point to the new server' script, so that those users weren't inconvience as well ... if you are going to play with CVS, then deal with problems that *will* arise as a result of it ... else, download the .tar.gz files like everyone else ... > From my other readinds I see that the PG team controls the entire disk > layout. Given that, I can see no reason that the CVS tree needed to be > changed in the way it was. well, for one, its easier to remember: /cvsroot then /home/projects/pgsql/cvsroot
On Fri, 5 Oct 2001, John Summerfield wrote: > On Thu, 4 Oct 2001, Stephan Szabo wrote: > > > > of the message this was in response to which appears to be what Lamar was > > responding to. Besides, there's a far cry from a message of constructive > > criticism and the message this was in response to. The point that the > > documentation and reality need to match up is a good one, but saying > > that "It's wrong because it's different from what worked before" isn't > > reasonable. Saying, "This change is unfortunate and did it really have > > to happen and why? And the documentation and the server realities really > > have to match up. Perhaps changing the page first with a note of both > > configurations with an estimated time change for the server would have > > been better/the right way to do this" is reasonable. > > > > How many people use anonymouse CVS? Hundreds? Thousands? Tens of thousands? Hundreds, maybe ... > You must have been fixing a pretty serious problem to justify > inconveniencing them all. And if it really is that serious, add a word > of explanation (to forestall problem reports) and apology. Ummm, all of these changes and moves were forewarned ... obvious that was before you came on the scene with your "in a perfect world" assessments ... > That is the point of my complaint. If it was just me, I'd shrug my > shoulders and (once I figured out how) get on with it. Obviously it is/was only you, cause nobody else appear to give two shakes ...
On Thursday 04 October 2001 09:40 pm, John Summerfield wrote: > Well, remember I only arrived here in the past two weeks. What I've seen > has not been reassuring. May I be so bold as to suggest your taking a few hours of your time and reading the last six months to a year of the list's archives? :-) I did just that a little over two years ago when I (somewhat rudely, I may add) grabbed the RPM bull by the specfile horns -- I read the previous two years of archives to get a feel for the culture of the group first. As I can read 1200-1600 words per minute, I'm able to process 10-15k messages per day easily. (My daily load is right now around 1k messages per day, along with all my other broadcast engineering related work). 1k messages takes a little over half an hour. > It's hard to believe there's a serious effort being made to fix a problem > when all the effort I can see has no apparent relationship to the problem. The interdependencies run deep into areas that appear unrelated to the problem at hand. > I don't think I was being rude. It's true I'm no diplomat. I've criticised > actions (and, I think, with considerable justice), but I've not actually > criticised people. 'You'd better get your act together fellas' was just a tad too critical for my taste, sorry. I'm not known for being a diplomat either.... I've seen real flamewars, too, and your message was certainly not a flame, but just a tad too critical. Had I considered it a flame I wouldn't have bothered replying. > And my point is that something moved. Something that many people (I don't > know how many, but thousands wouldn't surprise me) depended on. > That experiece tells me that making a change that inconveniences > users is a mistake. Too much backwards compatibility is also a mistake. If a person is tracking the bleeding-edge CVS, they are already having to watch for initdb-forcing changes -- a CVSROOT change is small potatoes compared to an initdb-force -- which happens _often_ during the development cycle. There are other major changes that happen -- to the point where a fresh checkout might even be necessary, so that leftover files from previous local builds aren't present. That's just a part of using CVS, in my experience. And this is not the only open source project that has changed CVSROOT on people -- in fact, this one has changed less than any of the other projects that I track with CVS. Just a momentary pain, really. > From my other readinds I see that the PG team controls the entire disk > layout. Given that, I can see no reason that the CVS tree needed to be > changed in the way it was. Correction: Marc Fournier controls the entire disk layout, as it's his server. It was his decision to change the layout. > I still think it should be made to work the old way; both ways, now, as > there are people who depend on both structures. All you have to do to use the new layout is to blow away your checkout, login again with the new layout, and run another checkout. It doesn't take long to do. And it is now documented again, AFAIK. It's a little more complicated for CVSup users, though. And that's where Thomas (our resident rocket scientist) had his beef, along with the documentation build process, etc. When docs build automatically, and you change the source document to reflect a change, but the build fails due to that very layout change, it can get pretty ugly. And that's exactly what happened, from my perspective. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On Fri, 5 Oct 2001, Lamar Owen wrote: > On Thursday 04 October 2001 09:40 pm, John Summerfield wrote: > > Well, remember I only arrived here in the past two weeks. What I've seen > > has not been reassuring. > > May I be so bold as to suggest your taking a few hours of your time and > reading the last six months to a year of the list's archives? :-) I'm on several PG lists (and many others). I do entirely enough reading already. And I don't read as quickly as you do. > > > It's hard to believe there's a serious effort being made to fix a problem > > when all the effort I can see has no apparent relationship to the problem. > > The interdependencies run deep into areas that appear unrelated to the > problem at hand. > > > I don't think I was being rude. It's true I'm no diplomat. I've criticised > > actions (and, I think, with considerable justice), but I've not actually > > criticised people. > > 'You'd better get your act together fellas' was just a tad too critical for > my taste, sorry. I'm not known for being a diplomat either.... I've seen > real flamewars, too, and your message was certainly not a flame, but just a > tad too critical. Had I considered it a flame I wouldn't have bothered > replying. I made it clear I was getting frustrated. Read in that context, I think it was pretty mild;-) Especially considering the point I saw a project in disarray (and I don't think anyone's disputed that). > > And my point is that something moved. Something that many people (I don't > > know how many, but thousands wouldn't surprise me) depended on. > > > That experiece tells me that making a change that inconveniences > > users is a mistake. > > Too much backwards compatibility is also a mistake. If a person is tracking > the bleeding-edge CVS, they are already having to watch for initdb-forcing > changes -- a CVSROOT change is small potatoes compared to an initdb-force -- > which happens _often_ during the development cycle. There are other major > changes that happen -- to the point where a fresh checkout might even be > necessary, so that leftover files from previous local builds aren't present. > That's just a part of using CVS, in my experience. I'm prepared for the project itself breaking my data - that I expect is likely to happen. Each time I do a CVS update, I rebuild my binaries and database. > > And this is not the only open source project that has changed CVSROOT on > people -- in fact, this one has changed less than any of the other projects I'm ingnorant. I don't see why CVSROOT would need to be changed. I thought Unix filesystems were flexible enough to allow CVS to see things as they really aren't, perhaps using symlinks. And if one project does change it, I still don't see how that justifies another. > that I track with CVS. > > Just a momentary pain, really. From what I can tell, completely unnecessary. And until somone explains why itwas necessary, then I won't understand it. > > > From my other readinds I see that the PG team controls the entire disk > > layout. Given that, I can see no reason that the CVS tree needed to be > > changed in the way it was. > > Correction: Marc Fournier controls the entire disk layout, as it's his > server. It was his decision to change the layout. Is Marc part of the team? > > > I still think it should be made to work the old way; both ways, now, as > > there are people who depend on both structures. > > All you have to do to use the new layout is to blow away your checkout, login > again with the new layout, and run another checkout. It doesn't take long to > do. And it is now documented again, AFAIK. And this is the first time someone has bothered to tell me, and it's weeks since the problemarose and I reported it (I hadfigured it out and got a new checkout). Instead of telling me how to go on with my affairs, there ensured a discussion about the documentation being wrong, about the devlopers corner shouldn't really be there and so on. And replies to my problems enroling in these lists were no more helpful. I wanted to get on the list because I felt I wasn't seeing all the relevant discussion of other problems, and in particular what was broken wrt CVS. Now, I've always thought that the first thing to do when someone has a problem is to give them the solution to their problem if the solution is easily had. In those two cases it would have taken someone a minute or two to say, Sorry 'bout that. Do this.' To be sure if the Postgresql itself is broken, that may take longer, but that wasn't the case. The procedures (from my point of view) or documentation (from yours) was wrong, and what I needed most was the knowledge of what actually works. And referring me to the incorrect documentation didn't serve to persuade me the project's running well.
On Fri, 5 Oct 2001, Marc G. Fournier wrote: > On Fri, 5 Oct 2001, John Summerfield wrote: > > > I don't think I was being rude. It's true I'm no diplomat. I've > > criticised actions (and, I think, with considerable justice), but I've > > not actually criticised people. > > How can your criticisms be 'with considerable justice' (justification?) I think my comments to another go to address this. The short form is that the particular problems I had required all of two minutes to fix by telling me the solution. When I get pointed to the same wrong documents I've allready read, then I think I' well justified in concluding that there's something wrong and saying so. > > > And my point is that something moved. Something that many people (I > > don't know how many, but thousands wouldn't surprise me) depended on. > > I'd be surprised if most of what moved affected hundreds ... What I can surmise of the scale of your operation suggests its likely. > > I have over thirty years' experience in computing, many of them > > supporting users. That experiece tells me that making a change that > > inconveniences users is a mistake. If the change really must be made, > > do it so as to reduce the inconvenience as far as possible. > > As you have only been here 2 weeks, what do you know about what did (or > didn't) need to be done? Or about the work that went into making the > whole change as painless as possible? CVS was the most painful, and there > were forewarnings about it, to the extent that we made sure that those > with changes to commit weren't affected before they changed ... Forwarning didn't help those arriving at the wrong time. Getting on to the lists didn't work as described, so don't use that as an excuse. My major concern is not so much the changes that were made, but that the problems that arose were not addressed properly. > > "End users", IMHO, it should have been totally irrelevant too ... remove > and re-check out the tree ... but, then again, I believe it was PeterE > that even posted a 'how to change your CVS to point to the new server' > script, so that those users weren't inconvience as well ... He might have, but not anywhere that I could find it. > > if you are going to play with CVS, then deal with problems that *will* > arise as a result of it ... else, download the .tar.gz files like everyone > else ... > > > From my other readinds I see that the PG team controls the entire disk > > layout. Given that, I can see no reason that the CVS tree needed to be > > changed in the way it was. > > well, for one, its easier to remember: > > /cvsroot > > then > > /home/projects/pgsql/cvsroot ln -s /home/projects/pgsql/cvsroot /cvsroot Nobody even took the time to tell me what it had changed to. I can live with the change if I have to, but first it's essential to have current information, and nobody took (in over two weeks) the time to ensure I had that information. Now I don't know why individuals get involved in OSS projects or how they get their rewards, but I'd guess that having happy users is part of it. And users need support, and those who use the CVS repositiories you should especially welcome as they're (or so I imagine) prospective new team members.. What I'm complaining about is neither helpful nor welcoming. Now there have been exceptions - I've also had some very good responses to other problems.
On Friday 05 October 2001 07:48 pm, John Summerfield wrote: > On Fri, 5 Oct 2001, Lamar Owen wrote: > I made it clear I was getting frustrated. Read in that context, I think it > was pretty mild;-) But it was done in an uninformed way. Had you read the previous two-three weeks of the archives, your questions mostly would have been answered. And I think that's the thing that irritated me -- at least try to understand what the culture of the project is before criticizing it. I am reminded of Tom Lane's first post....(it's in the archives....) > Especially considering the point I saw a project in disarray (and I don't > think anyone's disputed that). Temporary disarray only. But this project is a truly open project, where no one person has final say. People will occassionally get upset and disagree -- this is normal life in a true open source project. People here tend to disagree in a much more mild way that with some other projects, though. > I'm ingnorant. I don't see why CVSROOT would need to be changed. I thought > Unix filesystems were flexible enough to allow CVS to see things as they > really aren't, perhaps using symlinks. Why introduce additional complexity into an already complex system? The next time things need to be shuffled (in a few weeks, months, or years), having to remember to un-dangle a symlink might cause another issue. The new CVSROOT is shorter and simpler, and it is useless to mung in an unnecessary symlink. PeterE had just posted how to get around it without a new checkout -- a cursory half-hour browse through the last month's archives would have found it. > > Correction: Marc Fournier controls the entire disk layout, as it's his > > server. It was his decision to change the layout. > Is Marc part of the team? Reference the developers listing on developer.postgresql.org. > Instead of telling me how to go on with my affairs, there ensured a > discussion about the documentation being wrong, about the devlopers corner > shouldn't really be there and so on. Because your report was a symptom of a larger problem -- that of the automatically generated pages not generating properly. Fix the cause, not the symptom. > Now, I've always thought that the first thing to do when someone has a > problem is to give them the solution to their problem if the solution is > easily had. The first thing that has to be done is to find the real problem. You may not even know what the real problem is -- if CVS hadn't broken, something else would have pointed out that the docs we're being autogenerated any more. And a temporary fix for a symptom is not nearly as useful as is a cure for the real problem. Once the problem has been found and fixed, the symptom will go away. > To be sure if the Postgresql itself is broken, that may take longer, but > that wasn't the case. The procedures (from my point of view) or > documentation (from yours) was wrong, and what I needed most was the > knowledge of what actually works. > And referring me to the incorrect documentation didn't serve to persuade me > the project's running well. If the documentation build procedure was broken (which it was), telling you the correct incantation would have only fixed your individual problem. Attempting to fix the doc build process, with your help in saying 'Yes, that fixed it' or 'no that didn't' helps the whole userbase, not just you. PostgreSQL's online documentation is derived from the very same SGML source documentation that ships with the tarball -- to prevent duplication of effort. As the autogen system has been in place for awhile, when a change in the SGML source didn't propagate to the web pages, that problem had to be found before it could be fixed. In the process a few feathers got ruffled, but things are ok as of now, AFAIK. Again, it's been a kindof rocky two-three weeks --but this is momentary. But you have to have context to see its momentary nature -- and only by reading the archives can you obtain proper context. As to why things had to change, well, Marc is the person to answer that. But, really, he is under no obligation to answer that, as he's providing his servers and bandwidth to this project. They're his, and he can run them as he sees fit. If he wants to justify his actions, then that's ok. If he doesn't want to justify those actions, well, I can't really have a problem with that either -- I'm not the one forking out the money for his bandwidth. I'm too busy being thankful that he is taking the time and pouring out the effort to keep things running. And things typically have run very well over the last five-plus years that Marc has hosted the project. After all,` he basically rescued the whole thing. But that's context..... And speaking of context, even in my extra-busy state of the last three months, I was able to follow what was going on, and prepared for it here. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On Mon, 8 Oct 2001, Lamar Owen wrote: > On Friday 05 October 2001 07:48 pm, John Summerfield wrote: > > On Fri, 5 Oct 2001, Lamar Owen wrote: > > I made it clear I was getting frustrated. Read in that context, I think it > > was pretty mild;-) > > But it was done in an uninformed way. Had you read the previous two-three > weeks of the archives, your questions mostly would have been answered. And I > think that's the thing that irritated me -- at least try to understand what > the culture of the project is before criticizing it. I am reminded of Tom > Lane's first post....(it's in the archives....) I've spend years helping people (for free, just like you people here), first with OS/2 and then with Linux, specificallyRed Hat. I understand and accept that many questions are asked over and over. Where possible I have referred people to existing documentation, often with a shortened explanation. Often I illustrate answers with clippings from a terminal window. If I can't test an answer, I give a clue that it's untested. > > > Especially considering the point I saw a project in disarray (and I don't > > think anyone's disputed that). > > Temporary disarray only. But this project is a truly open project, where no > one person has final say. People will occassionally get upset and disagree > -- this is normal life in a true open source project. People here tend to > disagree in a much more mild way that with some other projects, though. > > > I'm ingnorant. I don't see why CVSROOT would need to be changed. I thought > > Unix filesystems were flexible enough to allow CVS to see things as they > > really aren't, perhaps using symlinks. > > Why introduce additional complexity into an already complex system? The next Someone said it had been the old way for five years. It caused me no inconveniece - I simply copied and pasted the lengthy name from the web page. I don't see for whom the long name would be a problem; certainly if it has been that way for five years, it couldn't have been a serious problem. > time things need to be shuffled (in a few weeks, months, or years), having to > remember to un-dangle a symlink might cause another issue. The new CVSROOT > is shorter and simpler, and it is useless to mung in an unnecessary symlink. > PeterE had just posted how to get around it without a new checkout -- a > cursory half-hour browse through the last month's archives would have found > it. The symlink could be used the other way - leave CVSROOT alone so it works the way it 'always has,' create the symlink as a convenience for whoever wants it. > > > > Correction: Marc Fournier controls the entire disk layout, as it's his > > > server. It was his decision to change the layout. > > > Is Marc part of the team? > > Reference the developers listing on developer.postgresql.org. yes or no? I don't have web access at present. He contributes to discussions, so I guess in at least some sense he is. > > > Instead of telling me how to go on with my affairs, there ensured a > > discussion about the documentation being wrong, about the devlopers corner > > shouldn't really be there and so on. > > Because your report was a symptom of a larger problem -- that of the > automatically generated pages not generating properly. Fix the cause, not > the symptom. > > > Now, I've always thought that the first thing to do when someone has a > > problem is to give them the solution to their problem if the solution is > > easily had. > > The first thing that has to be done is to find the real problem. You may not > even know what the real problem is -- if CVS hadn't broken, something else > would have pointed out that the docs we're being autogenerated any more. And > a temporary fix for a symptom is not nearly as useful as is a cure for the > real problem. Once the problem has been found and fixed, the symptom will go > away. No reason at all to make people wait for thich incantation. Someone had the correct information. Probably a minute to find it and incorproate it in a response. > > > To be sure if the Postgresql itself is broken, that may take longer, but > > that wasn't the case. The procedures (from my point of view) or > > documentation (from yours) was wrong, and what I needed most was the > > knowledge of what actually works. > > > And referring me to the incorrect documentation didn't serve to persuade me > > the project's running well. > > If the documentation build procedure was broken (which it was), telling you > the correct incantation would have only fixed your individual problem. Fix my problem so I can go on looking for more. Then fix the real problem. I went to the CVS version because I had problems with the most recent release. I try not to report fixed problems. However, I do need reasonable support from the developers, and I was only seeking a a modest amount of support. > Attempting to fix the doc build process, with your help in saying 'Yes, that > fixed it' or 'no that didn't' helps the whole userbase, not just you. Anyone can verify that the page I mentioned contains correct (or incorrect) information. Doesn't need a say-so from me. > > PostgreSQL's online documentation is derived from the very same SGML source > documentation that ships with the tarball -- to prevent duplication of > effort. As the autogen system has been in place for awhile, when a change in > the SGML source didn't propagate to the web pages, that problem had to be > found before it could be fixed. In the process a few feathers got ruffled, > but things are ok as of now, AFAIK. > > Again, it's been a kindof rocky two-three weeks --but this is momentary. But > you have to have context to see its momentary nature -- and only by reading > the archives can you obtain proper context. I don't ordinarily have web access. Archives are inconvenient. And, in my experience, somewhat hard to use. It can be hard to find a specific topic - too many synomyms - and often they're too voluminous, and unless you have a high-bandwidth service (I don't) slow.
On Monday 08 October 2001 09:37 pm, John Summerfield wrote: > I don't see for whom the long name would be a problem; certainly if > it has been that way for five years, it couldn't have been a serious > problem. Ask Marc why he changed it. > > > > Correction: Marc Fournier controls the entire disk layout, as it's > > > > his server. It was his decision to change the layout. > > > Is Marc part of the team? > > Reference the developers listing on developer.postgresql.org. > yes or no? I don't have web access at present. He contributes to > discussions, so I guess in at least some sense he is. He is one of the six core developers; maintains the postgresql.org server (which he donates); maintains the network bandwidth which we all enjoy; coordinates releases; runs the mailing list, ftp, web, CVS, CVSup, and nesgroup services; is President of PostgreSQL, Inc, who provides first-rate commercial support for PostgreSQL; is chief cook and bottlewasher; and anything else I may have left out. He is one of the first four who took the also-ran Postgres95 and turned it into the real database known as PostgreSQL. So, yes, I guess you could say he's part of the team... :-) > > > Instead of telling me how to go on with my affairs, there ensured a > > > discussion about the documentation being wrong, about the devlopers > > > corner shouldn't really be there and so on. > > Because your report was a symptom of a larger problem -- that of the > > automatically generated pages not generating properly. Fix the cause, > > not the symptom. > No reason at all to make people wait for thich incantation. Someone had the > correct information. Probably a minute to find it and incorproate it > in a response. Did you or did you not post the question to pgsql-hackers? This list isn't for just telling people how to solve problems -- that is what admin, general, ports, etc are for. The hackers list is the developers list, where the developers talk through development problems. So, directly answering your question wasn't the top priority -- fixing the larger problem was. > However, I do need reasonable support from the developers, and I was only > seeking a a modest amount of support. If you're going to run CVS or even beta versions, you had better be ready to do alot of your own support. I'm not trying to be mean or arrogant, either -- if a change in CVSROOT and a lack of docs is too upsetting, wait on the final release, or a release candidate, where things are much more polished. Bleeding edge sometimes cuts -- and I've been there. > I don't ordinarily have web access. Archives are inconvenient. And, in > my experience, somewhat hard to use. It can be hard to find a specific > topic - too many synomyms - and often they're too voluminous, and unless > you have a high-bandwidth service (I don't) slow. I can sympathize to an extent with that, but I again have to go back to what irked me -- you made an uninformed critical remark that had nothing to do with your question. Don't make critical remarks about a process or project of which workings you are ignorant. That isn't meant to be demeaning -- I try to follow that very same advice, as it was given to me long ago by none other than Jonathan Kamens. And it takes more than just a couple of weeks reading the list to get familiar with the workingsof a project this size. That's really all I have to say about that on-list. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11