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

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

[Stefan Schweizer]

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.

You can find the project page as a subproject of the overlays project [1]

The overlay is available on overlays.gentoo.org [2] 

Initially jokey and myself will be working on this. The current focus is to
migrate ebuilds from bugzilla into the overlay and to get contributors to
commit their changes to the overlay instead of updating the bugzilla every
time.

Anyone who wants to help, please stop by in #gentoo-overlays @ freenode

[1] http://gentoo.org/proj/en/overlays/sunrise
[2] http://overlays.gentoo.org/svn/proj/sunrise

- Stefan

PS: This is an announcement - No flamewars allowed

-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

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

On Thu, 2006-06-08 at 02:42 +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.

We already *have* a single place.  It is bugzilla.

Wasn't it decided that we would *not* end up with some giant overlay
that houses all of the non-tree stuff before the overlays project was
brought into being?  Does this not completely fly in the face of that?

> You can find the project page as a subproject of the overlays project [1]
> 
> The overlay is available on overlays.gentoo.org [2] 
> 
> Initially jokey and myself will be working on this. The current focus is to
> migrate ebuilds from bugzilla into the overlay and to get contributors to
> commit their changes to the overlay instead of updating the bugzilla every
> time.

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.

> Anyone who wants to help, please stop by in #gentoo-overlays @ freenode
> 
> [1] http://gentoo.org/proj/en/overlays/sunrise
> [2] http://overlays.gentoo.org/svn/proj/sunrise
> 
> - Stefan
> 
> PS: This is an announcement - No flamewars allowed

Perhaps you should have discussed this before going and making an
assumption for the entire developer pool.

The idea itself isn't so bad as the fact that you've now essentially
taken it upon yourself to decide how *every single one of us* is going
to accept ebuilds from now on without any form of discussion.

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

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

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

[Thomas Cort]

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

On Thu, 08 Jun 2006 09:20:18 -0400
Chris Gianelloni <wolf31o2@gentoo.org> 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.

No one needs permission to put ebuilds from bugs.gentoo.org into an
overylay. The ebuilds, assuming they have the proper header, are all
"Distributed under the terms of the GNU General Public License v2".

~tcort

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

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

[Chris Gianelloni]

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

On Thu, 2006-06-08 at 09:32 -0400, Thomas Cort wrote:
> On Thu, 08 Jun 2006 09:20:18 -0400
> Chris Gianelloni <wolf31o2@gentoo.org> 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.
> 
> No one needs permission to put ebuilds from bugs.gentoo.org into an
> overylay. The ebuilds, assuming they have the proper header, are all
> "Distributed under the terms of the GNU General Public License v2".

I'm sorry, but what does this have to do with me making a request for
games ebuilds to not be included?

I really don't care if the games ebuilds are in the overlay, so long as
the latest ebuilds are *also* in bugzilla, where they belong.  Of
course, it makes it rather pointless to have to update an ebuild in two
locations, but we already *have* an official location for ebuild
submissions, and that is bugzilla.

Having to troll through some overlay only increases our work load.

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

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

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

[Diego 'Flameeyes' Pettenò]

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

On Thursday 08 June 2006 15:46, Chris Gianelloni wrote:
> Having to troll through some overlay only increases our work load.
+1 for chris

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Stephen P. Becker]

> Having to troll through some overlay only increases our work load.
> 

That and it would become an an official Gentoo BMG-style repo.  Please,
let us not officially encourage the ricers.  Some of us work very hard
to discourage this type of user behavior.

-Steve
-- 
gentoo-dev@gentoo.org mailing list

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

[Henrik Brix Andersen]

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

On Thu, Jun 08, 2006 at 10:13:45AM -0400, Stephen P. Becker wrote:
> That and it would become an an official Gentoo BMG-style repo.  Please,
> let us not officially encourage the ricers.  Some of us work very hard
> to discourage this type of user behavior.

I wholeheartedly agree with Stephen on this.

You should have brought up the idea for the Sunricers project on this
mailing for discussion instead of just going ahead and implementing
it.

Personally, I dislike the idea of having officially supported (read:
hosted on *.gentoo.org infrastructure) overlays for unmaintained
ebuilds for which nobody did any real quality assurance. I fear this
will drag Gentoo back into the old-ages of having a reputation of a
ricer-distribution; a reputation I for one have worked very hard to
get rid of during the past 2 years.

Please put this project on hold until is has been discussed properly
on this mailing list.

Regards,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 213 bytes --]

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

[Lance Albertson]

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

Henrik Brix Andersen wrote:

> Personally, I dislike the idea of having officially supported (read:
> hosted on *.gentoo.org infrastructure) overlays for unmaintained
> ebuilds for which nobody did any real quality assurance. I fear this
> will drag Gentoo back into the old-ages of having a reputation of a
> ricer-distribution; a reputation I for one have worked very hard to
> get rid of during the past 2 years.

I agree here.

When I decided to help out the overlays project, I thought I had made it
clear that I didn't want to support a BMG-style repo on official
hardware. It was for things like php, perl, etc that had their own
overlay and were actively working out specific issues for their project.
What you're proposing goes against what I supported initially.

There was a lengthy discussion about this months ago, but apparently
this group decided to ignore all the points in it and just go with this
without consulting the group first. If you can't sort out the issues
that have been brought out here, I'm afraid I'm going to have to decline
my support on infra hardware for this specific project (but not the
other overlays so people don't have a fit :-) ).

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

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

[Jon Portnoy]

On Thu, Jun 08, 2006 at 09:32:13AM -0400, Thomas Cort wrote:
> On Thu, 08 Jun 2006 09:20:18 -0400
> Chris Gianelloni <wolf31o2@gentoo.org> 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.
> 
> No one needs permission to put ebuilds from bugs.gentoo.org into an
> overylay. The ebuilds, assuming they have the proper header, are all
> "Distributed under the terms of the GNU General Public License v2".
> 
> ~tcort

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.


-- 
Jon Portnoy
avenj/irc.freenode.net
-- 
gentoo-dev@gentoo.org mailing list

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

[Alec Warner]

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 <wolf31o2@gentoo.org> 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.
>>
>>No one needs permission to put ebuilds from bugs.gentoo.org into an
>>overylay. The ebuilds, assuming they have the proper header, are all
>>"Distributed under the terms of the GNU General Public License v2".
>>
>>~tcort
> 
> 
> 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.
> 

It is my understanding the the Sunrise overlay is not open to "anyone to 
commit", so it is not a contrib/  The sunrise project is the owner of 
the overlay and they are responsible for it's contents.  The people 
commiting are responsible for what they commit.  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.

-Alec
-- 
gentoo-dev@gentoo.org mailing list

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

[foser]

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

On Thu, 2006-06-08 at 11:12 -0400, Alec Warner wrote:
> It is my understanding the the Sunrise overlay is not open to "anyone to 
> commit", so it is not a contrib/  The sunrise project is the owner of 
> the overlay and they are responsible for it's contents.  The people 
> commiting are responsible for what they commit.  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.

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.

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.

- foser

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

[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

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

[Lance Albertson]

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

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 <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

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

[Chris Gianelloni]

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

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

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

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

[Chris Gianelloni]

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

On Thu, 2006-06-08 at 17:45 +0200, foser wrote:
> 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.

Don't forget the free reign it gives to the sunrise development team to
bypass any policies in place by the teams responsible for packages that
are already in the tree.

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

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

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

[Chris Bainbridge]

On 08/06/06, foser <foser@gentoo.org> 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.

One of the problems is that developer interest is transitory. The
current system suggests that a developer take personal responsibility
for ebuilds they maintain, and they maintain them until another
developer steps up. It would be nice (and I guess this is one of the
aims of sunrise) if there were a way for people to contribute ebuilds
that they are interested in at the time, but don't want to promise to
maintain forever. Think about wikipedia - how many pages would there
be if every page creator had to guarantee that they would maintain
each page indefinately?

The time it takes to actually apply fixes etc. is another point.
Bugzilla is a poor system for  sharing and managing the flow of
ebuilds and patches. It would be nice if there were a way for non-devs
to publish ebuilds/fixes using a VCS so that they could be shared and
easily pulled and applied to the main tree. It takes too long to
browse bugzilla, find bugs, find ebuilds and patches, download them,
copy to an overlay, fix digests, emerge, etc. and most users will
figure it's not worth the hassle.
-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

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

On Thu, 2006-06-08 at 17:48 +0100, Chris Bainbridge wrote:
> The time it takes to actually apply fixes etc. is another point.

This is where I'd respectfully disagree.

> Bugzilla is a poor system for  sharing and managing the flow of
> ebuilds and patches. It would be nice if there were a way for non-devs
> to publish ebuilds/fixes using a VCS so that they could be shared and
> easily pulled and applied to the main tree. It takes too long to
> browse bugzilla, find bugs, find ebuilds and patches, download them,
> copy to an overlay, fix digests, emerge, etc. and most users will
> figure it's not worth the hassle.

You mean all of the things that developers have to do, right?  Funny,
but I thought the idea for the overlays was to groom developers, not to
provide low-quality half-working ebuilds to users.

Perhaps if we had a bug-tracking system that integrated better with a
version control system, allowing for easier access to the
ebuilds/patches/etc within a bug report, yet without providing a "free
for all" as the current project suggests?  I really don't know what kind
of solution would be proper for this, but I do know that the current
idea of an overlay for the entire tree is not something that should be
taken lightly and definitely not something that should *ever* be done
without discussion.

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

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

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

[Luis Francisco Araujo]

Chris Bainbridge wrote:
> On 08/06/06, foser <foser@gentoo.org> 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.
>
> One of the problems is that developer interest is transitory. The
> current system suggests that a developer take personal responsibility
> for ebuilds they maintain, and they maintain them until another
> developer steps up. It would be nice (and I guess this is one of the
> aims of sunrise) if there were a way for people to contribute ebuilds
> that they are interested in at the time, but don't want to promise to
> maintain forever. Think about wikipedia - how many pages would there
> be if every page creator had to guarantee that they would maintain
> each page indefinately?
>
> The time it takes to actually apply fixes etc. is another point.
> Bugzilla is a poor system for  sharing and managing the flow of
> ebuilds and patches. It would be nice if there were a way for non-devs
> to publish ebuilds/fixes using a VCS so that they could be shared and
> easily pulled and applied to the main tree. It takes too long to
> browse bugzilla, find bugs, find ebuilds and patches, download them,
> copy to an overlay, fix digests, emerge, etc. and most users will
> figure it's not worth the hassle.
Yes, i agree, writting and maintaining ebuilds is a hard and 
*time-consuming* task.
So if an user can't even take the time to fix a digest, why we should 
support him
officially?.

-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Bainbridge]

On 09/06/06, Luis Francisco Araujo <araujo@gentoo.org> wrote:
> Yes, i agree, writting and maintaining ebuilds is a hard and
> *time-consuming* task.
> So if an user can't even take the time to fix a digest, why we should
> support him
> officially?.

The point is that there are lots of users who are interested in niche
packages that no developers use or are interested in. These users have
the skills to write an ebuild, and other users of the package have the
skills to fix and maintain that ebuild over time. These guys don't
mind downloading ebuilds from bugzilla and fixing digests. But there
are a larger class of users of niche packages that don't have the
ebuild skills, and don't want the hassle of bugzilla and digest
fixing. This larger group of users are the ones that would benefit
from an overlay.
-- 
gentoo-dev@gentoo.org mailing list

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

[Carsten Lohrke]

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

On Friday 09 June 2006 12:12, Chris Bainbridge wrote:
> This larger group of users are the ones that would benefit
> from an overlay.

And this larger group of people is exactly the same one, that doesn't know to 
help itself, if necessary and will suffer the most, when something goes 
wrong. This group of people shouldn't use any overlay.

I think the basic misconception is that some think we are supposed to provide 
a package just because it's requested. We need maintainers for every package. 
Without maintainers: Sorry, no. Period.


Carsten

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

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

[Luis Francisco Araujo]

Chris Bainbridge wrote:
> On 09/06/06, Luis Francisco Araujo <araujo@gentoo.org> wrote:
>> Yes, i agree, writting and maintaining ebuilds is a hard and
>> *time-consuming* task.
>> So if an user can't even take the time to fix a digest, why we should
>> support him
>> officially?.
>
> The point is that there are lots of users who are interested in niche
> packages that no developers use or are interested in. These users have
> the skills to write an ebuild, and other users of the package have the
> skills to fix and maintain that ebuild over time. These guys don't
> mind downloading ebuilds from bugzilla and fixing digests. But there
> are a larger class of users of niche packages that don't have the
> ebuild skills, and don't want the hassle of bugzilla and digest
> fixing. This larger group of users are the ones that would benefit
> from an overlay.
Fine. I highly agree on that, now my question is,
why this needs to be officially supported?
-- 
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

[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

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

[Chris Gianelloni]

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

On Thu, 2006-06-08 at 11:12 -0400, Alec Warner wrote:
> It is my understanding the the Sunrise overlay is not open to "anyone to 
> commit", so it is not a contrib/  The sunrise project is the owner of 
> the overlay and they are responsible for it's contents.  The people 
> commiting are responsible for what they commit.  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.

Ehh... except there's *already* ebuilds that are *not* under
maintainer-wanted in the overlay.

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?  Are they going to be responsible for
ensuring that the packages adhere to current ebuild standards?  How are
ebuilds going to get from this overlay into the official repository?

Not a single one of these questions has been answered, yet many
perfectly valid objections have been brought up by a few developers,
with no answers being given.

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

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

[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 <wolf31o2@gentoo.org> 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

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

[Chris Gianelloni]

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

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 <wolf31o2@gentoo.org> 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

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

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

[Henrik Brix Andersen]

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

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 <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 213 bytes --]

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

[Chris Bainbridge]

On 08/06/06, Jon Portnoy <avenj@gentoo.org> wrote:
 > 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.

There are already loads of semi-official overlays. Besides the stuff
actually hosted by gentoo (random example
http://dev.gentoo.org/~flameeyes/bzr/overlay/) there are official
groups (again, not picking on anyone but exampes would be java, php,
webapps...) with semi-official overlays. I don't know if the overlays
are actually hosted on gentoo hardware, but when they're run by gentoo
devs, publically available, and referred to in forums, bugzilla,
mailing lists etc. then that at least makes them "semi-official".
-- 
gentoo-dev@gentoo.org mailing list

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

[Diego 'Flameeyes' Pettenò]

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

On Thursday 08 June 2006 18:59, Chris Bainbridge wrote:
> Besides the stuff
> actually hosted by gentoo (random example
> http://dev.gentoo.org/~flameeyes/bzr/overlay/)
That is now actually moved on my own box :) This is going away soon as I have 
time to replace it with a fake overlay telling to use the GIT repo.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Patrick McLean]

Chris Bainbridge wrote:
> On 08/06/06, Jon Portnoy <avenj@gentoo.org> wrote:
>> 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.
> 
> There are already loads of semi-official overlays. Besides the stuff
> actually hosted by gentoo (random example
> http://dev.gentoo.org/~flameeyes/bzr/overlay/) there are official
> groups (again, not picking on anyone but exampes would be java, php,
> webapps...) with semi-official overlays. I don't know if the overlays
> are actually hosted on gentoo hardware, but when they're run by gentoo
> devs, publically available, and referred to in forums, bugzilla,
> mailing lists etc. then that at least makes them "semi-official".

These overlays are completely controlled by Gentoo developers, which is
what the overlays.gentoo.org was going to be, simply a single location
for all these developer controlled overlays. This project is an overlay
(un)controlled by random users, with no quality checks or any standards
of any kind. This is fine for non-gentoo hosted stuff (like BMG), but
hosting stuff like this on *.gentoo.org, and not having the use go
through hoops to use it is probably not a good idea from either a
security or QA standpoint.

Currently 3rd party ebuilds can live in bugzilla, and the use must
create their own overlay, and generate their own digests to use them.
Making a user put this extra work into encourages users to be more
careful, and hopefully look stuff over before using it. It also
reinforces that the package is _unsupported_, hence discouraging them
from filing any new bugs.

Having a "semi-official" overlay where users can contribute ebuilds will
open possible security problems (malicious commits) as well as be a
QA/bug triaging nightmare as developers will have to figure out whether
the ebuild the user is using came from the "official" overlay or the
official tree.
-- 
gentoo-dev@gentoo.org mailing list

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

[Luis Francisco Araujo]

Chris Bainbridge wrote:
> On 08/06/06, Jon Portnoy <avenj@gentoo.org> wrote:
> > 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.
>
> There are already loads of semi-official overlays. Besides the stuff
> actually hosted by gentoo (random example
> http://dev.gentoo.org/~flameeyes/bzr/overlay/) there are official
> groups (again, not picking on anyone but exampes would be java, php,
> webapps...) with semi-official overlays. I don't know if the overlays
> are actually hosted on gentoo hardware, but when they're run by gentoo
> devs, publically available, and referred to in forums, bugzilla,
> mailing lists etc. then that at least makes them "semi-official".
I don't agree with that "semi-official" term.

We for example have an overlay for the Haskell project. Nevertheless,
we consider it the official overlay for our group, but not for Gentoo. So
that way we can use it as our sand-box, to play with it as much as we
can, and giving commit access to even non-developers, the advantage
with this model, is that at some degree we compromise ourselves as a
group with the "little" base users who dare to test experimental stuff 
(that
probably will *never* find its way into portage), but we keep Gentoo as
project excluded from such a responsibility. And.. isn't that the real 
sense
behind the "overlay" concept?, to have an "official" overlay wouldn't 
break the
main goal of it?, and even more, an official maintainer-wanted overlay 
sounds
more crazy to me.

Regards,
-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Bainbridge]

On 09/06/06, Luis Francisco Araujo <araujo@gentoo.org> wrote:
> Chris Bainbridge wrote:
> > There are already loads of semi-official overlays. Besides the stuff
> > actually hosted by gentoo (random example
> > http://dev.gentoo.org/~flameeyes/bzr/overlay/) there are official
> > groups (again, not picking on anyone but exampes would be java, php,
> > webapps...) with semi-official overlays. I don't know if the overlays
> > are actually hosted on gentoo hardware, but when they're run by gentoo
> > devs, publically available, and referred to in forums, bugzilla,
> > mailing lists etc. then that at least makes them "semi-official".
> I don't agree with that "semi-official" term.
>
> We for example have an overlay for the Haskell project. Nevertheless,
> we consider it the official overlay for our group, but not for Gentoo. So
> that way we can use it as our sand-box, to play with it as much as we
> can, and giving commit access to even non-developers, the advantage

The Haskell overlay isn't publically available (at least, layman
doesn't know about it). That makes it quite different from the
"semi-official" overlays I gave as examples.

Whether something is "semi-official" or not is all about perception.
If people see that a project is run by gentoo developers, possibly
formed into a gentoo group, using gentoo resources (bugzilla, forums,
mailing lists etc) to discuss and organise, then there will be a
perception that the project has some semblance of officiality.
-- 
gentoo-dev@gentoo.org mailing list

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

[Luis Francisco Araujo]

Chris Bainbridge wrote:
> On 09/06/06, Luis Francisco Araujo <araujo@gentoo.org> wrote:
>> Chris Bainbridge wrote:
>> > There are already loads of semi-official overlays. Besides the stuff
>> > actually hosted by gentoo (random example
>> > http://dev.gentoo.org/~flameeyes/bzr/overlay/) there are official
>> > groups (again, not picking on anyone but exampes would be java, php,
>> > webapps...) with semi-official overlays. I don't know if the overlays
>> > are actually hosted on gentoo hardware, but when they're run by gentoo
>> > devs, publically available, and referred to in forums, bugzilla,
>> > mailing lists etc. then that at least makes them "semi-official".
>> I don't agree with that "semi-official" term.
>>
>> We for example have an overlay for the Haskell project. Nevertheless,
>> we consider it the official overlay for our group, but not for 
>> Gentoo. So
>> that way we can use it as our sand-box, to play with it as much as we
>> can, and giving commit access to even non-developers, the advantage
>
> The Haskell overlay isn't publically available (at least, layman
> doesn't know about it). That makes it quite different from the
> "semi-official" overlays I gave as examples.
>
I really don't know what "semi-official" means.

And our overlay has always been publically available,
http://haskell.org/~gentoo/gentoo-haskell/

But we don't have it as a way to offer "extra" ebuilds. We have it
for testing, and experimental works and it has been used as playground 
for new
developers too.
> Whether something is "semi-official" or not is all about perception.
> If people see that a project is run by gentoo developers, possibly
> formed into a gentoo group, using gentoo resources (bugzilla, forums,
> mailing lists etc) to discuss and organise, then there will be a
> perception that the project has some semblance of officiality.
I am not against the overlay idea, i like it very much!, and we have been
using it successfully in our team.

I just don't see the point of having another official portage tree
with maintainer-wanted packages as an overlay. Don't you see that
what you are asking for is to have another portage tree, but now,
with bunch of unmaintained and orphaned stuff, plus the extra sugar
of *dangerous* consequences as some developers have already pointed out in
this thread?

I think we already have LOT of work with only one tree.
-- 
gentoo-dev@gentoo.org mailing list

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

[Carsten Lohrke]

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

On Thursday 08 June 2006 02:42, Stefan Schweizer wrote:
> Initially jokey and myself will be working on this. The current focus is to
> migrate ebuilds from bugzilla into the overlay and to get contributors to
> commit their changes to the overlay instead of updating the bugzilla every
> time.

Can't agree with that. Users should a) post their ebuilds at bugzilla, since 
it is the place, we track request and b) get them from there, forced to 
maintain their own overlay (and actually look at each ebuild), than trust 
some arbitrary overlay, that is neither supported security wise, nor is 
ensured that the ebuilds have a minimal quality (do not fubar a users 
system).

Overlays make sense to perform changes how a whole range of packages are 
handled, to be merged with the official Portage tree, later. 

What you intend to do is just broken. Don't!


Carsten

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

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

[Josh Saddler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Carsten Lohrke wrote:
> On Thursday 08 June 2006 02:42, Stefan Schweizer wrote:
>> Initially jokey and myself will be working on this. The current focus is to
>> migrate ebuilds from bugzilla into the overlay and to get contributors to
>> commit their changes to the overlay instead of updating the bugzilla every
>> time.
> 
> Can't agree with that. Users should a) post their ebuilds at bugzilla, since 
> it is the place, we track request and b) get them from there, forced to 
> maintain their own overlay (and actually look at each ebuild), than trust 
> some arbitrary overlay, that is neither supported security wise, nor is 
> ensured that the ebuilds have a minimal quality (do not fubar a users 
> system).
> 
> Overlays make sense to perform changes how a whole range of packages are 
> handled, to be merged with the official Portage tree, later. 

Agreed. While this is in theory an excellent idea, it won't help right now. In
my opinion, what we really need is for some community members to step up and
create "the world's <lauditory adjective> Gentoo-ebuild-related "clearinghouse",
better than BMG etc., that could be used as a better means of submitting ebuilds
to bugzie. That way there's much more outside testing and widespread use before
(hopefully) very high quality ebuilds and/or overlays are submitted to bugzilla
for official Gentoo review.

So the workload on the Gentoo devs would be greatly reduced, instead of having
to (now) police ebuilds in at least two different locations. Overlays are a pain
to manage as it is. I understand that Sunrise is trying to solve the central
problem of maintainers, but right now it sounds like it's doing it in a very
roundabout, ineffective manner.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEiFKFrsJQqN81j74RAu9XAKCOuXMRWIKQqlVXpAzA9s2DvGA03QCfaGjp
f2zhH9DNu9dLONvnh1ACtK4=
=kuou
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

[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

[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

[Henrik Brix Andersen]

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

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 <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 213 bytes --]

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

[Chris Gianelloni]

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

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 benefits definitely do not outweigh the
negatives.

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

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

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

[Peter]

On Thu, 08 Jun 2006 15:51:25 -0400, Chris Gianelloni wrote:

First, let me say that I'm approaching this from a user's perspective. I
have no insight or knowledge as to the history of the overlay project or
any of the people involved. I _do_ know that since late 2004 when I first
switched to Gentoo, each week there are more bugs opened than closed.
There are also many open bugs that go back years.

In my particular frame, I want ebuilds I need or have contributed to get
into the tree. Having to download new ebuilds into local, and then have no
way to emerge update them is frustrating.

My point was about two things: 1) ebuilds that will never be committed to
portage, and 2) ebuilds that have been orphaned due to lack of interest.

As for breakmygentoo, here is my thought. As a user, I would prefer to do
all my shopping in one place. Gentoo has portage and uses ebuilds as a
package distribution mechanism. I would prefer to use gentoo's facilities
to get additional off-tree ebuilds. I don't want to have to sync all over
the place to get ebuilds of unknown origin. I would prefer to have a
sanctioned alt-gentoo ebuild repository where I know some q/a is applied
and standards adhered to.

My inference of the sunshine project was that there would be oversight and
control. That if _I_, for example wished to contribute, then I would have
to meet standards. And, on the flip side, anyone who would care to
download an ebuilt from o.g.o would be confident that the ebuild at least
meets certain quality standards. o.g.o, of course would have to disclose
that these packages are testing, and possibly experimental, but it's a
terrific opportunity to find a home for many orphaned and ignored
packages.

Using the example I brought up, about the kernel-sources, o.g.o would be
a perfect home for such a project.


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

Why? Because having two year old bugs is simply inexcusable. Especially
when many have not had any activity for a long time. Having
maintainer-wanted bugs for months on end is silly. Giving a user who files
a ebuild request or submits an ebuild deserves the chance to take
ownership of it. It's a good way to get a more experienced user, and
hopefully one day, a future dev.

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

Well as for packages getting picked up, this is not completely accurate.
Some will never get picked up, either because they are inappropriate
(hot-babe, for example), or too experimental (the kernel-source example I
cited). As for bmg, which I have to admit I had never heard about before
today, as a user, I would prefer to have everything genoo-sanctioned and
controlled. 


>> 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.
> 
Users would not be getting o.g.o ebuilds automatically. They would have to
actively emerge layman, and then select the ebuilds they want. I agree
with you that the o.g.o and the main portage tree should never be
comingled. But, I do argue that bugzilla is inefficient in getting ebuilds
resolved. And, just because o.g.o exists does not in any way mean a user
would have to or be advised to skip bugzilla. Some ebuilds will get picked
right up, others after some review. All I am suggesting is that o.g.o will
help find a home for ebuilds that are wasting away on bugzilla.


> 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 benefits definitely do not outweigh the
> negatives.

I did not read anything that implied o.g.o would bypass anything other
than a lengthy wait in bugzilla land. Other distros have their
experimental/testing branches, why can't gentoo?

-- 
Peter


-- 
gentoo-dev@gentoo.org mailing list

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

[Alec Warner]

> Why? Because having two year old bugs is simply inexcusable. Especially
> when many have not had any activity for a long time. Having
> maintainer-wanted bugs for months on end is silly. Giving a user who files
> a ebuild request or submits an ebuild deserves the chance to take
> ownership of it. It's a good way to get a more experienced user, and
> hopefully one day, a future dev.

Why inexcusable?  Why is leaving a bug open indefinately a bad thing? 
If someone wants it, they can comment on the bug.  This isn't a software 
development project (for the most part :)) so leaving a bug open causes 
no harm, other than to make it a bit difficult in some instances to find 
what you are looking for among the large number of filings.




-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

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

On Thu, 2006-06-08 at 16:23 -0400, Peter wrote:
> I did not read anything that implied o.g.o would bypass anything other
> than a lengthy wait in bugzilla land. Other distros have their
> experimental/testing branches, why can't gentoo?

*cough* ~arch *cough*

What everybody seems to miss is that having the ebuild in the overlay
doesn't "bypass" any sort of wait.  It still is not in the tree.  It is
still "unsupported".  Having a couple developers do a 30 second check
over an ebuild does not instantly make it good quality.

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

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

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

[Peter]

On Thu, 08 Jun 2006 18:09:04 -0400, Chris Gianelloni wrote:

> On Thu, 2006-06-08 at 16:23 -0400, Peter wrote:
>> I did not read anything that implied o.g.o would bypass anything other
>> than a lengthy wait in bugzilla land. Other distros have their
>> experimental/testing branches, why can't gentoo?
> 
> *cough* ~arch *cough*
> 
> What everybody seems to miss is that having the ebuild in the overlay
> doesn't "bypass" any sort of wait.  It still is not in the tree.  It is
> still "unsupported".  Having a couple developers do a 30 second check
> over an ebuild does not instantly make it good quality.

You're right. However it allows certain ebuilds to get published long
before they would (if ever) waiting in bugzilla maintainer-wanted. Unless
I am totally naive or utopian or foolish (or all of the above), what is
wrong for having an overlay for orphaned or ebuilds that will never be
supported. Things not being in the tree is the whole purpose of the
overlay as I understand it. Some things should not be in the tree, some
things should. However, for many different reasons, some things that
should be in the tree just don't get there.

Quality is subjective. I could write a perfect ebuild for foo.bar, but the
program could suck. Or, someone could write a piss poor ebuild for "best
program ever" and q/a would slam it rightfully so. Such an ebuild would
likely not get onto overlay either. But for those motivated enough to want
to push an ebuild, the o.g.o provides such an outlet.

And, for me again as a user, using a gentoo-hosted overlay is preferable
to a third party repository. This is a personal bias on my part -- and
maybe unwarranted.

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!

-- 
Peter


-- 
gentoo-dev@gentoo.org mailing list

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

[Henrik Brix Andersen]

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

On Thu, Jun 08, 2006 at 06:31:43PM -0400, Peter wrote:
> And, for me again as a user, using a gentoo-hosted overlay is preferable
> to a third party repository. This is a personal bias on my part -- and
> maybe unwarranted.

This is actually my main concern with the Sunrice project. You say you
would prefer a gentoo-hosted overlay to a third party repository. Why
is that? I can only assume it's because you think "hey, it's
officially endorsed by Gentoo, the same people who maintain the other
official ebuilds - so it must be ok".

I suspect most users will think similar and will come yelling at us,
or even worse - at upstream, when something in this overlay breaks and
leaves their computer as expensive paper weight (at least until
they've formattet and started over).

Regards,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 213 bytes --]

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

[Peter]

On Fri, 09 Jun 2006 13:08:01 +0200, Henrik Brix Andersen wrote:

> On Thu, Jun 08, 2006 at 06:31:43PM -0400, Peter wrote:
>> And, for me again as a user, using a gentoo-hosted overlay is
>> preferable to a third party repository. This is a personal bias on my
>> part -- and maybe unwarranted.
> 
> This is actually my main concern with the Sunrice project. You say you
> would prefer a gentoo-hosted overlay to a third party repository. Why is
> that? I can only assume it's because you think "hey, it's officially
> endorsed by Gentoo, the same people who maintain the other official
> ebuilds - so it must be ok".
> 
> I suspect most users will think similar and will come yelling at us, or
> even worse - at upstream, when something in this overlay breaks and
> leaves their computer as expensive paper weight (at least until they've
> formattet and started over).
> 
> Regards,
> Brix

I don't think so. I look forward to the sunrise (sorry I called it
sunshine earlier, it was late) project because of two reasons.

Firstly, I think it is very clear that anything in sunrise is experimental
or not supported in the main gentoo tree. That's fine! I don't think any
user who goes through the trouble to set up an overlay would miss that
point. You can't go to o.g.o and not see the disclaimers. And, anyone who
goes through the trouble to svn the overlay, edit make.conf, etc., would
not be an ignorant newbie (no disrespect to newbies intended). Anyone who
fetches the sunrise overlay would know exactly what he/she intends to do
and why. Much different than emerge --sync with keyword x86.

Secondly, my bias against a third party repository is perhaps unwarranted.
I am sure the bmg site is excellent and the people running it are
well-intentioned and experienced. However, that said, as a user, I have a
higher comfort level staying in the gentoo.realm.

Thirdly, the opportunity to be able to publish ebuilds that would
otherwise languish in bugzilla is very exciting. I think it also gives the
bugday people an opportunity to close out bugs. Despite what others have
written, having multi-year old bugs is very counter productive. If
something has not been fixed in so long, it probably either can't be
fixed, or may not even apply anymore. I know this is a generalization, but
if a bug was filed against gentoo 2004.3, who knows if it still applies
with gentoo 2006.0. Especially if there has been little or no activity.

Personally, I don't see the conflict, or the risk, or the additional work
for devs. In fact, I see the opposite. Removing maintainer-wanted bugs is
a net positive. If that means the proposed ebuild lives in o.g.o that's
fine. Just point users who see the bug over to it. And, if an ebuild
proves to be useful, or popular, it's conceivable that it could ultimately
find its way over to the main tree.

As for the more sinister aspects of a rogue ebuild finding its way onto
o.g.o, sure that's a possibility. However, any dev could do the same in
portage because they have commit access (and the problem may not be
caught right away). Moreover, it's possible that an ebuild may be fine,
but a particular version of a package tarball could have outright
malicious code or an undetected security hole in it that has not been
caught yet. That could find its way onto portage too. IMHO, I don't see
any more risk to security in o.g.o.

Again, I think you need to consider your audience for o.g.o. The newbie
won't be there or be syncing to o.g.o. The server admin probably would not
be there either for updating a production machine. I think the main
audience for o.g.o. would be the power user, or the wannabe power user or
certain project teams, or people with a particular interest or need in a
project not hosted on the main tree -- that is people who actively need
sunrise's services.

And, looking at this from a broader perspective, I see this as a real
enhancement to gentoo. Offering an experimental tree for packages not
intended or not wanted in the main tree. This is an added benefit, it
demonstrates a policy of inclusion, not exclusion. It shows a willingness
to push the envelope and give certain packages a home where they would not
normally get one.

-- 
Peter


-- 
gentoo-dev@gentoo.org mailing list

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

[Diego 'Flameeyes' Pettenò]

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

On Friday 09 June 2006 13:44, Peter wrote:
> And, anyone who
> goes through the trouble to svn the overlay, edit make.conf, etc., would
> not be an ignorant newbie (no disrespect to newbies intended).
I had a bug from an users unable to build kdesktop with gcc 4.1. I built it 
fine I told him, and the line where the error was reported didn't contain 
anything of the extra qualification reported, so I asked him to check as he 
was probably using an overlay.

He started ranting that we have a bad user support and so on... until he 
actually recognized he was using xgl overlay.

That said, I wouldn't be surprised if especially with layman people ends up 
using overlays without knowing that.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Henrik Brix Andersen]

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

