|
Size: 3005
Comment: Include a list of project ideas.
|
Size: 3417
Comment: bumped year
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| = Google Summer of Code 2008 = | #pragma section-numbers 2 = Google Summer of Code = |
| Line 3: | Line 4: |
| Mercurial is applying as a mentoring organization for the Summer of Code 2008. | Information about Mercurial's GSoC program. |
| Line 5: | Line 6: |
| == Project Ideas == | <<TableOfContents>> |
| Line 7: | Line 8: |
| Here are a bunch of project ideas you might like to apply for. Of course, if you have a different idea of something in Mercurial that badly needs fixing or some feature you think would make a difference, go ahead and apply with it! Some more project ideas can be found via NewFeatureDiscussions, CategoryNewFeatures and NewIdeas. | == About Mercurial and GSoC == |
| Line 9: | Line 10: |
| === Improved named branches === | For the last few years, Google has offered a fantastic opportunity for students to help out Open Source software projects in the summer while getting paid for it. It's called '''Google Summer of Code™''', and it provides free software projects a great way of attracting development effort while providing software developers who are still in university with some interesting and useful experiences. Find out more about the Summer of Code (SoC) from [[http://code.google.com/summerofcode.html|their site]]. |
| Line 11: | Line 12: |
| While Mercurial already somewhat supports having multiple actual branches in one repository, this support is perhaps less than polished. It would be nice, for example, if the web interface had better ways to expose the branches and if it became possible to explicitly close old branches. The named branch support really could use a lot of spit & polish. | Mercurial is a popular project with many enthusiastic users and a dynamic development community. By participating in GSoC with Mercurial, you'll be exposed to exciting technology and top-notch developers. |
| Line 13: | Line 14: |
| === Partial cloning === | <!> See [[SummerOfCode/Ideas2014|Ideas]] for project ideas and add yourself to [[SummerOfCode/2014|this year's status page]] to get involved. |
| Line 15: | Line 16: |
| Currently, it's only possible to clone one whole repository at a time. PartialClone and TrimmingHistory could help make cloning more efficient by limiting the cloning process in either of two dimensions: time or space. For time, we could maybe clone the last few changesets and lazily fetch the rest as needed. For space, it would be nice if it was possible to clone just a subtree of any repositories. For these features, any number of thorny issues can arise because of current assumptions in Mercurial code. | === Diversity === |
| Line 17: | Line 18: |
| === Lightweight copies/renames === | GSoC and open source development in general attracts a wide range of participants from around the world, but historically women have been very under-represented. So this year, Mercurial (and other projects under the Python umbrella) are actively encouraging more women to apply. Read more about Python's [[http://wiki.python.org/moin/DiversityInPython|diversity efforts]]. |
| Line 19: | Line 21: |
| Copies and renames currently copy all of the history from the old file to the new file, doubling the space used by that history in the process. It would be better if the code had some way of referring to the old history from the new file, so that the same on-disk file history is shared by the copies up to the point of copying. | == Notes on applying == |
| Line 21: | Line 23: |
| === Mercurial Queues improvements === | Here are some tips on how to apply: |
| Line 23: | Line 25: |
| Mercurial Queues (MqExtension) is a somewhat unique feature of Mercurial allowing a very flexible way of accumulating history before finally writing it to the actual changelog. Currently, it has a number of rough edges that sometimes cause problems when Mercurial is suddenly interrupted or when the user acts in unforeseen ways. Additionally, rebasing with MQ, while generally pretty easy, is a more elaborate process than it needs to be. It would be nice if MQ grew a little smarter about some of the common cases and a little more robust in the face of inexperienced users. | * Get acquainted! Introduce yourself on the [[MailingLists]] and talk to us on [[IRC]]. We're much more likely to accept applications from people we recognize. |
| Line 25: | Line 27: |
| === Repository forests === | * Get feedback on your proposal! We want to know all about you and your proposal before we have to choose between projects. |
| Line 27: | Line 29: |
| The ForestExtension implements a solution for repositories that want to include a number of subrepositories (similar to svn:externals). For large projects and because DVCS systems in general advocate smaller repositories, it can be helpful to implement a coherent set of repositories. The extension currently tries to do this, but it has proved to be less than intuitive and possibly not the best design. It would be good if Mercurial could incorporate an improved version of this extension. | * Submit a patch! We ask applicants to pick a simple issue from the [[BugTracker]] and [[ContributingChanges|send a patch for it]]. This will help demonstrate some of the basic skills you'll need for your summer project (using our tools, reading the code, talking to people, etc.). |
| Line 29: | Line 31: |
| == Mentors == | == Getting things done == |
| Line 31: | Line 33: |
| * PeterArrenbrecht * DirkjanOchtman |
The primary challenge of GSoC is not technical! Your goal as a GSoC student should be learning how to interact with other developers on a real-world project, and how to develop effectively in a cooperative environment. * Focus. Working on Mercurial in the summer should be your main activity. Realize that collaborating on software development takes time, and not just the time used to reason about and write the code. This also means that we want you to set some intermediate milestones to be able to keep track of your progress. * Communicate. In some ways, open source software development is more about communicating than about writing code. Some part of your time will be spent writing code, but a large part of the time spent will go towards explaining the code on mailing lists, asking and answering questions on IRC and in general reasoning about proposed software changes. If you can't do this, you take the risk of not understanding the goals of our project or not being able to explain why your patch is necessary. * Participate. Developing your own code is only part of the open source experience. You should also be getting involved with discussions on our mailing lists with users and developers, commenting on other code, responding to bug reports, editing the wiki, etc. |
| Line 34: | Line 42: |
| CategoryNewFeatures | CategoryGsoc |
Google Summer of Code
Information about Mercurial's GSoC program.
1. About Mercurial and GSoC
For the last few years, Google has offered a fantastic opportunity for students to help out Open Source software projects in the summer while getting paid for it. It's called Google Summer of Code™, and it provides free software projects a great way of attracting development effort while providing software developers who are still in university with some interesting and useful experiences. Find out more about the Summer of Code (SoC) from their site.
Mercurial is a popular project with many enthusiastic users and a dynamic development community. By participating in GSoC with Mercurial, you'll be exposed to exciting technology and top-notch developers.
See Ideas for project ideas and add yourself to this year's status page to get involved.
1.1. Diversity
GSoC and open source development in general attracts a wide range of participants from around the world, but historically women have been very under-represented. So this year, Mercurial (and other projects under the Python umbrella) are actively encouraging more women to apply. Read more about Python's diversity efforts.
2. Notes on applying
Here are some tips on how to apply:
Get acquainted! Introduce yourself on the MailingLists and talk to us on IRC. We're much more likely to accept applications from people we recognize.
- Get feedback on your proposal! We want to know all about you and your proposal before we have to choose between projects.
Submit a patch! We ask applicants to pick a simple issue from the BugTracker and send a patch for it. This will help demonstrate some of the basic skills you'll need for your summer project (using our tools, reading the code, talking to people, etc.).
3. Getting things done
The primary challenge of GSoC is not technical! Your goal as a GSoC student should be learning how to interact with other developers on a real-world project, and how to develop effectively in a cooperative environment.
- Focus. Working on Mercurial in the summer should be your main activity. Realize that collaborating on software development takes time, and not just the time used to reason about and write the code. This also means that we want you to set some intermediate milestones to be able to keep track of your progress.
- Communicate. In some ways, open source software development is more about communicating than about writing code. Some part of your time will be spent writing code, but a large part of the time spent will go towards explaining the code on mailing lists, asking and answering questions on IRC and in general reasoning about proposed software changes. If you can't do this, you take the risk of not understanding the goals of our project or not being able to explain why your patch is necessary.
- Participate. Developing your own code is only part of the open source experience. You should also be getting involved with discussions on our mailing lists with users and developers, commenting on other code, responding to bug reports, editing the wiki, etc.