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