Public SourceMage Discussion List

[David Kowis <dkowis AT shlrm.org>]

On 06/17/2011 01:07 AM, flux wrote:
> 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.

A post to the mailing list is insufficient. If an upgrade is going to
break someone's database with no way of going back to the prior version,
there should be logic in the spell to ask if they're ready to do the
update yet. It will default to no, and won't let them update. That's how
other spells have handled breaking changes like that in the past. It
ensures the sysadmin knows that this update is going to hoze stuff and
has allocated sufficient time to make the upgrade manually. That is the
only safe way to handle things.

> 
> 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.
> 

I would propose the general default be:

If a spell is going to significantly change functionality (major version
change, removal of multiple spell versions), there must be logic in
PREPARE that will check to see if they're making that version change (if
it's already installed, or installed at an incompatible version) which
will default to NO and require the Sysadmin's intervention to proceed.

This way people's systems remain operational, if out of date.

David

Attachment: signature.asc
Description: OpenPGP digital signature