gusdev-gusdev — Topics concerning GUS development

[GUSDEV] Writing Commit Messages

[Michael S. <msa...@pc...>]

I wanted to propose a couple of recommendations for writing good commit
messages.  Ultimately, I'd like to use the commit messages to effortlessly
track changes in GUS release, which is partly motivation for this.

* Always provide a log message.

* Use the log message to address the reasons behind the change, not just the
change.  For example (and sorry to pick on Debbie-- she's just the most
recent committer):

"remove statement to skip entries from tpg"

This is obvious from the code, but I have no idea *why* the tpg entries were
skipped to begin with, and now what change is allowing them to be processed.

* When fixing a bug from bugzilla, reference the bug number.  For example:

"Fixed bug #27, 'unable to run LoadTaxon'"

While this message doesn't really provide many details, it points to the bug
id that should provide a wealth of information about the debugging process.

* Try to avoid "fixed typo" log messages.  Sometimes, however, that's all
that happened :).  Which raises another point:  test and compile (perl -c)
*before* you check-in.

Any other ideas for source control log messages best practices?  I'll start
a wiki where we can track these.

--Mike

Re: [GUSDEV] managing GUS releases

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

all-

i think fernan layed out a lot of good issues, and i think mike very 
accurately offered what we have in mind.

the brief version is:
  - we branch when we make a release, eg, 3.7
  - as bugs come up in 3.7, we modify that branch, and merge into the 
trunk as needed.
  - when the release master determines that the bug fixes need to be 
released (a balance between their urgency and his/her time), he or she 
tags the branch with 3.7.1, and does the release to the download site.   
(if we're clever we'll  augment the build system's release facility to 
take care of all of this with a button push).
  - users of gus get their version of gus exclusively from the download 
site.
  - we separate the GUS schema and the GUS App. Framework into their own 
projects and release them on their own independent schedule, but the 
download site instructs the user as to their compatibility.

steve

Michael Saffitz wrote:

>Hi Fernan,
>
>Comments below.
>
>On 7/7/05 10:35 AM, "Fernan Aguero" <fe...@ii...> wrote:
>
>  
>
>>+----[ Steve Fischer <sfi...@pc...> (06.Jul.2005 20:29):
>>|
>>| Fernan-
>>| 
>>| see below for response to your first point.
>>| 
>>| for your second point, i strongly urge you to cut and paste into a new
>>| posting to the group with an appropriate subject.   its too important a
>>| topic to be buried inside this one.
>>
>>OK, will do.
>> 
>>| steve
>>| 
>>| Fernan Aguero wrote:
>>| 
>>| >Steve,
>>| >
>>| >here are my ideas about the part of your proposal that deal
>>| >with 'managing branches'.
>>| >
>>| >I agree with you on the branching before release, therefore
>>| >freeing the main trunk for continuing development towards
>>| >future versions. I also agree on the 'tagging' of already
>>| >released branches to provide landmarks of bug fixing
>>| >activity. However I think that it should also be pointed out
>>| >that usually you don't need to wait for the release engineer
>>| >to post a new tarball ... in your example, people can just
>>| >track the '3.6' branch and get all bug fixes irrespective of
>>| >the minor version. Am i correct?
>> 
>>| i am not sure i understand what you mean by tracking the 3.6 branch.
>>| perhaps you mean downloading from the repository directly using the
>>| tag?   the one thing we don't want is for people to download and use
>>| untagged versions.  then we don't know what they have, and can't
>>| properly track bugs, etc
>>|
>>+----]
>>
>>It's my personal bias towards a source centric view of the world :)
>>And it's also part of my FreeBSD heritage, where 'tracking' is
>>intimately related to the use of cvsup to sync sources
>>against a cvs repository.
>>http://www.polstra.com/projects/freeware/CVSup/
>>http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html
>>http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/synching.html
>> 
>>The thing I was trying to say is that once you do a major
>>release, the branch (3.6 in this example) does not undergo
>>further development. So if this is set as a policy (in
>>FreeBSD old releases are owned by a security officer and
>>normal people with commit privileges (committers) cannot
>>under any circumstances make changes to these branches) then
>>anyone 'checking out' the 3.6 branch using cvs (not the
>>tagged release, because there maybe bug fixes since the
>>release) or 'tracking' the 3.6 branch using cvsup (if you
>>find it useful to have a cvsupd server installed) is sure to
>>have the latest and most up to date version in the 3.6 line.
>>
>>    
>>
>
>As a matter of policy, it's my understanding that we all agree that a
>particular release branch will not have any further feature development--
>only bug fixes.  But I should also point out that non-urgent bugs could also
>be provided in the trunk for the next release and never released as part of
>a patch to the current release.
>
>  
>
>>You might as well tag the repository for each bug that is
>>fixed, but this assumes that there will be little activity
>>... so you will have 3.6p1 (patch 1), 3.6p2, and so on. If
>>the activity is higher, then tagging that much maybe
>>overkill.
>>    
>>
>
>Yes--- I think that's overkill.  After all, with subversion (which we're
>using) each checkin is numerically tagged anyway.
>
>  
>
>>The thing here is making the load lighter on the
>>release engineer ... just do the hard work (getting tarballs
>>out the door) for major releases. Users get minor releases
>>and bug fixes by applying patches or updating their sources
>>from the repository. What if you release 3.6.1 and
>>then notice that you missed a critical file or bug fix? You
>>need to do another release, 3.6.2. This is not necessary if
>>users checkout/track the repository. Does this sound
>>reasonable? 
>>    
>>
>
>The issue is that user's won't have a working copy to update-- their
>original should be from the distributable.  I think downloading the updated
>distributable is a trivial task, but I do agree that we could do more to
>make it even easier (I'm thinking specifically here about if a file is
>deleted as part of the release-- simply rerunning build GUS install -append
>won't remove that file in the gus_home which could cause issues).
>
>  
>
>>As to the issue of users working with 'untagged' versions,
>>this is just a matter of educating users. And keep reminding
>>people on the mailing list that they should do a cvs update
>>(or cvsup) and check their problem against the most current
>>version on any branch.
>>
>>    
>>
>
>No.  The most current version will frequently be the trunk, which may not be
>stable.  If people find an issue in their release, they should:
>
>1) Check the bug tracker to see if the issue is known and/or resolved.
>    * If unknown, file a bug
>    * If known, and fixed, and released: upgrade if possible
>    * If known, and fixed, and unreleased: if urgent, apply patch
>    * If known and not fixed: submit patch or wait
>
>
>  
>
>>Again, the idea is that the changes that go into these
>>'maintainance' branches should be easily applied to
>>production sites. They should not break anything, so there
>>shouldn't be a problem updating a gus installtion against
>>the most recent version in the same branch.
>>
>>It's just a suggestion. I would always prefer to track the
>>3.6 branch instead of downloading separate 3.6.1, 3.6.2,
>>etc. versions. And of course this doesn't preclude that you
>>might do minor releases where appropriate.
>>    
>>
>
>And that's ok for people comfortable with it, but I think for most people,
>the new "traditional" release/distributable paradigm will provide a better
>experience.
>
>These, of course, are just my opinions/suggests...  We should make sure the
>community is comfortable with whatever the "recommended" approach is.
>
>  
>
>>Fernan
>>
>>
>>-------------------------------------------------------
>>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>>from IBM. Find simple to follow Roadmaps, straightforward articles,
>>informative Webcasts and more! Get everything you need to get up to
>>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>_______________________________________________
>>Gusdev-gusdev mailing list
>>Gus...@li...
>>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>    
>>
>
>  
>

[GUSDEV] workshop summary

[Fernan A. <fe...@ii...>]

I had to leave early today to teach a class. I know a
discussion on future plans is scheduled next, maybe someone
can write a summary to the list with the agreed path of
action for each of the different GUS areas (schema, plugins,
wdk, etc?)

Thanks to all for a great workshop! And a very special
thanks to Mike and the others that had taken the moderator
role,    

Fernan

Re: [GUSDEV] managing GUS releases

[Fernan A. <fe...@ii...>]

