To whom this may concern, The following PR showed vividly what I've been seeing for a long time on this list and while working with FreeBSD ports.
I'm attaching my last response here because it may be important for some to see, even if it's being brushed off. ===> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231377 >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 _______________________________________________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
