Public SourceMage Discussion List

[flux <flux AT sourcemage.org>]

George Sherwood (pilot AT beernabeer.com) wrote [11.06.17 10:17]:
> Definitely an admirable goal, but I think it might be difficult to
> implement one policy dealing with all cases.
> 
> I don't use mysql for anything serious, so I can't speak to the issues
> with the 5.1 to 5.5 upgrade, but I am against creating a list of spells
> versioned by name.  As with gnome and most other spells, I believe that
> when you cast the spell with the proper name, you should be default
> receive the current upstream stable versions.
> 
> I also don't want to break every one's system with this type of update
> if the SA isn't paying attention, but honestly if you are using mysql
> for something very serious, I would expect that you are not just
> blindly running update and would better understand the implications of
> all update even within a series.
> 
> As a general policy, I believe a note to the mailing ist prior to
> committing the spell to test, should be sufficient in almost every
> case.
> 
> George Sherwood

I agree that a post to the mailing list should be sufficient to let
users know of "impending doom". However, the impetus of my original post
was more about how we handle major updates vs. spell versioning in a
general way. Currently there is no defined goal for how they should be
handled (not even a general guideline that can be broken). It is
entirely up to whomever is updating the spell. This causes confusion,
not only for users (a simple update to get the new version, cast -r, or
casting an entirely different spell?), but also for developers (like the
mysql case which prompted this thread in the first place). People are
unsure what should or is likely to be done.

If we have some kind of guideline (I don't intend policy to mean
something forever set in stone, that if violated results in 30 lashes),
then developers who are coming across this problem for the first time
may be more informed about what a good solution might be, and users
might be more alert to when a potential problem might be coming. For
example, if it is a general rule of thumb that major splits like this
one are handled via a separate spell, then a user will know that she can
be lazy with watching the mailing list regarding updates, because a
system-update would only use the same spell and (generally) wouldn't
involve a backwards incompatible update. Vice versa, if the general rule
were to have a single spell with just the most recent stable, then the
user would know she needed to be more adamant in watching the mailing
list, even if she weren't so adamant in watching the upstream mailing
list for the spell itself.

In other words, I'm not suggesting that we have a be-all-end-all single
policy. I'm just suggesting that it would be advantageous to discuss and
(if possible) settle on a good 'default' for how to handle these
situations. Corner cases will just be deviations from the default, and
of course allowed. If we have the default, then perhaps we might require
that deviations, though allowed, be explained and accounted for, but
that could be a further decision taken down the road.

As an added point, if we have at least a general default, it *might*
make some form of automated testing more feasible, as tests could be
written for the default case (which presumably would become the majority
in the spells), and either have a list of exceptions for the corner
cases or carefully examine all the spells that failed testing to see if
they failed from being a corner case or genuine failure.

-- 
Justin "flux_control" Boffemmyer
Cauldron wizard and general mage
Source Mage GNU/Linux
http://www.sourcemage.org

Attachment: pgpzEkbhk0IDd.pgp
Description: PGP signature