Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-pmc] Update of API Removal Process

----- Original Message -----
> From: "Lars Vogel" <lars.vogel@xxxxxxxxx>
> To: eclipse-pmc@xxxxxxxxxxx
> Sent: Thursday, 1 October, 2015 2:24:10 PM
> Subject: Re: [eclipse-pmc] Update of API Removal Process
> 
> Hi,
> AFAIK email lists eclipse.org-committers@xxxxxxxxxxx and eclipse-dev are
> moderated, so it cannot be guaranteed that we can reach them. I also suggest
> that these removal announcement can be batched to avoid to many emails.
> E.g., the platform lead (Dani) could once per release send out all planned
> removals.
> 
> I think that community disagreement must be weighted against available the
> developers maintaining the code, if the developers agree that an API should
> be removed, I don't think the community (not maintaining the code) should be
> allowed to stop them.

This is exactly what my edit tries to solve "If there is no substantial community disagreement (accompanied with resources to help fixing problems when needed)". Aka there is disagreement but it's broken and no one steps fixing it - it will still be removed, if one wants to keep it in he/she should jump in to fix the problems that made the current committers schedule it for removal. I think this is fare game and gives reaction path to both sides, simply complaining shouldn't be enough.

Regards,
Alex



> 
> Best regards, Lars
> 
> 2015-10-01 12:58 GMT+02:00 Aleksandar Kurtakov < akurtako@xxxxxxxxxx > :
> 
> 
> ----- Original Message -----
> > From: "Daniel Megert" < daniel_megert@xxxxxxxxxx >
> > To: eclipse-pmc@xxxxxxxxxxx
> > Sent: Thursday, 1 October, 2015 1:35:14 PM
> > Subject: [eclipse-pmc] Update of API Removal Process
> > 
> > Dear PMC colleagues
> > 
> > Here are the proposed changes to our API Removal Process as per our
> > discussion:
> > 
> > > Announce the upcoming deletion on relevant mailing lists, including a
> > > link
> > > to the bug for community comment (at least cross-project-issues-dev and
> > > eclipse-dev).
> > Announce the upcoming deletion on all relevant mailing lists, including a
> > link to the bug for community comment (at least cross-project-issues-dev,
> > eclipse.org-committers@xxxxxxxxxxx and eclipse-dev).
> > QUESTION : should we also send a note to eclipse.org-planning-council?
> 
> I don't think this will have a *net* add to the recipients lists covered by
> the the other lists so let's not spam one more list.
> 
> > 
> > > Assuming no community disagreement, update deprecation comment and add an
> > > entry in porting guide. The deprecation comment and porting guide entry
> > > must also include a link to the bug report to allow for further feedback
> > > from API adopters.
> > If there is no community disagreement, annotate all APIs that are to be
> > removed with @noreference , update the deprecation comment, and add an
> > entry
> > in the porting guide. The deprecation comment and porting guide entry must
> > explain how to adapt the client code and include a link to the bug report
> > to
> > allow for further feedback from API adopters.
> 
> "If there is no community disagreement" leaves the door open for unreasonable
> or unsubstantial disagreement for the sake of "I don't like changes" or
> similar to block the process.
> "If there is no substantial community disagreement (accompanied with
> resources to help fixing problems when needed)" is better way of leaving
> power to committers and putting some requirements about objections reasoning
> and a guard for not shipping broken stuff if there is no one going to fix
> it.
> 
> Alexander Kurtakov
> Red Hat Eclipse team
> 
> > 
> > > After the required waiting period has gone by, the API is removed and the
> > > porting guide entry is moved from the "upcoming deletions" to the
> > > "deleted
> > > API" section in the documentation.
> > After the required waiting period has gone by, the API is removed and the
> > porting guide entry is moved from the " Planned API removals " to the "
> > Removed APIs " section in the documentation.
> > 
> > 
> > Once you approve those changes I will make the corresponding updates to our
> > Deprecation Policy document as well. I will also adjust the section about
> > bundle and package versions according to our last discussion i.e. decide
> > case-by-case whether to increase the major or minor version.
> > 
> > Dani
> > 
> > _______________________________________________
> > eclipse-pmc mailing list
> > eclipse-pmc@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or unsubscribe
> > from
> > this list, visit
> > https://dev.eclipse.org/mailman/listinfo/eclipse-pmc
> _______________________________________________
> eclipse-pmc mailing list
> eclipse-pmc@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/eclipse-pmc
> 
> 
> _______________________________________________
> eclipse-pmc mailing list
> eclipse-pmc@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/eclipse-pmc


Back to the top