On Fri, Jun 09, 2006 at 07:44:38AM -0400, Peter wrote:
> Firstly, I think it is very clear that anything in sunrise is experimental
> or not supported in the main gentoo tree. That's fine! I don't think any
> user who goes through the trouble to set up an overlay would miss that
> point. You can't go to o.g.o and not see the disclaimers. And, anyone who
> goes through the trouble to svn the overlay, edit make.conf, etc., would
> not be an ignorant newbie (no disrespect to newbies intended). Anyone who
> fetches the sunrise overlay would know exactly what he/she intends to do
> and why. Much different than emerge --sync with keyword x86.

According to other mails in this thread, it will be possible to use
the overlay through layman - no need for a complicated svn checkout
process.

> Secondly, my bias against a third party repository is perhaps unwarranted.
> I am sure the bmg site is excellent and the people running it are
> well-intentioned and experienced. However, that said, as a user, I have a
> higher comfort level staying in the gentoo.realm.

Care to explain why you have a higher comfort of staying in the gentoo
realm? I ask since I'm afraid it's due to a false sense of security.

> Thirdly, the opportunity to be able to publish ebuilds that would
> otherwise languish in bugzilla is very exciting. I think it also gives the
> bugday people an opportunity to close out bugs. Despite what others have
> written, having multi-year old bugs is very counter productive. If
> something has not been fixed in so long, it probably either can't be
> fixed, or may not even apply anymore. I know this is a generalization, but
> if a bug was filed against gentoo 2004.3, who knows if it still applies
> with gentoo 2006.0. Especially if there has been little or no activity.

We're not talking about bugs per se here - we're talking about
enhancement request for new ebuilds. No bugs should be closed simply
because an ebuild from the bug is included in the sunrise
overlay. Until the ebuild is included in portage proper the
enchancement request still stands.

> Personally, I don't see the conflict, or the risk, or the additional work
> for devs. In fact, I see the opposite. Removing maintainer-wanted bugs is
> a net positive. If that means the proposed ebuild lives in o.g.o that's
> fine. Just point users who see the bug over to it. And, if an ebuild
> proves to be useful, or popular, it's conceivable that it could ultimately
> find its way over to the main tree.

Again, the bugs wont be removed - the ebuilds will simply be mirrored
in the sunrise project (please correct me if I am wrong here).

> As for the more sinister aspects of a rogue ebuild finding its way onto
> o.g.o, sure that's a possibility. However, any dev could do the same in
> portage because they have commit access (and the problem may not be
> caught right away). Moreover, it's possible that an ebuild may be fine,
> but a particular version of a package tarball could have outright
> malicious code or an undetected security hole in it that has not been
> caught yet. That could find its way onto portage too. IMHO, I don't see
> any more risk to security in o.g.o.

Except that when a Gentoo developer intends to add a new package to
the tree they're supposed to do QA on the package and the ebuild. Many
herds also use peer review for this. As every Gentoo developer knows,
this is a very time consuming task. A task for which we are already
understaffed as it is.

I fail to see how a new parallel portage tree with contributions from
people inexperienced in writing ebuilds and reviewing packages can be
reviewed and supported by only a handful of Gentoo developers, who
also have no experience with the packages in question.

> Again, I think you need to consider your audience for o.g.o. The newbie
> won't be there or be syncing to o.g.o. The server admin probably would not
> be there either for updating a production machine. I think the main
> audience for o.g.o. would be the power user, or the wannabe power user or
> certain project teams, or people with a particular interest or need in a
> project not hosted on the main tree -- that is people who actively need
> sunrise's services.

Perhaps. No one really knows how many newbies or experienced users
will use the sunrise project, not you - not I.

But I do fear that many of our end-users will use it, or at least, use
parts of it. As previously stated, I fear that the quality of the
parallel tree will not live up to the standards of the main tree,
causing the reputaion of Gentoo as a whole to degrade to the
reputation as a "ricer" distribution which we have worked so hard on
eliminating in the past couple of years.

Therefore I'd rather see the project hosted on third party servers
(e.g. gentoo-sunrise.org) to avoid having it automatically seen as an
officially endorsed Gentoo repository by end-users/upstream developers
to begin with. If the Gentoo developers and contributors involved
succeed in proving that this indeed is a good idea, and that it indeed
does not hurt the reputation of Gentoo as a whole, we can then
consider moving the project back on gentoo.org and make it official.

Regards,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 213 bytes --]

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

[Carsten Lohrke]

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

On Friday 09 June 2006 13:44, Peter wrote:
> Secondly, my bias against a third party repository is perhaps unwarranted.
> I am sure the bmg site is excellent and the people running it are
> well-intentioned and experienced. However, that said, as a user, I have a
> higher comfort level staying in the gentoo.realm.

It's not. The problem is, that the assumption an overlays.g.o overlay of the 
sort we speak about would be better, is false.


Carsten

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

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

[Chris Gianelloni]

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

On Fri, 2006-06-09 at 07:44 -0400, Peter wrote:
> Firstly, I think it is very clear that anything in sunrise is experimental
> or not supported in the main gentoo tree. That's fine! I don't think any
> user who goes through the trouble to set up an overlay would miss that
> point. You can't go to o.g.o and not see the disclaimers. And, anyone who
> goes through the trouble to svn the overlay, edit make.conf, etc., would
> not be an ignorant newbie (no disrespect to newbies intended). Anyone who
> fetches the sunrise overlay would know exactly what he/she intends to do
> and why. Much different than emerge --sync with keyword x86.

Sorry, but if it isn't supported, it doesn't belong on Gentoo
infrastructure.

> Secondly, my bias against a third party repository is perhaps unwarranted.
> I am sure the bmg site is excellent and the people running it are
> well-intentioned and experienced. However, that said, as a user, I have a
> higher comfort level staying in the gentoo.realm.

Again, you are *proving* the point on why this would be bad.  It would
be not nearly as well maintained, yet users such as yourself will have
this rose-colored perception that "it's from Gentoo, so it must be
good."  This is the *exact* thing that I am trying to avoid.  This will
*not* be from Gentoo and it will *not* be good.

> Thirdly, the opportunity to be able to publish ebuilds that would
> otherwise languish in bugzilla is very exciting. I think it also gives the
> bugday people an opportunity to close out bugs. Despite what others have
> written, having multi-year old bugs is very counter productive. If
> something has not been fixed in so long, it probably either can't be
> fixed, or may not even apply anymore. I know this is a generalization, but
> if a bug was filed against gentoo 2004.3, who knows if it still applies
> with gentoo 2006.0. Especially if there has been little or no activity.

Perhaps there is no activity because the interest is not there?  Nobody
seems to be taking this into account.

If you really think your package should be added to the tree, then add
yourself to CC, get your friends on CC, drum up some support in the
forums, find yourself a developer to proxy maintain for you.  We don't
need a dumping ground for abandoned or little-use ebuilds.

> Personally, I don't see the conflict, or the risk, or the additional work
> for devs. In fact, I see the opposite. Removing maintainer-wanted bugs is
> a net positive. If that means the proposed ebuild lives in o.g.o that's
> fine. Just point users who see the bug over to it. And, if an ebuild
> proves to be useful, or popular, it's conceivable that it could ultimately
> find its way over to the main tree.

Well, I've done about as good as I can do to point out how it would be
additional work and a major risk.  If you cannot see it, there's not
much else I can do.  Luckily, a growing number of official developers
*do* see the risks and are taking a stand against this egregious waste
of time.

> As for the more sinister aspects of a rogue ebuild finding its way onto
> o.g.o, sure that's a possibility. However, any dev could do the same in
> portage because they have commit access (and the problem may not be
> caught right away). Moreover, it's possible that an ebuild may be fine,
> but a particular version of a package tarball could have outright
> malicious code or an undetected security hole in it that has not been
> caught yet. That could find its way onto portage too. IMHO, I don't see
> any more risk to security in o.g.o.

Sure, a developer could be a risk, but they've gone through much more
extensive checking and testing than some user who submitted an ebuild to
a bug.

> Again, I think you need to consider your audience for o.g.o. The newbie
> won't be there or be syncing to o.g.o. The server admin probably would not
> be there either for updating a production machine. I think the main
> audience for o.g.o. would be the power user, or the wannabe power user or
> certain project teams, or people with a particular interest or need in a
> project not hosted on the main tree -- that is people who actively need
> sunrise's services.

You're absolutely right.  We need to think of the audience.  The
overlays.gentoo.org project was touted as a way to foster the community
and to help *developers* develop things that might be intrusive to the
portage tree, as well as allow for easier non-developer contributions.
It was *never* touted as a place where we would allow dumping of
half-correct, unsupported, and only marginally quality ebuilds for mass
user consumption.

> And, looking at this from a broader perspective, I see this as a real
> enhancement to gentoo. Offering an experimental tree for packages not
> intended or not wanted in the main tree. This is an added benefit, it
> demonstrates a policy of inclusion, not exclusion. It shows a willingness
> to push the envelope and give certain packages a home where they would not
> normally get one.

It also shows that we're not concerned with quality or providing a
consistent experience where things are meant to work together.  It shows
our complete lack of commitment to the safety of our users.  It shows
that we really are nothing more than a bunch of ricers that will take
the quick and easy approach, rather than doing things right.

No thanks...

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

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

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

[Peter]

On Fri, 09 Jun 2006 14:15:01 -0400, Chris Gianelloni 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.

I do think that is a pretty heavy-handed statement though. However,
authority issues aside, I would like to respond to your comments.
>> Secondly, my bias against a third party repository is perhaps
>> unwarranted. I am sure the bmg site is excellent and the people running
>> it are well-intentioned and experienced. However, that said, as a user,
>> I have a higher comfort level staying in the gentoo.realm.
> 
> Again, you are *proving* the point on why this would be bad.  It would
> be not nearly as well maintained, yet users such as yourself will have
> this rose-colored perception that "it's from Gentoo, so it must be
> good."  This is the *exact* thing that I am trying to avoid.  This will
> *not* be from Gentoo and it will *not* be good.
> 

I do not understand how ebuilds created by gentoo developers or interested
users who may have contributed via bugzilla that are hosted on o.g.o would
not be good? My perspective is primarily as a user. However, there are
several ebuilds in portage, and one eclass with my name on it. So, I feel
that I have the ability to discern between good and bad. I choose to
contribute to gentoo because I want to. Some projects will never see the
light of day. Others will. However, some bugs have a large following. And
to keep those ebuilds in limbo is unfair to those users who are interested.

>> Thirdly, the opportunity to be able to publish ebuilds that would
>> otherwise languish in bugzilla is very exciting. I think it also gives
>> the bugday people an opportunity to close out bugs. Despite what others
>> have written, having multi-year old bugs is very counter productive. If
>> something has not been fixed in so long, it probably either can't be
>> fixed, or may not even apply anymore. I know this is a generalization,
>> but if a bug was filed against gentoo 2004.3, who knows if it still
>> applies with gentoo 2006.0. Especially if there has been little or no
>> activity.
> 
> Perhaps there is no activity because the interest is not there?  Nobody
> seems to be taking this into account.
> 

That's a fair point. However, if there is no activity and no interest,
then nuke the bug. Post an announcement like they do periodically on
-devel saying "Last rites for....." and see who comes forward.

> If you really think your package should be added to the tree, then add
> yourself to CC, get your friends on CC, drum up some support in the
> forums, find yourself a developer to proxy maintain for you.  We don't
> need a dumping ground for abandoned or little-use ebuilds.
> 

Done that. However, there are some packages that won't ever make it. Like
some kernel sources, java and gcc hacks, etc. I don't think the process of
committing and ebuild should be a popularity contest. I do not infer that
sunrise would be a dumping ground at all. I think that it's a very low
chance that every maintainer-wanted bug will get there, don't you?

>> Personally, I don't see the conflict, or the risk, or the additional
>> work for devs. In fact, I see the opposite. Removing maintainer-wanted
>> bugs is a net positive. If that means the proposed ebuild lives in
>> o.g.o that's fine. Just point users who see the bug over to it. And, if
>> an ebuild proves to be useful, or popular, it's conceivable that it
>> could ultimately find its way over to the main tree.
> 
> Well, I've done about as good as I can do to point out how it would be
> additional work and a major risk.  If you cannot see it, there's not
> much else I can do.  Luckily, a growing number of official developers
> *do* see the risks and are taking a stand against this egregious waste
> of time.
> 

I've had some conversations with devs personally and on irc. Most complain
about how overworked they are or how little time they have. Something like
this will remove a burden from their plates. The "risk" aspect has been
covered in other posts far more eloquently than I could (see Christel's
post for example). What WOULD be a risk is adding a profile to the main
tree with this overlay.

snip...
> 
>> Again, I think you need to consider your audience for o.g.o. The newbie
>> won't be there or be syncing to o.g.o. The server admin probably would
>> not be there either for updating a production machine. I think the main
>> audience for o.g.o. would be the power user, or the wannabe power user
>> or certain project teams, or people with a particular interest or need
>> in a project not hosted on the main tree -- that is people who actively
>> need sunrise's services.
> 
> You're absolutely right.  We need to think of the audience.  The
> overlays.gentoo.org project was touted as a way to foster the community
> and to help *developers* develop things that might be intrusive to the
> portage tree, as well as allow for easier non-developer contributions.
> It was *never* touted as a place where we would allow dumping of
> half-correct, unsupported, and only marginally quality ebuilds for mass
> user consumption.
> 

I never inferred this to be the case and I think were you to be a little
less constrictive in your thinking, or chatted with the leads, you may
see things differently. I think you read much more into this that there
really is.

>> And, looking at this from a broader perspective, I see this as a real
>> enhancement to gentoo. Offering an experimental tree for packages not
>> intended or not wanted in the main tree. This is an added benefit, it
>> demonstrates a policy of inclusion, not exclusion. It shows a
>> willingness to push the envelope and give certain packages a home where
>> they would not normally get one.
> 
> It also shows that we're not concerned with quality or providing a
> consistent experience where things are meant to work together.  It shows
> our complete lack of commitment to the safety of our users.  It shows
> that we really are nothing more than a bunch of ricers that will take
> the quick and easy approach, rather than doing things right.
> 

I disagree. I think another user commented that gentoo has a reputation
for not being current. I see how this is the case. Part of it has to do
with being a source based distro. Part of it has to do with the
stabilization process. However, part of it has to do with some projects
just not getting in. I think sunrise will help that and show a concern for
the user community and a desire to embrace and include.

> No thanks...

Well, I respect your opinions, though I think it is a bit tight.
-- 
Peter


-- 
gentoo-dev@gentoo.org mailing list

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

[Ryan Hill]

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

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Richard Fish]

On 6/9/06, Peter <pete4abw@comcast.net> wrote:
>
> Firstly, I think it is very clear that anything in sunrise is experimental
> or not supported in the main gentoo tree. That's fine! I don't think any
> user who goes through the trouble to set up an overlay would miss that
> point. You can't go to o.g.o and not see the disclaimers. And, anyone who
> goes through the trouble to svn the overlay, edit make.conf, etc., would
> not be an ignorant newbie (no disrespect to newbies intended). Anyone who
> fetches the sunrise overlay would know exactly what he/she intends to do
> and why. Much different than emerge --sync with keyword x86.

Recently on -user there was someone who couldn't build any gnome apps,
because they had an obsolete gnome2.eclass in their overlay.  This
user certainly didn't know enough about portage or ebuilds to be using
an overlay like that.

Besides, users frequently do imprudent things to their systems.  They
will break their systems by unmasking p.masked stuff (I've done this,
so I am in this group), add dangerous CFLAGS based on random forum or
wiki pages, and use ~arch packages and then rant about any bugs that
show up.

As you've already said, having it on a *.gentoo.org domain gives some
people a higher level of comfort with it, regardless of any
dislaimers.

I have no idea what the quality of the sunrise overlay will be, but it
seems likely to be worse than the currently p.masked stuff.  If
getting sunrise is easy enough, and a substantial number of users
start using it, supporting those users could become very difficult.

-Richard
-- 
gentoo-dev@gentoo.org mailing list

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

[Luis Francisco Araujo]

Peter wrote:
> On Thu, 08 Jun 2006 15:51:25 -0400, Chris Gianelloni wrote:
>
> First, let me say that I'm approaching this from a user's perspective. I
> have no insight or knowledge as to the history of the overlay project or
> any of the people involved. I _do_ know that since late 2004 when I first
> switched to Gentoo, each week there are more bugs opened than closed.
> There are also many open bugs that go back years.
>
> In my particular frame, I want ebuilds I need or have contributed to get
> into the tree. Having to download new ebuilds into local, and then have no
> way to emerge update them is frustrating.
>
> My point was about two things: 1) ebuilds that will never be committed to
> portage, and 2) ebuilds that have been orphaned due to lack of interest.
>
> As for breakmygentoo, here is my thought. As a user, I would prefer to do
> all my shopping in one place. Gentoo has portage and uses ebuilds as a
> package distribution mechanism. I would prefer to use gentoo's facilities
> to get additional off-tree ebuilds. I don't want to have to sync all over
> the place to get ebuilds of unknown origin. I would prefer to have a
> sanctioned alt-gentoo ebuild repository where I know some q/a is applied
> and standards adhered to.
>
> My inference of the sunshine project was that there would be oversight and
> control. That if _I_, for example wished to contribute, then I would have
> to meet standards. And, on the flip side, anyone who would care to
> download an ebuilt from o.g.o would be confident that the ebuild at least
> meets certain quality standards. o.g.o, of course would have to disclose
> that these packages are testing, and possibly experimental, but it's a
> terrific opportunity to find a home for many orphaned and ignored
> packages.
>
> Using the example I brought up, about the kernel-sources, o.g.o would be
> a perfect home for such a project.
>
>
> snip.....
>   
>>> 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
>>     
>
> Why? Because having two year old bugs is simply inexcusable. 
You are always free to fix them. Or even better, free to become a dev 
and maintain them.
> Especially
> when many have not had any activity for a long time. Having
> maintainer-wanted bugs for months on end is silly. Giving a user who files
> a ebuild request or submits an ebuild deserves the chance to take
> ownership of it. It's a good way to get a more experienced user, and
> hopefully one day, a future dev.
>
>   
I agree. It depends at the end upon the user interest to submit/maintain 
an ebuild.
Though that is our current situation with bugzilla too, so i don't see
what is the advantage of the overlay here.
>> 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?
>>
>>     
>
> Well as for packages getting picked up, this is not completely accurate.
> Some will never get picked up, either because they are inappropriate
> (hot-babe, for example), or too experimental (the kernel-source example I
> cited). As for bmg, which I have to admit I had never heard about before
> today, as a user, I would prefer to have everything genoo-sanctioned and
> controlled. 
>
>
>   
>>> 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.
>>
>>     
> Users would not be getting o.g.o ebuilds automatically. They would have to
> actively emerge layman, and then select the ebuilds they want. I agree
> with you that the o.g.o and the main portage tree should never be
> comingled. But, I do argue that bugzilla is inefficient in getting ebuilds
> resolved. And, just because o.g.o exists does not in any way mean a user
> would have to or be advised to skip bugzilla. Some ebuilds will get picked
> right up, others after some review. All I am suggesting is that o.g.o will
> help find a home for ebuilds that are wasting away on bugzilla.
>
>
>   
>> 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 benefits definitely do not outweigh the
>> negatives.
>>     
>
> I did not read anything that implied o.g.o would bypass anything other
> than a lengthy wait in bugzilla land. Other distros have their
> experimental/testing branches, why can't gentoo?
>
>   
masked packages are our "officially" supported experimental/testing 
branches.
-- 
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

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

