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?
- A "Mailing List" isn't purely email, it allows conversation threads, and FOS projects generally have a issue tracker where you can submit patchesratchet freak– ratchet freak2014-10-29 15:36:55 +00:00CommentedOct 29, 2014 at 15:36
- Is the upstream repo a git/hg-based one? If yes, why not just fork it onto Github/Bitbucket anyway?JensG– JensG2014-10-29 15:56:04 +00:00CommentedOct 29, 2014 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– stephenfin2014-10-29 16:06:21 +00:00CommentedOct 29, 2014 at 16:06
1 Answer1
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 ongithub,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 andgithub 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).
Explore related questions
See similar questions with these tags.