genex-dev — GeneX developers

Re: [GeneX-dev] updated SF genex page on harwin

[<ja...@op...>]

Wow ...

Muey excellente, I'm impressed. Nice banner, good colors.

jas.

"Jiaye Zhou" <ze...@in...> writes:

> Hi Harry,
> 
>   I just went ahead and changed the single page into server side included pages.
> I checked on Sourceforge, they support ssi with extension shtml. The new page is 
> called index2.shtml ( http://24.1.175.29/sf/index2.shtml ). I also included the 
> new banner image. I put the image in the "img" folder and created a "content" 
> folder for placing the included files. (menu.ssi and main.ssi for now). Please 
> take a look and double check that nothing is broken.
> 
> Jiaye
> 
> _______________________________________________
> Genex-dev mailing list
> Gen...@li...
> http://lists.sourceforge.net/lists/listinfo/genex-dev

[GeneX-dev] updated SF genex page on harwin

[Jiaye Z. <ze...@in...>]

Hi Harry,

  I just went ahead and changed the single page into server side included pages.
I checked on Sourceforge, they support ssi with extension shtml. The new page is 
called index2.shtml ( http://24.1.175.29/sf/index2.shtml ). I also included the 
new banner image. I put the image in the "img" folder and created a "content" 
folder for placing the included files. (menu.ssi and main.ssi for now). Please 
take a look and double check that nothing is broken.

Jiaye

Re: [GeneX-dev] [Q]: GeneXML <==> Curation Tool

[Lonny M. <lx...@nc...>]

Hmmm, I'm not entirely sure the xml2ct won't choke if it doesn't find the
info in the control bundle.  As for the rest of the curation tool, I don't
think it is used anywhere.  Put up a the new control bundle download on
genesoup, and I'll test the curation tool and let you know if we need to fix
it before you commit the changes to genex.

Lonny

----- Original Message -----
From: Jason E. Stewart <ja...@op...>
To: <gen...@li...>
Sent: Tuesday, January 30, 2001 10:04 AM
Subject: [GeneX-dev] [Q]: GeneXML <==> Curation Tool


> Hey,
>
> In the control-bundle we ship a list of the current groups in the
> GroupSec table. With each groups comes a list of that groups
> members. It turns out that this is a problem for the new XML API.
>
> I doubt that the CT is actually using this group information for
> anything, is it? I would like to remove that information completely
> from the control-bundle. Although it is not a security risk (we are
> not giving out login names or passwords) it is not anyone's business
> who is currently registered as a user with NCGR, and so it shouldn't
> go out in the control-bundle.
>
> The problem that I would like to fix is that currently the group
> members are listed by their contact fkey, and not by their usersec
> fkey. I want to use the XML API to do updates of the DB, and I need it
> to accurately reflect the state of the DB, so an update of the
> GroupSec/UserSec information is only possible if that info is stored
> in GeneXML.
>
> jas.
>
> _______________________________________________
> Genex-dev mailing list
> Gen...@li...
> http://lists.sourceforge.net/lists/listinfo/genex-dev
>

Re: [GeneX-dev] Re: Categories on SF

[Todd P. <tf...@nc...>]

OK...then they're fine.

> PS. Unfortunately, once items are in the list, you have to make an SA
> request to remove them. So unless someone feels really strongly that
> the ones I added are incorrect, we may want to keep them. The
> sourceforge SA's seem to take about 2 weeks to handle requests such as
> that.
> 

[GeneX-dev] Re: Categories on SF

[<ja...@op...>]

"Todd Peterson" <tf...@nc...> writes:

> > Genex.pm is (to me) very descriptive. It is *only* the Perl API
> > module. It is mainly a category for me to refile bugs under when
> > someone reports a problem in the Server that I find is really an issue
> > with the API.
> > 
> How about GeneX Perl API then?

I Could have used that. 

I have been using Genex.pm as a description for
the entire piece, much like we talk about DBI.pm or CGI.pm, although
they are certainly more well known.

> > The genex-analysis/genex-query are very fuzzy things that overlap
> > quite a bit. That's why I registered it as just 'Server', which
> > includes all the CGI scripts, and the WWW pages that come with the
> > server.
> 
> GeneX Server then?

It is the GeneX project, who's server would I be talking about? When
the bugzilla items were shared between many projects at NCGR there was
a need to preface them with a project name. Since this bug tracker is
specific to Genex, why add them?

just my $0.05,
jas.

PS. Unfortunately, once items are in the list, you have to make an SA
request to remove them. So unless someone feels really strongly that
the ones I added are incorrect, we may want to keep them. The
sourceforge SA's seem to take about 2 weeks to handle requests such as
that.

Re: [GeneX-dev] [Q]: GeneXML <==> Curation Tool

[<ja...@op...>]

"Todd Peterson" <tf...@nc...> writes:

> The CT actually does have an editor window for groups. My current thought is
> that the CT should eventually be capable of reading/editing of any DB table.
> We would need to implement some permission determination such that a curator
> can edit any table. A user is only allowed to edit a subset of all the
> tables and some tables would not be user-viewable. When an XML request is
> made, the content could be restricted if the requestor is a user.

What should we do about this? The current GeneXML DTD is deficient
because it only represents groups as having <member> sub-elements, and
each <member> is EMPTY, with a single attribute, 'contact_id', which
is an IDREF to a <contact>:id. 

This wants to be changed so that a <group> has <user> sub-elements,
and each <user> has two attributes, 'login' and 'password'. 

Currently, users should not be editing user and group info this way
(at least, we agreed that the CT would not be handling any security
stuff, that it should be handled on the server side for now).

So if I modify db2xml to *not* output group info, it shouldn't break
the CT, right? Is this an OK solution? Shall I make a control-bundle
available to test it?

> At the heart of this design is XML. It is the communication medium between
> the components of the GeneX system. We already can do CT->XML, XML->CT,
> XML->DB and DB->XML. The CT could also do XML->CT->other format. Where other
> format could be tab-delimited file, archive-bundle, etc. Another
> component could be the schema, so we could have XML->schema and
> schema->XML. This scheme would allow someone to edit any format and
> have the changes propogate to the other components. For example, the
> schema could be edited by directly editing the XML and doing
> XML->schema to get the new picture and XML->DB to update the table
> definitions (requires a new DTD for schema definition).  Then, it
> should be possible to do DB(postgres)->XML->DB(Oracle). I have been
> re-studying an old tool I have used for the last 4 years called DoMe
> (www.htc.honeywell.com/dome). This tool does modeling for a whole
> slew of formats including UML. The tool includes a programming
> language which allows user-customization of code-generation from a
> model. I believe UML model->XML would not be a hard task. XML->DB
> wouldn' t be hard either. Oh yeah, DoMe is a GNU project.

Currently the curation tool is being used mainly as an 'annotation
tool', moving ahead as you suggest would really add the 'curation'
functionality. I think that would be excellent. 

It's also not going to happen before the public announcement of GeneX
on SourceForge which is the timeframe I need a solution for.

jas.

[GeneX-dev] Public Announcement

[<ja...@op...>]

Hey All,

We need to have a checklist of everything we want to have in place
before make the public broadcast that GeneX is available at
sourceforge. 

My purpose is to go into as little detail as possible and just
indicate what are the minimum things needing to be done before we
alert the world.

Here is my first attempt at that list for things I work on:

GeneXML:  modify to accept proper <group><user> info (jes)
Server:   no additions to what's in CVS
Genex.pm: Add USF, ExpSet, ArrayMeas to XML API so that a DB update
            can be made in XML (jes)
DB:       Add update DB script to take XML dump and update DB (jes)
SourceForge: Main page with links to info (hjm), finalize bug items (jes), 
             make sure all releases are current

Here are pieces I need others to fill in:

xml2db: any issues ?? (jz)
curation tool: current release up on SF (lxm), other ???
documentation: ???
announcement: needs to be written (hjm??)
press release: does NCGR want one (gdc??)

anything else???

jas.

Re: [GeneX-dev] [Q]: GeneXML <==> Curation Tool

[Todd P. <tf...@nc...>]

The CT actually does have an editor window for groups. My current thought is
that the CT should eventually be capable of reading/editing of any DB table.
We would need to implement some permission determination such that a curator
can edit any table. A user is only allowed to edit a subset of all the
tables and some tables would not be user-viewable. When an XML request is
made, the content could be restricted if the requestor is a user.

At the heart of this design is XML. It is the communication medium between
the components of the GeneX system. We already can do CT->XML, XML->CT,
XML->DB and DB->XML. The CT could also do XML->CT->other format. Where other
format could be tab-delimited file, archive-bundle, etc. Another component
could be the schema, so we could have XML->schema and schema->XML. This
scheme would allow someone to edit any format and have the changes propogate
to the other components. For example, the schema could be edited by directly
editing the XML and doing XML->schema to get the new picture and XML->DB to
update the table definitions (requires a new DTD for schema definition).
Then, it should be possible to do DB(postgres)->XML->DB(Oracle). I have been
re-studying an old tool I have used for the last 4 years called DoMe
(www.htc.honeywell.com/dome). This tool does modeling for a whole slew of
formats including UML. The tool includes a programming language which allows
user-customization of code-generation from a model. I believe UML model->XML
would not be a hard task. XML->DB wouldn' t be hard either. Oh yeah, DoMe is
a GNU project.

----- Original Message -----
From: "Jason E. Stewart" <ja...@op...>
To: <gen...@li...>
Sent: Tuesday, January 30, 2001 9:04 AM
Subject: [GeneX-dev] [Q]: GeneXML <==> Curation Tool


> Hey,
>
> In the control-bundle we ship a list of the current groups in the
> GroupSec table. With each groups comes a list of that groups
> members. It turns out that this is a problem for the new XML API.
>
> I doubt that the CT is actually using this group information for
> anything, is it? I would like to remove that information completely
> from the control-bundle. Although it is not a security risk (we are
> not giving out login names or passwords) it is not anyone's business
> who is currently registered as a user with NCGR, and so it shouldn't
> go out in the control-bundle.
>
> The problem that I would like to fix is that currently the group
> members are listed by their contact fkey, and not by their usersec
> fkey. I want to use the XML API to do updates of the DB, and I need it
> to accurately reflect the state of the DB, so an update of the
> GroupSec/UserSec information is only possible if that info is stored
> in GeneXML.
>
> jas.
>
> _______________________________________________
> Genex-dev mailing list
> Gen...@li...
> http://lists.sourceforge.net/lists/listinfo/genex-dev
>

[GeneX-dev] [Q]: GeneXML <==> Curation Tool

[<ja...@op...>]

Hey,

In the control-bundle we ship a list of the current groups in the
GroupSec table. With each groups comes a list of that groups
members. It turns out that this is a problem for the new XML API.

I doubt that the CT is actually using this group information for
anything, is it? I would like to remove that information completely
from the control-bundle. Although it is not a security risk (we are
not giving out login names or passwords) it is not anyone's business
who is currently registered as a user with NCGR, and so it shouldn't
go out in the control-bundle.

The problem that I would like to fix is that currently the group
members are listed by their contact fkey, and not by their usersec
fkey. I want to use the XML API to do updates of the DB, and I need it
to accurately reflect the state of the DB, so an update of the
GroupSec/UserSec information is only possible if that info is stored
in GeneXML.

jas.

Re: [GeneX-dev] GeneX Sourceforge Web page template

[Harry M. <man...@ho...>]

Hi Jiaye,

Tried to call you just now - busy.  Give me a buzz tomorrow and we can settle this.  IThe Jscript is neat, but I want to keep it as plainjane as possible for now and any stylistic flourishes should be
done with std fonts/backgrounds, etc.  Jscript is almost as bad as Java for being platform-dependent ;).

shtml's about the most sophisticated I want to get (and even then...)..

Lets settle the format with some voice-time tomorrow. and then start in on the content and get it out there.  We can always edit later.  Times a wasting..

hjm



Jiaye Zhou wrote:
> 
> Exactly what I'm afraid of...I know that netscape is funky with support for
> stylesheets and layers...maybe so much for that idea, I can see about another
> approach or scratching the idea all together?
> 
> jiaye
> 
> Quoting "Jason E. Stewart" <ja...@op...>:
> 
> > "Jiaye Zhou" <ze...@in...> writes:
> >
> > > Hi Harry, should have talked to you earlier about this. I generated
> > > a javascript driven navigation bar that expands and collapses when
> >
> > These seems like a good idea. It is broken for the following browsers:
> > * Netscape 4.73 on linux-i86: the menus expand, but the text overlaps
> >   horribly and is unreadable
> > * Mozilla on linux-ppc:
> > * Konqueror on linux-ppc: Neither of these expand the menus.
> >
> > jas.
> >
> > _______________________________________________
> > Genex-dev mailing list
> > Gen...@li...
> > http://lists.sourceforge.net/lists/listinfo/genex-dev
> >
> 
> _______________________________________________
> Genex-dev mailing list
> Gen...@li...
> http://lists.sourceforge.net/lists/listinfo/genex-dev

-- 
Cheers,
Harry

Harry J Mangalam -- (949) 856 2847 (v&f) -- hj...@nc... || man...@ho...

Re: [GeneX-dev] Bug tracking on sourceforge

[Lonnie M. <lx...@nc...>]

That's true, I think we do need to wait to stop using Bugzilla, however we should still set up sourceforge bug tracking, both to give outsiders a chance to start logging bugs and so it will be set up and tested when we go live with it.

I like having at least 4 levels of priority (P1, P2, P3, P4) because it gives us the ability to set some "this release" bugs at a higher priority than other "this release" bugs andsome "next release" bugs at a higher priority than other "next release" bugs.

Lonny

> 
> jason:
> 
> It sounded to me like Lonny wanted to wait before stopping NCGR bugzilla until 
> after the Curation Tool was on Source Forge CVS.
> 
> Better check with him.
> 
> Also the reason I put P3 and P4 as permanent "next release" priorities was to 
> leave P1 and P2 for emergency patch cases only, which I assume will occur with 
> most releases. However, you are probably right that there is no meaningful 
> distinction between P3 and P4; except I thought maybe P4 could be those items 
> which could be dropped from a release if the deadline is hit before they are 
> done.
> 
> Greg
> 
> >Delivered-To: fix...@li...@fixme
> >To: gen...@li...
> >Subject: Re: [GeneX-dev] Bug tracking on sourceforge
> >Mime-Version: 1.0 (generated by tm-edit 1.5)
> >From: ja...@op... (Jason E. Stewart)
> >Date: 29 Jan 2001 16:16:24 -0700
> >
> >I will think we could go with something that's above a P1 that mean's
> >drop whatever you're doing, and fix this NOW!!! This would work well
> >for things like user accounts on genex.ncgr.org not working,
> >etc. Also, would we ever distinguish between a P3 and a P4, or do we
> >just want a lump 'for next release' category, and once the current
> >release goes out, we re-evaluate all the 'next-release' items up to P1
> >or P2?
> >
> >I will start adding this to SourceForge.
> >
> >jas.
> >
> >_______________________________________________
> >Genex-dev mailing list
> >Gen...@li...
> >http://lists.sourceforge.net/lists/listinfo/genex-dev
> 
> 
> _______________________________________________
> Genex-dev mailing list
> Gen...@li...
> http://lists.sourceforge.net/lists/listinfo/genex-dev
> 

Re: [GeneX-dev] Bug tracking on sourceforge

[Greg D. C. <gd...@nc...>]

jason:

It sounded to me like Lonny wanted to wait before stopping NCGR bugzilla until 
after the Curation Tool was on Source Forge CVS.

Better check with him.

Also the reason I put P3 and P4 as permanent "next release" priorities was to 
leave P1 and P2 for emergency patch cases only, which I assume will occur with 
most releases. However, you are probably right that there is no meaningful 
distinction between P3 and P4; except I thought maybe P4 could be those items 
which could be dropped from a release if the deadline is hit before they are 
done.

Greg

>Delivered-To: fix...@li...@fixme
>To: gen...@li...
>Subject: Re: [GeneX-dev] Bug tracking on sourceforge
>Mime-Version: 1.0 (generated by tm-edit 1.5)
>From: ja...@op... (Jason E. Stewart)
>Date: 29 Jan 2001 16:16:24 -0700
>
>I will think we could go with something that's above a P1 that mean's
>drop whatever you're doing, and fix this NOW!!! This would work well
>for things like user accounts on genex.ncgr.org not working,
>etc. Also, would we ever distinguish between a P3 and a P4, or do we
>just want a lump 'for next release' category, and once the current
>release goes out, we re-evaluate all the 'next-release' items up to P1
>or P2?
>
>I will start adding this to SourceForge.
>
>jas.
>
>_______________________________________________
>Genex-dev mailing list
>Gen...@li...
>http://lists.sourceforge.net/lists/listinfo/genex-dev

[GeneX-dev] SUMMARY: extra gibberish at top of list messages?

[Greg D. C. <gd...@nc...>]

Ok. Final note. Forrest showed me how to make CDE's DT mail tool on my Sun 
filter arbitrary header rows. Yeah! I now do not see the "List-" whatever rows.

So, ok, you all were right. You shamed me into actually dorking with the filter 
options on my emailer. I am no longer a filter virgin. Anybody got a cigarette?

Greg

>Delivered-To: fix...@li...@fixme
>To: gen...@li...
>Subject: Re: [GeneX-dev] extra gibberish at top of list messages?
>Mime-Version: 1.0 (generated by tm-edit 1.5)
>From: ja...@op... (Jason E. Stewart)
>Date: 25 Jan 2001 11:52:14 -0700
>
>I use an Emacs mail client, gnus, which also handles those headers
>just fine.
>
>I would say that the verdict is:
>  Sun's mail tool is the cause
>
>jas.
>
>"Harry Mangalam" <man...@ho...> writes:
>
>> What are youse guys using as mailers?
>> 
>> Netscape Messenger (what I use) has a configurable header filter, so I don;t 
see anything odd.  Michael, living on the edge of safety and sanity, uses 
Outlook, ands also doesn;t see anything odd.
>> 
>> hjm
>> 
>> 
>> "Greg D. Colello" wrote:
>> > 
>> > This is what it looks like to me. Since I did a REPLY TO I assume your 
filter
>> > will not recognize the lines anymore. The header you see in my REPLY copy 
should
>> > have 17 lines. I have enclosed this area with two dashed lines.
>> > 
>> > By the way there is another odd behavior. When I do a REPLY TO ALL with my
>> > mailer the group address (gen...@li...) appears twice.
>> > 
>> > Another strange thing I haven't analyzed is when Jason sends mail to this 
list,
>> > I get two copies of his email. I don't believe this has happened with 
anyone
>> > else.
>> > 
>> > Greg
>> > 
>> > ----------------------------------
>> > >From: Harry Mangalam <man...@ho...>
>> > >X-Accept-Language: en
>> > >MIME-Version: 1.0
>> > >To: genexdev at SF <gen...@li...>
>> > >Content-Transfer-Encoding: 7bit
>> > >Subject: [GeneX-dev] extra gibberish at top of list messages?
>> > >X-BeenThere: gen...@li...
>> > >X-Mailman-Version: 2.0
>> > >List-Help: <mailto:gen...@li...?subject=help>
>> > >List-Post: <mailto:gen...@li...>
>> > >List-Subscribe: <http://lists.sourceforge.net/lists/listinfo/genex-dev>,
>> > <mailto:gen...@li...?subject=subscribe>
>> > >List-Id: GeneX Developers' List <genex-dev.lists.sourceforge.net>
>> > >List-Unsubscribe: <http://lists.sourceforge.net/lists/listinfo/genex-dev>,
>> > <mailto:gen...@li...?subject=unsubscribe>
>> > >List-Archive: <http://lists.sourceforge.net/archives//genex-dev/>
>> > >Date: Wed, 24 Jan 2001 17:14:17 -0800
>> > ----------------------------------
>> > >
>> > >Hi All,
>> > >
>> > >Greg says that there are several extra lines at the top of things that get 
sent
>> > to the SF genex list (ie this message).  I don't see them (using Netscape 
mail);
>> > does anyone else?  could be they escape
>> > >the header filter for Greg's mail reader?
>> > >--
>> > >Cheers,
>> > >Harry
>> > >
>> > >Harry J Mangalam -- (949) 856 2847 (v&f) -- hj...@nc... || 
man...@ho...
>> > >
>> > >_______________________________________________
>> > >Genex-dev mailing list
>> > >Gen...@li...
>> > >http://lists.sourceforge.net/lists/listinfo/genex-dev
>> > 
>> > _______________________________________________
>> > Genex-dev mailing list
>> > Gen...@li...
>> > http://lists.sourceforge.net/lists/listinfo/genex-dev
>> 
>> -- 
>> Cheers,
>> Harry
>> 
>> Harry J Mangalam -- (949) 856 2847 (v&f) -- hj...@nc... || man...@ho...
>> 
>> _______________________________________________
>> Genex-dev mailing list
>> Gen...@li...
>> http://lists.sourceforge.net/lists/listinfo/genex-dev
>
>_______________________________________________
>Genex-dev mailing list
>Gen...@li...
>http://lists.sourceforge.net/lists/listinfo/genex-dev

