[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