+----[ Michael Saffitz <msa...@pc...> (08.Jul.2005 11:01):
|
| Hi Fernan,

Hi Mike,

[snipped]
 
| > The thing I was trying to say is that once you do a major
| > release, the branch (3.6 in this example) does not undergo
| > further development. So if this is set as a policy (in
| > FreeBSD old releases are owned by a security officer and
| > normal people with commit privileges (committers) cannot
| > under any circumstances make changes to these branches) then
| > anyone 'checking out' the 3.6 branch using cvs (not the
| > tagged release, because there maybe bug fixes since the
| > release) or 'tracking' the 3.6 branch using cvsup (if you
| > find it useful to have a cvsupd server installed) is sure to
| > have the latest and most up to date version in the 3.6 line.
| > 
| 
| As a matter of policy, it's my understanding that we all agree that a
| particular release branch will not have any further feature development--
| only bug fixes.  But I should also point out that non-urgent bugs could also
| be provided in the trunk for the next release and never released as part of
| a patch to the current release.

Of course. This will be ultimately driven by usage of past
releases. If newer releases are not widely adopted, or take
some time to get into production sites then probably there
is more pressure to merge fixes back.  

| > You might as well tag the repository for each bug that is
| > fixed, but this assumes that there will be little activity
| > ... so you will have 3.6p1 (patch 1), 3.6p2, and so on. If
| > the activity is higher, then tagging that much maybe
| > overkill.
| 
| Yes--- I think that's overkill.  After all, with subversion (which we're
| using) each checkin is numerically tagged anyway.

You mean that the whole branch gets tagged for a commit to
one or more files? That is overkill, but since subversion is
doing it ... it's fine then. Users can then use these
'patchlevel' numbers to get to a specific patchlevel or
revision?

| > The thing here is making the load lighter on the
| > release engineer ... just do the hard work (getting tarballs
| > out the door) for major releases. Users get minor releases
| > and bug fixes by applying patches or updating their sources
| > from the repository. What if you release 3.6.1 and
| > then notice that you missed a critical file or bug fix? You
| > need to do another release, 3.6.2. This is not necessary if
| > users checkout/track the repository. Does this sound
| > reasonable? 
| 
| The issue is that user's won't have a working copy to update-- their
| original should be from the distributable.  I think downloading the updated
| distributable is a trivial task, but I do agree that we could do more to
| make it even easier (I'm thinking specifically here about if a file is
| deleted as part of the release-- simply rerunning build GUS install -append
| won't remove that file in the gus_home which could cause issues).

OK, so maybe this is my bias as a heavy user of cvsup. Given
any working copy (even those obtained from distributables)
cvsup can update it to any given cvs tag/branch as specified
in a config file. cvsup will take care of deleting files
that were deleted in the repository (but it will not
delete files created locally by the user). 

So instead of downloading distributables you just specify
tags/branches in your cvsup config file, point cvsup to the
local directory where the files live, and run cvsup from
cron (every day, every week) or manually. If bug fixes are
rare, you cvsup manually every time there's a bug fixed
announced. If bug fixes are more frequent, you run cvsup
from cron.

| > As to the issue of users working with 'untagged' versions,
| > this is just a matter of educating users. And keep reminding
| > people on the mailing list that they should do a cvs update
| > (or cvsup) and check their problem against the most current
| > version on any branch.
| > 
| 
| No.  The most current version will frequently be the trunk, which may not be
| stable.  

Yes I know, I meant the latest code for any branch the user is
interested in. The trunk will be the most current
*development* version, updating or tracking against the 3.6
branch (or any branch) will get youthe most current version in
that branch. If I'm using a previous release (say 3.5), and
I want to report a bug or problem with this code, I have to
make sure that I have the latest 3.5 code, so I have to
update my working copy (using either a 3.5.x distributable
if it exists, or cvs/cvsup against the 3.5 branch). 

I guess that we're trying to say the same thing: 
 
| If people find an issue in their release, they should:
| 
| 1) Check the bug tracker to see if the issue is known and/or resolved.
|     * If unknown, file a bug
|     * If known, and fixed, and released: upgrade if possible
|     * If known, and fixed, and unreleased: if urgent, apply patch
|     * If known and not fixed: submit patch or wait

only that your third step (if urgent, apply patch) is what
you do when you checkout/update to the latest code in a *branch*.
The alternative here is if the bug was committed to trunk but
not merged into other branches.   

| > Again, the idea is that the changes that go into these
| > 'maintainance' branches should be easily applied to
| > production sites. They should not break anything, so there
| > shouldn't be a problem updating a gus installtion against
| > the most recent version in the same branch.
| > 
| > It's just a suggestion. I would always prefer to track the
| > 3.6 branch instead of downloading separate 3.6.1, 3.6.2,
| > etc. versions. And of course this doesn't preclude that you
| > might do minor releases where appropriate.
| 
| And that's ok for people comfortable with it, but I think for most people,
| the new "traditional" release/distributable paradigm will provide a better
| experience.

Of course, as I said, even if you do the work of providing
point releases for bug fixes, users can always check out
code from the repository either for the tagged point
release, or from any branch (3.5, 3.6). So it's not
something that we should decide or vote on ... it will be
there anyway. 

I'm just trying to point out that the way of
tracking or following a stable branch should be
documented, because if users know about it and feel
comfortable with this way of working, there's less need for
providing minor point releases, which should probably help
you guys have more time for other things. 

On a side note, I just noticed that there is no cvsup
equivalent yet for subversion repositories ... :( 
Hopefully, one will be developed soon.

Fernan

| These, of course, are just my opinions/suggests...  We should make sure the
| community is comfortable with whatever the "recommended" approach is.
|
+----]

Re: FW: [GUSDEV] Load a Blast result using LoadNRDB

[Deborah P. <pi...@pc...>]

And finally I see your attachment and it looks like it is in the right=20
format to be loaded with LoadNRDB. However, if the defline only has a=20
single source_id, I think I would use LoadFastaSequences.pm to load your=20
sequences into dots.AASequence or one of its views. This plugin is=20
generic and loads your choice of sequence tables with source_id, etc=20
defined using regex. I think you will find that more satisfactory.

                                                                         =
                                                                        =20
Debbie




Deborah Pinney wrote:

> I reread your e-mail and am guessing that your file is a file of=20
> sequences (query or subject ?) with information on the defline=20
> pertaining to a BLAST analysis. Perhaps you can send an excerpt of=20
> your file  and a bit more explanation. Perhaps we can make some better=20
> suggestions.
>
>                                                                        =
                                    =20
> Debbie
>
>
>
> Deborah Pinney wrote:
>
>> LoadNRDB.pm is not the appropriate plugin to use to load BLAST=20
>> results into GUS. It is specifically designed to load defline and=20
>> sequence information  from NCBI's non redundant protein database=20
>> files. It uses the gitax file to get taxon information for each of=20
>> the gi numbers in the defline so as to attach a taxon_id. Therefore,=20
>> LoadTaxon would have to be run with NCBI's taxonomy files prior to=20
>> running LoadNRDB.
>>
>> There is at least one plugin that can be used to load BLAST results,=20
>> InsertBlastSimilarities.pm, which is one of the GUS/Supporterd=20
>> plugins. Take a look at that and see if it serves your purposes.
>>                                                                       =
                                                                         =
    =20
>> Debbie
>>
>>                                                =20
>>
>>
>> Michael Saffitz wrote:
>>
>>> Hi Debbie,
>>>
>>> Can you help with this?  I think we should start with an overview of=20
>>> what
>>> LoadNRDB is doing-- specifically how it handles the gitax file.  We=20
>>> can then
>>> figure out if Fabricio's issue is in the data or code.
>>>
>>> Please include gusdev in your reply-- I think it will be useful=20
>>> information.
>>>
>>> --Mike
>>>
>>> ------ Forwarded Message
>>> =20
>>>
>>>> From: Fabr=EDcio <fab...@de...>
>>>> Date: Thu, 9 Jun 2005 16:38:44 -0300
>>>> To: <gus...@li...>
>>>> Subject: [GUSDEV] Load a Blast result using LoadNRDB
>>>>
>>>> Hello all,
>>>>
>>>>
>>>> We=B9re trying to insert a Blast result into Gus Schema using LoadNR=
DB
>>>> plug-in. Our blast result was filtered and is in a Fasta format=20
>>>> according to
>>>> the plug-in requirement. The problem is the load process takes many=20
>>>> times
>>>> and our postgres server process crashes after some hours, thus the=20
>>>> plug-in
>>>> never concludes. I would like to know why this plug-in is so slow,=20
>>>> if the
>>>> file we want to store is not so big. I think that it=B9s due to the
>>>> =ADgitax=3Dgi_taxid_prot.dmp parameter that has a large file.
>>>>
>>>>
>>>>
>>>> Does anyone could help us to understand this?
>>>>
>>>>
>>>>
>>>> Thanks a lot,
>>>>
>>>>
>>>>
>>>> Fabr=EDcio.
>>>>
>>>>  =20
>>>
>>>
>>>
>>> ------ End of Forwarded Message
>>> =20
>>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by the 'Do More With Dual!' webinar=20
>> happening
>> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in du=
al
>> core and dual graphics technology at this free one hour event hosted=20
>> by HP, AMD, and NVIDIA.  To register visit=20
>> http://www.hp.com/go/dualwebinar
>> _______________________________________________
>> Gusdev-gusdev mailing list
>> Gus...@li...
>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>
>

