[pkg-go] EARLY DRAFT: pkg-go plans

[Michael Stapelberg]

Hi Ximin,

Sorry for replying late, I’m pretty swamped lately.

Ximin Luo <infinity0 at pwned.gg> writes:
> I agree with the general principle of the main points, but I disagree
> with how "mandatory code review" is to be implemented (I support the
> general idea though).
Good to hear, thanks for the feedback.

> Disallowing pushes to alioth is a bit on the heavy side IMO. Debian
> already has a mechanism for restricting non-experienced packagers from
> uploading - and that is the sponsorship process. Adding another
> barrier in the form of git restrictions only adds bureaucracy, and
> forces the newbies to find their own git hosting, which is not very
> supportive/friendly.
Consider that users can publish git repositories under their own
username, e.g. mstapelberg-guest back in the days :-).

The repositories that you get to after clicking on the VCS links on the
Debian PTS should not be a place where you see random commits from
newbies (your example) that may or may not go into what we actually
upload.

> However, I can see how it would be useful to do reviews asynchronously
> in batches, instead of all-at-once during sponsorship. Perhaps we can
> have "reviewed" branches, that only "experienced reviewers" are
> allowed to update, and mandate that we only release things via `gbp
> buildpackage --git-debian-branch=reviewed`? In your document you
> already mandate using `--git-pbuilder` so adding another flag won't
> mess things up too much. (I am not sure how we are supposed to enforce
> these flags, but that applies to `--git-pbuilder` as well.)
That’s certainly a possibility. However, I think reversing your model
(have branches/separate repositories for non-reviewed commits) has one
big advantage: we can stay with the standard branch model for all of our
repositories, i.e. master/upstream/pristine-tar. This considerably
lowers the barrier of entry for many many use-cases and contributions.

What do you think?

-- 
Best regards,
Michael