Mailing List Archive

On Thu, 22 Feb 2007 05:26:56 -0800 Brian Harring <ferringb@gmail.com>
wrote:
| > | Seriously? Without an implementation, your spec of what should
| > | happen will have loads of errors?
| >
| > Yes. It will describe what people think is allowed, rather than what
| > really is.
|
| If you're writing the spec to match what "people think", why limit
| the # of folks involved?

You're reading that backwards.

| > b) they're more interested in replacing
| > the ebuild format
|
| Pure and absolute FUD; recall which project has added incompatible
| version extensions

Which are optional

| which is dropping running *rm when reinstalling the same ver

We haven't done that in trunk/ for a while now.

| which *still* doesn't actually implement overlay logic,

Sure we do.

| leading to overlay authors having to copy master files into each
| overlay branch.

Uh, no.

| Doing it formally, I hereby request access to PMS specifically with
| the intention of going over it to spot where it differs from long
| standing portage behaviour.

And as you know all too well, given your behaviour on every previous
discussion we've had related to this, you're not getting it.

| > | a portage dev such as zmedico
| >
| > We have a Portage dev reviewing it.
|
| Which, if I may ask? (vague specifics help no one). Zmedico,
| indicated above isn't (although perhaps you're just being coy, and he
| is). Genone isn't ever around, bit hard for him to be doing it.
| Stubbs is mia, kito/exg are both MIA afaik (additionally, prefix
| specific although both have a pretty good understanding of env
| requirements due to changing it for the prefix experiment- same goes
| for grobian despite not being an official portage monkey).
|
| That leaves spanky, and antarus, who you specifically contradict
| within the email.
|
| So... which?

Genone.

| > > and Gianelloni for the infrastructure.
| >
| > And what on earth do infrastructure have to do with a package
| > manager specification?
|
| Wolf31o2 (chris) is releng moreso; one of the few folks doing
| non-trivial things with the profiles pretty much, with long term
| experience doing so.
|
| In that regard, he's one of a few handful of people who basically
| could be considered profile experts- further, he's a catalyst monkey,
| which at least currently, is the stage building method.

Which I know fine well, and which has no relevance to what I said.

| For example, dismissing Chris when he's effectively the "profiles
| guy". Granted, can involve him afterwards, but don't much see the
| point in *not* doing it up front.

Just where did I dismiss Chris?

--
Ciaran McCreesh
Mail : ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis, the secure package manager : http://paludis.pioto.org/

On Thu, 22 Feb 2007 17:10:38 +0100
Marien Zwart <marienz@gentoo.org> wrote:

> The
> idea was to not get any messy portage quirks documented as required
> standard behaviour, the risk here is that we'll now get paludis quirks
> documented as required standard behaviour.

Well, that'll come out in review later, I would expect. I'll be
surprised if the EAPI=0 spec Ciaran et. al. are working on just gets
rubber-stamped without anyone looking! This thread shows there are a
number of people who know what they're talking about and will review it
heavily when it is published as a draft, and the council are unlikely
to approve something that doesn't have broad support.

With respect to having a small relatively closed group for initial
drafting - it's a sensible way to do things in the early stages (it's
not the only sensible way of course). If anyone doesn't like it,
there's nothing stopping them from drafting their own in a different
way. Indeed, having two strong drafts would be good, for finding
idiosyncrasies from different perspectives.

I have to say, the few queries I've seen from Ciaran have been exactly
what I would (happily) expect. Queries about whether some current
portage behaviours should be classed as quirks or EAPI=0 behaviour,
presumably because the answer has a large impact on the design of a
package manager. A good example is the recent one about whether EAPI=0
should require that the ebuild be sourced in every phase or only once.

--
Kevin F. Quinn

On Thu, 22 Feb 2007 17:10:38 +0100 Marien Zwart <marienz@gentoo.org>
wrote:
| I am a bit unsure about what the goal for PMS is here. It does not
| seem to be to document what a certain (the current?) version of
| portage does, as the defacto standard. Instead you want to document
| what portages *intention* is, or something like that.

The aim is to document things that Portage does intentionally, along
with things that Portage does unintentionally if that behaviour is
required by a lot of the tree, whilst excluding things that are
clearly Portage bugs.

Which is, of course, not entirely quantifiable, rather vague and a pain
in the ass to get right, which is another reason that it helps that
everyone currently writing PMS is more or less on the same page in
terms of what gets documented.

