Difference between revisions of "Features/Patch workflow"
< Features
Jump to navigation
Jump to search
(Created page with '* pylint and pep8.py should be integrated to git pre-commit hooks to catch all obvious fails * Reviewer notes should cover only logic of patch, other things will be caught on pr...') |
|||
| Line 3: | Line 3: | ||
* Reviewer notes should cover only logic of patch, other things will be caught on pre-commit level (if hook lacks of some checks, it shouldn't be subject for review process any way, and hooks should be fixed) | * Reviewer notes should cover only logic of patch, other things will be caught on pre-commit level (if hook lacks of some checks, it shouldn't be subject for review process any way, and hooks should be fixed) | ||
| − | * Submiting patches via email sounds pretty obvious and comfortable since glucose uses git.<br>But we need to have some kind of centralization to simplify releasing workflows and do not enforce people to setup local environment if they used to track patches in web browser.<br> Possible options are: | + | * Submiting patches via email sounds pretty obvious and comfortable since glucose uses git.<br>But we need to have some kind of centralization to simplify releasing workflows and do not enforce people to setup local environment if they used to track patches in web browser.<br> Possible options are, vote for particular option on [http://idea.sugarlabs.org/drupal5/ideatorrent/idea/36/]: |
** We dont need such centralization at all, this is just remains from previous workflow | ** We dont need such centralization at all, this is just remains from previous workflow | ||
*** ''no comments :)'' | *** ''no comments :)'' | ||
Revision as of 06:18, 16 May 2010
- pylint and pep8.py should be integrated to git pre-commit hooks to catch all obvious fails
- Reviewer notes should cover only logic of patch, other things will be caught on pre-commit level (if hook lacks of some checks, it shouldn't be subject for review process any way, and hooks should be fixed)
- Submiting patches via email sounds pretty obvious and comfortable since glucose uses git.
But we need to have some kind of centralization to simplify releasing workflows and do not enforce people to setup local environment if they used to track patches in web browser.
Possible options are, vote for particular option on [1]:- We dont need such centralization at all, this is just remains from previous workflow
- no comments :)
- http://patchwork.sugarlabs.org/
- Pro:
- already implemented
- ...
- Contra:
- since most of patches are bug fixes, will have two places for bugs related info, bugs.sl.o and patchwork.sl.o
- ...
- Pro:
- trac <-> mailing list synchronization
- Pro:
- the same place for all bugs fixes related info
- using only email to work with bugs.sl.o (not only for bugs)
- ...
- Contra:
- afaik, not implemented
- Pro:
- We dont need such centralization at all, this is just remains from previous workflow