Re: GNOME 40 work should be done on Savannah (was: Re: GNOME 40)

[Léo Le Bouter]

On Tue, 2021-03-30 at 02:41 -0400, Mark H Weaver wrote:
> Sorry, but that's simply false.  You _do_ have a choice.  You can do
> what we've been doing in the Guix community for years: as a
> committer,
> _you_ can commit the work of non-committers on their behalf.  If not
> you, then any of the other ~64 Guix committers can do so.
> 
> Needless to say, before committing, you must review the proposed
> patches, for the sake of your reputation.  The fact that you must do
> this is a *feature*, not a bug.

Nobody is talking about skipping the review process, as I said, it's
just about collaborating over git rather than with patches (good for
little patches but very troublesome for larger patchsets)

> No one is "barred" from contributing.  Raghav and many others without
> commit access have been successfully contributing to Guix for years.
> 
> I understand that it's inconvenient.  Naturally, you would like to
> eliminate that inconvenience.
> 
> The thing is, the work of non-committers *must* be reviewed at some
> point, anyway.  Moreover, a committer must take responsibility by
> digitally signing it.  To eliminate either of these steps would put
> us
> at risk.
> 
> There's no guarantee that the work of Guix committers will be
> reviewed
> by anyone else, because no one else's reputation is on the
> line.  Some
> of us try to keep an eye on things, but I would not bet on that
> oversight being comprehensive.  I'm certainly not doing it
> comprehensively.
> 
> With this in mind, I think that we *should* have a high standard for
> committers.  The security of our systems, as well as Guix's
> reputation
> as a project, depends upon the good judgment of _every_ Guix
> committer.
> 
> Observe what can happen with projects that are too lax:
> 
>   
> https://arstechnica.com/gadgets/2021/03/buffer-overruns-license-violations-and-bad-code-freebsd-13s-close-call/
> 

I don't think we are on the same page.

> Upgrading GNOME is not trivial.  It will be a large patch set.  A
> large
> patch set presented to guix-patches when the branch is ready to merge
> is
> far less likely to get careful review than if the review is done a
> few
> commits at a time.  That's because, at any given time, it's easier to
> find Guix developers with a few minutes available to carefully review
> a
> small handful of commits, than to find developers prepared to review
> a
> non-trivial branch merge.  If they're reviewed at all, reviews of
> larger
> code drops are more likely to be superficial.

We also go by steps and review things as they appear with Raghav,
collaborating over git is just easier than exchanging patches for
testing/review back&forth.

> * * *
> 
> In summary: it seems to me that working in an external repository
> with a
> larger set of committers would not actually save time, because it
> would
> merely postpone the required review work until the end of the process
> when the branch is ready to be merged into Savannah.  Moreover, it
> would
> likely reduce the quality of that review work.
> 
> Does that make sense?

Not to me, the git vector is just a way to collaborate more easily but
things would still get reviewed (in smaller patchsets if necessary
also) before getting merged.

> Regards,
>   Mark

Léo


signature.asc
Description: This is a digitally signed message part

Re: GNOME 40 work should be done on Savannah (was: Re: GNOME 40)

[zimoun]

Hi,

> The thing is, the work of non-committers *must* be reviewed at some
> point, anyway.  Moreover, a committer must take responsibility by
> digitally signing it.  To eliminate either of these steps would put us
> at risk.
>
> There's no guarantee that the work of Guix committers will be reviewed
> by anyone else, because no one else's reputation is on the line.  Some
> of us try to keep an eye on things, but I would not bet on that
> oversight being comprehensive.  I'm certainly not doing it
> comprehensively.

Reviewing does not require commit access.  Examples [1,2] among many
others.  The recent (trivial) addition of Julia packages [3] is
interesting in this regard, IMHO.  It is a chain of trust.  Committer
has the final word.

And to my taste, there is too much non-trivial patches pushed without
going through guix-patches first.  Another story.

1: 
2: 
3: 

>> 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.
>
> Sorry, but that's simply false.  You _do_ have a choice.  You can do
> what we've been doing in the Guix community for years: as a committer,
> _you_ can commit the work of non-committers on their behalf.  If not
> you, then any of the other ~64 Guix committers can do so.

[...]

>> 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.
>
> No one is "barred" from contributing.  Raghav and many others without
> commit access have been successfully contributing to Guix for years.
>
> I understand that it's inconvenient.  Naturally, you would like to
> eliminate that inconvenience.

I miss something.  Is the Git ’remote’ not fitting the need?

Well, for instance, I have currently 4 remotes, some where I fetch, some
where I push.

For example, to avoid to overflow guix-patch when updating Bioconductor
R packages, Ricardo (committer) pushed the work on the Savannah branch
’wip-r’, i.e, I fetched from Savannah, tweaked, pushed to my personal
repo, Ricardo fetched from it, etc. with a simple synchronisation on
#guix or #guix-hpc.

Another example is the recent Outreachy.  Magali (intern) pushed their
work on their own repo, I (non-committer) fetched from it, commented,
etc.  Then once ready, I do not remember who (committer) pushed to the
Savannah branch ’wip-guix-log’ (help with review welcome ;-)).

Another example is the recent Cuirass / new offloading thing.  Mathieu
did some work on a branch in their personal repo, asked me to give a
look, so I fetched, commented, etc. then they pushed to ’master’
Savannah a part of it, still improving other part on their personal
branch, etc.

Well, I should miss something.  In my understanding, Git is designed to
allow collaboration without a central repo.  Is it not what
“distributed” means in DVCS?