--
Ciaran McCreesh
Mail : ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis, the secure package manager : http://paludis.pioto.org/

On Thu, 22 Feb 2007 17:10:38 +0100
Marien Zwart <marienz@gentoo.org> wrote:

> I am a bit unsure about what the goal for PMS is here. It does not
> seem to be to document what a certain (the current?) version of
> portage does, as the defacto standard. Instead you want to document
> what portages *intention* is, or something like that. That obviously
> sounds like an excellent idea, but as far as I know most of the PMS
> contributors are also Paludis devs. Paludis, being an alternative to
> portage, is *also* trying to handle ebuilds the way portage is
> "intended" to handle them. So what I'm afraid of is that "by the time
> that Paludis 1.0_pre is released" we will simultaneously see PMS
> released to the public, and Paludis 1.0_pre supporting that PMS
> perfectly, with all deviations on the part of portage (or pkgcore)
> being considered "bugs" in their implementation of the specification.

The intention is much as you initially surmised -- to describe
portage's intended behaviour, or perhaps more accurately that subset of
Portage's current behaviour which ebuilds and eclasses upon which are
allowed to rely. Certainly by the time it is finished and sent to the
Council for approval I expect whatever is the current Portage release
to be compatible, and in most cases where I've deviated thus far from
what Portage allows or does I've asked the current portage team whether
it seems reasonable to do so.

In some cases there are ebuilds in the tree relying upon behaviour that
is not specified by PMS, or intended to be. These are the cases where
only one or two packages rely upon undocumented and often unintentional
by-products of Portage behaviour, and it seems more sensible to fix
those few ebuilds instead of adding a lot of compatibility junk to the
standard. A good example of this would be the recent -dev thread on
global ebuild variables and pkg_setup.
--
gentoo-dev@gentoo.org mailing list

On Thu, Feb 22, 2007 at 06:42:39PM +0100, Kevin F. Quinn wrote:
> On Thu, 22 Feb 2007 17:10:38 +0100
> Marien Zwart <marienz@gentoo.org> wrote:
>
> > The
> > idea was to not get any messy portage quirks documented as required
> > standard behaviour, the risk here is that we'll now get paludis quirks
> > documented as required standard behaviour.
>
> Well, that'll come out in review later, I would expect. I'll be
> surprised if the EAPI=0 spec Ciaran et. al. are working on just gets
> rubber-stamped without anyone looking! This thread shows there are a
> number of people who know what they're talking about and will review it
> heavily when it is published as a draft, and the council are unlikely
> to approve something that doesn't have broad support.

I'd like to add some emphasis on "when it is published as a draft".
What makes me uncomfortable is that the intention seems to be to
release that draft simultaneously with the Paludis 1.0_pre mentioned
earlier, which is rather a lot later than I'd like to see it.

> With respect to having a small relatively closed group for initial
> drafting - it's a sensible way to do things in the early stages (it's
> not the only sensible way of course).

In the early stages: agreed. I just hope it will not be developed up
to "release candidate" status with little external (from non-Paludis
devs) input.

> If anyone doesn't like it,
> there's nothing stopping them from drafting their own in a different
> way. Indeed, having two strong drafts would be good, for finding
> idiosyncrasies from different perspectives.

If I considered myself qualified and had a lot of spare time I would
have started doing that by now :)

> I have to say, the few queries I've seen from Ciaran have been exactly
> what I would (happily) expect.

Yes, the *few* queries I've seen were ok. Perhaps there is simply much
less there yet than I think there is.

--
Marien.

Am Donnerstag, 22. Februar 2007 17:41 schrieb Brian Harring:
> On Thu, Feb 22, 2007 at 05:07:22PM +0100, Danny van Dyk wrote:
> > Am Donnerstag, 22. Februar 2007 14:26 schrieb Brian Harring:
> > > On Thu, Feb 22, 2007 at 04:13:11AM +0000, Ciaran McCreesh wrote:
> > > > On Thu, 22 Feb 2007 04:04:37 +0000 Steve Long
> > > >
> > > > <slong@rathaus.eclipse.co.uk> wrote:
> > > > | In process terms, I can't understand why the team working on
> > > > | it isn't a pkgcore dev (eg marienz if you can't communicate
> > > > | with ferringb)
> > > >
> > > > b) they're more interested in replacing
> > > > the ebuild format
> > >
> > > Pure and absolute FUD; recall which project has added
> > > incompatible version extensions, which is dropping running *rm
> > > when reinstalling the same ver, which *still* doesn't actually
> > > implement overlay logic, leading to overlay authors having to
> > > copy master files into each overlay branch.
> >
> > Please have a look at our code before you make such claims.

