Re: cvs problem

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