:gvelchuru - yes, I have done some work in the related bugs 1595982 and 1597616, broken up by subdirectory. I would prefer if the patch was smaller and more self-contained such that it is easier to review and keep in mind the context. For example, changes to `manifestparser.py` will conflict with the changes made by :championshuttler in bug 1428705. Changes to `mozharness/base/` would conflict with the now-landed patches that I have authored, so they should not be included in D35332. As a side note, I added a test environment for python3.5 in `tox` which would conflict with your patch here. I guess my preference would be to have the patch broken up into smaller chunks as well as having the patch be rebased to work off the current mozilla-central. Take one file or subdirectory and work in small chunks at a time, solving issues that running `tox -e py35-hg4.3` would throw up for the file you're working on.
Bug 1532427 Comment 25 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
:gvelchuru - yes, I have done some work in the related bugs 1595982 and 1597616, broken up by subdirectory. I would prefer if the patch was smaller and more self-contained such that it is easier to review and keep in mind the context. For example, changes to `manifestparser.py` will conflict with the changes made by :championshuttler in bug 1428705. Changes to `mozharness/base/` would conflict with the now-landed patches that I have authored, so they should not be included in D35332. As a side note, I added a test environment for python3.5 in `tox` which would conflict with your patch here. To reiterate, my preference would be to have the patch broken up into smaller chunks as well as having the patch be rebased to work off the current or reasonably updated `mozilla-central`. Take one file or subdirectory and work in small chunks at a time, solving issues that running `tox -e py35-hg4.3` would throw up for the file you're working on, and repeat. For me that workflow looks like: 1. identify a file/subdirectory to tackle (that does not overlap with existing work in progress by another engineer) 2. fix the issues 3. put up patch 4. land 5. once landed, pull updated mozilla-central, repeat from step 1. This way multiple engineers can tackle the same issue and work in parallel.