Hi Petr, 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.
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. 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. 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. I see some discussion to that effect for the CI is already happening on GitHub, so that’s great. 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: (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. (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. Prime example for this is the change we made as part of https://github.com/lathiat/avahi/pull/175 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. 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. 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. 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. 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). Hopefully that helps and will let us move forward a bit. Thanks again :) Cheers, Trent > On 21 Nov 2022, at 8:41 am, Petr Menšík <pemen...@redhat.com> wrote: > > Hello Trent, Hi Adrian. > > 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. > > You said your are open to maintainers joining on, but haven't said nothing > about your conditions. > > 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 > Neustradamus to move to an organization is reasonable. Not sure if there is > another way to add commit rights to your personal repository. > > 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. > > I think now we are missing mainly two things: > > - 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. > - a person with the language understanding and commit access able to merge > > 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. > > 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. > > Kind Regards, > Petr > > [1] https://github.com/lathiat/avahi/issues/388 > [2] > 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 > > -- > Petr Menšík > Software Engineer, RHEL > Red Hat, https://www.redhat.com/ > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