I meant the overlay logic, and my share of this discussion is still
down the mail. Yet you discussed things I didn't even remotely mention.

> Further, getting away from the daft FUD we're trying to 'replace the
> ebuild format' that was leveled.
>
> > Also have a look at our statements regarding overlays again.
> > Overlays can't be configure properly. Multiple repositories can.
> > Nobody says there should be no sharing between them, but it needs
> > to be configured by the user.
>
> master_repository is a new one added within the last two weeks;
> stand corrected.
Repository defaults have been in a little bit longer I think.
<looking up>
2007-01-26 Ciaran McCreesh <ciaranm@ciaranm.org>
* doc/configuration.html.skel,
paludis/environment/default/default_config.cc,
paludis/util/collection.hh, paludis/util/collection_concrete.hh: Add
support for a repository_defaults.conf file.

There we go.

> > > > And what on earth do infrastructure have to do with a package
> > > > manager specification?
> > >
> > > Wolf31o2 (chris) is releng moreso; one of the few folks doing
> > > non-trivial things with the profiles pretty much, with long term
> > > experience doing so.
> > >
> > > In that regard, he's one of a few handful of people who basically
> > > could be considered profile experts- further, he's a catalyst
> > > monkey, which at least currently, is the stage building method.
> >
> > He said there would be no need for infrastructure to be involved; a
> > claim i back. Nobody said Chris shouldn't be involved
>
> <snip>
>
> > Read again, he did not dismiss Chris, he dismissed the claim that
> > Infrastructure should send somebody to discuss the package manager
> > standard.

> SRC_URI restrictions (port, protocol, etc) are one angle of why at
> least poking them matters- really depends upon what PMS is going to
> address, standalone spec, or gentoos form- if the latter, then
> port/protocol restrictions apply, if the former then those
> restrictions need to wind up somewher as an extension of the spec.
What has that to do with the PMS? PMS doesn't talk about how mirrors
should work or how to stage files. It's a spec for the package manager.

What you are talking about are implementation details, and even those
which are only remotely related to how the package manager handles
stuff. This matters once we should ever start writing a Gentoo
Distribution Backstage Spec.

> Re: dismissing chris being seperate from dismissing infra, yep,
> misinterpretted the phrasing- still would suggest hauling in one of
> the actual profile/catalyst monkeys however since some of the stuff
> they have in there aren't well documented.
s/well//. And I don't think that anything or anyone speaks or spoke
against Chris getting access to PMS and commenting on it. And to
reiterate: this holds true for all council members.

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

On Thu, Feb 22, 2007 at 08:11:34PM +0100, Danny van Dyk wrote:
> Am Donnerstag, 22. Februar 2007 17:41 schrieb Brian Harring:
> > Further, getting away from the daft FUD we're trying to 'replace the
> > ebuild format' that was leveled.
> >
> > > Also have a look at our statements regarding overlays again.
> > > Overlays can't be configure properly. Multiple repositories can.
> > > Nobody says there should be no sharing between them, but it needs
> > > to be configured by the user.
> >
> > master_repository is a new one added within the last two weeks;
> > stand corrected.
> Repository defaults have been in a little bit longer I think.
> <looking up>
> 2007-01-26 Ciaran McCreesh <ciaranm@ciaranm.org>
> * doc/configuration.html.skel,
> paludis/environment/default/default_config.cc,
> paludis/util/collection.hh, paludis/util/collection_concrete.hh: Add
> support for a repository_defaults.conf file.
>
> There we go.

