unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Léo Le Bouter" <lle-bout@zaclys.net>
To: Mark H Weaver <mhw@netris.org>, Christopher Baines <mail@cbaines.net>
Cc: guix-devel@gnu.org
Subject: Re: GNOME 40 work should be done on Savannah (was: Re: GNOME 40)
Date: Tue, 30 Mar 2021 01:17:59 +0200	[thread overview]
Message-ID: <35efe3776747ef36d6eec350843428fa0abf22fd.camel@zaclys.net> (raw)
In-Reply-To: <87eefx36ni.fsf@netris.org>

[-- Attachment #1: Type: text/plain, Size: 3128 bytes --]

Hello!

On Mon, 2021-03-29 at 19:02 -0400, Mark H Weaver wrote:
> This sounds theoretical.  Concretely, what needs do you have that
> aren't
> being met by Savannah?

Per-branch access control

> I don't understand this.  It seems to me the opposite.
> 
> If I want to contribute to this external 'wip' branch, I need to
> arrange
> for access.  Ditto for any other Guix committer who wants to work on
> it.
> That's added "bureaucracy" entailed by your approach that would not
> be
> needed for 'wip' branches on Savannah.

Cbaines is more responsive and has much lower requirements than what
the "Commit Access" for GNU Guix itself requires. It's as if we created
a third party git repo for both of us Raghav and myself then
collaborated there except through Cbaines's infra we get CI
infrastructure for free.

> On the other hand, maybe your point is that you'd like to allow
> direct
> commit access to this 'wip' branch by people who don't have commit
> access to Savannah.  If that's the goal, I find that objectionable,
> because when this branch is finally merged, all of those commits will
> suddenly get dumped into Savannah.  That increases "risk" from my
> perspective.
> 
> I actively do not want commits getting into Savannah without an
> existing
> Guix committer taking responsibility for them.  Your approach
> effectively creates a loophole for non-committers to potentially
> introduce many commits into the official Guix repository in a way
> that
> is likely to not get adequate oversight.

Why would it not get adequate oversight? It's just an easier way to
collaborate on patches, but the patchset would be sent over to guix-
patches before getting merged to master or else.

In general I don't agree with such gatekeeping of access to wip
branches because it actively hinders the development of GNU Guix by
non-committers, and many non-committers would like to get involved more
but they are barred by the commit access requirement.

> * * *
> 
> I'd strongly prefer for this work to be done on Savannah.  If this
> were
> a fringe branch of marginal interest, it might make sense to have it
> elsewhere, but this is core Guix desktop work that's likely to be of
> interest to a large segment (plausibly a majority) of our community.
> IMO, it belongs in our official git repository.
> 
> Thoughts?
> 
>       Mark

The people that work on it now are Raghav and me, and Raghav does not
have commit access yet, so that's the only way we can work and
cooperate now. We don't have a choice. If and when Raghav's commit
access application is approved then we can move to Savannah.

I don't feel like people should be barred to contribute to that GNOME
40 upgrade because they arent an approved committer. That doesnt feel
inclusive to me.

If you want to work on this GNOME upgrade however, that help is more
than welcome, in this particular situation probably we can work on
getting Raghav's commit access application approved then your concerns
will be sorted out as no other non-committer participant seemed to show
up.

Léo

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2021-03-29 23:18 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-28 13:19 GNOME 40 Raghav Gururajan
2021-03-28 15:16 ` Léo Le Bouter
2021-03-28 20:48   ` Mark H Weaver
2021-03-29  7:38     ` Christopher Baines
2021-03-29 23:02       ` GNOME 40 work should be done on Savannah (was: Re: GNOME 40) Mark H Weaver
2021-03-29 23:17         ` Léo Le Bouter [this message]
2021-03-30  6:41           ` Mark H Weaver
2021-03-30 11:12             ` zimoun
2021-03-30 23:50             ` Léo Le Bouter
2021-03-30 12:12           ` GNOME 40 work should be done on Savannah Ludovic Courtès
2021-03-31  0:06             ` Léo Le Bouter
2021-03-31  1:55               ` Mark H Weaver
2021-03-31  2:08                 ` Léo Le Bouter
2021-03-31  0:16             ` Léo Le Bouter
2021-03-30  6:53         ` GNOME 40 work should be done on Savannah (was: Re: GNOME 40) Christopher Baines
2021-03-29 21:33     ` GNOME 40 Léo Le Bouter
2021-03-31 14:05       ` 宋文武
2021-03-29 11:41   ` Raghav Gururajan
     [not found]     ` <67c5aac2-2669-62dc-a82a-16c2bf9b554a@raghavgururajan.name>
2021-04-07 19:10       ` Raghav Gururajan
2021-04-10  7:09         ` 宋文武
2021-04-13 20:27         ` Mark H Weaver

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=35efe3776747ef36d6eec350843428fa0abf22fd.camel@zaclys.net \
    --to=lle-bout@zaclys.net \
    --cc=guix-devel@gnu.org \
    --cc=mail@cbaines.net \
    --cc=mhw@netris.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).