Difference between revisions of "Features/Patch workflow"

From Sugar Labs
Jump to navigation Jump to search
Line 16: Line 16:
 
*** Pro:
 
*** Pro:
 
**** the same place for all bugs fixes related info
 
**** the same place for all bugs fixes related info
**** using only email to work with bugs.sl.o (not only for bugs)
+
**** using only email to work with bugs.sl.o (not only for patches)
 
**** ...
 
**** ...
 
*** Contra:
 
*** Contra:
 
**** afaik, not implemented
 
**** afaik, not implemented
 +
**** ...

Revision as of 06:23, 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
        • ...
    • 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 patches)
        • ...
      • Contra:
        • afaik, not implemented
        • ...