<div dir="ltr"><div dir="ltr"><div dir="ltr">On Thu, Feb 14, 2019 at 9:58 PM Till Kamppeter <<a href="mailto:till.kamppeter@gmail.com">till.kamppeter@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 14/02/2019 18:49, Kurt Pfeifle wrote:<br>
> This is not correct.<br>
> <br>
> Avahi was initially created by Trend Lloyd in early 2004. He was <br>
> certainly inspired by Apple's Bonjour, which unfortunately was not Open <br>
> Source initially, so there as a strong motivation to implement a FOSS <br>
> ZeroConf stack, since all of the relevant specs (mDNS + DNS-SD) were <br>
> already there at IETF, and open.<br>
> <br>
> Later that same year Lennart Poettering started a similar project to <br>
> implement mDNS/DNS-SD functionality called "FlexMDNS".<br>
> <br>
> Both projects united and merged their code bases sometime in 2005. <br>
> Though I have no idea which of the two guys wrote more lines of code <br>
> that still exists in today's code base, Poettering surely had a heavy <br>
> impact on today's Avahi.<br>
> <br>
> Apple released Bonjour as Open Source software under the Apache License <br>
> only in 2006.<br>
> <br>
> Avahi's name certainly was Trend's decision, and he started his <br>
> implementation half a year before Poettering.<br>
> <br>
> Poettering's last commit into Avahi's GitHub code was in Sept 2012. <br>
> Trend's last commit was 10 days ago. The last time Trend merged a major <br>
> pull request was in August 2018. See <br>
> <a href="https://github.com/lathiat/avahi/commits?author=lathiat" rel="noreferrer" target="_blank">https://github.com/lathiat/avahi/commits?author=lathiat</a>.<br>
> <br>
> According to <a href="https://github.com/lathiat" rel="noreferrer" target="_blank">https://github.com/lathiat</a> Trend works for Canonical.<br>
> <br>
<br>
That is interesting to know. Now I understand why Trent does not like <br>
that someone will take the project away from him.<br></blockquote><div><br></div><div>In any case, starting at the last link I provided, this leads, within 5 minutes to...</div><div><br></div><div>* ...his info that he works for Canonical,</div><div>* ...an email address registered by Trent with GitHub,</div><div>* ...a website run by him showing his Twitter handle,</div><div>* ...confirming his Canonical association info,</div><div>* ...showing his frequent Twitter activity.</div><div><br></div><div>In the same time span spent at <a href="https://github.com/lathiat/avahi/issues">https://github.com/lathiat/avahi/issues</a> I </div><div>could not identify...</div><div><br></div><div>* ...any bug reports related to problems created by Avahi shortcomings</div><div> for CUPS printing as mentioned before,</div><div>* ...any pull requests submitted at GitHub to solve these problems.</div><div><br></div><div>But maybe I was not aware of what I should search for....</div><div><br></div><div>However I noted the following Avahi statistics on GitHub:</div><div><br></div><div>* 81 open vs. 43 closed Issues.</div><div>* 39 open vs. 55 closed Pull Requests.</div><div><br></div><div>So indeed, the activities on Avahi have slowed down in recent years.</div><div>But it is not the case that Trent is missing from planet earth or turned</div><div>un-interested regarding computer-related topics.</div><div><br></div><div>So my advice would be the following:</div><div><br></div><div>* Create the relevant bug reports ("issues") for Avahi on GitHub.</div><div>* Create the most wanted feature requests for Avahi on GitHub.</div><div>* For each bug and feature supply a pull request on GitHub.</div><div>* Upvote/comment/like/discuss these new activities on Avahi's GitHub.</div><div>* Contact Trent via Twitter (where he seems most responsive) about </div><div> the Github issues and ask for his comments.</div><div>* If he does not show any willingness to integrate well done pull</div><div> requests, then only seriously consider a fork on the project. Y'all</div><div> will have an easier way to convince people about the need for </div><div> such a drastic step, if your PRs are sitting there for too long. Also</div><div> a fork will have a headstart, if the code to add/improve is already</div><div> waiting there, well-tested.</div><div><br></div><div>Don't just jump into such an adventure based on rumours, un-prepared and without your troops well-equipped.</div><div><br></div><div><br></div></div></div></div>