Re: [GeneX-dev] Bug tracking on sourceforge

[<ja...@op...>]

"Greg D. Colello" <gd...@nc...> writes:

> Greg
> 
> >Some ideas:
> >* Switch completely to SourceForge's builtin tracking system. Maybe,
> >  for the long term, probably not for the short term
> 
> Desirable choice I think. This works for core development. We can then just 
> continue to use NCGR bugzilla only for commercial items.

Ok, I'm game.

> This is all reasonable; however, based on past experience, putting
> timelines on priorities will probably be ignored. Also, the "release
> after next" task lists always seem to change. Might as well just say
> future. Also, those other designations, like "critical" never get
> maintained. How about:
> 
> P1: High Priority Patch to Current Release (ASAP)
> P2: Lower Priority Patch to Current Release (before next release or make P3)
> P3: High Priority Item for Next Release
> P4: Lower Priority Item for Next Release (slip deadline or drop items to P5)
> P5: Future (don't work on this unless specifically told to)
> 
> normal = bug (should be the default)
> enhancement = new feature, not a bug
> 

OK. I agree with the normal vs enhancement, the others seem
pointless. 

I will think we could go with something that's above a P1 that mean's
drop whatever you're doing, and fix this NOW!!! This would work well
for things like user accounts on genex.ncgr.org not working,
etc. Also, would we ever distinguish between a P3 and a P4, or do we
just want a lump 'for next release' category, and once the current
release goes out, we re-evaluate all the 'next-release' items up to P1
or P2?

I will start adding this to SourceForge.

jas.

Re: [GeneX-dev] Bug tracking on sourceforge

[Lonnie M. <lx...@nc...>]

Jas,

You're not the only one not using Bugzilla.  I think we all are guilty there.  I agree with you that we need to open up the bug tracking on sourceforge.  I think we should convert to the sourceforge bug tracking as soon as we get everything on sourceforge cvs set up.  After all I think the plan was to use sourceforge for our core development.  I think (correct me if I'm wrong ) that we wanted to use sourceforge cvs, bug tracking, etc. for everything we do fo the core development.  that way it is always up to date.  I think we need to start moving toward this as soon as we can.  I also think it should be completely in place before the 1.0 release.



