GNU bug report logs -
#76503
[GCD] Migrating repositories, issues, and patches to Codeberg
Previous Next
Full log
View this message in rfc822 format
Hi Arun,
Arun Isaac <arunisaac <at> systemreboot.net> skribis:
>> Assuming we agree that a move along the lines of this proposal is
>> desirable (let me know if you think we don’t share that premise), what
>> other options would you think of?
>
> I think we share the premise. I am not fundamentally opposed to the
> proposal in any way. Lowering the barrier to entry and making the
> project more accessible is a good thing. But…
You say “not fundamentally opposed”, but I’d like to stress that the
process is not about agreeing/disagreeing on an immutable proposal; it’s
about building it together to into account our concerns and needs.
> 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.
There are many factors contributing to the lack of timely reviews. As
someone reviewing patches every week and who also tried the PR model and
tools despite a natural aversion, I can tell that tools play a role.
Examples: I easily lose track of updated patch versions and comments
because they’re just more unread email in my inbox; contributors
sometimes lose track of what they sent, so they open a new issue, and I
find myself digging for the original submission and review; people
comment on each other’s issues but there’s no way to know unless you
read every single message. And the list goes on.
Annoyances like this make reviewing tedious and discouraging.
These specific issues go away on Codeberg and similar platforms. Will
that be enough to achieve timely reviews? No, but I’m sure it can help.
(BTW, you should give Codeberg a try, as I mentioned in the cover
letter. It would ensure we’re all on the same page.)
[...]
> The proposal mentions better automation of our review process. But, many
> of our review processes are not automatable—at least not easily so.
I agree. And it’s also true that the important bit, qa.guix, does not
require Codeberg to exist. A “modern forge” just makes it easier to
automate things and to integrate them with the contribution workflow.
[...]
> Requiring the agit workflow and disallowing forks (preferably enforced
> by technical means), thus solving the storage problem, would remove my
> most important grievances with this proposal.
I don’t think there’s a “storage problem”. There’s a storage risk, and
it’s one of several—there are other ways Codeberg could fail, some are
spelled out in the GCD.
In my view, what we need to do during the discussion period is to find
ways to mitigate and deal with those risks in the months and years to
come. We already discussed the storage risk before; what more do you
think should be done?
How would you amend the proposal to better address this and other
concerns your raised?
Thank you,
Ludo’.
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.