[gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Ryan Hill]

Peter wrote:

> Chris, I am not familiar enough about gentoo's hierarchy, politics, or
> team responsibilities to question your sincerity or authority to say
> something like: Sorry, but if it isn't supported, it doesn't belong on
> Gentoo infrastructure.

Then please trust that these people who are familiar enough actually know what
they're talking about.

--de.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Luis Francisco Araujo]

Stefan Schweizer wrote:

Luis Francisco Araujo wrote:
  

Fine. I highly agree on that, now my question is,
why this needs to be officially supported?



See
"Why does this have to be on official gentoo hardware?"

http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq

  
" The FAQ is offline due to ongoing discussion on this matter - expect a 
reworked FAQ when it has been reviewed." ?

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Stefan Schweizer]

Luis Francisco Araujo wrote:
> Fine. I highly agree on that, now my question is,
> why this needs to be officially supported?

See
"Why does this have to be on official gentoo hardware?"

http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Chris Gianelloni]

On Fri, 2006-06-09 at 13:28 +0200, Carsten Lohrke wrote:
> > we do support it security wise, we will be reacting upon security issues.
> > We do have package.mask support in the overlay and we are going to use it.
> > The ebuilds have a quality, repoman is required to be run. Also
> > contributors should be knowing what they are doing - they are submitting an
> > ebuild to the sunrise overlay, it needs to follow certain standards.
> 
> See, I don't go over this bridge, that an overlay of arbitrary packages, with 
> varying skills and knowledge needed, can be decently controlled with very few 
> people caring and not having a security team backing you up.

I couldn't agree more.  With the entire security team, plus arch teams,
plus package maintainers, plus arch testers, it is *still* a complex job
to maintain security in the tree.  However, this group thinks that
without any backup support whatsoever, that they'll be able to maintain
the security of a project with countless contributors of varying degrees
of skill and proficiency in writing ebuilds, as well as the security of
the packages themselves.

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


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Ciaran McCreesh]

On Fri, 9 Jun 2006 11:05:56 +0100 "Chris Bainbridge"
<[EMAIL PROTECTED]> wrote:
| On 09/06/06, Edward Catmur <[EMAIL PROTECTED]> wrote:
| > And what if they do know what they're doing, and what they're doing
| > is subverting Gentoo systems en masse? You're proposing to hand out
| > commit access to anyone who makes a case on IRC; you have no way to
| > tell that they aren't an attacker.
| 
| This is the way the system currently works. I'm sure any decent
| motivated hacker would be able to fix a few ebuilds, hang out on irc,
| do the quiz, and gain cvs commit access. There are no identity checks
| when you become a gentoo developer; it's all about reputation.

And in theory, you have to build up quite a bit more of a reputation
and talk to quite a few people and have your dev application seen and
commented upon by existing developers who can have it cancelled if they
deem it inappropriate, which is quite a bit harder to do than what is
being proposed here. Of course, the practice is, uh, somewhat lacking
of late...

-- 
Ciaran McCreesh
Mail: ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Carsten Lohrke]

On Friday 09 June 2006 02:53, Stefan Schweizer wrote:
> > It also doesn't answer the questions of security and maintenance.  Are
> > genstef and jokey going to be responsible for the security of every
> > single package in the overlay?
>
> Yes, we will be acting upon all issues that we hear about.

...

> > that is neither supported security wise, nor is
> > ensured that the ebuilds have a minimal quality (do not fubar a users
> > system).
>
> we do support it security wise, we will be reacting upon security issues.
> We do have package.mask support in the overlay and we are going to use it.
> The ebuilds have a quality, repoman is required to be run. Also
> contributors should be knowing what they are doing - they are submitting an
> ebuild to the sunrise overlay, it needs to follow certain standards.

See, I don't go over this bridge, that an overlay of arbitrary packages, with 
varying skills and knowledge needed, can be decently controlled with very few 
people caring and not having a security team backing you up.


Carsten


pgpjJeyxOwK7k.pgp
Description: PGP signature

Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Chris Bainbridge]

On 09/06/06, Edward Catmur <[EMAIL PROTECTED]> wrote:

