emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gitlab Migration


From: Eli Zaretskii
Subject: Re: Gitlab Migration
Date: Sat, 28 Aug 2021 11:00:08 +0300

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Theodor Thornhill <theo@thornhill.no>,  emacs-devel@gnu.org,
>   larsi@gnus.org,  monnier@iro.umontreal.ca,  danflscr@gmail.com,
>   sir@cmpwn.com
> Date: Fri, 27 Aug 2021 20:58:01 +0000
> 
> + Reduce email noise
> 
>   The mailing lists are just mailing lists, from
>   what I know the only "spam" might be CI responding with the results of
>   a test

What about automated notifications regarding a PR being merged or
issues being closed or merged or changed status?  These are a source
of constant useless noise when you subscribe to Github-based project.
Can they be filtered out, or limited to the submitter if he/she is not
an Emacs maintainer?  Or some other useful and flexible enough
filtering?

> > I tried to find answers to those questions myself, but there doesn't
> > seem to be any detailed documentation that describes the setup and
> > usage from the routine user POV (or maybe I missed it?).  I did find a
> > heads-up that "from the beta onwards, unpaid accounts will be limited
> > to read-only access to their own projects", so I wonder what that
> > means for us.  It also says that "web-based workflow for submitting
> > and reviewing patches" is still under development.
> 
> It shouldn't mean anything, if GNU decides to host their own
> instance. Otherwise, every project member would have to play to have an
> account, but I assume mailing list contributors could continue accessing
> the mailing list without any issue.

This answers the first part, but not the second.  It looks like the
Web-based workflows are still not supported well enough.

Thanks.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]