GSoC folks, read this: (Re: Lightweight copies/renames)
pmalmsten at gmail.com
Mon Apr 5 10:41:47 CDT 2010
Thank you for the advice! I will keep that in mind.
On Sat, Apr 3, 2010 at 2:47 PM, Matt Mackall <mpm at selenic.com> wrote:
> On Sat, 2010-04-03 at 10:53 -0400, Paul Malmsten wrote:
> > Hi Matt,
> [forwarded back to the list]
> > I am considering applying to the Mercurial project for Google's Summer
> > of Code program, and I'm looking for more information about the posted
> > projects to determine which would be a good fit for me. To this end, I
> > have a few questions about the lightweight copies/renames project, and
> > I learned from the mailing list that you would be the person to ask.
> > * Which skills do you think should be brought to the project in
> > order to make considerable progress?
> The real challenge of GSoC is not coding, it's learning to work with a
> community. And the first lesson is: communicate in public. I'm sorry
> that I didn't see your first message, but I rarely answer private
> correspondence about Mercurial. If I did, I'd spend my entire life
> repeating myself and never get any work done.
> The next big challenge is: work in public (you might begin to see a
> theme here). Lots of programmers have a tendency to go off in a corner
> and code until they think they've found what they think is the complete
> solution. That's one of the best ways to fail at GSoC, because odds are
> good you'll have overlooked some important issue and we'll send you back
> to the drawing board. Alternately, you'll go off in the wrong direction
> and never be able to finish. Instead, divide your project into small,
> manageable parts and get feedback on each of them along the way.
> And finally: be part of the community. The tendency for GSoC students
> has been to work on their own projects and talk to no one but their
> mentor. That's completely missing the interesting parts of the open
> source experience.
> So this year, I'm hoping that students will actually engage with all
> facets of the community. That means following both lists, reading
> patches from other contributors, hanging out on IRC, responding to stuff
> on the BTS, and engaging in things other than just your project,
> including helping users. Plan on spending as much as half your time
> doing these things.
> Students who learn how to do this will learn a lot more valuable skills
> and will be more successful than those who go off in a corner to code.
> To help encourage this, this year we're going to pair students with
> mentors who aren't experts in the project area so students don't have
> any shortcuts around the community to getting help or getting their code
> > * What kinds of challenges can you foresee one encountering?
> Lightweight renames is known to be a hard problem. It involves touching
> code in several areas and maintaining backwards compatibility. You'll
> pretty much be forced to become a Mercurial expert. And you'll need to
> make sure you've got a good mental map of all the inter-related
> requirements before you get too far in. We've actually had fairly
> detailed discussions of what's involved here in the past and the biggest
> difficulty is in managing the wire protocol changes and coordinating
> with other developers who need protocol changes for their projects.
> Again, a big piece of this particular problem is not the code, it's
> coordinating with everyone else to understand what the code needs to do.
> > * Is this a feature frequently requested by the community?
> Absolutely. Whoever successfully completes this project will be many
> users' hero. And mine too - because if no one else does it, I'll
> eventually be forced to.
> http://selenic.com : development and support for Mercurial and Linux
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mercurial