On 02/24/2010 02:36:45 AM, Samuli Seppänen wrote:
>
> >> If someone who explicitly chooses a functionality
> >> needs to get a warning about the default they
> >> should get this warning at ./configure time --
> >> the time they make the choice.
> >>
> >
> > The only time I can think of that a warning should
> > be delivered to those who explicitly choose
> > functionality in the process of deprecation
> > is to, _after_ the default has changed,
> > deliver a ./configure time warning to those
> > who explicitly choose the default telling them
> > that they no longer have to be explicit because
> > they are choosing what is now the default.
> >
> > It hardly seems worth it.
> >
> >
> Runtime warnings about deprecated features are important for users
> who
> use packages rather than build from source.
Yes. I've since had second thoughts about this. It seems to me
that there should be ./configure options for the use of package
maintainers that allow the enable/disablement of such runtime
warnings. Maintainers may decide to that some features are part
of their distribution, put a note in their changelog, and move forward.
>
> Could you guys take a look at the current FRP draft and let me know
> if
> it needs modifications:
I need to re-read it. Particularly with an eye towards changes
that are only enabled at compile time v.s. changes to defaults
that the user requests at runtime in the OpenVPN config file.
...
> So it'd 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 could, 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)
> 2) shorter process for features somebody _might_ use - like the
> randomization feature discussed earlier
By putting control over runtime warning messages into ./configure
(along with the enablement of the feature iteslf)
you put control over deciding which features fall into category 1
and which in category 2 into the hands of the end-user. This
becomes significant when you put such control into the hands
of a distribution's package maintainer who can set policy
for entire groups of users. A distro maintainer can
enable the feature and turn off the warning and speed
up the process of depreciation for their users if they
think the change is trivial.
I would think that this would be the best way to make as
many people happy as possible.
And of course OpenVPN retains
control over the ./configure defaults which can be nice
and conservative. Taking 24-36 months to change something can
be a good thing.
Karl <k...@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
