headers
Danny Angus | 1 Aug 2002 01:17
Picon
Favicon

RE: Jakarta Newsletter - June 2002

Pier wrote:
>There has never been such an election. I would say: all committers.

in which case :

> [X]I want Rob to be a voting member of the Jakarta community

> [X] I vote to make Rob a committer of "jakarta-site" and related CVS
       repositories.

And at the same time:

>+1 [ ] I want the institution of a new figure of "non committer  voting
       member" giving rights to people involved with the Jakarta community
       at large, but not directly involved with one particular codebase, to
       vote on "general" issues, such as acceptance of a new codebase, or
       PMC election)
> 0 [ ] I don't care about this issue
>-1 [X] I don't want to give voting rights to people non associated with a
       particular code base because ....

-1 because, although I do agree with Pier's sentiments regarding the
involvement of non-coding contributors, and argued his case when this was
last aired, I have thought about it and made a radical U turn.

I believe that non coding contributors, to whom we wish to extend voting
rights, can also reasonably be expected to have write access to
jakarta-site2, making them commiters.

The fact that they may either never use this right directly, or may indeed
(Continue reading)

Permalink | Reply | 0 comments |
headers
Danny Angus | 1 Aug 2002 01:17
Picon
Favicon

RE: [VOTE] Promotion of 'jakarta-site' to project status and additionof Rob Oxspring as committer to same

> 2) ALL WITH JAKARTA-SITE PRIVS :  Proposal - add Rob Oxspring as 
> a member of
> the jakarta-site project
> 
>    [X] +1 
>    [ ] +0
>    [ ] -0 
>    [ ] -1
Permalink | Reply | 0 comments |
headers
Danny Angus | 1 Aug 2002 01:29
Picon
Favicon

RE: [VOTE] Promotion of 'jakarta-site' to project status and additionof Rob Oxspring as committer to same


> Geir Magnusson Jr. wrote:

> > It's entirely reasonable that our website and related materials be a
> > project.  It requires the same care, vision and participation
> as any other
> > project.

I also agree with this, I think that making non-coding contributors
commiters to commons is more of an indefensable fudge than elevating the
web-site to project status.

d.
Permalink | Reply | 15 comments |
headers
Ceki Gülcü | 1 Aug 2002 03:22
Picon
Gravatar

Short essay on commons-logging


FYI:

http://www.qos.ch/logging/thinkAgain.html

This is just to let you know that the link exists. I am not interested
to start yet another discussion.

--
Ceki
Permalink | Reply | 0 comments |
headers
Jeff Dever | 1 Aug 2002 16:22
Picon
Favicon

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?
Permalink | Reply | 23 comments |
headers
Danny Angus | 1 Aug 2002 20:10
Picon
Favicon

don't flame me till you read this... reply-to munging

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.
Permalink | Reply | 2 comments |
headers
Pier Fumagalli | 1 Aug 2002 20:11

Re: don't flame me till you read this... reply-to munging

"Danny Angus" <danny <at> 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
Permalink | Reply | 0 comments |
headers
Pier Fumagalli | 1 Aug 2002 20:19

Re: Change tracking and bugzilla limitations

"Jeff Dever" <jsdever <at> 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?
(Continue reading)

Permalink | Reply | 7 comments |
headers
Jon Scott Stevens | 1 Aug 2002 20:21
Gravatar

Re: Change tracking and bugzilla limitations

on 8/1/02 11:19 AM, "Pier Fumagalli" <pier <at> 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
Permalink | Reply | 6 comments |
headers
Pier Fumagalli | 1 Aug 2002 20:31

Re: Change tracking and bugzilla limitations

"Jon Scott Stevens" <jon <at> 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
Permalink | Reply | 5 comments |

Gmane