[SM-Discuss] SCM perforce replacement was: Re: Grimoire Team Lead vote

Seth Woolley swoolley at panasas.com
Tue Mar 14 18:31:42 EST 2006


Jeremy Blosser (emrys) wrote:
 > I'm going to continue this a bit in the interests of seeing if the
 > candidates differentiate themselves... hopefully it won't just derail 
 > into "the SCM argument".
 >
 > On Mar 14, Seth Woolley [swoolley at panasas.com] wrote:
<snip>
 > > select one that people can use easily, can compile with very little
 > > difficulty and error proneness, is stable, doesn't change archive/db
 > > formats/APIs frequently, is well-secured, and is free software.
 > > Perhaps one doesn't exist that meets those tentative criteria yet.
 >
 > I would add "uptime" to that list (or include it under "stable", 
which > to me first means "doesn't eat my code").  Specifically, I'd prefer
 > something we can get on our own servers and can have redundancy
 > around.  We're trying to do more of that in general after 
experiencing > non-trivial downtime. This has affected p4 as well, and 
we've lost
 > full weekends of dev access, though not very recently.

I of course meant to include uptime with stability.

 >
 > IMO this list is a good one, but of course different people 
prioritize > each thing differently.  The argument could be made that p4 
doesn't
 > meet all of these criteria as well as some other systems might, even
 > if it does do certain things more natively than those other systems.
 >

I consider uptime and availability (this includes its ability to 
failover or use redundancy) more important than its fancy features.  I 
can work with almost any code manager, even if it has no integration 
support.  History is nice to have but we do our own manually already. 
The main "feature" (outside stability/redundancy issues) I consider 
critical to have is the ability to see code in previous points in time 
for easier debugging.  Everything else is pretty fancy to me.

<snip>
 >
 > This is an important issue to me both because of the philosophical
 > issue, the stability issue, and the developer appeal issue.  I know 
we > have several developers who aren't happy we use p4,

Yep, not very many of us are, mainly due to the single point of failure, 
that it's proprietary, that it's not been stable for us, and (one thing 
I have noticed) old clients sometimes cause issues (so it's important to 
keep the p4 client binary updated).

 > regardless of the
 > functionality, and I know several others who don't contribute to the
 > project as they might otherwise because we use a SCM they don't care
 > to pick up, for various reasons.
 >

The more aware leaders are of this effect, the more likely they are to 
move on it.  If people don't want to reveal names, people can let Eric 
know privately of a rough count, so we can get an idea of how widespread 
the effect might be.

<snip>
 >
 > WRT to the topic at hand (Grimoire Lead election), I guess the
 > question becomes how much initiative the candidates would support in
 > this direction, and if seeing it happen is enough of a priority 
you'll > push it yourself vs waiting to see what others come back with. 
  There > have been some small efforts to get some things on other 
systems, but > as with other things we don't have enough people to go 
all out.  We
 > don't have a few dozen active developers to run that many systems in
 > parallel and have meaningful performance comparisons, that doesn't
 > mean we shouldn't try to work on this.
 >

I suggest that only for systems that would have some movement around 
them.  I was envisioning the case of a number of people who volunteer to 
help who are proactively advocating a particular platform.  If that were 
to happen, then we'd probably want to give them due process of 
evaluation first (especially if they were consistent developers).

<snip>
 >
 > How do *you* prioritize the various things listed above?  And how do
 > you prioritize this question vs. other things in front of the 
Grimoire > Team? The SCM issue is one for the whole project, not just 
any team,
 > but the most affected team(s) definitely need to be behind anything
 > that goes on.

Stability of the Grimoire will always be more important than which SCM 
to use, to me.  I can see myself devoting some time to the SCM issue if 
I see some actual action from others to help.  Personally, the critical 
mass is nice to have before anything systematic like this is done. 
Typically when I start on a project, and actually start on it, I like to 
finish it, so if I do get into the state of "hey, we're switching", 
you'd likely see it done sooner rather than later.  If nobody cared 
which one and just wanted to switch away from p4, I could have it done 
in a week, avoiding the evaluation projects.  Of course, I might pick an 
old standby that nobody 31337 [elite] likes, like cvs. ;)

Seth

-- 
Seth Alan Woolley
Software Engineer
Accelerating Time to Results(TM) with Clustered Storage

www.panasas.com
swoolley at panasas.com
510-608-4382



More information about the SM-Discuss mailing list