Re: Emacs next variants
On 2023-03-12 08:46, Liliana Marie Prikler wrote: > Am Sonntag, dem 12.03.2023 um 09:18 +0400 schrieb Andrew Tropin: >> > As for tree-sitter-with/without-gtk, I have no opinion here. We >> > could try exporting package rewriters so that everyone can have >> > their cup of tea, but maintaining one's own Emacs on the >> > user/channel level ought not to be too difficult either. >> >> I guess inheriting pgtk from tree-sitter looks most logical here: no >> potential problems for X users, tree-sitter for wayland users. >> Updated the inheritance hierarchy. > For the future, I think we should be careful not to be too close to the > master branch. emacs-next has thus far historically been a package to > try out things for the next release, not the one after that. The > inclusion of a package variant with tree-sitter necessitated a change, > but for packages that don't need it we should go back to tailing pre- > releases as soon as reasonable. Sure, I think after the release of emacs-29 we can make emacs-next to track emacs-30 and deprecate emacs-next-tree-sitter and after emacs-30 release we will include tree-sitter in emacs package itself and also we will be able to move emacs-next-pgtk to emacs-pgtk. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
Re: Emacs next variants
On 12-03-2023 08:46, Liliana Marie Prikler wrote: Am Sonntag, dem 12.03.2023 um 09:18 +0400 schrieb Andrew Tropin: > As for tree-sitter-with/without-gtk, I have no opinion here. We > could try exporting package rewriters so that everyone can have > their cup of tea, but maintaining one's own Emacs on the > user/channel level ought not to be too difficult either. I guess inheriting pgtk from tree-sitter looks most logical here: no potential problems for X users, tree-sitter for wayland users. Updated the inheritance hierarchy. For the future, I think we should be careful not to be too close to the master branch. emacs-next has thus far historically been a package to try out things for the next release, not the one after that. The inclusion of a package variant with tree-sitter necessitated a change, but for packages that don't need it we should go back to tailing pre- releases as soon as reasonable. Out of curiosity, where do such prescriptions concerning one tool or a set of tools get documented? Or is it currently a situation whereby enough people with such acculumated knowledge and experience as in the vicinity when somebody wants to make relevant changes? Thanks, -- Jonathan McHugh indieterminacy@libre.brussels
Re: bug#61894: [PATCH RFC] Team approval for patches
Hi,
On Sat, 11 Mar 2023 at 21:33, Maxim Cournoyer wrote:
> It may help to shed a bit of light on the original reason I think this
> change came into existence, and in the interest of transparency and
> hopefully improving or finding alternatives to the proposed change, I
> consent to Ludovic openly discussing it, even if it involves a healthy
> dose of critique and looking inward.
There is no one original reason but several diffuse situations. Well, I
have tried to provide the context and the intent behind the patch in
this message here:
https://lists.gnu.org/archive/html/guix-devel/2023-03/msg00121.html
Although I agree that the wording of the initial Ludo’s proposal is not
the one I would like, it does not appear to me so crazy to ask another
LGTM for some part of the code.
Double-check leaf Python package is not worth and it adds a lot of
unnecessary burden. We all agree here, I guess.
Double-check core packages or Guile build-side code sounds to me totally
reasonable.
The initial wording of the proposal,
--8<---cut here---start->8---
+When your patch falls under the area of expertise of a team
+(@pxref{Teams}), you need the explicit approval of at least one team
+member before committing (another team member if you are on the team).
--8<---cut here---end--->8---
cannot apply for all the teams. Again, we all agree I guess.
However, this proposal appears to me totally sane for what is under the
scope of the team named ’core’ for instance.
Instead of a strong opposition, the patch needs an update.
Cheers,
simon
Re: State of core-updates
Hello Chris, Am Fri, Mar 10, 2023 at 06:24:38PM + schrieb Christopher Baines: > I configured QA to submit builds for core-updates a little while back, > currently it requires a code change [1]. > 1: > https://git.cbaines.net/guix/qa-frontpage/commit/?id=39e9ec627faca95a7b43ff91e195ca9ab9846bf3 > I'm going to try and put some more time in to getting the qa-frontpage > to display some useful information about branches. I saw you just deployed the change, great, thanks a lot! > The builds are currently low priority compared to the patch testing ones > though, and there are more of these since raising the limit [2]. > It's possible to alter the priority for builds, so we could try and get > some to happen for core-updates. Well, from an egoistical point of view concerning core-updates, I would of course love to see that. But I think we should be consistent: Since we made a pass through QA mandatory for patch pushing, we should give this very high priority to avoid discouraging people. And at the time being, we do not have enough build power on bordeaux to do both, even after doing more builds on bayfront. I see a few options for the moment: use cuirass on berlin for this core-updates merge; devote a few of the berlin machines to QA (which I suppose could be difficult with respect to firewalls and so on, the Berlin administrators would need to speak out about this); add more build power to bordeaux locally (which may or may not be possible, and in any case is not a short term solution). Andreas
Re: Core-updates and cross-compilation
Hello, Am Sat, Mar 11, 2023 at 01:56:27PM +0100 schrieb Josselin Poiret: > I've been looking at the state of most failures for the CI jobset for > core-updates, and we have a couple of problems: > - gcc < 9 and gcc == 12 never cross-compile. > - we can't build the cross toolchain for the hurd, because the glibc > upgrade to 2.35 would require newer gnumach headers are these new issues compared to master? There we also have gcc@9 and @12, so my guess would be no, at least for the first one. > Should we consider these blockers for a core-updates merge? If the situation is not worse than on master, my answer will be a firm "no". Otherwise I am less sure. I think we might still want to merge core-updates first and handle these cross compilation issues in a later feature branch of the core team. Thanks for your work and thorough analysis! Andreas
Re: bug#61894: [PATCH RFC] Team approval for patches
Hello,
Am Sat, Mar 11, 2023 at 10:26:18PM -0500 schrieb Maxim Cournoyer:
> Ludovic Courtès writes:
> > I hope the maintainer team can help make teams “more functional”,
> > whatever that teams. It’s really what maintainership is about in Guix;
> > it’s not about writing code.
> I'm happy to help with the effort, but I don't think it's particularly
> relevant to Guix co-maintainers more than anyone else interested in
> advancing/contributing to Guix, and I find it great that it's this way
> (not out of laziness, but because the talent pool of the whole Guix
> community is much larger that that of us 4 co-maintainers). Per what we
> co-maintainers signed up for in [1], the co-maintainers three primary
> duties are:
but there is also
"Looking after people: making sure to promote people who are very involved
in leadership position; dubbing new committers, new maintainers, new
members of the spending committee. Supporting new initiatives. Generally
trying to make sure everyone’s happy. :-)"
As for all "management positions" (even if we may not like the term here
as it often evokes a hierarchy; maybe "board members of a non-profit"
captures the idea better), I think the maintainers' role is more about
moderating ("animer" in French, which I think is more to the point),
keeping the overview, overseeing and facilitating initiatives, making sure
the project moves on, etc., than day to day work on details, or the three
technical points you mention (and which probably hardly ever require
action).
Maybe it would be time to move on to something like the Debian Social
Contract and concrete rules how membership, commit rights, maintainer
roles in the Guix project are bestowed and what is expected from people
fulfilling such roles.
Andreas
Re: bug#61894: [PATCH RFC] Team approval for patches
Hi Maxim, On Sat, 11 Mar 2023 at 22:26, Maxim Cournoyer wrote: > I'm sorry that you feel that way. I don't think consensus was willfully > broken, and perhaps by studying some actual examples of these > occurrences we can better understand what went wrong and how the new > suggested policy would have helped or could be modified to help avoid > such problems in the future. Well, all is in the public archive. :-) For one recent example, see #61255 [1]: --8<---cut here---start->8--- We should think about how to improve our processes to avoid such issues in the future. I did raise concerns about this very patch late at night during FOSDEM, 24h after submission, and reaffirmed my viewpoint days later. I understand that delaying a nice patch series like this one is unpleasant, but I think those concerns should have been taken into account. --8<---cut here---end--->8--- 1: https://issues.guix.gnu.org/issue/61255#32 >From my point of view, it is useless to rehash specific example by specific example. Because it is not one unique case but several diffuse situations popping here or there. To be honest, I am missing what are the objections when one is asking to double-check some core changes. Anyway, I have expressed my opinion in various places in this thread and now I will not comment further. Cheers, simon
Re: Emacs next variants
Am Sonntag, dem 12.03.2023 um 10:46 +0100 schrieb indieterminacy: > Out of curiosity, where do such prescriptions concerning one tool or > a set of tools get documented? It isn't, but note the manual on version numbers leads with > We usually package only the latest version of a given free software > project. But sometimes, for instance for incompatible library > versions, two (or more) versions of the same package are needed. emacs is a notable exception here due to emacs next almost always existing. Cheers
Re: GHC in core-updates
Hi Andreas, > But I confirm that ghc@9.2.5 now fails its tests, it has happened a second > time for me. Nothing in the recent commits to core-updates since I tried > the last time springs to mind as obviously having a connection to these > failures. fixed by commit ec79901a33b6463ad77dcaf4c37e538645b4d7b5 on core-updates. I also verified pandoc builds. Cheers, Lars
Re: GHC in core-updates
Am Sun, Mar 12, 2023 at 05:26:51PM +0100 schrieb Lars-Dominik Braun: > > But I confirm that ghc@9.2.5 now fails its tests > fixed by commit ec79901a33b6463ad77dcaf4c37e538645b4d7b5 on > core-updates. I also verified pandoc builds. Wow, fantastic, thanks a lot! Andreas
Re: bug#61894: [PATCH RFC] Team approval for patches
Hi Andreas,
Andreas Enge writes:
> Hello,
>
> Am Sat, Mar 11, 2023 at 10:26:18PM -0500 schrieb Maxim Cournoyer:
>> Ludovic Courtès writes:
>> > I hope the maintainer team can help make teams “more functional”,
>> > whatever that teams. It’s really what maintainership is about in Guix;
>> > it’s not about writing code.
>> I'm happy to help with the effort, but I don't think it's particularly
>> relevant to Guix co-maintainers more than anyone else interested in
>> advancing/contributing to Guix, and I find it great that it's this way
>> (not out of laziness, but because the talent pool of the whole Guix
>> community is much larger that that of us 4 co-maintainers). Per what we
>> co-maintainers signed up for in [1], the co-maintainers three primary
>> duties are:
>
> but there is also
> "Looking after people: making sure to promote people who are very involved
> in leadership position; dubbing new committers, new maintainers, new
> members of the spending committee. Supporting new initiatives. Generally
> trying to make sure everyone’s happy. :-)"
Yes, I've only quoted the core duties of the maintainers, because we
struggle to do much of anything else; thankfully, many individuals in
the our community mostly fill in the gaps (thanks!). I'm aware that
ideally we would do more: if you are interested in giving a hand, let
guix-maintainers know -- we're currently 4 and could do with a 5th
person onboard to smooth out operations).
> As for all "management positions" (even if we may not like the term here
> as it often evokes a hierarchy; maybe "board members of a non-profit"
> captures the idea better), I think the maintainers' role is more about
> moderating ("animer" in French, which I think is more to the point),
> keeping the overview, overseeing and facilitating initiatives, making sure
> the project moves on, etc., than day to day work on details, or the three
> technical points you mention (and which probably hardly ever require
> action).
Past maintainers will probably smile at the "hardly ever require
actions" :-). But you are right, the occurrences of things like CoC
complaints or other requests sent over email are not constant in time
(but it doesn't mean they are easy or quick to resolve). That said, I
agree with the general idea about maintainers having a role to play in
smoothing out interactions (which I believe we are doing) and
shepherding efforts toward a common goal (which I don't think we are
doing much at all).
> Maybe it would be time to move on to something like the Debian Social
> Contract and concrete rules how membership, commit rights, maintainer
> roles in the Guix project are bestowed and what is expected from
> people fulfilling such roles.
I'm not sure how something like the Debian Social Contract would help
here, and I do not know that "membership" has a meaning in our
community. As I mentioned before, I feel like our problems are mostly
social rather than organizational (such as the question about how to
motivate people to review more), so I'd rather focusing on that more
than adding organizational layers.
I'll now leave the discussion space to other participants, as I feel
like I've already used too much of it :-).
--
Thanks,
Maxim
gnu: inetutils: Update to 2.4.
Hi, With core-updates possibly being replaced by feature branches, I am not sure where to place this update to GNU Inetutils 2.4. The patch series [1] will rebuild 3,416 packages. Thank you, everyone, for your hard work! Kind regards, Felix Lechner [1] https://issues.guix.gnu.org/62154
