[opendmarc-users] Patch Comparison and Personal RFC

[Juri Haberland]

Good morning everyone.

On 2016-12-13 06:42, Scott Kitterman wrote:
> On Monday, December 12, 2016 07:56:57 PM Steve Jenkins wrote:
>> Scott, Juri, and anyone else who feels like chiming in (I'm looking at 
>> you,
>> Andreas):
>> 
>> I've built this simple spreadsheet showing the patches that each of 
>> you
>> suggests including in an opendmarc build that you consider "worthy" of
>> pushing to stable repos , even though it's built using beta source:
>> 
>> https://docs.google.com/spreadsheets/d/1bhlYp_A6j_NF6I9cEAoHsYJV06ooEjkDlsMo
>> 9v67mtQ/edit?usp=sharing
>> 
>> As you can see, for the most part, both agree on the majority of the
>> patches.
>> 
>> But before I make a final decision regarding which patches I believe 
>> should
>> appear in a Fedora/RHEL build, I'd like to hear comments about:
>> 
>> - why you chose to include a patch that the other one didn't, and
>> - why you chose not to include a patch that the other one did
> 
> So here's the differences:
> 
> https://sourceforge.net/p/opendmarc/tickets/159/
> 
> I didn't include it because I didn't have the time to study it.

In hindsight this patch is wrong - it uses an internal variable of the 
autoconf/automake stuff, which it shouldn't. I need to dig deeper into 
this matter to understand how autoconf/automake works. I guess there is 
a problem in the way it is used in OpenDMARC and that is also why 
Scott's approach to use %{prefix} in the ./configure command line didn't 
work as expected.
If you didn't already applied it - leave it out.

btw. the same goes for https://sourceforge.net/p/opendmarc/tickets/179/ 
which is on top of #159.

> https://sourceforge.net/p/opendmarc/tickets/168/
> 
> I included this one, but in retrospect, probably shouldn't have.  It's 
> a new
> feature and I generally don't think we should be distro patching those 
> in.  I
> don't plan to drop it, since I've shipped it, but I don't particularly
> recommend you add it.
> 
> Not sure what I was thinking at the time.

He he, I wondered why you included that one, too, but didn't want to 
start a discussion, because I was glad that there was some progress at 
least at the distro/packaging end...

> https://sourceforge.net/p/opendmarc/tickets/171/
> 
> Seemed low priority, but probably worthwhile including. The only 
> concern is if
> later msk decides to change the code to match the docs rather than 
> change the
> docs to match the code.

It is low priority, but annoying if you are try to debug some mail flow 
and run into this problem. And yes, I understand your concerns, but 
maybe just create precedents?

> https://sourceforge.net/p/opendmarc/tickets/193/
> 
> I think I missed this one by accident.

The patch is fairly new, but we had a couple of users on the ML 
complaining about scripts failing with MySQL running with strict mode 
enabled.

> https://sourceforge.net/p/opendmarc/tickets/197/
> 
> This one I left alone since there's no telling which of the two msk 
> will keep.
> I thought it better to have two than to remove one and have it change 
> later.

Fair enough - or just create another precedent ;)


   Juri