To that end, as far as the curation tool goes, we just need to set up the install scripts to use JAVA_HOME or something to replace the jdk and jre on cvs.  After that we should be ready to go live with sourceforge cvs.


Any other thoughts on this anyone?


Todd, by the way, your sourceforge account is now active.


Lonny


>  Hey All,
> 
> Since it has come to my attention that I am not:
> * responding to bugs filed
> * working on code not associated with existing bug reports
> 
> I've started updating my bugs on NCGR's bugzilla. However, we need a
> policy for opening up to bugs from sourceforge.
> 
> Some ideas:
> * punt -- not a good one, I think
> * Switch completely to SourceForge's builtin tracking system. Maybe,
>   for the long term, probably not for the short term
> * Allow non-NCGR folks to register bugs at SF, and move them over to
>   NCGR's bugzilla when verified.
> * Run both SF's bug tracking and NCGR's bugzilla concurrently.
> 
> I feel at the very least we should configure SF's bug tracking. This
> means setting our 'Categories' and 'Groups'. The rest is done. Since
> you have to be registered at NCGR's bugzilla, this will never be
> something we open up to the mass-public. To use the SF bug tracker,
> they just have to register with SF, this makes it more accessible.
> 
> jas.
> 
> PS. It seems that we want to add a 'Genex-sourceforge' category to the
> bugzilla at NCGR. Also we should remove the 'genex-www' category. It's
> too broad, the bug should be filed under another category.
> 
> PPS. We should agree on guidelines for what priorities P1-5 mean, as
> well as what the severities 'critical' -> 'enhancement' mean. If too
> much stuff gets filed as P1, then it means nothing. How about:
> 
> P1: fix should be in place by end of week
> P2: fix in place within 10 business days
> P3: fix in place by next release
> P4: fix by release after-next
> P5: no date
> 
> This way the default is P3, and if we file with P1 or P2, it's
> important to do it *soon*.
> 
> critical: Some major sub-system is broken, perhaps we could reserve
>   this one for publicly visible breakage on SourceForge or the
>   ncgr.org WWW sites, or some download capability
> major: major sub-system is broken for local installations, not NCGR
>   public site, e.g. query script is broken, no experiment retrieval
>   possible 
> normal: Some component is not working as specified, e.g. a WWW link on
>   a CGI generated WWW page cannot access the specified file
> minor: an appearance bug, e.g. an HTML table mislabeled, no
>   functionality is broken
> trivial: this is pointless, let's not use it
> enhancement: this means new behavior, not a bug
> 
> _______________________________________________
> Genex-dev mailing list
> Gen...@li...
> http://lists.sourceforge.net/lists/listinfo/genex-dev
> 