Re: FW: [GUSDEV] Load a Blast result using LoadNRDB

[Deborah P. <pi...@pc...>]

I reread your e-mail and am guessing that your file is a file of=20
sequences (query or subject ?) with information on the defline=20
pertaining to a BLAST analysis. Perhaps you can send an excerpt of your=20
file  and a bit more explanation. Perhaps we can make some better=20
suggestions.

                                                                         =
                                   =20
Debbie



Deborah Pinney wrote:

> LoadNRDB.pm is not the appropriate plugin to use to load BLAST results=20
> into GUS. It is specifically designed to load defline and sequence=20
> information  from NCBI's non redundant protein database files. It uses=20
> the gitax file to get taxon information for each of the gi numbers in=20
> the defline so as to attach a taxon_id. Therefore, LoadTaxon would=20
> have to be run with NCBI's taxonomy files prior to running LoadNRDB.
>
> There is at least one plugin that can be used to load BLAST results,=20
> InsertBlastSimilarities.pm, which is one of the GUS/Supporterd=20
> plugins. Take a look at that and see if it serves your purposes.
>                                                                        =
                                                                         =
   =20
> Debbie
>
>                                                 =20
>
>
>
> Michael Saffitz wrote:
>
>> Hi Debbie,
>>
>> Can you help with this?  I think we should start with an overview of=20
>> what
>> LoadNRDB is doing-- specifically how it handles the gitax file.  We=20
>> can then
>> figure out if Fabricio's issue is in the data or code.
>>
>> Please include gusdev in your reply-- I think it will be useful=20
>> information.
>>
>> --Mike
>>
>> ------ Forwarded Message
>> =20
>>
>>> From: Fabr=EDcio <fab...@de...>
>>> Date: Thu, 9 Jun 2005 16:38:44 -0300
>>> To: <gus...@li...>
>>> Subject: [GUSDEV] Load a Blast result using LoadNRDB
>>>
>>> Hello all,
>>>
>>>
>>> We=B9re trying to insert a Blast result into Gus Schema using LoadNRD=
B
>>> plug-in. Our blast result was filtered and is in a Fasta format=20
>>> according to
>>> the plug-in requirement. The problem is the load process takes many=20
>>> times
>>> and our postgres server process crashes after some hours, thus the=20
>>> plug-in
>>> never concludes. I would like to know why this plug-in is so slow,=20
>>> if the
>>> file we want to store is not so big. I think that it=B9s due to the
>>> =ADgitax=3Dgi_taxid_prot.dmp parameter that has a large file.
>>>
>>>
>>>
>>> Does anyone could help us to understand this?
>>>
>>>
>>>
>>> Thanks a lot,
>>>
>>>
>>>
>>> Fabr=EDcio.
>>>
>>>  =20
>>
>>
>> ------ End of Forwarded Message
>> =20
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar=20
> happening
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dua=
l
> core and dual graphics technology at this free one hour event hosted=20
> by HP, AMD, and NVIDIA.  To register visit=20
> http://www.hp.com/go/dualwebinar
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev

Re: FW: [GUSDEV] Load a Blast result using LoadNRDB

[Deborah P. <pi...@pc...>]

LoadNRDB.pm is not the appropriate plugin to use to load BLAST results=20
into GUS. It is specifically designed to load defline and sequence=20
information  from NCBI's non redundant protein database files. It uses=20
the gitax file to get taxon information for each of the gi numbers in=20
the defline so as to attach a taxon_id. Therefore, LoadTaxon would have=20
to be run with NCBI's taxonomy files prior to running LoadNRDB.

There is at least one plugin that can be used to load BLAST results,=20
InsertBlastSimilarities.pm, which is one of the GUS/Supporterd plugins.=20
Take a look at that and see if it serves your purposes.
                                                                         =
                                                                         =
  =20
Debbie

                                                  =20




Michael Saffitz wrote:

>Hi Debbie,
>
>Can you help with this?  I think we should start with an overview of wha=
t
>LoadNRDB is doing-- specifically how it handles the gitax file.  We can =
then
>figure out if Fabricio's issue is in the data or code.
>
>Please include gusdev in your reply-- I think it will be useful informat=
ion.
>
>--Mike
>
>------ Forwarded Message
> =20
>
>>From: Fabr=EDcio <fab...@de...>
>>Date: Thu, 9 Jun 2005 16:38:44 -0300
>>To: <gus...@li...>
>>Subject: [GUSDEV] Load a Blast result using LoadNRDB
>>
>>Hello all,=20
>>
>>=20
>>
>>We=B9re trying to insert a Blast result into Gus Schema using LoadNRDB
>>plug-in. Our blast result was filtered and is in a Fasta format accordi=
ng to
>>the plug-in requirement. The problem is the load process takes many tim=
es
>>and our postgres server process crashes after some hours, thus the plug=
-in
>>never concludes. I would like to know why this plug-in is so slow, if t=
he
>>file we want to store is not so big. I think that it=B9s due to the
>>=ADgitax=3Dgi_taxid_prot.dmp parameter that has a large file.
>>
>>=20
>>
>>Does anyone could help us to understand this?
>>
>>=20
>>
>>Thanks a lot,
>>
>>=20
>>
>>Fabr=EDcio.
>>
>>   =20
>>
>
>------ End of Forwarded Message
> =20
>

Re: [GUSDEV] GUS schema questions

[Robert O. <ol...@mc...>]

> You want each version of the genome (i.e. the nasequence entries)  
> "tagged" by the different database release versions.  You don't  
> have to further "tag" the associated data, as they are already tied  
> to the nasequence entries, so it's not as clumsy as it may seem at  
> first.

Are you thinking something like this:  our 630.2 data we tag as  
external db "SEED", version "630.2" ? That works for me.

Do you typically store whole contigs in the database, or just the  
NASeq's for the features?

Am I correct that features with multiple exons are stored with the  
exon sequences as multiple NASequences attached to a NAFeature ?

thanks for the patience in the newbie questions :-)

--bob

Re: [GUSDEV] GUS schema questions

[Chris S. <sto...@pc...>]

Hi Bob,
Will try to elaborate on the answer given yesterday. Taxon is NOT to  
be used for designating version. It is the controlled vocabulary for  
organism whose genome has been sequenced (e.g., Yersinia) and is used  
to annotate any genome sequence (or transcript or protein) that  
originated from that organism. ExternalDatabase is used to tag  
datasets that have been loaded into GUS. It can be a genome sequence,  
or microarray data, or a set of ESTs. Project is used to tag datasets  
that belong together. In PlasmoDB we use this to tag the current  
genome and associated automated analyses that we may have run. In RAD  
we use this to relate microarray datasets from the same group.

In terms of the annotations, what you describe I believe is intended  
to assign a possible gene name to the feature. This is different from  
assigning the gene name (or any other annotation) to the gene itself.  
That's done at the central dogma table (DoTS.Gene). To identify the  
gene feature that is reference for a give Gene, you use  
GeneInstance.is_reference.

Hope this helps.
Chris

On Jul 8, 2005, at 9:43 AM, Robert Olson wrote:

