Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [eclipse-pmc] Pending API deletions list

Sounds good to me - one question remains open though:
What is the public feedback channel for clients to disagree with the
deletion AFTER it has been put into the porting guide?  There's
1-2 years during which we should be open for discussion.
Shall we keep the same bug? If yes, should the bug state be
kept open until the API is actually deleted or should the bug
just talk about announcing the deletion (and close when
Or should a different channel be used after announced (eg
mailing list, newsgroup... but there's a risk of losing bug
history when doing that).
Martin Oberhuber, Senior Member of Technical Staff, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: eclipse-pmc-bounces@xxxxxxxxxxx [mailto:eclipse-pmc-bounces@xxxxxxxxxxx] On Behalf Of John Arthorne
Sent: Thursday, April 22, 2010 4:07 AM
To: eclipse-pmc@xxxxxxxxxxx
Subject: Re: [eclipse-pmc] Pending API deletions list

Ok, sounds good to me. So the process would be:

1) Enter a bug report describing the proposed removal and rationale
2) Send request to eclipse-pmc mailing list, quoting bug reference
3) We discuss and come to agreement on a PMC weekly call, and mark pmc_approved+ on the bug if approved
4) Wider announcement of deletion on relevant mailing lists, including link to bug for community comment (cross-project-issues-dev and eclipse-dev)

5) Assuming no community disagreement, update deprecation comment, add entry in porting guide

How does that sound?


Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx>
Sent by: eclipse-pmc-bounces@xxxxxxxxxxx

04/21/2010 06:30 PM

Please respond to

Re: [eclipse-pmc] Pending API deletions list

Use Bugzilla. It is open, visible, supports community input and has a voting/approval mechanism.


On 2010-04-21, at 3:14 PM, Oberhuber, Martin wrote:

Definitely we should use a bug for tracking each deletion.
Note that the deprecation policy says that after the intent for API deletion has been
announced, clients / consumers can argue against the deletion. So we'll need a
channel for this, and it will be useful to be able and have the "client channel"
reference the original discussion that led to proposing a deprecation.
Actually, agreeing on what the client channel should be and how to announce
it is a prerequisite for your item (3) wider announcement.
Martin Oberhuber, Senior Member of Technical Staff, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: eclipse-pmc-bounces@xxxxxxxxxxx [mailto:eclipse-pmc-bounces@xxxxxxxxxxx] On Behalf Of John Arthorne
Wednesday, April 21, 2010 8:52 PM
[eclipse-pmc] Pending API deletions list

I haven't had a chance to bring this up in a recent PMC call, but I added a section to the platform porting guide for "upcoming" deletions according to our API deprecation policy. Please take a look at it in and let me know if you think of any needed changes (available in this week's I-builds). I added two entries partly as an exercise at writing what I think entries should look like as an example for others. We can discuss those two specific deletions at an upcoming call.

The next question is what the process should be for developers who want to add entries to this list. My opening proposal is that we should have quorum agreement on deletions within the PMC because it is quite a significant change (rather than +1 from any single PMC member). So, I suggest a process such as:

1) Developers send request to eclipse-pmc mailing list

2) We discuss and come to agreement on a PMC weekly call

3) Wider announcement of deletion (update deprecation comment, entry in porting guide, announce on wider mailing lists)

How does that sound? Should we also require a bug report to track the change?


eclipse-pmc mailing list


eclipse-pmc mailing list

Back to the top