And what if they do know what they're doing, and what they're doing is
subverting Gentoo systems en masse? You're proposing to hand out commit
access to anyone who makes a case on IRC; you have no way to tell that
they aren't an attacker.


This is the way the system currently works. I'm sure any decent
motivated hacker would be able to fix a few ebuilds, hang out on irc,
do the quiz, and gain cvs commit access. There are no identity checks
when you become a gentoo developer; it's all about reputation.
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Edward Catmur]

On Fri, 2006-06-09 at 02:53 +0200, Stefan Schweizer wrote:
> Stefan Schweizer wrote:
> it is actually encouraged to update bugzilla when changes are made in the
> overlay.

Encouraged? If you leave it at that, people will forget, and things will
get out of sync. At the very least you should supply per-package rss
feeds and email subscriptions. Otherwise this will be a downgrade in
functionality from the current bugzilla system. (Which I think is
perfectly fine as it is.)

> The ebuilds have a quality, repoman is required to be run. Also contributors
> should be knowing what they are doing - they are submitting an ebuild to
> the sunrise overlay, it needs to follow certain standards.

And what if they do know what they're doing, and what they're doing is
subverting Gentoo systems en masse? You're proposing to hand out commit
access to anyone who makes a case on IRC; you have no way to tell that
they aren't an attacker. 

Part of the reason becoming a dev is expensive is that it provides a
barrier for attackers (and gives recruiters time to check that the
candidate is who they claim to be). By using Gentoo resources for this
project you're implying that the ebuilds can be trusted; hordes of users
*will* sync with the sunrise overlay, giving an attractive target to
attackers. (Or what if they're attacking overlays.gentoo.org itself?
This stuff is shell code; some well-meaning person's going to source it
at some point.)

And similarly, Gentoo's reputation would be immeasurably damaged if an
attacker succeeded in sneaking malicious code in. (Don't say you'll
review it; can you review every line of a 20K gcc4-compatibility patch?
Have you read the Underhanded C Contest?[1])


Ed


[1] http://www.brainhz.com/underhanded/


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Luis Francisco Araujo]

Peter wrote:

On Thu, 08 Jun 2006 02:42:03 +0200, Stefan Schweizer wrote:

  

Hi,

I have founded a new Gentoo Project for the Gentoo User Overlay.

The intention is to give contributors a single place to put their ebuilds -
a place where they can be downloaded, updated and be moved to portage more
easily than through bugzilla. It is also a good place for users who would
like to become developers to learn how to commit and how to not break the
tree.



I think this answers an important shortcoming of the bugzilla approach:
vis, some bugs will never make it to the tree -- for any number of
reasons. Take, for example, http://bugs.gentoo.org/show_bug.cgi?id=103354,
which has an enhancement request for what is now called beyond-sources. A
amalgamation of the arch, ck, tiger, nitro, and suspend2 sources. While on
the kernel, IRC, I enquired about it, since I had just updated an ebuild
for it, and was told unequivocally that there was no interest on the
kernel team's part for adding this source tree to sys-kernel. Not maybe,
not let's have a look at it, not come back in a month after testing. Just
NO.

And, I'm fine with that. That's their job -- to protect the quality of
their project, and to keep things relatively safe and manageable.

Nonetheless, the bug is active, with a good number of people subscribing
to it and contributing to it. The sunshine overlay would be an ideal place
to store a kernel source tree or any project which would never find a home
in portage.

  
If the ebuild will never find a home in portage, then it shouldn't be 
officially supported.

What you are proposing is like to setup a parallel portage tree.


--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Stefan Schweizer]

Stefan Schweizer wrote:
> ..commit their changes to the overlay instead of updating the bugzilla
> every time.
it is actually encouraged to update bugzilla when changes are made in the
overlay.

Here are some more things I found in the current thread:
chris
> It also doesn't answer the questions of security and maintenance.  Are
> genstef and jokey going to be responsible for the security of every
> single package in the overlay?
Yes, we will be acting upon all issues that we hear about.

chris
> How are 
> ebuilds going to get from this overlay into the official repository?
The people who committed them to the overlay will move them to the tree
eventually when they are developers - otherwise any developer can move them
if he likes to. Of course taking full responsibility of it, it is also
mentioned in the overlay project documentation, that automatic tools for
committing to the tree are not allowed.


