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
Hi Dani,

> Our prime directive is not to delete any API.
> We will only allow to delete it if the removal is
> well justified, e.g. the API no longer works.
> Simply remove an API because it was deprecated will not be
> approved. 

In this case I suggest to split the decision about "mark it for deletion" and "delete it". I think the project developer should be allowed to mark API, which we do not plan to maintain, for deletion (after PMC approval).

But the PMC should also have the final go for deletion, if that is requested by the project.

I think it hard to guess that happens in the three year wait period for an API which we do not want to maintain. Without that we cannot delete an unmaintained API which starts causing NPE for additional three years.

This would also reflect reality better, e.g., some API in Platform UI which we marked for deletion in 4.2 is still in 4.6. The deletion flag send a strong message to consumer, even though we should avoid deleting it unless is causes problems.

This will help committers and contributors, as it is clearer what can be simplify ignored and what is only deprecated because a better alternative exists.

Best regards, Lars


2015-10-01 13:54 GMT+02:00 Daniel Megert <daniel_megert@xxxxxxxxxx>:
> AFAIK email lists eclipse.org-committers@xxxxxxxxxxx and eclipse-dev are moderated, so it cannot be guaranteed that we can reach them.
The moderator would for sure not block our notification.

> 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.
But the PMC will. Our prime directive is not to delete any API. We will only allow to delete it if the removal is well justified, e.g. the API no longer works. Simply remove an API because it was deprecated will not be approved. We were clear about that in our call from yesterday. Having said that, it is also clear that no one can expect any maintenance for deprecated APIs.

Dani



From:        Lars Vogel <lars.vogel@xxxxxxxxx>
To:        eclipse-pmc@xxxxxxxxxxx
Date:        01.10.2015 13:24
Subject:        Re: [eclipse-pmc] Update of API Removal Process
Sent by:        eclipse-pmc-bounces@xxxxxxxxxxx



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.

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

_______________________________________________
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