tp32 is now open for business - snapshots/docs are deployed. On Fri, Oct 26, 2018 at 8:18 AM Stephen Mallette <[email protected]> wrote:
> I'm +0 on formalizing too much....some common sense like "release next > cycle unless someone can provide a proof of concept or just feels strongly > otherwise" is fine by me. > > > If you're going to reopen tp32, then I'll retarget > > sounds good - thanks for staying up on the "security" stuff > > On Fri, Oct 26, 2018 at 8:06 AM Robert Dale <[email protected]> wrote: > >> If you're going to reopen tp32, then I'll retarget >> https://github.com/apache/tinkerpop/pull/969 >> >> Robert Dale >> >> >> On Fri, Oct 26, 2018 at 7:56 AM Robert Dale <[email protected]> wrote: >> >> > So to answer your earlier question on security fixes, the driver should >> be >> > our security policy ;-) >> > >> > For example, if tp32 is not officially closed and accepts bug fixes, and >> > given "security problems are just bugs" [1], then tp32 should get >> > security-related bug fixes. >> > >> > We can use CVSS [2] to score vulnerabilities. They even have a >> handy-dandy >> > calculator [3]. >> > >> > The release trigger should also be in the security policy. It could be >> > based on the CVSS score: >> > <5, next scheduled release >> > <7, within 30 days >> > <8, within 2 weeks >> > <9, within 1 week >> > 9+, asap >> > >> > Or we just keep it simple, release next cycle unless someone can >> provide a >> > proof of concept or just feels strongly otherwise. >> > >> > For example, I don't think TINKERPOP-2068 [4] is critical because our >> > serializers handle only explicitly listed types. Nothing is blindly >> > delegated to Jackson. No need for an emergency release. Someone can >> confirm. >> > >> > 1. https://lkml.org/lkml/2017/11/17/767 >> > 2. https://www.first.org/cvss/ >> > 3. https://www.first.org/cvss/calculator/3.0 >> > 4. https://issues.apache.org/jira/browse/TINKERPOP-2068 >> > >> > Robert Dale >> > >> > >> > On Fri, Oct 26, 2018 at 7:02 AM Stephen Mallette <[email protected]> >> > wrote: >> > >> >> tp32............... >> >> >> >> i started thinking that we could keep a JIRA ticket open that had a >> list >> >> of >> >> bugs we might backport to tp32 should we have some triggering event, >> >> but....i dunno. maybe we go with a first step at this and re-open the >> >> branch but just ship security+bug fixes at it and not try to wait for a >> >> triggering event for release. i would expect the CHANGELOG for 3.2.11 >> to >> >> be >> >> really small if we do this right. please let me know if there are any >> >> concerns, otherwise we'll start heading down this route and i'll >> re-open >> >> the branch on Monday. >> >> >> >> On Mon, Oct 22, 2018 at 11:42 AM Stephen Mallette < >> [email protected]> >> >> wrote: >> >> >> >> > there's always going to be those kinds of things though right? can we >> >> get >> >> > away with doing stuff to tp32 only when there is some specific demand >> >> for a >> >> > 3.2.11. like, that fix on its own doesn't feel like something we'd >> >> trigger >> >> > a release over....or would we? >> >> > >> >> > On Sat, Oct 20, 2018 at 9:27 AM Robert Dale <[email protected]> >> wrote: >> >> > >> >> >> You don't want to put >> >> >> https://issues.apache.org/jira/browse/TINKERPOP-2068 >> >> >> on tp32? >> >> >> >> >> >> Robert Dale >> >> >> >> >> >> >> >> >> On Fri, Oct 19, 2018 at 6:03 PM Stephen Mallette < >> [email protected] >> >> > >> >> >> wrote: >> >> >> >> >> >> > > I created a ticket to track this and I can probably take care >> of >> >> it >> >> >> next >> >> >> > week >> >> >> > >> >> >> > that makes sense, thank you. >> >> >> > >> >> >> > separately, code freeze is now lifted on tp33 - i've bumped to >> >> >> > 3.3.5-SNAPSHOT, published initial docs/artifacts and all is good >> to >> >> go. >> >> >> > I've left tp32 on 3.2.10 until we decide to actually do something >> on >> >> >> that >> >> >> > branch. For now, we'll just say we're done there as we discussed >> >> >> > elsethread. >> >> >> > >> >> >> > kuppitz, feel free to fire up the dead branch cleanup email. i >> wonder >> >> >> if it >> >> >> > will be more convenient to delete branches as we go now that we >> have >> >> the >> >> >> > github UI available to us. might be good to just hit the "delete >> >> branch" >> >> >> > button right when we hit the merge one. >> >> >> > >> >> >> > i will announce the releases on monday morning EST time. >> >> >> > >> >> >> > >> >> >> > >> >> >> > On Fri, Oct 19, 2018 at 5:04 PM Florian Hockmann < >> >> >> [email protected]> >> >> >> > wrote: >> >> >> > >> >> >> > > We currently use this to push the package: >> >> >> > > >> >> >> > > ${nugetExe} push Gremlin.Net/bin/Gremlin.Net.*.nupkg >> >> >> > > >> >> >> > > which pushes all NuGet packages starting with Gremlin.Net. You >> >> >> probably >> >> >> > > also had the package for version 3.4.0-rc2 in that directory. >> So, >> >> >> > > nuget.exe tried to push that version again which isn't allowed >> by >> >> >> NuGet >> >> >> > > as packages are immutable for a given version. >> >> >> > > >> >> >> > > I guess we should specify the exact version here instead to >> avoid >> >> >> these >> >> >> > > problems in the future. Otherwise we could push development >> >> versions >> >> >> to >> >> >> > > nuget.org by accident. I probably implemented it like this at >> >> first >> >> >> > > because I assumed that mvn clean would always remove older >> packages >> >> >> > > which seems to be not the case here. >> >> >> > > >> >> >> > > Anyway, I created a ticket to track this and I can probably take >> >> care >> >> >> of >> >> >> > > it next week: >> >> >> > > >> >> >> > > https://issues.apache.org/jira/browse/TINKERPOP-2074 >> >> >> > > >> >> >> > > >> >> >> > > Am 19.10.2018 um 21:16 schrieb Stephen Mallette: >> >> >> > > > Florian, any idea what's going on with this error when i >> deployed >> >> >> > 3.3.4: >> >> >> > > > >> >> >> > > > main: >> >> >> > > > [echo] nuget.exe already downloaded. >> >> >> > > > [exec] Pushing Gremlin.Net.3.3.4.nupkg to ' >> >> >> > > > https://www.nuget.org/api/v2/package'... >> >> >> > > > [exec] PUT https://www.nuget.org/api/v2/package/ >> >> >> > > > [exec] Created https://www.nuget.org/api/v2/package/ >> >> 1362ms >> >> >> > > > [exec] Your package was pushed. >> >> >> > > > [exec] Pushing Gremlin.Net.Template.3.3.4.nupkg to ' >> >> >> > > > https://www.nuget.org/api/v2/package'... >> >> >> > > > [exec] PUT https://www.nuget.org/api/v2/package/ >> >> >> > > > [exec] Created https://www.nuget.org/api/v2/package/ >> >> 11405ms >> >> >> > > > [exec] Your package was pushed. >> >> >> > > > [exec] Pushing Gremlin.Net.Template.3.4.0-rc2.nupkg to ' >> >> >> > > > https://www.nuget.org/api/v2/package'... >> >> >> > > > [exec] PUT https://www.nuget.org/api/v2/package/ >> >> >> > > > [exec] Conflict https://www.nuget.org/api/v2/package/ >> >> 365ms >> >> >> > > > [exec] 409 (A package with ID 'Gremlin.Net.Template' and >> >> >> version >> >> >> > > > '3.4.0-rc2' already exists and cannot be modified.) >> >> >> > > > >> >> >> > > > >> >> >> > > > why is it trying to push the 3.4.0 line? looks like the error >> >> >> didn't >> >> >> > > > matter as the other two published fine, but let's fix the >> error >> >> if >> >> >> we >> >> >> > > > can........... >> >> >> > > > >> >> >> > > > On Fri, Oct 12, 2018 at 7:27 PM Stephen Mallette < >> >> >> [email protected] >> >> >> > > >> >> >> > > > wrote: >> >> >> > > > >> >> >> > > >> Robert Dale is without power so I pushed the 3.2.10-SNAPSHOT >> >> >> artifacts >> >> >> > > and >> >> >> > > >> docs too: >> >> >> > > >> >> >> >> > > >> http://tinkerpop.apache.org/docs/3.2.10-SNAPSHOT/ >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> On Fri, Oct 12, 2018 at 8:22 AM Stephen Mallette < >> >> >> > [email protected]> >> >> >> > > >> wrote: >> >> >> > > >> >> >> >> > > >>> I just published final 3.3.4-SNAPSHOT artifacts and docs: >> >> >> > > >>> >> >> >> > > >>> http://tinkerpop.apache.org/docs/3.3.4-SNAPSHOT/ >> >> >> > > >>> >> >> >> > > >>> On Sun, Oct 7, 2018 at 8:33 AM Robert Dale < >> [email protected]> >> >> >> > wrote: >> >> >> > > >>> >> >> >> > > >>>> I'll take 3.2.10. >> >> >> > > >>>> >> >> >> > > >>>> Robert Dale >> >> >> > > >>>> >> >> >> > > >>>> >> >> >> > > >>>> On Fri, Oct 5, 2018 at 7:40 PM Stephen Mallette < >> >> >> > [email protected] >> >> >> > > > >> >> >> > > >>>> wrote: >> >> >> > > >>>> >> >> >> > > >>>>> So - code freeze for the tp32 and tp33 branches is in >> effect >> >> at >> >> >> > this >> >> >> > > >>>> point. >> >> >> > > >>>>> We'll use this thread to discuss issues related to 3.2.10 >> and >> >> >> 3.3.4 >> >> >> > > >>>> leading >> >> >> > > >>>>> up to the build of release artifacts for 10/15. We >> currently >> >> >> have a >> >> >> > > >>>> few PRs >> >> >> > > >>>>> that need merging to those branches, >> >> >> > > >>>>> >> >> >> > > >>>>> https://github.com/apache/tinkerpop/pull/952 (submit >> scripts >> >> >> with >> >> >> > > >>>>> gremlin-javascript) >> >> >> > > >>>>> https://github.com/apache/tinkerpop/pull/953 (minor fix >> for >> >> >> > testing >> >> >> > > >>>> around >> >> >> > > >>>>> inject in .net) >> >> >> > > >>>>> >> >> >> > > >>>>> but they are related to GLVs so we shouldn't be affecting >> the >> >> >> > ability >> >> >> > > >>>> of >> >> >> > > >>>>> graph providers to test against the core code. If those >> merge >> >> >> > during >> >> >> > > >>>> code >> >> >> > > >>>>> freeze, I don't think that's too big a problem. >> >> >> > > >>>>> >> >> >> > > >>>>> Note that the master branch will remain open for >> development >> >> >> during >> >> >> > > >>>> this >> >> >> > > >>>>> time period. >> >> >> > > >>>>> >> >> >> > > >>>>> Anyone care to volunteer for release manager duties for >> >> either >> >> >> of >> >> >> > > these >> >> >> > > >>>>> releases? >> >> >> > > >>>>> >> >> >> > > >> >> >> > > >> >> >> > >> >> >> >> >> > >> >> >> > >> >