antarus
> The point of the 
> Sunrise project as I understand it is to aid in the development of 
> ebuilds in maintainer-wanted, such that they may improve and be added to 
> the tree; as well as to give frequent 'not quite a dev' and 'I don't 
> have a bunch of time but would like to help' people a place to commit to.
Have to agree here :)

chris
> Why is there access controls?
Because we are just following the overlays.g.o standards. There is no actual
access controls, because we are not refusing valid requests currently.
valid requests = come with a valid change they want to make.

carlo
> that is neither supported security wise, nor is 
> ensured that the ebuilds have a minimal quality (do not fubar a users 
> system).
we do support it security wise, we will be reacting upon security issues. We
do have package.mask support in the overlay and we are going to use it.
The ebuilds have a quality, repoman is required to be run. Also contributors
should be knowing what they are doing - they are submitting an ebuild to
the sunrise overlay, it needs to follow certain standards.

peter
> The sunshine overlay
nice name :)
> Warn users that ebuild in o.g.o come with no assurances whatsoever, and
> let the market decide if this is a source worthy of use!
That is the plan.

g2boojum made some interesting suggestions about how bugzilla could be
automatically connected with an overlay - unfortunately no one is working
on that.

flameeyes 21:38:17
> I would prefer if people would still comment on the bugs when they do some 
> changes on the overlay so that at least we know that.
yeah that is already suggested by the current guide it is useful for
maintainers to know about contributors.
> eclasses
The eclass/ subdirectory has been blocked in the overlay - It is not
possible to commit there.
If eclasses are needed they need to go through the usual gentoo-dev-review
and need to be committed to the main portage tree.

- Stefan

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Chris Gianelloni]

On Thu, 2006-06-08 at 12:26 -0400, Peter wrote:
> I think this answers an important shortcoming of the bugzilla approach:
> vis, some bugs will never make it to the tree -- for any number of
> reasons. Take, for example, http://bugs.gentoo.org/show_bug.cgi?id=103354,
> which has an enhancement request for what is now called beyond-sources. A
> amalgamation of the arch, ck, tiger, nitro, and suspend2 sources. While on
> the kernel, IRC, I enquired about it, since I had just updated an ebuild
> for it, and was told unequivocally that there was no interest on the
> kernel team's part for adding this source tree to sys-kernel. Not maybe,
> not let's have a look at it, not come back in a month after testing. Just
> NO.
> 
> And, I'm fine with that. That's their job -- to protect the quality of
> their project, and to keep things relatively safe and manageable.
> 
> Nonetheless, the bug is active, with a good number of people subscribing
> to it and contributing to it. The sunshine overlay would be an ideal place
> to store a kernel source tree or any project which would never find a home
> in portage.

See, that's the misconception.  An overlay for this set of sources, and
possibly other sources, would be what "fits" in better with the original
idea of overlays.gentoo.org, as it was presented before it was approved.

Here's the problem, as I see it.  If you're filing a bug and you have
this "sunshine" overlay in your overlay list, I have exactly 0 clue what
you might be using from this overlay, since it covers *everything*.
This means that I, as a package maintainer, have no idea if you've used
some modified kernel/glibc/gcc/whatever that could be affecting my
package inadvertently.  This means I have exactly 2 choices, spend time
researching what is and isn't in this overlay and determine if any of it
could possibly effect my package and *then* start to try to troubleshoot
the bug, or mark it as RESOLVED-INVALID (or whatever) and ask you to try
again without the overlay.

It is a *huge* amount of overhead.

On the other hand, if you had a "kernel-sources" overlay, and are having
a problem compiling a non-kernel package, it is not very likely that the
kernel is the source of the problem, so the overhead is minimal to none.
The name of the overlay matches what the "project" would be, and
everything is transparent to both the user and also to the developer.

Were there a rule that said that *nothing* from the tree could be
present in this overlay, then it wouldn't be nearly as much of a
problem.  It would still have the problem presented above, but it would
be slightly less of a problem, since I now don't have to worry about if
your version of knights is the one from the tree or from the overlay.

