Hi all,
there’s still some confusion on re: the process of back ports. Here’s a quick
reminder:
1) Backports should (obviously) be landed on Master branch first.
2) You are responsible for suggesting backports, either by directly adding the
“Projects” tags on the Github PR, or comment on the
> the person proposing a Backport should be willing and expected to make
the PR if asked
I proposed a backport but didn't make a PR for 7.1.x because I wasn't asked
to make it. Should I make the PR even if I wasn't asked to do so, or should
I wait for the request from RM?
Masakazu
On Sat, Sep 1
+1
-Bryan
> On Aug 29, 2018, at 4:47 PM, Leif Hedstrom wrote:
>
> Hi all,
>
> since we now have two of the “new” style LTS release branches, 7.1.x and
> 8.0.x, it gets more problematic to deal with backport requests. The issue
> comes down to the fact that a PR can only have one Milestone. M
Hi all,
since we now have two of the “new” style LTS release branches, 7.1.x and 8.0.x,
it gets more problematic to deal with backport requests. The issue comes down
to the fact that a PR can only have one Milestone. My suggestion is as follow:
1. The latest LTS branch has priority on d
file a Jira, target (right now) Fix version is 7.0.0. You create a
Github PR, and once committed, you close the Jira.
2) If you think this is a critical fix that should be considered for back port,
“Edit” the Jira, and add the appropriate versions for Backports. For example,
6.2.0 which is our
Hi all,
if you are contributing or making a commit on master, that you feel really
ought to be back ported to a stable release branch (or branches), please
remember to mark the Jira with the back port version. There is a field for this
when you “Edit” the issue.
Candidates for back porting inc
I plan on rolling a 4.2.3 release here in the next 24 hours or so. I wanted
to make sure there was nothing else anyone wanted to see backported before
I did that. Here is the current list of backports for 4.2.3:
https://issues.apache.org/jira/browse/TS-3304?jql=project%20%3D%20TS%20AND%20
We're still learning the ropes here, but I'd like to suggest an addition to the
new workflow:
When you fix a bug, please mark the bug if it should be back ported as well.
This should be for truly critical bugs only, such as security problems or
frequent crashers.
This makes it easier for the
+1
- Original Message -
> So everyone is on board for this? Since we've already begun the
> release
> process for 3.0.5, I think it might be best to start the new process
> with
> 3.0.6 and 3.1.5, thoughts?
>
> Brian
>
>
> On Fri, Apr 27, 2012 at 8:30 AM, James Peach
> wrote:
>
> > On Apr
So everyone is on board for this? Since we've already begun the release
process for 3.0.5, I think it might be best to start the new process with
3.0.6 and 3.1.5, thoughts?
Brian
On Fri, Apr 27, 2012 at 8:30 AM, James Peach wrote:
> On Apr 27, 2012, at 6:34 AM, Igor Galić wrote:
>
> >
> >
> >
On 4/27/12 7:34 AM, Igor Galić wrote:
- Original Message -
Hi all,
James suggested a while ago that we change how we deal with
backported bugs.
I agree with him that our system of closing, reopening, reassigning
etc. is
not only complicated, but difficult to follow.
His suggestion was
On Apr 27, 2012, at 6:34 AM, Igor Galić wrote:
>
>
> - Original Message -
>> Hi all,
>>
>> James suggested a while ago that we change how we deal with
>> backported bugs.
>> I agree with him that our system of closing, reopening, reassigning
>> etc. is
>> not only complicated, but diffi
- Original Message -
> Hi all,
>
> James suggested a while ago that we change how we deal with
> backported bugs.
> I agree with him that our system of closing, reopening, reassigning
> etc. is
> not only complicated, but difficult to follow.
>
> His suggestion was simply to clone a bug t
tistics would not change in any
> > way.
> >
> > What do you guys think? I'm personally +1 on this idea.
>
> +1 from me ... I find it quite confusing when fixe bugs get re-opened for
> backports
>
> J
backport(s).
>
> The one objection I've heard is that this could duplicate the number of bugs
> that we have, but the per release statistics would not change in any way.
>
> What do you guys think? I'm personally +1 on this idea.
+1 from me ... I find it quite confusing when fixe bugs get re-opened for
backports
J
Hi all,
James suggested a while ago that we change how we deal with backported bugs.
I agree with him that our system of closing, reopening, reassigning etc. is
not only complicated, but difficult to follow.
His suggestion was simply to clone a bug that has been approved for
backport, and ma
16 matches
Mail list logo
