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 _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