> As I see it, there are really two main issues with bugzilla. One, is to
> resolve open ebuild enhancement bugs. Mark them somehow so it's clear the
> bug has been reviewed and an action determined. CANTFIX/WONTFIX is harsh,
> but if that's what it is, then mark it! The second issue is the orphaning
> of packages which have merit, but no maintainer. Again, the sunshine
> overlay would provide a home for those packages. It will also allow the
> user to take ownership of a project, get some experience, and maybe decide
> to become a dev. And, should that occur, then, lo, the orphaned package
> may have a maintainer someday.

This is something that I do not get.  Why exactly does everything have
to be resolved in some specific time frame?  Is "when I get to it" not
good enough?  I mean, it works for Linus, right?  ;p

As for packages that have merit, this is quite simple.  If the package
has enough of a good following, it will get picked up.  The likely
reason why many of the maintainer-wanted packages are in the state
they're in is simply because there isn't enough interest in the package.
In this particular instance, I can see an external overlay being useful.
However, there already is one.  It is called "breakmygentoo".  Do we
really need to duplicate their functionality?

> So, hopefully, as the overlay project moves forward, it will help take
> some of the heat off bugzilla and allow for the offering of more ebuilds
> to userland.

I sincerely hope it doesn't effect bugzilla in any way.  I have no
problem with users getting access to ebuilds, but many of these ebuilds
simply are not ready for anyone to get them "automatically".  Having an
ebuild on a bug makes it easily searchable.  Having an ebuild on a bug
makes it easy to peer review.  Having an ebuild on a bug means the user
needs to explicitly add the ebuild to their overlay.

The idea behind the overlays project, as it was presented, was to assist
projects in doing development by allowing outside contributors to more
easily interact with specific projects or teams.  It was not designed to
bypass Gentoo's security or quality assurance policies, nor was it
designed to allow a mechanism to give our users substandard ebuilds.

The idea isn't so bad, but the benefit

Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Henrik Brix Andersen]

On Thu, Jun 08, 2006 at 12:26:50PM -0400, Peter wrote:
> And, I'm fine with that. That's their job -- to protect the quality of
> their project, and to keep things relatively safe and manageable.
> 
> Nonetheless, the bug is active, with a good number of people subscribing
> to it and contributing to it. The sunshine overlay would be an ideal place
> to store a kernel source tree or any project which would never find a home
> in portage.

What's wrong with using BMG for uofficial and potentially broken stuff
like your proposed beyond-sources?

Regards,
Brix
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd


pgpQCfkMPAMYB.pgp
Description: PGP signature

Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Henrik Brix Andersen]

On Thu, Jun 08, 2006 at 12:27:47PM -0400, Chris Gianelloni wrote:
> Does anyone else see this as a problem?

I think it is clear from the comments in this thread that your view is
shared by many other Gentoo developers.

Regards,
Brix
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd


pgpLMwBnP2GUo.pgp
Description: PGP signature

Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Ryan Tandy]

Peter wrote:

Nonetheless, the bug is active, with a good number of people subscribing
to it and contributing to it. The sunshine overlay would be an ideal place
to store a kernel source tree or any project which would never find a home
in portage.


Pardon me if I'm totally confused, but isn't this what BMG is for?
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Chris Gianelloni]

On Thu, 2006-06-08 at 18:04 +0200, Stefan Schweizer wrote:
> Please do not comment on this if you have no real improvements to make and
> just fell like commenting, "flaming" it.

No.  A flame is being insulting to someone.  Pointing out problems with
an idea is not flaming.  Please quit trying to use this term to stifle
any comments from anyone that thinks this idea is not good, and has
valid points why they think so.

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


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Chris Gianelloni]

On Thu, 2006-06-08 at 17:29 +0200, Stefan Schweizer wrote:
> Jon Portnoy wrote:
> 
> > On Thu, Jun 08, 2006 at 09:32:13AM -0400, Thomas Cort wrote:
> >> On Thu, 08 Jun 2006 09:20:18 -0400
> >> Chris Gianelloni <[EMAIL PROTECTED]> wrote:
> >> > Please keep the games bugs in bugzilla.  Making this change is a direct
> >> > change in games team policy without any prior notice to the games team
> >> > and without our permission.
> 
> We have good instructions on our trac wiki page[1] for how to work with the
> overlay. The bottom of the page, point 6) adresses your problem.

