Re: Formalizing teams
Hi Ludovic, Ludovic Courtès writes: > Hello Guix! > > I’ve been looking at our guix-patches backlog, at the great > contributions we get but that stick there for too long, certainly > discouraging people, and also at non-code initiatives (meetups, Guix > Days, Outreachy, documentation, etc.) that we as a project could often > support and encourage better, wondering how we could improve. I think we're not doing too badly considering the tooling we have at our disposal, but yes, there's definitely room for improvement! [...] > One idea that I like is to bring structure to the group, or rather to > make structure visible, so that newcomers know who they can talk to to > get started on a topic, know who to ping for reviews, and so that each > one of us can see where they fit. Rust has well-defined teams: I've grown to like our apparent lack of structure; we interact globally on any topic of interest and the discussions all happen in a shared space, which makes it easy to stay informed with everything that's going on (do we really need more mailing lists to follow? I don't think so -- our current volume doesn't warrant it). > Guix is nowhere near the size of the Rust community (yet!), but I can > already picture teams and members: > > co-maintainers (“core team”) > community > infrastructure > internationalization > security response > release > Rust packaging > R packaging > Java packaging We'd have to include every language/system of importance to that list (Python, Ruby, Emacs, LaTeX, Perl, etc.), no? > In Rust, teams are responsible for overseeing discussions and changes in > their area, but also ultimately for making decisions. I think that’s > pretty much the case with the informal teams that exist today in Guix, > but that responsibility could be made more explicit here. They > distinguish teams from “working groups”, where working groups work on > actually implementing what the team decided. > > How about starting with a web page listing these teams, their work, > their members, and ways to contact them? Teams would be the primary > contact point and for things that fall into their area and would be > responsible for channeling proposals and advancing issues in their area. > > What do people think? Are our problems really organizational? I think before attempting to come up with a solution, we must analyze and agree on what it is that needs improvement to help us move forward more efficiently. Thanks for initiating the conversation, Maxim
Re: Browsers and Gstreamer plugins
Hello Jack, Thank you for posting this well written piece here. Jack Hill writes: > Hi Guix, > > While we have made progress on #52375 [0], the way forward remains > unclear. In summary, WebKitGTK expects certain GStreamer plugins to be > available. Depending on which plugins are missing and the web page > content, the process corresponding to a browser tab may even crash. > Currently, we expect folks to manually install the necessary plugins > into their profile/environment. That sucks; but it really is webkitgtk/browsers' fault; they should have better reporting so that users know what is missing instead of obtusely crashing a tab. > Complicating matters, it is not clear to me which plugins WebKitGTK > needs or optionally makes use of. At least some of the needed plugins > are from gst-plugins-bad, which upstream considers to be of lesser > (code) quality [1]. gst-plugins-bad is also a large dependency. Adding > it would increase the closure size of browsers by almost 1GiB! > > [0] https://issues.guix.gnu.org/52375 > [1] > https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/ca8068c6d793d7aaa6f2e2cc6324fdedfe2f33fa/README#L80 1 GiB for code deemed of even worst quality than even the 'ugly' plugins (they're literally at the bottom of the chart, quality-wise) doesn't sound too appealing :-) [0]. [0] https://raw.githubusercontent.com/GStreamer/gstreamer/master/README > I believe that what I have written above is more or less factual. Now > for my opinion: I think that we should make browsers work out of the > box on commonly-encountered web content. How would you define "commonly-encountered" web content? How will we handle bug reports of "tab crashed on site X" because a plugin we thought obscure is used by someone? It's a bit of a slippery slope where we may end up wrapping all/too many plugins, because of the issue I raised in my preceding paragraph (bad reporting from webkitgtk itself). Plugins exist for the very reason to allow end users to extend functionalities the way they see fit, so it seems a bit backward to me to "wrap plugins in", which makes them non-optional onto users. On other systems, they are typically "recommended" but not wrapped in a way that makes it difficult for users to opt out of them. > To that end, I propose that > we wrap WebKitGTK-powered browsers so that they can find the necessary > plugins. I have attached a proof-of-concept patch that does just that > for Vimb. I used the gst-plugins/selection procedure [2] to to add > just one plugin from gst-plugins-bad that fixed the crash I was seeing > in #52374. > > Size comparisons: > > Existing Vimb: 1397.5 MiB > Vimb with my patch: 1409.9 MiB > Vimb with all of gst-plugins-bad: 2298.6 MiB This looks reasonable, space wise. > Of course this is just the bare-minimum set of plugins. We may want to > work with WebKitGTK upstream to determine any additional ones that we > should be including. > > [2] The patch depends on the fix for gst-plugins/selection that I > submitted in https://issues.guix.gnu.org/52730 > > A note on the approach of wrapping browsers rather than somehow > including the plugins in WebKitGTK. It is much more obvious and > straight forward (to me at least) to wrap the browser executable. Also > WebKitGTK could in theory be used to render content that comes from a > controlled environment, not the web, and therefore doesn't need the > "web plugins". A downside to doing it this way is that each browser > would need to be wrapped in the same set of plugins. Perhaps we can > factor that out so that the plugin list only has to be maintained in > one place. > > > Questions and comments? How shall we move forward? Is it ok to wrap > browsers in this way? I sympathize with the goal of improving our users experience (by shipping browsers that don't crash mysteriously left and right), but I'm not satisfied with the solution of wrapping plugins. Could we instead try to fast-forward work that has happened in webkitgtk to produce better diagnostics about missing plugins? Such as [1], which has a patch (with comments on). It's not a panacea, but having errors about missing plugins/functionality appear on stderr would be an improvement. We should also create tickets upstream in webkitgtk-based browsers requesting that they report missing plugins gracefully in their user interfaces. [1] https://bugs.webkit.org/show_bug.cgi?id=233949 If all this is done and documented and in the waiting queue, then we could proceed with wrap browsers with a minimal set of plugins as a stopgap/temporary measure until the upstream issues get resolved. What do you think? Thanks, Maxim
Re: Release v1.4 (or 2.0): process and schedule ?
Hi Vagrant, Vagrant Cascadian writes: > On 2021-12-19, Maxim Cournoyer wrote: >> zimoun writes: >>> Now core-updates-frozen is merged. Now The Big Change [1 ]is done. Do >>> we go for v1.4 or v2.0? >> >> As I've mentioned previously, I'd go for a 1.4.0 release, since overall >> we've refined and improved (greatly!) what we already had rather than >> introduced something revolutionary. I'd keep a 2.0.0 for when we have >> p2p distributed substitutes, a custom graphical tool and/or integration >> with the 'Software' application in GNOME, this kind of big user-facing >> changes. But that's just my personal opinion :-). If the majority >> feels a 2.0.0 is more suitable, I won't mind. >> >>> In both case, what is the target for a release date? I propose January >>> 31rst. WDYT? >> >> I'd like to fix #52051 before issuing the first release candidate (RC). >> Assuming this can be made before the end of January with the first RC >> coming out around New Year, and that the kind of collaboration I've seen >> in the last weeks continues at the same intensity, this seems >> achievable. > > Would it be appropriate to fix the ~700 low-hanbging fruit issues that > are identified by: > > guix lint --checkers=description,synopsis > > It is not the most exciting work technically, but it is relatively easy, > and low risk, maybe the worst it does is put a bit more work on > translators... > > Maybe there are also other low hanging fruit guix lint knows about that > would not be particularly disruptive? > > It is not particularly urgent for a release, per se, but I suspect it > will just grow and grow without some sort of cycle to address such > trivial issues... and doing such cleanup before making a release would > aim for a higher standard of craftspersonship. :) About the current status, I'm nearing on pushing a version-1.4.0 branch which is based on master with a few more (core-ish) updates. There's still a few days ahead of that, so if you manage to get many of this kind of problems fixed & merged in master they can easily be included in the next release. HTH, Maxim
Re: How to test modified shepherd services
Hello, Simon South writes: > Nathan Dehnel writes: >> I modified a shepherd service to accept a new field from config.scm >> and I was wondering how to test that it works correctly. > > Assuming this is an existing Guix service, it's probably easiest to > update the corresponding system test suite under gnu/tests (if > necessary) to reflect your change, then run the suite with "make > check-system" (setting "TESTS" to limit it to the service in question) > to make sure everything works the way you expect. > > If you're planning on contributing the change to Guix it would be good > to submit it along with an updated test suite anyway. > > The Guix manual has a bit of information about this in Section 2.3, > "Running the Test Suite": > > https://guix.gnu.org/en/manual/en/html_node/Running-the-Test-Suite.html#Running-the-Test-Suite +1. System tests are the best way to validate system services. You'll save time by writing/extending one. Maxim
