-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should yanic be also a respondd daemon #156
Comments
mesh_announce did just get full multidomain support. ffnord/mesh-announce#47 Please test and report your findings. |
Nice but my main problem is that my babel support is not merged over years - so I often have to rebase it. The multidomain support and his unreviewed broken PRs was just a symptom that For me it is/was easier to write some modules here the most logic I have already to parse it. |
Well, I'd love to get babel support merged. A primary issue with your support PR is that it does neither have a descripton nor any documentation for the changes applied. |
firstly imo meshannounces major rewrite made it way better. On the other hand, I really like software that does one job, but one job well. For me it'd be quite a drawback if this became loaded with redundant features. |
I really like the feature and we are using it since a while in our community. IMHO it is not a problem if yanic can work as collector and respondd. |
The https://github.com/ffnord/mesh-announce design of code become more and more unusable.
(e.g. no multidomain support possible - ffnord/mesh-announce@01de2c5)
Maintaince become worse:
Issues not closed or discussed. (PRs are merged without discussion - ffnord/mesh-announce#41)
All this are reasons to make a fork or rewrite
yanic has a lot of need sourcecode /packages already - becouse it collects already thows data
The text was updated successfully, but these errors were encountered: