Newbie maintainer, question regarding patches

[Michael Gmelin]

On Feb 24, 2012, at 14:55, Eitan Adler wrote:

> On Fri, Feb 24, 2012 at 7:39 AM, Michael Gmelin <freebsd at 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.
> 
> 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

> 
> 
> 
> -- 
> Eitan Adler