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
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
_______________________________________________