Hi Sergio,
Sergio Pastor Pérez <sergio.pastorpe...@outlook.es> writes:
Hello Ian.
I cannot help you since I don't have commit access. But I want
to thank
you for your hard work, I'm currently using your package.
Thank you for the kind words, they truly mean a lot to me.
Whatever the state of Guix proper, you can always find the current
version of LibreWolf in my personal channel[1], though I don’t
have a public substitute server, so long build times will await
you if you choose this route.
We should try to come up with a solution that alleviates the
burden on
the maintainers. Given how often this issue arises, what if we
try, as
a collective, to suggest new mechanisms that would improve the
situation?
If I recall correctly, someone suggested having a development
branch in
which, once the QA passes, the patches get automatically
merged. I know
some people rose concerns about the slowness of the QA system
for this
to be an effective solution, and there is also the issue
ordering the
patch application.
If the previous solution is ruled out, I would like to know the
opinion
of the Guix community on a voting system. I'm imagining a system
where
we reuse the mailing infrastructure we have, where each accepted
mail in
the guix devel mailing list has 1 vote for a given patch, that
way we
avoid multiple votes from the same entity and would allow people
without
commit access, but active on the Guix development, to
participate. So,
we could set up a threshold where if a patch gets 10 votes from
non-committers the merge would be done; preferably automated,
but if it's
not possible, committers would know what is ready to be merged
without
effort and what the community wants.
I’m not sure this would be effective, because the QA service is
unreliable. I regularly see patches which simply don’t get picked
up by it, including many of my own. At other times, it lags very
far behind. I don’t think it’s reliable enough to be in the
critical path for anything. Guix is supposed to be a
rolling-release distro, so it feels strange to have a develop
branch which moves even faster.
Thanks,
— Ian
[1]: https://codeberg.org/ieure/atomized-guix
