Re: On adding new APIs

2016-10-20 Thread Michael Dürig
On 20.10.16 2:21 , Bertrand Delacretaz wrote: On Thu, Oct 20, 2016 at 2:02 PM, Michael Marth wrote: ...So I have a proposal: when a new public API is added the developer should drop an email with subject tag [REVIEW] onto the dev list, so that others are aware and can

Re: On adding new APIs

2016-10-20 Thread Davide Giannella
On 20/10/2016 13:02, Michael Marth wrote: > developer should drop an email with subject tag [REVIEW] ok for the email, but it should point to a ticket in jira where the discussion would happen. Davide

Re: On adding new APIs

2016-10-20 Thread Thomas Mueller
Hi, I would prefer C-T-R (commit, then review), because it reduces bureaucracy. Except for changes just before a major release (when there is little time to und or change things). +1 to [REVIEW] emails. In my view, this should include new configuration and new features. Basically all

Re: On adding new APIs

2016-10-20 Thread Bertrand Delacretaz
On Thu, Oct 20, 2016 at 2:02 PM, Michael Marth wrote: > ...So I have a proposal: when a new public API is added the developer should > drop an > email with subject tag [REVIEW] onto the dev list, so that others are aware > and can > chime in if needed... The Oak team can also

On adding new APIs

2016-10-20 Thread Michael Marth
Hi all, I had a discussion with Michael Dürig about adding new Oak-specific APIs for public consumption. There is a concern that these might be too “ad-hoc” and might come back to bite us later. OTOH I would not like to add too much process or ceremony. So I have a proposal: when a new public