From: Rich Freeman <rich0@gentoo.org>
To: gentoo-project@lists.gentoo.org
Subject: Re: [gentoo-project] Status update of Sunrise project?
Date: Sat, 11 Apr 2015 07:54:56 -0400 [thread overview]
Message-ID: <CAGfcS_nUA8rRvppHKgKpirjs3iF1GGDbotAzFO8_WgMVBUTavA@mail.gmail.com> (raw)
In-Reply-To: <5528F375.30009@gentoo.org>
On Sat, Apr 11, 2015 at 6:12 AM, hasufell <hasufell@gentoo.org> wrote:
> On 04/11/2015 07:38 AM, Ben de Groot wrote:
>>
>> Since you said you are the only remaining active developer on Sunrise,
>> and the proxy-maintainers team has quite a few more, and we now have
>> git pull requests for the main repo, I don't think that reason is
>> quite so important anymore.
>>
>> Of course you are free to continue with Sunrise, but in my opinion the
>> first port of call for user contributions should be proxy-maintainers.
>> It is better to include useful packages in the main repo, don't you
>> agree?
>>
>
> Although you didn't ask me I don't agree, because the statement is too
> broad.
>
> Unless gentoo workflow gets fixed (not just by replacing the VCS)...
> importing something into the tree often slows down contribution activity
> and also version bumps, unless... you _use_ that package yourself.
>
> Proxy-maintainers do not solve that problem. Neither does sunrise.
Since most of us want the gentoo repository to be as easy to
contribute to as possible, I'd be interested in your discrete answers
to:
1. What does proxy-maintainers lack in comparison to sunrise
exclusively. The immediate question is whether sunrise should be
migrated to proxy-maintainers, so this specific comparison is
important.
2. What does proxy-maintainers lack in comparison to overlays in
general, beyond QA standards? (By QA standards I'm more concerned
with our QA goals such as not having security-vulnerable packages in
the tree, having consistent depgraphs, having PMS-compliant ebuilds,
etc. I'd rather not discuss changes to these, unless there really is
something most of us don't think is necessary. How we go about
achieving those goals is fair game. ie, one "benefit" of overlays is
that you can commit an ebuild that contains only line noise, and I'm
not so interested in that. However, maybe another benefit of overlays
is that you can go about quality in a different way that makes it
easier, ultimately reaching a level of quality comparable to the
gentoo repository.)
--
Rich
next prev parent reply other threads:[~2015-04-11 11:54 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-06 6:15 [gentoo-project] Status update of Sunrise project? Ben de Groot
2015-04-09 18:57 ` Thomas Sachau
2015-04-09 22:55 ` Ben de Groot
2015-04-10 16:14 ` Thomas Sachau
2015-04-11 5:38 ` Ben de Groot
2015-04-11 10:12 ` hasufell
2015-04-11 11:54 ` Rich Freeman [this message]
2015-04-12 9:59 ` hasufell
2015-04-12 10:02 ` Patrick Lauer
2015-04-12 10:04 ` hasufell
2015-04-12 10:13 ` Patrick Lauer
2015-04-12 10:21 ` hasufell
2015-04-12 10:34 ` Patrick Lauer
2015-04-12 11:22 ` Rich Freeman
2015-04-12 12:03 ` Michał Górny
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGfcS_nUA8rRvppHKgKpirjs3iF1GGDbotAzFO8_WgMVBUTavA@mail.gmail.com \
--to=rich0@gentoo.org \
--cc=gentoo-project@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox