Date: Fri, 24 Feb 2012 15:18:49 +0100 From: Michael Gmelin <freebsd@grem.de> To: Eitan Adler <lists@eitanadler.com> Cc: ports@freebsd.org Subject: Re: Newbie maintainer, question regarding patches Message-ID: <EBFDDF5D-6BE4-4BCF-BD0A-C297D3E6DCA2@grem.de> In-Reply-To: <CAF6rxgmj7V85qrDBoK4ZbmShDLTW-yazUodEgq8KYA3jYYGhxQ@mail.gmail.com> References: <845ACEFD-830F-4941-9EE3-F3CB35FD6200@grem.de> <CAF6rxgmj7V85qrDBoK4ZbmShDLTW-yazUodEgq8KYA3jYYGhxQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 24, 2012, at 14:55, Eitan Adler wrote: > On Fri, Feb 24, 2012 at 7:39 AM, Michael Gmelin <freebsd@grem.de> = wrote: >> b) I also have another massive patch which touches another 20 files = which enables some new security features in ice (the history of this = patch is that I developed it at first and submitted it to the vendor, = who refined it and sent it back to me). I might want to make this patch = optional as well (using a dialog style menu to enable it). In this case = it also seems like it would be better not to split the patch up to all = that many sources, but keep it as one feature that's contained in one = patch. >=20 > Just replying to this question: The ports tree is not meant for > software development. I would much rather you try to get the patch > into the upstream source than keep it as an optional patch in the > ports tree. In general I agree with your reasoning. The feature I'm talking about = has been approved and will be in the next version (this happened almost = half a year ago). Unfortunately Ice has a slow release cycle, as it is = dual licensed (GPLv2+commercial). The next release of Ice is quite a = while away and will probably a major release, as they only create = releases that are also commercially supported. The vendor doesn't = provide any source repository access or anything else that could be used = to track new features or patches, they only get announced in the forums. = So as a heavy user of this software package I would like to have access = to these vendor approved and backwards compatible optional features = without working outside of the ports tree. To a certain degree this is = comparable to other ports that pull in optional features through patches = (djbdns, qmail, nginx, php, etc.). Alternatively an devel/ice-devel port could be created, that brings in = more of these new features, but that would of course create more = overhead - I could also host these feature patches outside of ports (as = PATCHFILES) or create a forked project to track them, but all of this = seems a little bit like over engineering, given the fact that the = changes are fairly minimal (even though they're touching many files). Michael >=20 >=20 >=20 > --=20 > Eitan Adler
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EBFDDF5D-6BE4-4BCF-BD0A-C297D3E6DCA2>