Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

With a mailing list you download a patch and apply it with "git am", then push it to the repository -- as you are presumably the maintainer who has permission to do that, and assuming the patch is good. You basically just do code review through email and reading the patches with some git functions. It completely sucks in my opinion, but some people like it, or it's how they do things in those parts, etc. When in Rome...

Having done a similar rodeo in the past -- migrating a project to an actual code review tool that enforces some more rigid structure, over plain patch files -- the interim process will probably be something like:

- Previously, some key people were allowed to commit to trunk directly.

- They would read emails/patches, do code review, apply, and push them to trunk.

- For now, you can keep emailing people your patches like you did before. Nothing will change.

- But at a certain point, you'll have to use this new Other Method.

- So, you should probably get familiar with Other Method early, by using it in the meantime, so you can be ready.

- At some point, no more patch files will be accepted and you will have to use Other Method.

- In the meantime, the maintainers will do double-duty and handle both venues.

Most projects are small enough where the double-duty isn't so bad. Most people will switch quick enough and you probably aren't dealing with 1,000 patches. It sucks but the payoff is considered worth it.

Eventually once this is completed you can do things like stop pushing directly to trunk and handling all patches to main through the Other Method. But you don't have to do that. It does sound like they'll stop accepting email patches, though.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: