public inbox for gentoo-project@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed]
@ 2019-02-03 19:28 Michał Górny
  2019-02-03 21:29 ` Kristian Fiskerstrand
                   ` (5 more replies)
  0 siblings, 6 replies; 24+ messages in thread
From: Michał Górny @ 2019-02-03 19:28 UTC (permalink / raw
  To: gentoo-project

[-- Attachment #1: Type: text/plain, Size: 4217 bytes --]

Hello,

I'd like to collect feedback on starting a new project focused
on providing a platform to users work on ebuilds without the explicit
need for developer intervention.


Why?
----
The current contribution platforms seem inadequate to the needs of our
users.  In particular:

- Submissions via Bugzilla etc. are inconvenient for anyone to use,
and basically rely on some developer taking them up and transferring
to ::gentoo.

- Proxy-maint requires a lot of effort for both contributors
and developers.  We're undermanned for quite some time and can't handle
all the contributions timely.  Plus, not every contributor wants to
become package maintainer.

- User repositories are cheap to create but cause ebuilds to be
scattered all over the place.  In the end, they're inconvenient to
users, and adding them and cleaning up unmaintained repos afterwards
costs me a lot of effort.

While all of those venues have their use case, we seem to lack something
akin Arch Linux's AUR.  What I'm specifically aiming for here is
a single place where users can maintain (or not) packages themselves
without unnecessary developer intervention.  Something like Sunrise,
except without reviews.


What do I propose?
------------------
GURU would be an official repository maintained entirely by Gentoo
users.  I'm thinking of Wiki-like workflow where anyone is allowed to
add new ebuilds or modify existing ebuilds, and users are expected to
keep order.  Gentoo developers would be allowed to contribute
on the same terms as users; official developer intervention would be
only used to resolve conflicts and other kinds of trouble.


Open issues
-----------
1. Should the access be open or explicitly granted?  If the latter, how
should we determine whether to grant access for a particular
contributor?

2. Where should it be hosted?  Gentoo Infra is unsuitable for open
access, as we would have to add all keys manually.  GitHub, GitLab, etc.
are all options.

3. How far should Gentoo policies apply?  I think we should enforce
sign-off per copyright policy but let users resolve issues beyond that.

4. Should it be purely for new packages, or should forking Gentoo
packages be allowed?  I'm thinking allowing forks for unmaintained
or severely outdated Gentoo packages makes sense.

5. And most importantly, what should the last 'U' stand for?  My initial
idea was 'Unreviewed' but I'm open to better-sounding ideas.


Foreseen Q&A
------------

* Will it replace proxy-maint?

No, proxy-maint will continue working as-is.  I expect some contributors
may switch over, and some will simply submit ebuilds both ways. 
Ideally, GURU may serve as initial ebuild improvement/proofreading
exercise before moving to ::gentoo.

* Why not revive Sunrise instead?

The problem with Sunrise is that it needs active developers.  Given that
it died pretty much because people lost interest, I don't think trying
to artificially revive it is going to help.  Instead, I'd like to try
something new and see how it works.

* Who will be allowed to commit?

The idea is that everybody will be allowed to commit.  I'm not planning
to enforce strong maintainer boundaries like in Gentoo.  However,
in the end I expect the people actually working on GURU to decide
and establish best practices themselves.

* What if somebody submits malware?

This risk is inevitable.  Hopefully, the Wiki-like workflow will
eventually create some kind of mutual review of new commits, and users
will look out for suspicious ebuilds.  Users will be able to revert them
themselves, and developers will block reported accounts if necessary.

That said, please remember that no other way of submitting ebuilds is
free of this risk.  Believe me, we don't really review the code of every
submitted package, and if somebody wrote a program with malicious
functionality and wanted to package it, it will probably be accepted.

* What if somebody misbehaves?

I think we will reserve the right to ban contributors who repeatedly
misbehave (e.g. remove packages, commit offensive stuff, etc.).


---
What do you think?

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread
end of thread, other threads:[~2019-02-04 18:44 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-02-03 19:28 [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed] Michał Górny
2019-02-03 21:29 ` Kristian Fiskerstrand
2019-02-04  5:45   ` Michał Górny
2019-02-03 22:37 ` Michael Orlitzky
2019-02-03 23:08   ` Kristian Fiskerstrand
2019-02-04 10:58 ` Alexis Ballier
2019-02-04 13:28   ` Michał Górny
2019-02-04 13:43     ` Brian Evans
2019-02-04 14:02       ` Michał Górny
2019-02-04 14:25         ` Michael Orlitzky
2019-02-04 13:48     ` Alexis Ballier
2019-02-04 13:54       ` Michał Górny
2019-02-04 14:04         ` Alexis Ballier
2019-02-04 14:13           ` Michał Górny
2019-02-04 14:35             ` Alexis Ballier
2019-02-04 14:43               ` Rich Freeman
2019-02-04 15:09                 ` Alexis Ballier
2019-02-04 15:20                   ` Rich Freeman
2019-02-04 17:06                   ` Ian Stakenvicius
2019-02-04 18:32                     ` Mike
2019-02-04 18:44                       ` Rich Freeman
2019-02-04 14:28 ` Virgil Dupras
2019-02-04 14:35 ` Rich Freeman
2019-02-04 17:18 ` Thomas Deutschmann

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox