[SM-Discuss] SCM perforce replacement was: Re: Grimoire Team Lead vote
Jeremy Blosser (emrys)
jblosser-smgl at firinn.org
Tue Mar 14 17:40:15 EST 2006
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:
> Mathieu L. wrote:
> > Ok, here's an additional question for both our candidates:
> > I'd like to know if getting rid of perforce is one of your priorities
> > and if yes, what are your plans about that.
> Hi Mathieu,
> It is definitely a priority for me. But, we have, as a group, talked
> about what to change to, but the "powerful enough" alternatives have
> only recently begun to stabilize. As to what to switch to, since there
> are so many "near ready" options, we should tread carefully and 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.
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 think the people who want to see perforce go should be prepared to
> offer assistance to do this. The last thing I would want is to have
> expert SMGL developers getting bogged down in implementing a change in
> SCM that could otherwise be spent improving the deliverables. In the
> past when the discussion has come up, some people have made statements
> about what they *don't* want (e.g. perforce) and then have dropped away.
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, 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.
As such, I'm very prepared to help with any real transition work that needs
to happen, including any glue that needs to be added to other systems to
make them more supportive of our existing workflow. I know some people
don't like that idea, but IMO it's much better to have a system that
supports our developer's ideals and extend that a bit via the Unix approach
vs. something that creates a bar to entry. I know those that like p4 don't
see this as a high bar to entry. Regardless, our distro is not about p4,
and this shouldn't have to even be an issue for prospective devs, but it
> Some people may say, "but switching's easy!" It's not. We need people
> to write up conversion scripts between the different scms to keep our
> history intact. We need scripts written and offered to developers on
> how to switch that is tested and error free. We need testing of any
> proposal to see if it's feasable, perhaps by running a few well-chosen
> alternatives in parallel with perforce and seeing if there are
> performance problems or feature holes. Free and Open Source software is
> based on participatory meritocracy -- nothing gets done without doing
> something about what you don't like (one has to, at times, sratch their
> own itches ;) ).
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
> The existing developers have a lot on their plates. Who wants to
> volunteer to do this? What I expect out of the Grimoire Lead is
> somebody who will accept this move, but doesn't necessarily do it all
> themselves. I think both Arwed and I meet that expectation. :)
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.
> That being said, a number of developers have been, in their spare time,
> looking at SCMs. Consensus hasn't developed yet, and I expect more time
> is needed for everybody to do that (and even for some products to
> improve). If we had some more help, maybe we would have enough
> person-hours to complete this task sooner than if we were all on our
> own. Since we are talking about replacing the collaboration tool that
> handles all the code, the very essence of our collaborative output, we
> need collaborative action and agreement on it.
> I think that covers all the permutations of my thoughts on that subject. ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 232 bytes
Desc: not available
Url : http://lists.ibiblio.org/pipermail/sm-discuss/attachments/20060314/40f75cad/attachment.bin
More information about the SM-Discuss