master_repository is required for thirdpartymirrors, which was the
main stumbling block (and why folks were daftly copying
$PORTDIR/profiles/thirdpartymirror into the overlay); feature above
just enables avoiding boilerplate in the repostories/* definitions.


> > SRC_URI restrictions (port, protocol, etc) are one angle of why at
> > least poking them matters- really depends upon what PMS is going to
> > address, standalone spec, or gentoos form- if the latter, then
> > port/protocol restrictions apply, if the former then those
> > restrictions need to wind up somewher as an extension of the spec.
>
> What has that to do with the PMS? PMS doesn't talk about how mirrors
> should work or how to stage files. It's a spec for the package manager.

The point there was that of binding the gentoo specific restrictions
in somehow; whether y'all jam it into the spec itself (ick), or
shoving it into a seperate doc.


> What you are talking about are implementation details, and even those
> which are only remotely related to how the package manager handles
> stuff. This matters once we should ever start writing a Gentoo
> Distribution Backstage Spec.

Said spec covers profiles also; mentioning at least the existance of
the misc STAGE* settings isn't a horrible idea, even if not going into
detail- anyone digging through the profiles will see them, and likely
wonder why they're there, and why quite a few profiles specify an
extra set of use lists.

While writing the sucker out, I'd expect you'll come across things
where gentoo has a specific way of doing it, which isn't required by
the manager. The suggestion would be to track that somehow, or look
at mangling the devmanual so that it's just diffs against the spec.

Either way, the protocol/port bit was an idle, badly phrase
suggestion (in other words, take it or leave it).

~harring

(Everything here is meant to be educational, not really commenting on
anything else.)

On Thu, 2007-02-22 at 12:04 -0800, Brian Harring wrote:
> Said spec covers profiles also; mentioning at least the existance of
> the misc STAGE* settings isn't a horrible idea, even if not going into
> detail- anyone digging through the profiles will see them, and likely
> wonder why they're there, and why quite a few profiles specify an
> extra set of use lists.

Some of the stuff in profiles, such as STAGE1_USE, isn't used by the
package manager in any way. STAGE1_USE is used by nothing but catalyst,
and it does exactly what you think it does. It doesn't stack (that
might be something worth mentioning) but it is inherited.
GRP_STAGE23_USE hasn't been used in catalyst for a very long time.
Again, this was the only thing that actually used it.

Of course, I'm always willing to help anyone understand any aspects of
the profiles that might be in question. I can definitely tell you how
default-linux works. I tend to leave the hardened/embedded/uclibc stuff
alone, except where I am positive what I'm doing won't affect them
adversely.

> While writing the sucker out, I'd expect you'll come across things
> where gentoo has a specific way of doing it, which isn't required by
> the manager. The suggestion would be to track that somehow, or look
> at mangling the devmanual so that it's just diffs against the spec.

Well, the STAGE1_USE stuff you pointed out is a prime example. Also,
STAGE1_USE is *not* required. If it is empty, stage1 is built with
USE="build" and if it is actually populated, stage1 is built with
USE="build ${STAGE1_USE}".

As for USE, what I've been trying to do is the following:

default-linux - uhhh... defaults for all arches under Linux for releases

$arch - *very* generic USE additions for arch-specific stuff *only*

$relver - generic USE used to build the release... this would be the
equivalent of the old GRP_STAGE23_USE, since it is what stages 2 and 3
are built against

desktop/server - these are the massive USE that used to be in $relver
previously... since the stages aren't built against these, they can have
more stuff added to them without as harsh consequences... LiveCD-based
installs use the desktop profile for networkless installs

Essentially, as you go to the right down the stack, things get more
specific and adds more USE flags.

--
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

On Thu, 22 Feb 2007 12:04:58 -0800 Brian Harring <ferringb@gmail.com>
wrote:
| Said spec covers profiles also; mentioning at least the existance of
| the misc STAGE* settings isn't a horrible idea, even if not going
| into detail- anyone digging through the profiles will see them, and
| likely wonder why they're there, and why quite a few profiles specify
| an extra set of use lists.

Anything about STAGE* will be "package manager specific". The whole
concept of stages is basically a workaround for Portage limitations.

| While writing the sucker out, I'd expect you'll come across things
| where gentoo has a specific way of doing it, which isn't required by
| the manager. The suggestion would be to track that somehow, or look
| at mangling the devmanual so that it's just diffs against the spec.

The devmanual and PMS are two entirely different things. Think of the
devmanual as "The C++ Programming Language" plus "The C++ Standard
Library" and PMS as "ISO/IEC 14882:2003".

--
Ciaran McCreesh
Mail : ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis, the secure package manager : http://paludis.pioto.org/

On Thursday 22 February 2007, Ciaran McCreesh wrote:
> On Thu, 22 Feb 2007 04:04:37 +0000 Steve Long
>
> <slong@rathaus.eclipse.co.uk> wrote:
> | > I'm saying that until there is an independent implementation, the
> | > specification is worthless and will contain huge numbers of errors.
> |
> | Seriously? Without an implementation, your spec of what should happen
> | will have loads of errors?
>
> Yes. It will describe what people think is allowed, rather than what
> really is. Perfect example -- we'd never have caught the multiple
> sourcing issue without an independent implementation.

I'm sorry, but this was already a known issue over 3 years ago. And yes, the
way portage handles ebuilds does not necessarilly win any beauty contest.

Paul

--
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

On Thursday 22 February 2007, Ciaran McCreesh wrote:
> By that same argument, anybody who ever had to deal with abuse from bug
> wranglers wouldn't be using Gentoo. Which would mean a whooooole lot
> fewer users.

Grow up.

--
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

On Thu, 22 Feb 2007 22:35:59 +0100 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| On Thursday 22 February 2007, Ciaran McCreesh wrote:
| > On Thu, 22 Feb 2007 04:04:37 +0000 Steve Long
| > <slong@rathaus.eclipse.co.uk> wrote:
| > | > I'm saying that until there is an independent implementation,
| > | > the specification is worthless and will contain huge numbers of
| > | > errors.
| > |
| > | Seriously? Without an implementation, your spec of what should
| > | happen will have loads of errors?
| >
| > Yes. It will describe what people think is allowed, rather than what
| > really is. Perfect example -- we'd never have caught the multiple
| > sourcing issue without an independent implementation.
|
| I'm sorry, but this was already a known issue over 3 years ago. And
| yes, the way portage handles ebuilds does not necessarilly win any
| beauty contest.

Which isn't relevant to what I said. Had it not been for the
independent implementation, it would have remained "something that's
been known to be weird for years", and would not have been documented
or specified either way.

--
Ciaran McCreesh
Mail : ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis, the secure package manager : http://paludis.pioto.org/

On 2/22/07, Ciaran McCreesh <ciaranm@ciaranm.org> wrote:
> And if you want a perfect example of reverting to ad hominem rather
> than technical discussion, I suggest you reread your own email.

I did. I don't see any ad hominem attacks. I was very careful not to
say anything nasty.

Even assuming I am a hypocrite - philosophically speaking, I am sure
we are all hypocrites to a certain extent, yes? - this doesn't give
any of us permission to behave in flagrantly nasty ways over and over
again and not be called on it. That's the fallacy in your argument.

At this point, I am going to separate myself from this conversation
and wait to see what action is taken, if any.

Really, I think you are mis-using your debating skills, as you were
clearly in the wrong, and what you said was indefensible, so you
should have just apologized.

I tend to get pulled into these things because a) I care about Gentoo
and b) I don't like to see people get away with crap over and over
again by using cheap debating tricks. But I will cut myself off from
this thread now.

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

If that, what you stated in your last three paragraphs - and I do agree with
it - will be the case, this proposed PMS will be dismissed and Paludis
remains with a more or less accurate description, of what isn't a Gentoo
package manager.


Carsten

On Sun, 25 Feb 2007 18:51:51 +0000
Steve Long <slong@rathaus.eclipse.co.uk> wrote:

> Like I said, tho, I'm happy if the council is. Although I'm starting to
> worry at the increasingly poisonous atmosphere, and that devs are leaving.
> Flameeyes was on the council, no? It concerns me that this atmosphere is
> just intimidating people simply because no one feels confident to stand up
> to abusive bullying.

Diego left because he was simply burnt out, as suggested by his many blog
posts.

As for the poisonous atmosphere - I don't know, I feel very good among the
developers, and am still enjoying working on the tree just like on the day I
joined. Don't let few loud flamers ruin your day.

Kind regards,
--
Andrej "Ticho" Kacian <ticho at gentoo dot org>
Gentoo Linux Developer - net-mail, antivirus, sound, x86

On Sun, 25 Feb 2007 18:51:51 +0000
Steve Long <slong@rathaus.eclipse.co.uk> wrote:

> And irrespective
> of whether bug-wranglers have much to say, I'd still want them
> involved, as they deal with the ebuild bugs. As such they could well
> have ideas or viewpoints which would help. Even if they don't, it's
> how I'd do it for any software development project- not having
> testing/ QA/ bug fixers involved would leave me uneasy.

bug-wranglers don't really have much to do with QA, their main job is
just to assign bugs to the right people, and that doesn't have
anything to do with a package manager specification (at most you could
argue about the metadata.xml format, but even that is a long shot).

> I don't buy the stuff about needing the so-called independent
> implementation sorry. ``What people think is allowed rather than what
> is?'' The spec defines what is allowed. Period.

Thing is that if you only have a single implementation it's much easier
for errors to slip by due to implicit assumptions. Unless you write a
full compliance testsuite ...

> And that still leaves the issue of EAPI 0 being the preexisting
> implementation. What exactly is so wrong with that?

Which implementation exactly? Portage isn't frozen, the behavioris more
less constantly changing. Another issue are the things that just work by
accident or only exist for legacy reasons, you don't really want those
in a formal spec aimed at future developments.
Also in general it's easier to extend a spec than to restrict it later
on, no matter what the spec is about.

Marius

--
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

Steve Long wrote:
> Andrej Kacian wrote:
>> As for the poisonous atmosphere - I don't know, I feel very good among the
>> developers, and am still enjoying working on the tree just like on the day
>> I joined. Don't let few loud flamers ruin your day.
>>
> Thanks for that Andrej. Makes me feel much better :)

FWIW, I was sad to see flameeyes retire, but it's clear that wasn't a
spur of the moment decision.

I have had great experiences working with many developers, including
getting some constructive criticism at times (hi, dev-zero!). Overall,
I have found the atmosphere in IRC and elsewhere quite pleasant.

Thanks,
Marty
--
gentoo-dev@gentoo.org mailing list

On Sun, 25 Feb 2007 18:51:51 +0000
Steve Long <slong@rathaus.eclipse.co.uk> wrote:

> Um I put it badly, sorry (i've had the flu) - I meant Chris in his
> capacity of releng, catalyst etc. You only want to review, np. ++ to
> moving ahead.

And if he'd like to do so, I'll be happy to give him access to it.

> The PMS will presumably be the definitive statement of what should
> happen for *all* gentoo PMs, and it so happens that the people who
> are doing it are mostly paludis devs, and sorry it won't be ready til
> Paludis is. pfft.

Noone said that. At present the only people working on it are also
working on Paludis, but that can change should people take an interest.
As for "it won't be ready til Paludis is", that's not what was stated
-- what ciaranm said was that his personal priority will switch to
getting PMS finished once paludis is ready. That doesn't mean that
other people can't work on it and finish it before that, and I for one
currently have PMS above Paludis on my priorities list and don't intend
to wait for the latter.
--
gentoo-dev@gentoo.org mailing list

Brian Harring wrote:
> Offhand, if the council (majority, no offense meant but not just
> one council member who is also a paludis dev) is happy with the state
> of things and timelines, then I'll gladly retract the request.
>
Is this the case; are the majority of the council happy?

--
gentoo-dev@gentoo.org mailing list

Ciaran McCreesh wrote:
> | Are you really saying that you won't be releasing this information
> | until such time as *Paludis* meets it, even though portage/pkgcore
> | may not? Isn't the *point* of this spec to try to bring everyone on
> | the same page?
>
> I'm saying that until there is an independent implementation, the
> specification is worthless and will contain huge numbers of errors.

Seriously? Without an implementation, your spec of what should happen will
have loads of errors?

> This is standard practice for professional standards, and is the
> principal difference between, say, Open Document Format and Office Open
> XML -- the former is a real standard, whereas the latter is a
> description of how one program operates.
>
> Now, if PMS happens to end up being ready before Paludis 1.0, PMS will
> get released before then. But if Paludis 1.0 ends up being ready before
> PMS, my and probably others' priorities will switch to getting PMS
> ready as quickly as sanely possible.
>
Clearly you are more concerned about getting Paludis ready. spb has other
priorities, fair enough, but this is something that seems fairly important
for gentoo as a whole.

In process terms, I can't understand why the team working on it isn't a
pkgcore dev (eg marienz if you can't communicate with ferringb), a portage
dev such as zmedico, yourself from paludis and say antarus from
treecleaners. I'd add in someone like jakub or spanky from bug wranglers
and Gianelloni for the infrastructure. Having it all from one set of devs
(paludis) is like having w3c standards written by one company.


--
gentoo-dev@gentoo.org mailing list

Chris Gianelloni wrote:
> On Thu, 2007-02-22 at 04:13 +0000, Ciaran McCreesh wrote:
>> | and Gianelloni for the infrastructure.
>>
>> And what on earth do infrastructure have to do with a package manager
>> specification?
>
> Especially considering that I am not an infrastructure guy. I'll be
> honest. I'm not concerned personally with the *contents* of the package
> manager specification, since I know it will end up being reviewed by
> many. What I am mostly concerned with is making sure that we're moving
> forward as efficiently as possible. I want this spec so we can all get
> cracking on making everything support it. The contents itself I leave
> to more capable hands. I'll be reviewing it when it is released, but
> that's only just to assist in the process.
>
Um I put it badly, sorry (i've had the flu) - I meant Chris in his capacity
of releng, catalyst etc. You only want to review, np. ++ to moving ahead.

And yeah, ferringb had it right- it was about having several perspectives on
this rather than just paludis devs. And irrespective of whether
bug-wranglers have much to say, I'd still want them involved, as they deal
with the ebuild bugs. As such they could well have ideas or viewpoints
which would help. Even if they don't, it's how I'd do it for any software
development project- not having testing/ QA/ bug fixers involved would
leave me uneasy.

The PMS will presumably be the definitive statement of what should happen
for *all* gentoo PMs, and it so happens that the people who are doing it
are mostly paludis devs, and sorry it won't be ready til Paludis is. pfft.

I don't buy the stuff about needing the so-called independent implementation
sorry. ``What people think is allowed rather than what is?'' The spec
defines what is allowed. Period.

Further, I don't recollect any discussion about needing an independent
implementation when this was first mooted, and spb took it on. Or am I
wrong- was it in fact understood that the spec would need paludis before it
could be considered correct?

And that still leaves the issue of EAPI 0 being the preexisting
implementation. What exactly is so wrong with that?

Like I said, tho, I'm happy if the council is. Although I'm starting to
worry at the increasingly poisonous atmosphere, and that devs are leaving.
Flameeyes was on the council, no? It concerns me that this atmosphere is
just intimidating people simply because no one feels confident to stand up
to abusive bullying.

Personally, I'd like to see ferringb and zmedico's take on what the PMS
should be. (Not that they want to do it.) I sincerely doubt it would take
them anything like as long ;)

BTW if i preface a statement with `personally' that means it's just my gut
feeling. It doesn't mean that I think it /has/ to be done like that. Sorry
to explain the obvious..


--
gentoo-dev@gentoo.org mailing list

Andrej Kacian wrote:
> As for the poisonous atmosphere - I don't know, I feel very good among the
> developers, and am still enjoying working on the tree just like on the day
> I joined. Don't let few loud flamers ruin your day.
>
Thanks for that Andrej. Makes me feel much better :)


--
gentoo-dev@gentoo.org mailing list

Stephen Bennett wrote:
> On Sun, 25 Feb 2007 18:51:51 +0000
> Steve Long <slong@rathaus.eclipse.co.uk> wrote:
>> The PMS will presumably be the definitive statement of what should
>> happen for *all* gentoo PMs, and it so happens that the people who
>> are doing it are mostly paludis devs, and sorry it won't be ready til
>> Paludis is. pfft.
>
> Noone said that. At present the only people working on it are also
> working on Paludis, but that can change should people take an interest.
> As for "it won't be ready til Paludis is", that's not what was stated
> -- what ciaranm said was that his personal priority will switch to
> getting PMS finished once paludis is ready. That doesn't mean that
> other people can't work on it and finish it before that, and I for one
> currently have PMS above Paludis on my priorities list and don't intend
> to wait for the latter.
>
Glad to hear it :D

Ciaran did say the spec was worthless without Paludis. Still as long as it's
coming..


--
gentoo-dev@gentoo.org mailing list

Marius Mauch wrote:
>> And that still leaves the issue of EAPI 0 being the preexisting
>> implementation. What exactly is so wrong with that?
>
> Which implementation exactly? Portage isn't frozen, the behavioris more
> less constantly changing. Another issue are the things that just work by
> accident or only exist for legacy reasons, you don't really want those
> in a formal spec aimed at future developments.
>
Sure, the moving target thing was worrying me too. But ciaran has actually
said that it'll be basically what portage should be doing atm (ie ignoring
bugs.)

I don't see what's wrong with documenting legacy behaviour, so long as it is
marked as such, or is in a legacy doc- not the spec used for future dev.
But still, this is all moot as the work is in hand.

> Also in general it's easier to extend a spec than to restrict it later
> on, no matter what the spec is about.
>
No argument there.

--
gentoo-dev@gentoo.org mailing list