[Grant Goodyear]

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

Stefan Schweizer wrote: [Wed Jun 07 2006, 07:42:03PM CDT]
> Initially jokey and myself will be working on this. The current focus is to
> migrate ebuilds from bugzilla into the overlay and to get contributors to
> commit their changes to the overlay instead of updating the bugzilla every
> time.

I'm not opposed to what would essentially be an overlay of
maintainier-wanted ebuilds, but I would actually prefer to see that
happen by pulling from the bugzilla database instead of trying to
replace bugzilla altogether.  My reasoning is that bugzilla provides a
place for community development of an ebuild (including commentary!),
which would not be true of just the overlay.  If one were instead to add
a magical bugs whiteboard status or keyword that let a script know that
there's an ebuild to pull from bugzilla that should be added to the
there-be-dragons-here overlay, I'd think that would make life
much simpler for everybody.

-g2boojum-
-- 
Grant Goodyear	
Gentoo Developer
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Alec Warner]

Grant Goodyear wrote:
> Stefan Schweizer wrote: [Wed Jun 07 2006, 07:42:03PM CDT]
> 
>>Initially jokey and myself will be working on this. The current focus is to
>>migrate ebuilds from bugzilla into the overlay and to get contributors to
>>commit their changes to the overlay instead of updating the bugzilla every
>>time.
> 
> 
> I'm not opposed to what would essentially be an overlay of
> maintainier-wanted ebuilds, but I would actually prefer to see that
> happen by pulling from the bugzilla database instead of trying to
> replace bugzilla altogether.  My reasoning is that bugzilla provides a
> place for community development of an ebuild (including commentary!),
> which would not be true of just the overlay.  If one were instead to add
> a magical bugs whiteboard status or keyword that let a script know that
> there's an ebuild to pull from bugzilla that should be added to the
> there-be-dragons-here overlay, I'd think that would make life
> much simpler for everybody.
> 
> -g2boojum-

FYI I've been tinkering with something similar using gentoo-bugger, but 
I haven't had time to work on it recently.
-- 
gentoo-dev@gentoo.org mailing list

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

[Luca Barbato]

Grant Goodyear wrote:
> Stefan Schweizer wrote: [Wed Jun 07 2006, 07:42:03PM CDT]
> My reasoning is that bugzilla provides a
> place for community development of an ebuild (including commentary!),
> which would not be true of just the overlay.  If one were instead to add
> a magical bugs whiteboard status or keyword that let a script know that
> there's an ebuild to pull from bugzilla that should be added to the
> there-be-dragons-here overlay, I'd think that would make life
> much simpler for everybody.

+1

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

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

On Thu, 2006-06-08 at 22:20 +0200, Luca Barbato wrote:
> Grant Goodyear wrote:
> > Stefan Schweizer wrote: [Wed Jun 07 2006, 07:42:03PM CDT]
> > My reasoning is that bugzilla provides a
> > place for community development of an ebuild (including commentary!),
> > which would not be true of just the overlay.  If one were instead to add
> > a magical bugs whiteboard status or keyword that let a script know that
> > there's an ebuild to pull from bugzilla that should be added to the
> > there-be-dragons-here overlay, I'd think that would make life
> > much simpler for everybody.
> 
> +1

You mean like: REVIEWED ?

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

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

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

[Markus Ullmann]

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

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.

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

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.

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.

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.

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.

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.

Greetz,
Jokey


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

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

[Lance Albertson]

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

Markus Ullmann wrote:

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

Thanks for the clarification.

To clarify my point, I'm all for helping our distro, but I just don't
want this project to be labeled as a more official BMG. If you suit the
needs of what the devs think is the right way to do this, then I'm all
for it. I just noticed several mails from the project that seemed to be
ignoring the issues at hand and I wasn't going to support the project on
infra if they continued to be like that.

Thanks for answering most of those questions. I'll let the developer
community decide if they like them or not :-).

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

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

[Henrik Brix Andersen]

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

On Thu, Jun 08, 2006 at 08:58:48PM +0200, Markus Ullmann wrote:
> 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.

It's not a "normal" overlay as I see it. You've promoted it to be an
official overlay. The difference is huge in my opinion.

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

Will you also review the code each and every ebuild pull down over the
internet?

Regards,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 213 bytes --]

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

[Peter Volkov (pva)]

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

On Чтв, 2006-06-08 at 21:20 +0200, Henrik Brix Andersen wrote:
> It's not a "normal" overlay as I see it. You've promoted it to be an
> official overlay. The difference is huge in my opinion.

IMO such overlay should be official! Why not to keep all (partially)
broken ebuilds in one place? This is the same story as with German
gentoo forum that is outside gentoo.org and thus none of devs wanted to
keep eyes there, so forum became much less useful.

Another problem with BMG is that it is gnome oriented, as cleary stated
on About page and thus I never thought that my, fex, www-apps could be
there.

> > 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.
> 
> Will you also review the code each and every ebuild pull down over the
> internet?

And that is really exciting moment. :) The main difference between such
overlay and wiki is that reading text never does `rm -rf /`. How can one
stop such jokes? I think if this problem will be solved such overlay
should be.

Peter.

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

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

[Peter Volkov (pva)]

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

On Чтв, 2006-06-08 at 21:20 +0200, Henrik Brix Andersen wrote:
> It's not a "normal" overlay as I see it. You've promoted it to be an
> official overlay. The difference is huge in my opinion.

IMO such overlay should be official! Why not to keep all (partially)
broken ebuilds in one place? This is the same story as with German
gentoo forum that is outside gentoo.org and thus none of devs wanted to
keep eyes there, so forum became much less useful.

Another problem with BMG is that it is gnome oriented, as cleary stated
on About page and thus I never thought that my, fex, www-apps could be
there.

> > 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.
> 
> Will you also review the code each and every ebuild pull down over the
> internet?

And that is really exciting moment. :) The main difference between such
overlay and wiki is that reading text never does `rm -rf /`. How can one
stop such jokes? I think if this problem will be solved such overlay
should be.

Peter.

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

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

[Ciaran McCreesh]

On Thu, 08 Jun 2006 23:52:50 +0400 "Peter Volkov (pva)"
<pva@gentoo.org> wrote:
| > Will you also review the code each and every ebuild pull down over
| > the internet?
| 
| And that is really exciting moment. :) The main difference between
| such overlay and wiki is that reading text never does `rm -rf /`. How
| can one stop such jokes? I think if this problem will be solved such
| overlay should be.

Somehow I think certain people aren't quite grasping the potential
security breaches with this whole thing... Slipping in malicious and
hard to detect code that gets executed by everybody is very very easy.

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


-- 
gentoo-dev@gentoo.org mailing list

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

[Henrik Brix Andersen]

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

On Thu, Jun 08, 2006 at 09:35:07PM +0100, Ciaran McCreesh wrote:
> On Thu, 08 Jun 2006 23:52:50 +0400 "Peter Volkov (pva)"
> <pva@gentoo.org> wrote:
> | > Will you also review the code each and every ebuild pull down over
> | > the internet?
> | 
> | And that is really exciting moment. :) The main difference between
> | such overlay and wiki is that reading text never does `rm -rf /`. How
> | can one stop such jokes? I think if this problem will be solved such
> | overlay should be.
> 
> Somehow I think certain people aren't quite grasping the potential
> security breaches with this whole thing... Slipping in malicious and
> hard to detect code that gets executed by everybody is very very easy.

My point exactly.

Regards,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 213 bytes --]

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

[Chris Gianelloni]

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

On Thu, 2006-06-08 at 21:35 +0100, Ciaran McCreesh wrote:
> On Thu, 08 Jun 2006 23:52:50 +0400 "Peter Volkov (pva)"
> <pva@gentoo.org> wrote:
> | > Will you also review the code each and every ebuild pull down over
> | > the internet?
> | 
> | And that is really exciting moment. :) The main difference between
> | such overlay and wiki is that reading text never does `rm -rf /`. How
> | can one stop such jokes? I think if this problem will be solved such
> | overlay should be.
> 
> Somehow I think certain people aren't quite grasping the potential
> security breaches with this whole thing... Slipping in malicious and
> hard to detect code that gets executed by everybody is very very easy.

You mean like:

perl -e 'print
i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'

I'm sure everyone will get what that means in a quick cursory glance...
and of course repoman will know what it does, right?

*grin*

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

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

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

[Markus Ullmann]

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

Henrik Brix Andersen wrote:
> > It's not a "normal" overlay as I see it. You've promoted it to be an
> > official overlay. The difference is huge in my opinion.

Well partly you're right. As it is promoted that way it is a bit more
official but anyway still an overlay.

> > Will you also review the code each and every ebuild pull down over the
> > internet?

Well at least briefly. We decided to maintain it in an official way and
thus keep an eye on the quality of the checkins. As said, at least a
briefly view at it and also a repoman scan.

We're going to have some contributors at it so it wouldn't be an easy
job but I think we can get some more of them that way.
Searched my inbox and found a mail saying this:

--- Paste ---
"He was trying to recruit me as a Gentoo developer. Unfortunately, I
turned him down, the main reason being time. Also, I don't really
need/want the status/powers/responsibilities that come with being a
developer, so that was another reason.

He then suggested that I become an arch-tester, or maybe contribute to
this public overlay that you have in mind. The arch-tester position
didn't seem that appealing to me. The public overlay on the other hand
is more suitable for me. I like to write the occasional ebuild and there
are some ebuilds writen by me in Bugzilla that are currently assigned to
maintainer-wanted so getting these in an overlay would be nice. Also, I
would assume that the barrier of entry and time requirements are lower
than the developer position.
--- Paste ---

Sounds he likes to contribute / maintain some apps, just not the whole
thing you have to do when being a full dev. But he expressed his
interest in this as a possible entry point. So I guess we can keep an
eye on him...

But one thing is important: As the project has some overlay nature,
there _may_ be the one or other small issue with it. On the other hand
what ebuild is 100% bugfree?  ;)  QA would have nothing todo then... And
here we don't break the (stable) tree if some really nasty issue ever
slips through our fingers.

Greetz,
Jokey



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

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

[Chris Gianelloni]

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

On Thu, 2006-06-08 at 21:57 +0200, Markus Ullmann wrote:
> Well at least briefly. We decided to maintain it in an official way and
> thus keep an eye on the quality of the checkins. As said, at least a
> briefly view at it and also a repoman scan.

A repoman scan won't catch subtle bugs caused in other packages by
packages in this overlay.  It *will* add extra maintenance to any
package maintainer within Gentoo.

> Sounds he likes to contribute / maintain some apps, just not the whole
> thing you have to do when being a full dev. But he expressed his
> interest in this as a possible entry point. So I guess we can keep an
> eye on him...

Yes.  This person is also fully capable of continuing to provide ebuilds
to bugzilla.

> But one thing is important: As the project has some overlay nature,
> there _may_ be the one or other small issue with it. On the other hand
> what ebuild is 100% bugfree?  ;)  QA would have nothing todo then... And
> here we don't break the (stable) tree if some really nasty issue ever
> slips through our fingers.

No, but the ebuilds are also checked by the team in question, that
actually knows the packages, versus a couple of developers that will be
overworked, dealing with packages that they are completely unfamiliar
with and have no experience with.  I just don't see the two as equal in
any way.  I also do not see how this helps Gentoo development.  The only
thing that this does is allows for a few packages that hardly anyone is
interested in having become available for our users.  That's a noble
effort, but there's usually a reason why these packages do not get
picked up.

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

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

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

[Donnie Berkholz]

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

Chris Gianelloni wrote:
> No, but the ebuilds are also checked by the team in question, that
> actually knows the packages, versus a couple of developers that will be
> overworked, dealing with packages that they are completely unfamiliar
> with and have no experience with.  I just don't see the two as equal in
> any way.  I also do not see how this helps Gentoo development.

Being able to maintain these ebuilds in version control rather than
random attachments to bugzilla is a huge improvement.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

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

[Chris Gianelloni]

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

On Thu, 2006-06-08 at 15:22 -0700, Donnie Berkholz wrote:
> Chris Gianelloni wrote:
> > No, but the ebuilds are also checked by the team in question, that
> > actually knows the packages, versus a couple of developers that will be
> > overworked, dealing with packages that they are completely unfamiliar
> > with and have no experience with.  I just don't see the two as equal in
> > any way.  I also do not see how this helps Gentoo development.
> 
> Being able to maintain these ebuilds in version control rather than
> random attachments to bugzilla is a huge improvement.

Of course they would be, to the team in question.  To a few random
developers being responsible for *any* kind of package, it won't make
much difference since their familiarity level is very near zero.

Good examples of this *working* are php, webapps, or even vmware.

Bad examples would be this overlay.  Instead of a directed and focused
overlay, designed to ease testing and development on otherwise intrusive
changes to the tree, it is a dumping ground for ebuilds that either
weren't good enough, or weren't interesting enough for inclusion.

Either that, or they're ebuilds related to an already-established
project where the team members simply don't have the time.  This is
probably the only case where the ebuilds in question might make it into
the tree after being in this overlay.

This overlay is a dumping ground for the barely-wanted, and little more.
As I have said, I don't see it actually improving the situation nearly
as much as it will be detrimental to it.

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

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

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

[Stuart Herbert]

On 6/8/06, Henrik Brix Andersen <brix@gentoo.org> wrote:
> Will you also review the code each and every ebuild pull down over the
> internet?

The policy for overlays.gentoo.org hosting [1] is hopefully clear: as
the project leads, they're ultimately responsible (and therefore
accountable) for what goes into their project overlay - no matter
whether it's committed by a dev or by a user who has been entrusted
with commit rights to the overlay.

The policy for what can go into an overlay is also hopefully clear:
overlays are for package trees, their patchsets, any docs, and any
downloadable tarballs that have nowhere else to be hosted.  It's not
there to be $UPSTREAM, except for eselect modules, -config scripts and
the like that exist purely to support ebuilds in the package tree.

I expect projects and developers who are using overlays to be
respectful of others.  The whole point of the overlays project is to
continue our work in trying to get our users much more involved in
developing Gentoo.  It's there to be a stepping stone for getting
packages into the tree - although I do not expect every package in
overlays to end up in the tree.  Any hostile hijacking of other
people's packages doesn't fit into that vision, and there's no place
for it on o.g.o.

I also expect projects and developers who are not using overlays to be
equally respectful of those who are.  There are projects and
developers who find overlays an excellent way of safely testing and
developing ebuilds, and who find overlays to be a good way to help
train and develop the next generation of Gentoo developers (good
developers are something we really need more of).

If any overlay is ultimately an abuse of the hosting that the overlays
project provides, then your first course of redress is with the
overlay's owner.  If you're still unhappy, then come and talk to me as
the Overlays Project team lead.  I'm here to listen, and if necessary
to act.  If I don't agree, you can still go to the Council as a last
resort if you feel that strongly about it.

[1] http://www.gentoo.org/proj/en/overlays/policy.xml

Best regards,
Stu
-- 
gentoo-dev@gentoo.org mailing list

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

[Henrik Brix Andersen]

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

On Thu, Jun 08, 2006 at 10:05:38PM +0100, Stuart Herbert wrote:
> On 6/8/06, Henrik Brix Andersen <brix@gentoo.org> wrote:
> >Will you also review the code each and every ebuild pull down over the
> >internet?
> 
> The policy for overlays.gentoo.org hosting [1] is hopefully clear: as
> the project leads, they're ultimately responsible (and therefore
> accountable) for what goes into their project overlay - no matter
> whether it's committed by a dev or by a user who has been entrusted
> with commit rights to the overlay.
[snip]

I don't really see how this answers my question, but I do appreciate
the summary of the policy for overlays.g.o. I have no problems with
the overlay project in general - my concern is about the Sunshine
project.

> [1] http://www.gentoo.org/proj/en/overlays/policy.xml

While reading the policy above, I stumbled across this line:

"Bug Tracking: bugs.g.o is the OneTrueBugTrackingSystem(tm), even for
overlays."

Could you please elaborate on this?

Regards,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 213 bytes --]

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

[Stuart Herbert]

Hi Henrik,

On 6/8/06, Henrik Brix Andersen <brix@gentoo.org> wrote:
> While reading the policy above, I stumbled across this line:
>
> "Bug Tracking: bugs.g.o is the OneTrueBugTrackingSystem(tm), even for
> overlays."
>
> Could you please elaborate on this?

Sure ... in the discussion we had on -dev earlier in the year about
the overlays service, it was agreed that we wouldn't maintain separate
bug tracking systems for each overlay.  All the bugs for each overlay
will go into bugs.gentoo.org.

This means that the following cycle can happen:

a) User A submits ebuild via bugzilla
b) Developer takes ebuild from bugzilla, and adds it to overlay for
testing & fixing
c) User B submits bug in bugzilla about the ebuild in the overlay

For example, we've been working that way in the webapps overlay for
some months now, and it's worked well for us (although we haven't been
using bugzilla until this week).

Hope that answers your question.

Best regards,
Stu
-- 
gentoo-dev@gentoo.org mailing list

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

[Carsten Lohrke]

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

This may work for Apache or PHP, but an overlay with arbitrary "maintainer 
wanted" ebuilds would need an extra bugzilla account. The problem is that 
this won't really help, since (some) users will see "oh, an kde app crashed" 
and file a bug at kde@gentoo.org. Then /me looks at the tree, doesn't see the 
package and marks the bug as invalid. Even worse it is for bug wranglers. You 
hardly can expect that they look up every single overlay. 

You should at least make it visible in bold letters on the overlay.g.o front 
page, what the conditions of each overlay are and which foo@g.o address bugs 
have to be assigned to. Also some warning that an overlay may break the tree 
or fubar the users system and that only the one who uses it, is responsible 
for using it, wouldn't be wrong.


Carsten

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

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

[Stefan Schweizer]

Carsten Lohrke wrote:
> You should at least make it visible in bold letters on the overlay.g.o
> front page, what the conditions of each overlay are and which foo@g.o
> address bugs have to be assigned to. 


Please, do not assume our users being stupid. They know that they are using
an ebuild from the sunrise overlay with zero support. They deliberately
typed 

"svn co http://overlays.gentoo.org/svn/proj/sunrise/category/application"
"emerge application"

And also there are only applications from maintainer-wanted or
maintainer-needed allowed in the overlay. Because packages are not supposed
to overwrite files from other ebuilds it is unlikely that they can cause
any damage to applications that have not been directly installed from the
overlay.

> Also some warning that an overlay may
> break the tree or fubar the users system 
That is not the intention of the overlay. Everyone can help fixing breakage,
it is not like with the current tree, where you have apps broken for a few
days, weeks or even months because the maintainer is unreachable. With
fixes (by users) spread all over bugzilla.
It is designed to be more open and more easily fixable.

-Stefan

-- 
gentoo-dev@gentoo.org mailing list

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

[Carsten Lohrke]

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

On Friday 09 June 2006 14:04, Stefan Schweizer wrote:
> Please, do not assume our users being stupid. They know that they are using
> an ebuild from the sunrise overlay with zero support. They deliberately
> typed

You have said stupid, not me. Some won't care enough, I'm quite sure about 
that. We had such invalid bug reports occasionally in the past and I expect 
this to happen more often, the easier and more common dealing with overlays 
becomes. Regarding "zero support": Making this abslutely clear is what I miss 
looking at overlays.g.o.

> "svn co http://overlays.gentoo.org/svn/proj/sunrise/category/application"
> "emerge application"
>
> And also there are only applications from maintainer-wanted or
> maintainer-needed allowed in the overlay. Because packages are not supposed
> to overwrite files from other ebuilds it is unlikely that they can cause
> any damage to applications that have not been directly installed from the
> overlay.

maintainer-needed is imho not acceptable at all, as any dev trying to clean up 
bugs, won't know if a bug report comes from a user of the main tree ebuild or  
from your overlay.

> > Also some warning that an overlay may
> > break the tree or fubar the users system
>
> That is not the intention of the overlay.

If it were intended, it would be malicious. Even if not intended, it doesn't 
mean tree breakages won't happen. Some dev may change an eclass, without 
taking overlay ebuilds into account (and he doesn't have to), but the change 
may break all ebuilds inheriting the eclass in an overlay, leaving all the 
users of the overlay with a broken tree. And to make that clear: Eclasses in 
overlays are only "sort of" acceptable, when the same team handles the eclass 
in the the main tree, as eclasses in overlays hide the main tree eclasses.


Carsten


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

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

[Danny van Dyk]

Am Freitag, 9. Juni 2006 14:04 schrieb Stefan Schweizer:
> And also there are only applications from maintainer-wanted or
> maintainer-needed allowed in the overlay. Because packages are not
> supposed to overwrite files from other ebuilds it is unlikely that
> they can cause any damage to applications that have not been directly
> installed from the overlay.
>
That is only true, if you have enabled FEATURES="collision-protect".

Danny
-- 
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-- 
gentoo-dev@gentoo.org mailing list

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

[Danny van Dyk]

Am Freitag, 9. Juni 2006 14:04 schrieb Stefan Schweizer:
> And also there are only applications from maintainer-wanted or
> maintainer-needed allowed in the overlay. Because packages are not
> supposed to overwrite files from other ebuilds it is unlikely that
> they can cause any damage to applications that have not been directly
> installed from the overlay.
Only when you have FEATURES="collision-protect".

Danny
-- 
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-- 
gentoo-dev@gentoo.org mailing list

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

[Danny van Dyk]

Am Freitag, 9. Juni 2006 14:04 schrieb Stefan Schweizer:
> And also there are only applications from maintainer-wanted or
> maintainer-needed allowed in the overlay. Because packages are not
> supposed to overwrite files from other ebuilds it is unlikely that
> they can cause any damage to applications that have not been directly
> installed from the overlay.
Only when you got FEATURES="collision-protect".

Danny
-- 
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

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

On Fri, 2006-06-09 at 14:04 +0200, Stefan Schweizer wrote:
> Carsten Lohrke wrote:
> > You should at least make it visible in bold letters on the overlay.g.o
> > front page, what the conditions of each overlay are and which foo@g.o
> > address bugs have to be assigned to. 
> 
> 
> Please, do not assume our users being stupid. They know that they are using
> an ebuild from the sunrise overlay with zero support. They deliberately
> typed 
> 
> "svn co http://overlays.gentoo.org/svn/proj/sunrise/category/application"
> "emerge application"

Umm... and what if they checkout the entire repository and get something
they weren't expecting?

I love how you simply just dismiss this possibility as something that
either can't happen, or something that won't happen because the users
will "know what they're doing" when they use this overlay.

> And also there are only applications from maintainer-wanted or
> maintainer-needed allowed in the overlay. Because packages are not supposed
> to overwrite files from other ebuilds it is unlikely that they can cause
> any damage to applications that have not been directly installed from the
> overlay.

Hahahahahahahahahahahaha!!

Oh wait... Are you serious?  What if it is a library?  What if it is an
alternative to a library already in the tree?  Hrrrmn... plot thickens.

> > Also some warning that an overlay may
> > break the tree or fubar the users system 
> That is not the intention of the overlay. Everyone can help fixing breakage,
> it is not like with the current tree, where you have apps broken for a few
> days, weeks or even months because the maintainer is unreachable. With
> fixes (by users) spread all over bugzilla.

Everyone that you happen to include as allowed to actually commit, you
mean.  As opposed to "everyone that can sign themselves up for
bugzilla"?

> It is designed to be more open and more easily fixable.

Sure.  More open then a self-registering system.  Gotcha.

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

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

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

[Stefan Schweizer]

Chris Gianelloni wrote:
> Everyone that you happen to include as allowed to actually commit, you
> mean.  As opposed to "everyone that can sign themselves up for
> bugzilla"?
> 
>> It is designed to be more open and more easily fixable.
> 
> Sure.  More open then a self-registering system.  Gotcha.
> 

We actually have a FAQ entry about that. See "But there is access controls?
Why is there access controls?" on
http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq

-- 
gentoo-dev@gentoo.org mailing list

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

[Mike Frysinger]

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

On Friday 09 June 2006 15:01, Stefan Schweizer wrote:
> Chris Gianelloni wrote:
> > Everyone that you happen to include as allowed to actually commit, you
> > mean.  As opposed to "everyone that can sign themselves up for
> > bugzilla"?
> >
> >> It is designed to be more open and more easily fixable.
> >
> > Sure.  More open then a self-registering system.  Gotcha.
>
> We actually have a FAQ entry about that. See "But there is access controls?
> Why is there access controls?" on
> http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq

umm, that should of course read "are" instead of "is" ...
-mike

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

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

[Stefan Schweizer]

Mike Frysinger wrote:

> On Friday 09 June 2006 15:01, Stefan Schweizer wrote:
>> Chris Gianelloni wrote:
>> > Everyone that you happen to include as allowed to actually commit, you
>> > mean.  As opposed to "everyone that can sign themselves up for
>> > bugzilla"?
>> >
>> >> It is designed to be more open and more easily fixable.
>> >
>> > Sure.  More open then a self-registering system.  Gotcha.
>>
>> We actually have a FAQ entry about that. See "But there is access
>> controls? Why is there access controls?" on
>> http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
> 
> umm, that should of course read "are" instead of "is" ...
> -mike

I picked that up from wolf31o2, 08 Juni 2006 18:27:47:
".. Also, who is going to
control access to this resource?  Why is there access controls? .."

Seems I was wrong in thinking the native knows the language better ;)

