[
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
announced)?
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).
Thanks,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
direct
+43.662.457915.85 fax +43.662.457915.6
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? John
Jeff McAffer
<jeff@xxxxxxxxxxxxxxxxx>
Sent by: eclipse-pmc-bounces@xxxxxxxxxxx
04/21/2010 06:30 PM
|
Please respond
to
eclipse-pmc@xxxxxxxxxxx |
|
|
To
| eclipse-pmc@xxxxxxxxxxx
|
|
cc
|
|
|
Subject
| Re: [eclipse-pmc] Pending API
deletions list |
|
Use
Bugzilla. It is open, visible, supports community input and has a
voting/approval mechanism. Jeff
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. Thanks,
-- 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: Wednesday, April 21, 2010 8:52 PM
To:
eclipse-pmc@xxxxxxxxxxx
Subject: [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?
John _______________________________________________
eclipse-pmc mailing
list
eclipse-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-pmc
_______________________________________________
eclipse-pmc mailing
list
eclipse-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-pmc
