+1
On Wed 1 May, 2019, 1:13 AM Sijie Guo, wrote:
> Agreed. We should seriously consider introducing a process for managing
> this minor release.
>
> Also I am re-proposing using the approach we used in bookkeeper to have a
> merge script to merge and cherry-pick the changes.
> The script that bo
Agreed. We should seriously consider introducing a process for managing
this minor release.
Also I am re-proposing using the approach we used in bookkeeper to have a
merge script to merge and cherry-pick the changes.
The script that bookkeeper uses comes from Spark and the same approach has
been a
Hi all,
Considering that we are facing issues in minor releases *ex:*
https://github.com/apache/pulsar/issues/4095
https://github.com/apache/pulsar/pull/4181 It would be great if we
introduce a process to keep track of commits to be merged into minor
versions . On top it releases mana
Hi Yuva,
I don't think we have adopted this process. Matteo is driving 2.3.1
release.
#3840 is already marked for 2.3.1.
I also comment in #3956 and mark it for 2.3.1.
- Sijie
On Mon, Apr 1, 2019 at 12:49 AM Yuva raj wrote:
> Hi Sijie,
> Are we going to do this for 2.3.1 release ? We need 2
Hi Sijie,
Are we going to do this for 2.3.1 release ? We need 2 of our pull request
#3956 and #3840 to be merged in 2.3.1. If required we can go ahead and
request to add cherry-pick/2.3.1
On Thu, 21 Feb 2019 at 23:35, Sijie Guo wrote:
> On Thu, Feb 21, 2019 at 8:03 PM Ivan Kelly wrote:
>
> >
On Thu, Feb 21, 2019 at 8:03 PM Ivan Kelly wrote:
> > If so, I would suggest pulling the proposal out of the thread and do a
> vote
> > to make sure everyone in the community are on the same page.
> >
> > It is okay we don't have to document at this time. We can let you manage
> > the process in
> If so, I would suggest pulling the proposal out of the thread and do a vote
> to make sure everyone in the community are on the same page.
>
> It is okay we don't have to document at this time. We can let you manage
> the process in next bugfix release. Once it is done, propagate the process
> to
On Thu, Feb 21, 2019 at 4:53 PM Ivan Kelly wrote:
> > Your proposal works for me.
>
> If it helps, I can volunteer to do the next bugfix release also.
>
+1 from me.
If so, I would suggest pulling the proposal out of the thread and do a vote
to make sure everyone in the community are on the same
> Your proposal works for me.
If it helps, I can volunteer to do the next bugfix release also.
-Ivan
On Thu, Feb 21, 2019 at 4:45 PM Ivan Kelly wrote:
> > When it comes to release a minor release, he should :
> >
> > 1) go through all the issues in current master and pick the issues that
> are
> > required to cherry-pick to branches, and label them with `cherry-pick`
> > label.
> > 2) go through
> When it comes to release a minor release, he should :
>
> 1) go through all the issues in current master and pick the issues that are
> required to cherry-pick to branches, and label them with `cherry-pick`
> label.
> 2) go through all the issues label with `cherry-pick` label, and
> cherry-pick
On Thu, Feb 21, 2019 at 10:57 AM Dave Fisher wrote:
>
>
> > On Feb 20, 2019, at 6:47 PM, Sijie Guo wrote:
> >
> > On Wed, Feb 20, 2019 at 9:12 PM Ivan Kelly wrote:
> >
> >>> Can anyone propose a change to current release management? Otherwise it
> >> is
> >>> not a scalable solution because not
> On Feb 20, 2019, at 6:47 PM, Sijie Guo wrote:
>
> On Wed, Feb 20, 2019 at 9:12 PM Ivan Kelly wrote:
>
>>> Can anyone propose a change to current release management? Otherwise it
>> is
>>> not a scalable solution because not every committer knows how to handle
>>> this situation clearly.
>>
>
> On Feb 20, 2019, at 6:47 PM, Sijie Guo wrote:
>
> On Wed, Feb 20, 2019 at 9:12 PM Ivan Kelly wrote:
>
>>> Can anyone propose a change to current release management? Otherwise it
>> is
>>> not a scalable solution because not every committer knows how to handle
>>> this situation clearly.
>>
On Wed, Feb 20, 2019 at 9:12 PM Ivan Kelly wrote:
> > Can anyone propose a change to current release management? Otherwise it
> is
> > not a scalable solution because not every committer knows how to handle
> > this situation clearly.
>
> I agree that not every committer knows this.
> What has wo
> Can anyone propose a change to current release management? Otherwise it is
> not a scalable solution because not every committer knows how to handle
> this situation clearly.
I agree that not every committer knows this.
What has worked well for me in the past is to have _every_ commit go
to mast
Hi all,
Can we discuss the policy for major and minor release management?
The current approach using milestone for tracking how a pull request is
merged is a bit confusing. For example, I am seeing some issues labelled as
2.3.1 but the pull requests are created based on master. I don't kno
17 matches
Mail list logo