Well, I will change it as soon as possible. Currently all the wiki and avn
are locked until the council meeting.

Thanks for the comment.

-Stefan

-- 
gentoo-dev@gentoo.org mailing list

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

[Christian Birchinger]

On Fri, Jun 09, 2006 at 02:04:57PM +0200, Stefan Schweizer wrote:
>
> "svn co http://overlays.gentoo.org/svn/proj/sunrise/category/application"
> "emerge application"
> 

As long as it's made for pulling single ebuilds (and their
support files), i think it's really helpfull.

It's exactly the same as downloading single ebuilds from
Bugzilla just without the pain of using bugzilla for it.
While Bugzilla is fine for handling bugs, i think it's
annoying to use for maintaining and downloading ebuilds.

The "danger" of people breaking something is exactly the
same though. I don't see a difference between downloading
an ebuild with bugzilla and fetching them with svn.

What i would fear is a full overlay with eclasses and many
other things the user didn't cherry pick.

I would mostly like a method to easily add external ebuilds
to my own overlay.
When that source allows people to maintain their ebuilds in
a simple way, it's also better. Raising the annoyance bar
for handling ebuilds doesn't increase their quality.


Christian
-- 
gentoo-dev@gentoo.org mailing list

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

[Henrik Brix Andersen]

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

On Sun, Jun 11, 2006 at 03:42:19PM +0200, Christian Birchinger wrote:
> On Fri, Jun 09, 2006 at 02:04:57PM +0200, Stefan Schweizer wrote:
> >
> > "svn co http://overlays.gentoo.org/svn/proj/sunrise/category/application"
> > "emerge application"
> > 
> 
> As long as it's made for pulling single ebuilds (and their
> support files), i think it's really helpfull.

The way SVN works you can just as easily do "svn co
http://overlays.gentoo.org/svn/proj/sunrise/" and get the full
repository - so no, this is not limited to pulling single ebuilds.

./Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 213 bytes --]

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

[Luis Francisco Araujo]

Stuart Herbert wrote:
> On 6/8/06, Henrik Brix Andersen <brix@gentoo.org> wrote:
>> Will you also review the code each and every ebuild pull down over the
>> internet?
>
> The policy for overlays.gentoo.org hosting [1] is hopefully clear: as
> the project leads, they're ultimately responsible (and therefore
> accountable) for what goes into their project overlay - no matter
> whether it's committed by a dev or by a user who has been entrusted
> with commit rights to the overlay.
>
> The policy for what can go into an overlay is also hopefully clear:
> overlays are for package trees, their patchsets, any docs, and any
> downloadable tarballs that have nowhere else to be hosted.  It's not
> there to be $UPSTREAM, except for eselect modules, -config scripts and
> the like that exist purely to support ebuilds in the package tree.
>
> I expect projects and developers who are using overlays to be
> respectful of others.  The whole point of the overlays project is to
> continue our work in trying to get our users much more involved in
> developing Gentoo.  It's there to be a stepping stone for getting
> packages into the tree - although I do not expect every package in
> overlays to end up in the tree.  Any hostile hijacking of other
> people's packages doesn't fit into that vision, and there's no place
> for it on o.g.o.
>
> I also expect projects and developers who are not using overlays to be
> equally respectful of those who are.  There are projects and
> developers who find overlays an excellent way of safely testing and
> developing ebuilds, and who find overlays to be a good way to help
> train and develop the next generation of Gentoo developers (good
> developers are something we really need more of).
>
That is being done with the per-group overlays. No need to have a
maintainer-wanted official overlay for it.


-- 
gentoo-dev@gentoo.org mailing list

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

[Diego 'Flameeyes' Pettenò]

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

On Thursday 08 June 2006 20:58, Markus Ullmann wrote:
> 3) replacement for bugs.g.o
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.

> 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.
This is appreciated. On this note, I would like to ask what are you going to 
do with eclasses. From my POV I'd ask to absolutely _not_ touching eclasses 
at all in the overlay. I have bad past experiences with overlays replacing 
eclasses. As bad as with xgl overlay rewriting some of the kde packages and 
breaking then with gcc 4.1 :)

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Chris Gianelloni]

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

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

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

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

[Markus Ullmann]

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

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

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

[Chris Gianelloni]

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

On Fri, 2006-06-09 at 00:30 +0200, Markus Ullmann wrote:
> > 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.

Not like you think that they are.  Let me try to make this clearer.

The php overlay is maintained by the php developers.  They are
intimately aware of the issues with their package, and are probably
aware of any security bugs before the rest of us.

You are talking about a random collection of ebuilds with absolutely no
cohesiveness other than they were submitted to bugzilla.  How are you
going to maintain any form of security on this project?

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

No.  It clearly says that you would be doing the basic QA checks and
repoman checking on initial commit.  You even said it right above where
I commented!

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

Umm... so now I need to go and instead of clicking a nice link in
bugzilla, trawl through the subversion repository and find what I'm
looking for?  How exactly is downloading things via http any different
than downloading them from bugzilla, which is also http?

Now, I know that you're not an idiot, so please don't treat me like one.

> Or, if you want some history like sources.g.o, you can do so as well here:
> http://overlays.gentoo.org/proj/sunrise/browser/

Excellent.  So we're moving the history from being in a single location
(the bug) to being in multiple locations.  That will definitely improve
the development process.  Another thing that people tend to miss is that
not all improved versions of ebuilds submitted to bugzilla are done byt
he original authors.  There are many cases where an initial ebuild is
done, a developer makes comments on what needs to be changed, and
*another* contributor gives a fixed ebuild.  How exactly will this
streamline that process?  No offense, but everything I have seen looks
as if it will add even *more* overhead to actually getting packages into
the tree.  The only thing this seems to provide is a half-baked
repository for the users to get marginally-tested ebuilds for software
that wasn't interesting enough for inclusion in the tree.

> > Except that I can *look* at an ebuild without having to break out a
> > subversion client currently.
> See my answer in 3)

See mine.  ;]

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

This is a bug for an ebuild that the user does not think is related to
the pam_skey.  Go back and read what I wrote.

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

Again, read what I wrote.  I said that the developer would see "sunrise"
in the PORTDIR_OVERLAY of the user's emerge --info, which you reiterated
without considering.  This is a login bug.  At no point did they make
mention of having installed pam_skey from this overlay.  This means that
I, as the developer getting this bug, am now responsible for looking at
*every package* in the sunrise overlay to determine if *any* of them
could *possibly* be affecting this package or causing this bug, then
asking the user if they have any of them installed.

Wouldn't this process be *infinitely* easier if instead of "sunrise"
there was a "pam" overlay with *only* the pam stuff?

That is *exactly* what we get with the other overlays like php and
vmware.  I *know* that if I'm looking at a glibc bug and the user has
"php" as an overlay, that it isn't going to be a concern.

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

They do this in a very quick and cursory manner.  They do a pretty good
job of it, but there are countless bugs which they do not catch that are
not assigned properly or end up being invalid due to user negligence.
The bug wranglers cannot be *expected* to perform this level of service,
lest they burn out and run away within a couple weeks.  ;]

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

This is a prime example of totally glossing over any discussion to make
it sound promising for you.  How exactly is a proxy maintainer going to
know that a new version of an ebuild has been committed?  Either by
watching the overlay like a hawk, or when the maintainer
emails/pings/whatever and lets him know that there's a new version.  How
exactly is this easier to track?  Even better, if I am the proxy
maintainer for a particular set of ebuilds for one or more
user/maintainers, why do I need it in your big, bloated, and completely
inappropriately-named "sunshine" overlay versus a developer overlay of
my own?  After all, I am the *only* proxy maintainer.  Why should there
be the added *insecurity* of allowing any number of people that *I*
might not trust complete access to the small number of packages where I
am the proxy?

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

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

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

[Markus Ullmann]

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

Chris Gianelloni wrote:
> On Fri, 2006-06-09 at 00:30 +0200, Markus Ullmann wrote:
>>> 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.
> 
> Not like you think that they are.  Let me try to make this clearer.
> 
> The php overlay is maintained by the php developers.  They are
> intimately aware of the issues with their package, and are probably
> aware of any security bugs before the rest of us.
> 
> You are talking about a random collection of ebuilds with absolutely no
> cohesiveness other than they were submitted to bugzilla.  How are you
> going to maintain any form of security on this project?
> 

The approach is to get them maintained... But there is a chance that
there'll be security bugs in it, I admit that. Once we know about it, we
p.mask it as we have support for it in the overlay. I'm following most
common vuln lists and run some automated scripts already on installed
packages, should be easy to adapt them to search one other dir as well.

>>>> 2) responsibility
>>>>
> 
> No.  It clearly says that you would be doing the basic QA checks and
> repoman checking on initial commit.  You even said it right above where
> I commented!

You're doing some witch hunting here... I said we keep an eye on
non-devs commits.

> 
>>> 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.
> 
> Umm... so now I need to go and instead of clicking a nice link in
> bugzilla, trawl through the subversion repository and find what I'm
> looking for?  How exactly is downloading things via http any different
> than downloading them from bugzilla, which is also http?

the key difference is that you only need one wget command to get a
completely prepared dir to work on, no ebuild renaming manual files/
population needed.

> Now, I know that you're not an idiot, so please don't treat me like one.

Was really not the intention.. You keeped the svn requirement which is
simply wrong. Needed to make that clear.

>> Or, if you want some history like sources.g.o, you can do so as well here:
>> http://overlays.gentoo.org/proj/sunrise/browser/
> 
> Excellent.  So we're moving the history from being in a single location
> (the bug) to being in multiple locations.  That will definitely improve
> the development process.  Another thing that people tend to miss is that
> not all improved versions of ebuilds submitted to bugzilla are done byt
> he original authors.  There are many cases where an initial ebuild is
> done, a developer makes comments on what needs to be changed, and
> *another* contributor gives a fixed ebuild.  How exactly will this
> streamline that process?  No offense, but everything I have seen looks
> as if it will add even *more* overhead to actually getting packages into
> the tree.  The only thing this seems to provide is a half-baked
> repository for the users to get marginally-tested ebuilds for software
> that wasn't interesting enough for inclusion in the tree.

we want to encourage users to contribute and if they do good
contributions in bugzilla they get commit access to the overlay. and
then the workload is drastically reduced...

>>> 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.
> 
> This is a bug for an ebuild that the user does not think is related to
> the pam_skey.  Go back and read what I wrote.
> 

it was agreed upon that we don't keep extra bugzilla or whatever for all
things on o.g.o but keep track of all issues within bugs.g.o. and btw,
most work on "new" bugs is done by bug wranglers and not the common
devs. So if they say the workload from it is too high, I'll take it as
valid reason as they have to handle it.

>> 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...)
> 
> Again, read what I wrote.  I said that the developer would see "sunrise"
> in the PORTDIR_OVERLAY of the user's emerge --info, which you reiterated
> without considering.  This is a login bug.  At no point did they make
> mention of having installed pam_skey from this overlay.  This means that
> I, as the developer getting this bug, am now responsible for looking at
> *every package* in the sunrise overlay to determine if *any* of them
> could *possibly* be affecting this package or causing this bug, then
> asking the user if they have any of them installed.

why would a pam dev get this bug? as far as I know bug wranglers work, a
check whether the ebuild is in tree is one of the first ones... So the
chance that it really hits the pam dev is damn small...
We're not the first large overlay project, there are other ones out
there already and these "wrong" bugs aren't a new thing arising here...

> Wouldn't this process be *infinitely* easier if instead of "sunrise"
> there was a "pam" overlay with *only* the pam stuff?

Then the pam devs are responsible for all the things with it. As it
would surely be hosted on o.g.o then, we'll notice it and either shift
all ebuilds we have in the sunrise tree over or do whatever is fine with
pam devs. If they really dislike the m-w bugs out of their control, then
a friendly note on irc, a friendly mail or whatever is enough and we
won't touch things of them then...

> That is *exactly* what we get with the other overlays like php and
> vmware.  I *know* that if I'm looking at a glibc bug and the user has
> "php" as an overlay, that it isn't going to be a concern.

Well we don't keep ebuilds in there which have a maintainer in contrast
to the php overlay. they may even keep newer versions of in-tree
packages in their overlays.

>>> 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...
> 
> They do this in a very quick and cursory manner.  They do a pretty good
> job of it, but there are countless bugs which they do not catch that are
> not assigned properly or end up being invalid due to user negligence.
> The bug wranglers cannot be *expected* to perform this level of service,
> lest they burn out and run away within a couple weeks.  ;]

Well a simple grep for "sunrise" in there will show the needed thing...

And, sorry, if one or another bug slips through. Wranglers are humans as
well and humans make mistakes. Also you can't expect them to know about
all issues. But that is a bit off-topic here.
Just a last note on it: the main bug wrangler is helping us as well as
commiting so I guess he notices the problems with sunrise...

>>> 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...
> 
> This is a prime example of totally glossing over any discussion to make
> it sound promising for you.  How exactly is a proxy maintainer going to
> know that a new version of an ebuild has been committed?  Either by
> watching the overlay like a hawk, or when the maintainer
> emails/pings/whatever and lets him know that there's a new version.  How
> exactly is this easier to track?  Even better, if I am the proxy
> maintainer for a particular set of ebuilds for one or more
> user/maintainers, why do I need it in your big, bloated, and completely
> inappropriately-named "sunshine" overlay versus a developer overlay of
> my own?  After all, I am the *only* proxy maintainer.  Why should there
> be the added *insecurity* of allowing any number of people that *I*
> might not trust complete access to the small number of packages where I
> am the proxy?

Tracking:
First we want people to get used to it. Adding some random features like
automated email upon a special commit can be added easily with just two
lines in the post-commit hook...

Dev-Overlay:
Well you're free to use the dev overlay for it. But if you keep it on
the sunrise overlay, it (hopefully) gets more tested.

Greetz,
Jokey


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

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

[Ciaran McCreesh]

On Fri, 09 Jun 2006 02:49:14 +0200 Markus Ullmann <jokey@gentoo.org>
wrote:
| > No.  It clearly says that you would be doing the basic QA checks and
| > repoman checking on initial commit.  You even said it right above
| > where I commented!
| 
| You're doing some witch hunting here... I said we keep an eye on
| non-devs commits.

How much do you want to bet that I couldn't sneak malicious code past
you?

And if you accept that I could do it, you're also admitting that quite
a few other random people, some of whom don't share my own ethical
objections to such a stunt, could also pull it off given sufficient
time and effort...

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


-- 
gentoo-dev@gentoo.org mailing list

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

[Christel Dahlskjaer]

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

On Fri, 2006-06-09 at 02:08 +0100, Ciaran McCreesh wrote:
> On Fri, 09 Jun 2006 02:49:14 +0200 Markus Ullmann <jokey@gentoo.org>
> wrote:
> | > No.  It clearly says that you would be doing the basic QA checks and
> | > repoman checking on initial commit.  You even said it right above
> | > where I commented!
> | 
> | You're doing some witch hunting here... I said we keep an eye on
> | non-devs commits.
> 
> How much do you want to bet that I couldn't sneak malicious code past
> you?
> 
> And if you accept that I could do it, you're also admitting that quite
> a few other random people, some of whom don't share my own ethical
> objections to such a stunt, could also pull it off given sufficient
> time and effort...

I'd say that it's entirely possibly for some non-dev to sneak malicious
code into the tree as is now, just as it will be possible to do in an
overlay.   

It's not like it's particulary difficult to have someone proxy for you,
and let's face it, if someone is willing to do so then they probably
can't be arsed checking that what they are committing is clean and
nice.. I mean, I trust you, right? 



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

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

[Ciaran McCreesh]

On Fri, 09 Jun 2006 20:06:04 +0100 Christel Dahlskjaer
<christel@gentoo.org> wrote:
| I'd say that it's entirely possibly for some non-dev to sneak
| malicious code into the tree as is now, just as it will be possible
| to do in an overlay.   
| 
| It's not like it's particulary difficult to have someone proxy for
| you, and let's face it, if someone is willing to do so then they
| probably can't be arsed checking that what they are committing is
| clean and nice.. I mean, I trust you, right? 

Huge difference between committing a few things for a person you know,
where you have time to review code, and bulk committing random stuff
where you don't have time to check anything. That's the deal here -- if
a large number of developers can't handle maintainer-wanted, what makes
people think a far smaller number can without screwing up?

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


-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

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

On Fri, 2006-06-09 at 20:32 +0100, Ciaran McCreesh wrote:
> Huge difference between committing a few things for a person you know,
> where you have time to review code, and bulk committing random stuff
> where you don't have time to check anything. That's the deal here -- if
> a large number of developers can't handle maintainer-wanted, what makes
> people think a far smaller number can without screwing up?

*ding* *ding* *ding* *ding* *ding*

We have a winner!

What do we have for our winner, today, Dianne?

Isn't that nice, a turkey baster!

;]

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

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

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

[Christel Dahlskjaer]

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

On Fri, 2006-06-09 at 20:32 +0100, Ciaran McCreesh wrote:
> On Fri, 09 Jun 2006 20:06:04 +0100 Christel Dahlskjaer
> <christel@gentoo.org> wrote:
> | I'd say that it's entirely possibly for some non-dev to sneak
> | malicious code into the tree as is now, just as it will be possible
> | to do in an overlay.   
> | 
> | It's not like it's particulary difficult to have someone proxy for
> | you, and let's face it, if someone is willing to do so then they
> | probably can't be arsed checking that what they are committing is
> | clean and nice.. I mean, I trust you, right? 
> 
> Huge difference between committing a few things for a person you know,
> where you have time to review code, and bulk committing random stuff
> where you don't have time to check anything. That's the deal here -- if
> a large number of developers can't handle maintainer-wanted, what makes
> people think a far smaller number can without screwing up?

I was actually agreeing with you. 

I also believe to be mistaken as I believed that all overlays on o.g.o
would be in the style of say the existing PHP and Haskell overlays, and
as such those with access would be trusted contributors, and I also
believed that the individual projects would be making sure that they
were testing and reviewing whatever patches were made to their stuff. 



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

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

[Chris Gianelloni]

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

On Fri, 2006-06-09 at 02:49 +0200, Markus Ullmann wrote:
> > Excellent.  So we're moving the history from being in a single location
> > (the bug) to being in multiple locations.  That will definitely improve
> > the development process.  Another thing that people tend to miss is that
> > not all improved versions of ebuilds submitted to bugzilla are done byt
> > he original authors.  There are many cases where an initial ebuild is
> > done, a developer makes comments on what needs to be changed, and
> > *another* contributor gives a fixed ebuild.  How exactly will this
> > streamline that process?  No offense, but everything I have seen looks
> > as if it will add even *more* overhead to actually getting packages into
> > the tree.  The only thing this seems to provide is a half-baked
> > repository for the users to get marginally-tested ebuilds for software
> > that wasn't interesting enough for inclusion in the tree.
> 
> we want to encourage users to contribute and if they do good
> contributions in bugzilla they get commit access to the overlay. and
> then the workload is drastically reduced...

You didn't answer anything I asked here.

> > This is a bug for an ebuild that the user does not think is related to
> > the pam_skey.  Go back and read what I wrote.
> > 
> 
> it was agreed upon that we don't keep extra bugzilla or whatever for all
> things on o.g.o but keep track of all issues within bugs.g.o. and btw,
> most work on "new" bugs is done by bug wranglers and not the common
> devs. So if they say the workload from it is too high, I'll take it as
> valid reason as they have to handle it.

I'm sorry, but you're avoiding the question here.  How will the
bug-wranglers even *know* that this is related to a package in the
overlay?  They wouldn't.  As I ststed *repeatedly* now.  The user has
not mentioned that they're using pam_skey, as is a common occurrence in
bugs.

> > Again, read what I wrote.  I said that the developer would see "sunrise"
> > in the PORTDIR_OVERLAY of the user's emerge --info, which you reiterated
> > without considering.  This is a login bug.  At no point did they make
> > mention of having installed pam_skey from this overlay.  This means that
> > I, as the developer getting this bug, am now responsible for looking at
> > *every package* in the sunrise overlay to determine if *any* of them
> > could *possibly* be affecting this package or causing this bug, then
> > asking the user if they have any of them installed.
> 
> why would a pam dev get this bug? as far as I know bug wranglers work, a
> check whether the ebuild is in tree is one of the first ones... So the
> chance that it really hits the pam dev is damn small...

Because the user has "pam" in USE and there's nothing else indiciating
that they're using some pam packages from an overlay that has absolutely
no hint as to its contents.  Also, as I have said, while the bug
wranlgers are wonderful and really do reduce our workload, they're
*nowhere* near perfect.  There are *tons* of bugs that go to the wrong
people, or are simply invalid once the actual maintainers see it.  The
bug wranglers cannot be expected to be experts on every package.  Your
comments make it sound like they will be.

> We're not the first large overlay project, there are other ones out
> there already and these "wrong" bugs aren't a new thing arising here...

No.  You're the first large overlay project that is on official Gentoo
infrastructure, even after it was agreed that there wouldn't be
something like this.  With the non-official projects, we simply don't
support any bugs from anyone using them.  It's that simple.  With this
project, you're vying for official status, meaning we cannot do that.
This will be an *enormous* time sink for the entire ebuild developer
pool.

> > Wouldn't this process be *infinitely* easier if instead of "sunrise"
> > there was a "pam" overlay with *only* the pam stuff?
> 
> Then the pam devs are responsible for all the things with it. As it
> would surely be hosted on o.g.o then, we'll notice it and either shift
> all ebuilds we have in the sunrise tree over or do whatever is fine with
> pam devs. If they really dislike the m-w bugs out of their control, then
> a friendly note on irc, a friendly mail or whatever is enough and we
> won't touch things of them then...

Excellent job of avoiding the issue.

I asked how the pam developers would even *know* that there is pam crap
in your aptly-named "sunrise" overlay, and you respond with a comment
about how when the pam devs tell you to move the packages you will.

I am honestly seeing that this is starting to go nowhere as the answers
to my questions aren't being given, and instead the issues are being
avoided.

> > That is *exactly* what we get with the other overlays like php and
> > vmware.  I *know* that if I'm looking at a glibc bug and the user has
> > "php" as an overlay, that it isn't going to be a concern.
> 
> Well we don't keep ebuilds in there which have a maintainer in contrast
> to the php overlay. they may even keep newer versions of in-tree
> packages in their overlays.

That doesn't have anything to do with what I stated.  Again, avoiding
the issue.

> > They do this in a very quick and cursory manner.  They do a pretty good
> > job of it, but there are countless bugs which they do not catch that are
> > not assigned properly or end up being invalid due to user negligence.
> > The bug wranglers cannot be *expected* to perform this level of service,
> > lest they burn out and run away within a couple weeks.  ;]
> 
> Well a simple grep for "sunrise" in there will show the needed thing...

So I can mark any bug that has sunrise in it as INVALID, then, because
the overlay is going to be known to be in an unmaintained state?

Perfect.

> And, sorry, if one or another bug slips through. Wranglers are humans as
> well and humans make mistakes. Also you can't expect them to know about
> all issues. But that is a bit off-topic here.

No.  It is *exactly* the topic that I am speaking of, which you're
avoiding.

> Just a last note on it: the main bug wrangler is helping us as well as
> commiting so I guess he notices the problems with sunrise...

So having one extra man on the team is going to alleviate all of the
problems?  Excellent.  My fears are quelled.

> > This is a prime example of totally glossing over any discussion to make
> > it sound promising for you.  How exactly is a proxy maintainer going to
> > know that a new version of an ebuild has been committed?  Either by
> > watching the overlay like a hawk, or when the maintainer
> > emails/pings/whatever and lets him know that there's a new version.  How
> > exactly is this easier to track?  Even better, if I am the proxy
> > maintainer for a particular set of ebuilds for one or more
> > user/maintainers, why do I need it in your big, bloated, and completely
> > inappropriately-named "sunshine" overlay versus a developer overlay of
> > my own?  After all, I am the *only* proxy maintainer.  Why should there
> > be the added *insecurity* of allowing any number of people that *I*
> > might not trust complete access to the small number of packages where I
> > am the proxy?
> 
> Tracking:
> First we want people to get used to it. Adding some random features like
> automated email upon a special commit can be added easily with just two
> lines in the post-commit hook...
> 
> Dev-Overlay:
> Well you're free to use the dev overlay for it. But if you keep it on
> the sunrise overlay, it (hopefully) gets more tested.

No offense, but this email was pretty much useless as you avoided my
questions with lots of vague references to how it will make things
"better" and didn't bother to actually thoughtfully answer any of my
points.

I'm through wasting my time with this.  If I see a bug with sunrise,
it's going INVALID, as it is now apparent to me that the issues with the
project won't be resolved.

So long, and thanks for all the fish.

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

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

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

[Brian Harring]

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

On Fri, Jun 09, 2006 at 08:16:32AM -0400, Chris Gianelloni wrote:
> On Fri, 2006-06-09 at 02:49 +0200, Markus Ullmann wrote:
> > > This is a bug for an ebuild that the user does not think is related to
> > > the pam_skey.  Go back and read what I wrote.
> > > 
> > 
> > it was agreed upon that we don't keep extra bugzilla or whatever for all
> > things on o.g.o but keep track of all issues within bugs.g.o. and btw,
> > most work on "new" bugs is done by bug wranglers and not the common
> > devs. So if they say the workload from it is too high, I'll take it as
> > valid reason as they have to handle it.
> 
> I'm sorry, but you're avoiding the question here.  How will the
> bug-wranglers even *know* that this is related to a package in the
> overlay?  They wouldn't.  As I ststed *repeatedly* now.  The user has
> not mentioned that they're using pam_skey, as is a common occurrence in
> bugs.

Curious, how will the wrangler know in general?  *cough* they won't.

You're using a generic arguement against a specific target- iow, apply 
it to overlays.g.o in general instead of singling sunrise out via it.

Meanwhile, answer to that one is better bug data for reporting- dump 
of (random out of the ass example) first level deps, and where they 
came from (overlay/portdir).

