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 <spmalle...@gmail.com> 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 <spmalle...@gmail.com> > 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 <robd...@gmail.com> 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 <spmalle...@gmail.com> > >> 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 < > >> f...@florian-hockmann.de> > >> > 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 < > >> spmalle...@gmail.com > >> > > > >> > > > 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 < > >> > spmalle...@gmail.com> > >> > > >> 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 <robd...@gmail.com> > >> > wrote: > >> > > >>> > >> > > >>>> I'll take 3.2.10. > >> > > >>>> > >> > > >>>> Robert Dale > >> > > >>>> > >> > > >>>> > >> > > >>>> On Fri, Oct 5, 2018 at 7:40 PM Stephen Mallette < > >> > spmalle...@gmail.com > >> > > > > >> > > >>>> 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? > >> > > >>>>> > >> > > > >> > > > >> > > >> > > >
