Re: New module decisions for 2.16

[David Nielsen <david lovesunix net>]

ons, 09 08 2006 kl. 22:55 +0800, skrev Davyd Madeley:
> On Wed, Aug 09, 2006 at 03:08:40PM +0200, Vincent Untz wrote:
> > On mar, 2006-08-01 at 14:31 -0600, Elijah Newren wrote:
> > >  + Sticky notes
> > >    => mostly duplicates functionality of Tomboy
> > >    => general agreement to deprecate sticky notes for now and remove
> > >       it in a later release
> > >    => 'deprecation' means hidden from the user and some kind of
> > >       warning for those trying to use it
> > 
> > Davyd, is there anything we can do to help here, or is this something
> > you can handle?
> 
> Ok. Here is a suggested migration path.
> 
> Since some users will not be able to use Tomboy (on systems that are
> not Mono enabled), we should keep stickynotes around. I propose we
> do the same as we currently do with mini-commander, that is by
> default it will transparently upgrade people's stickynotes to
> tomboy.
> 
> We then have a --enable-stickynotes flag, that will cause
> stickynotes to be compiled and installed (installing with this flag
> will also cause people's whose stickynotes to get upgraded to Tomboy
> will then cause it to go back again). We then leave it up to package
> distributors to decide if they want to break this out as a separate
> package or not.
> 
> Sound reasonable?

To avoid this debate in the future it would be nice if we could come up
with a standard protocol for handling application replacements. Aside
preserving the users data, deciding how we rid ourselves of the old
program is an acceptable fasion would be nice.

If we do seperate out the program out with the option to reenable it,
then how long do we keep it that way, one cycle, two cycles or more? I
mean we definately don't want a situation where such programs sit around
forever. We also shouldn't encourage a situation where the norm is "as
long as it's desired" because that means defacto shipping both
applications and maintaining them both to a degree forever (there will
after all always be a group of users however small that would like to
keep a given program).

I would favor something general like, --enable-deprecated=application
and have the standard be keeping it during the cycle we mark them and
the next one, after which they get removed from the shipped product. If
someone wants to pick it up and maintain it seperately after scheduled
removal then that would be a fine solution for the code rather than
death. We might also want to keep a centralised list of items scheduled
for removal along with rationale like the kernel does, it seems to work
nicely for them so odds are it will be a decent solution for us as
well. 

What kinds of warnings do we want to display to the user or should we
leave that to the vendors? If they want to keep an application around
telling their users that it will go away would not be the best possible
approach. I think it should continue to work as always, a vendor has to
take active steps to reenable a given application with the knowledge
that it will go away after a given date and as such can take the steps
they see fit to either move over to the new application or arrange for
maintainership of the old one at their leisure.

- David Nielsen