[Gusdev-gusdev] schema features v. patches

[Steve F. <st...@pc...>]

  folks-

as the mail thread attached demonstrates, we are trying to figure out 
how to handle changes to the schema.  (the case attached arose because 
we upgraded our dbEST parser but never got a chance to test it on the 
schema before the schema was released, and now we have an urgent need to 
run the dbEST parser).

as we know, jonathan crabtree is our point man on this issue.

the main goal i see is to have a light-weight process in place for 
handling this.

here are my thoughts:

1. we need to decide which version of the schema the public schema 
browser points to.  it seems to me that it must always point to the most 
recent official version of the schema.  at CBIL, this might mean we need 
a db instance which is neither production nor development that houses 
the official schema.

2. i am going to venture the following tentative definition of a bug:
     - a correction to something we are already modelling
     - does not introduce any new tables
     - can it introduce new attributes?
     - *does not require migrating data*

3. if we do go with such a bug notion, then which tracker do we use? 
 here is a proposal:
    - all schema changes --bugs and features-- go to the schema feature 
tracker (might have to rename it)
    - after we release a version of the schema (including a patched 
version, eg 3.0.1) we add a "group" to the tracker called, eg, "3.0.1 
(bug)"  and any bugs against that version are tagged with that group
    - after we release a version of the schema, we add a "group" for the 
next version of the schema, eg "3.1".   feature requests are tagged with 
this group.  ultimately, we decide as a team which requested features 
are going to make it into the 3.1 release.  any that don't are either 
re-tagged with the next release "3.2" or maybe relegated to a "not 
scheduled yet" group.   Jonathan is responsible for making these changes 
(expressing the consensus).

4. we develop a light-weight mechanism for "patching" an instance, ie, 
the scripts that will surgically make the patch.  these always work on 
the most recent official version of the schema.  eg, patch 3.0.7 is only 
officially applicable to the 3.0.6 version of the schema

steve

-------- Original Message --------
Subject: Re: dots.est.polyA_siganl
Date: Mon, 17 Feb 2003 10:14:42 -0500 (EST)
From: "Deborah F. Pinney" <pi...@sn...>
To: Angel Pizarro <an...@sn...>
CC: Jonathan Crabtree <cra...@sn...>, Steve Fischer 
<st...@pc...>, <cb...@sn...>



Please note, changes are needed for otehr tables too including Clone,
Library,  and NASequenceImp.

NaSequenceImpOn Mon, 17 Feb 2003, Angel Pizarro wrote:

> On Mon, 17 Feb 2003, Jonathan Crabtree wrote:
>
> >
> > On Fri, 14 Feb 2003, Angel Pizarro wrote:
> > >
> > > right, sorry about that, I changed the assignment from Bugs to GUS Schema
> > > Features and assigned category = DoTS and group = 3.0
> >
> > We could actually handle this (and changes like this) in one of two ways:
> >
> >  1. Treat this as a feature request/schema change for 3.1 (since 3.0 is
> >     now "out the door" in some sense).  In that case, the appropriate
> >     group would be 3.1, not 3.0 (and we would create schema change entries
> >     in group 3.1 *before* the release of that version, versus bug fixes
> >     for version 3.1, which would be assigned to that group only *after*
> >     3.1 has been released.)
> >  2. Treat this as a bug/omission in 3.0.  In this case the chosen category
> >     (3.0) is correct, but we then have to worry about the issue of
> >     providing patches (so that people who have already downloaded what
> >     they thought was the 3.0 release can get updated to the version with
> >     the "bug" fix).
> >
> > I'd be inclined to go with #1, except in cases where the change is quite
> > clearly a bug.  For example, if we know (and have documented that!) the
> > est.polyA_signal column is supposed to be an exact replica of a column in
> > dbEST, and we fail to give it the same datatype/constraints, then that
> > is clearly a bug.  The problems we're running into with EST table at the
> > moment will hopefully not happen in future because we plan to actually
> > test and "certify" all the plugins against the proposed schema before
> > doing a release.
>
> I am for #2 since it is as you say a known bug. Which was why I had
> originally submitted it as a bug report, until Steve said that was not the
> place for these things. As debbie noted in a very recent email, there are
> other bugs that need to be addressed. We can prvide one large patch for
> the EST table to encompass all of the needed changes, or give them
> piece-meal. Or both.
>
> Angel
>
> PS. Sorry, I forgot about the version table change to the polya_signal
> column. Shoddy workmanship. won't happen again.
>