Bug 231377 - www/c-icap: update to 0.5.5
Summary: www/c-icap: update to 0.5.5
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Rodrigo Osorio
URL:
Keywords:
Depends on:
Blocks: 231378
  Show dependency treegraph
 
Reported: 2018-09-15 08:55 UTC by Franco Fichtner
Modified: 2018-10-02 15:51 UTC (History)
4 users (show)

See Also:
franco: maintainer-feedback? (rodrigo)


Attachments
0.5.4 update (1.16 KB, patch)
2018-09-15 08:55 UTC, Franco Fichtner
no flags Details | Diff
0.5.5 (1.16 KB, patch)
2018-09-19 20:30 UTC, Franco Fichtner
no flags Details | Diff
0.5.5 with fixes (3.09 KB, patch)
2018-09-25 18:00 UTC, Renato Botelho
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Franco Fichtner 2018-09-15 08:55:25 UTC
Created attachment 197105 [details]
0.5.4 update
Comment 1 Nathan 2018-09-15 17:16:32 UTC
Need to add bug#231378 to blocks on this bug report, since it depends on this port being done first.
Comment 2 Franco Fichtner 2018-09-19 20:30:55 UTC
Created attachment 197240 [details]
0.5.5
Comment 3 Nathan 2018-09-19 20:32:58 UTC
(In reply to Franco Fichtner from comment #2)
See comment#1
Comment 4 Franco Fichtner 2018-09-19 20:36:05 UTC
Like this?
Comment 5 Nathan 2018-09-19 20:37:52 UTC
(In reply to Franco Fichtner from comment #4)
Correct. Lets a committer know, this one must be committed first, as c-icap-modules depends on this port
Comment 6 Franco Fichtner 2018-09-19 20:41:49 UTC
Ok, thanks :)
Comment 7 Renato Botelho freebsd_committer freebsd_triage 2018-09-25 18:00:38 UTC
Created attachment 197495 [details]
0.5.5 with fixes

- Update c-icap to 0.5.5
- Move USES to a better place and silence portlint
- Remove 'ListenAddress 127.0.0.1' parameter from sample c-icap.conf since it doesn't work. Instead, replace the change to 'Port 127.0.0.1:1344'. More references about this problem at https://redmine.pfsense.org/issues/8832#note-10
- Regenerate patches with 'make makepatch'
Comment 8 commit-hook freebsd_committer freebsd_triage 2018-09-30 08:59:05 UTC
A commit references this bug:

Author: rodrigo
Date: Sun Sep 30 08:58:42 UTC 2018
New revision: 480943
URL: https://svnweb.freebsd.org/changeset/ports/480943

Log:
  Upgrade c-icap to 0.5.5

  - Update c-icap to 0.5.5
  - Move USES to a better place and silence portlint
  - Remove 'ListenAddress 127.0.0.1' parameter from sample c-icap.conf since it doesn't work. Instead, replace the change to 'Port 127.0.0.1:1344'. More references about this problem at https://redmine.pfsense.org/issues/8832#note-10
  - Regenerate patches with 'make makepatch'

  c-icap-0.5.5 changes
  - c-icap may crash with a SIGBUS while using mmap to map files to memory.
  - Fix multiple brotli decoding bugs
  - c-icap-client does not send the ";ieof" preview termination sequence when sends zero sized files

  PR:		231377
  Submitted by:	garga

Changes:
  head/www/c-icap/Makefile
  head/www/c-icap/distinfo
  head/www/c-icap/files/patch-c-icap.conf.in
  head/www/c-icap/files/patch-modules_memcached.c
  head/www/c-icap/pkg-plist
Comment 9 Rodrigo Osorio freebsd_committer freebsd_triage 2018-09-30 09:07:41 UTC
Commited thanks
Comment 10 Franco Fichtner 2018-09-30 09:34:48 UTC
Thank you for ignoring my contributions to this PR.
Comment 11 Rodrigo Osorio freebsd_committer freebsd_triage 2018-09-30 09:44:50 UTC
You have the full credits for the c-icap-modules. Isn't that enough ?
Should I put your name in uppercase ?
Comment 12 Franco Fichtner 2018-09-30 09:47:37 UTC
Save your jokes. I added patches for 0.5.4 and 0.5.5 while waiting for you to commit and I do appreciate Renato's cleanups, but discarding "Submitted by:" is a rookie mistake.
Comment 13 Franco Fichtner 2018-09-30 11:11:50 UTC
Thanks, your lack of candour and empathy is useful to note for future interactions. I'm sure you enjoy being treated in the same manner as you treat others and I hope you will not hold others to standards that you refuse to meet.  :)


Cheers,
Franco
Comment 14 Rodrigo Osorio freebsd_committer freebsd_triage 2018-09-30 11:59:51 UTC
Dear Franco,

I'm not trying to mock you in any way and I really appreciate your contribution. 

Stops me if I'm wrong but the patch submitted by Renato comes with more improvements than yours. This doesn't mean your patch is bad, but if for the same issue someone submit a better patch we will pick it.

Hope this glitch doesn't stop you from contributing in the future.

All the best,
- rodrigo
Comment 15 Franco Fichtner 2018-09-30 12:02:13 UTC
So your reasoning is if I take *any* other open PR, modify the Makefile because of a style issue the submission by the original submitter is void?
Comment 16 Franco Fichtner 2018-10-02 11:28:51 UTC
c-icap writeup


Rodrigo,

From your lack of response I gather that you have realised your argument was not as well laid out as it could have been or simply don't care. Let me also tell you why this is the *worst experience* with a FreeBSD ports committer that I've come across since 2014 and therefore can't let this slide. Here's the full timeline for general reading pleasure.

You committed C-ICAP 0.5.3 in April 2018[1]. Nobody has given you much trouble or blame which is only fair considering the involvement of upstream in this issue, but doing so broke integration for OPNsense[2] and pfSense[3] for these newer versions. As you can see from [2] we have been at it since your commit. We brought this topic up with the C-ICAP mailing list[4]. Meanwhile, you had another open bug[5] first reported in April as well.

A silent couple of months followed until September. 0.5.4 and 0.5.5 came out which were tested and *both* submitted for you to review[6]. 15 days go by before you immediately committed a fix from another FreeBSD committer who added a very similar patch with a few cleanups on top. You failed to take into account that this patch may have included previous efforts, which were clearly laid out in the two weeks of existence of the ticket. They were committed as "Submitted by:  garga" and that was the end of it for you.

And you also never answered to [5] in the months June, July and August. Instead of looking into the issue, you've now opportunistically asked the user if the issue resolved itself?

In general, my concern is that we have a 3 months pause in urgency and then a generally sloppy approach to resolving the issues with no concern from you why we ended up here in the first place. And I don't care about bylines, but I care about process and a sense of urgency and professionalism to the task at hand so that no issue lays dormant for weeks and is then brushed over as if it was submitted yesterday and you have been all over it.

I understand that we are all busy and real lives get in the way, but it doesn't exempt or excuse you from not heeding the following things:

1. Talk to submitters as to what you are going to do given split choices against proposed changes or when conflicts arise, which have clearly arisen in [5] due to "more impovements". Renato himself called to his aid a rule previously that contributions that were opened earlier are the ones to be committed[7] which is in conflict with the action taken here. It makes no sense to me as an external contributor. And find the repeated involvement does not shed the best light on this.

2. Don't brush over submitter concerns after the fact. Admit your mistake. If you feel like it it doesn't hurt to say you're sorry this was handled in a suboptimal way.

3. Make sure an episode like this never repeats. The FreeBSD ports prosperity depends on it.

I would now like to add to your sentiment "Hope this glitch doesn't stop you from contributing in the future."

First of all, it's not a glitch. Your actions are raising multiple concerns over the fact that FreeBSD ports has many rules for external contributors, but some committers have no regard for process and correctness that is being forced upon externals in comparison.

Secondly, I'll continue pushing updates but have long lost faith in the "process" employed. In 2014 it would have been an honour to be a committer. In following years it would have been easier than wait for someone to help, to take burden off of other committers. Nowadays, I have to admit that my interest in this has completely faded so submissions are a mere courtesy to the user interests of the FreeBSD ports which cannot be left un- or underrepresented. I also feel the need to protect future contributions[8] in fear of doing them for no apparent reason if someone else submits them anyway, too.

More importantly Interactions like this alter the future forever. I would wish that this does not happen to others, especially newbies, contributing because it can just turn them away from FreeBSD to never return. It's up to you to make a difference here. I'm not seeing that at the moment so please prove me wrong.

Last but not least, this could have been avoided by showing at least a bit of empathy and maintainer spirit, but you decided to go the route of swiftly cherry-picking a submission that you can't even know wasn't based on the initial submission because you did not ask or talk or otherwise made an effort to separate the incoming submissions.

This is a singular incident in a rising battle for external contributors literally begging for committers to look at their patches in the port mailing list. These times are full of "Sponsored by" and "Submitted by" lines that are freely sprinkled by committers without regard where they originate from or how much time and effort they cost bringing forward. It's a growing challenge for you to be able to brush up your process and mentorship efforts to be able to sustain a happy pool of external contributors for a long term benefit of the FreeBSD ports ecosystem.


Cheers,
Franco

--
[1] https://github.com/freebsd/freebsd-ports/commit/a16970b72cc
[2] https://github.com/opnsense/plugins/issues/645
[3] https://redmine.pfsense.org/issues/8832
[4] https://sourceforge.net/p/c-icap/mailman/message/36303689/
[5] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227451
[6] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231377
[7] https://reviews.freebsd.org/D16366#348280
[8] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231839