sm-discuss AT lists.ibiblio.org
Subject: Public SourceMage Discussion List
List archive
Re: [SM-Discuss] How to handle multi-version spells
- From: Eric Sandall <eric AT sandall.us>
- To: sm-discuss AT lists.ibiblio.org
- Subject: Re: [SM-Discuss] How to handle multi-version spells
- Date: Thu, 12 May 2005 15:10:22 -0700
Quoting "Sergey A. Lipnevich" <sergey AT optimaltec.com>:
> No, your understanding is correct. But, this is not good enough (that's why
> I
> started the whole thread about choice), because it will produce even more
> confusion than it provides choice. This makes safe spells update together
> with
> unsafe ones, and provides no incentive for the user to know what's going
> into
> the build. When we're talking about "latest source" spells, their ideal use
> case is to (a) look at the source code or follow developers' mailing list;
> (b)
> whenever some new feature is finalized (*not* every day) *consciously*
> choose
> to update. Both of these steps are missing in the proposed technical
> solution.
>
> The alternative would be to keep VERSION=$(date) proposal but make a list of
> spells updated by "sorcery system-update" advisory, asking a user not what
> to
> *remove* from this list, but what spells to *include* into initially empty
> update list. For example, spells A, B have new versions, spells C, D have
> patches, spells E, F are force-updated, please pick the ones to update now?
> Of
> course, that'd require more effort from users, so it's not really
> acceptable.
>
> Anyway, I am getting tired of this whole discussion, so with my
> opposition being
> registered, I'll accept whatever the majority wants.
>
> Sergey.
(defaults in this case are referring just to the update code we're talking
about)
Or we could just assume that our users are intelligent enough to either
1) Use the defaults if they don't know what it's for
2) If they don't use the defaults then they should know what they're doing and
understand that this might break packages.
I don't see why we should treat the users as though they can't make their own
decisions about their system wisely. We're not here to coddle them (last I
checked). ;)
-sandalle
--
Eric Sandall | Source Mage GNU/Linux Developer
eric AT sandall.us PGP: 0xA8EFDD61 | http://www.sourcemage.org/
http://eric.sandall.us/ | SysAdmin @ Inst. Shock Physics @ WSU
http://counter.li.org/ #196285 | http://www.shock.wsu.edu/
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-
Re: [SM-Discuss] How to handle multi-version spells
, (continued)
-
Re: [SM-Discuss] How to handle multi-version spells,
Arwed von Merkatz, 05/12/2005
- Re: [SM-Discuss] How to handle multi-version spells, Sergey A. Lipnevich, 05/12/2005
- Re: [SM-Discuss] How to handle multi-version spells, Arwed von Merkatz, 05/12/2005
- Re: [SM-Discuss] How to handle multi-version spells, Sergey A. Lipnevich, 05/12/2005
- Re: [SM-Discuss] How to handle multi-version spells, Arwed von Merkatz, 05/12/2005
- Re: [SM-Discuss] How to handle multi-version spells, Sergey A. Lipnevich, 05/12/2005
-
Re: [SM-Discuss] How to handle multi-version spells,
Arwed von Merkatz, 05/12/2005
- Re: [SM-Discuss] How to handle multi-version spells, Sergey A. Lipnevich, 05/12/2005
- Re: [SM-Discuss] How to handle multi-version spells, Eric Sandall, 05/12/2005
- Re: [SM-Discuss] How to handle multi-version spells, Sergey A. Lipnevich, 05/12/2005
- Re: [SM-Discuss] How to handle multi-version spells, Eric Sandall, 05/12/2005
-
Re: [SM-Discuss] How to handle multi-version spells,
Arwed von Merkatz, 05/17/2005
- Re: [SM-Discuss] How to handle multi-version spells, Andrew, 05/17/2005
-
Re: [SM-Discuss] How to handle multi-version spells,
Arwed von Merkatz, 05/08/2005
-
Re: [SM-Discuss] How to handle multi-version spells,
Sergey A. Lipnevich, 05/11/2005
- Re: [SM-Discuss] How to handle multi-version spells, Arwed von Merkatz, 05/12/2005
-
Re: [SM-Discuss] How to handle multi-version spells,
Sergey A. Lipnevich, 05/11/2005
- Re: [SM-Discuss] How to handle multi-version spells, Sergey A. Lipnevich, 05/11/2005
Archive powered by MHonArc 2.6.24.