Re: API Review Policy
> On Mar 13, 2018, at 3:58 PM, Greg Mann wrote: > > Sure we can use that as a starting point. The basic policy that we > discussed in the working group was that any public API change should be > advertised on the developer mailing list. If no concerns are raised after > several days, then the change could proceed. If concerns were raised, then > discussion could start on the mailing list and continue in the next meeting > of the API working group if necessary. > > The Traffic Server policy includes a few other concrete details which we > did not discuss. I'll quote it here to make things easy: > > > Due to the importance of getting API right, there is a required review >> process for changes to the Traffic Server API. For every API change, the >> developer should post a message to the dev@ list that >> >> - references the relevant Github Issue or PR >> - explains the motivating problem and rationale >> - shows the actual API change itself (ie. API signatures, etc) >> - documents the semantics of the proposed API >> - notes any ABI or compatibility implicates >> >> After a comments period (1 or 2 days), the committer would add the API. If >> there were any comments or suggestions, then the committer would address >> those as necessary. >> >> New API can be added to experimental.h if the developer believe that it >> might change after some adoption or implementation experience. APIs >> intended for experimental.h should still be reviewed on the mailing list. >> APIs added to experimental.h, or another experimental header, can (and >> should!) get moved to a frozen and stable include file when appropriate. >> It's up to the author to propose a promotion to stable on the mailing list, >> lazy consensus applies here. >> >> It is strongly preferable that a new API to be integrated into a sample >> plugin - giving users a good sample to copy. API documentation and unit >> tests should be provided as a matter of course. >> >> > > I think this is pretty good as-is; replace "Github Issue or PR" with "JIRA > issue or ReviewBoard patch", and remove the portion about 'experimental.h' > and what follows. I’m generally in favor of this. I think that we all try to raise compatibility and operational issues on the mailing lists, so this seems like a formalization and extension of that practice. Most of the information needed for an API proposal would already be captured in a design document, so in the Mesos context this would be about improving the visibility of changes and widening the feedback net. cheers, James.
Re: API Review Policy
Sure we can use that as a starting point. The basic policy that we discussed in the working group was that any public API change should be advertised on the developer mailing list. If no concerns are raised after several days, then the change could proceed. If concerns were raised, then discussion could start on the mailing list and continue in the next meeting of the API working group if necessary. The Traffic Server policy includes a few other concrete details which we did not discuss. I'll quote it here to make things easy: Due to the importance of getting API right, there is a required review > process for changes to the Traffic Server API. For every API change, the > developer should post a message to the dev@ list that > >- references the relevant Github Issue or PR >- explains the motivating problem and rationale >- shows the actual API change itself (ie. API signatures, etc) >- documents the semantics of the proposed API >- notes any ABI or compatibility implicates > > After a comments period (1 or 2 days), the committer would add the API. If > there were any comments or suggestions, then the committer would address > those as necessary. > > New API can be added to experimental.h if the developer believe that it > might change after some adoption or implementation experience. APIs > intended for experimental.h should still be reviewed on the mailing list. > APIs added to experimental.h, or another experimental header, can (and > should!) get moved to a frozen and stable include file when appropriate. > It's up to the author to propose a promotion to stable on the mailing list, > lazy consensus applies here. > > It is strongly preferable that a new API to be integrated into a sample > plugin - giving users a good sample to copy. API documentation and unit > tests should be provided as a matter of course. > > I think this is pretty good as-is; replace "Github Issue or PR" with "JIRA issue or ReviewBoard patch", and remove the portion about 'experimental.h' and what follows. Greg On Tue, Mar 13, 2018 at 3:40 PM, Zhitao Li wrote: > +1 for keeping the policy in writing. Are we looking at the Traffic > Server's API policy as a starting point for discussion? > > On Tue, Mar 13, 2018 at 10:12 AM, Greg Mann wrote: > > > Hi all, > > As BenM mentioned in a recent email, we discussed our process for review > of > > API changes in the recent API working group meeting [1]. James Peach was > > also kind enough to share with me Apache Traffic Server's API review > > policy, which they have formalized [2]. > > > > I like the idea of putting our review policy in writing, as this > increases > > transparency and helps to communicate the policy to new contributors. If > > others in the project are amenable to this idea, I could propose a draft > > policy and present it to the mailing list for review. > > > > What do folks think about this? > > > > Cheers, > > Greg > > > > [1] > > https://docs.google.com/document/d/1JrF7pA6gcBZ6iyeP5YgDG62ifn0cZ > > IBWw1f_Ler6fLM/edit > > [2] https://cwiki.apache.org/confluence/display/TS/API+Review+Process > > > > > > -- > Cheers, > > Zhitao Li >
Re: API Review Policy
+1 for keeping the policy in writing. Are we looking at the Traffic Server's API policy as a starting point for discussion? On Tue, Mar 13, 2018 at 10:12 AM, Greg Mann wrote: > Hi all, > As BenM mentioned in a recent email, we discussed our process for review of > API changes in the recent API working group meeting [1]. James Peach was > also kind enough to share with me Apache Traffic Server's API review > policy, which they have formalized [2]. > > I like the idea of putting our review policy in writing, as this increases > transparency and helps to communicate the policy to new contributors. If > others in the project are amenable to this idea, I could propose a draft > policy and present it to the mailing list for review. > > What do folks think about this? > > Cheers, > Greg > > [1] > https://docs.google.com/document/d/1JrF7pA6gcBZ6iyeP5YgDG62ifn0cZ > IBWw1f_Ler6fLM/edit > [2] https://cwiki.apache.org/confluence/display/TS/API+Review+Process > -- Cheers, Zhitao Li
Release policy and 1.6 release schedule
Hi folks, During the recent API working group meeting [1], we discussed the release schedule. This has been a recurring topic of discussion in the developer sync meetings, and while our official policy still specifies time-based releases at a bi-monthly cadence, in practice we tend to gate our releases on the completion of certain features, and our releases go out on a less-frequent basis. Here are the dates of our last few release blog posts, which I'm assuming correlate pretty well with the actual release dates: 1.5.0: 2/8/18 1.4.0: 9/18/17 1.3.0: 6/7/17 1.2.0: 3/8/17 1.1.0: 11/10/16 Our current cadence seems to be around 3-4 months between releases, while our documentation states that we release every two months [2]. My primary motivation here is to bring our documented policy in line with our practice, whatever that may be. Do people think that we should attempt to bring our release cadence more in line with our current stated policy, or should the policy be changed to reflect our current practice? If we were to attempt to align with our stated policy for 1.6.0, then we would release around April 8, which would probably mean cutting an RC sometime around the end of March or beginning of April. This is very soon! :) I'm currently working with Gastón on offer operation feedback, and I'm not sure that we would have it ready in time for an early April release date. Personally, I would be OK with this, since we could land the feature in 1.7.0 in June. However, I'm not sure how well this schedule would work for the features that other people are currently working on. I'm curious to hear people's thoughts on this, developers and users alike! Cheers, Greg [1] https://docs.google.com/document/d/1JrF7pA6gcBZ6iyeP5YgDG62ifn0cZ IBWw1f_Ler6fLM/edit# [2] http://mesos.apache.org/documentation/latest/ versioning/#release-schedule
API Review Policy
Hi all, As BenM mentioned in a recent email, we discussed our process for review of API changes in the recent API working group meeting [1]. James Peach was also kind enough to share with me Apache Traffic Server's API review policy, which they have formalized [2]. I like the idea of putting our review policy in writing, as this increases transparency and helps to communicate the policy to new contributors. If others in the project are amenable to this idea, I could propose a draft policy and present it to the mailing list for review. What do folks think about this? Cheers, Greg [1] https://docs.google.com/document/d/1JrF7pA6gcBZ6iyeP5YgDG62ifn0cZIBWw1f_Ler6fLM/edit [2] https://cwiki.apache.org/confluence/display/TS/API+Review+Process
[GitHub] mesos pull request #259: Update contributors.yaml
Github user asfgit closed the pull request at: https://github.com/apache/mesos/pull/259 ---
