You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Jon Stevens <jo...@latchkey.com> on 2001/01/18 01:28:42 UTC
Re: PHP Security Advisory - Apache Module bugs
on 1/17/01 4:10 PM, "Hans Bergsten" <ha...@gefionsoftware.com> wrote:
> Jon Stevens wrote:
>>
>> Ok, the interesting point here is the next to last line of this
>> message...PHP has a "PHP Quality Assurance Team"...maybe we should form one
>> for the Tomcat project as a requirement...
>
> Is that a team of people hired for QA? I'm not sure we need to
> formalize a "QA team", and I have a feeling it's hard to implement
> in a volunteer organization. But if you have ideas about how it
> could be made to work, I'm all ears.
>
> Hans
Started on the PMC, now taken to the general list as a matter of recourse
from the PMC meeting...
I guess my point being is that we can ask for volunteers who will form this
Tomcat QA team. People are always asking how they can help out...lets find
ways for them to do so that is above and beyond just doing code or
documentation.
These people will be responsible for making sure that the software passes
all of the watchdog tests and passes Sam's nightly tinderbox system and
things like that. I don't think that this is a paid position, it would be a
group of people who are delegated and volunteer to be in this "Team" of
people. If no one volunteers, then I guess it won't work and the community
potentially suffers as a result.
thanks,
-jon
Re: PHP Security Advisory - Apache Module bugs
Posted by Jon Stevens <jo...@latchkey.com>.
on 1/19/01 6:57 AM, "Conor MacNeill" <co...@cortexebusiness.com.au> wrote:
> Can you expand on what are the "issues surrounding the Ant-Dev list" ? I'm
> not sure what you are referring to here.
>
> Cheers
> Conor
All of the flames related to 2.0.
-jon
Re: PHP Security Advisory - Apache Module bugs
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
Jon,
From: "Jon Stevens" <jo...@latchkey.com>
>
> I think that we should be more cautious towards who is allowed become
part
> of the team. Example criteria in my mind includes showing a willingness
to
> develop and an understanding and respect of the ASF infrastructure and
> responsibilities. So far, we haven't been following the second of those
> principles at all. Example, all the Paulo email on the Tomcat-Dev list as
> well as a lot of the issues surrounding the Ant-Dev list.
>
Can you expand on what are the "issues surrounding the Ant-Dev list" ? I'm
not sure what you are referring to here.
Cheers
Conor
Re: PHP Security Advisory - Apache Module bugs
Posted by Kief Morris <ki...@bitbull.com>.
Jon Stevens typed the following on 10:47 AM 1/18/2001 -0800
>on 1/18/01 4:07 AM, "Glenn Nielsen" <gl...@voyager.apg.more.net> wrote:
>> You may need more than three members if you want the set of QA/QC members
>> to cover the possible set of OS/JVM/usage combinations.
>
>They are perfectly allowed to delegate responsibility. The goal here is to
>define a volunteer team which has a well defined responsibility to the
>project.
Good point, these people shouldn't be expected to handle all QA/QC (what is
the definition of each?) themselves, any more than committers handle all of the
coding and bugfixing themselves. They just need to make sure everything gets
tested by someone.
Kief
Re: PHP Security Advisory - Apache Module bugs
Posted by Jon Stevens <jo...@latchkey.com>.
on 1/18/01 4:07 AM, "Glenn Nielsen" <gl...@voyager.apg.more.net> wrote:
> Is this really QA (Quality Assurance) or QC (Quality Control) ?
> To me the functions and responsibilities listed fall into QC rather than QA.
> Sometimes QA and QC get used interchangeably, but they really are
> two different things.
Ok, then lets encompass it to be both QA and QC combined. What modifications
would you make to the job req in that case?
> You may need more than three members if you want the set of QA/QC members
> to cover the possible set of OS/JVM/usage combinations.
They are perfectly allowed to delegate responsibility. The goal here is to
define a volunteer team which has a well defined responsibility to the
project.
For example, if you are in Florida and you volunteer to count ballots, you
work with a team of people and you have a well defined set or
responsibilities. :-)
-jon
--
Honk if you love peace and quiet.
Re: PHP Security Advisory - Apache Module bugs
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
Hans Bergsten wrote:
>
> Jon Stevens wrote:
> >
> > on 1/17/01 8:44 PM, "Hans Bergsten" <ha...@gefionsoftware.com> wrote:
> > [...]
> > > Do we have to limit the size of the team. I think it would be
> > > a good idea to define QA Member as a new role, between User and
> > > Developer in terms of active involvement and authority. See more
> > > below.
> >
Is this really QA (Quality Assurance) or QC (Quality Control) ?
To me the functions and responsibilities listed fall into QC rather than QA.
Sometimes QA and QC get used interchangeably, but they really are
two different things.
> > Yes. I think it is important to limit the size of the team. At this point,
> > our experiences with giving everyone and their brother commit access has
> > actually seemed to prove to not be beneficial towards overall project health
> > and has simply proven to cause problems.
> > [...]
>
> I can buy that. We can put in the role description that at any point in
> time, the number of QA Members should not be more than 3 (or whatever
> number seems right), with the explanation you just gave; more focused
> and more sense of responsibility.
>
You may need more than three members if you want the set of QA/QC members
to cover the possible set of OS/JVM/usage combinations.
Regards,
Glenn
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
Re: PHP Security Advisory - Apache Module bugs
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
"Craig R. McClanahan" wrote:
>
> In general, I agree with the proposal for a QA team. A couple of detailed
> comments follow.
>
> Hans Bergsten wrote:
>
> > Jon Stevens wrote:
> > >
> > > on 1/17/01 8:44 PM, "Hans Bergsten" <ha...@gefionsoftware.com> wrote:
> > > [...]
> > > > Do we have to limit the size of the team. I think it would be
> > > > a good idea to define QA Member as a new role, between User and
> > > > Developer in terms of active involvement and authority. See more
> > > > below.
> > >
> > > Yes. I think it is important to limit the size of the team. At this point,
> > > our experiences with giving everyone and their brother commit access has
> > > actually seemed to prove to not be beneficial towards overall project health
> > > and has simply proven to cause problems.
> > > [...]
> >
> > I can buy that. We can put in the role description that at any point in
> > time, the number of QA Members should not be more than 3 (or whatever
> > number seems right), with the explanation you just gave; more focused
> > and more sense of responsibility.
> >
>
> Is the primary issue team size, or is it focus? As the amount of functionality
> increases, it gets progressively harder to understand broad areas well enough to
> test them. I would also like to see at least some portion of this team focused
> specifically on isolating security problems as well.
Could we go with something like this:
In order to keep the important task of QA focused, the number of
people in this role need to be limited. It's impossible to specify
a specific number, since it depends on the circumstances at the
time and the specific subproject. For instance, if more than one
version of the product is in active use at the same time, each version
may require its own team of roughly the same size. Over time, one
version will be the one used by most and use of the other version
will drop, and therefore require a smaller team. To control the size
of the QA team, any Committer or QA Member can veto a vote for a new
QA Member on the grounds that adding another person would result in
lost focus.
> >
> > > > I don't think it's fair to require anyone in this type of organization
> > > > to be responsible for finding their replacement. Besides, it would be
> > > > hard to enforce.
> > >
> > > However, I'm trying to establish stronger a chain of responsibility here as
> > > I think that that is lacking in the organization. In other words, if you
> > > sign up to be part of a team, then you are committing yourself to being part
> > > of that team. If you can't do your duties, then it should be your
> > > responsibility to find a replacement.
> >
> > I agree with the goal, but I think it's better to say something like this:
> >
> > If a QA Member realizes that he/she can not perform the duties,
> > he/she must announce this (to the Users list? to teh General list?) so
> > that a new QA Member can be nominated and elected.
> >
> > That is a more fair distribution of responsibilities between the
> > individual and the community IMHO.
> >
>
> If it's a Tomcat-specific QA team, wouldn't TOMCAT-DEV be the right place? I
> would expect the QA folks would be hanging out there, because lots of bugs get
> reported in emails to the -DEV list.
I agree; the Development list for the subproject is probably the best way
for all votes and notices regarding QA Members.
> > [...]
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: PHP Security Advisory - Apache Module bugs
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
In general, I agree with the proposal for a QA team. A couple of detailed
comments follow.
Hans Bergsten wrote:
> Jon Stevens wrote:
> >
> > on 1/17/01 8:44 PM, "Hans Bergsten" <ha...@gefionsoftware.com> wrote:
> > [...]
> > > Do we have to limit the size of the team. I think it would be
> > > a good idea to define QA Member as a new role, between User and
> > > Developer in terms of active involvement and authority. See more
> > > below.
> >
> > Yes. I think it is important to limit the size of the team. At this point,
> > our experiences with giving everyone and their brother commit access has
> > actually seemed to prove to not be beneficial towards overall project health
> > and has simply proven to cause problems.
> > [...]
>
> I can buy that. We can put in the role description that at any point in
> time, the number of QA Members should not be more than 3 (or whatever
> number seems right), with the explanation you just gave; more focused
> and more sense of responsibility.
>
Is the primary issue team size, or is it focus? As the amount of functionality
increases, it gets progressively harder to understand broad areas well enough to
test them. I would also like to see at least some portion of this team focused
specifically on isolating security problems as well.
>
> > > I don't think it's fair to require anyone in this type of organization
> > > to be responsible for finding their replacement. Besides, it would be
> > > hard to enforce.
> >
> > However, I'm trying to establish stronger a chain of responsibility here as
> > I think that that is lacking in the organization. In other words, if you
> > sign up to be part of a team, then you are committing yourself to being part
> > of that team. If you can't do your duties, then it should be your
> > responsibility to find a replacement.
>
> I agree with the goal, but I think it's better to say something like this:
>
> If a QA Member realizes that he/she can not perform the duties,
> he/she must announce this (to the Users list? to teh General list?) so
> that a new QA Member can be nominated and elected.
>
> That is a more fair distribution of responsibilities between the
> individual and the community IMHO.
>
If it's a Tomcat-specific QA team, wouldn't TOMCAT-DEV be the right place? I
would expect the QA folks would be hanging out there, because lots of bugs get
reported in emails to the -DEV list.
>
> > > At times, QA Members may go inactive for a variety of reasons. A
> > > QA Member that has been inactive for 6 months or more may lose his or
> > > her status as a QA Member.
> >
> > I think that 6 months is WAY to long for that. Especially if we go with a
> > smaller group size. I would say 2 months and/or the time between a release
> > of the software. These people have to be around for the time that there are
> > releases.
>
> I agree, I just copy/pasted from the Committer process. 2 months sounds
> okay.
>
Two months is OK with me.
>
> > [...]
>
> Hans
>
Craig McClanahan
Re: PHP Security Advisory - Apache Module bugs
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Jon Stevens wrote:
>
> on 1/17/01 8:44 PM, "Hans Bergsten" <ha...@gefionsoftware.com> wrote:
> [...]
> > Do we have to limit the size of the team. I think it would be
> > a good idea to define QA Member as a new role, between User and
> > Developer in terms of active involvement and authority. See more
> > below.
>
> Yes. I think it is important to limit the size of the team. At this point,
> our experiences with giving everyone and their brother commit access has
> actually seemed to prove to not be beneficial towards overall project health
> and has simply proven to cause problems.
> [...]
I can buy that. We can put in the role description that at any point in
time, the number of QA Members should not be more than 3 (or whatever
number seems right), with the explanation you just gave; more focused
and more sense of responsibility.
> > I don't think it's fair to require anyone in this type of organization
> > to be responsible for finding their replacement. Besides, it would be
> > hard to enforce.
>
> However, I'm trying to establish stronger a chain of responsibility here as
> I think that that is lacking in the organization. In other words, if you
> sign up to be part of a team, then you are committing yourself to being part
> of that team. If you can't do your duties, then it should be your
> responsibility to find a replacement.
I agree with the goal, but I think it's better to say something like this:
If a QA Member realizes that he/she can not perform the duties,
he/she must announce this (to the Users list? to teh General list?) so
that a new QA Member can be nominated and elected.
That is a more fair distribution of responsibilities between the
individual and the community IMHO.
> > At times, QA Members may go inactive for a variety of reasons. A
> > QA Member that has been inactive for 6 months or more may lose his or
> > her status as a QA Member.
>
> I think that 6 months is WAY to long for that. Especially if we go with a
> smaller group size. I would say 2 months and/or the time between a release
> of the software. These people have to be around for the time that there are
> releases.
I agree, I just copy/pasted from the Committer process. 2 months sounds
okay.
> [...]
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: PHP Security Advisory - Apache Module bugs
Posted by James Duncan Davidson <du...@x180.net>.
On 1/17/01 9:08 PM, "Jon Stevens" <jo...@latchkey.com> wrote:
> Yes. I think it is important to limit the size of the team. At this point,
> our experiences with giving everyone and their brother commit access has
> actually seemed to prove to not be beneficial towards overall project health
> and has simply proven to cause problems.
Totally agreed.
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: PHP Security Advisory - Apache Module bugs
Posted by Jon Stevens <jo...@latchkey.com>.
on 1/17/01 8:44 PM, "Hans Bergsten" <ha...@gefionsoftware.com> wrote:
> Jon Stevens wrote:
>> [...]
>> Here is a stab at a Job description:
>>
>> Wanted: Tomcat QA Team
>>
>> This team will be composed of a group of 2-3 individuals who are responsible
>> for tracking the progress of the Tomcat development cycle.
>
> Do we have to limit the size of the team. I think it would be
> a good idea to define QA Member as a new role, between User and
> Developer in terms of active involvement and authority. See more
> below.
Yes. I think it is important to limit the size of the team. At this point,
our experiences with giving everyone and their brother commit access has
actually seemed to prove to not be beneficial towards overall project health
and has simply proven to cause problems.
I think that we should be more cautious towards who is allowed become part
of the team. Example criteria in my mind includes showing a willingness to
develop and an understanding and respect of the ASF infrastructure and
responsibilities. So far, we haven't been following the second of those
principles at all. Example, all the Paulo email on the Tomcat-Dev list as
well as a lot of the issues surrounding the Ant-Dev list.
By limiting the team size that will help them focus on the task at hand.
> I don't think it's fair to require anyone in this type of organization
> to be responsible for finding their replacement. Besides, it would be
> hard to enforce.
However, I'm trying to establish stronger a chain of responsibility here as
I think that that is lacking in the organization. In other words, if you
sign up to be part of a team, then you are committing yourself to being part
of that team. If you can't do your duties, then it should be your
responsibility to find a replacement.
> In order for a User to become a QA Member, another QA Member or
> Committer can nominate that User or the User can ask for it.
> Typically, a User that is actively reporting bugs and answering
> user questions on the Users mailing list is a candidate for
> nomination. Once a QA Member is nominated, all of the QA Members
> and Committers for a subproject will vote. If there are at least 3
> positive votes and no negative votes, the User is converted into a
> QA Member and given write access to the bug report system for that
> subproject.
+1
> At times, QA Members may go inactive for a variety of reasons. A
> QA Member that has been inactive for 6 months or more may lose his or
> her status as a QA Member.
I think that 6 months is WAY to long for that. Especially if we go with a
smaller group size. I would say 2 months and/or the time between a release
of the software. These people have to be around for the time that there are
releases.
> To seed the role, we can just ask for volunteers.
Correct.
>> The QA team is responsible for the
>> following things:
>>
>> x Bugs. Opening and closing.
>> x Watching the Users and Developers mailing lists looking for things to
>> report into the bug database. Example, if a patch is sent to the mailing
>> list, this should be reported as a bug and then assigned to the lead
>> developer on the project.
>> x Testing of alpha, beta and released code.
>> x Helping with QA on releases.
>
> Is this different than the previous points combined?
Nope. Sounds good.
>> x Helping create testing suites (optional)
>> x Helping answer user questions (optional)
>> x Helping document FAQ items (optional)
>> x Helping respond to security related items (optional)
>
> I'm not so sure the last one is a good example. Security related
> stuff usually requires pretty deep knowledge of the inner workings
> of the product, and/or the specifications the implemented by the
> product.
Again, optional. But remember where this whole discussion originated. It
started because a PHP QA team member posted to bugtraq. Therefore, I do
think it is important.
> I think it's a good idea to leave most of these things optional.
> The main goal is to get help with testing and bug reporting, and
> I believe we may scare people off if we make the task too
> daunting.
Right. That is why I made them optional.
thanks,
-jon
Re: PHP Security Advisory - Apache Module bugs
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Jon Stevens wrote:
> [...]
> Here is a stab at a Job description:
>
> Wanted: Tomcat QA Team
>
> This team will be composed of a group of 2-3 individuals who are responsible
> for tracking the progress of the Tomcat development cycle.
Do we have to limit the size of the team. I think it would be
a good idea to define QA Member as a new role, between User and
Developer in terms of active involvement and authority. See more
below.
> These people will
> be given write access to the bug database in order to not only submit, but
> also close bugs. People in this role will be required to actively maintain
> their duties or find a replacement.
I don't think it's fair to require anyone in this type of organization
to be responsible for finding their replacement. Besides, it would be
hard to enforce.
> Members of the QA team must have prior
> knowledge of working with Tomcat.
We need a process for becoming a QA Member, the same as we have for
a Committer. My suggestion is something like this (modeled after
the Committer process):
In order for a User to become a QA Member, another QA Member or
Committer can nominate that User or the User can ask for it.
Typically, a User that is actively reporting bugs and answering
user questions on the Users mailing list is a candidate for
nomination. Once a QA Member is nominated, all of the QA Members
and Committers for a subproject will vote. If there are at least 3
positive votes and no negative votes, the User is converted into a
QA Member and given write access to the bug report system for that
subproject.
At times, QA Members may go inactive for a variety of reasons. A
QA Member that has been inactive for 6 months or more may lose his or
her status as a QA Member.
To seed the role, we can just ask for volunteers.
> The QA team is responsible for the
> following things:
>
> x Bugs. Opening and closing.
> x Watching the Users and Developers mailing lists looking for things to
> report into the bug database. Example, if a patch is sent to the mailing
> list, this should be reported as a bug and then assigned to the lead
> developer on the project.
> x Testing of alpha, beta and released code.
> x Helping with QA on releases.
Is this different than the previous points combined?
> x Helping create testing suites (optional)
> x Helping answer user questions (optional)
> x Helping document FAQ items (optional)
> x Helping respond to security related items (optional)
I'm not so sure the last one is a good example. Security related
stuff usually requires pretty deep knowledge of the inner workings
of the product, and/or the specifications the implemented by the
product.
I think it's a good idea to leave most of these things optional.
The main goal is to get help with testing and bug reporting, and
I believe we may scare people off if we make the task too
daunting.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: PHP Security Advisory - Apache Module bugs
Posted by Jon Stevens <jo...@latchkey.com>.
on 1/17/01 4:51 PM, "Hans Bergsten" <ha...@gefionsoftware.com> wrote:
> Okay, it may be worth a shot. If so, I guess we could ask for volunteers here
> and on the users list first of all. If there's enough interest, we should
> define the QA role on the web site, along with some guidelines for how it
> should work in practice (can be worked out on this list). For instance, a QA
> person should probably have write access to the bug database so they can close
> bug reports when they are solved. There may be more things like this needed.
I agree 100%.
Here is a stab at a Job description:
Wanted: Tomcat QA Team
This team will be composed of a group of 2-3 individuals who are responsible
for tracking the progress of the Tomcat development cycle. These people will
be given write access to the bug database in order to not only submit, but
also close bugs. People in this role will be required to actively maintain
their duties or find a replacement. Members of the QA team must have prior
knowledge of working with Tomcat. The QA team is responsible for the
following things:
x Bugs. Opening and closing.
x Watching the Users and Developers mailing lists looking for things to
report into the bug database. Example, if a patch is sent to the mailing
list, this should be reported as a bug and then assigned to the lead
developer on the project.
x Testing of alpha, beta and released code.
x Helping with QA on releases.
x Helping create testing suites (optional)
x Helping answer user questions (optional)
x Helping document FAQ items (optional)
x Helping respond to security related items (optional)
thanks,
-jon
--
Honk if you love peace and quiet.
Re: PHP Security Advisory - Apache Module bugs
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Jon Stevens wrote:
>
> on 1/17/01 4:10 PM, "Hans Bergsten" <ha...@gefionsoftware.com> wrote:
>
> > Jon Stevens wrote:
> >>
> >> Ok, the interesting point here is the next to last line of this
> >> message...PHP has a "PHP Quality Assurance Team"...maybe we should form one
> >> for the Tomcat project as a requirement...
> >
> > Is that a team of people hired for QA? I'm not sure we need to
> > formalize a "QA team", and I have a feeling it's hard to implement
> > in a volunteer organization. But if you have ideas about how it
> > could be made to work, I'm all ears.
> >
> > Hans
>
> Started on the PMC, now taken to the general list as a matter of recourse
> from the PMC meeting...
>
> I guess my point being is that we can ask for volunteers who will form this
> Tomcat QA team. People are always asking how they can help out...lets find
> ways for them to do so that is above and beyond just doing code or
> documentation.
>
> These people will be responsible for making sure that the software passes
> all of the watchdog tests and passes Sam's nightly tinderbox system and
> things like that. I don't think that this is a paid position, it would be a
> group of people who are delegated and volunteer to be in this "Team" of
> people. If no one volunteers, then I guess it won't work and the community
> potentially suffers as a result.
Okay, it may be worth a shot. If so, I guess we could ask for volunteers
here and on the users list first of all. If there's enough interest, we
should define the QA role on the web site, along with some guidelines
for
how it should work in practice (can be worked out on this list). For
instance,
a QA person should probably have write access to the bug database so
they
can close bug reports when they are solved. There may be more things
like
this needed.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com