Changes between Version 7 and Version 8 of FRP

Timestamp:

07/23/10 07:12:18 (14 years ago)

Author:

Samuli Seppänen

Comment:

--

FRP

@@ -1 @@
- = The Feature Removal Process (FRP) =
+= The Feature Removal Process (FRP) =
 
- == Overview ==
+== Overview ==
 
-The initial process was drafted in the [wiki:IrcMeetings IRC meeting] on 18th Feb 2010. It has since been discussed in detail on the  [http://sourceforge.net/mailarchive/forum.php?forum_name=openvpn-devel devel mailinglist] in the ''"[PATCH v2] Do not randomize resolving of IP addresses in getaddr()"'' thread.
+The initial process was drafted in the IRC meeting on [http://sourceforge.net/mailarchive/attachment.php?list_name=openvpn-devel&message_id=4B7E88AC.9030701%40openvpn.net&counter=1 18th Feb 2010]. It has since been discussed in detail on the  [http://sourceforge.net/mailarchive/forum.php?forum_name=openvpn-devel devel mailinglist] in the ''"[PATCH v2] Do not randomize resolving of IP addresses in getaddr()"'' thread. In the IRC meeting on [wiki:IrcMeetings 22nd July 2010] it was decided to simplify the FRP somewhat by removing the "display a runtime warning" phase.
 
  1. '''Ask users if they are depending on a feature considered for deprecation''' (e.g. using the openvpn-users mailing list)
   * If users complain, discuss the issue and possible solutions with them
   * If there are no complaints, proceed to 2
- 1. '''Warn the user about feature deprecation on application startup'''. The deprecated code itself can also output a warning itself, depending on how often it's triggered. The warning can be a simple log message (e.g. "WARNING: this feature is being deprecated and will be removed soon"). The deprecated code will still be enabled by default. 
+ 1. '''Make the feature disabled by default, but allow enabling it at compile-time'''
   * If users complain now, discuss the issue and possible solutions with them
   * If there are no complaints, proceed to 3
- 1. '''Make the feature disabled by default, but allow enabling it at compile-time'''
+ 1. '''Remove the feature entirely from the code'''
   * If users complain now, discuss the issue and possible solutions with them
   * If there are no complaints, proceed to 4
- 1. '''Remove the feature entirely from the code'''
-  * If users complain now, discuss the issue and possible solutions with them
-  * If there are no complaints, proceed to 5
  1. '''Finished.''' The feature was not really important to anyone and is not cluttering the code anymore.
 
- == Overview over features undergoing FRP ==
+== Overview over features undergoing FRP ==
+
 The [https://community.openvpn.net/openvpn/query?status=accepted&status=assigned&status=new&status=reopened&group=severity&order=priority&col=id&col=summary&col=status&col=owner&col=milestone&col=component&col=version&col=changetime&report=9&type=FRP+-+Feature+Removal+Process Feature Removal Process] view found under [https://community.openvpn.net/openvpn/report View Tickets] contains a list over all features going through this process.
 
- == Moving features "down the ladder" ==
+== Moving features "down the ladder" ==
 
-It is probably easiest move features down the ladder (see steps in above paragraph) is when new stable releases are made. This allows users to be certain that no features they use are removed without a warning and time to react. Assuming one release takes ~12 months and a feature is deprecated in "testing" just ''after'' a stable release is made, it will stay in the code for
+It is probably easiest move features down the ladder (see steps in above paragraph) is when new stable releases are made. This allows users to be certain that no features they use are removed without a warning and time to react. Assuming a feature is deprecated just ''after'' a stable release is made, it will be available for quite a while:
 
- * 12 months (in testing, outputs a runtime warning)
- * 12 months (in stable, outputs a runtime warning)
- * 12 months (in stable + 1, disabled but available)
+ * enabled by default in release + 0
+ * disabled but available in release + 1
+ * remove in release + 2
 
-So it'll take 24 - 36 months to get rid of a feature, depending on when (in the release cycle) it's deprecated. There are ways to speed up the
-process. We can, for example, have two processes depending on feature type:
+There are ways to speed up the process. We can, for example, have two processes depending on feature type:
 
  1. Longer process for features we know people depend on, but which '''need''' to be removed nevertheless (for whatever reason)
  1. Shorter process for features somebody _might_ use - like the randomization feature discussed earlier
 
-The full FRP with steps 1-4 would suit type 1 features. Type 2 features could skip step 3 (''"disabled but available"'')
-to save time. It should be relatively easy to spot type 1 features: a mail to the -users mailing list should trigger loud complaints if a
-feature is widely used. Also, users have plenty of time to react to the warnings during the 12-24 month period.
+The full FRP with steps 1-3 would suit type 1 features. Type 2 features could skip the "disabled but available" step to save time. It should be relatively easy to spot type 1 features: a mail to the -users mailing list should trigger loud complaints if a feature is widely used. Also, users have plenty of time to react to the warnings.
 
- = What to do - code wise =
+= What to do - code wise =
 
 It important that each feature deprecation / removal is documented visibly in the release notes of each stable release.
 
- == First phase: Disable the feature on request ==
+== First phase: Disable the feature on request ==
 
  * Remove the feature by using #ifdef's wherever this feature is called or executed in the source code