Bruno Oliveira wrote: >> Rather than work on a large, monolithic reorganisation as I tried before, >> I would like to do it in very small commits and cycles, that can quickly be >> checked, approved and merged, over a period of a few weeks.
>Are the small changes self-contained? If so, I think they can target the >master branch as usual with other PRs. > >If however the changes are just part of an overall redesign, where it only >makes sense to publish them to users once the overall redesign is complete, >we can have a separate branch in the repository, like before. That's exactly the thing I want to and think I can successfully avoid. The changes will be iterative and evolutionary. The idea is that each one will contain something - however small - that moves in the right direction and can be included. So yes, I would like to target the master branch, in effect with a stream of small commits. It's possible to do this with documentation in a way that's not possible with code. >>To help make it work, I would need to be able to rely on very short >> review/merge cycles, which I know is asking a lot in a project like this. >> On the other hand, each proposed change will typically be very small and >> easy to review. In fact some of them will likely seem quite trivial or >> banal in content, but if you can put up with that during the process, it's >> part of the approach. >Overall our review response is quick, usually within 1-2 days (if not a few >hours). What do you think would be required for this work? That would certainly work for me. >Thanks for offering to contribute again! I'd really like to do this, it has been on my mind since 2017! But as it could be annoying for the team to be faced with the proposed stream of very small commits, I'd like to get a sense whether it would fit with the way you actually want to work. Regards, Daniele _______________________________________________ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