Not really.  You've taken what was a simple and open way of addressing
ebuild requests, and turned it into a closed forum.  With a bug, anyone
with a bugzilla account can *contribute* anything that they want, and it
is all peer-reviewed.  With this overlay, only people that are given
access will be allowed to contribute anything.  Also, who is going to
control access to this resource?  Why *is* there access controls?  I
know that I'm going to hear "security" as a response, but it is a false
one.  We already had a completely open resource where any of our users
can contribute any ebuilds that they want.  You've created a more
restrictive and less useful version of this and increased the workload
on any developers whose packages are affected, such as the games team
with the inclusion of xmoto, which has been rejected in its current
state, and knights, which is currently in the tree *and* maintained.

> > I do not object to the concept of ebuilds in overlays.
> > 
> > I do very much object to using any gentoo.org infrastructure or
> > subdomains to do so. If someone is going to tackle that, it should be
> > done outside of Gentoo proper. We don't need to be stuck maintaining and
> > supporting a semiofficial overlay.
> 
> This is a problem, that we are working on, see [2]
> It is obvioous to see if an ebuild comes from an overlay or not with that
> change. Due to the good metastructure and project support in gentoo it is
> possible to have most of the overlay-work done in the projects [3] and [4]
> 
> [1] http://overlays.gentoo.org/proj/sunrise
> [2] http://bugs.gentoo.org/136031
> [PATCH] Display a warning when an overlay-ebuild fails
> [3] http://www.gentoo.org/proj/en/overlays
> [4] http://www.gentoo.org/proj/en/overlays/sunrise
> 
> I am still against the idea of turning this into a flamewar. Better no
> comments than flaming comments. Please - keep it constructive.

Nobody has turned this into a flame war.  We are trying to provide
constructive comments.  Just because a comment points out ways why this
is a bad idea doesn't make it a flame.

The only thing that bothers me is the fact that this was done and is
something that was explicitly stated would not happen with the overlays
project.  We now have a semi-official secondary repository, run by a
small group of developers, allowed to touch *any* package in the tree
however they see fit, whether it goes against the policies of the
package's maintainers or not.  I'm sorry, but this is not in the spirit
of cooperation and working together so much as it is in the spirit of
doing what you want, policies be damned.

Were this limited *solely* to packages that need maintainers, I would
have less of a problem than it being used, as it is currently, to
explicitly work outside of the policies of established projects.  As I
stated several times to you now when you brought up the idea of a games
overlay just so you could maintain packages how you wanted, you're more
than willing to keep packages that belong under the games herd in a
personal *developer* overlay.  However, what you've done here is said
that you're more important than the established practices of another
project, and blatantly disregarded their policies, establishing a
"project" that gives you free reign to do whatever you wish.

Does anyone else see this as a problem?

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


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Peter]

On Thu, 08 Jun 2006 02:42:03 +0200, Stefan Schweizer wrote:

> Hi,
> 
> I have founded a new Gentoo Project for the Gentoo User Overlay.
> 
> The intention is to give contributors a single place to put their ebuilds -
> a place where they can be downloaded, updated and be moved to portage more
> easily than through bugzilla. It is also a good place for users who would
> like to become developers to learn how to commit and how to not break the
> tree.
> 
I think this answers an important shortcoming of the bugzilla approach:
vis, some bugs will never make it to the tree -- for any number of
reasons. Take, for example, http://bugs.gentoo.org/show_bug.cgi?id=103354,
which has an enhancement request for what is now called beyond-sources. A
amalgamation of the arch, ck, tiger, nitro, and suspend2 sources. While on
the kernel, IRC, I enquired about it, since I had just updated an ebuild
for it, and was told unequivocally that there was no interest on the
kernel team's part for adding this source tree to sys-kernel. Not maybe,
not let's have a look at it, not come back in a month after testing. Just
NO.

And, I'm fine with that. That's their job -- to protect the quality of
their project, and to keep things relatively safe and manageable.

Nonetheless, the bug is active, with a good number of people subscribing
to it and contributing to it. The sunshine overlay would be an ideal place
to store a kernel source tree or any project which would never find a home
in portage.