If having a central repo—–where a large number of people can write
in––eases the work, why not.  But the key point is to regularly push to
a ’wip-gnome’ branch or ’core-updates’ on Savannah.  Savannah must be
the reference.  For 2 practical reasons: 1) it is more discoverable,
i.e., inclusive, for newcomers (clone the Guix repo Savannah, press ’y’
with Magit, see ’wip-gnome’, contribute!) and 2) it increases the chance
that other Guixers give a look time to time.

Last, I agree with Mark, regularly pushing to Savannah is the guarantee
that the final work is fully respecting the Guix standards.  By doing
so, it is the responsibility of the committer by signing off to ensure
that the standards are respected.

Somehow, it is the plan, right?  And a “miscommunication” about the word
«flexible» and about how to exchange large numbers of patches without
’format-patch+send-email’?

Cheers,
simon

Re: GNOME 40 work should be done on Savannah (was: Re: GNOME 40)

[Christopher Baines]

Mark H Weaver  writes:

> Christopher Baines  writes:
>
>> Mark H Weaver  writes:
>>> How is it more flexible than a "wip-*" branch on Savannah?
>>
>> I wouldn't use quite the same words as Léo, but from my perspective,
>> controlling access to particular branches (master, staging,
>> core-updates, ...) on Savannah is a good thing, as it reduces risk.
>
> I don't see much risk here.  You're talking about a 'wip' branch that
> almost no one will be using anyway.  We already trust all Guix
> committers with our master branch, which directly and immediately
> affects any Guix user who updates their system at the right time.

No, I was talking about particular branches, master, staging,
core-updates, ... and controlling access to those more sensitive
branches.

I mention this as context for discussing acesss control to wip-*
branches, because currently as I understand it, if someone wants access
to work on a specific wip- branch, the only way to do that is grant
access to all branches in all repositories in the Guix Savannah project.

...

> 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.

I'm not commenting on this Gnome 40 related work, as I'm not really
involved, but I do think there's some potential for improvement
regarding how wip- branches are handled.

Having them on Savannah is great as you say, but that makes these
branches more difficult to use for people who don't have commit access.


signature.asc
Description: PGP signature

Re: GNOME 40 work should be done on Savannah (was: Re: GNOME 40)

[Mark H Weaver]

Hi Léo,

Léo Le Bouter  writes:
> 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.

Sorry, but that's simply false.  You _do_ have a choice.  You can do
what we've been doing in the Guix community for years: as a committer,
_you_ can commit the work of non-committers on their behalf.  If not
you, then any of the other ~64 Guix committers can do so.

Needless to say, before committing, you must review the proposed
patches, for the sake of your reputation.  The fact that you must do
this is a *feature*, not a bug.

> 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.

No one is "barred" from contributing.  Raghav and many others without
commit access have been successfully contributing to Guix for years.

I understand that it's inconvenient.  Naturally, you would like to
eliminate that inconvenience.

The thing is, the work of non-committers *must* be reviewed at some
point, anyway.  Moreover, a committer must take responsibility by
digitally signing it.  To eliminate either of these steps would put us
at risk.

There's no guarantee that the work of Guix committers will be reviewed
by anyone else, because no one else's reputation is on the line.  Some
of us try to keep an eye on things, but I would not bet on that
oversight being comprehensive.  I'm certainly not doing it
comprehensively.

With this in mind, I think that we *should* have a high standard for
committers.  The security of our systems, as well as Guix's reputation
as a project, depends upon the good judgment of _every_ Guix committer.

Observe what can happen with projects that are too lax:

  
https://arstechnica.com/gadgets/2021/03/buffer-overruns-license-violations-and-bad-code-freebsd-13s-close-call/

> 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.

Upgrading GNOME is not trivial.  It will be a large patch set.  A large
patch set presented to guix-patches when the branch is ready to merge is
far less likely to get careful review than if the review is done a few
commits at a time.  That's because, at any given time, it's easier to
find Guix developers with a few minutes available to carefully review a
small handful of commits, than to find developers prepared to review a
non-trivial branch merge.  If they're reviewed at all, reviews of larger
code drops are more likely to be superficial.

* * *

In summary: it seems to me that working in an external repository with a
larger set of committers would not actually save time, because it would
merely postpone the required review work until the end of the process
when the branch is ready to be merged into Savannah.  Moreover, it would
likely reduce the quality of that review work.

Does that make sense?

Regards,
  Mark

Re: GNOME 40 work should be done on Savannah (was: Re: GNOME 40)

[Léo Le Bouter]

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


signature.asc
Description: This is a digitally signed message part

GNOME 40 work should be done on Savannah (was: Re: GNOME 40)

[Mark H Weaver]

Christopher Baines  writes:

> Mark H Weaver  writes:
>> How is it more flexible than a "wip-*" branch on Savannah?
>
> I wouldn't use quite the same words as Léo, but from my perspective,
> controlling access to particular branches (master, staging,
> core-updates, ...) on Savannah is a good thing, as it reduces risk.

I don't see much risk here.  You're talking about a 'wip' branch that
almost no one will be using anyway.  We already trust all Guix
committers with our master branch, which directly and immediately
affects any Guix user who updates their system at the right time.

If someone commits something inappropriate to a 'wip' branch, we can all
easily see that they did so, investigate more closely, and optionally
revert the changes.

Léo Le Bouter  writes:

> On Sun, 2021-03-28 at 16:48 -0400, Mark H Weaver wrote:
>> How is it more flexible than a "wip-*" branch on Savannah?
>
> Because as the GNU Guix project we have no control on the forge to
> catter it to our own needs,

This sounds theoretical.  Concretely, what needs do you have that aren't
being met by Savannah?

> because there is bureaucracy involved with approving new committers so
> they can work on wip branches (shouldnt be necessary).

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.

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.

* * *

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