Downside to that data is that slackers will automatically punt the bug 
if they see non portdir in cases where it's obvious it's an issue in 
the pkg rather then the deps, but there always is a downside...


> > We're not the first large overlay project, there are other ones out
> > there already and these "wrong" bugs aren't a new thing arising here...
> 
> No.  You're the first large overlay project that is on official Gentoo
> infrastructure, even after it was agreed that there wouldn't be
> something like this.  With the non-official projects, we simply don't
> support any bugs from anyone using them.  It's that simple.  With this
> project, you're vying for official status, meaning we cannot do that.
> This will be an *enormous* time sink for the entire ebuild developer
> pool.

Same for above re: "large overlay", realistically, like it or not the 
general case of N overlay/repo is coming down the pipe.

Personally, I'd rather see this particular case be handled from the 
get go as an experiment- lay out from the start the exit conditions 
for it (if it becomes a dumping ground, out she goes).

Reason?  Devs/users have been after a true testing branch/repo from 
day one, if we're doing overlays and people are willing to try and 
supply that demand, lets get the question answered once and for all 
(instead of everyone and their mother shooting off about every 
potential they can think of for why it might fail).

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Henrik Brix Andersen]

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

On Fri, Jun 09, 2006 at 05:42:01AM -0700, Brian Harring wrote:
> Curious, how will the wrangler know in general?  *cough* they won't.
> 
> You're using a generic arguement against a specific target- iow, apply 
> it to overlays.g.o in general instead of singling sunrise out via it.

Well, the other overlays at overlays.gentoo.org will primarily be
team/herd specific overlays as I understand it - overlays maintained
by the people managing the ebuilds.

If a bug ticks in about, say, a KDE related ebuild it will be assigned
to the KDE herd - who are in a much better position to know whether or
not this bug might be caused by something available in their project
overlay, since they're the ones who put it there in the first place.

Sincerely,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 213 bytes --]

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

[Chris Gianelloni]

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

On Fri, 2006-06-09 at 05:42 -0700, Brian Harring wrote:
> On Fri, Jun 09, 2006 at 08:16:32AM -0400, Chris Gianelloni wrote:
> > On Fri, 2006-06-09 at 02:49 +0200, Markus Ullmann wrote:
> > > > This is a bug for an ebuild that the user does not think is related to
> > > > the pam_skey.  Go back and read what I wrote.
> > > > 
> > > 
> > > it was agreed upon that we don't keep extra bugzilla or whatever for all
> > > things on o.g.o but keep track of all issues within bugs.g.o. and btw,
> > > most work on "new" bugs is done by bug wranglers and not the common
> > > devs. So if they say the workload from it is too high, I'll take it as
> > > valid reason as they have to handle it.
> > 
> > I'm sorry, but you're avoiding the question here.  How will the
> > bug-wranglers even *know* that this is related to a package in the
> > overlay?  They wouldn't.  As I ststed *repeatedly* now.  The user has
> > not mentioned that they're using pam_skey, as is a common occurrence in
> > bugs.
> 
> Curious, how will the wrangler know in general?  *cough* they won't.

I already covered this.  If you're going to be a part of the
conversation, try to keep up, will you?  *grin*

> You're using a generic arguement against a specific target- iow, apply 
> it to overlays.g.o in general instead of singling sunrise out via it.

Except the other overlays are not designed as end-user overlays.  They
are designed to aid developers.  Also, they are targeted at a specific
task/goal, as opposed to being a dumping ground for the unwanted and
unmaintained.

> Meanwhile, answer to that one is better bug data for reporting- dump 
> of (random out of the ass example) first level deps, and where they 
> came from (overlay/portdir).

I definitely agree that better bug data would help the situation.
However, it does not change the fact that this is still a dumping
ground.  Again, this was something that was *explicitly* stated that
overlays.gentoo.org would *not* become, yet here we are.

> Downside to that data is that slackers will automatically punt the bug 
> if they see non portdir in cases where it's obvious it's an issue in 
> the pkg rather then the deps, but there always is a downside...

Most people tend to not punt the bug so much as ask for proof that it
isn't caused by the overlay.  I know that we have done this in games and
it has almost always ended up as something the user has done thanks to
an overlay.  In the cases where it truly is a bug, we fix it.

> > > We're not the first large overlay project, there are other ones out
> > > there already and these "wrong" bugs aren't a new thing arising here...
> > 
> > No.  You're the first large overlay project that is on official Gentoo
> > infrastructure, even after it was agreed that there wouldn't be
> > something like this.  With the non-official projects, we simply don't
> > support any bugs from anyone using them.  It's that simple.  With this
> > project, you're vying for official status, meaning we cannot do that.
> > This will be an *enormous* time sink for the entire ebuild developer
> > pool.
> 
> Same for above re: "large overlay", realistically, like it or not the 
> general case of N overlay/repo is coming down the pipe.

Sure.  Doesn't mean I have to support anything but the one and only
official Gentoo package repository.  Complain all you want, but I became
a Gentoo developer, not a $random_repository developer for a reason.

> Personally, I'd rather see this particular case be handled from the 
> get go as an experiment- lay out from the start the exit conditions 
> for it (if it becomes a dumping ground, out she goes).

I'd rather the things that were agreed upon when the overlays project
was started were actually adhered to, instead.  I guess it is just too
much to ask from some people to keep their word.

...and people wonder why Gentoo developers don't trust each other
anymore.

> Reason?  Devs/users have been after a true testing branch/repo from 
> day one, if we're doing overlays and people are willing to try and 
> supply that demand, lets get the question answered once and for all 
> (instead of everyone and their mother shooting off about every 
> potential they can think of for why it might fail).

Fine.  Make a proposal to actually add it to the tree and do it
properly.  There's no need to have this sort of thing limited to a very
small subset of developers who couldn't *possibly* keep up with the
workload.  Yes, there will only be a few developers and they'll be
really busy, especially since they're going to be checking every commit
to ensure that there's no malicious code......

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

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

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

[Patrick Lauer]

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

On Thu, 2006-06-08 at 20:06 -0400, Chris Gianelloni wrote:
> > 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.
> 
> Umm... so now I need to go and instead of clicking a nice link in
> bugzilla, trawl through the subversion repository and find what I'm
> looking for?  How exactly is downloading things via http any different
> than downloading them from bugzilla, which is also http?
just my point of view - 

bugzilla sucks. Ever had to download 10 attachments for one ebuild?
It is a good tool for discussion, but I would prefer a simple tool (like
layman) that can automatically update things. You obviously don't like
overlays, but that shouldn't be a reason to stop us from using it. 

> > Or, if you want some history like sources.g.o, you can do so as well here:
> > http://overlays.gentoo.org/proj/sunrise/browser/
> 
> Excellent.  So we're moving the history from being in a single location
> (the bug) to being in multiple locations.  That will definitely improve
> the development process.  
Yes, now it is easier to check out the ebuilds. More users ==> better
testing.
;-)

>   No offense, but everything I have seen looks
> as if it will add even *more* overhead to actually getting packages into
> the tree.  The only thing this seems to provide is a half-baked
> repository for the users to get marginally-tested ebuilds for software
> that wasn't interesting enough for inclusion in the tree.
That differs from the 20 or so overlays maintained by users how?
Honestly I'd prefer an overlay where I can marginally trust the content
over a "foreign" repository maintained by people I don't know.
And the quality of some of the overlays ... better have that supervised
by devs, they should know how to handle b0rkage.

> > > Except that I can *look* at an ebuild without having to break out a
> > > subversion client currently.
> > See my answer in 3)
> See mine.  ;]
Hmmm ... bugzilla.
Instead of a simple cvs up; cd /usr/local/portage/category/package I
need to search for ALL bugs with $name in it, look which one it is,
curse bugzilla for falling asleep again, see which attachments are
relevant, download them, curse bugzilla for falling asleep again, copy
them to my overlay, read the bugcomments to see if any special renaming
or directory structure is needed ...

Hmmm. I think an overlay does have some advantages there ...

> 
> Again, read what I wrote.  I said that the developer would see "sunrise"
> in the PORTDIR_OVERLAY of the user's emerge --info, which you reiterated
> without considering.  This is a login bug.  At no point did they make
> mention of having installed pam_skey from this overlay.  This means that
> I, as the developer getting this bug, am now responsible for looking at
> *every package* in the sunrise overlay to determine if *any* of them
> could *possibly* be affecting this package or causing this bug, then
> asking the user if they have any of them installed.
This differs from a manually patched ebuild in /usr/portage by virtue of showing you that an overlay is used ...

> Wouldn't this process be *infinitely* easier if instead of "sunrise"
> there was a "pam" overlay with *only* the pam stuff?
Ooooh, cool. Now I need about 75 overlays to get things done, and of course there will be no bad interaction between them ;-)

Having one overlay with a focus on not-in-portage ebuilds should not
cause the scenario you described and will most likely cause less weird
bugs because of intra-overlay dependencies.
</opinion>

> That is *exactly* what we get with the other overlays like php and
> vmware.  I *know* that if I'm looking at a glibc bug and the user has
> "php" as an overlay, that it isn't going to be a concern.
... and if we control the overlay we can exclude things like system
packages easily.
Could be part of the policy to not touch existing ebuilds.

> This is a prime example of totally glossing over any discussion to make
> it sound promising for you. 
If bugzilla wasn't so sucky people wouldn't try to use other methods of
communication ;-)

And again, one svn repo vs. 113 hard-to-find bugs ...

>  Even better, if I am the proxy
> maintainer for a particular set of ebuilds for one or more
> user/maintainers, why do I need it in your big, bloated, and completely
> inappropriately-named "sunshine" overlay versus a developer overlay of
> my own?  
You don't. Please use your developer overlay. Please don't try to take
away our more open overlay.

> After all, I am the *only* proxy maintainer.  Why should there
> be the added *insecurity* of allowing any number of people that *I*
> might not trust complete access to the small number of packages where I
> am the proxy?
It's your choice. Either you get mailbombed with each minor version update or you trust them to not screw up with the sunrise overlay.

And the users could just create their own overlay, get it added to
layman and we'd have the same without supervision. From where I'm
standing it's better to have the possibility to nuke a bad ebuild in the
overlay instead of asking some random user to change this in that
overlay because of $problem.

Maybe we even find some motivated new ebuild monkeys that have the
motivation to become devs ... one can always hope :-)


Patrick
-- 
Stand still, and let the rest of the universe move

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

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

[Jakub Moc]

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

Patrick Lauer wrote:
> On Thu, 2006-06-08 at 20:06 -0400, Chris Gianelloni wrote:

>> Again, read what I wrote.  I said that the developer would see "sunrise"
>> in the PORTDIR_OVERLAY of the user's emerge --info, which you reiterated
>> without considering.  This is a login bug.  At no point did they make
>> mention of having installed pam_skey from this overlay.  This means that
>> I, as the developer getting this bug, am now responsible for looking at
>> *every package* in the sunrise overlay to determine if *any* of them
>> could *possibly* be affecting this package or causing this bug, then
>> asking the user if they have any of them installed.
> This differs from a manually patched ebuild in /usr/portage by virtue of showing you that an overlay is used ...
> 
>> Wouldn't this process be *infinitely* easier if instead of "sunrise"
>> there was a "pam" overlay with *only* the pam stuff?
> Ooooh, cool. Now I need about 75 overlays to get things done, and of course there will be no bad interaction between them ;-)

Please, leave pam_skey alone. ;) It's a thing I'm using daily and the
default system-auth config file installed by this ebuild allows for both
system and S/KEY passwords to be used at the same time, you can pick
whichever one you want. There's no way to get yourself locked out of
system unless you've already forgotten your normal password and didn't
yet set up OTP, in which case, it's not pam_skey problem at all.

The thing has been sitting in bugzilla for ages, I've asked Flameeyes to
commit it and he said he's not going to put any mode pam stuff into the
tree unless he's using the modules himself. Nothing wrong w/ that. So, I
can either keep on maintaining it in my local overlay or let other
people use it if they find it useful. I prefer the latter. pam_abl and
pam_mount is also stuff that I'm testing/using myself. The only thing I
haven't tested beyond "it compiles and installs" is pam_pgsql, that one
doesn't touch system-auth at all, comes w/ commented-out .conf and so
has no effect until the user has  configured it.

There are about 3 other bugs requesting pam stuff, but since that stuff
is essentially dead upstream, it won't be in the overlay. So, are you
asking to have a separate overlay project for 4 pam ebuilds? Heh, really
an overkill.

> Could be part of the policy to not touch existing ebuilds.

IMHO the sunrice project is a good place for maintainer-wanted/needed
bugs. Shouldn't be a dumpspace for whatever experimental patches for
stuff that's actually being maintained in the main tree.

>> This is a prime example of totally glossing over any discussion to make
>> it sound promising for you. 
> If bugzilla wasn't so sucky people wouldn't try to use other methods of
> communication ;-)

Erm, look at the vmware-server bug
(http://bugs.gentoo.org/show_bug.cgi?id=122500) . It's vastly useless
for grabbing any ebuilds, there are ~350 comments and tons of obsolete,
yet not marked as such ebuilds, that's why you switched to subversion,
right? And it boosted the effectivity by a huge margin. Also comes w/ a
nice side-effect of not bugspamming another 200 folks CCed on the bug
when someone screws w/ attachments for a couple of times.


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Diego 'Flameeyes' Pettenò]

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

On Friday 09 June 2006 11:06, Jakub Moc wrote:
> The thing has been sitting in bugzilla for ages, I've asked Flameeyes to
> commit it and he said he's not going to put any mode pam stuff into the
> tree unless he's using the modules himself.
Or if somebody wants to help with PAM and related... considering right now 
Azarah is mostly away and I'm almost alone handling the rest. 

Yes it's offtopic, but a quick way to remember that we need more PAM 
maintainers :)

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Chris Gianelloni]

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

On Fri, 2006-06-09 at 11:06 +0200, Jakub Moc wrote:
> The thing has been sitting in bugzilla for ages, I've asked Flameeyes to
> commit it and he said he's not going to put any mode pam stuff into the
> tree unless he's using the modules himself. Nothing wrong w/ that. So, I
> can either keep on maintaining it in my local overlay or let other
> people use it if they find it useful. I prefer the latter. pam_abl and
> pam_mount is also stuff that I'm testing/using myself. The only thing I
> haven't tested beyond "it compiles and installs" is pam_pgsql, that one
> doesn't touch system-auth at all, comes w/ commented-out .conf and so
> has no effect until the user has  configured it.

Uhh... You're a developer.  How about instead, you simply join the pam
team with Flameeyes and add these packages and maintain them yourself?

Do you really need an overlay with *countless* possibilities for other
ebuilds to maintain 4 packages?

> There are about 3 other bugs requesting pam stuff, but since that stuff
> is essentially dead upstream, it won't be in the overlay. So, are you
> asking to have a separate overlay project for 4 pam ebuilds? Heh, really
> an overkill.

No.  It is called a repository that actually has an explicit purpose.  I
guess you've missed all of the other overlays out there that are limited
to a specific scope.  The funny thing is that I *know* that you use at
least one of these external repositories, and I haven't heard you
complaining that you need to move these packages to some free-for-all
overlay such as this.  I wonder why that is?

> > Could be part of the policy to not touch existing ebuilds.
> 
> IMHO the sunrice project is a good place for maintainer-wanted/needed
> bugs. Shouldn't be a dumpspace for whatever experimental patches for
> stuff that's actually being maintained in the main tree.

It really is funny when you're arguing *for* something, yet you call it
the "sunrice" project.  Freudian slip, or an admission of truth?

> >> This is a prime example of totally glossing over any discussion to make
> >> it sound promising for you. 
> > If bugzilla wasn't so sucky people wouldn't try to use other methods of
> > communication ;-)
> 
> Erm, look at the vmware-server bug
> (http://bugs.gentoo.org/show_bug.cgi?id=122500) . It's vastly useless
> for grabbing any ebuilds, there are ~350 comments and tons of obsolete,
> yet not marked as such ebuilds, that's why you switched to subversion,
> right? And it boosted the effectivity by a huge margin. Also comes w/ a
> nice side-effect of not bugspamming another 200 folks CCed on the bug
> when someone screws w/ attachments for a couple of times.

So you're going to try to use my own project as an example against me?
Great.  Bring it on.

The vmware overlay is limited to only vmware products.  When someone
uses the overlay, they *know* that they are only getting ebuilds related
to vmware.  The project sunricer overlay is for any ebuilds of any kind.
It is not focused on anything, what-so-ever, and has had many arguments
against its use for many reasons.  In the future, if you're going to try
to use someone's project as an argument against them, at least try to
come up with an argument that works.  Using a focused overlay as an
example of why a massive, bloated, free-for-all overlay should exist
isn't exactly helping your argument, but instead helps mine.  Thanks for
making my work easier. =]

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

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

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

[Edward Catmur]

On Fri, 2006-06-09 at 10:28 +0200, Patrick Lauer wrote:
> > > > Except that I can *look* at an ebuild without having to break out a
> > > > subversion client currently.
> > > See my answer in 3)
> > See mine.  ;]
> Hmmm ... bugzilla.
> Instead of a simple cvs up; cd /usr/local/portage/category/package I
> need to search for ALL bugs with $name in it, look which one it is,
> curse bugzilla for falling asleep again, see which attachments are
> relevant, download them, curse bugzilla for falling asleep again, copy
> them to my overlay, read the bugcomments to see if any special renaming
> or directory structure is needed ...
> 
> Hmmm. I think an overlay does have some advantages there ...

Advantages? With bugzilla I: search for the bug, cc myself on it,
download the relevant files, look over them, note a style error, try to
merge it, fix a compilation bug, re-upload the fixed ebuild and patch to
bugzilla with a comment to the ebuild author on their mistake. When an
update hits my inbox I can go directly to the bug...

With an overlay: search sunrice.gentoo.org for the package (no, I don't
know category/name), sync that directory (no, I'm not syncing the whole 
sunrice tree), check it over, note some mistakes, compile it if I feel
OK with it, it fails, I fix it - and what then? Where do I discuss the
problems? How do I get my fixes to other users, considering the package
is devless and the b.g.o bug is out of date? If I open a b.g.o bug, will
it be read? 

This seems like *raising* the barrier to entry to me...

Ed

-- 
gentoo-dev@gentoo.org mailing list

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

[Stuart Herbert]

On 6/9/06, Edward Catmur <ed@catmur.co.uk> wrote:
> With an overlay: search sunrice.gentoo.org for the package

If you want people to debate seriously with you, stop calling this
project 'sunrice'.

If you can't discuss this topic respectfully with others on this list,
please stop using our lists.

Best regards,
Stu
-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

On Fri, 9 Jun 2006 11:24:34 +0100 "Stuart Herbert"
<stuart.herbert@gmail.com> wrote:
| On 6/9/06, Edward Catmur <ed@catmur.co.uk> wrote:
| > With an overlay: search sunrice.gentoo.org for the package
| 
| If you want people to debate seriously with you, stop calling this
| project 'sunrice'.

Why? It's a small amount of mild entertainment in what is otherwise a
highly depressing state of affairs. It doesn't in any way detract from
the other valid points he raised.

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


-- 
gentoo-dev@gentoo.org mailing list

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

[Jakub Moc]

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

Edward Catmur wrote:
> On Fri, 2006-06-09 at 10:28 +0200, Patrick Lauer wrote:
>> Instead of a simple cvs up; cd /usr/local/portage/category/package I
>> need to search for ALL bugs with $name in it, look which one it is,
>> curse bugzilla for falling asleep again, see which attachments are
>> relevant, download them, curse bugzilla for falling asleep again, copy
>> them to my overlay, read the bugcomments to see if any special renaming
>> or directory structure is needed ...
>>
>> Hmmm. I think an overlay does have some advantages there ...
> 
> Advantages? With bugzilla I: search for the bug, cc myself on it,
> download the relevant files, look over them, note a style error, try to
> merge it, fix a compilation bug, re-upload the fixed ebuild and patch to
> bugzilla with a comment to the ebuild author on their mistake. When an
> update hits my inbox I can go directly to the bug...

Hmmm, I mostly notice a different scenario:

- search for the bug, and file a dupe because you didn't find it :P
- bug gets marked as a dupe
- the guy who filed the dupe comments on how much bugzilla search sucks
- download one of obsolete broken ebuilds attached to the bug
- moan that it doesn't work
- download another ebuild
- moan that it doesn't work either
- someone points to comment #27 that says you need to edit lines XX and
YY for the ebuild to work
- do it, post yet another redundant "yay, that finally worked!" comment
- attach a "fixed" ebuild tarball
- you get scream upon to not attach tarballs
- you attach a plaintext ebuild now
- notice that its MIME type is application/octet-stream
- change the mime type
- look at the ebuild in the browser now that you can and notice bunch of
stupid typos you've done that ruin the whole fix (hello, Mr. Murphy)
- try to edit the attachment in bugzilla, which produces one huge
nonsense comment instead of actually editing the ebuild
- attach a new one
- oh noes, it's octet-stream again! argh!
- fix it...
- forgot to mark previous one as obsolete, do it now
- produce "sorry for the noise" comment
- someone notices that you've still left two typos there and attaches
yet another ebuild

By now, about 15 bugspams times the number of people CCed on the bug got
 sent, containing mostly useless crap.

> With an overlay: search sunrice.gentoo.org for the package (no, I don't
> know category/name), sync that directory (no, I'm not syncing the whole 
> sunrice tree), check it over, note some mistakes, compile it if I feel
> OK with it, it fails, I fix it - and what then? Where do I discuss the
> problems? How do I get my fixes to other users, considering the package
> is devless and the b.g.o bug is out of date? If I open a b.g.o bug, will
> it be read? 
> 
> This seems like *raising* the barrier to entry to me...

Yes, with an overlay you can prevent all the attachment screwups noted
above and once you are really satisfied that it works, you post a link
to bugzilla. You can fix your typos in VCS, even multiple times, without
bugspamming the hell out of people, and you still have the history to go
back if you screw up. Bugs with tens of attachments are essentially
useless for most of newcomers and suck for effective development as
well. A couple of examples:

http://bugs.gentoo.org/show_bug.cgi?id=24247
http://bugs.gentoo.org/show_bug.cgi?id=70161
http://bugs.gentoo.org/show_bug.cgi?id=122500


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Chris Gianelloni]

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

On Fri, 2006-06-09 at 12:33 +0200, Jakub Moc wrote:
> well. A couple of examples:
> 
> http://bugs.gentoo.org/show_bug.cgi?id=122500

And again, you use my project of an example.  Perhaps you should try
looking at something that actually supports your argument?

A subversion repository was built for this.  However, if you took the 3
seconds to *look* at the repository, you would see that it is actually
an overlay for *all* of the vmware stuff.  Then again, I guess it is
just easier to ignore the facts and use things as you wish in an attempt
to strengthen a weak argument.

Of course, this is also an example of how a repository with an actual
defined goal can bring on developers, since Mike is now a developer and
a part of the VMware team.  So again, I thank you for strengthening my
position, while attempting to support your own.  If you keep this up, I
won't even have to reply anymore.  ;]

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

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

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

[Peper]

> > well. A couple of examples:
> >
> > http://bugs.gentoo.org/show_bug.cgi?id=122500
>
> And again, you use my project of an example.  Perhaps you should try
> looking at something that actually supports your argument?

I think it's an example of how user-friendly is bugzilla...

-- 
Best Regards,
Piotr Jaroszynski
-- 
gentoo-dev@gentoo.org mailing list

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

[Jakub Moc]

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

Peper wrote:
>>> well. A couple of examples:
>>>
>>> http://bugs.gentoo.org/show_bug.cgi?id=122500
>> And again, you use my project of an example.  Perhaps you should try
>> looking at something that actually supports your argument?
> 
> I think it's an example of how user-friendly is bugzilla...

Yeah, exactly... I don't understand where did this idea of me using
someone else's own project against himself came from in the first place.
*confused*

I've merely posted a few examples illustrating that bugzilla and
attachments suck big time for new ebuilds' development. Or, why did you
switch vmware-server work to SVN if bugzilla is *the* place for all
this? Apparently it's not all that great, otherwise you wouldn't have
done that.

-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Daniel Ostrow]

On Fri, 2006-06-09 at 20:12 +0200, Jakub Moc wrote:
> Peper wrote:
> >>> well. A couple of examples:
> >>>
> >>> http://bugs.gentoo.org/show_bug.cgi?id=122500
> >> And again, you use my project of an example.  Perhaps you should try
> >> looking at something that actually supports your argument?
> > 
> > I think it's an example of how user-friendly is bugzilla...
> 
> Yeah, exactly... I don't understand where did this idea of me using
> someone else's own project against himself came from in the first place.
> *confused*
> 
> I've merely posted a few examples illustrating that bugzilla and
> attachments suck big time for new ebuilds' development. Or, why did you
> switch vmware-server work to SVN if bugzilla is *the* place for all
> this? Apparently it's not all that great, otherwise you wouldn't have
> done that.
> 

