[OpenDaylight TSC] [OpenDaylight Discuss] best practices for preventing/handling cross-project breakages

Colin Dixon colin at colindixon.com
Thu Feb 4 16:32:26 UTC 2016


In addition to what's been raised here. Robert Reminded me during the TWS
call that we need to have a provision that says downstream projects can't
just block indefinitely. I think that gives us this, which I'll try to
bring up today on the TSC call.

0.) Broadly, our culture should be one of respecting the time and pain of
other developers.
     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
make sense
2.) If a change is believed to potentially problematic, test it more
intensively
     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.) Announce it as a Weather event and via e-mail at least a week in
advance of it being merged to give downstream projects time to test.
     d.) 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]
     c.) downstream projects should not be able to indefinitely stall a
change.
          [after some reasonable period of time, e.g., 2 weeks, downstream
projects are expected to be able to make reasonable changes with help to
allow a change to be merged]
          [if the downstream project feels the changes aren't reasonable
and it can't be resolved between projects, the TSC can adjudicate]

Cheers,
--Colin


On Thu, Jan 14, 2016 at 1:33 PM, Anil Vishnoi <vishnoianil at gmail.com> wrote:

>
>
> On Thu, Jan 14, 2016 at 9:51 AM, Colin Dixon <colin at colindixon.com> wrote:
>
>> 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.
>>
>> Cheers,
>> --Colin
>>
>>
>> 0.) Broadly, our culture should be one of respecting the time and pain of
>> other developers.
>>      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 make sense
>> 2.) If a change is believed to potentially problematic, test it more
>> intensively
>>      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
>>
> ​It would be good if atleast 1 week of time is given to downstream project
> to test the patch locally, to raise any issues before the merge. In case of
> no response from downstream projects, fall back to (c).​
>
>
>>
>> 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]
>>
>>
>>
>> _______________________________________________
>> Discuss mailing list
>> Discuss at lists.opendaylight.org
>> https://lists.opendaylight.org/mailman/listinfo/discuss
>>
>>
>
>
> --
> Thanks
> Anil
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendaylight.org/pipermail/tsc/attachments/20160204/6ea8705f/attachment-0001.html>


More information about the TSC mailing list