GSoC folks, read this: (Re: Lightweight copies/renames)

[Paul Malmsten]

Thank you for the advice! I will keep that in mind.

Regards,
~Paul Malmsten


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
> reviewed.
>
> >       * 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...
URL: <http://selenic.com/pipermail/mercurial/attachments/20100405/85848d9f/attachment.htm>