See you are just missing the point. He switched it to a VMware specific
SVN repo maintained by people who know VMware inside and out, otherwise
known as the VMware team. There is a HUGE difference between an overlay
with ${random_ebuilds} maintained by a small group who cannot possibly
know all of the ins and outs of every package and their impact on every
architecture and a targeted overlay for a very specific purpose which
only contains ebuilds for which the maintainers have 100% complete
understanding. Targeted overlays maintained by people who understand the
packages in question in totality == good, Catchall overlays maintained
by a few people who cannot possibly (and this isn't meant as a dig
against anyone it's just a fact) understand the implications and
interactions of *all* the packages in said overlay == BAD!

--Dan

-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

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

On Fri, 2006-06-09 at 20:12 +0200, Jakub Moc wrote:
> Peper wrote:
> >>> well. A couple of examples:
> >>>
> >>> http://bugs.gentoo.org/show_bug.cgi?id=122500
> >> And again, you use my project of an example.  Perhaps you should try
> >> looking at something that actually supports your argument?
> > 
> > I think it's an example of how user-friendly is bugzilla...
> 
> Yeah, exactly... I don't understand where did this idea of me using
> someone else's own project against himself came from in the first place.
> *confused*
> 
> I've merely posted a few examples illustrating that bugzilla and
> attachments suck big time for new ebuilds' development. Or, why did you
> switch vmware-server work to SVN if bugzilla is *the* place for all
> this? Apparently it's not all that great, otherwise you wouldn't have
> done that.

#1.  *I* (as the vmware team) didn't do it, the (then) user who posted
the package did
#2.  We also built it up as the entire vmware overlay... it had little
to do with any limitations in bugzilla, and more to do with my
already-established desires to make maintaining vmware-* easier

This really is a case of you not knowing what the actual facts were in
regards to the situation, yet pointing it out as some kind of
corroborating evidence for your argument.  This is definitely not the
case.

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

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

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

[Chris Gianelloni]

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

On Fri, 2006-06-09 at 11:01 +0100, Edward Catmur wrote:
> > Hmmm. I think an overlay does have some advantages there ...
> 
> Advantages? With bugzilla I: search for the bug, cc myself on it,
> download the relevant files, look over them, note a style error, try to
> merge it, fix a compilation bug, re-upload the fixed ebuild and patch to
> bugzilla with a comment to the ebuild author on their mistake. When an
> update hits my inbox I can go directly to the bug...
> 
> With an overlay: search sunrice.gentoo.org for the package (no, I don't
> know category/name), sync that directory (no, I'm not syncing the whole 
> sunrice tree), check it over, note some mistakes, compile it if I feel
> OK with it, it fails, I fix it - and what then? Where do I discuss the
> problems? How do I get my fixes to other users, considering the package
> is devless and the b.g.o bug is out of date? If I open a b.g.o bug, will
> it be read? 
> 
> This seems like *raising* the barrier to entry to me...

Thank you.  This explains my point about no longer having a definitive
place to look for things much better than I did, and from a user
point-of-view no less.

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

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

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

[Donnie Berkholz]

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

Chris Gianelloni wrote:
>> With an overlay: search sunrice.gentoo.org for the package (no, I don't
>> know category/name), sync that directory (no, I'm not syncing the whole 
>> sunrice tree), check it over, note some mistakes, compile it if I feel
>> OK with it, it fails, I fix it - and what then? Where do I discuss the
>> problems? How do I get my fixes to other users, considering the package
>> is devless and the b.g.o bug is out of date? If I open a b.g.o bug, will
>> it be read? 

If the overlay were using a decent distributed SCM, you would get your
fixes to users by posting your repository and requesting that it be
merged in. I was under the impression that all ebuilds in this overlay
would already have an associated bug for discussion.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

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

[Chris Gianelloni]

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

On Fri, 2006-06-09 at 10:05 -0700, Donnie Berkholz wrote:
> Chris Gianelloni wrote:
> >> With an overlay: search sunrice.gentoo.org for the package (no, I don't
> >> know category/name), sync that directory (no, I'm not syncing the whole 
> >> sunrice tree), check it over, note some mistakes, compile it if I feel
> >> OK with it, it fails, I fix it - and what then? Where do I discuss the
> >> problems? How do I get my fixes to other users, considering the package
> >> is devless and the b.g.o bug is out of date? If I open a b.g.o bug, will
> >> it be read? 
> 
> If the overlay were using a decent distributed SCM, you would get your
> fixes to users by posting your repository and requesting that it be
> merged in. I was under the impression that all ebuilds in this overlay
> would already have an associated bug for discussion.

Initially, yes.  What happens once the user gets complete access to the
repository, though?  Are we going to be keeping people from adding
packages without bugs?

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

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

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

[Donnie Berkholz]

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

Chris Gianelloni wrote:
> Initially, yes.  What happens once the user gets complete access to the
> repository, though?  Are we going to be keeping people from adding
> packages without bugs?

Absolutely. This is for maintainer-wanted stuff, so it should be
documented in Bugzilla and assigned to maintainer-wanted with a special
keyword to indicate it's in the overlay. The question is how to come up
with some QA tool to enforce this.

I don't find this overlay objectionable, assuming it's only used for
maintainer-wanted packages.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

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

[Chris Gianelloni]

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

On Fri, 2006-06-09 at 10:28 +0200, Patrick Lauer wrote:
> On Thu, 2006-06-08 at 20:06 -0400, Chris Gianelloni wrote:
> > > 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.
> > 
> > Umm... so now I need to go and instead of clicking a nice link in
> > bugzilla, trawl through the subversion repository and find what I'm
> > looking for?  How exactly is downloading things via http any different
> > than downloading them from bugzilla, which is also http?
> just my point of view - 
> 
> bugzilla sucks. Ever had to download 10 attachments for one ebuild?
> It is a good tool for discussion, but I would prefer a simple tool (like
> layman) that can automatically update things. You obviously don't like
> overlays, but that shouldn't be a reason to stop us from using it. 

Well, I thank you for your vast experience as an ebuild developer in
this matter.

You do realize that this isn't one of those things where you can say
that if you don't like it you don't have to use it, right?

This *will* affect *every* ebuild developer.

This means it *CANNOT* be left up to a small group of developers to
decide without any discussion on the matter.

> > > Or, if you want some history like sources.g.o, you can do so as well here:
> > > http://overlays.gentoo.org/proj/sunrise/browser/
> > 
> > Excellent.  So we're moving the history from being in a single location
> > (the bug) to being in multiple locations.  That will definitely improve
> > the development process.  
> Yes, now it is easier to check out the ebuilds. More users ==> better
> testing.

Except that now the developer has to do much more work to get the same
information, making it even less likely that he'll bother to pick up one
of these maintainer-wanted bugs.  You also completely gloss over the
ability of a single rogue user to now compromise countless users with a
single commit.  Please come back once you've firmly grounded yourself in
the reality that we're a pretty popular distribution, and that makes
this project a prime target for malicious abuse.  Perhaps if you were
responsible for some ebuilds, you've be more cognizant of the
implications that a bad commit can cause our users.

> >   No offense, but everything I have seen looks
> > as if it will add even *more* overhead to actually getting packages into
> > the tree.  The only thing this seems to provide is a half-baked
> > repository for the users to get marginally-tested ebuilds for software
> > that wasn't interesting enough for inclusion in the tree.
> That differs from the 20 or so overlays maintained by users how?

Let's see.  They aren't on Gentoo infrastructure, which means they don't
give off any immediate assumption of being "official" or "supported" in
any way.  Hell, go back and look at Peter's response about how he would
use an overlay such as this only *because* it is on Gentoo
infrastructure.

So what exactly was your counter-point again?

> Honestly I'd prefer an overlay where I can marginally trust the content
> over a "foreign" repository maintained by people I don't know.

Having an overlay such as this will tarnish Gentoo's reputation.  We
should not be providing *anything* that is only half-supported or
half-tested.  Anything less than being sully supported via the security
team and QA is a failure on the part of Gentoo.  We have enough *crap*
in the *tree* that is unsupported, which makes us look bad, yet you want
to insist on supporting a project that affects all of the ebuild
developers, which you have not mentioned is a group which you are not a
part of, so can gladly speak of increasing their workload with no
consequences to yourself, and provides an avenue for low-quality or
possibly malicious ebuilds to be distributed to our users, all under a
Gentoo banner?

I seriously question your motives towards the Gentoo project.

> Hmmm ... bugzilla.
> Instead of a simple cvs up; cd /usr/local/portage/category/package I
> need to search for ALL bugs with $name in it, look which one it is,
> curse bugzilla for falling asleep again, see which attachments are
> relevant, download them, curse bugzilla for falling asleep again, copy
> them to my overlay, read the bugcomments to see if any special renaming
> or directory structure is needed ...
> 
> Hmmm. I think an overlay does have some advantages there ...

Sure.  Until I sneak in some obfuscated code as a "fix" to a "bug" and
it gets executed on your machine because the actual *developers* that
are used to maintaining this stuff and know what to look for aren't a
part of the process.

Making something easier does not make it better.  I'm sorry, but you've
yet to convince me on how your laziness is supposed to be an improvement
for the development process of Gentoo.

> > Again, read what I wrote.  I said that the developer would see "sunrise"
> > in the PORTDIR_OVERLAY of the user's emerge --info, which you reiterated
> > without considering.  This is a login bug.  At no point did they make
> > mention of having installed pam_skey from this overlay.  This means that
> > I, as the developer getting this bug, am now responsible for looking at
> > *every package* in the sunrise overlay to determine if *any* of them
> > could *possibly* be affecting this package or causing this bug, then
> > asking the user if they have any of them installed.
> This differs from a manually patched ebuild in /usr/portage by virtue of showing you that an overlay is used ...

Wow.  Another one of those "I can't answer your issue, so I'll just try
to divert your attention somewhere else" answers.  Thanks for absolutely
nothing but contributing noise.

> > Wouldn't this process be *infinitely* easier if instead of "sunrise"
> > there was a "pam" overlay with *only* the pam stuff?
> Ooooh, cool. Now I need about 75 overlays to get things done, and of course there will be no bad interaction between them ;-)

As opposed to the free for all that is this overlay?

> Having one overlay with a focus on not-in-portage ebuilds should not
> cause the scenario you described and will most likely cause less weird
> bugs because of intra-overlay dependencies.

What evidence do you have of this?

> </opinion>

Oh, right.  None.

> > That is *exactly* what we get with the other overlays like php and
> > vmware.  I *know* that if I'm looking at a glibc bug and the user has
> > "php" as an overlay, that it isn't going to be a concern.
> ... and if we control the overlay we can exclude things like system
> packages easily.

You really do a good job of making attempts to skirt the issues.  Do me
a favor, if you're just going to use vague references and try to avoid
answering the issues at hand, don't bother wasting everyone's time by
replying.  You're more than welcome to provide some *useful* insight,
but simply stating that something won't be an issue doesn't make it
true.

> Could be part of the policy to not touch existing ebuilds.

Actually, it already is, according to jokey.

> > This is a prime example of totally glossing over any discussion to make
> > it sound promising for you. 
> If bugzilla wasn't so sucky people wouldn't try to use other methods of
> communication ;-)

Except this isn't another form of communication, nor is it being
presented as one.  Do you even bother to notice what you're writing?
How exactly is a bunch of ebuilds in an overlay a "method of
communication"?

> And again, one svn repo vs. 113 hard-to-find bugs ...

Amazing how you pull such numbers out of thin air.  Which 113 bugs are
you talking about, exactly?

> >  Even better, if I am the proxy
> > maintainer for a particular set of ebuilds for one or more
> > user/maintainers, why do I need it in your big, bloated, and completely
> > inappropriately-named "sunshine" overlay versus a developer overlay of
> > my own?  
> You don't. Please use your developer overlay. Please don't try to take
> away our more open overlay.

Unfortunately, your request for my dropping of this issue will not be
honoured.  This overlay is a bad idea, that is being poorly executed,
and is being *forced* on the developer community at large with
absolutely no for-warning or planning.  It really is a shame that we
don't have any policies that allow for action to be taken against people
who either knowingly, or through actions of ignorance, cause massive
damage to Gentoo such as this.

> > After all, I am the *only* proxy maintainer.  Why should there
> > be the added *insecurity* of allowing any number of people that *I*
> > might not trust complete access to the small number of packages where I
> > am the proxy?
> It's your choice. Either you get mailbombed with each minor version update or you trust them to not screw up with the sunrise overlay.

Isn't that what the process of becoming a developer is supposed to
build?  Also, just because I trust one person, doesn't mean I trust
someone that you trust.  Trust is not implicit, it is earned.  Some
random user having complete access to an area where only people that *I*
trust should really have access is not instilling faith in me of this
project.  However, instead of answering these concerns, you simply brush
them aside as a non-issue, though I am not the only developer that has
spoken out on this *exact* same issue.

> And the users could just create their own overlay, get it added to
> layman and we'd have the same without supervision. From where I'm
> standing it's better to have the possibility to nuke a bad ebuild in the
> overlay instead of asking some random user to change this in that
> overlay because of $problem.

Why exactly are we supporting these overlays via layman anyway?  That
implies a level of trust and support that you admit we do not have.  I
guess I should touch on that subject next, but that doesn't belong in
this discussion.

> Maybe we even find some motivated new ebuild monkeys that have the
> motivation to become devs ... one can always hope :-)

...and maybe we get owned and people quit using Gentoo because a few
developers decided to go against the advice of other developers and
allowed for an easy-access, easily-exploitable way for some malicious
user to own countless Gentoo boxes, and nobody did anything to stop it.

Well, I am going to do everything within my power to stop it.  I will
not back down until this project is dead.  It really is that simple.

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

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

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

[Andrew Gaffney]

Chris Gianelloni wrote:

<snipped lots and lots of valid points>

> Well, I am going to do everything within my power to stop it.  I will
> not back down until this project is dead.  It really is that simple.

*golf-clap*

-- 
Andrew Gaffney                            http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer                                   Installer Project

-- 
gentoo-dev@gentoo.org mailing list

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

[Patrick Lauer]

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

On Fri, 2006-06-09 at 12:20 -0400, Chris Gianelloni wrote:
> > bugzilla sucks. Ever had to download 10 attachments for one ebuild?
> > It is a good tool for discussion, but I would prefer a simple tool (like
> > layman) that can automatically update things. You obviously don't like
> > overlays, but that shouldn't be a reason to stop us from using it. 
> 
> Well, I thank you for your vast experience as an ebuild developer in
> this matter.

My pleasure. I'd rather see myself as poweruser in this regard since I
try not to break too many ebuilds ...

> You do realize that this isn't one of those things where you can say
> that if you don't like it you don't have to use it, right?
>
> This *will* affect *every* ebuild developer.
Maybe you don't realize that taking ebuilds for packages that are _not in portage_ and providing them in a nice bundle does not affect every developer?
Noone wants to push a new cvs-snapshot of glibc. That so not the point
here.

But having a controlled managed overlay with ebuilds that are now spread
all across bugzilla ... that would be a good service to our users.

> This means it *CANNOT* be left up to a small group of developers to
> decide without any discussion on the matter.
So now we're a democracy where everything needs to be voted upon?
*sigh*
Let's leave that debate for another day ...

> > Yes, now it is easier to check out the ebuilds. More users ==> better
> > testing.
> 
> Except that now the developer has to do much more work to get the same
> information, making it even less likely that he'll bother to pick up one
> of these maintainer-wanted bugs.  
s/the developer/I/
there are some devs that would prefer this overlay environment.
Please don't push your personal preferences as The Right Way (tm)

> You also completely gloss over the
> ability of a single rogue user to now compromise countless users with a
> single commit.
And an ebuild on bugzilla has more security?
We're just making it easier to use these ebuilds. Also I expect the
maintainers to keep a reasonable quality standard.  
>   Please come back once you've firmly grounded yourself in
> the reality that we're a pretty popular distribution, and that makes
> this project a prime target for malicious abuse.  Perhaps if you were
> responsible for some ebuilds, you've be more cognizant of the
> implications that a bad commit can cause our users.
I am not responsible for ebuilds because I don't trust myself enough :-)
That doesn't stop me from giving out access to my server to anyone who
has a good reason ... like the Gentoo/HURD repository or the Java
overlay. 

> > That differs from the 20 or so overlays maintained by users how?
> 
> Let's see.  They aren't on Gentoo infrastructure, which means they don't
> give off any immediate assumption of being "official" or "supported" in
> any way.  Hell, go back and look at Peter's response about how he would
> use an overlay such as this only *because* it is on Gentoo
> infrastructure.
> 
> So what exactly was your counter-point again?
We have control over sunrise. And hey, if it sucks kill the project with silver bullets, a stake to the heart and two pounds of garlic.
Just don't kill an idea before it is even tested ...

> Having an overlay such as this will tarnish Gentoo's reputation.
No :-)
What reputation are we talking about? The distro that lags in updates
behind others?
Where you see a problem I see potential: More well-tested ebuilds,
recruiting potential developers ... if you don't want that you're an
elitist bastard. ;-)

>   We
> should not be providing *anything* that is only half-supported or
> half-tested.  Anything less than being sully supported via the security
> team and QA is a failure on the part of Gentoo.  We have enough *crap*
> in the *tree* that is unsupported, which makes us look bad, yet you want
> to insist on supporting a project that affects all of the ebuild
> developers, which you have not mentioned is a group which you are not a
> part of, so can gladly speak of increasing their workload with no
> consequences to yourself, and provides an avenue for low-quality or
> possibly malicious ebuilds to be distributed to our users, all under a
> Gentoo banner?
No :-)
1) It doesn't increase your workload - these packages are things that
are _not_ in the main tree.
No overlap --> no stupid bugs with overwritten ebuilds etc.
2) low-quality? I might mention that I'm hosting some overlays that have
non-gentoo contributors (*gasp!*)
Why are they hosted on my server? Because the contributors are not (yet)
gentoo devs, but provide good to excellent input to the projects. So now
you tell me that I'm doing wrong in helping Gentoo development? These
people can't contribute to other gentoo-hosted projects, so it is easier
to move the repositories to a more liberal server. 

That tells me that Gentoo development is fundamentally buggy when we
complain about a lack of manpower and then say "yeah, but not _that_
kind of manpower" when users try to help.

<cynic>
And people wonder why usually things get done secretly and then
presented as a finished product - no wonder, it seems to be the only way
to get _anything_ done.
</cynic>

> I seriously question your motives towards the Gentoo project.
Good. Question them. I'm still doing what I can to help ... doing such silly things as finding new servers for Infra and writing articles for the GWN.
If that isn't good enough ... well ... who cares. You invest as much as
I do in your own server for Gentoo usage and I'll not question _your_
motives.

> > Hmmm ... bugzilla.
> > Instead of a simple cvs up; cd /usr/local/portage/category/package I
> > need to search for ALL bugs with $name in it, look which one it is,
> > curse bugzilla for falling asleep again, see which attachments are
> > relevant, download them, curse bugzilla for falling asleep again, copy
> > them to my overlay, read the bugcomments to see if any special renaming
> > or directory structure is needed ...
> > 
> > Hmmm. I think an overlay does have some advantages there ...
> 
> Sure.  Until I sneak in some obfuscated code as a "fix" to a "bug" and
> it gets executed on your machine because the actual *developers* that
> are used to maintaining this stuff and know what to look for aren't a
> part of the process.
It's all about trust. Those people that suck ebuilds out of bugzilla now
will use the overlay. Same potential for damage in a slightly different
package ...

> Making something easier does not make it better.  I'm sorry, but you've
> yet to convince me on how your laziness is supposed to be an improvement
> for the development process of Gentoo.
Less work --> more time to do interesting things.

And just because you don't like overlays doesn't mean we should remove
them. Heck, I really really dislike Gnome, but I'm not going to petition
for removal just because I don't like it.

Remember that "Gentoo is all about choice" discussion that pops up every
now and then?
If a motivated group of devs wants to try an overlay experiment you
should let them try. Worst case it's a failure and gets punted after two
months.


> Wow.  Another one of those "I can't answer your issue, so I'll just try
> to divert your attention somewhere else" answers.  Thanks for absolutely
> nothing but contributing noise.
You know, I've met you at FOSDEM and I know that you don't mean this as an insult, but it is very easy to misread it as that.
Might I suggest that you don't formulate responses in a way that can
easily be read as a personal attack? 

> > > Wouldn't this process be *infinitely* easier if instead of "sunrise"
> > > there was a "pam" overlay with *only* the pam stuff?
> > Ooooh, cool. Now I need about 75 overlays to get things done, and of course there will be no bad interaction between them ;-)
> As opposed to the free for all that is this overlay?
It's easier to manage one big overlay - at least that seems to be the motivation for doing it.
And if we're all mistaken we at least learn a valuable lesson.

> > Having one overlay with a focus on not-in-portage ebuilds should not
> > cause the scenario you described and will most likely cause less weird
> > bugs because of intra-overlay dependencies.
> What evidence do you have of this?
> > </opinion>
It helps if you keep things in context 

> Oh, right.  None.
That's why I wrapped it in <opinion></opinion> tags.
If we knew the answers we wouldn't need to discuss things ...


> > ... and if we control the overlay we can exclude things like system
> > packages easily.
> 
> You really do a good job of making attempts to skirt the issues.  Do me
> a favor, if you're just going to use vague references and try to avoid
> answering the issues at hand, don't bother wasting everyone's time by
> replying.  You're more than welcome to provide some *useful* insight,
> but simply stating that something won't be an issue doesn't make it
> true.
And you are trying your best to make me look like an ass. Please stop
doing that, it makes discussion really hard. Keep to technical issues.

The issue is: This overlay will _not_ contain BreakMyGentoo-style
ebuilds of new versions of things in portage. There won't be a glibc cvs
snapshot. Just ebuilds that for now live in bugzilla and are hard to
find. We wish to provide them in an easy-to-use package to our users.

You know ... users. Those people that are not devs. Some of us try to
give them the best experience we can, and if there is something like an
overlay that even the more n00bish users can use we should try to
provide it. 

> > Could be part of the policy to not touch existing ebuilds.
> Actually, it already is, according to jokey.
Even better!

> > And again, one svn repo vs. 113 hard-to-find bugs ...
> Amazing how you pull such numbers out of thin air. 
It's a special talent. 47 <-- just for you
>  Which 113 bugs are you talking about, exactly?
Try to find the relevant files in the three bugs jakub posted.
Now try that for multiple packages ... Most users won't need to harvest
113 bugs, but I'd prefer a "svn up". It's just so much saner and less
work that it is hard for me to see how bugzilla even makes sense.
> > >  Even better, if I am the proxy
> > > maintainer for a particular set of ebuilds for one or more
> > > user/maintainers, why do I need it in your big, bloated, and completely
> > > inappropriately-named "sunshine" overlay versus a developer overlay of
> > > my own?  
> > You don't. Please use your developer overlay. Please don't try to take
> > away our more open overlay.
> 
> Unfortunately, your request for my dropping of this issue will not be
> honoured.
That is weird, but you are entitled to your opinion.

>   This overlay is a bad idea, that is being poorly executed,
> and is being *forced* on the developer community at large with
> absolutely no for-warning or planning. 
That is your opinion. I think it's a good idea with a best-effort
execution.
And noone is forced to do anything - all that data is in bugzilla
already.

>  It really is a shame that we
> don't have any policies that allow for action to be taken against people
> who either knowingly, or through actions of ignorance, cause massive
> damage to Gentoo such as this.
Define damage - I see your efforts to keep a motivated group of devs
from implementing a new and untested idea as damaging. But I can accept
that - you have a different point of view. Would be boring if we all
agreed.

> > > After all, I am the *only* proxy maintainer.  Why should there
> > > be the added *insecurity* of allowing any number of people that *I*
> > > might not trust complete access to the small number of packages where I
> > > am the proxy?
> > It's your choice. Either you get mailbombed with each minor version update or you trust them to not screw up with the sunrise overlay.
> 
> Isn't that what the process of becoming a developer is supposed to
> build?
That process that many people consider too complicated and
time-consuming?
Not everyone wants to spend 20h a week on Gentoo. Some people just want
to maintain their personal app for Gentoo. In some cases we already have
proxy-maintainers, so I don't see why we should not try to find more
motivated smart users to help.

>   Also, just because I trust one person, doesn't mean I trust
> someone that you trust.  Trust is not implicit, it is earned.
That's why most Gentoo devs can have an account on my server. Except
those that have told me directly that they don't like me :-)

>   Some
> random user having complete access to an area where only people that *I*
> trust should really have access is not instilling faith in me of this
> project.  However, instead of answering these concerns, you simply brush
> them aside as a non-issue, though I am not the only developer that has
> spoken out on this *exact* same issue.
The difference between a random user and a dev often is not much more
than an @gentoo.org email adress. I don't consider all users
untrustworthy - if they show that they wish to help we should not
sabotage them. Maybe you don't remember the time when you were "just" a
user? 

> Why exactly are we supporting these overlays via layman anyway?  That
> implies a level of trust and support that you admit we do not have.  I
> guess I should touch on that subject next, but that doesn't belong in
> this discussion.
We support them because a dev or a group of devs decided to do it.
As long as Gentoo doesn't have a BDFL this will happen ... and if you
don't like it discuss it with the relevant person(s). Maybe they are
willing to change things?

> > Maybe we even find some motivated new ebuild monkeys that have the
> > motivation to become devs ... one can always hope :-)
> 
> ...and maybe we get owned and people quit using Gentoo because a few
> developers decided to go against the advice of other developers and
> allowed for an easy-access, easily-exploitable way for some malicious
> user to own countless Gentoo boxes, and nobody did anything to stop it.
If someone wanted to exploit boxen he'd use a much simpler attack
vector ... our rsync mirrors are wide open. No need to secure the little
window over there when the front door is open ...

> Well, I am going to do everything within my power to stop it.  I will
> not back down until this project is dead.  It really is that simple.
Ok, that seems counterproductive to me, but if you are not willing to compromise it will be hard to have any communication at all.

Instead of trying to kill this idea you should try to get it modified
into something we all can agree on.


take care,
Patrick
-- 
Stand still, and let the rest of the universe move

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

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

[Chris Gianelloni]

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

On Fri, 2006-06-09 at 19:41 +0200, Patrick Lauer wrote:
> > This *will* affect *every* ebuild developer.
> Maybe you don't realize that taking ebuilds for packages that are _not in portage_ and providing them in a nice bundle does not affect every developer?

