Improve handling of experimental features

[whiteknight]

I would like to suggest some changes with regards to features labeled "experimental":

• Create an EXPERIMENTAL.pod file to keep experimental items (on their way in) separated from deprecated items (on their way out)
• That features labeled experimental have a certain time-limit. Beyond that time, say two stable releases, we have to make a decision whether the feature is suitable for permanent addition to the API, whether it needs to be improved, or whether it can be safely deleted.
• That we update the #parrotsketch meeting process to regularly evaluate these items for viability
• That we add a ticket Type "experimental" on Trac, and associate all experimental features with a ticket. Many experimental features have associated tickets now as problems that the experimental feature tries to fix. However, these aren't tickets that assure we properly triage these features in a timely manner. Also, not all experimental features are added as a response to a bug.

Input on this issue would be very helpful.

[coke]

First, isn't the mailing list a better place for discussion than trac tickets? You'll probably get a wider audience on parrot-dev.

Nothing substantial for or against:

Move both DEPRECATED.pod and EXPERIMENTAL.pod to docs and mention them in the README.

We have things that were experimental in 1.0 that are still considered experimental. We're using it to also mean "subject to change" (like the enum #'s of PMCs) as opposed to truly unreliable. I would suggest that rather than go with a complicated rule, we just evaluate anything labeled experimental before a stable release.

If we're going to add an experimental type, I would also add a "deprecated" type at the same time.

[whiteknight]

Replying to coke:

First, isn't the mailing list a better place for discussion than trac tickets? You'll probably get a wider audience on parrot-dev.

Tickets are echoed to the mailing list. We can also send a mail to the list referencing this ticket if we want, but the ticket is a permanent reminder of the issue when the mailinglist inevitably stops talking about this.

Move both DEPRECATED.pod and EXPERIMENTAL.pod to docs and mention them in the README.

I'm fine with that change.

We have things that were experimental in 1.0 that are still considered experimental. We're using it to also mean "subject to change" (like the enum #'s of PMCs) as opposed to truly unreliable. I would suggest that rather than go with a complicated rule, we just evaluate anything labeled experimental before a stable release.

Exactly my point. Things that are experimental tend to be ignored so long as they are working. Some kind of process change would force us to re-examine some of these things to make sure that the experimental status is warranted.

An item marked experimental, but which has been stable and largely unmodified for a certain time period should be a candidate for permanent addition to the API. Items which are experimental and are largely unused or are known to be buggy are candidates for removal. Items that are "almost" good enough but still in flux can remain experimental.

What we don't want is dozens of "experimental" items building up in the DEPRECATED.pod without being tracked, triaged, or dealt with.

If we're going to add an experimental type, I would also add a "deprecated" type at the same time.

[coke]

Replying to whiteknight:

Replying to coke:

First, isn't the mailing list a better place for discussion than trac tickets? You'll probably get a wider audience on parrot-dev.

Tickets are echoed to the mailing list. We can also send a mail to the list referencing this ticket if we want, but the ticket is a permanent reminder of the issue when the mailinglist inevitably stops talking about this.

FYI, tickets are sent to parrot-tickets (29 members), not parrot-dev (437 members).

[coke]

Replying to whiteknight:

Replying to coke:

We have things that were experimental in 1.0 that are still considered experimental. We're using it to also mean "subject to change" (like the enum #'s of PMCs) as opposed to truly unreliable. I would suggest that rather than go with a complicated rule, we just evaluate anything labeled experimental before a stable release.

Exactly my point. Things that are experimental tend to be ignored so long as they are working. Some kind of process change would force us to re-examine some of these things to make sure that the experimental status is warranted. An item marked experimental, but which has been stable and largely unmodified for a certain time period should be a candidate for permanent addition to the API. Items which are experimental and are largely unused or are known to be buggy are candidates for removal. Items that are "almost" good enough but still in flux can remain experimental. What we don't want is dozens of "experimental" items building up in the DEPRECATED.pod without being tracked, triaged, or dealt with.

We're in agreement here - IMO, just raising the issue in the parrotsketch or in parrot-dev is fine; I don't think we need a hard timeline here, just a regular review (which has not happened so far.)

It would be helpful if future additions with the experimental status were tagged with the first release in which they were introduced.

[jkeenan]

coke, whiteknight:

Do you feel that you reached some kind of consensus in the above discussion?

Are there any points on which we have to take action?

Can the ticket be closed?

Thank you very much.

kid51

[whiteknight]

We're going to be raising issues about some experimental features at #ps today and at meetings in the future. I'll consider this issue resolved for now.