> I've been trolling thru the schema browser trying to map the  
> concepts in SEED to those in the schema. (If you want an idea about  
> the system I am discussing, our public SEED server is available at  
> http://theseed.uchicago.edu/FIG/index.cgi ).
>
> I think I've mapped most of them, with the following exceptions.
>
> I asked this in the workshop yesterday, thought I'd repeat it here  
> for the larger group, with a motivating example.
>
> In the SEED, we support having multiple genomes installed for any  
> given taxon. For instance, we have a genome we tag as 630.1 which  
> is Yersinia enterocolitica from NCBI Refseq, and 630.2 which is  
> Sanger's version of that organism. It was discussed in the workshop  
> to use the external database version to tag the difference between  
> these in GUS, but that seems clumsy to me (since I may want that to  
> tag overall SEED data versions). I'm curious what the rank  
> attribute on DoTS.Taxon is intended to be used for; it seems  
> possible I could subvert that to use as the organism version  
> indicator.
>
> The other one is mapping feature annotations. The SEED being a  
> genome annotation system, we need to support the storage of  
> multiple annotations for each feature. The presentation software  
> uses a set of rules to decide which annotation to display as the  
> "current" annotation for a feature (where the usual rule is "latest  
> annotation from a trusted user"). Is DoTS.NAGene the right place to  
> put this, where I'd create a NAFeatureNAGene entry that links the  
> NAFeature for the feature in question to the set of NAGenes  
> containing the annotations?
>
> thanks,
> --bob
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar  
> happening
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in  
> dual
> core and dual graphics technology at this free one hour event  
> hosted by HP,AMD, and NVIDIA.  To register visit http://www.hp.com/ 
> go/dualwebinar
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>

Re: [GUSDEV] GUS schema questions

[Aaron J. M. <am...@pc...>]

On Jul 8, 2005, at 9:43 AM, Robert Olson wrote:

> In the SEED, we support having multiple genomes installed for any  
> given taxon. For instance, we have a genome we tag as 630.1 which  
> is Yersinia enterocolitica from NCBI Refseq, and 630.2 which is  
> Sanger's version of that organism. It was discussed in the workshop  
> to use the external database version to tag the difference between  
> these in GUS, but that seems clumsy to me (since I may want that to  
> tag overall SEED data versions). I'm curious what the rank  
> attribute on DoTS.Taxon is intended to be used for; it seems  
> possible I could subvert that to use as the organism version  
> indicator.
>

You have multiple genomes for one organism.  That one organism is in  
DoTS.Taxon, and it's rank is what the NCBI taxonomy database  
specifies as "genus", "phylum", "subspecies", etc.

You want each version of the genome (i.e. the nasequence entries)  
"tagged" by the different database release versions.  You don't have  
to further "tag" the associated data, as they are already tied to the  
nasequence entries, so it's not as clumsy as it may seem at first.

-Aaron

--
Aaron J. Mackey, Ph.D.
Project Manager, ApiDB Bioinformatics Resource Center
Penn Genomics Institute, University of Pennsylvania
email:  am...@pc...
office: 215-898-1205
fax:    215-746-6697
postal: Penn Genomics Institute
         Goddard Labs 212
         415 S. University Avenue
         Philadelphia, PA  19104-6017

Re: [GUSDEV] managing GUS releases

[Michael S. <msa...@pc...>]

Hi Fernan,

Comments below.

On 7/7/05 10:35 AM, "Fernan Aguero" <fe...@ii...> wrote:

> +----[ Steve Fischer <sfi...@pc...> (06.Jul.2005 20:29):
> |
> | Fernan-
> | 
> | see below for response to your first point.
> | 
> | for your second point, i strongly urge you to cut and paste into a new
> | posting to the group with an appropriate subject.   its too important a
> | topic to be buried inside this one.
> 
> OK, will do.
>  
> | steve
> | 
> | Fernan Aguero wrote:
> | 
> | >Steve,
> | >
> | >here are my ideas about the part of your proposal that deal
> | >with 'managing branches'.
> | >
> | >I agree with you on the branching before release, therefore
> | >freeing the main trunk for continuing development towards
> | >future versions. I also agree on the 'tagging' of already
> | >released branches to provide landmarks of bug fixing
> | >activity. However I think that it should also be pointed out
> | >that usually you don't need to wait for the release engineer
> | >to post a new tarball ... in your example, people can just
> | >track the '3.6' branch and get all bug fixes irrespective of
> | >the minor version. Am i correct?
>  
> | i am not sure i understand what you mean by tracking the 3.6 branch.
> | perhaps you mean downloading from the repository directly using the
> | tag?   the one thing we don't want is for people to download and use
> | untagged versions.  then we don't know what they have, and can't
> | properly track bugs, etc
> |
> +----]
> 
> It's my personal bias towards a source centric view of the world :)
> And it's also part of my FreeBSD heritage, where 'tracking' is
> intimately related to the use of cvsup to sync sources
> against a cvs repository.
> http://www.polstra.com/projects/freeware/CVSup/
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/synching.html
>  
> The thing I was trying to say is that once you do a major
> release, the branch (3.6 in this example) does not undergo
> further development. So if this is set as a policy (in
> FreeBSD old releases are owned by a security officer and
> normal people with commit privileges (committers) cannot
> under any circumstances make changes to these branches) then
> anyone 'checking out' the 3.6 branch using cvs (not the
> tagged release, because there maybe bug fixes since the
> release) or 'tracking' the 3.6 branch using cvsup (if you
> find it useful to have a cvsupd server installed) is sure to
> have the latest and most up to date version in the 3.6 line.
> 

As a matter of policy, it's my understanding that we all agree that a
particular release branch will not have any further feature development--
only bug fixes.  But I should also point out that non-urgent bugs could also
be provided in the trunk for the next release and never released as part of
a patch to the current release.

> You might as well tag the repository for each bug that is
> fixed, but this assumes that there will be little activity
> ... so you will have 3.6p1 (patch 1), 3.6p2, and so on. If
> the activity is higher, then tagging that much maybe
> overkill.

Yes--- I think that's overkill.  After all, with subversion (which we're
using) each checkin is numerically tagged anyway.

> The thing here is making the load lighter on the
> release engineer ... just do the hard work (getting tarballs
> out the door) for major releases. Users get minor releases
> and bug fixes by applying patches or updating their sources
> from the repository. What if you release 3.6.1 and
> then notice that you missed a critical file or bug fix? You
> need to do another release, 3.6.2. This is not necessary if
> users checkout/track the repository. Does this sound
> reasonable? 

The issue is that user's won't have a working copy to update-- their
original should be from the distributable.  I think downloading the updated
distributable is a trivial task, but I do agree that we could do more to
make it even easier (I'm thinking specifically here about if a file is
deleted as part of the release-- simply rerunning build GUS install -append
won't remove that file in the gus_home which could cause issues).

> 
> As to the issue of users working with 'untagged' versions,
> this is just a matter of educating users. And keep reminding
> people on the mailing list that they should do a cvs update
> (or cvsup) and check their problem against the most current
> version on any branch.
> 

No.  The most current version will frequently be the trunk, which may not be
stable.  If people find an issue in their release, they should:

1) Check the bug tracker to see if the issue is known and/or resolved.
    * If unknown, file a bug
    * If known, and fixed, and released: upgrade if possible
    * If known, and fixed, and unreleased: if urgent, apply patch
    * If known and not fixed: submit patch or wait


> Again, the idea is that the changes that go into these
> 'maintainance' branches should be easily applied to
> production sites. They should not break anything, so there
> shouldn't be a problem updating a gus installtion against
> the most recent version in the same branch.
> 
> It's just a suggestion. I would always prefer to track the
> 3.6 branch instead of downloading separate 3.6.1, 3.6.2,
> etc. versions. And of course this doesn't preclude that you
> might do minor releases where appropriate.

And that's ok for people comfortable with it, but I think for most people,
the new "traditional" release/distributable paradigm will provide a better
experience.

These, of course, are just my opinions/suggests...  We should make sure the
community is comfortable with whatever the "recommended" approach is.

> 
> Fernan
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev

[GUSDEV] GUS schema questions

[Robert O. <ol...@mc...>]

I've been trolling thru the schema browser trying to map the concepts  
in SEED to those in the schema. (If you want an idea about the system  
I am discussing, our public SEED server is available at http:// 
theseed.uchicago.edu/FIG/index.cgi ).

I think I've mapped most of them, with the following exceptions.

I asked this in the workshop yesterday, thought I'd repeat it here  
for the larger group, with a motivating example.

In the SEED, we support having multiple genomes installed for any  
given taxon. For instance, we have a genome we tag as 630.1 which is  
Yersinia enterocolitica from NCBI Refseq, and 630.2 which is Sanger's  
version of that organism. It was discussed in the workshop to use the  
external database version to tag the difference between these in GUS,  
but that seems clumsy to me (since I may want that to tag overall  
SEED data versions). I'm curious what the rank attribute on  
DoTS.Taxon is intended to be used for; it seems possible I could  
subvert that to use as the organism version indicator.

The other one is mapping feature annotations. The SEED being a genome  
annotation system, we need to support the storage of multiple  
annotations for each feature. The presentation software uses a set of  
rules to decide which annotation to display as the "current"  
annotation for a feature (where the usual rule is "latest annotation  
from a trusted user"). Is DoTS.NAGene the right place to put this,  
where I'd create a NAFeatureNAGene entry that links the NAFeature for  
the feature in question to the set of NAGenes containing the  
annotations?

thanks,
--bob

Re: [GUSDEV] class notdefyet on building GUS 3.5

[Ed R. <ero...@ug...>]

Here is the FINAL SQL;

select '>'||name,sequence from dots.externalnasequence;


-ed



---- Original message ----
>Date: Thu, 07 Jul 2005 15:44:51 -0400
>From: Michael Saffitz <msa...@pc...>  
>Subject: Re: [GUSDEV] class notdefyet on building GUS 3.5  
>To: Robert Olson <ol...@mc...>, Gusdev gusdev-gusdev
<gus...@li...>
>
>
>Thanks-- this is really very helpful.
>
>I've entered this issue as Bug #47 and I'm investigating now.
 Let's move
>futher discussion there.
>
>--Mike
>
>On 7/6/05 2:00 PM, "Robert Olson" <ol...@mc...> wrote:
>
>> Got it:
>> 
>> diff -u -r GUS/project_home/GUS/ObjRelP/lib/perl/Generator/
>> GeneratorFunctions.pm ../GUS/project_home/GUS/ObjRelP/lib/perl/
>> Generator/GeneratorFunctions.pm
>> --- GUS/project_home/GUS/ObjRelP/lib/perl/Generator/
>> GeneratorFunctions.pm    2005-06-16 16:35:04.000000000 -0400
>> +++ ../GUS/project_home/GUS/ObjRelP/lib/perl/Generator/
>> GeneratorFunctions.pm    2005-07-06 13:47:58.000000000 -0400
>> @@ -45,6 +45,9 @@
>>           $newType .= "Time";}
>>       else { $newType .= "Timestamp";}
>>       }
>> +    elsif (uc($oraType) eq "TIMESTAMP"){
>> +    $newType .= "Timestamp";
>> +    }
>>       elsif (uc($oraType) eq "FLOAT" || uc($oraType) eq
"FLOAT8"){
>>       $newType .= "BigDecimal"}
>> 
>> build runs to completion anyway.
>> 
>> --bob
>
>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Discover Easy Linux Migration
Strategies
>from IBM. Find simple to follow Roadmaps, straightforward
articles,
>informative Webcasts and more! Get everything you need to get
up to
>speed, fast.
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>_______________________________________________
>Gusdev-gusdev mailing list
>Gus...@li...
>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
-----------------
Ed Robinson
Center for Tropical and Emerging Global Diseases
University of Georgia, Athens, GA 30602
ero...@ug.../(706)542.1447/254.8883

