[OpenDaylight TSC] best practices for preventing/handling cross-project breakages
colin at colindixon.com
Thu Jan 14 17:51:20 UTC 2016
This paragraph (really a list) is what's emerged from the assigned
discussion from several TSC meetings ago. It would be good if the TSC and
broader community could look it over and provide any additional feedback.
At that point, the TSC could formally adopt it as our best practices.
0.) Broadly, our culture should be one of respecting the time and pain of
a.) Ideally, the "don't break userspace!" mantra of Linux would
translate here into "don't break downstream!"
1.) Do your best to test code (across projects) before it's merged.
a.) If the ODL kernel depends on something you're changing, compiling
the whole kernel with the change locally to make sure it builds seems to
2.) If a change is believed to potentially problematic, test it more
a.) At least run the test-integration keyword to see what happens.
b.) Ideally run autorelease with the patch.
[keeping autorelease working better as a high priority would be a
good technical change]
[we should provide more streamlined ways to do this will be
important, e.g., the autorelease validate that we've created]
c.) it should be merged earlier in the week, e.g., Monday or Tuesday,
to provide time when developers will be around to catch/fix any fallout
3.) If, after a change has been merged, downstream projects complain that
they are having issues, either:
a.) provide patches to get them back up and working if they're simple.
b.) revert the change for some specified period of time while
downstream projects and the community can figure out what to do.
[such breakages should be reported in a timely fashion, e.g.,
within 48 hours]
[upstream projects should have some time to analyze the breakage
and either fix it or revert the troublesome patch, e.g., 24 hours]
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the TSC