On Mon, 23 Jun 2008, Kevin Jackson <[EMAIL PROTECTED]> wrote:
> No worries, I didn't take it as a negative comment, but I'm aware
> that I haven't been able to work on ant as much as I'd like this
> year ;)
I guess this is true for many of us (and in my case I'd replace this
year with "the past t
> If you feel you'd need a new beta, than I'd vote against including the
> patch. I'd be +0 for including it without another beta.
>
>> (PS sorry about being slow getting 1.7.1 out,
>
> Just in case I've been misunderstood. When I said that in retrospect
> we should have released 1.7.1 earlier I
On Mon, 23 Jun 2008, Kevin Jackson <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Since there seems to be a bit of a debate on the acceptance of late
> patches in the beta cycle, we should probably have a vote
> ---
> Do you think that a patch which *seems* like a trivial fix and has
> been accepted in
Hi all,
Since there seems to be a bit of a debate on the acceptance of late
patches in the beta cycle, we should probably have a vote
---
Do you think that a patch which *seems* like a trivial fix and has
been accepted into SVN HEAD should be backported/merged into the
current 'about to be release
On Fri, 20 Jun 2008, Guntis Ozols <[EMAIL PROTECTED]> wrote:
> Anyway, if the code is too fragile to survive even
> the slightest change, can docs be safely fixed instead?
>
> I am writing this because I stumbled over
> 41201 "[jar-task] wrong name for services folder" recently.
> The latest and
>>> I fixed https://issues.apache.org/bugzilla/show_bug.cgi?id=45190 with
>>> a rather trivial patch
>>> http://svn.apache.org/viewvc?view=rev&revision=668624 and now the
>>> reporter asks whether this could go into 1.7.1.
>
> I'm more ruthless here, I'd stick it out and say 1.7.2. Otherwise more
>
I understand the sentiment, but the implication is that our releases are
always identical to our betas. AFAIR we have never had that policy before.
The benefit to doing that is that we know we haven't added code that
hasn't been through an adequate release cycle, no matter how trivial a
change
On Wed, 18 Jun 2008, Steve Loughran <[EMAIL PROTECTED]> wrote:
> I'm more ruthless here, I'd stick it out and say 1.7.2. Otherwise more
> bugs come in and get patched in late.
This sort of implies there would be a 1.7.2 and that we'd ge to
shorter release cycles.
I can live with either way.
Ste
Kevin Jackson wrote:
Hi Stefan,
I fixed https://issues.apache.org/bugzilla/show_bug.cgi?id=45190 with
a rather trivial patch
http://svn.apache.org/viewvc?view=rev&revision=668624 and now the
reporter asks whether this could go into 1.7.1.
While I understand that he needs the bug fixed, I also
On Tue, 17 Jun 2008, Kevin Jackson <[EMAIL PROTECTED]> wrote:
> Hi Stefan,
>
>> I fixed https://issues.apache.org/bugzilla/show_bug.cgi?id=45190
>> with a rather trivial patch
>> http://svn.apache.org/viewvc?view=rev&revision=668624 and now the
>> reporter asks whether this could go into 1.7.1.
>
Hi Stefan,
> I fixed https://issues.apache.org/bugzilla/show_bug.cgi?id=45190 with
> a rather trivial patch
> http://svn.apache.org/viewvc?view=rev&revision=668624 and now the
> reporter asks whether this could go into 1.7.1.
>
> While I understand that he needs the bug fixed, I also wouldn't want
Hi all,
I fixed https://issues.apache.org/bugzilla/show_bug.cgi?id=45190 with
a rather trivial patch
http://svn.apache.org/viewvc?view=rev&revision=668624 and now the
reporter asks whether this could go into 1.7.1.
While I understand that he needs the bug fixed, I also wouldn't want
to cause any
12 matches
Mail list logo