Public SourceMage Discussion List

[George Sherwood <pilot AT beernabeer.com>]

On Fri, 17 Jun 2011 09:31:11 +0900
flux <flux AT sourcemage.org> wrote:

> David Haley (khoralin AT gmail.com) wrote [11.06.17 01:18]:
> > 
> > On Jun 14, 2011, at 3:45 PM, George Sherwood wrote:
> > 
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > > 
> > > On Tue, 14 Jun 2011 12:23:55 -0500
> > > David Haley <khoralin AT gmail.com> wrote:
> > > 
> > << snip >>
> > 
> > > At one time I was looking at this also and leaning toward you 2nd
> > > option (removing the oldest version) and making the current the
> > > default.
> > > 
> > > The issue that I ran into though, is the fact that it appears they
> > > changed to the build system (I think cmake) if I remember
> > > correctly. Many of our current options are not valid and it
> > > really is a re-write of the spell from the ground up or you are
> > > going to have to maintain both build methods in one spell which
> > > seemed to all a lot of clutter and will make maintenance very
> > > difficult.
> > > 
> > That being said if build requirements are not changes due the move
> > upstream that makes me want to lean even more to starting a new
> > spell from scratch. I agree that if we go the two separate paths it
> > is going to be difficult to maintain.
> > 
> > > Given that I was tempted to just renaming the old spell and
> > > building a new mysql spell from scratch with the new build system
> > > and new options.
> > 
> > I am leaning away from having older spells for things in the long
> > run. I would like to propose that we use only a single version
> > spell and write it new to handle the new build environment in Test.
> > We leave Stable as it is for the moment, but, when the next branch
> > comes out I would like to (thinking long-term) we would nuke the
> > multi-version spell in Stable, move what would no be new to Stable,
> > and update the single version spell accordingly in Test.
> 
> I personally don't use MySQL, but I have a concern here consisting of
> two words: upgrade path. If you simply drop the older versions, anyone
> who is using the mysql path will be upgraded (via a sorcery
> system-upgrade, for example). Does the new version break backward
> compatibility in some way? Does it do so in a way that is easy to fix,
> as long as the user is warned? Does it do so in a way that is a real
> pain to fix?
> 
> If the spell can be upgraded easily without damaging a running system,
> then I see no problem with just dropping the older versions. If an
> upgrade would require damage control, then I think more thought needs
> to go into how it would be handled. Having separate spells would
> mitigate this problem, but only for the 5.1<->5.5 split, so the
> problem could surface again after 5.5. Will we create a new mysql
> spell for each split? How long will we keep each one around?
> 
> I know that as a distro we tend away from having hard set policies,
> but the question of spell versioning has come up often enough that I
> think it's time we come up with policies for it. There are situations
> like this where it will be impossible to have a best-case scenario.
> If we have a policy that clearly states how we will handle it, then
> both spell-writers and users will know what to expect. Then when an
> update causes a big change, we can still do the update but with
> sufficient warning to the end user per the policy-defined update
> process (whatever that ends up being). This will also require clearly
> defined communication plans/channels that users can be aware of. That
> way we aren't caught in limbo as developers, and users don't get
> shafted because they'll know what to expect.
> 
> +2 cents
> 


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

Attachment: signature.asc
Description: PGP signature