GNU bug report logs -
#76503
[GCD] Migrating repositories, issues, and patches to Codeberg
Previous Next
Full log
Message #50 received at 76503 <at> debbugs.gnu.org (full text, mbox):
Arun Isaac <arunisaac <at> systemreboot.net> writes:
> According to the survey, only 9% want a pull request workflow, while 20%
> just want timely reviews. My hunch (I have no data or proof) is that the
> 9% would also be perfectly happy if we just provide them timely reviews.
The thing is, moving to Codeberg isn't just about the pull-request
workflow. I don't really care about that. What I care about is having a
/forge/, and all the features that come with it.
A forge would make the collaboration process far more accessible,
because it would provide a decent default experience for every
contributor (ie. the web interface). There would be no need to set up
isync/offlineimap/whatever + Notmuch/Mu4e/GNUs/mutt/whatever just for
the bare minimum of a decent UI for plain-text email.
And then, there are the additional features provided by a forge, which
are very difficult to provide in an email-based workflow. For example,
tagging issues. We have Debbugs usertags, but the majority of
contributors will not see them, because they'd have to use the Debbugs
web interface - and I struggle to imagine anyone ever doing that
willingly. I have tried to set up debbugs.el, but I couldn't get it
working the last time I tried, and frankly I don't have the energy to
configure even more Emacs-specific tooling that I will never use
anywhere else (as if contributing isn't difficult enough for non-Emacs
users...). Perhaps this is why I've observed that usertags don't really
get used much, outside of QA reviews maybe ('reviewed-looks-good').
Now compare this with the situation on GitHub or Codeberg, where there's
a web interface that even a child could figure out, that shows the same
view to everyone. So if you tag issues, you can be sure that everyone
will see the tags. It's that simple.
Also, more reliable and integrated QA would probably make a big
difference, since QA seems to be how committers find out whether a
series is ready to apply. While qa.guix.gnu.org is very impressive for a
volunteer effort, it suffers from a lot of issues that don't really
happen in modern forges (eg. failing to detect or apply patches from a
Debbugs submission), and we don't seem to have enough bandwidth to
improve it. A forge would provide most of what it does, and it would be
directly integrated with the rest of the tooling.
> And, to provide timely reviews, we need to be focussing on entirely
> different things—for example, the infinite growth of our package
> collection and the strictness of our code reviews. If we could decompose
> Guix into smaller channels, some of which have less stringent review
> processes, we may get much faster reviews. To some extent, we see this
> already in channels such as guix-science (less stringent review),
> guix-cran (no review!), etc. Centralization of review and decision
> making does not scale well. To grow, we need to devolve power. One day,
> we aim to be as big as or bigger than Debian. We cannot do that without,
> in some way, imitating their organizational structure.
Could you share what aspects of Debian's organizational structure you'd
like us to mirror? I agree that decentralization is good in principle,
but I'm concerned about needlessly fragmenting the community. I'm not
familiar with how things work in Debian-land. If they've managed to
solve this problem, it'd be good for all of us to know about.
> The Codeberg move aims to make it easier for contributors. But, if
> anything, we already have too many contributions and are unable to keep
> up with reviews! :-D Codeberg is likely to increase the number of
> contributors without significantly increasing the number of reviewers. I
> cannot be sure of this, nor can I provide much in the way of proof; only
> time will tell.
As I mentioned above, I think features like tagging, reliable detection
of merge conflicts, and a decent and consistent interface would remove a
lot of the friction involved in contribution/review. And since reviewers
are also contributors, a nicer and more efficient contribution process
would mean more time and energy left over for review.
This bug report was last modified 16 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.