4

I've started work on a large, open-source project recently. This project uses a mailing list for development, thus all patches must be mailed to this mailing list. This marks a change from my previous work where I used Gerrit or GitHub pull requests.

One of the biggest issues I'm finding is how to collaborate on these patches. I have my local copy of the upstream repo, which I work on, but there isn't a "shared repo". This means I can't work on a features with teammates via feature branches or Gerrit topics (my previous workflow). The best I can do is submit patches back and forth via email, which is painful.

Given the prevalence of projects using this style of development, I imagine it's a "solved" problem. As such, could anyone recommend a general practice to follow for this kind of development?

stephenfin
  • 171
  • 4
  • A "Mailing List" isn't purely email, it allows conversation threads, and FOS projects generally have a issue tracker where you can submit patches – ratchet freak Oct 29 '14 at 15:36
  • Is the upstream repo a git/hg-based one? If yes, why not just fork it onto Github/Bitbucket anyway? – JensG Oct 29 '14 at 15:56
  • @ratchetfreak This is true, but there doesn't seem to be anything there to help me collaborate with others during the actual development process - only the review process? – stephenfin Oct 29 '14 at 16:06

1 Answers1

4

The fact that the central repo isn't shared does not stop you from sharing your repo.

When you want to work on something closely with somebody else, just set up a clone on github, gitorious or similar and share there. When time comes to push it to master you still submit via the mail process, but while cooking the changeset, you can share in another way.

In fact there is little difference between this and github pull requests. With pull requests you are still publishing your clone and requesting merge from it. So do everything the same, just the request goes through another channel (ok, there will be rebase instead of merge as the mailed patches don't preserve commit identity, but that shouldn't be big problem; you know the old versions are obsolete when it's integrated).

Jan Hudec
  • 18,250
  • 1
  • 39
  • 62