Minutes of technical board meeting 2017-12-06

Minutes of technical board meeting 2017-12-06

[Richardson, Bruce]

Attendees:
Bruce, Hemant, Jerin, Konstantin, Olivier, Thomas, Yuanhan

Absent:
Stephen, Jan

Due to discontinued involvement in DPDK, Jan has now resigned from the technical board.
The tech board wishes to thank him for his contributions to DPDK and tech-board over the last few years and wish him well in his other endeavours.
The topic of a possible replacement for Jan on the tech-board will be discussed at the next meeting.

Topic: Management of old patches in patchwork
* Unanimous agreement that old patches should be rejected in patchwork
  after a reasonable period, set initially at 3 releases (9 months).
* After a release, all patches dated older than 3 releases previously,
  e.g. after 17.11, any patches submitted before the release of 17.02,
  will be marked as rejected and a mail reply sent to the appropriate
  mailing list thread informing people of the same.
* To have patches reconsidered for future inclusion, a new version of
  the patches should be submitted to the mailing list.

* Bruce to update the documentation with this new policy.
* Thomas to request support from patchwork and DPDK community to
  automate/script the implementation of this policy.

Topic: Licensing
* No major updates. Discussion in progress on a number of items that
  need relicensing or exceptions.

Topic: Technical Board Voting
* For charter changes the governing board requires a 2/3 majority. The
  technical board has no such special case for charter or policy
  changes.
* Following brief discussion, most seemed happy with the current
  situation where a simple majority suffices for such decisions.
  
Next Meeting:
* 2017-12-20 @ 3pm UTC
* Hemant to chair discussion

Re: Minutes of technical board meeting 2017-12-06

[Jay Rolette]

On Tue, Dec 12, 2017 at 11:26 AM, Richardson, Bruce <
bruce.richardson@intel.com> wrote:


> Topic: Management of old patches in patchwork
> * Unanimous agreement that old patches should be rejected in patchwork
>   after a reasonable period, set initially at 3 releases (9 months).
> * After a release, all patches dated older than 3 releases previously,
>   e.g. after 17.11, any patches submitted before the release of 17.02,
>   will be marked as rejected and a mail reply sent to the appropriate
>   mailing list thread informing people of the same.
> * To have patches reconsidered for future inclusion, a new version of
>   the patches should be submitted to the mailing list.
>

Does this mean there is a commitment to act on submitted patches in a
timely manner? Maybe this is better now, but at least in the past, even
small patches to fix bugs would sit around with no action on them for 6+
months.

It's been a while since I submitted any patches, so if this isn't an issue
now, then nevermind :-)

Jay

Re: Minutes of technical board meeting 2017-12-06

[Bruce Richardson]

On Tue, Dec 12, 2017 at 12:30:11PM -0600, Jay Rolette wrote:
> On Tue, Dec 12, 2017 at 11:26 AM, Richardson, Bruce <
> bruce.richardson@intel.com> wrote:
> 
> 
> > Topic: Management of old patches in patchwork * Unanimous agreement
> > that old patches should be rejected in patchwork after a reasonable
> > period, set initially at 3 releases (9 months).  * After a release,
> > all patches dated older than 3 releases previously, e.g. after
> > 17.11, any patches submitted before the release of 17.02, will be
> > marked as rejected and a mail reply sent to the appropriate mailing
> > list thread informing people of the same.  * To have patches
> > reconsidered for future inclusion, a new version of the patches
> > should be submitted to the mailing list.
> >
> 
> Does this mean there is a commitment to act on submitted patches in a
> timely manner? Maybe this is better now, but at least in the past,
> even small patches to fix bugs would sit around with no action on them
> for 6+ months.
> 
> It's been a while since I submitted any patches, so if this isn't an
> issue now, then nevermind :-)
> 
Being honest, I don't think we could ever say it's not a problem, and I
also don't believe we could ever make a committment to always respond to
patches in a timely manner. Each maintainer is responsible for reviewing
and "managing" patches in their area of responsibility and some
maintainers will be faster to respond than others. We have, however, a
documented procedure for having patches merged once acked by the
maintainer, so that should have improved things. Up to getting
maintainer ack, it is still up to the submitter to ping the maintainer
to review if no response is forthcoming on the patch submission.

/Bruce