Re: [GUSDEV] class notdefyet on building GUS 3.5

[Michael S. <msa...@pc...>]

Thanks-- this is really very helpful.

I've entered this issue as Bug #47 and I'm investigating now.  Let's move
futher discussion there.

--Mike

On 7/6/05 2:00 PM, "Robert Olson" <ol...@mc...> wrote:

> Got it:
> 
> diff -u -r GUS/project_home/GUS/ObjRelP/lib/perl/Generator/
> GeneratorFunctions.pm ../GUS/project_home/GUS/ObjRelP/lib/perl/
> Generator/GeneratorFunctions.pm
> --- GUS/project_home/GUS/ObjRelP/lib/perl/Generator/
> GeneratorFunctions.pm    2005-06-16 16:35:04.000000000 -0400
> +++ ../GUS/project_home/GUS/ObjRelP/lib/perl/Generator/
> GeneratorFunctions.pm    2005-07-06 13:47:58.000000000 -0400
> @@ -45,6 +45,9 @@
>           $newType .= "Time";}
>       else { $newType .= "Timestamp";}
>       }
> +    elsif (uc($oraType) eq "TIMESTAMP"){
> +    $newType .= "Timestamp";
> +    }
>       elsif (uc($oraType) eq "FLOAT" || uc($oraType) eq "FLOAT8"){
>       $newType .= "BigDecimal"}
> 
> build runs to completion anyway.
> 
> --bob

[GUSDEV] proposal for community involvement in GUS development

[Fernan A. <fe...@ii...>]

This has been mentioned in a previous email to the list, I'm
resending it (with a few minor corrections and additions) as
a separate message as it may warrant further discussion in
its own thread. 

The issue that I brought up was that of control of the
repository and user involvement in GUS development.

I'm sure that everyone agrees that the repository should not
be open to everyone. All open source projects control access
to repositories. But there should be a way to gain access to
'commit privileges'. The following are standard practices in
the FreeBSD community (the ones with which I'm most
familiar). I believe that these are both fair to all
participants and work well to keep users involved in
maintaining and developing code:

o in FreeBSD every file or group of files has a maintainer.
This is reflected with a line in every file (or in a top
file like a Makefile) such as: 
Maintainer: First Last <email@domain.whatever>

