Skip to Content.
Sympa Menu

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

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Seth Woolley <swoolley AT panasas.com>
  • To: "Jeremy Blosser (emrys)" <jblosser-smgl AT firinn.org>
  • Cc: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] SCM perforce replacement was: Re: Grimoire Team Lead vote
  • Date: Tue, 14 Mar 2006 15:31:42 -0800

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




Archive powered by MHonArc 2.6.24.

Top of Page