Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Markus Ullmann]

First let me state this one really important thing:

The sunrise project is a project on its own. We're about to convert it
to a TLP to make clear that it shares nothing with the overlay project
except the hardware ressources and the overlay feature of portage.

Chris Gianelloni wrote:
> On Thu, 2006-06-08 at 20:58 +0200, Markus Ullmann wrote:
>> To clarify things a bit (hopefully):
>>
>> 1) security
>>
> I know that when I spoke of security, I was not only talking about the
> security of letting non-developers commit to an overlay that is, by
> design, for end users, but also of the implications of ensuring that any
> packages in these overlays are not vulnerable to exploits.

You're right here, there is a chance that your system gets vulnerable.
But this isn't limited to this one overlay. All overlays are affected here.

>> 2) responsibility
>>
>> As already mentioned at 1), it is an overlay. The devs on sunrise do
>> keep an eye on it and all ebuilds do have to pass at least repoman and
>> some basic QA checks (currently done when porting them from bugs.g.o) so
>> that they don't do some rm -rf / thing. They should be improved by the
>> contributors then so that we have two things here: a) a contributor who
>> can contribute good-quality ebuils and b) a good ebuild to be picked up
>> by a dev and ported to the tree
>
> The problem is that you are only checking on the initial commit.  Go
> back to point #1 (security).

You just assume this, no real reason/example for it.

> Again, the entire concept of overlays.gentoo.org was stated again and
> again that this would *not* be the result of the project.  Many of the
> maintainer-wanted ebuilds are quite good, many need to be completely
> rewritten to even work properly.

First let me say this. We don't blindly commit things here nor do we
commit everything from m-w bugs. There is this interface inbetween
called human intelligence.

So I can convince you that I do look at things that are committed.

> This also completely missing the point that most of the things in
> maintainer-wanted are there because there is not a developer interested
> in them.  How will this change by moving the ebuild into an overlay, I
> have yet to hear.

Well if you can look / test a bit easier, that helps a lot... Some
(won't exclude myself here) are just a bit lazy if they see a bunch of
things to download, rename and move instead of a single checkout command ;)

>> 3) replacement for bugs.g.o
>>
>> This project isn't a try to replace the contributions to bugs. It should
>> just help to fetch and update things. We have help from bug-wranglers
>> here (well, at least from jakub) to keep the overlay in sync with it so
>> that one can say "Yeah, my-example/myapp r158 has this and this issue,
>> here is a fix for it" and then either the sunrise-devs or one of the
>> project-contributors commits it to the overlay.
>
> Honestly, having to break out a subversion client to check a fix
> immediately sounds like extra work.  It is usually much easier to simply
> look at the attachment online and make a decision immediately.

You don't need a subversion client, you perhaps notice the http in front
of the url.. just open it up in your browser and you get the source
immediately.
Or, if you want some history like sources.g.o, you can do so as well here:
http://overlays.gentoo.org/proj/sunrise/browser/

>> 4) workload on devs
>>
>> Well I really have problems to see increased workload on devs here who
>> don't actively support the project. They can scour bugzie for
>> interesting ebuilds and instead of fetching files, renaming them, moving
>> them to a local overlay dir, just do a svn co
>> http://overlays.gentoo.org/svn/proj/sunrise/sys-auth/pam_skey/ (as an
>> example here) and you have all needed files already prepared to look at
>> them or to give them a try.
>
> Except that I can *look* at an ebuild without having to break out a
> subversion client currently.
See my answer in 3)

  Also, you completely gloss over the fact
> that this is a overlay designed for end-user usage.  This means that
> anything in this overlay is *very* likely to be on user's machines and
> cause any number of possible problems.  Let's use your pam_skey as an
> example.  Now, let's say that someone has this installed, and has
> configured it improperly.  They file a bug because they are unable to
> login, and the pam maintainers receive the bug.
> How exactly are they
> supposed to know that this user has pam_skey even *available* to them
> when all they see as an overlay is "sunrise" and not the
> project-specific overlays that overlays.gentoo.org was designed for?

Well as the ebuilds in there already have open bugs, comments can be
attached there.
Secondly, the portage team already integrates a patch to show you a
bright warning in the error that you use an overlay... also, if you take
a look at the PORTDIR_OVERLAY in emerge --info, you can get really fast
that in case you don't find the ebuild in tree that it doesn't belong
there. (We even get bugs originating at other overlay's ebuils...)


> All of the time wasted to determine that the user has done something
> unsupported to break their system is time that this developer could be
> working on a problem with a package that is actually in the portage
> tree, which is our primary product.

bug wranglers already do this job currently...

>
>> 5) the tarball problem
>>
>> On some bugs we also notice that people contribute tarballs instead of
>> ebuilds and the files as such.
>> Some apps need a change on a bunch of files with every version bump.
>> Take MailScanner as an example  (
>> http://bugs.gentoo.org/show_bug.cgi?id=36060 ). Many devs cry out loud
>> when they come across a tarball on bugzie. It is not the best way of
>> contribution, I know that myself. But take it the otherway around.
>> Someone out there took time (on some apps it is really much time) and
>> provided an ebuild. Maybe he is new to it and doesn't know much about
>> bugzie (no usability talk required here, done every 3 months on bugzie
>> devel ml) then they post their hard work there. Then a dev comes along
>> and says "never ever do attach tarballs blah blubb", the contributor
>> feels scared as it was his first contribution and the dev was crying out
>> loud and would surely think twice if the work done is worth it.
>
> An overlay will have exactly 0 impact on this.  You have already stated
> that the ebuilds will come from bugzilla.  That means that a user can
> still post a tarball and can still have a developer request that he not
> post a tarball again.  This is a non-issue in this conversation.

Well it is partly, as the dev isn't needed to clarify things here. If we
come across something like this, we'll work these things out.. i.e.
offer to send us the tarball to commit or (if the user has proven
himself trustworthy to the project admins) give him commit access to
fire things up himself.

>> 6) problems on infra hardware
>>
>> Well Lance arised that, so if infra has that big concerns about this
>> project (I personally see no hard reason for it, but let the infra guys
>> handle it how they want), then feel free to drop me a note and we host
>> it elsewhere. I really see a great chance for contributors here as they
>> can improve themselves here and if they contribute good quality, even
>> commit themselves and learn how to handle maintainership. You all know
>> we also have some people out there that would like to maintain just one
>> or two packages. Now we call it proxy maintainership but why not giving
>> them commit access to sunrise then? They can maintain it here without
>> the whole workload as dev, but maybe they get encouraged by doing so and
>> then become a dev later. Lots of options are possible here.
>
> You miss something.  Things in this overlay still don't make it into the
> official tree unless a maintainer picks it up.  Taking an ebuild from
> bugzilla and being responsible for it and taking an ebuild from an
> overlay and being responsible for it have the exact same cost on
> developer resources.  Someone *still* has to maintain it.

Yup, but the proxy maintainerships are much easier to track as they're
done on one central place...

Greetz,
Jokey