The maintainer is responsible for these files. Users
suggesting changes to these files or sending patches need to
get approval from the maintainer. This usually works by
CCing the maintainer when you create a new item in bugzilla.
Approval is by a simple followup message from the
maintainer. Maintainership is a volunteer type thing,
maintainers that don't work anymore in a certain area can
drop maintainership. Users can request maintainership for
orphan files (unmaintained files). In some cases (big areas
or subprojects, the maintainer is a virtual entity (ie a
mailing list) and maintainership is thus shared by a group
of people. Some files do not have a maintainer and are thus
maintained by 'everyone', discussion of changes and patches
use the mailing lists and tracker as in:
Maintainer: <gu...@gu...>
So as you see there is ample flexibility in implementing
this 'maintainership' strategy.

o some users have commit privileges (they can commit changes
  to the repository). But maintainers != committers. Some
  maintainers do not have commit privileges, some do.
  Committers need to know how to deal with the repository,
  maintainers only need to know about their files or their
  area of development.
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/

o Usually you should be a maintainer first, participate in
  mailing lists and send good patches, before you can ask for
  or be offered to have commit privileges. Since having commit
  privileges means that you should also take responsibility
  for committing patches from other people and do work on the
  repository, not all maintainers have or request these
  privileges. But this doesn't affect the development or
  maintainance of the project ... maintainership is the key here. 
  
  Even when you're given the 'commit bit', there is a period
  when you have a 'mentor' with whom you should discuss
  everything before committing (ie your commits should be
  approved by your mentor). Furthermore, even if you have
  commit privileges you cannot commit stuff that is being
  maintained by other people without their approval (of
  course, committers do commit very minor stuff, like typos in
  the documentation or trivial fixes without approval) but
  other than that respect is paid to maintainers.  

  Also, all commits that were not originated by the
  committer have an appropriate line giving credit to the
  originators (either the maintainer or whoever contributed
  the patch, or suggested a solution, pinpointed the
  problem, etc.).

Perhaps some of this is already in place ... I'm fairly new
to GUS, so I don't know how you guys give away commit
privileges or how you acknowledge contributions from users.
But from what I've seen there is no 'maintainership' as
depicted above. From my experience in FreeBSD this is a
great way to have users involved in the maintaince of code
and documentation without giving widespread commit
privileges. It has worked quite well for several projects. 

I hope this adds to the project, 

Fernan

Re: [GUSDEV] managing GUS releases

[Fernan A. <fe...@ii...>]

+----[ Steve Fischer <sfi...@pc...> (06.Jul.2005 20:29):
|
| Fernan-
| 
| see below for response to your first point.
| 
| for your second point, i strongly urge you to cut and paste into a new 
| posting to the group with an appropriate subject.   its too important a 
| topic to be buried inside this one.

OK, will do.
 
| steve
| 
| Fernan Aguero wrote:
| 
| >Steve,
| >
| >here are my ideas about the part of your proposal that deal
| >with 'managing branches'. 
| >
| >I agree with you on the branching before release, therefore
| >freeing the main trunk for continuing development towards
| >future versions. I also agree on the 'tagging' of already
| >released branches to provide landmarks of bug fixing
| >activity. However I think that it should also be pointed out
| >that usually you don't need to wait for the release engineer
| >to post a new tarball ... in your example, people can just
| >track the '3.6' branch and get all bug fixes irrespective of
| >the minor version. Am i correct?
 
| i am not sure i understand what you mean by tracking the 3.6 branch.  
| perhaps you mean downloading from the repository directly using the 
| tag?   the one thing we don't want is for people to download and use 
| untagged versions.  then we don't know what they have, and can't 
| properly track bugs, etc
|
+----]

It's my personal bias towards a source centric view of the world :)
And it's also part of my FreeBSD heritage, where 'tracking' is
intimately related to the use of cvsup to sync sources
against a cvs repository.   
http://www.polstra.com/projects/freeware/CVSup/
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/synching.html
 
The thing I was trying to say is that once you do a major
release, the branch (3.6 in this example) does not undergo
further development. So if this is set as a policy (in
FreeBSD old releases are owned by a security officer and
normal people with commit privileges (committers) cannot
under any circumstances make changes to these branches) then
anyone 'checking out' the 3.6 branch using cvs (not the
tagged release, because there maybe bug fixes since the
release) or 'tracking' the 3.6 branch using cvsup (if you
find it useful to have a cvsupd server installed) is sure to
have the latest and most up to date version in the 3.6 line.

You might as well tag the repository for each bug that is
fixed, but this assumes that there will be little activity
... so you will have 3.6p1 (patch 1), 3.6p2, and so on. If
the activity is higher, then tagging that much maybe
overkill. The thing here is making the load lighter on the
release engineer ... just do the hard work (getting tarballs
out the door) for major releases. Users get minor releases
and bug fixes by applying patches or updating their sources
from the repository. What if you release 3.6.1 and
then notice that you missed a critical file or bug fix? You
need to do another release, 3.6.2. This is not necessary if
users checkout/track the repository. Does this sound
reasonable? 

As to the issue of users working with 'untagged' versions,
this is just a matter of educating users. And keep reminding
people on the mailing list that they should do a cvs update
(or cvsup) and check their problem against the most current
version on any branch.

Again, the idea is that the changes that go into these
'maintainance' branches should be easily applied to
production sites. They should not break anything, so there
shouldn't be a problem updating a gus installtion against
the most recent version in the same branch.

It's just a suggestion. I would always prefer to track the
3.6 branch instead of downloading separate 3.6.1, 3.6.2,
etc. versions. And of course this doesn't preclude that you
might do minor releases where appropriate.

Fernan

Re: [GUSDEV] managing GUS releases

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

Fernan-

see below for response to your first point.

for your second point, i strongly urge you to cut and paste into a new 
posting to the group with an appropriate subject.   its too important a 
topic to be buried inside this one.

steve

Fernan Aguero wrote:

>+----[ sfi...@pc... <sfi...@pc...> (04.Jul.2005 09:09):
>|
>| Folks-
>| 
>| I have had a number of discussions with people at CBIL about how to manage GUS
>| version numbers and releases in the source code repository.
>| 
>| I have posted a proposal for this on the wiki at
>| http://www.gusdb.org/wiki/index.php/GusVersionBranch
>| 
>| If you have a chance to take a look before the GUS conference, this might make a
>| good topic for discussion.
>| 
>| Steve
>|
>+----]
>
>Steve,
>
>here are my ideas about the part of your proposal that deal
>with 'managing branches'. 
>
>I agree with you on the branching before release, therefore
>freeing the main trunk for continuing development towards
>future versions. I also agree on the 'tagging' of already
>released branches to provide landmarks of bug fixing
>activity. However I think that it should also be pointed out
>that usually you don't need to wait for the release engineer
>to post a new tarball ... in your example, people can just
>track the '3.6' branch and get all bug fixes irrespective of
>the minor version. Am i correct?
>  
>
i am not sure i understand what you mean by tracking the 3.6 branch.  
perhaps you mean downloading from the repository directly using the 
tag?   the one thing we don't want is for people to download and use 
untagged versions.  then we don't know what they have, and can't 
properly track bugs, etc

>The other issue that I would like to bring forward is that
>of control of the repository and user involvement in GUS
>development. These are not strictly related to the version
>managing, but since we're talking about the source
>repository and about setting a policy, perhaps it is also a
>good time to discuss these ideas:
>
>I'm sure that everyone agrees that the repository should not
>be open to everyone. All open source projects control access
>to repositories. But there should be a way to gain access to
>'commit privileges'. The following are standard practices in
>the FreeBSD community (with which I'm most familiar). I
>believe that these are both fair to all participants and
>work well to keep things clean:
>
>o every file or group of files has a maintainer. The
>  maintainer is responsible for these files. Users suggesting
>  changes to these files or sending patches need to get
>  approval from the maintainer. This usually works by CCing
>  the maintainer when you create a new item in bugzilla.
>  Approval is by a simple followup message from the
>  maintainer. Maintainership can be dropped or requested.
>  Some files do not have maintainers and are maintained by
>  'everyone', some files have active maintainers.  
>
>o some users have commit privileges (they can commit changes
>  to the repository). But maintainers != committers. Some
>  maintainers do not have commit privileges, some do.
>  Committers need to know how to deal with the repository,
>  maintainers only need to know about their files or their
>  area of development.
>http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/
>
>o Usually you should participate in mailing lists and send
>  good patches, before you can ask for or be offered to have
>  commit privileges. And even when you're given the 'commit
>  bit', there is a period when you have a 'mentor' with whom
>  you should discuss everything before commiting (ie your
>  commits should be approved by your mentor). And even if you
>  have commit privileges and the maintainer doesn't you
>  cannot commit stuff without approval from the maintainer. 
>
>Perhaps some of this is already in place ... I'm fairly new
>to GUS, so I don't know how you guys give away commit
>privileges. But from what I've seen there is no
>'maintainership' as depicted above. From my experience in
>FreeBSD this is a great way to have users involved in the
>maintaince of code and documentation without giving
>widespread commit privileges. It has worked quite well for
>several projects. 
>
>Also, I wanted to stress the fact that producing tarballs
>for major releases is fine but you cannot do a release for
>every bug fixed on the repository.  Having a branch (3.6 in
>the example) that you can track using cvs or cvsup and that
>will only have non-breaking fixes is a good way to keep old
>releases supported.
>
>Sorry for the long email. Hope this adds to the project,
>
>Fernan
>  
>

Re: [GUSDEV] non-obvious error

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

Robert-

We're having the GUS Workshop now.  We have all agreed that we need to 
use the tracker to track bugs:

https://www.cbil.upenn.edu/tracker/enter_bug.cgi?product=GUS

so, go ahead and enter it there...

steve

Robert Olson wrote:

> FYI from a new user:
>
> If you forget ga +meta --commit and try to register a plugin, you get  
> confusing errors like this:
>
> $ ga +create GUS::PluginMgr::GusApplication --commit
>
> USER ERROR: GUS::PluginMgr::GusApplication has never been registered.
> Please use 'ga +create GUS::PluginMgr::GusApplication --commit'
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev

Re: [GUSDEV] managing GUS releases

[Fernan A. <fe...@ii...>]

+----[ sfi...@pc... <sfi...@pc...> (04.Jul.2005 09:09):
|
| Folks-
| 
| I have had a number of discussions with people at CBIL about how to manage GUS
| version numbers and releases in the source code repository.
| 
| I have posted a proposal for this on the wiki at
| http://www.gusdb.org/wiki/index.php/GusVersionBranch
| 
| If you have a chance to take a look before the GUS conference, this might make a
| good topic for discussion.
| 
| Steve
|
+----]

Steve,

here are my ideas about the part of your proposal that deal
with 'managing branches'. 

I agree with you on the branching before release, therefore
freeing the main trunk for continuing development towards
future versions. I also agree on the 'tagging' of already
released branches to provide landmarks of bug fixing
activity. However I think that it should also be pointed out
that usually you don't need to wait for the release engineer
to post a new tarball ... in your example, people can just
track the '3.6' branch and get all bug fixes irrespective of
the minor version. Am i correct?

The other issue that I would like to bring forward is that
of control of the repository and user involvement in GUS
development. These are not strictly related to the version
managing, but since we're talking about the source
repository and about setting a policy, perhaps it is also a
good time to discuss these ideas:

I'm sure that everyone agrees that the repository should not
be open to everyone. All open source projects control access
to repositories. But there should be a way to gain access to
'commit privileges'. The following are standard practices in
the FreeBSD community (with which I'm most familiar). I
believe that these are both fair to all participants and
work well to keep things clean:

o every file or group of files has a maintainer. The
  maintainer is responsible for these files. Users suggesting
  changes to these files or sending patches need to get
  approval from the maintainer. This usually works by CCing
  the maintainer when you create a new item in bugzilla.
  Approval is by a simple followup message from the
  maintainer. Maintainership can be dropped or requested.
  Some files do not have maintainers and are maintained by
  'everyone', some files have active maintainers.  

o some users have commit privileges (they can commit changes
  to the repository). But maintainers != committers. Some
  maintainers do not have commit privileges, some do.
  Committers need to know how to deal with the repository,
  maintainers only need to know about their files or their
  area of development.
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/

o Usually you should participate in mailing lists and send
  good patches, before you can ask for or be offered to have
  commit privileges. And even when you're given the 'commit
  bit', there is a period when you have a 'mentor' with whom
  you should discuss everything before commiting (ie your
  commits should be approved by your mentor). And even if you
  have commit privileges and the maintainer doesn't you
  cannot commit stuff without approval from the maintainer. 

Perhaps some of this is already in place ... I'm fairly new
to GUS, so I don't know how you guys give away commit
privileges. But from what I've seen there is no
'maintainership' as depicted above. From my experience in
FreeBSD this is a great way to have users involved in the
maintaince of code and documentation without giving
widespread commit privileges. It has worked quite well for
several projects. 

Also, I wanted to stress the fact that producing tarballs
for major releases is fine but you cannot do a release for
every bug fixed on the repository.  Having a branch (3.6 in
the example) that you can track using cvs or cvsup and that
will only have non-breaking fixes is a good way to keep old
releases supported.

Sorry for the long email. Hope this adds to the project,

Fernan

[GUSDEV] non-obvious error

[Robert O. <ol...@mc...>]

FYI from a new user:

If you forget ga +meta --commit and try to register a plugin, you get  
confusing errors like this:

$ ga +create GUS::PluginMgr::GusApplication --commit

USER ERROR: GUS::PluginMgr::GusApplication has never been registered.
Please use 'ga +create GUS::PluginMgr::GusApplication --commit'

Re: [GUSDEV] class notdefyet on building GUS 3.5

[Robert O. <ol...@mc...>]

Got it:

diff -u -r GUS/project_home/GUS/ObjRelP/lib/perl/Generator/ 
GeneratorFunctions.pm ../GUS/project_home/GUS/ObjRelP/lib/perl/ 
Generator/GeneratorFunctions.pm
--- GUS/project_home/GUS/ObjRelP/lib/perl/Generator/ 
GeneratorFunctions.pm    2005-06-16 16:35:04.000000000 -0400
+++ ../GUS/project_home/GUS/ObjRelP/lib/perl/Generator/ 
GeneratorFunctions.pm    2005-07-06 13:47:58.000000000 -0400
@@ -45,6 +45,9 @@
          $newType .= "Time";}
      else { $newType .= "Timestamp";}
      }
+    elsif (uc($oraType) eq "TIMESTAMP"){
+    $newType .= "Timestamp";
+    }
      elsif (uc($oraType) eq "FLOAT" || uc($oraType) eq "FLOAT8"){
      $newType .= "BigDecimal"}

build runs to completion anyway.

--bob

Re: [GUSDEV] class notdefyet on building GUS 3.5

[Robert O. <ol...@mc...>]

I'm seeing a similar problem; this is with postgresql 8.0 on a mac =20
running Tiger.

gus.config info about the db:

dbiDsn=3DDBI:Pg:dbname=3Dgus;port=3D10001
jdbcDsn=3Djdbc:postgresql://localhost:10001/gus?user=3Dgus&password=3Dgus

# Login and Password to the RDBMS

databaseLogin=3Dgus
databasePassword=3Dgus

I didn't see any errors on the load, and there's a bunch of stuff in =20
the database; however, I don't see a core.algorithm_row table that =20
perhaps is what is trying to be used:

gus=3D> \dn
       List of schemas
         Name        | Owner
--------------------+-------
core               | gus
corever            | gus
dots               | gus
dotsver            | gus
information_schema | olson
pg_catalog         | olson
pg_toast           | olson
prot               | gus
protver            | gus
public             | olson
rad                | gus
radver             | gus
sres               | gus
sresver            | gus
study              | gus
studyver           | gus
tess               | gus
tessver            | gus
(18 rows)

gus=3D> \dt core.
                 List of relations
Schema |          Name           | Type  | Owner
--------+-------------------------+-------+-------
core   | algorithm               | table | gus
core   | algorithmimplementation | table | gus
core   | algorithminvocation     | table | gus
core   | algorithmparam          | table | gus
core   | algorithmparamkey       | table | gus
core   | algorithmparamkeytype   | table | gus
core   | analysisalgorithm       | table | gus
core   | category                | table | gus
core   | databasedocumentation   | table | gus
core   | databaseinfo            | table | gus
core   | databaseversion         | table | gus
core   | groupinfo               | table | gus
core   | projectinfo             | table | gus
core   | tablecategory           | table | gus
core   | tableinfo               | table | gus
core   | usergroup               | table | gus
core   | userinfo                | table | gus
core   | userproject             | table | gus
(18 rows)
gus=3D> select table_id, name from core.tableinfo where name like '%=20
Algorith%';
table_id |            name
----------+----------------------------
       592 | AnalysisAlgorithmVer
       593 | AlgorithmInvocationVer
       594 | AlgorithmParamKeyVer
       596 | AlgorithmParamVer
       604 | AlgorithmImplementationVer
       605 | AlgorithmVer
       606 | AlgorithmParamKeyTypeVer
       701 | AlgorithmInvocation
       702 | Algorithm
       704 | AnalysisAlgorithm
       706 | AlgorithmParamKeyType
       707 | AlgorithmParam
       713 | AlgorithmImplementation
       714 | AlgorithmParamKey
(14 rows)

errors follow.

Thanks,
--bob

      [exec] Warning: No JavaType found for 'modification_date', =20
type: 'timestamp'
      [exec] Warning: No JavaType found for 'modification_date', =20
type: 'timestamp'
      [copy] Copying 2 files to /Users/olson/GUS/project_home/GUS/=20
Model/src/java/org/gusdb/model/DoTS
      [copy] Copying 1 file to /Users/olson/GUS/project_home/GUS/=20
Model/src/java/org/gusdb/model/SRes
      [echo] Starting target: JavaModel
     [mkdir] Created dir: /Users/olson/GUS/gus_home/schema
      [echo] .
      [echo] Installing GUS/Model
      [copy] Copying 2 files to /Users/olson/GUS/gus_home/bin
      [copy] Copying 1546 files to /Users/olson/GUS/gus_home/lib/perl/=20=

GUS/Model
     [mkdir] Created dir: /Users/olson/GUS/project_home/GUS/Model/=20
classes
     [javac] Compiling 1260 source files to /Users/olson/GUS/=20
project_home/GUS/Model/classes
     [javac] /Users/olson/GUS/project_home/GUS/Model/src/java/org/=20
gusdb/model/Core/Algorithm_Row.java:86: cannot resolve symbol
     [javac] symbol  : class notdefyet
     [javac] location: class org.gusdb.model.Core.Algorithm_Row
     [javac]     public void setModificationDate (notdefyet value)
     [javac]                                      ^
     [javac] /Users/olson/GUS/project_home/GUS/Model/src/java/org/=20
gusdb/model/Core/Algorithm_Row.java:91: cannot resolve symbol
     [javac] symbol  : class notdefyet
     [javac] location: class org.gusdb.model.Core.Algorithm_Row
     [javac]     public notdefyet getModificationDate () { return =20
(notdefyet)get_Attribute("modification_date"); }
     [javac]            ^
     [javac] /Users/olson/GUS/project_home/GUS/Model/src/java/org/=20
gusdb/model/Core/AlgorithmInvocation_Row.java:54: cannot resolve symbol

On Jul 4, 2005, at 12:51 AM, Michael Saffitz wrote:

>
> Hi Fabricio,
>
> This is usually indicative that the schema was not properly loaded =20
> into the
> RDBMS.  Can you review the output from the very first run (when you =20=

> did
> -installDBSchema) to confirm there were no SQL errors?  Can you =20
> connect to
> your DB and confirm that the objects exist-- especially that the
> core.tableinfo table is fully populated.
>
> If the DB was not fully installed, you must resolve the issue =20
> preventing
> installation, and then remove all GUS objects that may have been =20
> partially
> created (i.e. Users/schemas, tables, sequences, etc.)  Then you can =20=

> try
> again.  (I believe this is outlined in the install docs).
>
> If all of the objects are being fully installed, then it may be =20
> that your
> jdbc connection string has different settings than your perl =20
> connection
> string.  Make sure that your $GUS_CONFIG_FILE has the correct =20
> dbiDsn for
> your database.
>
> Let me know how the above goes and we'll figure out the next step.
>
> --Mike
>
> On 7/3/05 10:18 PM, "Fabr=EDcio" <fab...@de...> wrote:
>
>
>> Hello all,
>>
>>
>>
>> We=92re trying to install the new GUS 3.5 release, and we=92re having =
=20
>> a problem
>> when we have to run =93build GUS install -append -installDBSchema=94. =
=20
>> After a
>> time running the building process stops whit many errors like this:
>>
>>
>>
>> [javac]/usr/local/GUS/GUS35/project_home/GUS/Model/src/java/org/=20
>> gusdb/model/
>> Core/AlgorithmInvocation_Row.java:99: cannot resolve symbol
>> [javac]symbol  : class notdefyet
>> [javac]location: class org.gusdb.model.Core.AlgorithmInvocation_Row
>> [javac]public notdefyet getModificationDate () { return
>> (notdefyet)get_Attribute("modification_date"); }
>> [javac]            ^
>>
>>
>>
>> Despite these errors, the schema was generated in our postgres, =20
>> but we don=92t
>> know if it=92s complete.
>>
>>
>>
>> We tried to build again using only the command =93build GUS install =96=
=20
>> append=94
>> and we put the output in a file as you can see here:
>>
>>
>>
>> http://www.de9.ime.eb.br/~fabricio/out.txt
>>
>>
>>
>> Can you tell us why the notdefyet class isn=92t found?
>>
>>
>>
>> Thanks a lot,
>>
>>
>>
>> Fabr=EDcio.
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dclick
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>
>

[GUSDEV] Schema Browser Updated to 3.5

[Michael S. <msa...@pc...>]

All,

I've updated the schema browser to GUS 3.5:

http://www.gusdb.org/cgi-bin/schemaBrowser

The previous schema browser is available at:

http://www.gusdb.org/cgi-bin/schemaBrowserOld

--Mike

Re: RES: [GUSDEV] class notdefyet on building GUS 3.5

[Michael S. <msa...@pc...>]

Hi Fabricio,

I believe the dbiDsn should be:

dbiDsn=3Ddbi:Pg:dbname=3Dgus35

--Mike

On 7/4/05 11:35 AM, "Fabr=C3=ADcio" <fab...@de...> wrote:

> Hi Mike,
>=20
> I checked your suggestions and I noticed that we didn=E2=80=99t get SQL errors =
when
> running the build command with -installDBSchema. The core.tableinfo table
> has exactly 954 rows. I don=E2=80=99t known if this is the final row number; th=
e
> schema seems all ok, I really don=E2=80=99t know.
>=20
> The build output with -installDBSchema is here again:
>=20
> http://www.de9.ime.eb.br/~fabricio/out.txt
>=20
>=20
> About our jdbcDsn and dbiDsn we have this in the gus.properties file:
>=20
> dbiDsn=3Ddbi:Pg:gus35
> jdbcDsn=3Djdbc:postgresql://localhost/gus35
>=20
> Is it not right?
>=20
> I tested this jdbc connection string in a simple java class and I could
> connect and manipulate the database without problems.
>=20
> Can you have an idea about the problem? I can't visualize where we are
> faulting.=20
>=20
> Thanks a lot for your help!
>=20
> Fabr=C3=ADcio
>=20
> -----Mensagem original-----
> De: Michael Saffitz [mailto:msa...@pc...]
> Enviada em: segunda-feira, 4 de julho de 2005 01:52
> Para: Fabr =C3=AD cio; Gusdev gusdev-gusdev
> Assunto: Re: [GUSDEV] class notdefyet on building GUS 3.5
>=20
>=20
> Hi Fabricio,
>=20
> This is usually indicative that the schema was not properly loaded into t=
he
> RDBMS.  Can you review the output from the very first run (when you did
> -installDBSchema) to confirm there were no SQL errors?  Can you connect t=
o
> your DB and confirm that the objects exist-- especially that the
> core.tableinfo table is fully populated.
>=20
> If the DB was not fully installed, you must resolve the issue preventing
> installation, and then remove all GUS objects that may have been partiall=
y
> created (i.e. Users/schemas, tables, sequences, etc.)  Then you can try
> again.  (I believe this is outlined in the install docs).
>=20
> If all of the objects are being fully installed, then it may be that your
> jdbc connection string has different settings than your perl connection
> string.  Make sure that your $GUS_CONFIG_FILE has the correct dbiDsn for
> your database.
>=20
> Let me know how the above goes and we'll figure out the next step.
>=20
> --Mike
>=20
> On 7/3/05 10:18 PM, "Fabr=C3=ADcio" <fab...@de...> wrote:
>=20
>> Hello all,
>>=20
>> =20
>>=20
>> We=C2=B9re trying to install the new GUS 3.5 release, and we=C2=B9re having a
> problem
>> when we have to run =C2=B3build GUS install -append -installDBSchema=C2=B2. Afte=
r a
>> time running the building process stops whit many errors like this:
>>=20
>> =20
>>=20
>>=20
> [javac]/usr/local/GUS/GUS35/project_home/GUS/Model/src/java/org/gusdb/mod=
el/
>> Core/AlgorithmInvocation_Row.java:99: cannot resolve symbol
>> [javac]symbol  : class notdefyet
>> [javac]location: class org.gusdb.model.Core.AlgorithmInvocation_Row
>> [javac]public notdefyet getModificationDate () { return
>> (notdefyet)get_Attribute("modification_date"); }
>> [javac]            ^
>>=20
>> =20
>>=20
>> Despite these errors, the schema was generated in our postgres, but we
> don=C2=B9t
>> know if it=C2=B9s complete.
>>=20
>> =20
>>=20
>> We tried to build again using only the command =C2=B3build GUS install =C2=ADapp=
end=C2=B2
>> and we put the output in a file as you can see here:
>>=20
>> =20
>>=20
>> http://www.de9.ime.eb.br/~fabricio/out.txt
>>=20
>> =20
>>=20
>> Can you tell us why the notdefyet class isn=C2=B9t found?
>>=20
>> =20
>>=20
>> Thanks a lot,
>>=20
>> =20
>>=20
>> Fabr=C3=ADcio.
>>=20
>> =20
>>=20
>> =20
>>=20
>> =20
>>=20
>=20
>=20

Re: [GUSDEV] class notdefyet on building GUS 3.5

[Michael S. <msa...@pc...>]

Hi Fabricio,

This is usually indicative that the schema was not properly loaded into the
RDBMS.  Can you review the output from the very first run (when you did
-installDBSchema) to confirm there were no SQL errors?  Can you connect to
your DB and confirm that the objects exist-- especially that the
core.tableinfo table is fully populated.

If the DB was not fully installed, you must resolve the issue preventing
installation, and then remove all GUS objects that may have been partially
created (i.e. Users/schemas, tables, sequences, etc.)  Then you can try
again.  (I believe this is outlined in the install docs).

If all of the objects are being fully installed, then it may be that your
jdbc connection string has different settings than your perl connection
string.  Make sure that your $GUS_CONFIG_FILE has the correct dbiDsn for
your database.

Let me know how the above goes and we'll figure out the next step.

--Mike

On 7/3/05 10:18 PM, "Fabr=EDcio" <fab...@de...> wrote:

> Hello all,
>=20
> =20
>=20
> We=B9re trying to install the new GUS 3.5 release, and we=B9re having a probl=
em
> when we have to run =B3build GUS install -append -installDBSchema=B2. After a
> time running the building process stops whit many errors like this:
>=20
> =20
>=20
> [javac]/usr/local/GUS/GUS35/project_home/GUS/Model/src/java/org/gusdb/mod=
el/
> Core/AlgorithmInvocation_Row.java:99: cannot resolve symbol
> [javac]symbol  : class notdefyet
> [javac]location: class org.gusdb.model.Core.AlgorithmInvocation_Row
> [javac]public notdefyet getModificationDate () { return
> (notdefyet)get_Attribute("modification_date"); }
> [javac]            ^
>=20
> =20
>=20
> Despite these errors, the schema was generated in our postgres, but we do=
n=B9t
> know if it=B9s complete.
>=20
> =20
>=20
> We tried to build again using only the command =B3build GUS install =ADappend=
=B2
> and we put the output in a file as you can see here:
>=20
> =20
>=20
> http://www.de9.ime.eb.br/~fabricio/out.txt
>=20
> =20
>=20
> Can you tell us why the notdefyet class isn=B9t found?
>=20
> =20
>=20
> Thanks a lot,
>=20
> =20
>=20
> Fabr=EDcio.
>=20
> =20
>=20
> =20
>=20
> =20
>=20