[nycbug-talk] Request for Review, Summary of FreeBSD src fetching problems

[Isaac (.ike) Levy]

On Jan 27, 2013, at 5:51 PM, Glen Barber wrote:
> On Sun, Jan 27, 2013 at 02:57:31PM -0500, Isaac Levy wrote:
>> Hi All,
>> 
>> To continue to weed through all the noise, on the hot 'at the
>> bar' topic:
>> "Wny is my tool for src fetching, nearly as big as my base Operating
>> System all the sudden?"
>> 
>> I've posted what I can glean as the current state of things, I'm
>> trying to centralize my notes on this topic, here:
>> 
>>  https://wiki.freebsd.org/UsersFetchingSource#preview
>> 
>> Please feel to make edits (esp. if you are a committer and know
>> something I don't!), or email me with corrections and I'll put them
>> in!
>> 
> 
> I do have a comment about the "Why is this a big deal?" section.
> 
> Why is changing the primary source control software such a big deal?
> Truthfully, I do not know the one-size-fits-all answer.  I wish it was
> not, however, because it is consuming far too many cycles and far too
> much time for something that is inevitable.

I just added additional commentary inspired by your post here,

> The warning signs have been there for years.  All FreeBSD src/ commits
> go into subversion since its inception.  The availability of the changes
> through cvs/cvsup/csup happens as a result of a svn->cvs exporter.
> 
> And therein, in my opinion, is what is making this such a big deal.  The
> exporter has run for far too long.  It is buggy at best.  It often
> crashes when files are replaced.  

Thanks for this peek behind the curtain, this makes sense-

> Most importantly, and this is the part
> that bothers me so much about this ongoing topic, it is not secure.

This is game-changing for my attitude.  Neglected systems are dangerous systems.

> 
> The way I see it, speaking "unofficially", the cvs exporter was provided
> as a service to provide time for users to convert their systems to the
> new source control system, or to choose an alternative way to obtain the
> sources (freebsd-update(8), for example).
> 
> This service was far from free (as in time).  Taking into account the
> aforementioned crashes, in addition to maintenance, keeping two methods
> for obtaining the src/ tree available is expensive.  Additionally, when
> a RELENG_N branch is created, manual intervention is needed on the cvs
> side.  It is extremely costly.

As an admin, I can absolutely appreciate the cost of "just another service".

> Now, consider any other software project.  
> If "foo" decides to switch
> from cvs to svn, or cvs to git, or git to svn, or whatever, I can
> guarantee two things:
> 
> 1.) They will not attempt to put in the effort to make the "old
>   system" available.
> 2.) There very likely would not be as much talk about the topic as
>   there has been for FreeBSD changing source control software.

Both true, but not many other software projects are:
- 20+ years old
- have such stable systems
  (There are 4.x boxes still alive and kicking doing meaningful work)

These aspects set expectations for the speed of change, and communication/notice about changes.

Quite seriously, my head is churning on how to keep users (like NYC*BUG users) right out on the forefront for changes- so these problems aren't so disruptive. I'd rather have been aware just how serious cvs changes were back in 2010, (at least I'm upset with myself not to have been paying attention).
However, it seems like I'm not a special case- and that a *lot* of users haven't been prepared enough.

So here we are :)

> So, having said all that, here is why I think this is such a big, time
> consuming topic:  Until recently, the ports/ and doc/ repositories were
> still developed within CVS.  With the cvs exporter for src/, users had
> no real reason to switch.
> 
> Not moving ports/ and doc/ from cvs to svn sooner, in my opinion, is the
> only mistake FreeBSD made.  But again, the warning signs were there all
> along.
> 
> Glen

Change is not easy, I see what you've got on your hands there!

--
Is there any clear path that you know of to end-of-life the src cvsup?

It seems the work that popped up on stable@ this week is a real ray of hope to just seal it all off clean, a (a lightweight, in-base svn fetcher).

Anywhere you can think of where we can be watching, for changes upstream?

Best,
.ike