You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Justin Erenkrantz <ju...@erenkrantz.com> on 2003/05/23 17:10:11 UTC
Sheparding patches was Re: Volunteering to be RM
--On Friday, May 23, 2003 7:38 PM +1000 Stas Bekman <st...@stason.org> wrote:
> Sander, you have asked if there are any objections. I've posted the
> information about an existing problem. Nobody has followed up on this
> report, though everybody seems to be happy to proceed with a new release,
> rolling a new tag. Can somebody please explain why? Is it because I haven't
> logged this issue into a STATUS file, haven't submitted it to the bug
> database, or just because I don't have enough httpd-dev karma to make any
> difference?
In this particular case, my attitude is that since you have commit access, the
responsibility is upon you to produce patches that fix the problem and
shepherd them through the release process. Please don't expect anyone else to
fix your problems.
I've suggested what approach I think you should take and I pointed out places
where your original patch was incorrect/inefficient, but you haven't come back
with a patch that implements it. That should have been the next step in the
process. After the patch gets some positive feedback on the list, you could
then have committed it to 2.1. Then, you could have proposed it to be
backported to 2.0.
And, as Sander has pointed out, this isn't a regression from prior releases.
Therefore, we won't necessarily hold up a release for it. -- justin
Re: Sheparding patches was Re: Volunteering to be RM
Posted by Stas Bekman <st...@stason.org>.
Jeff Trawick wrote:
> Stas Bekman wrote:
>
>> Justin Erenkrantz wrote:
>>
>>> And, as Sander has pointed out, this isn't a regression from prior
>>> releases. Therefore, we won't necessarily hold up a release for it. --
>>
>>
>>
>> If something wasn't known to be buggy in prior releases and gets known
>> as buggy later on, it can't be even considered to be a showstopper?
>
>
> Ordinarily, no. The philosophy of those willing to do the work to
> tag/test/roll/release as been that as long as it is expected to be
> better than the previous release, with no apparent regressions, it is
> ready to go. An exception would be if there is something to indicate
> that a significant number of users would suddenly begin to suffer the
> problem. Consider the chunked encoding vulnerability as an example of
> this; it was obviously going to become an impact to many sites when the
> vulnerability was disclosed, even though the problem had been around for
> eons.
>
> The bright side is that we don't have to wait months and months for
> another GA release. When a reasonable set of fixes becomes available,
> the willingness to invest in the required effort to
> tag/test/roll/release will follow.
>
> If we aren't conservative about what is considered a showstopper, there
> will be more time between releases and users will have to wait longer to
> get relief for problems they are seeing.
Thanks for the explanation, Jeff.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Sheparding patches was Re: Volunteering to be RM
Posted by Jeff Trawick <tr...@attglobal.net>.
Stas Bekman wrote:
> Justin Erenkrantz wrote:
>> And, as Sander has pointed out, this isn't a regression from prior
>> releases. Therefore, we won't necessarily hold up a release for it. --
>
>
> If something wasn't known to be buggy in prior releases and gets known
> as buggy later on, it can't be even considered to be a showstopper?
Ordinarily, no. The philosophy of those willing to do the work to
tag/test/roll/release as been that as long as it is expected to be
better than the previous release, with no apparent regressions, it is
ready to go. An exception would be if there is something to indicate
that a significant number of users would suddenly begin to suffer the
problem. Consider the chunked encoding vulnerability as an example of
this; it was obviously going to become an impact to many sites when the
vulnerability was disclosed, even though the problem had been around for
eons.
The bright side is that we don't have to wait months and months for
another GA release. When a reasonable set of fixes becomes available,
the willingness to invest in the required effort to
tag/test/roll/release will follow.
If we aren't conservative about what is considered a showstopper, there
will be more time between releases and users will have to wait longer to
get relief for problems they are seeing.
Re: Sheparding patches was Re: Volunteering to be RM
Posted by Stas Bekman <st...@stason.org>.
Justin Erenkrantz wrote:
> --On Friday, May 23, 2003 7:38 PM +1000 Stas Bekman <st...@stason.org>
> wrote:
>
>> Sander, you have asked if there are any objections. I've posted the
>> information about an existing problem. Nobody has followed up on this
>> report, though everybody seems to be happy to proceed with a new release,
>> rolling a new tag. Can somebody please explain why? Is it because I
>> haven't
>> logged this issue into a STATUS file, haven't submitted it to the bug
>> database, or just because I don't have enough httpd-dev karma to make any
>> difference?
>
>
> In this particular case, my attitude is that since you have commit
> access, the responsibility is upon you to produce patches that fix the
> problem and shepherd them through the release process. Please don't
> expect anyone else to fix your problems.
Not exactly *my* problem, I'm rewriting all the code removing its usage.
However other people want to use it.
> I've suggested what approach I think you should take and I pointed out
> places where your original patch was incorrect/inefficient, but you
> haven't come back with a patch that implements it. That should have
> been the next step in the process. After the patch gets some positive
> feedback on the list, you could then have committed it to 2.1. Then,
> you could have proposed it to be backported to 2.0.
Yes, the reason I haven't taken this further was your suggestion to deprecate
and remove that API. I was expecting that there will be a resolution on this
issue, however the thread has died out. What's the point of fixing something
if it's going to be removed.
> And, as Sander has pointed out, this isn't a regression from prior
> releases. Therefore, we won't necessarily hold up a release for it. --
If something wasn't known to be buggy in prior releases and gets known as
buggy later on, it can't be even considered to be a showstopper?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com