As I see it, there are really two main issues with bugzilla. One, is to
resolve open ebuild enhancement bugs. Mark them somehow so it's clear the
bug has been reviewed and an action determined. CANTFIX/WONTFIX is harsh,
but if that's what it is, then mark it! The second issue is the orphaning
of packages which have merit, but no maintainer. Again, the sunshine
overlay would provide a home for those packages. It will also allow the
user to take ownership of a project, get some experience, and maybe decide
to become a dev. And, should that occur, then, lo, the orphaned package
may have a maintainer someday.

So, hopefully, as the overlay project moves forward, it will help take
some of the heat off bugzilla and allow for the offering of more ebuilds
to userland.

JM2C


-- 
Peter


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Lance Albertson]

Stefan Schweizer wrote:

> Please do not comment on this if you have no real improvements to make and
> just fell like commenting, "flaming" it.

Please stop ending every reply by ignoring the real issues and claiming
its just people 'flaming'. If you honestly think that every person that
replies against your idea is flaming then you need to open your eyes up
and see the valid concerns they have (which I agree most on).

I'm not at all impressed by your answers for all the questions brought
up thus far. Please be more detailed in the reasoning and follow through
 on questions. Ignoring them will only make the project less credible. I
do not support such tactics on infra if this is certainly the case.

Cheers-

-- 
Lance Albertson <[EMAIL PROTECTED]>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Stefan Schweizer]

foser wrote:
> I don't think the problem with maintainer-wanted ebuilds is that they
> are crappy, but that there is no dev willing to maintain them and ensure
> their quality over time. 'sunrise' (who came up with that name ? cheap
> asian poetry attempt) doesn't change that by adding it to an 'official'
> overlay.

The sunrise name name from Patrick Lauer and I personally really like it :)

> 
> Instead of tackling the real problem -the lack of maintainers to deal
> with all requests- 'sunrise' is trying to create a backdoor for
> unreliable maintained stuff to enter the tree.

Please, you are confusing "overlay" and "tree" here.

And yes - I do try to tackle the real problem with this project. I am hoping
to teach quite a few people how to write ebuilds and contribute with the
overlay. I am already beeing contacted by interested people and it will
only help the situation come better. Eventually a few good recruits might
be the result of this project

Also the sunriose overlay is an attempt to solve the  unreliable maintained
problem. You see that for example today we are committing a bunch of
gcc-4.1 fixes for ebuilds that are obviously "unreliable maintained" in
gentoo. The sunrise overlay helps to fix stuff quicker and extends the
basis of people that can do maintaining work.

Please do not comment on this if you have no real improvements to make and
just fell like commenting, "flaming" it.

Kind regards,
- Stefan

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Stefan Schweizer]

Jon Portnoy wrote:

> On Thu, Jun 08, 2006 at 09:32:13AM -0400, Thomas Cort wrote:
>> On Thu, 08 Jun 2006 09:20:18 -0400
>> Chris Gianelloni <[EMAIL PROTECTED]> wrote:
>> > Please keep the games bugs in bugzilla.  Making this change is a direct
>> > change in games team policy without any prior notice to the games team
>> > and without our permission.

We have good instructions on our trac wiki page[1] for how to work with the
overlay. The bottom of the page, point 6) adresses your problem.


> I do not object to the concept of ebuilds in overlays.
> 
> I do very much object to using any gentoo.org infrastructure or
> subdomains to do so. If someone is going to tackle that, it should be
> done outside of Gentoo proper. We don't need to be stuck maintaining and
> supporting a semiofficial overlay.

This is a problem, that we are working on, see [2]
It is obvioous to see if an ebuild comes from an overlay or not with that
change. Due to the good metastructure and project support in gentoo it is
possible to have most of the overlay-work done in the projects [3] and [4]

[1] http://overlays.gentoo.org/proj/sunrise
[2] http://bugs.gentoo.org/136031
[PATCH] Display a warning when an overlay-ebuild fails
[3] http://www.gentoo.org/proj/en/overlays
[4] http://www.gentoo.org/proj/en/overlays/sunrise

I am still against the idea of turning this into a flamewar. Better no
comments than flaming comments. Please - keep it constructive.

Kind regards,
- Stefan

-- 
gentoo-dev@gentoo.org mailing list