Re: [GeneX-dev] Bug tracking on sourceforge

[Greg D. C. <gd...@nc...>]

Jason:

Good questions. See selected replies below...
 
Greg

>Delivered-To: fix...@li...@fixme
>To: gen...@li...
>Mime-Version: 1.0 (generated by tm-edit 1.5)
>From: ja...@op... (Jason E. Stewart)
>Subject: [GeneX-dev] Bug tracking on sourceforge
>X-BeenThere: gen...@li...
>X-Mailman-Version: 2.0

>Some ideas:
>* Switch completely to SourceForge's builtin tracking system. Maybe,
>  for the long term, probably not for the short term

Desirable choice I think. This works for core development. We can then just 
continue to use NCGR bugzilla only for commercial items.
 
>PS. It seems that we want to add a 'Genex-sourceforge' category to the
>bugzilla at NCGR. Also we should remove the 'genex-www' category. It's
>too broad, the bug should be filed under another category.

Don't need to worry about any of this if we use SourceForge bug tracking for all 
core development.

>PPS. We should agree on guidelines for what priorities P1-5 mean, as
>well as what the severities 'critical' -> 'enhancement' mean. If too
>much stuff gets filed as P1, then it means nothing. How about:
>
>P1: fix should be in place by end of week
>P2: fix in place within 10 business days
>P3: fix in place by next release
>P4: fix by release after-next
>P5: no date
>
>This way the default is P3, and if we file with P1 or P2, it's
>important to do it *soon*.
>
>critical: Some major sub-system is broken, perhaps we could reserve
>  this one for publicly visible breakage on SourceForge or the
>  ncgr.org WWW sites, or some download capability
>major: major sub-system is broken for local installations, not NCGR
>  public site, e.g. query script is broken, no experiment retrieval
>  possible 
>normal: Some component is not working as specified, e.g. a WWW link on
>  a CGI generated WWW page cannot access the specified file
>minor: an appearance bug, e.g. an HTML table mislabeled, no
>  functionality is broken
>trivial: this is pointless, let's not use it
>enhancement: this means new behavior, not a bug