I'm sorry for the language, but I call bullshit.  It is painfully
obvious by your response that you've never had a library that is an
optional dependency (and one we don't --without durng configure, since
it isn't in the tree) cause a problem in one of your packages.  Allowing
libraries means it can cause breakage.  Period.

> Noone wants to push a new cvs-snapshot of glibc. That so not the point
> here.

Nobody ever said that you have to push a new glibc to cause mass
breakage.

> But having a controlled managed overlay with ebuilds that are now spread
> all across bugzilla ... that would be a good service to our users.

Since when was overlays.gentoo.org supposed to even be a service to our
users?  As I understand it, the goal was to ease development, not to
provide an easy method for half-working ebuilds to make it to our user's
machines.

> > This means it *CANNOT* be left up to a small group of developers to
> > decide without any discussion on the matter.
> So now we're a democracy where everything needs to be voted upon?

Anything this abhorrently stupid doesn't need a vote.  It should be cast
out on its complete lack of merit, alone.  Also, at no point did I ever
ask for a vote.  Don't put words in my mouth and I'll try to pretend
like I care what you say, OK?

> *sigh*
> Let's leave that debate for another day ...

You brought it up, not I.  Feel free to debate it with yourself until
you're blue in the face.

> > > Yes, now it is easier to check out the ebuilds. More users ==> better
> > > testing.
> > 
> > Except that now the developer has to do much more work to get the same
> > information, making it even less likely that he'll bother to pick up one
> > of these maintainer-wanted bugs.  
> s/the developer/I/

You're right... I had that wrong.

s/the developer/the developers/

After all, there have been quite a number of people agreeing with me.

> there are some devs that would prefer this overlay environment.
> Please don't push your personal preferences as The Right Way (tm)

Ehh.  Were you an ebuild developer, your opinion might actually count
for something when it comes to an ebuild development discussion.  By the
way, where's the GWN this week?

> > You also completely gloss over the
> > ability of a single rogue user to now compromise countless users with a
> > single commit.
> And an ebuild on bugzilla has more security?

Nope.  However, I'm also not proposing that ebuilds from bugzilla
automatically get pulled in over some magical overlay that is supposed
to fix all of the problems Gentoo's ever had with unmaintained packages.

> We're just making it easier to use these ebuilds. Also I expect the
> maintainers to keep a reasonable quality standard.

I'm glad your faith in them is so high.  My faith in *any* group this
small having the ability to watch over a large number of outside
contributors simply isn't there.

> >   Please come back once you've firmly grounded yourself in
> > the reality that we're a pretty popular distribution, and that makes
> > this project a prime target for malicious abuse.  Perhaps if you were
> > responsible for some ebuilds, you've be more cognizant of the
> > implications that a bad commit can cause our users.
> I am not responsible for ebuilds because I don't trust myself enough :-)

That's great.  I don't trust you enough, either.  ;]

> That doesn't stop me from giving out access to my server to anyone who
> has a good reason ... like the Gentoo/HURD repository or the Java
> overlay.

Well, we thank you for your immense self-sacrifice.  What this has to do
with the topic at hand, I have no idea.

> > > That differs from the 20 or so overlays maintained by users how?
> > 
> > Let's see.  They aren't on Gentoo infrastructure, which means they don't
> > give off any immediate assumption of being "official" or "supported" in
> > any way.  Hell, go back and look at Peter's response about how he would
> > use an overlay such as this only *because* it is on Gentoo
> > infrastructure.
> > 
> > So what exactly was your counter-point again?
> We have control over sunrise. And hey, if it sucks kill the project with silver bullets, a stake to the heart and two pounds of garlic.

I'm locked and loaded.

> Just don't kill an idea before it is even tested ...

Why not?  What reason is there to stop me from aborting this brain-dead
monstrosity before it claims a single user casualty, let alone our
reputation?  I would have thought that your involvement in "PR" would
have you thinking better.  A reputation is something that takes years to
establish, and seconds to demolish.  You, of all people, should know
that.

> > Having an overlay such as this will tarnish Gentoo's reputation.
> No :-)
> What reputation are we talking about? The distro that lags in updates
> behind others?

Yes, we are *so* lagged behind everyone else.  Where do you come up with
these "facts" anyway?  I'd like to visit this mythical land.

> Where you see a problem I see potential: More well-tested ebuilds,
> recruiting potential developers ... if you don't want that you're an
> elitist bastard. ;-)

Aww, how sweet.  We've started the name calling.

I'm sorry, but having a general dumping ground for all of the crap that
nobody found useful enough to actually include into Gentoo doesn't sound
like the paradise that you're making it out to be.  Luckily, I'm finding
that I'm not alone in this, and that quite a few developers are backing
me on this one.  We're not blind to the problems with this project in
its implementation, management, and intended goals.  Perhaps you should
open your eyes and seriously look at what you're pushing as a solution?

> >   We
> > should not be providing *anything* that is only half-supported or
> > half-tested.  Anything less than being sully supported via the security
> > team and QA is a failure on the part of Gentoo.  We have enough *crap*
> > in the *tree* that is unsupported, which makes us look bad, yet you want
> > to insist on supporting a project that affects all of the ebuild
> > developers, which you have not mentioned is a group which you are not a
> > part of, so can gladly speak of increasing their workload with no
> > consequences to yourself, and provides an avenue for low-quality or
> > possibly malicious ebuilds to be distributed to our users, all under a
> > Gentoo banner?
> No :-)
> 1) It doesn't increase your workload - these packages are things that
> are _not_ in the main tree.

I'm sorry, so your answer to this point is to just say that it is wrong
with absolutely no data to back it up.  Sounds about par for the course
from this project's proponents.  I've shown many examples where this
*could* and *would* adversely affect developer workload for developers
in the main tree.  You are unable to refute it, so you simply state it
isn't true with absolutely no way to substantiate your claims.

> No overlap --> no stupid bugs with overwritten ebuilds etc.

Hahahahaha!

Misdirection at its finest.  So tell me, where do I learn this valuable
skill of completely avoiding the truth and pretending to be blind to
facts.  It sure must come in handy.

> 2) low-quality? I might mention that I'm hosting some overlays that have
> non-gentoo contributors (*gasp!*)

Sure.  Overlays that are run by Gentoo developers with a specific
project in mind, where the project is also the maintainers of the
similar packages in the tree, are intimately familiar with the packages,
and are also responsible for all the bugs regarding them.  Did you have
a point, other than to help reiterate what I have said over and over
again?  You're starting to help my case as much as Jakub.

> Why are they hosted on my server? Because the contributors are not (yet)
> gentoo devs, but provide good to excellent input to the projects. So now
> you tell me that I'm doing wrong in helping Gentoo development? These
> people can't contribute to other gentoo-hosted projects, so it is easier
> to move the repositories to a more liberal server.

No.  They're on your server because we had no facility for them to be
placed on our infrastructure.  They could all easily be moved now and
would be well within the parameters for the overlays project.  However,
project sunshine flies directly in the face of those parameters, and
should be killed before it is allowed to harm Gentoo.

> That tells me that Gentoo development is fundamentally buggy when we
> complain about a lack of manpower and then say "yeah, but not _that_
> kind of manpower" when users try to help.

Except nobody says "Hey, I'd like it if users would start adding more
stuff to an overlay that isn't maintained by any Gentoo developers so I
can get more bugs that don't have anything to do with the official
Gentoo repository.  That would be swell."

Asking for help where help is actually needed is one thing.  Creating a
project to dump all of the useless shit and try to pass it off as
"helping" development is another.

> <cynic>
> And people wonder why usually things get done secretly and then
> presented as a finished product - no wonder, it seems to be the only way
> to get _anything_ done.
> </cynic>

Perhaps because stupid ideas such as this should never see the light of
day and would be shot down by anyone sensible enough to look at it on
its actual merit versus some hair-brained concept of how important they
are and how much this will "help" development?

> > I seriously question your motives towards the Gentoo project.
> Good. Question them. I'm still doing what I can to help ... doing such silly things as finding new servers for Infra and writing articles for the GWN.

Really?  Which servers?  Which articles?

> If that isn't good enough ... well ... who cares. You invest as much as
> I do in your own server for Gentoo usage and I'll not question _your_
> motives.

Like the hardware I've donated on multiple occasions?  Or the hours and
hours I spend working on Gentoo's actual products?  How about the hours
spent running the Gentoo Store, that actually brings in money for
Gentoo?

Spending a few dollars doesn't make you anything more than a monetary
contributor.  It doesn't buy you any respect.  It doesn't buy you
anything.

> Remember that "Gentoo is all about choice" discussion that pops up every
> now and then?

Yeah, I remember it.  I also remember that only idiots continue to tout
that party line as some kind of backing for every stupid and
hair-brained idea that should never see the light of day.  Are you
really trying to use that as an argument for why something that can be
shown to be a bad idea should be done?

How about instead actually answering the issues that have been
presented?

> If a motivated group of devs wants to try an overlay experiment you
> should let them try. Worst case it's a failure and gets punted after two
> months.

No.  The worst case scenario is some gets some malicious code in the
overlay and countless Gentoo boxes around the world get owned, Gentoo
catches the brunt of the backlash, and the distribution starts losing
users left and right and ends up dying out simply because a few selfish
developers couldn't be bothered to actually take into account what other
developers are telling them and decided to go forward with a stupid
idea.  Of course, I'm probably an optimist and much worse could probably
happen.

> > Wow.  Another one of those "I can't answer your issue, so I'll just try
> > to divert your attention somewhere else" answers.  Thanks for absolutely
> > nothing but contributing noise.
> You know, I've met you at FOSDEM and I know that you don't mean this as an insult, but it is very easy to misread it as that.
> Might I suggest that you don't formulate responses in a way that can
> easily be read as a personal attack?

Might I suggest you actually answer a damn question instead of using
redirection and vague promises as some sort of quasi-argument?

> > > > Wouldn't this process be *infinitely* easier if instead of "sunrise"
> > > > there was a "pam" overlay with *only* the pam stuff?
> > > Ooooh, cool. Now I need about 75 overlays to get things done, and of course there will be no bad interaction between them ;-)
> > As opposed to the free for all that is this overlay?
> It's easier to manage one big overlay - at least that seems to be the motivation for doing it.

How exactly is it easier to manage a large number of ebuilds versus a
small number?

> And if we're all mistaken we at least learn a valuable lesson.

Yes, that a small group of people shouldn't be allowed to make decisions
for the whole and not take into account any of the cons in their ideas,
instead plodding forwards as if there were no objections to their ideas.

> > > ... and if we control the overlay we can exclude things like system
> > > packages easily.
> > 
> > You really do a good job of making attempts to skirt the issues.  Do me
> > a favor, if you're just going to use vague references and try to avoid
> > answering the issues at hand, don't bother wasting everyone's time by
> > replying.  You're more than welcome to provide some *useful* insight,
> > but simply stating that something won't be an issue doesn't make it
> > true.
> And you are trying your best to make me look like an ass. Please stop
> doing that, it makes discussion really hard. Keep to technical issues.

Quit averting the issues when they are brought up.

> The issue is: This overlay will _not_ contain BreakMyGentoo-style
> ebuilds of new versions of things in portage. There won't be a glibc cvs
> snapshot. Just ebuilds that for now live in bugzilla and are hard to
> find. We wish to provide them in an easy-to-use package to our users.

This overlay *will* allow libraries that could inadvertently affect any
number of packages in the Gentoo repository.

This overlay *will* allow commits from anyone that requests it and has a
half-way decent ebuild in bugzilla, without doing any of the
trust-building that is normally required for someone to have commit
access to a Gentoo resource.

This overlay *will* not be monitored by any of the Gentoo security
project, yet will be an official repository of ebuilds coming from
Gentoo and hosted on Gentoo infrastructure.

> You know ... users. Those people that are not devs. Some of us try to
> give them the best experience we can, and if there is something like an
> overlay that even the more n00bish users can use we should try to
> provide it.

Huh?  You mean the ones that expect us, as developers, to have their
best interests in mind and to not allow poor-quality and potentially
hazardous ebuilds to hit their machines?  The same ones that trust us
with the stability of their machines?  The same ones that choose Gentoo
because we're the best, not because we have some dumping ground of
barely-wanted packages?  Yeah, those users...

> > > And again, one svn repo vs. 113 hard-to-find bugs ...
> > Amazing how you pull such numbers out of thin air. 
> It's a special talent. 47 <-- just for you

Ahh, so you're lying.  Thanks for pointing that out.  It definitely
helps.

> >  Which 113 bugs are you talking about, exactly?
> Try to find the relevant files in the three bugs jakub posted.
> Now try that for multiple packages ... Most users won't need to harvest
> 113 bugs, but I'd prefer a "svn up". It's just so much saner and less
> work that it is hard for me to see how bugzilla even makes sense.

So you don't have a list of 113 bugs, but instead go on to speak of your
preference to svn up.

Now, I'm going to make this plain and simple.  This is you avoiding the
question that was presented to you.

> > Isn't that what the process of becoming a developer is supposed to
> > build?
> That process that many people consider too complicated and
> time-consuming?

Yes.  That *exact* process that weeds out the people that honestly want
to be a part of Gentoo and those that casually want to contribute.

> Not everyone wants to spend 20h a week on Gentoo. Some people just want
> to maintain their personal app for Gentoo. In some cases we already have
> proxy-maintainers, so I don't see why we should not try to find more
> motivated smart users to help.

Great.  Why do they need an overlay to do their job?  The funny thing is
that nobody has answered this question.  All that anyone has done is
given some vague references or promises about how it'll be "better"
having an overlay with nothing to back it up.  However, I've been able
to show quite a few ways in which this overlay will hurt Gentoo.  There
have also been comments from other developers, and users, that have been
all but ignored.  I guess it is hard to respond to something when you
have no way to refute it, but I digress.

> >   Also, just because I trust one person, doesn't mean I trust
> > someone that you trust.  Trust is not implicit, it is earned.
> That's why most Gentoo devs can have an account on my server. Except
> those that have told me directly that they don't like me :-)

Again, you decide to point out something that is only somewhat related
and try to use it as a proving point for your position, when it really
bares no real relevance.  What exactly does trusting developers, which
have been members of the community for some time and have proven
themselves, have to do with trusting a random set of users?

> >   Some
> > random user having complete access to an area where only people that *I*
> > trust should really have access is not instilling faith in me of this
> > project.  However, instead of answering these concerns, you simply brush
> > them aside as a non-issue, though I am not the only developer that has
> > spoken out on this *exact* same issue.
> The difference between a random user and a dev often is not much more
> than an @gentoo.org email adress. I don't consider all users
> untrustworthy - if they show that they wish to help we should not
> sabotage them. Maybe you don't remember the time when you were "just" a
> user?

I don't consider all users untrustworthy.  Never once have I said that.
This is another attempt to try to put words into my mouth so that you
can hit home your own ideas, which aren't even relevant, since I didn't
*say* what you're responding to.  Remember what I said, and that you
agreed to.  Trust is earned.

> If someone wanted to exploit boxen he'd use a much simpler attack
> vector ... our rsync mirrors are wide open. No need to secure the little
> window over there when the front door is open ...

Really?  I'd like you to give me root on rsync.gentoo.org, then.  What's
that?  You can't?  What a wonder!

> Instead of trying to kill this idea you should try to get it modified
> into something we all can agree on.

I tried that.  I ended up receiving vague references about how the
current plan will make things "better" and how nothing needs to change.
Either that or the issues were simply ignored.  That to me says that the
team involved isn't interested in compromise.  That only leaves one
course of action for me, and that is to work to kill the project.

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

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

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

[Donnie Berkholz]

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

Chris Gianelloni wrote:
> Since when was overlays.gentoo.org supposed to even be a service to our
> users?  As I understand it, the goal was to ease development, not to
> provide an easy method for half-working ebuilds to make it to our user's
> machines.

Our users are our biggest base of testers, and the point of overlays is
to develop and test, so of course one of the goals is to get overlays
onto users' (testers') machines. Making testing as easy as possible is
important. But it should be clear that it is testing, and if the apps
were ready for the real Portage tree, they'd be in it.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

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

[Luis Francisco Araujo]

Donnie Berkholz wrote:
> Chris Gianelloni wrote:
>   
>> Since when was overlays.gentoo.org supposed to even be a service to our
>> users?  As I understand it, the goal was to ease development, not to
>> provide an easy method for half-working ebuilds to make it to our user's
>> machines.
>>     
>
> Our users are our biggest base of testers, and the point of overlays is
> to develop and test, so of course one of the goals is to get overlays
> onto users' (testers') machines. Making testing as easy as possible is
> important. But it should be clear that it is testing, and if the apps
> were ready for the real Portage tree, they'd be in it.
>
> Thanks,
> Donnie
>
>   
That's already being done very well with per-team overlays.
-- 
gentoo-dev@gentoo.org mailing list

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

[Patrick Lauer]

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

On Fri, 2006-06-09 at 16:14 -0400, Chris Gianelloni wrote:
[snip]
> > If someone wanted to exploit boxen he'd use a much simpler attack
> > vector ... our rsync mirrors are wide open. No need to secure the little
> > window over there when the front door is open ...
> 
> Really?  I'd like you to give me root on rsync.gentoo.org, then.  What's
> that?  You can't?  What a wonder!

I don't need that ...
Look, three-step plan to hacking Gentoo boxen:

1) open a few rsync mirrors and get them into the official rotation
2) replace ebuilds on the server with your preferred rootkit installer
3) harvest all the zombies you just got 

Since not all ebuilds are signed and signing is not enforced portage
will not throw any errors if I take care  of a few things (fixing
manifests etc.). So any person running an rsync mirror has implicitly
the same level of trust as a dev.  

As for the rest of your email, I'd appreciate it if you didn't take this
so personal. There's no need to belittle or insult others to push your
agenda, it should stand on its own technical merits. 

Patrick
-- 
Stand still, and let the rest of the universe move

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

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

[Chris Gianelloni]

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

On Fri, 2006-06-09 at 22:51 +0200, Patrick Lauer wrote:
> On Fri, 2006-06-09 at 16:14 -0400, Chris Gianelloni wrote:
> [snip]
> > > If someone wanted to exploit boxen he'd use a much simpler attack
> > > vector ... our rsync mirrors are wide open. No need to secure the little
> > > window over there when the front door is open ...
> > 
> > Really?  I'd like you to give me root on rsync.gentoo.org, then.  What's
> > that?  You can't?  What a wonder!
> 
> I don't need that ...
> Look, three-step plan to hacking Gentoo boxen:
> 
> 1) open a few rsync mirrors and get them into the official rotation

Umm... the rsync servers in rsync.gentoo.org are all controlled by infra
now.  If you're using another rsync server (read, untrusted) then you
get what you deserve.  ;]

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

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

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

[Andrea Barisani]

On Fri, Jun 09, 2006 at 05:22:18PM -0400, Chris Gianelloni wrote:
> On Fri, 2006-06-09 at 22:51 +0200, Patrick Lauer wrote:
> > On Fri, 2006-06-09 at 16:14 -0400, Chris Gianelloni wrote:
> > [snip]
> > > > If someone wanted to exploit boxen he'd use a much simpler attack
> > > > vector ... our rsync mirrors are wide open. No need to secure the little
> > > > window over there when the front door is open ...
> > > 
> > > Really?  I'd like you to give me root on rsync.gentoo.org, then.  What's
> > > that?  You can't?  What a wonder!
> > 
> > I don't need that ...
> > Look, three-step plan to hacking Gentoo boxen:
> > 
> > 1) open a few rsync mirrors and get them into the official rotation
> 
> Umm... the rsync servers in rsync.gentoo.org are all controlled by infra
> now.  If you're using another rsync server (read, untrusted) then you
> get what you deserve.  ;]
>

Right.

Besides all distro suffer this same problem, indeed shouting that our mirror
system is a wide open door is far from being fair. This new project though
could be a nice attack vector, in the FAQ you state that you don't allow
eclasses, that's nice...but I can think thousand of other ways for
compromises without them using ebuilds.

Not pointing fingers here, just stating that if this is an "official" project
(whatever that means)...or even if it's not, much caution is advised
security-wise in who you trust and what you are going to put in the tree (and
most important what the perception of your authority/reliability will be
user-wise).

Cheers

-- 
Andrea Barisani <lcars@gentoo.org>                            .*.
Gentoo Linux Infrastructure Developer                          V
                                                             (   )
PGP-Key 0x864C9B9E http://dev.gentoo.org/~lcars/pubkey.asc   (   )
    0A76 074A 02CD E989 CE7F AC3F DA47 578E 864C 9B9E        ^^_^^
      "Pluralitas non est ponenda sine necessitate"
-- 
gentoo-dev@gentoo.org mailing list

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

[Lance Albertson]

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

Patrick Lauer wrote:
> On Fri, 2006-06-09 at 16:14 -0400, Chris Gianelloni wrote:
> [snip]
>>> If someone wanted to exploit boxen he'd use a much simpler attack
>>> vector ... our rsync mirrors are wide open. No need to secure the little
>>> window over there when the front door is open ...
>> Really?  I'd like you to give me root on rsync.gentoo.org, then.  What's
>> that?  You can't?  What a wonder!
> 
> I don't need that ...
> Look, three-step plan to hacking Gentoo boxen:
> 
> 1) open a few rsync mirrors and get them into the official rotation

Actually, the only rotation you can get on is a community one (which
minimizes the amount of users). All the servers under rsync.g.o are
strictly controlled by infra.

So nice try ...

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

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

[Patrick Lauer]

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

On Fri, 2006-06-09 at 16:14 -0400, Chris Gianelloni wrote:

> Since when was overlays.gentoo.org supposed to even be a service to our
> users?  As I understand it, the goal was to ease development, not to
> provide an easy method for half-working ebuilds to make it to our user's
> machines.

What's the point of development if not to help users? 
Everything we do should be done to help users (and worst case we help
that small group of users that are devs). 

> > > This means it *CANNOT* be left up to a small group of developers to
> > > decide without any discussion on the matter.
> > So now we're a democracy where everything needs to be voted upon?
> 
> Anything this abhorrently stupid doesn't need a vote. 
Bullshit.
If you need to resort to insults you failed to show on a technical level
why it is bad.

>  It should be cast
> out on its complete lack of merit, alone.  Also, at no point did I ever
> ask for a vote.  Don't put words in my mouth and I'll try to pretend
> like I care what you say, OK?
So now you're El Cheffe? 

And please, stop sounding like my father. 


> > *sigh*
> > Let's leave that debate for another day ...
> 
> You brought it up, not I.  Feel free to debate it with yourself until
> you're blue in the face.
I debated it for about 27 seconds, seems quite obvious now. Thanks for
the hint.

> > > > Yes, now it is easier to check out the ebuilds. More users ==> better
> > > > testing.
> > > 
> > > Except that now the developer has to do much more work to get the same
> > > information, making it even less likely that he'll bother to pick up one
> > > of these maintainer-wanted bugs.  
> > s/the developer/I/
> 
> You're right... I had that wrong.
> 
> s/the developer/the developers/
> 
> After all, there have been quite a number of people agreeing with me.

That's a non sequitur.
There's also quite a number of people agreeing with me, but that doesn't
make any point of view better or more thruthful. So either we try to
discuss in the hope of finding a compromise or we do a headcount and do
something stupid. I'd prefer a discussion, but if you just want to HULK
SMASH SUNRISE I won't stop you.

> > there are some devs that would prefer this overlay environment.
> > Please don't push your personal preferences as The Right Way (tm)
> 
> Ehh.  Were you an ebuild developer, your opinion might actually count
> for something when it comes to an ebuild development discussion.  By the
> way, where's the GWN this week?
Ulrich is MIA, nothing I can change. He does that from time to time.

> I'm glad your faith in them is so high.  My faith in *any* group this
> small having the ability to watch over a large number of outside
> contributors simply isn't there.
Let it grow. Slowly. 
Either it stands on its own or it dies from lack of interest.

> > That doesn't stop me from giving out access to my server to anyone who
> > has a good reason ... like the Gentoo/HURD repository or the Java
> > overlay.
> Well, we thank you for your immense self-sacrifice.  What this has to do
> with the topic at hand, I have no idea.
Well ... think about it. It's kinda obvious once you grok it.


> > Just don't kill an idea before it is even tested ...
> Why not?  What reason is there to stop me from aborting this brain-dead
> monstrosity before it claims a single user casualty, let alone our
> reputation?  I would have thought that your involvement in "PR" would
> have you thinking better.  A reputation is something that takes years to
> establish, and seconds to demolish.  You, of all people, should know
> that.
Yes. But killing an idea like this seems almost as damaging to me.

There's a group of devs thinking "Hey, how can we make things better?".
They come up with a few ideas, throw away those that are just not
feasible. Then they have one idea that looks useful, they try to
implement it. So either you convince those people (with whom I am only
tangentially involved) that it is a bad idea or you let them do their
thing.

I think what is more damaging to the reputation of Gentoo is the
incessant discussion of ideas before they are even tried, killing many
good things before they even have a chance on a technical level. 

> Yes, we are *so* lagged behind everyone else.  Where do you come up with
> these "facts" anyway?  I'd like to visit this mythical land.
Like, gcc 4 ? Gentoo is lagging behind most others (because our QA has grown from non-existant to really really good)

Sidenote: I don't mind that at all. But I see a split here ... one group going the debian route of making everything really really stable.
And the other group that doesn't mind mild b0rkage, but wants to be on
the bleeding edge.

Those two populations will be hard to reconcile. Give the second group a
sandbox and the first group can do their thing much easier ...
 
> > Where you see a problem I see potential: More well-tested ebuilds,
> > recruiting potential developers ... if you don't want that you're an
> > elitist bastard. ;-)
> 
> Aww, how sweet.  We've started the name calling.

Don't act that surprised, it looks fake. I'd appreciate it if we could
discuss things rationally, without your oh-so-funny sarcastic remarks
and snipes at me.

> I'm sorry, but having a general dumping ground for all of the crap that
> nobody found useful enough to actually include into Gentoo doesn't sound
> like the paradise that you're making it out to be.  Luckily, I'm finding
> that I'm not alone in this, and that quite a few developers are backing
> me on this one.  We're not blind to the problems with this project in
> its implementation, management, and intended goals.  Perhaps you should
> open your eyes and seriously look at what you're pushing as a solution?
Now ... funny thing ... I'm only morally supporting this idea. I'm not actually involved any more than trying to discuss it.
I like the idea, now we should try to find a working implementation. 

> Misdirection at its finest.  So tell me, where do I learn this valuable
> skill of completely avoiding the truth and pretending to be blind to
> facts.  It sure must come in handy.
I'm sorry, I'm out of sarcastic remarks. I'll have to pass on that one.
Bummer.


> > 2) low-quality? I might mention that I'm hosting some overlays that have
> > non-gentoo contributors (*gasp!*)
> 
> Sure.  Overlays that are run by Gentoo developers with a specific
> project in mind, where the project is also the maintainers of the
> similar packages in the tree, are intimately familiar with the packages,
> and are also responsible for all the bugs regarding them.  Did you have
> a point, other than to help reiterate what I have said over and over
> again?  You're starting to help my case as much as Jakub.
Hehe. You do realize that jakub does not agree with your interpretation
of reality as far as I can tell? So, considering that it's becoming
really nonsensical. 

> > Why are they hosted on my server? Because the contributors are not (yet)
> > gentoo devs, but provide good to excellent input to the projects. So now
> > you tell me that I'm doing wrong in helping Gentoo development? These
> > people can't contribute to other gentoo-hosted projects, so it is easier
> > to move the repositories to a more liberal server.
> 
> No.  They're on your server because we had no facility for them to be
> placed on our infrastructure.  They could all easily be moved now and
> would be well within the parameters for the overlays project. 
As it happened with planet. Why do I have to have a working
proof-of-concept before anyone listens to me? :-)
That's just a silly redirection step that annoys all involved. 

