Differences between revisions 10 and 11
Revision 10 as of 2012-12-23 12:24:06
Size: 1793
Editor: IdanKamara
Comment:
Revision 11 as of 2012-12-23 12:24:48
Size: 1799
Editor: IdanKamara
Comment:
Deletions are marked like this. Additions are marked like this.
Line 27: Line 27:
http://selenic.com/pipermail/mercurial-devel/2012-May/039771.html
http://selenic.com/pipermail/mercurial-devel/2012-December/047089.html
 * http://selenic.com/pipermail/mercurial-devel/2012-May/039771.html
 * http://selenic.com/pipermail/mercurial-devel/2012-December/047089.html

Note:

This page is primarily intended for developers of Mercurial.

Improving Collaboration

There has been recent discussion on IRC amongst Mercurial developers about how we can better collaborate. This wiki page is an attempt to summarize everyone's concerns and possible solutions.

1. Current Concerns

Concerns about the current development workflow include:

  • High-barrier of entry for new contributors (for example, the use of the patchbomb extension)
  • Does not encourage the Mercurial development team to dogfood the tools we ship to our users
    • Example: named branch support improved after the development team started using (read: dogfooding) them
  • The "Dictator for Life" hierarchy doesn't foster a feeling of teamwork amongst the rest of the developers
    • Not sure of the details about this one, but something along these lines was mentioned in the IRC channel
  • Changes that are "queued" may not show up in the public repository until day(s) later

2. Possible Solutions / Improvements

2.1. Set Up an "Official" Mirror of Mercurial for Development on Bitbucket

  • Figure out some way to make opening "pull requests" send a mail with the patch (and Bitbucket link) to the devel list for review (that way code can continue to be reviewed in a mailing list). Ideally we'd need to send comments back to the pull request so people looking at Bitbucket can see them
  • Encourage the use of branches for work (rather than staging up patches in MQ) and be willing to merge them rather than to "force" a pristine history by only rebasing patches


CategoryDeveloper

ImprovingCollaboration (last edited 2012-12-23 12:24:48 by IdanKamara)