Date: Thu, 7 Jul 2016 01:32:04 +0000 From: Alexey Dokuchaev <danfe@FreeBSD.org> To: Guido Falsi <madpilot@FreeBSD.org> Cc: Mathieu Arnold <mat@FreeBSD.org>, Baptiste Daroussin <bapt@FreeBSD.org>, ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: Re: svn commit: r417895 - in head/net: ndpi ntopng Message-ID: <20160707013204.GA96368@FreeBSD.org> In-Reply-To: <448ef6e0-5ea1-343a-7660-211ee9831b56@FreeBSD.org> References: <201607011649.u61Gn9fh068891@repo.freebsd.org> <20160701165811.7bcj7applsqmtsvr@ivaldir.etoilebsd.net> <d08ba7cd-14b1-f203-6d5d-81fb4b054dce@FreeBSD.org> <3980A22FBF4119291DE71664@atuin.in.mat.cc> <448ef6e0-5ea1-343a-7660-211ee9831b56@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jul 03, 2016 at 09:16:40AM +0200, Guido Falsi wrote: > On 07/02/16 22:01, Mathieu Arnold wrote: > > ... > > If this is not 1.8, it should not be called 1.8 but 1.8.1 or similar. > > The upstream did not create a new version, which is something I cannot > do. I would just lie by marking the port as 1.8.1 if there is no 1.8.1 > release upstream. Correct, and lying is bad. > The commit I am taking is just a few commits ahead of the 1.8 tag and > contains fixes which I could have imported as patches i files, like we > are doing all the time (I mean importing upstream patches), I did prefer > to just move ahead on the upstream repository for coherence with their > sources. Correct, it should be version 1.8 just like you did. > Apart from talking to the upstream and ask them to tag minor releases > (which I'm going to do BTW, I just need time ti coordinate about this) I > have these options(in random order): > > - add a date to the ndpi version (like 1.8.2016.07.02) to differentiate > from the 1.8 tag (imho this is overkill for just a few small > modifications from upstream) Rationale in parentheses is valid; it *is* an overkill for little benefit. > - revert my last commit opn ndpi and disengage the ntopng port from it, > using a statically linked ndpi in it like upstream is doing (which would > anyway come from the same sources ndpi port is using a t present) > > - maybe create a ndpi-stable port? this would definitely be overkill. > > - point the port at the tag and cherry pick some fixes from upstream as > local patches in files. This would be just formally different from what > I'm doing now. There's nothing to fix as nothing is broken. Move along. ;-) ./danfe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160707013204.GA96368>