>  However,
> project sunshine flies directly in the face of those parameters, and
> should be killed before it is allowed to harm Gentoo.
s/killed/modified/
It's called diplomacy, it's the thing you usually do instead of bombing
countries back into the stone age.

> > > I seriously question your motives towards the Gentoo project.
> > Good. Question them. I'm still doing what I can to help ... doing such silly things as finding new servers for Infra and writing articles for the GWN.
> 
> Really?  Which servers?  Which articles?
Bug number 108379, just a smallish Opteron on an unmetered 100Mbit connection. You do the math on that one :-)

And articles ... well ... I've had at least one bit of my prose in
almost all GWNs since November 2004. Together with Ulrich I've been the
only really regular contributor. 

But I don't see how _that_ relates to the discussion. 

> > If that isn't good enough ... well ... who cares. You invest as much as
> > I do in your own server for Gentoo usage and I'll not question _your_
> > motives.
> Like the hardware I've donated on multiple occasions?
Good to hear. Don't turn it into a pissing contest, I'm just a poor
student, so you can outspend me any day of the week.

>   Or the hours and
> hours I spend working on Gentoo's actual products?  How about the hours
> spent running the Gentoo Store, that actually brings in money for
> Gentoo?
Good.

> Spending a few dollars doesn't make you anything more than a monetary
> contributor.  It doesn't buy you any respect.  It doesn't buy you
> anything.
Except that all of Gentoo Infra is donated. Are you saying that we don't
need any of these donations? Hey, tell OSU that we don't need their
support. 

> How about instead actually answering the issues that have been
> presented?
You're going to kill it anyway, so why bother?

> How exactly is it easier to manage a large number of ebuilds versus a
> small number?
It is easier to manage one large overlay than managing 35 small overlays.
Communication overhead, duplication of effort, ...

> Quit averting the issues when they are brought up.
I'm not.

> > You know ... users. Those people that are not devs. Some of us try to
> > give them the best experience we can, and if there is something like an
> > overlay that even the more n00bish users can use we should try to
> > provide it.
> 
> Huh?  You mean the ones that expect us, as developers, to have their
> best interests in mind and to not allow poor-quality and potentially
> hazardous ebuilds to hit their machines?  The same ones that trust us
> with the stability of their machines?  The same ones that choose Gentoo
> because we're the best, not because we have some dumping ground of
> barely-wanted packages?  Yeah, those users...
You might want to differentiate between user groups ... some want breakage. 
Must be some special masochism, but they are using CFLAGS and overlays that 
are really whacky. But if that's what they want to do I'm not going to stop them. 
I'll try to convinve them that what they do is not right, their problem
if they don't listen.

Others want stability. For those everything moves too fast. So decide,
which group do you want? Ricers or debianites? I'll take both. A nice
stable tree for one group, one adequately labelled experimental
playground for the others.


> > > > And again, one svn repo vs. 113 hard-to-find bugs ...
> > > Amazing how you pull such numbers out of thin air. 
> > It's a special talent. 47 <-- just for you
> Ahh, so you're lying.  Thanks for pointing that out.  It definitely
> helps.
Eh? What about the 47 is a lie? You're doubting the 47? 

> > >  Which 113 bugs are you talking about, exactly?
> > Try to find the relevant files in the three bugs jakub posted.
> > Now try that for multiple packages ... Most users won't need to harvest
> > 113 bugs, but I'd prefer a "svn up". It's just so much saner and less
> > work that it is hard for me to see how bugzilla even makes sense.
> So you don't have a list of 113 bugs, but instead go on to speak of your
> preference to svn up.
What jakub said.

> Now, I'm going to make this plain and simple.  This is you avoiding the
> question that was presented to you.
No, it is you doing a ciaranm on me by trying to force me to discuss tangential issues, wrap me in two layers of confusion and then you do what you wanted to do from the beginning anyway.

> > Not everyone wants to spend 20h a week on Gentoo. Some people just want
> > to maintain their personal app for Gentoo. In some cases we already have
> > proxy-maintainers, so I don't see why we should not try to find more
> > motivated smart users to help.
> 
> Great.  Why do they need an overlay to do their job?  The funny thing is
> that nobody has answered this question.  All that anyone has done is
> given some vague references or promises about how it'll be "better"
> having an overlay with nothing to back it up. 
I think it was jokey who pasted an email from a user who just wanted to
maintain his two packages without the full become-a-dev stuff, including
reading huge flamewars on mailinglists and other non-productive issues. 

>  However, I've been able
> to show quite a few ways in which this overlay will hurt Gentoo.  There
> have also been comments from other developers, and users, that have been
> all but ignored.  I guess it is hard to respond to something when you
> have no way to refute it, but I digress.
*shrug*
Then try to _modify_ it. There's a large group of users (including devs)
that would appreciate such an overlay. I guess it's hard to accept
dissenting opinions when you are not prepared to discuss, but I digress
too. Those are not the users we want *jedi mind trick* I guess.

> > >   Also, just because I trust one person, doesn't mean I trust
> > > someone that you trust.  Trust is not implicit, it is earned.
> > That's why most Gentoo devs can have an account on my server. Except
> > those that have told me directly that they don't like me :-)
> 
> Again, you decide to point out something that is only somewhat related
> and try to use it as a proving point for your position, when it really
> bares no real relevance. 
It does.
>  What exactly does trusting developers, which
> have been members of the community for some time and have proven
> themselves, have to do with trusting a random set of users?
I also trust a mostly random subset of users. And I haven't had any
problems yet. Au contraire, these users have been some of the most
helpful and polite I've met. Some devs could learn a lot from them -
humility, politeness, all that stuff.

> I don't consider all users untrustworthy.  Never once have I said that.
> This is another attempt to try to put words into my mouth so that you
> can hit home your own ideas, which aren't even relevant, since I didn't
> *say* what you're responding to.  Remember what I said, and that you
> agreed to.  Trust is earned.
No, strangers are friends you haven't met. Maybe I'm showing my anarchistic/liberal side again, but I tend to trust people until they screw up.
And the amazing part is that people rarely screw up if you are nice to
them and help them.

> > If someone wanted to exploit boxen he'd use a much simpler attack
> > vector ... our rsync mirrors are wide open. No need to secure the little
> > window over there when the front door is open ...
> 
> Really?  I'd like you to give me root on rsync.gentoo.org, then.  What's
> that?  You can't?  What a wonder!
See my other email. No need to break the 10in metal plate when you can drive a truck trough the brick wall on the side...

> > Instead of trying to kill this idea you should try to get it modified
> > into something we all can agree on.
> 
> I tried that.  I ended up receiving vague references about how the
> current plan will make things "better" and how nothing needs to change.
> Either that or the issues were simply ignored.  That to me says that the
> team involved isn't interested in compromise.  That only leaves one
> course of action for me, and that is to work to kill the project.
Hmmm. Interesting.
So I guess it's all a big misunderstanding and we should start this
discussion from scratch. Looks like people talked past each other and
then got all personal instead of communicating.


Patrick 
-- 
Stand still, and let the rest of the universe move

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

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

[Luis Francisco Araujo]

Patrick Lauer wrote:
> On Fri, 2006-06-09 at 16:14 -0400, Chris Gianelloni wrote:
>   
>> How exactly is it easier to manage a large number of ebuilds versus a
>> small number?
>>     
> It is easier to manage one large overlay than managing 35 small overlays.
> Communication overhead, duplication of effort, ...
>
>   
How many people will manage the big overlay? , How many ebuilds will 
this overlay have? ,
now compare that to the amount of people maintaining the small overlays 
and their number
of ebuilds.

Which one is easier now?

Note: And i am omitting all that part of who are maintaining the 
ebuilds?, how they are maintaining them?,
what kind of ebuilds they are maintaining?, and many many other details 
that probably immediately kill
the assumption of a big overlay being easier than 35, 40, 90, 500 
smaller overlays.


-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

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

First off, I would like to apologize to everyone who has to read this
thread.  I know that it is long.  I know that it can be frustrating.
That being said, I also ask for your patience in this matter, as I am
not going to back down on this.  I will not roll over and let something
I see as this damaging to Gentoo simply happen.

Also, since it is obvious that some people are trying to deflect
attention away from the actual issues, I will likely not respond to any
points that I don't consider to be relevant.  I'm not wasting my time,
nor yours, with this garbage.

Some people seem to not understand that this is not *only* a technical
problem, and therefore cannot be discussed on a purely technical level.
Some people also think that by comparing someone to a certain
ex-developer, that they're going to either win some traction or cause
their opposing side to give up.  This is not the truth, at all.  If it
has done anything, it has *fueled* me to fight this "project" even more.

On Fri, 2006-06-09 at 23:54 +0200, Patrick Lauer wrote:
> On Fri, 2006-06-09 at 16:14 -0400, Chris Gianelloni wrote:
> 
> > Since when was overlays.gentoo.org supposed to even be a service to our
> > users?  As I understand it, the goal was to ease development, not to
> > provide an easy method for half-working ebuilds to make it to our user's
> > machines.
> 
> What's the point of development if not to help users?

Umm... perhaps to create a *product* that gives usable software to
users?

How about a little history lesson?

Not so many moons ago, new ebuilds were submitted to bugzilla.  The bug
wranglers would assign the bugs to the team most likely to end up as the
maintainers, and new ebuilds either made it into the tree, or sat in
bugzilla until the interest was there for it to be added, if ever.  Some
people felt that this process left lots of packages in bugzilla, with no
one to watch over them.  Because of this, the maintainer-wanted, and
maintainer-needed bugzilla accounts were created to assist in tracking
these bugs/packages.  This was a good idea at the time, and worked
fairly well so long as there were developers going through and actively
searching for bugs, that were no longer assigned to the relevant teams,
but instead, assigned into some big dumping ground for new package
requests.

This process failed, as visibility for new packages was reduced to the
teams that would likely be doing the actual work.

Now, instead of reverting a broken and failed process, a new project is
being created in an attempt to fix the problem.  Unfortunately, it has
been pointed out that this will introduce an even larger set of
problems, but that is not being addressed very well.

> Everything we do should be done to help users (and worst case we help
> that small group of users that are devs). 

I would have to absolutely disagree here.  Gentoo's resources should be
spent helping developers do their work more efficiently.  This provides
a positive end result of users getting more and better software.  If we
simply did everything for the users, then we would have every single
kernel source tree done by a few guys with little understanding of
kernel internals, we'd only ship a stage1 tarball, and reiser4 would be
our default file-system, stability be damned.

> > > > This means it *CANNOT* be left up to a small group of developers to
> > > > decide without any discussion on the matter.
> > > So now we're a democracy where everything needs to be voted upon?
> > 
> > Anything this abhorrently stupid doesn't need a vote. 
> Bullshit.
> If you need to resort to insults you failed to show on a technical level
> why it is bad.

I have already shown that this is a piss poor idea on a technical level.
I don't think I need to reiterate this again and again, but just for
you, since you're not catching on, I'll do it one more time.

This is an attempt to fix what is a social problem with a technical
solution, where one doesn't fit.

What problem is this project trying to resolve, exactly?

How will creating a secondary "official" (hey, it's on *.gentoo.org)
portage tree help in creating a higher-quality primary portage tree?

How will a small team maintain the security and reliability that Gentoo
has come to be known for in a secondary portage tree without the support
of a security team, or the architecture teams?

Why was this not discussed on the developer mailing list before being
publicly announced to the world as if it were a complete and working
service, with all of the issues worked out?

Now, (sorry Flameeyes) let's look at another scenario.  A new user to
Gentoo decides that he absolutely *must* have package foo.  He reads on
the forums that package foo is in the Sunrise overlay, so he uses layman
and syncs up the overlay.  Three weeks later, he decides that he wants
pam_skey.  He does a search, and there it is!  He installs it.  This
user is not even *aware* that the package came from the overlay.  He has
a problem.  He files a bug.  Guess who gets it?  Remember, that he isn't
likely to mention project Sunrise, or pam_skey, since he doesn't think
it is relevant.  The bug wranglers will see Sunrise in his overlays on
emerge --info, but will have *no clue* what packages he has installed
from this overlay.  How is this helpful again?

> Either it stands on its own or it dies from lack of interest.

You completely avoid the point where it is possibly damaging to Gentoo's
reputation and community.

> I think what is more damaging to the reputation of Gentoo is the
> incessant discussion of ideas before they are even tried, killing many
> good things before they even have a chance on a technical level.

You cannot band-aid a social problem (the lack of developers/interest)
with a technical solution.

> > Yes, we are *so* lagged behind everyone else.  Where do you come up with
> > these "facts" anyway?  I'd like to visit this mythical land.
> Like, gcc 4 ? Gentoo is lagging behind most others (because our QA has grown from non-existant to really really good)

Let's see.  We have GCC 3.4 stable and 4.1 in testing.  How about some
other guys?

Red Hat Enterprise Linux: GCC 3.4 (No testing branch)
Slackware: GCC 3.3.6 (3.4 in testing)
Debian: 3.3.5 (4.0 in testing)
Suse Linux Enterprise Server 9: 3.3.3 (No testing branch)
Suse Linux 10.1: 4.1 (No testing branch)
Ubuntu: 4.0.3
Fedora Core 5: 4.1
Mandriva: 4.0.1 (4.0.2 in beta)
Linspire: 3.4.3

Now, I don't see a whole lot of GCC 4.1 in people's stable trees.  I
guess that makes us pretty much on-par with some of the other guys,
doesn't it?

Please, if you're going to use something as an argument in your favor,
check the facts, first.

> It's called diplomacy, it's the thing you usually do instead of bombing
> countries back into the stone age.

(A side bit of humor...)

I'm an American.  We don't *do* that.  ;]

> > Like the hardware I've donated on multiple occasions?
> Good to hear. Don't turn it into a pissing contest, I'm just a poor
> student, so you can outspend me any day of the week.

You're right.  This doesn't need to become a pissing contest.  My only
question is this.  Why in the hell did you mention how you spend money
for this sort of thing if you didn't want it discussed?  It's one of
those things that really shows you don't want to have a discussion, but
instead are trying to redirect away from the issues at hand.

> > Spending a few dollars doesn't make you anything more than a monetary
> > contributor.  It doesn't buy you any respect.  It doesn't buy you
> > anything.
> Except that all of Gentoo Infra is donated. Are you saying that we don't
> need any of these donations? Hey, tell OSU that we don't need their
> support. 

Again, stop with putting words in my mouth.  It really makes you look
like an asshole.

> > How exactly is it easier to manage a large number of ebuilds versus a
> > small number?
> It is easier to manage one large overlay than managing 35 small overlays.
> Communication overhead, duplication of effort, ...

Is this not *exactly* why there is a project for managing these
overlays?

> > Huh?  You mean the ones that expect us, as developers, to have their
> > best interests in mind and to not allow poor-quality and potentially
> > hazardous ebuilds to hit their machines?  The same ones that trust us
> > with the stability of their machines?  The same ones that choose Gentoo
> > because we're the best, not because we have some dumping ground of
> > barely-wanted packages?  Yeah, those users...
> You might want to differentiate between user groups ... some want breakage. 
> Must be some special masochism, but they are using CFLAGS and overlays that 
> are really whacky. But if that's what they want to do I'm not going to stop them. 
> I'll try to convinve them that what they do is not right, their problem
> if they don't listen.

No offense, but of course you aren't going to stop them.  You are not an
ebuild developer.  You don't have access to the portage tree, and you
don't actually support the users.  You aren't a bug wrangler.  You
aren't responsible for working through bugs in *any* way.  I tend to
think that Gentoo, as a whole, is trying its damnedest to move away from
the ricer reputation that we had of old.  We don't *want* breakage in
our tree.  We are no longer a toy for a bunch of developers.  We are a
serious distribution, capable of being used in the enterprise.  Adding
additional overhead to get in the way of real development and causing
more breakage than we already have is *not* a way to grow our
distribution or make it better, it is a way to stifle it and kill it.

> No, it is you doing a ciaranm on me by trying to force me to discuss tangential issues, wrap me in two layers of confusion and then you do what you wanted to do from the beginning anyway.

Ahh, yes, the ciaranm defense.  What next, the Chewbacca defense?

> I think it was jokey who pasted an email from a user who just wanted to
> maintain his two packages without the full become-a-dev stuff, including
> reading huge flamewars on mailinglists and other non-productive issues.

...and?

You haven't proven any points here.  You've merely restated something
that was said before.

How will this help the individual in question maintain his package in
the portage tree, or get it included in the portage tree?

Will it not still require a proxy maintainer to take interest in the
package and actually commit it to the tree?

Will this proxy maintainer not need to be notified when new versions of
the package/ebuild are created?

How is getting an email stating to "go check out the subversion tree for
a new version" end up being that much quicker than an email that says
"attached is a new version of the package"?  Either way, the
communication must happen.

> > > >   Also, just because I trust one person, doesn't mean I trust
> > > > someone that you trust.  Trust is not implicit, it is earned.
> > > That's why most Gentoo devs can have an account on my server. Except
> > > those that have told me directly that they don't like me :-)
> > 
> > Again, you decide to point out something that is only somewhat related
> > and try to use it as a proving point for your position, when it really
> > bares no real relevance. 
> It does.

Excellent counter argument.  Let me try.  "It doesn't."

Bravo!  Go me!

Now, how about I try it for real.  I have faith in the Gentoo
recruitment process to try to weed out some of the less than skilled
users, who would like to contribute, but either don't know how or simply
don't have the necessary skills to do so.  While I might trust a small
subset of users that I personally have spoken with, or one of my trusted
associates has spoken with, I do not inherently trust every user who has
submitted an ebuild to have access to make changes to a repository where
my trusted users are working.  Remember now, I trust the recruitment
process to weed these people out.

What will *this* project do to provide the same level of trust?

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

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

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

[Kevin F. Quinn]

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

On Sat, 10 Jun 2006 10:27:29 -0400
Chris Gianelloni <wolf31o2@gentoo.org> wrote:

[lots of good stuff - +lots Chris]

> Not so many moons ago, new ebuilds were submitted to bugzilla.  The
> bug wranglers would assign the bugs to the team most likely to end up
> as the maintainers, and new ebuilds either made it into the tree, or
> sat in bugzilla until the interest was there for it to be added, if
> ever.  Some people felt that this process left lots of packages in
> bugzilla, with no one to watch over them.  Because of this, the
> maintainer-wanted, and maintainer-needed bugzilla accounts were
> created to assist in tracking these bugs/packages.  This was a good
> idea at the time, and worked fairly well so long as there were
> developers going through and actively searching for bugs, that were
> no longer assigned to the relevant teams, but instead, assigned into
> some big dumping ground for new package requests.

I think it's clear that the maintainer-wanted/maintainer-needed hasn't
actually solved the problem it was trying to address. While it has
improved on some counts, I think the fact that herd maintainers
are not watching those aliases means that new builds are not being
brought to the attention of the devs most likely to take them on.

Instead of having sunrise on gentoo.org, which I agree with Chris is
fundamentally a bad idea, could we simply go back to assigning new
builds to the most relevant herd alias, but also add
maintainer-wanted/needed to the CC:?  That way some responsibility is
assigned to the herd to deal with it one way or another. If the
herd does not have the manpower to deal with it they can just reassign
to maintainer-needed and CC the herd, indicating they need someone
to join the group of herd maintainers to take the package on. With
maintainer-* on CC the benefits accrued so far from having a bunch of
people helping to iron out early QA problems would remain, and at the
same time the group of people most likely to pick up the package would
also be aware of it.

-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

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

[Josh Saddler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Gianelloni wrote:
> [. . .]

Right on! :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEi/j4rsJQqN81j74RAsRHAKCJsN09KKGlLq5CD4Bh/7r9QYJ12QCgnFx1
lRWrDI1euePCP0MrwoP/Emg=
=G9qu
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[Stuart Herbert]

On 6/9/06, Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> Wouldn't this process be *infinitely* easier if instead of "sunrise"
> there was a "pam" overlay with *only* the pam stuff?

I agree that it would make sense for the the sunrise overlay to
contain smaller package trees, with each package tree aimed at a
particular type of ebuild.  Layman supports automatically downloading
each of these smaller trees as separate overlays.

This would still allow Sunrise to maintain a social workspace, where
Gentoo can encourage and train would-be developers (and hopefully
recruit the good ones) .  In fact, I believe that it will work better,
because we'll be encouraging users to focus on particular problem
areas rather than encouraging users to download a large and sprawling
mass of packages.

Having smaller, targetted trees would also help ensure that Sunrise
doesn't become another BMG.

Best regards,
Stu
-- 
gentoo-dev@gentoo.org mailing list

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

[Wernfried Haas]

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

Hi,
Both the current discussion as well as the overlay docs don't seem to
cover the support topic as far i could see. This is an issue for us
forums people though - our daily work involves classifying misplaced
threads into officially supported (read: in the tree) and unsupported
(someone installed some ebuild he found somewhere else) threads. The
latter go into the Unsupported Software forum [1].

For now, we've added "Bugs/errors caused by ebuilds from
overlays.gentoo.org are covered by this forum, too." to the
description of this forum because we think the primary objective of
the forums is supporting officially supported ebuilds - those in the
tree.

I'm not saying it has to be/stay this way forever, but to be honest we
are quite taken by surprise to have a new project appear that is both
official(?) and unsupported(?) at the same time. So if at some time
you intend to point the users of the overlay at the forums, please let
them know the US-forum is the place to be.

cheers,
	Wernfried

[1] http://forums.gentoo.org/viewforum-f-51.html

-- 
Wernfried Haas (amne) - amne at gentoo dot org
Gentoo Forums: http://forums.gentoo.org
IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

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

[Markus Ullmann]

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

My intention was to solve some parts with him directly and then send out
some solutions but he wants to do everything on list, so I'm sending it
out for you to know.

-- LOGPOST --
[22:09:15] <jokey> so after reading your posts I get the impression you
fear that this project will end up in some BMG overlay just with an
official gentoo stamp on it. Am I right here?
[22:10:22] <wolf31o2|work> please read what I said in #-releng
[22:11:45] <jokey> Yes I want to do it public, maybe just attach a log
of this to a mail sent to -dev afterwards. just want to avoid having
that much emails just for seeking the issues instead of finding
solutions for them
[22:11:52] <wolf31o2|work> I think it is a bad idea
[22:12:21] <wolf31o2|work> quite simply, when the overlays project was
formed, this was something that was specifically said would never happen
[22:12:41] <wolf31o2|work> I'm going to fight it tooth and nail, because
I never would have accepted a project such as overlays if it was going
to be abused like this
[22:13:02] <wolf31o2|work> and please don't even say it won't be abused
when there's already examples of it being done so
[22:13:07] <wolf31o2|work> and the overlay just began
[22:13:16] <wolf31o2|work> and that's really all I have to say about it
[22:13:39] <wolf31o2|work> (sorry, I prefer my discussions on things
that affect *everyone* be done completely in public)
[22:14:31] <jokey> okay, I'll attach this then to a mail just that
everybody knows about it then
-- LOGPOST --

Greetz,
Jokey


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

[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

[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

[gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Alternative?

[@4u]

Hi again

as written below I think it makes more sense for Project sunrise to redefine 
it a bit. It seems to be clear that currently noone is happy with the 
Sunrise Project. 

There is one huge disadvantage for end users like me:
If we decide to use an overlay package (because "we" need / want the 
functionality) we have to make sure from time to time that this one is up to 
date.

BTW: This is not only time consuming but also inefficient.

Where is the difference to BMG? Two things:
a) Official development support (note: not an official overlay).
b) One overlay per development (team) project instead of an huge overlay 
with maybe breaking stuff.

This is a different approach than the one of BMG:
"We want to provide unstable ebuilds, which have no chance to get into 
portage."

How about this alternative:

Use sunrise (as stated earlier) as an "help me"-mailing list or whatever for 
users who may want to become developers. Provide RSS feeds (as stated below 
- a good idea I think) for end users.

How should it work (new dev view):
- A user want to add application (x) to portage. He creates a overlay and 
uses bugzilla and so on.
- He is interested in adding his ebuild (or program (x)) permanently to 
portage.
- This user requests help and support from the sunrise developers. The 
guidelines say, that he should provide a RSS feed to inform users about new 
versions of program (x) for Gentoo.

Why should he provide an overlay? Because it's easier for testing purposes 
than downloading maybe a whole bunch of files from bugzilla.

How should it work (the sunrise project view):
- Sunrise works like an planet site. It scans the RSS feeds in specific 
time intervals and add new entries to its own DB.
- Sunrise contains a DB for locations of overlays and contact details.
- Sunrise will provide functions for users to search on it (like 
packages.gentoo.org) and to find information where the overlay is 
located.

How should it work (sunrise dev view):
- The developer finds out that a new version of the ebuild exists. He 
reviews the ebuild and gives feedback to the developer.
- He uses contact details that the "taker" used to register at sunrise.

How should it work (end users view):
- Load a RSS feed into your favorite RSS viewer and you're done. Of course 
you still have to use layman or whatever to update the overlays manually. Is 
there a way to integrate this functionality into emerge --sync?

Advantages:
- Easy to search and up to date DB for custom Gentoo overlays
- Helpful information and feedback from Gentoo developers.
- Learning by doing approach.

Disadvantages:
- Still different places all over the net for overlays.
- Possibility that two teams create ebuilds for the same program.
- Different development forms. Somehow there have to be a way that third 
parties provide improved ebuilds.
- Maybe complicated rules: After x days inactivity, the project should be 
given to new takers and so on.

What do you think?

Best regards

PS.: This is just an early idea. Maybe you will find some not logical points 
here or things that already exist in the www ...

Edward Catmur writes:

> On Fri, 2006-06-09 at 02:53 +0200, Stefan Schweizer wrote:
<SNIP>
> 
> 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.)
> 
<SNIP> 
-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Bainbridge]

On 09/06/06, Edward Catmur <ed@catmur.co.uk> 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

[Ciaran McCreesh]

On Fri, 9 Jun 2006 11:05:56 +0100 "Chris Bainbridge"
<chris.bainbridge@gmail.com> wrote:
| On 09/06/06, Edward Catmur <ed@catmur.co.uk> 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]

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

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

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

[Chris Gianelloni]

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

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

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