You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Jeff Dever <js...@sympatico.ca> on 2002/08/01 16:22:14 UTC
Change tracking and bugzilla limitations
Goodday,
I'm the new release manager for the commons httpclient subproject. We
are using Bugzilla to track both software faults and features, which
bugzilla handles quite well. We are also trying to use bugzilla for
forcasting in which milestone/release a particular feature should be
added or a fault fixed. Bugzilla does not handle this quite so well.
One problem is that there is only one "Version" field. Typically this
would be used for the version that a software fault (aka bug) was "found
in". We are left to use this field to specify which release the
fault/feature is "forcast" to be completed in.
The other problem is that in a report list, the version column is only 5
characters. With release names like 2.0 Beta 1, 2.0 Beta 2, the
resulting list only shows "2.0 B" which is insuficient information. I
could see no way for a user to change this.
Another issue with bugzilla is that sorting by any key other than the
bug name simply does not work on any browser I have tried.
I'm looking for suggestions on how to handle all this. Are we moving to
the new Scarab system somtime soon? Should I raise bug reports against
bugzilla? Is there some other configuration of bugzilla that can be
done to help me manage bugs/features in a change management way?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Change tracking and bugzilla limitations
Posted by Jeff Dever <js...@sympatico.ca>.
I see. Request made. Thanks Martin.
Martin van den Bemt wrote:
> Oops.. I see what you mean.. On nagoya it is not switched on..
> Ask an admin to go to parameters, and switch on usertargetmilestone
>
> Mvgr,
> Martin
>
> On Thu, 2002-08-01 at 22:31, Martin van den Bemt wrote:
> > The version field is the version of the software the bug is in,
> > the milestone field is for saying "we are trying to fixe it at
> > milestone...."
> > Heavily used by a lot of projects....
> >
> > Mvgr,
> > Martin
> >
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Change tracking and bugzilla limitations
Posted by Martin van den Bemt <ml...@mvdb.net>.
Thanx.
Mvgr,
Martin
On Fri, 2002-08-02 at 00:49, Pier Fumagalli wrote:
> "Martin van den Bemt" <ml...@mvdb.net> wrote:
>
> > I wouldn't mind doing it..
> > My account is mvdb@apache.org (I'm a commons committer btw), if you want
> > to let me set it up.
>
> Logout and relogin. You'll have the right perms.
>
> Pier
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Change tracking and bugzilla limitations
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Martin van den Bemt" <ml...@mvdb.net> wrote:
> I wouldn't mind doing it..
> My account is mvdb@apache.org (I'm a commons committer btw), if you want
> to let me set it up.
Logout and relogin. You'll have the right perms.
Pier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Change tracking and bugzilla limitations
Posted by Martin van den Bemt <ml...@mvdb.net>.
Pier,
I wouldn't mind doing it..
My account is mvdb@apache.org (I'm a commons committer btw), if you want
to let me set it up.
Mvgr,
Martin
On Thu, 2002-08-01 at 22:51, Jeff Dever wrote:
> Wow thats fast!
>
> One more thing, some of the release names that are currently in
> "version" need to be moved or copied to the new "target milestone" field.
> This includes:
> 2.0 Milestone 1
> 2.0 Milestone 2
> 2.0 Beta 1
> 2.0 Beta 2
> 2.0 Final
> 2.1 Final
>
> Thanks.
>
>
> Pier Fumagalli wrote:
>
> > "Martin van den Bemt" <ml...@mvdb.net> wrote:
> >
> > > Oops.. I see what you mean.. On nagoya it is not switched on..
> > > Ask an admin to go to parameters, and switch on usertargetmilestone
> >
> > Fixed
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Change tracking and bugzilla limitations
Posted by Martin van den Bemt <ml...@mvdb.net>.
I added them.Couldn't do it earlier, since I was sleeping ;)
Mvgr,
Martin
On Thu, 2002-08-01 at 22:51, Jeff Dever wrote:
> Wow thats fast!
>
> One more thing, some of the release names that are currently in
> "version" need to be moved or copied to the new "target milestone" field.
> This includes:
> 2.0 Milestone 1
> 2.0 Milestone 2
> 2.0 Beta 1
> 2.0 Beta 2
> 2.0 Final
> 2.1 Final
>
> Thanks.
>
>
> Pier Fumagalli wrote:
>
> > "Martin van den Bemt" <ml...@mvdb.net> wrote:
> >
> > > Oops.. I see what you mean.. On nagoya it is not switched on..
> > > Ask an admin to go to parameters, and switch on usertargetmilestone
> >
> > Fixed
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Change tracking and bugzilla limitations
Posted by Jeff Dever <js...@sympatico.ca>.
Wow thats fast!
One more thing, some of the release names that are currently in
"version" need to be moved or copied to the new "target milestone" field.
This includes:
2.0 Milestone 1
2.0 Milestone 2
2.0 Beta 1
2.0 Beta 2
2.0 Final
2.1 Final
Thanks.
Pier Fumagalli wrote:
> "Martin van den Bemt" <ml...@mvdb.net> wrote:
>
> > Oops.. I see what you mean.. On nagoya it is not switched on..
> > Ask an admin to go to parameters, and switch on usertargetmilestone
>
> Fixed
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Change tracking and bugzilla limitations
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Martin van den Bemt" <ml...@mvdb.net> wrote:
> Oops.. I see what you mean.. On nagoya it is not switched on..
> Ask an admin to go to parameters, and switch on usertargetmilestone
Fixed
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Change tracking and bugzilla limitations
Posted by Martin van den Bemt <ml...@mvdb.net>.
Oops.. I see what you mean.. On nagoya it is not switched on..
Ask an admin to go to parameters, and switch on usertargetmilestone
Mvgr,
Martin
On Thu, 2002-08-01 at 22:31, Martin van den Bemt wrote:
> The version field is the version of the software the bug is in,
> the milestone field is for saying "we are trying to fixe it at
> milestone...."
> Heavily used by a lot of projects....
>
> Mvgr,
> Martin
>
> On Thu, 2002-08-01 at 22:24, Jeff Dever wrote:
> > >
> > > > One problem is that there is only one "Version" field. Typically this
> > > > would be used for the version that a software fault (aka bug) was "found
> > > > in". We are left to use this field to specify which release the
> > > > fault/feature is "forcast" to be completed in.
> > >
> > > It is, you have to use the milestone field to "forecast"..
> > >
> >
> > Not sure I understand your response. Currently I am using the version field
> > as forecast (somtimes), which is a hack as any "found in" information is lost
> > for software faults (unless added as a comment). This is not typical of the
> > change tracking systems I am familar with in industry (clear quality and
> > prostar).
> >
> > But I'm all for jumping on the Scarab bandwagon.
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Change tracking and bugzilla limitations
Posted by Jeff Dever <js...@sympatico.ca>.
Hmm, I don't have a "milestone" field at all. HttpClient is in commons, not sure
if there are different schemas for different projects or what.
eg: http://issues.apache.org/bugzilla/show_bug.cgi?id=6513
Martin van den Bemt wrote:
> The version field is the version of the software the bug is in,
> the milestone field is for saying "we are trying to fixe it at
> milestone...."
> Heavily used by a lot of projects....
>
> Mvgr,
> Martin
>
> On Thu, 2002-08-01 at 22:24, Jeff Dever wrote:
> > >
> > > > One problem is that there is only one "Version" field. Typically this
> > > > would be used for the version that a software fault (aka bug) was "found
> > > > in". We are left to use this field to specify which release the
> > > > fault/feature is "forcast" to be completed in.
> > >
> > > It is, you have to use the milestone field to "forecast"..
> > >
> >
> > Not sure I understand your response. Currently I am using the version field
> > as forecast (somtimes), which is a hack as any "found in" information is lost
> > for software faults (unless added as a comment). This is not typical of the
> > change tracking systems I am familar with in industry (clear quality and
> > prostar).
> >
> > But I'm all for jumping on the Scarab bandwagon.
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Change tracking and bugzilla limitations
Posted by Martin van den Bemt <ml...@mvdb.net>.
The version field is the version of the software the bug is in,
the milestone field is for saying "we are trying to fixe it at
milestone...."
Heavily used by a lot of projects....
Mvgr,
Martin
On Thu, 2002-08-01 at 22:24, Jeff Dever wrote:
> >
> > > One problem is that there is only one "Version" field. Typically this
> > > would be used for the version that a software fault (aka bug) was "found
> > > in". We are left to use this field to specify which release the
> > > fault/feature is "forcast" to be completed in.
> >
> > It is, you have to use the milestone field to "forecast"..
> >
>
> Not sure I understand your response. Currently I am using the version field
> as forecast (somtimes), which is a hack as any "found in" information is lost
> for software faults (unless added as a comment). This is not typical of the
> change tracking systems I am familar with in industry (clear quality and
> prostar).
>
> But I'm all for jumping on the Scarab bandwagon.
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Change tracking and bugzilla limitations
Posted by Jeff Dever <js...@sympatico.ca>.
>
> > One problem is that there is only one "Version" field. Typically this
> > would be used for the version that a software fault (aka bug) was "found
> > in". We are left to use this field to specify which release the
> > fault/feature is "forcast" to be completed in.
>
> It is, you have to use the milestone field to "forecast"..
>
Not sure I understand your response. Currently I am using the version field
as forecast (somtimes), which is a hack as any "found in" information is lost
for software faults (unless added as a comment). This is not typical of the
change tracking systems I am familar with in industry (clear quality and
prostar).
But I'm all for jumping on the Scarab bandwagon.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Change tracking and bugzilla limitations
Posted by Martin van den Bemt <ml...@mvdb.net>.
On Thu, 2002-08-01 at 16:22, Jeff Dever wrote:
> Goodday,
>
> I'm the new release manager for the commons httpclient subproject. We
> are using Bugzilla to track both software faults and features, which
> bugzilla handles quite well. We are also trying to use bugzilla for
> forcasting in which milestone/release a particular feature should be
> added or a fault fixed. Bugzilla does not handle this quite so well.
>
> One problem is that there is only one "Version" field. Typically this
> would be used for the version that a software fault (aka bug) was "found
> in". We are left to use this field to specify which release the
> fault/feature is "forcast" to be completed in.
It is, you have to use the milestone field to "forecast"..
Mvgr,
Martin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: don't flame me till you read this... reply-to munging
Posted by Peter Donald <pe...@apache.org>.
On Fri, 2 Aug 2002 04:10, Danny Angus wrote:
> This is not really about reply-to munging...
> Except that it has been noticed that where mails already have a Reply-To
> header the listserver is adding a new header and not replacing the existing
> one, which I'd expect it to.
Its a bug ;/
--
Cheers,
Peter Donald
*------------------------------------------------------*
| "Common sense is the collection of prejudices |
| acquired by age 18. " -Albert Einstein |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: don't flame me till you read this... reply-to munging
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Danny Angus" <da...@apache.org> wrote:
> This is not really about reply-to munging...
> Except that it has been noticed that where mails already have a Reply-To
> header the listserver is adding a new header and not replacing the existing
> one, which I'd expect it to.
Bug. Will check
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
don't flame me till you read this... reply-to munging
Posted by Danny Angus <da...@apache.org>.
Hi,
This is not really about reply-to munging...
Except that it has been noticed that where mails already have a Reply-To
header the listserver is adding a new header and not replacing the existing
one, which I'd expect it to.
I don't know whether this is deliberate, buggy, or inadvertant, and frankly
I don't want to spark the whole reply-to debate again, so if its not
undesirable behaviour, please ignore this message.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Change tracking and bugzilla limitations
Posted by Jeff Dever <js...@sympatico.ca>.
I guess I won't bother raising any bugs against bugzilla then ;-)
As the release manager for commons-httpclient, I would love to be an early
adoptor of scarab. Please let me know if there is anything I can do to help in
the "project owner" capacity.
Pier Fumagalli wrote:
> "Jon Scott Stevens" <jo...@latchkey.com> wrote:
>
> > It is fine to use Scarab (I would suggest cvs head or waiting a couple more
> > days for b9). Scarab is self hosting itself already as well...
> >
> > I just don't have the time to install/maintain it though...
>
> Now that I am done with Subversion (got quite acquainted with building it
> weekly), I can take care of it... Also because I can just start ignoring
> BugZilla bugs! :) :) :) :)
>
> Pier
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Change tracking and bugzilla limitations
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Peter Donald" <pe...@apache.org> wrote:
> On Fri, 2 Aug 2002 11:02, Jon Scott Stevens wrote:
>> on 8/1/02 5:46 PM, "Peter Donald" <pe...@apache.org> wrote:
>>> Did Scarab end up completing the bugzilla - to -
>>> scarab script for converting a project/components into scarab form?
>>
>> Not yet...I'm working pretty hard on getting that done.
>
> woohoo!
Once he's done, I'll transfer over all bugs, and then we can do a one-week?
evaluation trial... If it works, great...
Pier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Change tracking and bugzilla limitations
Posted by Peter Donald <pe...@apache.org>.
On Fri, 2 Aug 2002 11:02, Jon Scott Stevens wrote:
> on 8/1/02 5:46 PM, "Peter Donald" <pe...@apache.org> wrote:
> > Did Scarab end up completing the bugzilla - to -
> > scarab script for converting a project/components into scarab form?
>
> Not yet...I'm working pretty hard on getting that done.
woohoo!
--
Cheers,
Peter Donald
--------------------------------
These aren't the droids you're
looking for. Move along.
--------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Change tracking and bugzilla limitations
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 8/1/02 5:46 PM, "Peter Donald" <pe...@apache.org> wrote:
> Did Scarab end up completing the bugzilla - to -
> scarab script for converting a project/components into scarab form?
Not yet...I'm working pretty hard on getting that done.
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Change tracking and bugzilla limitations
Posted by Peter Donald <pe...@apache.org>.
On Fri, 2 Aug 2002 04:31, Pier Fumagalli wrote:
> "Jon Scott Stevens" <jo...@latchkey.com> wrote:
> > It is fine to use Scarab (I would suggest cvs head or waiting a couple
> > more days for b9). Scarab is self hosting itself already as well...
> >
> > I just don't have the time to install/maintain it though...
>
> Now that I am done with Subversion (got quite acquainted with building it
> weekly), I can take care of it... Also because I can just start ignoring
> BugZilla bugs! :) :) :) :)
ooer - that would be kool. Did Scarab end up completing the bugzilla - to -
scarab script for converting a project/components into scarab form? If so it
may be a good idea to start moving projects across to it ?
--
Cheers,
Peter Donald
--------------------------------------------
Beer is proof that God loves us and wants
us to be happy. -- Benjamin Franklin
--------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Change tracking and bugzilla limitations
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Jon Scott Stevens" <jo...@latchkey.com> wrote:
> It is fine to use Scarab (I would suggest cvs head or waiting a couple more
> days for b9). Scarab is self hosting itself already as well...
>
> I just don't have the time to install/maintain it though...
Now that I am done with Subversion (got quite acquainted with building it
weekly), I can take care of it... Also because I can just start ignoring
BugZilla bugs! :) :) :) :)
Pier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Change tracking and bugzilla limitations
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 8/1/02 11:19 AM, "Pier Fumagalli" <pi...@betaversion.org> wrote:
> Jon, what's the status?
It is fine to use Scarab (I would suggest cvs head or waiting a couple more
days for b9). Scarab is self hosting itself already as well...
I just don't have the time to install/maintain it though...
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Change tracking and bugzilla limitations
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Jeff Dever" <js...@sympatico.ca> wrote:
> One problem is that there is only one "Version" field. Typically this
> would be used for the version that a software fault (aka bug) was "found
> in". We are left to use this field to specify which release the
> fault/feature is "forcast" to be completed in.
>
> The other problem is that in a report list, the version column is only 5
> characters. With release names like 2.0 Beta 1, 2.0 Beta 2, the
> resulting list only shows "2.0 B" which is insuficient information. I
> could see no way for a user to change this.
#
# Table structure for table 'versions'
#
CREATE TABLE versions (
value varchar(64) NOT NULL default '',
program varchar(64) NOT NULL default ''
) TYPE=MyISAM;
It's somewhere else. Not in the DB.
> Are we moving to the new Scarab system somtime soon?
ASAP. Jon, what's the status?
> Is there some other configuration of bugzilla that can be
> done to help me manage bugs/features in a change management way?
Nope.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>