guix package updates review: app team?

guix package updates review: app team?

[Andy Tai]

Hi, currently Guix has teams of reviewers for different types of
packages.   For example, changes to R packages and emacs seem to be
reviewed quickly.  However, recently, patches for updating more
general application packages (octave, for example) seem to be reviewed
and processed very slowly.

As a GNU/Linux distribution the update speed of applications impact
the perception of the community on a distribution, and thus it is
beneficial if packages update can be processed quickly to keep Guix
"up to date" so to speak.  Hope Guix maintainers can give some thought
to this and let more volunteers participate in package review process
to allow package updates more quickly.   As packages are usually at
the end of the dependency chain (they depend on other libraries or
components more than the other way around) updating packages shall
take less review effort.

Re: guix package updates review: app team?

[Andy Tai]

last paragraph shall be

As application packages are usually at
the end of the dependency chain (they depend on other libraries or
components more than the other way around) updating application packages shall
take less review effort.

On Fri, Jan 27, 2023 at 2:19 PM Andy Tai <atai@atai.org> wrote:
>
> Hi, currently Guix has teams of reviewers for different types of
> packages.   For example, changes to R packages and emacs seem to be
> reviewed quickly.  However, recently, patches for updating more
> general application packages (octave, for example) seem to be reviewed
> and processed very slowly.
>
> As a GNU/Linux distribution the update speed of applications impact
> the perception of the community on a distribution, and thus it is
> beneficial if packages update can be processed quickly to keep Guix
> "up to date" so to speak.  Hope Guix maintainers can give some thought
> to this and let more volunteers participate in package review process
> to allow package updates more quickly.   As packages are usually at
> the end of the dependency chain (they depend on other libraries or
> components more than the other way around) updating packages shall
> take less review effort.



-- 
Andy Tai, atai@atai.org, Skype: licheng.tai, Line: andy_tai, WeChat: andytai1010
Year 2023 民國112年
自動的精神力是信仰與覺悟
自動的行為力是勞動與技能

Re: guix package updates review: app team?

[Simon Tournier]

Hi,

On ven., 27 janv. 2023 at 14:19, Andy Tai <atai@atai.org> wrote:

> Hi, currently Guix has teams of reviewers for different types of
> packages.   For example, changes to R packages and emacs seem to be
> reviewed quickly.  However, recently, patches for updating more
> general application packages (octave, for example) seem to be reviewed
> and processed very slowly.
>
> As a GNU/Linux distribution the update speed of applications impact
> the perception of the community on a distribution, and thus it is
> beneficial if packages update can be processed quickly to keep Guix
> "up to date" so to speak.  Hope Guix maintainers can give some thought
> to this and let more volunteers participate in package review process
> to allow package updates more quickly.   As packages are usually at
> the end of the dependency chain (they depend on other libraries or
> components more than the other way around) updating packages shall
> take less review effort.

First of all, people are volunteers. :-)

Well, if it appears slow, then it probably mean people are busy
elsewhere.  The only thing is to help and reduce the workload.

What *you* (reader) could do is:

 1. Review.  It is not restricted only to people with commit access.

 2. Bug triage.  The tracker has many old bugs still open.  It would
    help to:

    a) confirm or not if the bug is still there;
    b) propose a fix if it is still there.


About #1, if applying the patch is straightforward, if the patch is
already compliant with the standard, etc. then it is easier for
merging because it makes the task less boring for people with commit
access.

Please note that some packages and/or patches are harder than other.

Last, here the current state [1] of Guix.  Each red circle means that
one package is not available (probably broken and/or fails to build).
Since the manpower is limited, personally I would prefer to be less “up
to date” and all green, rather than packages merged more quickly and
probably a global state less stable.

Well, the balance is not easy to find and I understand the frustration.

1: <http://ci.guix.gnu.org/eval/156739/dashboard>

Moreover, I agree that some part of the process could be revisited.
Please note this past thread « Incentives for review» with my own
ramblings on the topic. :-)

    Re: Tricking peer review
    Tue, 19 Oct 2021 16:22:30 +0200
    id:86k0i9drh5.fsf@gmail.com
    https://yhetil.org/guix/86k0i9drh5.fsf@gmail.com

More than one year later, my words are still describing my own point of
view on this topic about reviewing and merging.  However, the solutions
are not so easy to implement… otherwise it would already be done. ;-)
Thus, the question is: what could it be done for helping?

Cheers,
simon