This is all reasonable; however, based on past experience, putting timelines on 
priorities will probably be ignored. Also, the "release after next" task lists 
always seem to change. Might as well just say future. Also, those other 
designations, like "critical" never get maintained. How about:

P1: High Priority Patch to Current Release (ASAP)
P2: Lower Priority Patch to Current Release (before next release or make P3)
P3: High Priority Item for Next Release
P4: Lower Priority Item for Next Release (slip deadline or drop items to P5)
P5: Future (don't work on this unless specifically told to)

normal = bug (should be the default)
enhancement = new feature, not a bug

Developers do what they can as fast as they can in priority order. Project tries 
to set "Next Release" task lists that can be accomplished by the desired release 
date.

On release day there should be no P1's or P2's; and there should be a whole new 
set of P3's and P4's.

Re: [GeneX-dev] GeneX Sourceforge Web page template

[Jiaye Z. <ze...@in...>]

Exactly what I'm afraid of...I know that netscape is funky with support for 
stylesheets and layers...maybe so much for that idea, I can see about another 
approach or scratching the idea all together?

jiaye

Quoting "Jason E. Stewart" <ja...@op...>:

> "Jiaye Zhou" <ze...@in...> writes:
> 
> > Hi Harry, should have talked to you earlier about this. I generated
> > a javascript driven navigation bar that expands and collapses when
> 
> These seems like a good idea. It is broken for the following browsers:
> * Netscape 4.73 on linux-i86: the menus expand, but the text overlaps
>   horribly and is unreadable
> * Mozilla on linux-ppc:
> * Konqueror on linux-ppc: Neither of these expand the menus.
> 
> jas.
> 
> _______________________________________________
> Genex-dev mailing list
> Gen...@li...
> http://lists.sourceforge.net/lists/listinfo/genex-dev
> 

Re: [GeneX-dev] List Ettiquette

[<ja...@op...>]

Also, as Greg just pointed out to me, since we all are on the
sourceforge list, it is a nice idea to trim down the To: and Cc: lines
to avoid getting an avalanche of duplicate emails.

Thanks,
jas.

Re: [GeneX-dev] GeneX Sourceforge Web page template

[<ja...@op...>]

"Jiaye Zhou" <ze...@in...> writes:

> Hi Harry, should have talked to you earlier about this. I generated
> a javascript driven navigation bar that expands and collapses when

These seems like a good idea. It is broken for the following browsers:
* Netscape 4.73 on linux-i86: the menus expand, but the text overlaps
  horribly and is unreadable
* Mozilla on linux-ppc:
* Konqueror on linux-ppc: Neither of these expand the menus.

jas.

[GeneX-dev] Bug tracking on sourceforge

[<ja...@op...>]

Hey All,

Since it has come to my attention that I am not:
* responding to bugs filed
* working on code not associated with existing bug reports

I've started updating my bugs on NCGR's bugzilla. However, we need a
policy for opening up to bugs from sourceforge.

Some ideas:
* punt -- not a good one, I think
* Switch completely to SourceForge's builtin tracking system. Maybe,
  for the long term, probably not for the short term
* Allow non-NCGR folks to register bugs at SF, and move them over to
  NCGR's bugzilla when verified.
* Run both SF's bug tracking and NCGR's bugzilla concurrently.

I feel at the very least we should configure SF's bug tracking. This
means setting our 'Categories' and 'Groups'. The rest is done. Since
you have to be registered at NCGR's bugzilla, this will never be
something we open up to the mass-public. To use the SF bug tracker,
they just have to register with SF, this makes it more accessible.

jas.

PS. It seems that we want to add a 'Genex-sourceforge' category to the
bugzilla at NCGR. Also we should remove the 'genex-www' category. It's
too broad, the bug should be filed under another category.

PPS. We should agree on guidelines for what priorities P1-5 mean, as
well as what the severities 'critical' -> 'enhancement' mean. If too
much stuff gets filed as P1, then it means nothing. How about:

P1: fix should be in place by end of week
P2: fix in place within 10 business days
P3: fix in place by next release
P4: fix by release after-next
P5: no date

This way the default is P3, and if we file with P1 or P2, it's
important to do it *soon*.

critical: Some major sub-system is broken, perhaps we could reserve
  this one for publicly visible breakage on SourceForge or the
  ncgr.org WWW sites, or some download capability
major: major sub-system is broken for local installations, not NCGR
  public site, e.g. query script is broken, no experiment retrieval
  possible 
normal: Some component is not working as specified, e.g. a WWW link on
  a CGI generated WWW page cannot access the specified file
minor: an appearance bug, e.g. an HTML table mislabeled, no
  functionality is broken
trivial: this is pointless, let's not use it
enhancement: this means new behavior, not a bug

Re: [GeneX-dev] GeneX Sourceforge Web page template

[Jiaye Z. <ze...@in...>]

Hi Harry, should have talked to you earlier about this. I generated a javascript 
driven navigation bar that expands and collapses when accessing menu items. This 
essentially is trying to accomplish the same as one you just posted. (I 
thought collapsable nav bar can help to organize items better). It was uploaded 
to your server this morning before class and I didn't get a change to email. 
Anyway, if you would like to take a look at it, it's at. 
http://24.1.175.29/sf/menu.html
And this could be part of a frame or a ssi. 

Jiaye


Quoting Harry Mangalam <man...@ho...>:

> Please look at it and comment on the layout and especially what the nav
> bar should include.  It will be turned into a shtml so the nav bar can
> be included everywhere and the color choices are
> certainly up for discussion.  As is the Header title graphics, but I do
> want it to be kept as simple as possible.
> 
> Real content and live links are going in as soon as I send this and I
> think we can replace the currenplace holder by tonight or tomorrow.
> 
> http://24.1.175.29/sf/index.hjm.html
> -- 
> Cheers,
> Harry
> 
> Harry J Mangalam -- (949) 856 2847 (v&f) -- hj...@nc... ||
> man...@ho...
> 
> _______________________________________________
> Genex-dev mailing list
> Gen...@li...
> http://lists.sourceforge.net/lists/listinfo/genex-dev
> 

Re: [GeneX-dev] GeneX Sourceforge Web page template

[<ja...@op...>]

"Lonnie Montoya" <lx...@nc...> writes:

> I like the look of the page.  The content of the nav bar seems
> pretty useful.  I think the blue is a nice color.  Am I
> hallucinating or has your color coordination gotten better?

couldn't have gotten worse, que no? ;-) And, yes, blue is better.

I would like to see the links in the nav bar be bulleted. I use a
fairly large font, and many of the links look like two or three
separate entries.

Also, we should probably not be too verbose, e.g. (incl Database
scripts & Genex.pm Perl API) is too much text. 

The Other required software maybe wants to be it's own separate page
where we repeat that section from INSTALL with embedded links

I noticed you took of the review, is it not yet available?

jas.

Re: [GeneX-dev] GeneX Sourceforge Web page template

[Greg D. C. <gd...@nc...>]

Harry:

Ok. Let's see. I vaguely remember in a past meeting you saying that SourceForge 
has a default page. We would have to use that for now until we create our own. 
If memory serves correctly, then you can actually replace the existing default 
page. Yes?

If so, then I assume you intend to recapture most of the info that's on the 
default page and add to it. Or are there things on the default page you want to 
intentionally exclude?

Greg

>From: Harry Mangalam <man...@ho...>
>X-Accept-Language: en
>MIME-Version: 1.0
>To: gen...@li...
>Subject: Re: [GeneX-dev] GeneX Sourceforge Web page template
>Content-Transfer-Encoding: 7bit
>X-BeenThere: gen...@li...
>X-Mailman-Version: 2.0
>Date: Mon, 29 Jan 2001 11:59:10 -0800
>
>Greg, it's for the Sourceforge Web site to be the GeneX Face to the world, for 
release and dev work.
>
>"Greg D. Colello" wrote:
>> I must have missed something. I didn't understand what your email was about.
>
>-- 
>Cheers,
>Harry
>
>Harry J Mangalam -- (949) 856 2847 (v&f) -- hj...@nc... || man...@ho...
>
>_______________________________________________
>Genex-dev mailing list
>Gen...@li...
>http://lists.sourceforge.net/lists/listinfo/genex-dev

Re: [GeneX-dev] GeneX Sourceforge Web page template

[Lonnie M. <lx...@nc...>]

Harry,

I like the look of the page.  The content of the nav bar seems pretty useful.  I think the blue is a nice color.  Am I hallucinating or has your color coordination gotten better?

Lonny

> 
> Please look at it and comment on the layout and especially what the nav bar should include.  It will be turned into a shtml so the nav bar can be included everywhere and the color choices are
> certainly up for discussion.  As is the Header title graphics, but I do want it to be kept as simple as possible.
> 
> Real content and live links are going in as soon as I send this and I think we can replace the currenplace holder by tonight or tomorrow.
> 
> http://24.1.175.29/sf/index.hjm.html
> -- 
> Cheers,
> Harry
> 
> Harry J Mangalam -- (949) 856 2847 (v&f) -- hj...@nc... || man...@ho...
> 
> _______________________________________________
> Genex-dev mailing list
> Gen...@li...
> http://lists.sourceforge.net/lists/listinfo/genex-dev
> 

Re: [GeneX-dev] Summaries for Listserv

[Harry M. <man...@ho...>]

"Jason E. Stewart" wrote:

> This could be handled if we installed FAQ-o-Matic on the source forge
> site.
> 
> Harry, would this be useful?

Yes, but only when we get a useful stream of info built up.  I've installed a FOM on my machine, and it's not hard - I wonder if SF will allow us to install it there or maybe we'll just have to link
to it here.
-- 
Cheers,
Harry

Harry J Mangalam -- (949) 856 2847 (v&f) -- hj...@nc... || man...@ho...