Well, I feel like some of my existing questions have not received explicit answers like:
Additionally, it is possible to make contributions to the
vyos-buildrepo as well, where the image building aspect is what needs testing (I certainly have submitted a few PRs there). It seems like it’s essentially not possible to test changes to thevyos-buildrepo if not building against the current rolling release.
Let’s say hypothetically I would like to upstream my patches of newer PDNS recursor to sagitta, which will require PRs to both vyos-build and vyos-1x. Given there’s no way to build a sagitta image from scatch, how would I go about creating said PR. Now I am aware that one avenue for this specific case is to simply build against “current” and hope that backports just work, though I’d like a little more confidence in being able to test against the LTS (which I will be using) myself.
Another hypothetical feature I’ve been mulling over involves better coordination of IPv6 prefix handling between DHCP (ISC DHCP) and radvd, which would require the ability to custom build sagitta (given the DHCP server change). Upstreamed or not, this doesn’t seem to be possible right now given the current landscape.
Also for something like:
Additionally, in absence of any other responses, should we take it that the project’s stance is explicitly not looking for contributions from new contributors towards the LTS releases in that case?
If this comes across like an excuse, I sincerely apologize, but just as VyOS the project has no contractual or legal obligations towards me as an individual, contributors have the right to choose what projects are worth their time and effort to work on. Perhaps I may be missing stuff from the responses to prior queries, but I don’t really see clear guidance on what kind of contributions are welcome.
The statement put out by @dmbaturin:
We will keep improving the documentation on building VyOS from source, but it’s not a priority for us. We are also working on ways to provide access to LTS repositories to contributors.
But the rolling release is exactly as easy to build as it ever was, it’s more stable than it was ever before, and that’s all people need to start contributing. And if they are contributing, they are eligible for LTS image access through contributor subscriptions. That’s all.
in the announcements subforum here is a little bit more clear, with implication that contributors are expected to work against “current” until they are eligible for LTS images before considering working on LTS images. This would seem to imply that application for LTS images is now a necessary part of contributing.
Note: I am, at times, purposefully using the hypothetical “first time contributor” identity to solicit some answers that may have wider applicability than just myself.
At present, I am trying to gauge what the project’s official stance on external contributions are in order to better inform myself in terms of whether it’s worth the time working on this project.
If the project’s stance is antagonistic towards good-faith potential contributors, I find it harder to justify putting my time in upstreaming any bug fixes or patches. If on the other hand, the current state of the project is merely transient, where some explicit guidance is made towards defining what type of contributions are welcomed and what types of contributions are of a lower priority, I think people can have an easier time making their mind up about whether one submits merely a bug report versus authoring an entire PR with the relevant bug fix along with the bug report.
Once again I hope nothing above seems too opinionated or seem too much like an “excuse”, the goal is to get clear, official information out in a format that people can read and understand. I don’t claim my existing contributions are significant but hopefully they are not trivial so that you may some faith that I’m not trying to con my way into getting some sort of special treatment or access, but rather to merely get clarity for myself (and anyone else that might read this thread).