lathiat
Is Avahi abandoned? New maintainer?
@lathiat - can you confirm that you have now abandoned further development and maintenance of Avahi, as appears to be the case?
While I interpret no response from you = confirmation of abandonment, judging by the number of recent PRs submitted I would urge you to say so definitively. Otherwise people are putting in a significant amount of work to PRs that will never go anywhere. This is disrespectful to others' time, especially since a 1-line post here saying 'I have abandoned Avahi' would take less than 20 seconds of yours.
If you have abandoned Avahi, please tell us. In that case, also please tell us whether you would be willing to hand the repo over to a new maintainer, should someone volunteer (which I think is highly likely).
It’s not abandoned but there is a solid shortage of time spent currently that I hope to rectify.
I’m open to contributing maintainers joining on
@lathiat - that's great to know - thank you.
If it's helpful, I volunteer to be a maintainer. I do not have much experience with the avahi-autoipd side, however, I am the maintainer of a private fork of avahi-daemon which is used on a commercial IoT device. This fork incorporates a number of open PRs on this repo, along with other fixes (principally to work around IPv6 router bugs), which address many frequently reported issues posted here and is running on ca. 100K devices 'in the field'. So I can at least vouch for specific existing PRs as being effective and unlikely to introduce side effects, and/or submit new PRs with some additional fixes, if this is helpful.
That sounds great. Can you shoot me an e-mail with a way to get in touch with you (twitter/irc/something) so we can have a chat?
Reviewing/testing the PRs is one of the bottle necks so if nothing else if theres something you've validated in the field im happy to take that as a +1 to just merge it.
Sure thing! Happy to go through what I’m running in the field with you, and so we can pick some low hanging fruit / well tested PRs to get merged. I will reach out.
@adriancable Maybe one quick action to take now is to label #243 not as an enhancement, but as a bug! This issue keeps hitting people in my development projects. And the specifications are quite clear I think on what the implementation should do. And for the same reasoning #269 can be rejected, I believe.
Hi, I would like to contribute if it was possible. But I think this is not the best communication platform. Is there a reason, why is avahi mailing list dead? I would volunteer to occasional moderation if needed. But can I suggest opening that mailing list as a start? Some place we could discuss changes would be nice. Can you please open mailing list to automatic registration, because @lathiat clearly does not have time to manage it manually.
Thanks for opening the mailing list. It is now open to new people, tested: https://lists.freedesktop.org/archives/avahi/2022-October/thread.html
It is possible to move in an organization place to the future developement?
- https://github.com/avahi
Note, I have done a long time ago:
- https://github.com/lathiat/avahi/issues/245
- https://github.com/lathiat/avahi/issues/258
- https://github.com/lathiat/avahi/issues/325
- https://github.com/lathiat/avahi/issues/335
@lathiat: Can you do the transfer for the future?
I think that you can do for nss-mdns too.
cc: @adriancable and @pemensik.
I have prepared a list of candidate bugs on wiki page. Most of them looks just right. Can somebody else look at them, maybe rate their importance too? I think we definitely want to merge the CVE soon. Is there anyone else, who can assign labels to PR and issues?
@lathiat: After several weeks, several months, it is possible to look for the move/transfer?
It is really easy to do it, at the bottom:
- https://github.com/lathiat/avahi/settings
- https://github.com/lathiat/nss-mdns/settings
Push the "Transfer" button...
Thanks in advance.
@pemensik You mention a list of bugs on the Wiki - do you mean the links to the list of patches there? (Or should I be looking elsewhere?) I could label issues but the project would need to be located somewhere with an active maintainer so that people can be given rights to e.g. apply labels, close issues, and such. Maybe discuss further on the mailing list?
I have just received commit rights. @adriancable has them as well, as I can see. I will try to review pending pull requests. If you had any changes needed, please create a pull request if it does have some already. Ping me if you have anything important.
@pemensik: Now we wait the transfer to the organization... @lathiat: Do not forget to do it!
I will try to review pending pull requests.
@pemensik I wonder if it would make sense to set up some sort of CI first. As far as I can see there are quite a few PRs waiting to be merged but they don't seem to be even compile-tested anywhere. It seems avahi was built on Travis CI back in the day but now that it's gone the CI is no longer functional. I mostly care about various static analyzers and fuzzers (and I opened https://github.com/google/oss-fuzz/pull/9107 to be able to keep the fuzz targets closer eventually) and can bring CodeQL and Coverity if anyone is interested but I think some CI jobs simply compiling avahi and running its three unit tests on various architectures (using say Packit) should probably be up and running before PRs get merged to avoid breaking builds downstream at least. Just my 2 cents.
@evverx I agree that a CI would be very useful here. For example just the standard CI that Github offers already has a lot of features. Here's an example of a pretty advanced cross-platform build definition as part of standard Github CI: https://github.com/openthread/openthread/blob/main/.github/workflows/build.yml
Yes, it turns the avahi code is not as straight forward as it seemed. At least basic checks done on pull requests would be nice. If we could create at least basic functional tests, it would be even better. There were some PR I marked with CI label. But I would create separate issue for it. I think CI is important enough to have separate issue. This issue were about entirely different thing.
But I would create separate issue for i
Makes sense.
This issue were about entirely different thing.
I commented here because to set up some things like Packit for example it's necessary to have admin access to the repository so in a way it boils to down to whether there are active maintainers with this kind of access. My understanding is that all the new maintainers have only commit access and that isn't enough to change any repository settings affecting CI among other things.
Here's an example of a pretty advanced cross-platform build definition as part of standard Github CI
@EskoDijk Thanks! I suggested Packit because there almost all architectures apart from armhfp and probably ppc64le are native. On GitHub almost all GHActions like that boil down to spawning QEMU VMs or multi-arch containers (usually boiling down to qemu-user as well) and depending on the project it can lead to annoying issues like https://gitlab.com/qemu-project/qemu/-/issues/1248. It's just easier to build stuff natively. Anyway let's move this discussion to #412.
Hello all,
I do not arrive to speak with @lathiat, same to you?
He is on Twitter too: https://twitter.com/lathiat.
The future of Avahi and nss-mdns is now...
@Neustradamus I think all the questions regarding the state of the repository were answered on the mailing list in https://lists.freedesktop.org/archives/avahi/2022-December/002587.html.
Yeah, that mailling list post was the main update. I am excited by the activity from various people :)
3 main outstanding requests of relevance:
- Commit access requests from @evverx and @Neustradamus
- Moving the avahi and nss-mdns repositories into a GitHub org
(the combination of those two will assist the comment from @evverx needing admin access for packit etc)
I will handle those soon.
@Neustradamus it's probably a weird question but I'm just curious. I wonder if you are planning to review/merge PRs/change repository settings? I' just trying to figure out why commit access is necessary. Assuming https://github.com/avahi-project was created by you it would also mean that if this repository was transferred there you would have full admin access with access to advisories and stuff like that.
The main goal is to have a nice future for avahi and nss-mdns!
Several projects have been already saved from the death.
For information, Debian 12 freeze is very soon.
@lathiat: The devel will be better if avahi and nss-mdns will be in the new place!
- https://github.com/avahi
Several months have been lost...
Too late for Debian 12.
Several projects have been already saved from the death.
I'm not sure how moving stuff around can help with anything. The problem is that at this point nobody (apart from @pemensik) tries to review PRs/triage and fix bugs and so on. On top of that there is no adequate testing infrastructure and that makes it really hard to actually do anything without introducing even more bugs. (I brought some pretty basic testing stuff but it isn't enough to test non-trivial features like monotonic timers for example).
I think that this repository should just be converted into a public archive to make it clear that it isn't maintained any more. Downstream consumers that claim that they actually support avahi can always fork it and if their fork isn't dead everyone can switch to it.
I brought some pretty basic testing stuff but it isn't enough to test non-trivial features like monotonic timers for example
Just to expand on that I hooked up the repository to Coveralls in https://github.com/lathiat/avahi/pull/461 and https://coveralls.io/builds/60369370 shows that approximately 10% is covered at this point. What I'm trying to say is that in terms of saving avahi it would be much more important to start covering it with tests to make it easier for reviewers and contributors to make sure that stuff works and regressions aren't introduced. PRs are welcome as usual.
Another way to help would be to go over https://scan.coverity.com/projects/avahi-daemon and help to fix some of those issues. I can give access to it if anyone is interested.
I have added @evverx as a contributor. @Neustradamus seems just motivated to keep the project going but not really to be involved in PR reviewing/merging so will not add them but if that changes let me know and we can discuss further.
@lathiat thanks! I think it would be great if @mbiebl could be invited too to represent Debian (if it's something @mbiebl is interested in of course). The "collaborator"/"member" tag helps with reviews in the sense that those reviews can be blocking for example. @EskoDijk helps with various RFC corner cases. Then again I'm not sure if @EskoDijk is interested in that. It's just some stuff based on my observations.
@lathiat: Thanks to have added @evverx.
An exemple of the current problem, you can see that the code is in your personal account (Avahi and nss-mdns).
You can see that I have permit 2 releases for PPP and active development: https://github.com/ppp-project/ppp And one release and a not abandoned developement for radvd: https://github.com/radvd-project/radvd