Mailing List Archive

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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