geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Owen Nichols <onich...@pivotal.io>
Subject Re: [DISCUSS] Time to cut Geode 1.10.0?
Date Tue, 06 Aug 2019 20:00:41 GMT
Hi Kirk, thank you for bringing your concern.

Yes, release/1.10.0 was created last week <https://lists.apache.org/thread.html/4d4388ccab1170d94b8b6d204efe9197a4d3ddc2d25cbb6e6cecee0d@%3Cdev.geode.apache.org%3E>
as planned.  Our current process <https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E>
dictates a time-based schedule to cut release branches.  Once cut, the “critical fixes”
rule allows critical fixes to be brought to the release branch by proposal on the dev list.

Currently the 1.10.0 release pipeline <https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-10-0-main>
is all green.  If there is consensus from the Geode community that this log4j change satisfies
the “critical fixes” rule, Dick or I will be happy to bring it to the 1.10.0 release branch.

-Owen

> On Aug 6, 2019, at 12:49 PM, Kirk Lund <klund@apache.org> wrote:
> 
> Did we already cut the 1.10 branch?
> 
> I'd like to find out if it's possible to get a change into 1.10: Upgrade
> log4j from 2.11.1 to 2.12.0 and mark log4j-core as an optional dependency
> in the geode-core pom.
> 
> Getting this change into 1.10 will make things much easier for Spring Boot
> Data Geode. When using Geode with Spring Boot, log4j-core has to be
> manually excluded so that logback can be used instead. The change to log4j
> 2.12.0 will also help as they have already have some dependency on 2.12.0
> (probably log4j-to-slf4j). I can find out more precise details if needed.
> 
> On Wed, Jul 31, 2019 at 9:35 AM Dick Cavender <dixie@apache.org> wrote:
> 
>> In preparation for cutting the release branch have we confirmed that
>> Geode's LICENSE and NOTICE file been confirmed to accurately reflect what
>> is being shipped for v1.10?
>> 
>> From Apache: http://www.apache.org/dev/licensing-howto.html
>> *"*The LICENSE and NOTICE files must exactly represent the contents of the
>> distribution they reside in."
>> 
>> Ideally this is kept up to date during development as the dependencies
>> change or are added but this often is missed and needs to be reconciled on
>> develop before we cut a release branch.
>> 
>> -Dick
>> 
>> 
>> 
>> 
>> 
>> On Tue, Jul 30, 2019 at 6:04 PM Owen Nichols <onichols@pivotal.io> wrote:
>> 
>>> From that email:
>>> 
>>> To make this work, it's important to be strict
>>> about cutting the release branch on the set date and only allow critical
>>> fixes after the release has been cut. Once we start compromising on this,
>>> we go down a slippery slope that ultimately leads to not getting the
>>> predictability benefits described here.
>>> 
>>> We are perilously close to the "slippery slope”:
>>> * Geode 1.8.0 was announced on Dec 12 — almost 8 months ago
>>> * Geode 1.9.0 was announced on Apr 25 — putting us about 5 weeks late
>>> already on cutting the 1.10 branch
>>> 
>>> It seems like the community reaction to branching from the SHA initially
>>> proposed is “woah, not quite yet”.
>>> 
>>> To get last-minute stuff in (or out) and get back on track, I propose
>>> setting a strict CUT date for the 1.10 branch at 3PM PDT Thursday August
>> 1.
>>> 
>>> -Owen
>>> 
>>> 
>>>> On Jul 30, 2019, at 5:31 PM, Alexander Murmann <amurmann@apache.org>
>>> wrote:
>>>> 
>>>> Hi Karen,
>>>> 
>>>> Here is the previous discussion that was very positively received:
>>>> 
>>> 
>> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
>>>> 
>>>> However, JIRA tells me that GEODE-7013 is already fixed. If we were to
>> go
>>>> with a SHA from this week, for which Jake also chimed in with plenty of
>>>> reasons, this should be in the release.
>>>> 
>>>> On Tue, Jul 30, 2019 at 5:10 PM Karen Miller <kmiller@pivotal.io>
>> wrote:
>>>> 
>>>>> Alexander, can you point me at the policy decision for the "critical
>>> issue"
>>>>> rule you mention? I always though it was up
>>>>> to the release manager.
>>>>> 
>>>>> I want GEODE-7013 fixes in because it is the right thing to do.  Our
>>> gfsh
>>>>> help/hint wasn't working the way we say that it did.
>>>>> With the fix, it does.  I want either the documentation to match the
>>> code,
>>>>> or I want the code to match the documentation.
>>>>> The fix in GEODE-7013 changes the code to match the existing
>>> documentation,
>>>>> so we don't have to change the documentation
>>>>> (which would have needed to be cherry-picked into our 1.10 release
>>> branch).
>>>>> 
>>>>> 
>>>>> On Tue, Jul 30, 2019 at 11:47 AM Owen Nichols <onichols@pivotal.io>
>>> wrote:
>>>>> 
>>>>>> Our "critical issue” rule has the effect that the bar to commit
to
>>>>> develop
>>>>>> is “low”, but the bar to cherry-pick to support branch is “very
>> high”.
>>>>>> 
>>>>>> Contributors could plan around this disparity more easily if any
of
>> the
>>>>>> following were true:
>>>>>> - releases were more frequent
>>>>>> - planned cut date of release branch was announced in advance (rather
>>>>> than
>>>>>> retroactively)
>>>>>> - a process existed for making exceptions to the “critical issue”
>> rule
>>>>>> 
>>>>>> I agree that the proposed SHA looks like a relatively stable
>>> branchpoint
>>>>>> (coming near the end of a nice period of solid green in the
>> pipeline),
>>>>> and
>>>>>> I acknowledge that fair warning was given a week ago that a branch
>> was
>>>>>> “coming soon”, but I wonder if there is anything we can do to
make
>> the
>>>>>> rules for what gets in a release and what doesn’t feel a little
less
>>>>>> arbitrary?
>>>>>> 
>>>>>> -Owen
>>>>>> 
>>>>>> 
>>>>>>> On Jul 30, 2019, at 11:16 AM, Alexander Murmann <
>> amurmann@apache.org>
>>>>>> wrote:
>>>>>>> 
>>>>>>> Dick, thank you for stepping up!
>>>>>>> 
>>>>>>> I think it's great to cut the branch sooner rather than later.
There
>>>>>>> already is GEODE-7012 which introduces a distributed deadlock
during
>>>>>>> startup. That seems like a critical issue to fix. That should
be
>> able
>>>>> to
>>>>>>> happen after we cut the branch though.
>>>>>>> 
>>>>>>> Karen, I wonder if that could be merged after the branch got
cut,
>> but
>>>>>> also
>>>>>>> wonder if that fits our "critical issue" rule for being merged
after
>>>>> the
>>>>>>> branch has been cut or hold up the release. This has been broken
>> since
>>>>> a
>>>>>>> very long time. Thoughts?
>>>>>>> 
>>>>>>> On Tue, Jul 30, 2019 at 10:51 AM Karen Miller <kmiller@pivotal.io>
>>>>>> wrote:
>>>>>>> 
>>>>>>>> I'd like to see the changes from
>>>>>>>> https://issues.apache.org/jira/browse/GEODE-7013 included
in the
>>>>> Geode
>>>>>>>> 1.10
>>>>>>>> release. GEODE-7013's changes restore gfsh help/hint behavior
that
>>> was
>>>>>> lost
>>>>>>>> during a refactor in the earliest
>>>>>>>> releases of Geode.  The commit occurred after SHA1
>>>>>>>> dc6890107a2651d8ba1450e8db8a1c39d712fdc7.
>>>>>>>> Thanks.  Karen
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Tue, Jul 30, 2019 at 10:39 AM Dick Cavender <dixie@apache.org>
>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> I'll take on the Release Manager role for Geode 1.10
with the
>> 1.9.0
>>>>>>>> release
>>>>>>>>> manager's help (Owen:).
>>>>>>>>> 
>>>>>>>>> I'd like to propose cutting the release/1.10 branch off
develop
>> sha:
>>>>>>>>> dc6890107a2651d8ba1450e8db8a1c39d712fdc7
>>>>>>>>> 
>>>>>>>>> aka: 1.10.0-SNAPSHOT.476
>>>>>>>>> 
>>>>>>>>> Please speak up and discuss. We'll then start taking
>> considerations
>>>>> for
>>>>>>>>> additional changes for 1.1.0 after we get the branch
and pipeline
>> in
>>>>>>>> place.
>>>>>>>>> 
>>>>>>>>> -Dick
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Mon, Jul 29, 2019 at 4:08 PM Alexander Murmann <
>>>>> amurmann@apache.org
>>>>>>> 
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> Thanks for calling this out Ernie!
>>>>>>>>>> 
>>>>>>>>>> It might be a good idea to cut the release and at
the same time
>>> keep
>>>>>>>>>> looking for urgent issues that need to be resolved
and merged.
>> Once
>>>>>> the
>>>>>>>>>> branch is cut, we release likelihood of new issues
being
>>> introduced.
>>>>>>>>>> 
>>>>>>>>>> Does anyone know of any other issues, we'd want to
make sure get
>>>>>>>>> addressed
>>>>>>>>>> before we ship?
>>>>>>>>>> 
>>>>>>>>>> On Mon, Jul 29, 2019 at 3:36 PM Ernest Burghardt
<
>>>>>>>> eburghardt@pivotal.io>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> There is a PR #3844 <https://github.com/apache/geode/pull/3844>
>>> up
>>>>>>>> to
>>>>>>>>>>> address GEODE-7012 <
>>>>> https://issues.apache.org/jira/browse/GEODE-7012
>>>>>>>>> 
>>>>>>>>> I
>>>>>>>>>>> think this should be in the next release...
>>>>>>>>>>> 
>>>>>>>>>>> EB
>>>>>>>>>>> 
>>>>>>>>>>> On Fri, Jul 26, 2019 at 4:07 PM Alexander Murmann
<
>>>>>>>> amurmann@apache.org
>>>>>>>>>> 
>>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> *Cutting the release*
>>>>>>>>>>>> Do we have any volunteers to take over the
release manager
>> role?
>>>>>>>>>>>> 
>>>>>>>>>>>> *Re: Udo's concerns*
>>>>>>>>>>>> While I believe that iterations of this particular
work have
>> been
>>>>>>>>>>> discussed
>>>>>>>>>>>> on the mailing list as far back as March
2018, I do think that
>> we
>>>>>>>>>> should
>>>>>>>>>>>> take Udo's response as an indicator that
something with our
>>> larger
>>>>>>>>>>> proposal
>>>>>>>>>>>> process needs to be improved. We used to
have synchronous Geode
>>>>>>>> club
>>>>>>>>>>> house
>>>>>>>>>>>> sessions. For future discussions and for
proposals in
>> particular,
>>>>> I
>>>>>>>>>> think
>>>>>>>>>>>> it would be great to supplement our asynchronous
mailing list
>>>>>>>>>>> communication
>>>>>>>>>>>> with a synchronous video chat discussions
by the community.
>>>>>>>>>>>> 
>>>>>>>>>>>> On Fri, Jul 26, 2019 at 4:02 PM Dan Smith
<dsmith@pivotal.io>
>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> +1 for cutting a 1.10.0 release branch.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Fri, Jul 26, 2019 at 3:55 PM Nabarun
Nag <nnag@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>> I believe the original authors of
the feature has done their
>>>>>>>> due
>>>>>>>>>>>>> diligence
>>>>>>>>>>>>>> and followed all steps, we can get
this feature in under the
>>>>>>>>>>>> Experimental
>>>>>>>>>>>>>> flag and let the community improve
on it, if there is
>> anything
>>>>>>>>> else
>>>>>>>>>>>> that
>>>>>>>>>>>>>> needs to be done.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> We have done this before for Lucene
re-index feature, where
>> we
>>>>>>>>>>> involved
>>>>>>>>>>>>> the
>>>>>>>>>>>>>> entire community in its development,
phase by phase. The wiki
>>>>>>>> is
>>>>>>>>> up
>>>>>>>>>>> and
>>>>>>>>>>>>>> running, if someone has any concerns
can raise it as a JIRA
>> or
>>>>>>>>>>> comment
>>>>>>>>>>>> in
>>>>>>>>>>>>>> the wiki and the community as a whole
can decide if it is a
>>>>>>>> valid
>>>>>>>>>>>>>> concern or not and act upon it.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>> Nabarun Nag
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Fri, Jul 26, 2019 at 3:40 PM Udo
Kohlmeyer <
>> udo@apache.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> @Alexander + @Jared,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> So maybe that was my misunderstanding
on the RFC (not being
>>>>>>>>>>> optional
>>>>>>>>>>>> on
>>>>>>>>>>>>>>> new feature work). Given that
this is a new feature, there
>> is
>>>>>>>>>>>>>>> significant risk to getting it
"wrong".
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I was expecting more discussion
around this. I have some
>>>>>>>>>> objections
>>>>>>>>>>>> to
>>>>>>>>>>>>>>> the current approach/design.
Given that my day job does not
>>>>>>>>> allow
>>>>>>>>>>> me
>>>>>>>>>>>> to
>>>>>>>>>>>>>>> respond in a timely manner, I
would have not been able to
>> get
>>>>>>>>> all
>>>>>>>>>>> my
>>>>>>>>>>>>>>> concerns raised. In addition,
throwing something onto the
>>>>>>>> wiki,
>>>>>>>>>> and
>>>>>>>>>>>>> then
>>>>>>>>>>>>>>> a few weeks before we'd like
to cut a version raising a
>>>>>>>>>> discussion
>>>>>>>>>>>>>>> thread on work that has been
going on for months already
>> does
>>>>>>>>> not
>>>>>>>>>>>> help
>>>>>>>>>>>>>>> with the community being able
to read, digest, think, reason
>>>>>>>>> and
>>>>>>>>>>>>> respond
>>>>>>>>>>>>>>> BEFORE it is released.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I know `@Experimental` is non-binding
on API's or usage, BUT
>>>>>>>> I
>>>>>>>>>>> prefer
>>>>>>>>>>>>>>> some of the ground work to have
been discussed, API's
>>>>>>>> validated
>>>>>>>>>>>> BEFORE
>>>>>>>>>>>>>>> it is released into the wild.
I mean this is a PUBLIC API,
>> so
>>>>>>>>>> we'd
>>>>>>>>>>>>>>> prefer to get it more correct
than the previous one.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Maybe it is just me, taking it
too serious... Where I prefer
>>>>>>>>> not
>>>>>>>>>>>>> release
>>>>>>>>>>>>>>> something as close to 95% correct
(and discussed).
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Anyway.. If we want to cut 1.10...
and we should... Let's do
>>>>>>>>> so..
>>>>>>>>>>> but
>>>>>>>>>>>>>>> I'd prefer that more on the correctness
on the approach.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> --Udo
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 7/25/19 11:08 AM, Alexander
Murmann wrote:
>>>>>>>>>>>>>>>>> I don't believe we should
be including anything into the
>>>>>>>>> Geode
>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>> that has not gone through
the correct process of feature
>>>>>>>>>>> proposal.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> All work under the experimental
cluster management service
>>>>>>>>> has
>>>>>>>>>>> not
>>>>>>>>>>>>> yet
>>>>>>>>>>>>>>>>> been approved by the
agreed upon RFC process.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Udo, I didn't take the RFC
process that we agreed on to be
>>>>>>>> a
>>>>>>>>>> gate
>>>>>>>>>>>>>> keeper,
>>>>>>>>>>>>>>>> but rather a way to de-risk
work before making a PR.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> From the RFC doc in the wiki:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> When to write an RFC?
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Writing an RFC should
be entirely voluntary. There is
>>>>>>>> always
>>>>>>>>>> the
>>>>>>>>>>>>>> option
>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>> going straight to a pull
request. However, for larger
>>>>>>>>> changes,
>>>>>>>>>>> it
>>>>>>>>>>>>>> might
>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>> wise to de-risk the risk
of rejection of the pull request
>>>>>>>> by
>>>>>>>>>>> first
>>>>>>>>>>>>>>>>> gathering input from
the community. Therefore it’s up to
>>>>>>>>> every
>>>>>>>>>>>>> member
>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>> our community to decide
themselves when they want to reach
>>>>>>>>> for
>>>>>>>>>>>> this
>>>>>>>>>>>>>>> tool.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> If we want to change the
role of the RFC process, that's
>>>>>>>> fine
>>>>>>>>>>> with
>>>>>>>>>>>>> me,
>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>> we should have that discussion
first.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On Tue, Jul 23, 2019 at 10:30
AM Jared Stewart <
>>>>>>>>>>>>>> stewart.jared@gmail.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> What was missing from
the RFC process for the cluster
>>>>>>>>>> management
>>>>>>>>>>>>>>> service?
>>>>>>>>>>>>>>>>> I saw a [Discuss] thread
for it, as well as a proposal at
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>> 
>>> 
>> https://cwiki.apache.org/confluence/display/GEODE/Cluster+Management+Service
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On Tue, Jul 23, 2019
at 10:02 AM Udo Kohlmeyer <
>>>>>>>>>> udo@apache.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> I don't believe we
should be including anything into the
>>>>>>>>>> Geode
>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>> that has not gone
through the correct process of feature
>>>>>>>>>>>> proposal.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> All work under the
experimental cluster management
>>>>>>>> service
>>>>>>>>>> has
>>>>>>>>>>>> not
>>>>>>>>>>>>>> yet
>>>>>>>>>>>>>>>>>> been approved by
the agreed upon RFC process.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> I don't believe we
should be including this work,
>>>>>>>>>> experimental
>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>> otherwise.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> --Udo
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On 7/22/19 4:51 PM,
Alexander Murmann wrote:
>>>>>>>>>>>>>>>>>>> Udo, do you mind
explaining how the RFC process comes
>>>>>>>> into
>>>>>>>>>>> this?
>>>>>>>>>>>>> Are
>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>> suggesting that
we should wait if an RFC had a target
>>>>>>>>>> release
>>>>>>>>>>>>>>> attached?
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> On Mon, Jul 22,
2019 at 4:47 PM Udo Kohlmeyer <
>>>>>>>>>> udo@apache.com
>>>>>>>>>>>> 
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> I don't think
we need to wait for this, as there has
>>>>>>>> been
>>>>>>>>>> no
>>>>>>>>>>>> RFC
>>>>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>>>>> followed.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> --Udo
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> On 7/22/19
3:38 PM, Jinmei Liao wrote:
>>>>>>>>>>>>>>>>>>>>> Work
is still being planned to move the cluster
>>>>>>>>> management
>>>>>>>>>>>> rest
>>>>>>>>>>>>>>>>> service
>>>>>>>>>>>>>>>>>>>>> under
an experimental version flag and use a geode
>>>>>>>>>> property
>>>>>>>>>>> to
>>>>>>>>>>>>>> turn
>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>> on/off.
I would say we are ready to cut the geode
>>>>>>>> 1.10.0
>>>>>>>>>>> after
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>> work
>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>> complete.
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> On Mon,
Jul 22, 2019 at 3:24 PM Alexander Murmann <
>>>>>>>>>>>>>>>>> amurmann@apache.org
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> Hi
everyone!
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> We
released Geode 1.9.0 on April 25th. That's about 3
>>>>>>>>>>> months
>>>>>>>>>>>>> ago.
>>>>>>>>>>>>>>>>> End
>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>> last
year we discussed releasing quarterly. In the
>>>>>>>> past
>>>>>>>>>>> we've
>>>>>>>>>>>>> had
>>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>> month
between cutting a release branch and actually
>>>>>>>>>>> shipping
>>>>>>>>>>>>> our
>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>>>>> minor.
>>>>>>>>>>>>>>>>>>>>>> This
means we are already behind our target release
>>>>>>>>>>> cadence.
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> What
are your thoughts on cutting a 1.10.0 release
>>>>>>>>> branch
>>>>>>>>>>>> this
>>>>>>>>>>>>>>> week?
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> Would
anyone like to volunteer to be the release
>>>>>>>>> manager
>>>>>>>>>>> for
>>>>>>>>>>>>>> geode
>>>>>>>>>>>>>>>>>>>> 1.10.0?
>>>>>>>>>>>>>>>>>>>>>> Thank
you all!
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>> 
>>> 
>> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message