On Thu, 2006-03-23 at 18:34 -0500, Dan Meltzer wrote:
> On 3/23/06, Daniel Goller <[EMAIL PROTECTED]> wrote:
> > On Wed, 2006-03-22 at 09:15 -0500, Dan Meltzer wrote:
> > > Asking developers to "proxy" takes almost as much time as it does to
> > > ask them to maintain a package by themselves.
> >
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As many are aware nss-3.11 and nspr-4.6.1 are in the tree. Many
packages still set the {nss|nspr}-libs and includes. With nss-3.11 and
nspr-4.6.1 the proper configs and pkgtools files are included. Any
package in the tree that has them hardcoded in th
Hi all,
One big issue has come up with modular X, which is now fixed in
xorg-server 1.0.2-r1. The problem is that upstream released new versions
of a couple of extensions (composite and xfixes), but didn't release an
xorg-server including the updated knowledge of these extensions. The
code fo
Stefan Schweizer wrote:
> On 3/24/06, Alec Warner <[EMAIL PROTECTED]> wrote:
>
>>Thoughts on ideas on this somewhat more focussed idea? ( or at least I
>>think it's more focused :P )
>
>
> IMO motivation b) is not taken into account enough.
>
> You are missing out a general-user-overlay, where
On Thu, 23 Mar 2006 19:57:07 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote:
| > Sounds like a perfect way to break lots and lots of systems. Those
| > policies are mostly there for good reason.
|
| You want to apply policies on overlays? Well no - sorry, overlays are
| none of QA's or any other policy
> Thoughts on ideas on this somewhat more focussed idea? ( or at least I
> think it's more focused :P )
Will there be restrictions on what can go into these overlays? There
are some ebuilds that aren't allowed in the main portage tree. One
example is winex-cvs (see
app-emulation/winex-cvs/winex-cv
so we're clear, users would be able to create their own overlays and publish
their ebuilds right ?
-mike
--
gentoo-dev@gentoo.org mailing list
On 3/24/06, Alec Warner <[EMAIL PROTECTED]> wrote:
> Thoughts on ideas on this somewhat more focussed idea? ( or at least I
> think it's more focused :P )
IMO motivation b) is not taken into account enough.
You are missing out a general-user-overlay, where the developer adding
a user to the acces
To hijack the overlay thread, I see a few things here:
MOTIVATION:
a) Developers don't like putting experimental stuff in the tree: This is
usually because Joe Ricer picks up the ebuild, 'tests' it, it breaks and
he files a bug. Joe Ricer has no clue what went wrong or what he is
doing and said
On 3/23/06, Daniel Goller <[EMAIL PROTECTED]> wrote:
> On Wed, 2006-03-22 at 09:15 -0500, Dan Meltzer wrote:
> > Asking developers to "proxy" takes almost as much time as it does to
> > ask them to maintain a package by themselves.
>
> wrong
>
> > The developer is
> > directly responsible for anyt
Chris Gianelloni wrote: [Thu Mar 23 2006, 09:41:25AM EST]
> On Thu, 2006-03-23 at 10:09 +, Chris Bainbridge wrote:
> > Reduced responsibility for package QA (I expect "we don't care about
> > overlays" to become a standard response on bugs.g.o)
>
> You will *definitely* get this from develop
Ciaran McCreesh wrote: [Wed Mar 22 2006, 12:33:10PM EST]
> On Wed, 22 Mar 2006 09:03:38 -0800 Donnie Berkholz
> <[EMAIL PROTECTED]> wrote:
> | This definitely sounds like a fun idea. It would be even cooler if we
> | were using a distributed SCM on both ends that allowed for easy
> | merging.
>
>
On Wed, 2006-03-22 at 09:15 -0500, Dan Meltzer wrote:
> Asking developers to "proxy" takes almost as much time as it does to
> ask them to maintain a package by themselves.
wrong
> The developer is
> directly responsible for anything he commits, so he will have to still
> test the ebuild, still
On Thursday 23 March 2006 19:55, Chris Bainbridge wrote:
> I agree. I would ask, what are the advantages of overlays that
> developers find so compelling that they use them rather than the
> portage tree? Would it not be a better idea to find a way to bring
> those advantages to the tree, rather th
Duncan wrote:
> I believe that's a fair summation of the arguments. My personal opinion,
> for whatever it's worth as a user on the dev list, is that the CC point is
> a valid one, the CC list should be a pretty decent measure of interest --
> I know it has certainly proven so on some of the bugs
Rumen Yotov posted <[EMAIL PROTECTED]>, excerpted below,
on Thu, 23 Mar 2006 20:20:30 +0200:
> Using a remote overlays is rather simple, just do "emerge layman".
> Read the einfo and then "man layman".
> It works flawlessly, just tested this with one remote overlay.
> Beside that "man layman" exp
Chris Bainbridge posted <[EMAIL PROTECTED]>,
excerpted below, on Thu, 23 Mar 2006 18:55:15 +:
>> No. It indicates nothing except that 58% of the 80 people who filled
>> out the poll are "not really happy with the way the portage tree is
>> handled" which by my counts, isn't even a drop in th
Paul de Vrieze wrote:
> I can only assume that other developers have similar overlays too. These
> overlays form actually a wealth of resources that are hidden away. If there
> were a semi-public overlay system in which developers could keep their
> overlays, this might help in getting this out
On Thursday 23 March 2006 16:31, Chris Gianelloni wrote:
> No. It isn't. Look in many developer overlays and you'll see packages
> that they have made that work how *they* want them to, even if it is
> *very* different from what is in the tree. This is the case for
> packages that are not mainta
On Thursday 23 March 2006 15:54, Eric Edgar wrote:
> I personally think this is a bad idea. I can understand and support
> links to different overlay repositories, however I do not think that
> gentoo should host or support overlays on its own infrastructure. For
> one thing supporting overlays o
> As said above, how are you going to get new contributors without people
> that are actually using/testing that stuff?
We find the via Bugzilla and/or irc and point them at the overlay.
That way, we more or less know who's using the overlay and make sure
they are briefed a bit before they start u
Duncan Coutts wrote:
> The way the Haskell team manages this is that we don't tell our end
> users about our testing overlay. So we don't get bug reports from them.
> We have three outside contributers with write access to the overlay
> repo. They make changes in consultation with the team. So we'
On 3/23/06, Daniel Ostrow <[EMAIL PROTECTED]> wrote:
> That is not what Stuart said, he indicated that overlays would be treated as
> supported systems including the use of our bugzilla system to track defects.
> If that is the case it crosses the line into the land of the "official" in
> which cas
On Thu, 2006-03-23 at 18:55 +, Chris Bainbridge wrote:
> On 23/03/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote:
> > On Thu, 2006-03-23 at 16:40 +, Chris Bainbridge wrote:
> > > If the software a user wants is in an overlay, then the user will be
> > > forced to install the overlay.
> >
>
On Thursday 23 March 2006 20:43, Chris Bainbridge wrote:
> On 23/03/06, Rumen Yotov <[EMAIL PROTECTED]> wrote:
> > Hi,
> > Using a remote overlays is rather simple, just do "emerge layman".
> > Read the einfo and then "man layman".
> > It works flawlessly, just tested this with one remote overlay.
On 3/23/06, Daniel Ostrow <[EMAIL PROTECTED]> wrote:
> You can't have it both ways, either they are wholey Unofficial and do not get
> tracked in bugzilla at all (something which would have to be made VERY clear
> to our users, e.g. a you use it you get to keep the pieces policy, and the
> develope
On Thu, 2006-03-23 at 13:55 -0500, Chris Gianelloni wrote:
> I'm sorry, but I am not OK with just standing by and watching us give
> complete access to do anything with no accountability. If you are,
> perhaps you really need to rethink your commitment to our users and your
> fellow developers.
On Thursday 23 March 2006 13:57, Jakub Moc wrote:
> Ciaran McCreesh wrote:
> > On Thu, 23 Mar 2006 19:31:24 +0100 "Stefan Schweizer"
> >
> > <[EMAIL PROTECTED]> wrote:
> > | What about if we just skip your "policies" and let the overlays be a
> > | free place where people can handle issues how they
On Thu, 2006-03-23 at 19:31 +0100, Stefan Schweizer wrote:
> On 3/23/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote:
> > Think about it this way, what if we had two competing products in the
> > tree that do the same thing, with the same file names? We would add a
> > blocker, no? So what mechani
Ciaran McCreesh wrote:
> On Thu, 23 Mar 2006 19:31:24 +0100 "Stefan Schweizer"
> <[EMAIL PROTECTED]> wrote:
> | What about if we just skip your "policies" and let the overlays be a
> | free place where people can handle issues how they think it is right
> | for the specific case and not how $super_
On 23/03/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote:
> On Thu, 2006-03-23 at 16:40 +, Chris Bainbridge wrote:
> > If the software a user wants is in an overlay, then the user will be
> > forced to install the overlay.
>
> It shouldn't be in the overlay, is I think the point many are trying
On 23/03/06, Rumen Yotov <[EMAIL PROTECTED]> wrote:
> Hi,
> Using a remote overlays is rather simple, just do "emerge layman".
> Read the einfo and then "man layman".
> It works flawlessly, just tested this with one remote overlay.
> Beside that "man layman" explains pretty much of it's innerwork.
On Thu, 23 Mar 2006 19:31:24 +0100 "Stefan Schweizer"
<[EMAIL PROTECTED]> wrote:
| What about if we just skip your "policies" and let the overlays be a
| free place where people can handle issues how they think it is right
| for the specific case and not how $super_dev said somewhere. That is
| wha
On 3/23/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote:
> Think about it this way, what if we had two competing products in the
> tree that do the same thing, with the same file names? We would add a
> blocker, no? So what mechanism is there to ensure that there's no
> "blocking" issues between a
On Thu, 2006-03-23 at 16:40 +, Chris Bainbridge wrote:
> On 23/03/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote:
> > On Thu, 2006-03-23 at 14:41 +, Stuart Herbert wrote:
> > > Your nightmare scenario seems unavoidable. Enabling per-overlay bug
> > > tracking doesn't stop users posting bug
On Thursday 23 March 2006 19:16, Duncan wrote:
> Chris Bainbridge posted <[EMAIL PROTECTED]>,
>
> excerpted below, on Thu, 23 Mar 2006 12:47:13 +:
> > Adding the ebuilds to overlays is one option, but
> > then other users will be expected to find an overlay with their
> > package in, and then
On Thu, 2006-03-23 at 15:51 +, Stuart Herbert wrote:
> On 3/23/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote:
> > I see no problem with providing these sorts of overlays to
> > bridge the gap between contributing users and developers. I *do* see a
> > problem with simply allowing random overl
Chris Gianelloni wrote:
> I wouldn't mind seeing an actual "unstable" designation added to
> KEYWORDS. The basic premise would be like package.mask packages where
> things can be done *within the tree* but still has the same air of "this
> might be totally busted at some point" as overlays. Users
Chris Bainbridge posted <[EMAIL PROTECTED]>,
excerpted below, on Thu, 23 Mar 2006 12:47:13 +:
> Adding the ebuilds to overlays is one option, but
> then other users will be expected to find an overlay with their
> package in, and then add it to make.conf.
... This hints at something I wasn'
Chris Bainbridge wrote:
> Another thing that some people may not have considered - with many
> developers using various permutations of overlays, how can you
> guarantee that what is being checked into the main tree will build for
> a normal user? In order to test that, a developer would have to
>
On 23/03/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote:
> On Thu, 2006-03-23 at 14:41 +, Stuart Herbert wrote:
> > Your nightmare scenario seems unavoidable. Enabling per-overlay bug
> > tracking doesn't stop users posting bugs in bugzilla. It just causes
> > confusion for users, because the
On Thu, 23 Mar 2006 10:31:40 -0500
Chris Gianelloni <[EMAIL PROTECTED]> wrote:
> > Your nightmare scenario seems unavoidable. Enabling per-overlay bug
> > tracking doesn't stop users posting bugs in bugzilla. It just
> > causes confusion for users, because they're not sure where to go.
> > Norma
On 3/23/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote:
> I see no problem with providing these sorts of overlays to
> bridge the gap between contributing users and developers. I *do* see a
> problem with simply allowing random overlays from any developer for
> anything.
That's a reasonable point
On Thu, 2006-03-23 at 14:41 +, Stuart Herbert wrote:
> Hi Chris,
>
> On 3/23/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote:
> > If some random developer goes out there and creates his own fork of
> > catalyst in his overlay, I sure don't want to receive a *single* bug on
> > it. Ever.
>
> Y
Chris Gianelloni wrote:
> On Wed, 2006-03-22 at 22:03 +, Stuart Herbert wrote:
>> To answer Daniel's other question, about bugs.g.o ... trac on
>> overlays.g.o will have its bug tracking system disabled. We already
>> have one bug tracking system - bugs.g.o - and that's sufficient.
>
> Umm...
I personally think this is a bad idea. I can understand and support
links to different overlay repositories, however I do not think that
gentoo should host or support overlays on its own infrastructure. For
one thing supporting overlays on our infrastructure looks like we are
supporting broken eb
On Thu, 2006-03-23 at 10:09 +, Chris Bainbridge wrote:
> Reduced responsibility for package QA (I expect "we don't care about
> overlays" to become a standard response on bugs.g.o)
You will *definitely* get this from developers that won't be using the
overlays.
Let's just say you decide to u
Hi Chris,
On 3/23/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote:
> If some random developer goes out there and creates his own fork of
> catalyst in his overlay, I sure don't want to receive a *single* bug on
> it. Ever.
Your nightmare scenario seems unavoidable. Enabling per-overlay bug
track
On Wed, 2006-03-22 at 22:03 +, Stuart Herbert wrote:
> To answer Daniel's other question, about bugs.g.o ... trac on
> overlays.g.o will have its bug tracking system disabled. We already
> have one bug tracking system - bugs.g.o - and that's sufficient.
Umm... no?
If some random developer go
Hi Chris,
On 3/23/06, Chris Bainbridge <[EMAIL PROTECTED]> wrote:
> Developers are using overlays, however, the majority of users aren't.
True. But does that have to be the audience for overlays?
> If the usage of overlays is to increase, then remote overlay support
> should be added to emerge.
On 23/03/06, Stuart Herbert <[EMAIL PROTECTED]> wrote:
> Developers are already using overlays, and some teams (including ones
> I've been involved in) are actively and successfully using them to
> help with recruitment and to provide a way to access ebuilds that
> would otherwise still be rotting
> But it seems rather artificial to me, and I suspect some devs might
> enjoy contributions to their non-topical overlays.
It *is* artificial; that's fair critisism. I have a personal bias
towards projects. I'll withdraw the distinction.
So, to be clear: the owners of an overlay (the leads for
Stuart Herbert wrote:
> The confusion is probably because, in the original vision statement, I
> said that these things would only happen for overlays setup by, and
> for, official projects. I wanted a disctinction between who could
> commit to overlays run by projects, and who could commit to ove
Hi Donnie,
On 3/23/06, Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> I don't think I'm understanding your intent here, because I've read
> things two different ways. My main goal is to allow easy contribution by
> non-devs, via allowing them to commit directly to some overlay. How is
> that possibl
Hi Chris,
On 3/23/06, Chris Bainbridge <[EMAIL PROTECTED]> wrote:
> I think that the
> use of overlays is more a symptom of a problem with portage. Overlay
> problems:
[snip]
Developers are already using overlays, and some teams (including ones
I've been involved in) are actively and successfull
Stuart Herbert wrote:
> On 3/23/06, Donnie Berkholz <[EMAIL PROTECTED]> wrote:
>> Stuart Herbert wrote:
>>> Developer overlays would only be created for active Gentoo developers,
>>> and they would be accountable for its contents. Non-developers will
>>> not be given write access to developer over
Hi Luis,
On 3/23/06, Luis Medinas <[EMAIL PROTECTED]> wrote:
> I agree with the wiki because it seems to be an easy way to users and
> developers comunicate together and work. Like i said a few months ago
> the documentation won't give any problems to GDP since GDP provides high
> level docs. The
On 23/03/06, Stuart Herbert <[EMAIL PROTECTED]> wrote:
> > > The vision I have for overlays.g.o is one official home for all Gentoo
> > > overlays run by projects and by individual Gentoo devs. I see the
> > Also for Arch/Herd Testers?
The discussion seems to have moved from the original "how can
On 3/23/06, Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> Stuart Herbert wrote:
> > Developer overlays would only be created for active Gentoo developers,
> > and they would be accountable for its contents. Non-developers will
> > not be given write access to developer overlays.
>
> This removes mu
Stuart Herbert wrote:
> Developer overlays would only be created for active Gentoo developers,
> and they would be accountable for its contents. Non-developers will
> not be given write access to developer overlays.
This removes much of the motivation for merging overlays to o.g.o, at
least some
On Wed, 2006-03-22 at 22:03 +, Stuart Herbert wrote:
> I'd like to offer two wiki engines and two version control systems on
> overlays.g.o. I believe that gives us enough choice without us
> loading the box with too much software for us to keep on top of.
>
> One thing that was never planned
Hi Danny,
On 3/23/06, Danny van Dyk <[EMAIL PROTECTED]> wrote:
> Hi Stuart,
>
> I'd like to comment on some of your plans for overlays.g.o.
:)
> > The vision I have for overlays.g.o is one official home for all Gentoo
> > overlays run by projects and by individual Gentoo devs. I see the
> Also
On Thursday 23 March 2006 06:38, Greg KH wrote:
> > i know last time i upgraded, the evdev driver was broken to crap anyways
> > ;)
> The evdev kernel driver, or evdev X driver?
Talking about X driver I suppose...
And I think I sort of know what's the big issue there... scancodes given by X
are d
Hi Stuart,
I'd like to comment on some of your plans for overlays.g.o.
Am Mittwoch, 22. März 2006 23:03 schrieb Stuart Herbert:
> It's probably the right time for me to flesh out what I've been
> planning for overlays.g.o.
>
> The vision I have for overlays.g.o is one official home for all Gentoo
64 matches
Mail list logo
