Menu
▾
▴
genex-dev
|
From: Greg D. C. <gd...@nc...> - 2001-01-29 22:12:37
|
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. |
|
From: Greg D. C. <gd...@nc...> - 2001-01-30 01:44:18
|
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 |
|
From: Lonnie M. <lx...@nc...> - 2001-01-30 03:31:18
|
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 > |
|
From: Greg D. C. <gd...@nc...> - 2001-02-01 02:50:39
|
Jason: I really appreciate you taking care of this, but I don't understand your bug priority assignments. The way I think about GeneX releases is that we will have a CURRENT production release, which should be stable unless emergency patches are required. Patches are the only acceptable repair mechanism to a CURRENT release. Therefore, patches should have a priority named after them. Otherwise another production release must be built, but then that's the NEXT release. At the same time that we have have a CURRENT release in deployment, we are developing the NEXT release. It will have its own priorities. Then there are simply FUTURE release items. Therefore, it seems like we need bug priorities that reflect these divisions. Your priorities seem to all be about the CURRENT and FUTURE releases. Or is it about the NEXT and FUTURE releases? Maybe there is some kind of symantic problem with my understanding of the meanings of CURRENT and NEXT? Greg >Delivered-To: fix...@li...@fixme >To: gen...@li... >Cc: 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: 31 Jan 2001 13:13:21 -0700 > >Here then is the proposal for the use of the SF bug tracking system. > >SourceForge Bug track priority >9: Critical Failure, Must Fix Immediately >8: Major Bug Must fix in this release >7: Important BugFix in this release if possible >6: Minor Bug, re-examine priority in next release >5-1: Don't work on unless instructed > >The procedure: >When a bug is submitted agains you >* If you *don't* think it belongs to you, re-assign it to someone who > can decide. >* If it does apply: >1) If the priority is not set correctly, correct it in the bug admin > page (https://sourceforge.net/bugs/?group_id=16453) >2) Forward it to the buglist (gen...@li...), and > Make a note in the forward to any other developers ought to pay > attention. > >jas. > >_______________________________________________ >Genex-dev mailing list >Gen...@li... >http://lists.sourceforge.net/lists/listinfo/genex-dev |
|
From: <ja...@op...> - 2001-02-01 04:35:12
|
"Greg D. Colello" <gd...@nc...> writes: > I really appreciate you taking care of this, but I don't understand > your bug priority assignments. You're welcome. I figure this is a critical enough issue that we want to make sure that it's well understood and working within our relatively small group before we start getting other developers involved. > The way I think about GeneX releases is that we will have a CURRENT > production release, which should be stable unless emergency patches > are required. Patches are the only acceptable repair mechanism to a > CURRENT release. Therefore, patches should have a priority named > after them. Otherwise another production release must be built, but > then that's the NEXT release. > > At the same time that we have have a CURRENT release in deployment, > we are developing the NEXT release. It will have its own priorities. > > Then there are simply FUTURE release items. Ok. Terminology her is critical. First, remember that we will soon have a PRODUCTION and a DEVELOPMENT branch (or at least I hope this is decided and that I'm not telling everybody else it needs to be this way). Let's deal with each separately to see if they differ somehow. <terminology> PRODUCTION is the stable release. We should not be adding new features here. Only bug-fixes and items that get back-ported from DEVELOPMENT because they are critical. DEVELOPMENT is the exploration branch. New features are added here until they become stable, at which time the stable version of DEVELOPMENT becomes the new release of PRODUCTION (with an accompanying version number increase). For example, soon we will release v1.0.0 of the Server. all 1.0.x releases after that will be bug fixes on the stable 1.0 PRODUCTION release. The 1.1.x branch is DEVELOPMENT, and when 1.1 becomes stable, we release 1.2.0 which is the new PRODUCTION and 1.3.0 becomes the new DEVELOPMENT. Let's define CURRENT to mean the thing we just released. We'll define NEXT as the thing we're currently working gathering pathces for. If we had a FUTURE category it would mean items not intended to go into NEXT. </terminology> Now lets look at were the bugs fall. We can never effect CURRENT, it's already out the door, so all bugs go in either NEXT or FUTURE, don't they? PRODUCTION does not have a concept of FUTURE, either it's an important piece and it goes in NEXT or it isn't important and it shouldn't be in PRODUCTION, it should be in DEVELOPMENT, right? And for DEVELOPMENT all bugs that are important go in NEXT, and those that can wait go in FUTURE. That leaves three categories: PRODUCTION:NEXT DEVELOPMENT:NEXT DEVELOPMENT:FUTURE According to the system I proposed: >SourceForge Bug track priority >9: Critical Failure, Must Fix Immediately >8: Major Bug Must fix in this release >7: Important BugFix in this release if possible >6: Minor Bug, re-examine priority in next release >5-1: Don't work on unless instructed <9> stays the same, it is for items that are time sensitive, this could be fixing a piece of hardware, to restarting a wWW server. These are drop-whatever- you're-doing items. If they apply at all to software, then they are likely to be PRODUCTION related, requiring an immediate bug-fix release <8> Applies equally to PRODUCTION and DEVELOPMENT <7> seems only to apply to DEVELOPMENT, if it isn't really so important that it needs fixing for the next release, it sounds like a DEVELOPEMENT issue <6> is FUTURE, and only applies to DEVELOPMENT <5-1> are stuff that we're just keeping on the back burning for another time. Comments? Am I halucinatory? jas. |
|
From: <ja...@op...> - 2001-01-29 23:15:14
|
"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. |
|
From: Todd P. <tf...@nc...> - 2001-01-31 16:50:57
|
The current bug system on SF has the priorities annotated with the following: 1 Lowest ... 5 Medium ... 9 Highest This is opposite to the scheme below. Can we change the Lowest, Medium, Highest to our own interpretations? > > >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*. > > > |
|
From: <ja...@op...> - 2001-01-31 19:04:59
|
"Todd Peterson" <tf...@nc...> writes:
> The current bug system on SF has the priorities annotated with the
> following:
>
> 1 Lowest
> ...
> 5 Medium
> ...
> 9 Highest
>
> This is opposite to the scheme below. Can we change the Lowest, Medium,
> Highest to our own interpretations?
What do people feel. I think that 9 priorities are pointless, there
are at least 3 that will never get used.
Todd, if you're suggesting that we switch the SF priority scheme so
that 1 is high and 9 is low, that might be a problem. Since that
information is auto-generated by the SF scripts, we cannot change
it. That means users that examine our bug list will see all theses
priority one bugs, which sourceforge claims is *low* priority.
Perhaps what we want is to map:
Genex SourceForge
Bugzilla: Bug track
P0: Critical Failure 9:
Must Fix Immediately
P1 Major Bug 8:
Must fix in this release
P2 Important Bug 7:
Fix in this release if possible
P3 Minor Bug 6:
Fix in next release
P4 Minor Bug --
(redundant with P3)
P5 Don't work on unless instructed 5: (or 1:)?
jas.
|
|
From: Harry M. <man...@ho...> - 2001-01-31 19:39:47
|
"Jason E. Stewart" wrote: > What do people feel. I think that 9 priorities are pointless, there > are at least 3 that will never get used. 9 categories are useless. Probably 6 are too many; 4 is about right, but I don't really care too much; I'll ignore all less than the top 2 :). Re: the priority numbering inversion. Not enough confusion to worry about. We're big boys. We can count up as well as down. In conversation, refer to HIGH priority vs low pri and the point will be made. > Todd, if you're suggesting that we switch the SF priority scheme so > that 1 is high and 9 is low, that might be a problem. Since that > information is auto-generated by the SF scripts, we cannot change > it. That means users that examine our bug list will see all theses > priority one bugs, which sourceforge claims is *low* priority. > > Perhaps what we want is to map: > > Genex SourceForge > Bugzilla: Bug track > > P0: Critical Failure 9: > Must Fix Immediately > P1 Major Bug 8: > Must fix in this release > P2 Important Bug 7: > Fix in this release if possible > P3 Minor Bug 6: > Fix in next release > P4 Minor Bug -- > (redundant with P3) > P5 Don't work on unless instructed 5: (or 1:)? > > jas. > > _______________________________________________ > 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... |
|
From: Lonnie M. <lx...@nc...> - 2001-01-31 20:11:19
|
I agree with Harry, letsleave it like it is in sourceforge. Lonny > > "Jason E. Stewart" wrote: > > What do people feel. I think that 9 priorities are pointless, there > > are at least 3 that will never get used. > > 9 categories are useless. Probably 6 are too many; 4 is about right, but I don't really care too much; I'll ignore all less than the top 2 :). > > Re: the priority numbering inversion. Not enough confusion to worry about. We're big boys. We can count up as well as down. In conversation, refer to HIGH priority vs low pri and the point will be > made. > > > > > Todd, if you're suggesting that we switch the SF priority scheme so > > that 1 is high and 9 is low, that might be a problem. Since that > > information is auto-generated by the SF scripts, we cannot change > > it. That means users that examine our bug list will see all theses > > priority one bugs, which sourceforge claims is *low* priority. > > > > Perhaps what we want is to map: > > > > Genex SourceForge > > Bugzilla: Bug track > > > > P0: Critical Failure 9: > > Must Fix Immediately > > P1 Major Bug 8: > > Must fix in this release > > P2 Important Bug 7: > > Fix in this release if possible > > P3 Minor Bug 6: > > Fix in next release > > P4 Minor Bug -- > > (redundant with P3) > > P5 Don't work on unless instructed 5: (or 1:)? > > > > jas. > > > > _______________________________________________ > > 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 > |
|
From: Jiaye Z. <ze...@in...> - 2001-01-31 23:58:16
|
Hi Lonny, Greg, I am helping Wei Chen from UNM High Performance Computing Center preparing a data set for upload using the Curation Tool. She downloaded the latest version (v0.81). Seems there is a bug, unless I'm terribly mistaken. After selecting "creating new experiment set" and in the "Import Experiement Set Data File" section, "New Experiment Set" window. I was able to import a set of files (sequence feature, arraylayout and measurement data file). But only sequence feature file has the "Import Genex Data" button activated. No matter what I do, the button is grayed out when I selet the other files. After messing with it for a while, I decided to use the test data files included with the distribution, turned out that the same thing happened. Curation Tool is allowing only importing data from the sequence feature file and not the others. Is this another "random bug" that got introduced with the new version? Jason couldn't get v0.81 to run on his machine, so I could not verify this. Could someone else, perhaps someone knows the CT better than I, test it? We are running it on NT. Thanks, Jiaye |
|
From: Jiaye Z. <ze...@in...> - 2001-02-01 00:25:25
|
Sorry, Sorry, Sorry!!! My bad, somehow I managed to miss the big yellow "finish" button. heehee. Please don't shoot me. What happend was that after validating the files again the col files, I never clicked the finish button (thought it was just a status window for over 10 time!) and clicked on close button. Of course, without knowing that the next screen should look like, I thought everything imported just fine. After talking to greg, I realized the crime that I had committed. So please forgive me...I would bring up one point though, perhaps it is helpful to have the "finish" button say "click here to finish" instead to help dummies like me? jiaye Quoting Jiaye Zhou <ze...@in...>: > Hi Lonny, Greg, > > I am helping Wei Chen from UNM High Performance Computing Center > preparing a > data set for upload using the Curation Tool. She downloaded the latest > version > (v0.81). Seems there is a bug, unless I'm terribly mistaken. After > selecting > "creating new experiment set" and in the "Import Experiement Set Data > File" > section, "New Experiment Set" window. I was able to import a set of > files > (sequence feature, arraylayout and measurement data file). But only > sequence > feature file has the "Import Genex Data" button activated. No matter > what I do, > the button is grayed out when I selet the other files. After messing > with it for > a while, I decided to use the test data files included with the > distribution, > turned out that the same thing happened. Curation Tool is allowing only > importing data from the sequence feature file and not the others. Is > this > another "random bug" that got introduced with the new version? Jason > couldn't > get v0.81 to run on his machine, so I could not verify this. Could > someone else, > perhaps someone knows the CT better than I, test it? We are running it > on NT. > Thanks, > > Jiaye > > _______________________________________________ > Genex-dev mailing list > Gen...@li... > http://lists.sourceforge.net/lists/listinfo/genex-dev > |
|
From: Todd P. <tf...@nc...> - 2001-01-31 19:55:00
|
Whatever is simplest to implement and avoids any confusion is ok with me. ----- Original Message ----- From: "Jason E. Stewart" <ja...@op...> To: <gen...@li...> Sent: Wednesday, January 31, 2001 12:06 PM Subject: Re: [GeneX-dev] Bug tracking on sourceforge > "Todd Peterson" <tf...@nc...> writes: > > > The current bug system on SF has the priorities annotated with the > > following: > > > > 1 Lowest > > ... > > 5 Medium > > ... > > 9 Highest > > > > This is opposite to the scheme below. Can we change the Lowest, Medium, > > Highest to our own interpretations? > > What do people feel. I think that 9 priorities are pointless, there > are at least 3 that will never get used. > > Todd, if you're suggesting that we switch the SF priority scheme so > that 1 is high and 9 is low, that might be a problem. Since that > information is auto-generated by the SF scripts, we cannot change > it. That means users that examine our bug list will see all theses > priority one bugs, which sourceforge claims is *low* priority. > > Perhaps what we want is to map: > > Genex SourceForge > Bugzilla: Bug track > > P0: Critical Failure 9: > Must Fix Immediately > P1 Major Bug 8: > Must fix in this release > P2 Important Bug 7: > Fix in this release if possible > P3 Minor Bug 6: > Fix in next release > P4 Minor Bug -- > (redundant with P3) > P5 Don't work on unless instructed 5: (or 1:)? > > jas. > > > _______________________________________________ > Genex-dev mailing list > Gen...@li... > http://lists.sourceforge.net/lists/listinfo/genex-dev > |
|
From: <ja...@op...> - 2001-01-31 20:12:05
|
Here then is the proposal for the use of the SF bug tracking system. SourceForge Bug track priority 9: Critical Failure, Must Fix Immediately 8: Major Bug Must fix in this release 7: Important BugFix in this release if possible 6: Minor Bug, re-examine priority in next release 5-1: Don't work on unless instructed The procedure: When a bug is submitted agains you * If you *don't* think it belongs to you, re-assign it to someone who can decide. * If it does apply: 1) If the priority is not set correctly, correct it in the bug admin page (https://sourceforge.net/bugs/?group_id=16453) 2) Forward it to the buglist (gen...@li...), and Make a note in the forward to any other developers ought to pay attention. jas. |
Thanks for helping keep SourceForge clean.
X