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

[Chris Gianelloni]

On Thu, 2006-06-08 at 20:58 +0200, Markus Ullmann wrote:
> To clarify things a bit (hopefully):
>
> 1) security
>
> This is not the main tree, just a normal overlay. Okay, some non-devs
> contribute here but doesn't change the fact that it is just an overlay
> as any other out there in the world. Well, it is a bit different. Here
> are some devs keeping an eye on the evolution and can help people with
> doing it right and thus get better contributions in the end.

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.

> 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).

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.

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.

> 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.

> 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.  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?

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.

> 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.

> 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.

> 7) non maintainer-wanted things
>
> Some ebuilds found their way into the overlay, we talked about that
> internally and I'll remove them after this mail is sent out, so that we
> stick to maintainer-wanted things here.

Thank you.  This was a major concern for myself, and I'm sure quite a
few others.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux