<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div dir="auto" style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div dir="auto" style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div dir="auto" style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div dir="auto" style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div dir="auto" style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div dir="auto" style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div dir="auto" style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div dir="auto" style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hi Petr,<div><br></div><div>I’d like to retain stewardship of the project as a responsible oversight party but excited to onboard others whether that is in a smaller or larger time/responsibility commitment. If that becomes a blocker at some point we can re-discuss, it’s not my desire to entirely drop out of the project but I would like to enable others to do work without me in the critical path.</div><div><br></div><div>The main roadblock I have had (other than time) is that we don’t have a functional/integration test suite to verify patches are working correctly by exercising the publishing/browsing APIs against Avahi itself. In an ideal world I’d also love to CI against the Apple Bonjour Conformance Test and/or some other external implementations. So if anyone wants to work on or contribute something towards that goal I would be particularly appreciative as it would make for an easier time for both myself and others contributing smaller chunks of time to the project to be confident in the changes.</div><div><br></div><div>However I equally realise that merging patches that may possibly be broken but probably aren’t, and in the worst case releasing a fix for that, is distinctly better than not merging anything at all. So I don’t suggest we should block project progress on that goal, but it’s been a large factor in my confidence to spend smaller chunks of time merging things and it seems not unlikely others contributing smaller amounts of time may have face a similar difficulty.</div><div><br></div><div>One of the key bits of helpful feedback I had from Adrian is that for a 4 specific patches that people are hitting a lot but are also potentially high-impact he had already tested them in some sizeable and diverse deployments so that effectively solved the testing portion for those patches.</div><div><br></div><div>I see some discussion to that effect for the CI is already happening on GitHub, so that’s great.</div><div><br></div><div><br></div><div>I don’t want to set a bunch of arbitrary rules or guidelines up front unnecessarily, but two main things that are expectations I have on myself and would like to see also reflected by others are:</div><div><br></div><div>(1) Maintain respectful and non-conflictive discourse. I’d look to publish or adopt a code of conduct in the future to make more clear or explicit what that actually means.</div><div><br></div><div>(2) Maintain a backwards compatible (and/or versioned) API at the source, binary & d-bus level for the client library where possible unless there is a particularly good justification or reason we can’t.</div><div><br></div><div>Prime example for this is the change we made as part of <a href="https://github.com/lathiat/avahi/pull/175">https://github.com/lathiat/avahi/pull/175</a> for object oriented dbus wrappers (such as in Python) needing to have newly created d-bus objects not immediately start firing events after creation - as they they need to get a handle to the created object before they could subscribe to it’s events. We’d send events too quickly which were lost before the application could subscribe to them. </div><div><br></div><div>The ideal fix was an API break where you had to first Prepare the object and then “Start” it. So we added a new D-BUS API for that, but kept the old “broken” one-shot API for backwards compatibility and then also added a 10ms delay before events started firing on objects created with the old API to silently fix those old clients “most of the time” by delaying ourselves out of the race.</div><div><br></div><div><br></div><div>Thanks for the work you’ve done so far, I really appreciate it, and also a bunch of others at your call reviewing bits and pieces. The amount of work and testing outstanding has been a bit overwhelming so I am hoping the enthusiastic work by others will also enthuse and free me up to also contribute alongside more than I have been.</div><div><br></div><div>I have added permissions for Petr to the repository - if anyone else is also seriously interested in merge or bug editing permissions and you intend to spend a reasonable amount of time on that please e-mail me with some details on your intent and we can discuss.</div><div><br></div><div>In the mean time - For Petr or anyone else - If there is a specific item you want my attention on I’ve setup a rule to highlight specifically GitHub issues where I’m @mentioned so I can keep special attention on those (since there is so much comment traffic on the issues generally at the moment).</div><div><br></div><div>Hopefully that helps and will let us move forward a bit. Thanks again :)</div><div><br></div><div>Cheers,</div><div>Trent</div><div><br></div><div><br><div><br><blockquote type="cite"><div>On 21 Nov 2022, at 8:41 am, Petr Menšík <pemensik@redhat.com> wrote:</div><br class="Apple-interchange-newline"><div>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div><p>Hello Trent, Hi Adrian.<br>
</p><p>I understand you are busy elsewhere and your focus is not on
Avahi project. But there have been multiple people willing to help
on issue #388 [1], without any concrete reply. I would like to ask
you here, whether you would allow any other contributors a commit
access to the repository. If you have some conditions which a
potential co-maintainer has to meet, please say them aloud.</p><p>You said your are open to maintainers joining on, but haven't
said nothing about your conditions.<br>
</p><p>Both Debian and Fedora has not a short list of downstream patches
applied on top of the last Avahi release. Many issues are open and
not being worked on, pull requests are not commented on in months.
I think the offer of <strong>Neustradamus</strong> to move to an
organization is reasonable. Not sure if there is another way to
add commit rights to your personal repository.</p><p>We can fork your project and start merging those requests
manually. But it would be much easier if you could transfer
existing issues and pull requests to a common organization and
give permissions. If you want to be organization owner, fine, just
say it. Certainly you should be administrator there, your
expertise is vital. It seems a personal repository still allows
some ways to collaborate [2] with more people.</p><p>I think now we are missing mainly two things:</p><p>- a person with time to read issues and pull requests and
categorize them. Labels are a good thing and it would be nice to
prioritize bugs, grouping important and unimportant.<br>
- a person with the language understanding and commit access able
to merge</p><p>I messaged Adrian some time ago. He mentioned you talked, but no
change is visible to us. Still not a single comment, commit or a
label change. I have talked with Till Kamppeter on Ubuntu Summit
in Prague, he said you are just too busy and likely it would not
change anytime soon.</p><p>Would you be able to give some access to other collaborators
before the end of this year? I am willing to maintain a fork and
invite more people after the next year unless something changes. I
think the existing code is fixable, it just needs more eyes and
hands. If you have any vision how to allow that, please share it.</p><p>Kind Regards,<br>
Petr<br>
</p><p>[1] <a class="moz-txt-link-freetext" href="https://github.com/lathiat/avahi/issues/388">https://github.com/lathiat/avahi/issues/388</a><br>
[2]
<a class="moz-txt-link-freetext" href="https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-personal-account-settings/permission-levels-for-a-personal-account-repository">https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-personal-account-settings/permission-levels-for-a-personal-account-repository</a><br>
</p>
<pre class="moz-signature" cols="72">--
Petr Menšík
Software Engineer, RHEL
Red Hat, <a class="moz-txt-link-freetext" href="https://www.redhat.com/">https://www.redhat.com/</a>
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB</pre>
</div>
</div></blockquote></div><br></div></div></div></div></div></div></div></div></div></body></html>