Re: [PATCH v2 0/1] services: network-manager: Add extra-configuration-files field.
Attila Lendvai writes: >> instead of calling for >> the proliferation of private channels, a different kind of unmanageable >> structurelessness. > > not private channels, simply channels that are not owned/controlled by > the exact same set of committers as guix proper, and not demanding the > exact same requirements from their contributors. > > this may seem like nitpicking, but i think it's an important detail in this > context. Thanks for the correction. I did mean personal channels, i.e. operated (or abandoned) by a single person. The guix-science collective demonstrates an alternative model, where people of similar interest band together to provide a channel (or set of channels) that is governed by different rules than Guix itself. This started out as a set of independently run channels (guix-bimsb, guix-bimsb-nonfree, guix-science, guix-science-nonfree, guix-hpc, etc) and is now a much more streamlined and cohesive shared effort. I would advise against running a multitude of personal channels in favor of collaborating with others on a much smaller number of channels -- and ideally as a team in Guix itself. -- Ricardo
Re: Non-committers can't keep authenticated forks updated
On 2025-01-16 15:34, Liliana Marie Prikler wrote: >> The complexity is due to the requirements of not bumping the channel >> introduction (to avoid the increased attack surface from having to >> keep obtaining the updated one, as I discussed earlier), keeping fork >> history intact (to avoid force pulls), keeping upstream history >> intact, and being able to authenticate both upstream and fork >> commits. If you can think of a simpler method that meets these >> requirements, I'd love to hear it. > Guix committers are more than happy to use work trees and rebases, > which simplify this a lot – again, it's as simple as pull, > authenticate, rebase. > > W.r.t. keeping history intact, we had the following exchange on IRC > yesterday. > > lfam: that's interesting that there is really a merge > commit, for example if I remember right, the core updates merge few > months ago happened by directly appending the commits instead of a > merge commit > Yes, there are two ways to do it (rebase and merge) and it's a > matter of taste > Of course there is a correct choice, as with all questions of > taste ;) > I personally prefer a merge commit, since it has two > parents, you can track where the previous master pointed to > And I prefer a rebase. But ultimately it's up to whoever is in > front of the keyboard >FWIW, a rebase is cleaner, but requires that only one person > signs off commits on any given branch (or else you're signing commits > that someone else signed before and have to update the trailer… not > ideal) > It doesn't matter who signs the commits as long as they are > authorized. That's the security model we have > > So yeah, even for (branch-)local work at least some committers prefer > rebasing. > A lightly-related comment : I recently started a guix extension to help manage complexities of maintaining guix soft-forks. I haven't advertised it yet, and I'm fine authenticating locally for now. I mainly focus on reproducibility of patches sent (recording where patches are sent to be able to generate a list of patches from a repo) and pulling from patched channels. There still some work ahead before I can even advertise it properly, but feel free to take a look! There's no doc yet. https://git.sr.ht/~ngraves/guix-stack -- Best regards, Nicolas Graves
Survey: Pinging Neglected Patches
Hi Guix, I have seen different opinions [1][2] regarding sending pings to patches that aren't getting reviewed or are otherwise lacking attention. To get a better idea of peoples' opinions, I've created a survey. Please do take it, it's only two questions long. https://sneakmonkey.limesurvey.net/286966?lang=en I think it would be good for Guix to have stated guidelines on this subject, so that everybody knows in advance what is considered acceptable and what isn't. Right now it is difficult for a new contributor to judge whether sending a ping will help or not. Hopefully the survey is a step in the right direction. Thanks, 45mg P.S. Regarding the option 'To a dedicated thread or list meant for pings (hypothetical)': I was thinking along the lines of NixOS's monthly 'PRs ready for review' threads [3]. [1] https://lists.gnu.org/archive/html/guix-devel/2025-01/msg00072.html [2] https://lists.gnu.org/archive/html/guix-devel/2025-01/msg00100.html [3] https://discourse.nixos.org/t/prs-ready-for-review-december/1711
Re: Survey: Pinging Neglected Patches
Am Freitag, dem 17.01.2025 um 09:32 + schrieb 45mg: > Hi Guix, > > I have seen different opinions [1][2] regarding sending pings to > patches that aren't getting reviewed or are otherwise lacking > attention. > > To get a better idea of peoples' opinions, I've created a survey. > Please do take it, it's only two questions long. > > https://sneakmonkey.limesurvey.net/286966?lang=en > > I think it would be good for Guix to have stated guidelines on this > subject, so that everybody knows in advance what is considered > acceptable and what isn't. Right now it is difficult for a new > contributor to judge whether sending a ping will help or not. > Hopefully the survey is a step in the right direction. For context, I already took the survey, but here are some comments that didn't quite make the cut for lack of a free-form field with additional concerns: 1. You should only ping a contribution that require action from committers/reviewers to be pushed forward. Do not ping contributions that have received reviews on which you haven't acted yet. 2. You should not automate the process of pinging old bugs, but instead ping issues that are still important to you after the delay has elapsed. 3. If possible, send updated patches rather than pings. For instance, if your commit that bumps libfoo to x.y.z hasn't received attention, you may still, without review, submit a v2 that bumps it to x.y.z+1. Likewise, you may improve code style, etc. to keep your patch fresh. 4. Avoid contextless pings – do provide information for readers to move your patch forward. 5. Make sure that the right people are informed. (For example, consult etc/teams.scm) Hope that helps ;)
Re: [PATCH v2 0/1] services: network-manager: Add extra-configuration-files field.
> instead of calling for > the proliferation of private channels, a different kind of unmanageable > structurelessness. not private channels, simply channels that are not owned/controlled by the exact same set of committers as guix proper, and not demanding the exact same requirements from their contributors. this may seem like nitpicking, but i think it's an important detail in this context.
Re: Survey: Pinging Neglected Patches
Hi Liliana, Thanks for taking the survey! Liliana Marie Prikler writes: > For context, I already took the survey, but here are some comments that > didn't quite make the cut for lack of a free-form field with additional > concerns: I had assumed the 'Other:' option could be used for additional comments, but I didn't realise just how tiny its text box would be; can't blame you for not wanting to type into that. And it doesn't look like I can modify much without stopping the survey. Oops x~x For anyone else taking the survey - you could always type out detailed comments (if you have any) in your favourite text editor, then paste them into that text box. There doesn't actually seem to be a limit on how much text can go in there; it's just hilariously bad UI on LimeSurvey's part. Which is a phrase that basically sums up my experience with that site :P Still, my bad there, sorry.
Re: Guix Days and Fosdem 2025
Hello, > Registration for Guix days is closed because we have 60 people signed > up. Sadly we can only handle so many. If you changed your mind, you > can remove your name from the list so we can let someone in. In such a case please put me on the list. Thank you. Cheers, Bost
Re: Guix Days and Fosdem 2025
> Im marked down for two days, but I will be going to the Friday event (im > going to a community metrics event on the Thursday). > Also Im stepping out for a lecture at 230 PM on the Friday. > > Perhaps whoever has the stamina to navigate the buggy FSF site can > update that detail, so that they can add their own name as a Thursday > attendant? > > https://libreplanet.org/wiki/Group:Guix/FOSDEM2025 Thanks Jonathan. I put my real name on the list. (Whatever "real" means ;-) Cheers, Bost
Re: Guix Days and Fosdem 2025
Im marked down for two days, but I will be going to the Friday event (im going to a community metrics event on the Thursday). Also Im stepping out for a lecture at 230 PM on the Friday. Perhaps whoever has the stamina to navigate the buggy FSF site can update that detail, so that they can add their own name as a Thursday attendant? https://libreplanet.org/wiki/Group:Guix/FOSDEM2025 I see there are currently 6 attendees marked for only one day (plus me) - so I posit that we are still technically below the limit. On 2025-01-17 17:26, Rostislav Svoboda wrote: Hello, Registration for Guix days is closed because we have 60 people signed up. Sadly we can only handle so many. If you changed your mind, you can remove your name from the list so we can let someone in. In such a case please put me on the list. Thank you. Cheers, Bost Jonathan McHugh
Re: Guix Days and Fosdem 2025
Cool, ... Im still trying to work out what day of the week that the Day `futurile` occupies... On 2025-01-17 18:14, Rostislav Svoboda wrote: Im marked down for two days, but I will be going to the Friday event (im going to a community metrics event on the Thursday). Also Im stepping out for a lecture at 230 PM on the Friday. Perhaps whoever has the stamina to navigate the buggy FSF site can update that detail, so that they can add their own name as a Thursday attendant? https://libreplanet.org/wiki/Group:Guix/FOSDEM2025 Thanks Jonathan. I put my real name on the list. (Whatever "real" means ;-) Cheers, Bost
Re: Non-committers can't keep authenticated forks updated
Saturanya Rahjane de Lasca writes: >> Again, not disputing that things work fine for people with commit >> access. Perhaps that is part of why this issue hasn't been addressed >> before :P > You may call us privileged – and yes, we are – but that doesn't change > the fact that weakening security weakens security. Just to be explicit here, this whole thread was motivated by desire to simplify soft-forks while keeping the same level of security. No one here is arguing for weakening it. Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: Non-committers can't keep authenticated forks updated
Liliana Marie Prikler writes: >> All of these things discussed in this thread are technically >> possible. But I think that we all agree that the friction involved, >> compared to just using my own fork with the patch applied, is much >> larger, at least in my opinion. > Yes, we can agree that this is your opinion. We can even agree that > there is more friction, but I'm not sure whether we agree on the value > of "much". But honestly speaking, the friction with contributing to > upstream is much more a social one (too few people to review) than a > technical one, and soft forks are a band aid that will likely burn you > out even sooner the more you commit to them. I do not know what the future holds, but introduction of my soft-fork is form Fri Sep 15 16:18:25 2023 +0200, and I am of the opinion that it saved me more work that is has cost me over the time. But yes, as you stated, this is just my opinion. Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: bug#74736: [PATCH v2 0/1] Add Request-For-Comment process.
Simon Tournier skribis: >> Perhaps the “Decision Making” section could stress that, with a >> paragraph above “To learn …” along these lines: >> >> Consensus building requires that participants share a common goal, >> trust each other to act in good faith, listen to one another’s >> concerns to take them into account, and are committed to donating >> enough of their time to achieve it. > > To me, this paragraph would be redundant with this other paragraph: > > Thus, no decision is made against significant concerns; these concerns > are actively resolved through counter proposals. A deliberating > member > disapproving a proposal bears a responsibility for finding > alternatives, > proposing ideas or code, or explaining the rationale for the status > quo. > > >> A deliberating member who “insists on disapproving”, without proposing >> alternative paths, wouldn’t meet these requirements. > > Yes and I think that already included in the paragraph above, no? Yes, looks like it. Ludo’.
