|
|
|
|
|
by xeromal
654 days ago
|
|
I wonder how the interim process is handled? They're accepting mailing list updates until the end of the year. Does someone take the mailing list updates and manually PR them into Github? I've never actually used a mailing list so I'm curious how it works. |
|
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.