Re: [gentoo-dev] Arches marking ebuilds stable before maintainer

Re: [gentoo-dev] Arches marking ebuilds stable before maintainer

[Jon Hood]

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

On Sun, 2004-06-20 at 09:36, foser wrote:
> > > You skip things around. It is not the 'maintainers arch' that is QA-ing
> > > for an arch it does not maintain, it's the 'arch maintainer' thats skips
> > > part of QA done by the 'package maintainer'.
> > 
> > Examples?

net-p2p/mldonkey- I refuse to mark >2.5.16 stable because of numerous
bug reports and stability problems with the newer versions (though the
latest version in portage does seem a bit more stable). Completely
ignoring this, those versions are on the "stable on hppa". It's not a
majorly critical package, but it is an example of the QA done by the
maintainer, and the arch maintainer going beyond it. I don't mind much,
because I have yet to get a bug report from an hppa user, but I would
have prefered to keep it all testing until for at least another month.

-Jon

-- 
AIM: Squinky01
Yahoo!: Squinky86
ICQ: 160940989
Jabber: squinky86@im.gentoo.org

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

[gentoo-dev] Re: [gentoo-core] From [gentoo-dev] Arches marking ebuilds stable before maintainer

[foser]

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

From -core, please stop crossposting it.

On Sat, 2004-06-19 at 21:17 +0100, Ciaran McCreesh wrote:
> | It is my personal opinion that package maintainers should have the
> | word on when something is stable.
> 
> We are not Debian. Arch teams *must* be allowed to override package
> maintainers *where necessary*.

Not without discussion without the maintainer . I never said this can't
happen, i just said that it can't happen without the maintainer being in
the known. Actually this is better for all arches involved.

Anyway, do not compare us to another distro to make your point, I hope
we can come to decisions without the need to resort to such polarizing
arguments. We're not Debian.

> This isn't a case of arch maintainers being irresponsible and going
> around keywording all sorts of broken packages. Arch teams do not
> usually go around overriding package maintainers, and where there is
> any doubt the relevant maintainers are contacted first.

Arch maintainer show and have shown in the past they don't know
everything about a package and thats nothing more than logical. There's
only one conclusion you can draw from that, that arch maintainers should
be heading the direction the package maintainer gives them.

> For those of you who missed it the first three times, *the current
> system works*.

This is just not true, i've seen it break things & this will happen more
and more in the future. I've posted a recent example on -dev already, so
I don't even know why you can still knowingly make this false statement.

> Oh, and since the skim readers will miss it otherwise, *the current
> system works*. Did everyone see that? *the current system works*. Works,
> the current system does. Le systeme courant marche deja. Die aktuelle
> Loesung funktioniert. Romanes eunt domus.

Read above. You disregard any information contradicting your line of
though, but this is nothing new.

The current system is a mix of what used to be and what some newer arch
devs think is a system that never existed in the first place. We should
come to a conclusion that the maintainers arch is the relevant arch if
it comes to marking stable.

- foser

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

Re: [gentoo-dev] Re: [gentoo-core] From [gentoo-dev] Arches marking ebuilds stable before maintainer

[Ciaran McCreesh]

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

On Sat, 19 Jun 2004 22:48:53 +0200 foser <foser@gentoo.org> wrote:
| > For those of you who missed it the first three times, *the current
| > system works*.
| 
| This is just not true, i've seen it break things & this will happen
| more and more in the future. I've posted a recent example on -dev
| already, so I don't even know why you can still knowingly make this
| false statement.

And as I recall, the example you provided was invalid, since a) the
packages in question weren't stable on mips anyway, and b) it fixed a
lot more than it broke. I'd also like to point out that we have a lot of
happy users running our stable trees, and that the *only* complaint
we've had regarding our keywording policies for sparc and mips came from
a developer who has absolutely nothing to do with the archs in question.
So, from the perspective of the people who actually use our trees, yes,
the system works.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] Re: [gentoo-core] From [gentoo-dev] Arches marking ebuilds stable before maintainer

[foser]

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

On Sat, 2004-06-19 at 22:11 +0100, Ciaran McCreesh wrote:
> On Sat, 19 Jun 2004 22:48:53 +0200 foser <foser@gentoo.org> wrote:
> | > For those of you who missed it the first three times, *the current
> | > system works*.
> | 
> | This is just not true, i've seen it break things & this will happen
> | more and more in the future. I've posted a recent example on -dev
> | already, so I don't even know why you can still knowingly make this
> | false statement.
> 
> And as I recall, the example you provided was invalid, since a) the
> packages in question weren't stable on mips anyway, and b) it fixed a
> lot more than it broke.

Well, you recall wrong :
a) obviously you don't know the situation, because this is not true
b) this is not true either

The example is valid.

>  I'd also like to point out that we have a lot of
> happy users running our stable trees, and that the *only* complaint
> we've had regarding our keywording policies for sparc and mips came from
> a developer who has absolutely nothing to do with the archs in question.

If it breaks, the maintainer gets the bugs, not the arch, because the
break wouldn't be arch specfic, but a general problem. That's the whole
point.

> So, from the perspective of the people who actually use our trees, yes,
> the system works.

Read above, this is not a valid assumption.

Actually, because we paid attention to it, it has not lead to any
serious treaths to stable arches trees. So if we let go and you do for
once suffer the consequences, this might still change, but I hope it
won't have to come that.

- foser

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

Re: [gentoo-dev] Re: [gentoo-core] From [gentoo-dev] Arches marking ebuilds stable before maintainer

[Jason Wever]

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

On Sat, 19 Jun 2004 23:32:44 +0200
foser <foser@gentoo.org> wrote:

> > So, from the perspective of the people who actually use our trees,
> > yes, the system works.
> 
> Read above, this is not a valid assumption.
> 
> Actually, because we paid attention to it, it has not lead to any
> serious treaths to stable arches trees. So if we let go and you do for
> once suffer the consequences, this might still change, but I hope it
> won't have to come that.

If this is truly the case, then why are the arch teams not notified? 
Isn't that exactly what we exist for?  And how can a package maintainer
then apply and QA a fix a problem for an architecture for which they
cannot test?  Also, who is "we"?

Before this turns into more mud slinging than it has, can everyone please
provide cases where they feel there is a problem (including bug reports if
possible) to back up your side of the argument.  Please try to be as
understanding and rational as you can.

Personally, I cannot see how having a package maintainer that cannot test
for a given architecture can provide any level of QA towards that
architecture without outside help.  Additionally, outsides of cases where
new versions or revisions cause problems with dependencies (or the usual
~arching of a new rev/version of a given package), package maintainers who
cannot test for a given architecture shouldn't be adjusting those
keywords.  Again these are just my feelings and not any form of policy
that I'm aware of.

Also, I don't see how having the arch teams and the package maintainers
telling each other they are stupid accomplishes anything.  If anything, it
works against what the original goal was (if we can even remember
anymore).  I think it should be little wonder to most folks why a lot of
developers don't participate in threads on this list if half of them
deteriorate to this level.

Perhaps if you are noticing yourself getting worked up over this you need
to take a break for a bit or find one of those nice vendor-provided
squishy things to throw/help calm yourself.  I know I occasionally find
myself in this position (particularly on this sort of topic) and notice I
get better results if I don't totally berate the people I'm trying to work
with. Yes I can definitely understand getting frustrated and how
there is a desire to lash out in those times, but what does it
truly accomplish? 

Granted between my past postings and my orkut pic everyone may not think
that I know how to be cordial but...:-P 

Keep on SPARCin',
-- 
Jason Wever
Gentoo/Sparc Team Co-Lead

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

Re: [gentoo-dev] Re: [gentoo-core] From [gentoo-dev] Arches marking ebuilds stable before maintainer

[foser]

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

On Sat, 2004-06-19 at 17:33 -0600, Jason Wever wrote:
> > Actually, because we paid attention to it, it has not lead to any
> > serious treaths to stable arches trees. So if we let go and you do for
> > once suffer the consequences, this might still change, but I hope it
> > won't have to come that.
> 
> If this is truly the case, then why are the arch teams not notified? 
> Isn't that exactly what we exist for?  And how can a package maintainer
> then apply and QA a fix a problem for an architecture for which they
> cannot test?  Also, who is "we"?

The arch teams are notified, but the same thing happens again and again
and that has to lead to this thread.
About your problem & fixing : that's the whole deal, it is general
issues that slip trough this way, so it's the package maintainers
responsibility.

> Personally, I cannot see how having a package maintainer that cannot test
> for a given architecture can provide any level of QA towards that
> architecture without outside help.  Additionally, outsides of cases where
> new versions or revisions cause problems with dependencies (or the usual
> ~arching of a new rev/version of a given package), package maintainers who
> cannot test for a given architecture shouldn't be adjusting those
> keywords.  Again these are just my feelings and not any form of policy
> that I'm aware of.

You skip things around. It is not the 'maintainers arch' that is QA-ing
for an arch it does not maintain, it's the 'arch maintainer' thats skips
part of QA done by the 'package maintainer'.

- foser

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

Re: [gentoo-dev] Re: [gentoo-core] From [gentoo-dev] Arches marking ebuilds stable before maintainer

[Jason Wever]

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

On Sun, 20 Jun 2004 01:59:41 +0200
foser <foser@gentoo.org> wrote:

> The arch teams are notified, but the same thing happens again and again
> and that has to lead to this thread.
> About your problem & fixing : that's the whole deal, it is general
> issues that slip trough this way, so it's the package maintainers
> responsibility.

Examples?
 
> You skip things around. It is not the 'maintainers arch' that is QA-ing
> for an arch it does not maintain, it's the 'arch maintainer' thats skips
> part of QA done by the 'package maintainer'.

Examples?

-- 
Jason Wever
Gentoo/Sparc Team Co-Lead

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

Re: [gentoo-dev] Re: [gentoo-core] From [gentoo-dev] Arches marking ebuilds stable before maintainer

[foser]

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

On Sat, 2004-06-19 at 18:17 -0600, Jason Wever wrote:
> > The arch teams are notified, but the same thing happens again and again
> > and that has to lead to this thread.
> > About your problem & fixing : that's the whole deal, it is general
> > issues that slip trough this way, so it's the package maintainers
> > responsibility.
> 
> Examples?

Numerous. in the gnome case recently gtk+, *mm packages, ORBit2 ... over
a longer period of time many more things.

> > You skip things around. It is not the 'maintainers arch' that is QA-ing
> > for an arch it does not maintain, it's the 'arch maintainer' thats skips
> > part of QA done by the 'package maintainer'.
> 
> Examples?

This is theory, no examples. You interpret the situation the wrong way
around to begin with, so please get that right.

Anyway your call for examples is misguided in itself, because it's a
tendency I'm trying to keep from leading to big QA problems. The
problems so far have been minor or were fixed in time.

- foser

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

Re: [gentoo-dev] Arches marking ebuilds stable before maintainer

[Guy Martin]

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

On Sat, 19 Jun 2004 13:05:34 -0500
Jon Hood <squinky86@gentoo.org> wrote:

> net-p2p/mldonkey- I refuse to mark >2.5.16 stable because of numerous
> bug reports and stability problems with the newer versions (though the
> latest version in portage does seem a bit more stable). Completely
> ignoring this, those versions are on the "stable on hppa". It's not a
> majorly critical package, but it is an example of the QA done by the
> maintainer, and the arch maintainer going beyond it. I don't mind much,
> because I have yet to get a bug report from an hppa user, but I would
> have prefered to keep it all testing until for at least another month.


I've been running it 1 week with ~5Gb of dl on two box before marking it
stable and it still never crashed but I had some minor problems with the
current x86 stable one.

So, I did *extensive* QA on this packages as I do for every other package.
When I say extensive, that means I do everything wich I have the time and
the ressources for. I don't have thousands of users behind me to test stuff.

Also, I marked this directly stable because I don't have time and manpower
to first mark it ~hppa and then hppa. For thoses non-critical packages,
that's the way I proceed. Give me 10 more devs, 50000 users some fast box
and I'll apply to policy regarding the testing stuff for all packages.


-- 
Guy Martin
Gentoo Linux - HPPA port Lead / IPv6 team
Lug Charleroi (Belgium)

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

Re: [gentoo-dev] Arches marking ebuilds stable before maintainer

[Jon Hood]

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

On Sun, 2004-06-20 at 14:31, Guy Martin wrote:
> So, I did *extensive* QA on this packages as I do for every other package.
> When I say extensive, that means I do everything wich I have the time and
> the ressources for. I don't have thousands of users behind me to test stuff.

I stand corrected then, sorry, I didn't mean to attack anyone. I will
push mldonkey 2.5.21 to stable as soon as all the last of the bugs stop
rolling in from IRC and bugzilla (e.g.: #54530 just came in and half the
people who are trying to merge it report the same). It's a WORKSFORME,
but a lot of users still are having trouble.

-- 
AIM: Squinky01
Yahoo!: Squinky86
ICQ: 160940989
Jabber: squinky86@im.gentoo.org

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

Re: [gentoo-dev] Re: [gentoo-core] From [gentoo-dev] Arches marking ebuilds stable before maintainer

[Travis Tilley]

On Saturday 19 June 2004 05:32 pm, foser wrote:
> If it breaks, the maintainer gets the bugs, not the arch, because the
> break wouldn't be arch specfic, but a general problem. That's the whole
> point.

i dunno, if a bug so much as mentions amd64 it gets assigned to us, with very 
few exceptions.

> Actually, because we paid attention to it, it has not lead to any
> serious treaths to stable arches trees. So if we let go and you do for
> once suffer the consequences, this might still change, but I hope it
> won't have to come that.

uhhh.... right. who died and made you -GOD-? if you dont fix a bug personally, 
someone else will. and some other dev will commit it (like me). and you will 
bitch, of course, since we touched your ebuilds. but jesus... to threaten 
someone with a broken stable by refusing to care. *shakes head*

-- 

Travis Tilley <lv@gentoo.org>

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-core] From [gentoo-dev] Arches marking ebuilds stable before maintainer

[Jason Wever]

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

On Sun, 20 Jun 2004 16:36:08 +0200
foser <foser@gentoo.org> wrote:

> This is theory, no examples. You interpret the situation the wrong way
> around to begin with, so please get that right.

Please then explain to me with facts and examples how this is so.  If I'm
to understand how and why I'm wrong, I need something better than someone
saying something like the above.

> Anyway your call for examples is misguided in itself, because it's a
> tendency I'm trying to keep from leading to big QA problems. The
> problems so far have been minor or were fixed in time.

Please provide concrete evidence and examples rather than nebulous
comments.

Thanks,
-- 
Jason Wever
Gentoo/Sparc Team Co-Lead

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

Re: [gentoo-dev] Arches marking ebuilds stable before maintainer

[foser]

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

On Sun, 2004-06-20 at 21:31 +0200, Guy Martin wrote:
> I've been running it 1 week with ~5Gb of dl on two box before marking it
> stable and it still never crashed but I had some minor problems with the
> current x86 stable one.
> 
> So, I did *extensive* QA on this packages as I do for every other package.
> When I say extensive, that means I do everything wich I have the time and
> the ressources for. I don't have thousands of users behind me to test stuff.
> 
> Also, I marked this directly stable because I don't have time and manpower
> to first mark it ~hppa and then hppa. For thoses non-critical packages,
> that's the way I proceed. Give me 10 more devs, 50000 users some fast box
> and I'll apply to policy regarding the testing stuff for all packages.

So you do agree that arch maintainers do not have the same time spend to
attend to a certain package and you weren't aware of the fact that the
>2.5.16 version was not marked stable for a reason ? Both really are
statements to my plea. For you the frontline testing by another arch
with userbase should keep you out of the wind for most bugs.

Another interesting point you raise here is that usually the
'maintainers arch' (mostly x86 atm) does have the backing of a large
userbase to test, which will also improve QA.

- foser

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

[gentoo-dev] Re: that script (was [gentoo-dev] Arches marking ebuilds stable before maintainer)

[Travis Tilley]

On Tuesday 22 June 2004 04:13 am, Guy Martin wrote:
> That's how I see it for most packages. The script I coded
> (http://dev.gentoo.org/~gmsoft/tools/imlate) checks stable version of
> a packages on a given arch against the stable version on another arch
> (x86 per default).

dude that is -awesome-. i would love to see something like this in 
gentoolkit-dev. :)

i'd also like to see a better version of my revision checking script, which 
will compare a currently installed ebuild with the version in portage and 
tell you if they differ. i wrote it because i got annoyed while trying to fix 
a package... apparently the bug was in a package it depended on. one that was 
already fixed without revision bumping because the bug only effected amd64. 
>_< but i have a -lot- more work to do on revcheck before it's generally 
usable (and ignores changes we dont care about).
my initial version: http://dev.gentoo.org/~lv/revcheck.sh
the version ecatmur fixed up to have overlay support: 
http://dev.gentoo.org/~lv/revcheck2.sh

i'd love to know how many of these insanely useful tools are out there, just 
not in general use. i know for sure imlate is going into my personal 
toolbox. :)


-- 

Travis Tilley <lv@gentoo.org>

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Arches marking ebuilds stable before maintainer

[Guy Martin]

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

On Tue, 22 Jun 2004 02:21:57 +0200
foser <foser@gentoo.org> wrote:

> On Sun, 2004-06-20 at 21:31 +0200, Guy Martin wrote:
> > I've been running it 1 week with ~5Gb of dl on two box before
> > marking it stable and it still never crashed but I had some minor
> > problems with the current x86 stable one.
> > 
> > So, I did *extensive* QA on this packages as I do for every other
> > package. When I say extensive, that means I do everything wich I
> > have the time and the ressources for. I don't have thousands of
> > users behind me to test stuff.
> > 
> > Also, I marked this directly stable because I don't have time and
> > manpower to first mark it ~hppa and then hppa. For thoses
> > non-critical packages, that's the way I proceed. Give me 10 more
> > devs, 50000 users some fast box and I'll apply to policy regarding
> > the testing stuff for all packages.
> 
> So you do agree that arch maintainers do not have the same time spend
> to attend to a certain package

Yes, we are ~3 working on the hppa port. How could we ?

> and you weren't aware of the fact that
> the >2.5.16 version was not marked stable for a reason ?

For this particular packages, I didn't really checked because it's ocaml
and the code is compiled by arch specific stuff in ocaml. In this
particular case, I had to port the hppa generation code of ocaml to
linux which wasn't suffering of any particular bug (according the ocaml
BTS).


> Both really are statements to my plea. For you the frontline testing
> by another arch with userbase should keep you out of the wind for most
> bugs.
> 
> Another interesting point you raise here is that usually the
> 'maintainers arch' (mostly x86 atm) does have the backing of a large
> userbase to test, which will also improve QA.

That's how I see it for most packages. The script I coded
(http://dev.gentoo.org/~gmsoft/tools/imlate) checks stable version of
a packages on a given arch against the stable version on another arch
(x86 per default).

The point is that this list is only a starting point for me. For
packages which I'm not very familiar with, I follow x86 unless I got a
good reason to do otherwise (bug reported for hppa only, ...).

For other packages, I prefer and sometimes must use another stable
version than the x86 one.

So it's a case by case aproach.

-- 
Guy Martin
Gentoo Linux - HPPA port Lead / IPv6 team
Lug Charleroi (Belgium)

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

Re: [gentoo-dev] Arches marking ebuilds stable before maintainer

[Carsten Lohrke]

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

On Tuesday 22 June 2004 10:13, Guy Martin wrote:
> That's how I see it for most packages. The script I coded
> (http://dev.gentoo.org/~gmsoft/tools/imlate) checks stable version of
> a packages on a given arch against the stable version on another arch
> (x86 per default).

But isn't exactly this an issue? You don't know which arch the package 
maintainer is using and checking against a single arch doesn't work, because 
a maintainer could mark it stable on his arch for some reason before the 
package maintainer had done this? So the first arch maintainer goes ahead, 
the next one thinks "oh, seems like the package maintainer marked it stable", 
gets bitten and the package maintainer has to resolve resulting problems 
(possibly including blame by users)?


Carsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2BrzVwbzmvGLSW8RAvFiAJ44w72HeQFWG9mYhD43CmIgVKQ8lQCfTEYQ
NdURnBi64GtJXTyd8DcPN/I=
=xAB5
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: that script (was [gentoo-dev] Arches marking ebuilds stable before maintainer)

[Karl Trygve Kalleberg]

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

Make out a bug and assign to me personally, and it'll be done. 

Kind regards,

Karl T


On Tue, Jun 22, 2004 at 03:03:33AM -0400, Travis Tilley wrote:
> On Tuesday 22 June 2004 04:13 am, Guy Martin wrote:
> > That's how I see it for most packages. The script I coded
> > (http://dev.gentoo.org/~gmsoft/tools/imlate) checks stable version of
> > a packages on a given arch against the stable version on another arch
> > (x86 per default).
> 
> dude that is -awesome-. i would love to see something like this in 
> gentoolkit-dev. :)
> 
> i'd also like to see a better version of my revision checking script, which 
> will compare a currently installed ebuild with the version in portage and 
> tell you if they differ. i wrote it because i got annoyed while trying to fix 
> a package... apparently the bug was in a package it depended on. one that was 
> already fixed without revision bumping because the bug only effected amd64. 
> >_< but i have a -lot- more work to do on revcheck before it's generally 
> usable (and ignores changes we dont care about).
> my initial version: http://dev.gentoo.org/~lv/revcheck.sh
> the version ecatmur fixed up to have overlay support: 
> http://dev.gentoo.org/~lv/revcheck2.sh
> 
> i'd love to know how many of these insanely useful tools are out there, just 
> not in general use. i know for sure imlate is going into my personal 
> toolbox. :)
> 
> 
> -- 
> 
> Travis Tilley <lv@gentoo.org>
> 

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

Re: [gentoo-dev] proposed solution to arches/stable problem

[Travis Tilley]

On Tuesday 22 June 2004 10:44 am, Aron Griffis wrote:
>     1. Repoman could check keyword changes, warning arch maintainers
>        when they mark a version arch-stable that is not marked stable
>        by the maintainer.

actually, i'd love to have something that's repoman-activated. that would also 
be a great slap on the wrist reminder any time i'm tempted to do otherwise 
without first talking to the herd maintainers. ^^;

i'd prefer a different variation.. perhaps a "known issues exist" or "beware 
of dragons" flag of some sort. but any useful variation of this theme that's 
repoman activated would be nice. *shrug* foser's idea of having an ebuild 
mention the maintainer's arch(s) would probably also work if repoman knows 
about it... but there are a lot of semi-but-not-really maintained ebuilds.

but then again... i'd always have to mark gcc 3.4 as "known issues exist" even 
though it's stable on my arch and needed to fix other bugs. there are a few 
issues with unit-at-a-time still that cause internal compiler errors on a few 
archs among other things. hmm. in this case, it makes sense to completely 
ignore a "beware" flag on some archs (amd64, ppc64, mips)... but gcc tends to 
be a special case anyways.

i also think that there will always be strange special cases, but having 
repoman constantly remind you would go a long way in keeping the number of 
special cases down... and a reminder to communicate with the maintainer(s), 
like in the hppa mldonkey example (where communication seemed to be the only 
thing lacking, not proper QA). as much as i dislike repoman's bugs, it would 
be useful indeed.

just to clarify: i dont think this is something to prevent archs from 
determining special cases as needed, just something to force some extra 
thinking and remind arch maintainers that there are probably extra steps 
involved that should be taken first.


-- 

Travis Tilley <lv@gentoo.org>

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-core] From [gentoo-dev] Arches marking ebuilds stable before maintainer

[foser]

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

On Sun, 2004-06-20 at 19:36 -0400, Travis Tilley wrote:
> uhhh.... right. who died and made you -GOD-? if you dont fix a bug personally, 
> someone else will. and some other dev will commit it (like me). and you will 
> bitch, of course, since we touched your ebuilds. but jesus... to threaten 
> someone with a broken stable by refusing to care. *shakes head*

No, you are forcing us not to care, because we will get those bugs & we
do. And that is only because certain 'arch maintainers' move things to
stable that are not.
And the whole herds deal got instated because control is needed by a
group of people, we're not in the time anymore that everybody touched
every other ebuild. And actually amd64 has already proven over time that
their fixes broke other arches : remember gtkmm & related packages
(#44409), again here the gnome team reacted in time to prevent it from
becoming a big problem. So as far as package maintenance goes, i do
prefer _all_ changes to be at least relayed to the relevant herd(s).
Arches adding fixes for all arches without the maintaining herd knowing,
no please not.

- foser

PS. Again you attack me personally, I would prefer if you could keep it
more professional. I don't need you to like me, but I do deserve your
respect.

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

[gentoo-dev] proposed solution to arches/stable problem

[Aron Griffis]

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

Hi guys,

I've read through most of these arches vs. maintainers threads.  It
sounds like Carsten hits the nail on the head with this paragraph:

    But isn't exactly this an issue? You don't know which arch the
    package maintainer is using and checking against a single arch
    doesn't work, because a maintainer could mark it stable on his
    arch for some reason before the package maintainer had done this?
    So the first arch maintainer goes ahead, the next one thinks "oh,
    seems like the package maintainer marked it stable", gets bitten
    and the package maintainer has to resolve resulting problems
    (possibly including blame by users)?

So let's use one more KEYWORD: stable.  This KEYWORD would be set by
the package maintainer to indicate her impression of what versions
should be considered stable.  This would have the following effects:

    1. Repoman could check keyword changes, warning arch maintainers
       when they mark a version arch-stable that is not marked stable
       by the maintainer.

    2. Bugs can be assigned appropriately: 

        stable            -- assign maintainer, cc arch team
        not stable, arch  -- assign arch team, cc maintainer
        not stable, ~arch -- assign maintainer, cc arch team

This makes it clear that arches that choose to move ahead of the
maintainer get to deal with the bugs until the maintainer "catches
up".

Thoughts?

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] proposed solution to arches/stable problem

[foser]

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

On Tue, 2004-06-22 at 10:44 -0400, Aron Griffis wrote:
> So let's use one more KEYWORD: stable.  This KEYWORD would be set by
> the package maintainer to indicate her impression of what versions
> should be considered stable.  This would have the following effects:
> 
>     1. Repoman could check keyword changes, warning arch maintainers
>        when they mark a version arch-stable that is not marked stable
>        by the maintainer.
> 
>     2. Bugs can be assigned appropriately: 
> 
>         stable            -- assign maintainer, cc arch team
>         not stable, arch  -- assign arch team, cc maintainer
>         not stable, ~arch -- assign maintainer, cc arch team
> 
> This makes it clear that arches that choose to move ahead of the
> maintainer get to deal with the bugs until the maintainer "catches
> up".

As discussed on IRC, I think this is still overcomplicating the matter.
The 'package maintainer' should be responsible for the overall health of
a package, not an arch maintainer who just was eager to go stable.
The simplest & best solution is just to always wait for the 'maintainers
arch' to go stable in normal circumstances, the 'maintainers arch'
should be marked as such in the ebuild somehow instead. I think keeping
it simple will avoid confusion and always leave the overall package
responsibility to the herd, as it should be.

- foser

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

Re: [gentoo-dev] proposed solution to arches/stable problem

[Ferris McCormick]

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

On Tue, 22 Jun 2004, Aron Griffis wrote:

> Hi guys,
> 
> I've read through most of these arches vs. maintainers threads.  It
> sounds like Carsten hits the nail on the head with this paragraph:
> 
>     But isn't exactly this an issue? You don't know which arch the
>     package maintainer is using and checking against a single arch
>     doesn't work, because a maintainer could mark it stable on his
>     arch for some reason before the package maintainer had done this?
>     So the first arch maintainer goes ahead, the next one thinks "oh,
>     seems like the package maintainer marked it stable", gets bitten
>     and the package maintainer has to resolve resulting problems
>     (possibly including blame by users)?
> 
> So let's use one more KEYWORD: stable.  This KEYWORD would be set by
> the package maintainer to indicate her impression of what versions
> should be considered stable.  This would have the following effects:
> 
>     1. Repoman could check keyword changes, warning arch maintainers
>        when they mark a version arch-stable that is not marked stable
>        by the maintainer.
> 
>     2. Bugs can be assigned appropriately: 
> 
>         stable            -- assign maintainer, cc arch team
>         not stable, arch  -- assign arch team, cc maintainer
>         not stable, ~arch -- assign maintainer, cc arch team
> 
> This makes it clear that arches that choose to move ahead of the
> maintainer get to deal with the bugs until the maintainer "catches
> up".
> 
> Thoughts?
>

I rather like this approach. I think it addresses the maintainers'
concerns, and allows the arch maintainers to proceed if necessary.
Maybe your suggestion can help cool off this discussion.

(And it provides for useful feedback to the maintainer:  after all,
if she sees her package going stable on all architectures but hers,
that's useful information.)

But, truth in labeling requires me to identify myself as an
arch-type (sparc)
 
> Regards,
> Aron
> 
> --
> Aron Griffis
> Gentoo Linux Developer
> 
> 

Regards,
Ferris
- --
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2FdzQa6M3+I///cRAiVTAKCCMIsG4Uc46OIQtGyC64Lkkl+DzwCgoZKH
wwLesPJ4H0wnWQKqq1vKlkI=
=hq95
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proposed solution to arches/stable problem

[Chris Gianelloni]

On Tue, 2004-06-22 at 10:44, Aron Griffis wrote:
> Hi guys,
> 
> I've read through most of these arches vs. maintainers threads.  It
> sounds like Carsten hits the nail on the head with this paragraph:
> 
>     But isn't exactly this an issue? You don't know which arch the
>     package maintainer is using and checking against a single arch
>     doesn't work, because a maintainer could mark it stable on his
>     arch for some reason before the package maintainer had done this?
>     So the first arch maintainer goes ahead, the next one thinks "oh,
>     seems like the package maintainer marked it stable", gets bitten
>     and the package maintainer has to resolve resulting problems
>     (possibly including blame by users)?
> 
> So let's use one more KEYWORD: stable.  This KEYWORD would be set by
> the package maintainer to indicate her impression of what versions
> should be considered stable.  This would have the following effects:
> 
>     1. Repoman could check keyword changes, warning arch maintainers
>        when they mark a version arch-stable that is not marked stable
>        by the maintainer.
> 
>     2. Bugs can be assigned appropriately: 
> 
>         stable            -- assign maintainer, cc arch team
>         not stable, arch  -- assign arch team, cc maintainer
>         not stable, ~arch -- assign maintainer, cc arch team
> 
> This makes it clear that arches that choose to move ahead of the
> maintainer get to deal with the bugs until the maintainer "catches
> up".
> 
> Thoughts?

This would probably fit in perfectly with GLEP 19, as they both propose
the same KEYWORD addition.

http://www.gentoo.org/proj/en/glep/glep-0019.html

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proposed solution to arches/stable problem

[Carsten Lohrke]

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

On Tuesday 22 June 2004 17:38, foser wrote:
> The simplest & best solution is just to always wait for the 'maintainers
> arch' to go stable in normal circumstances, the 'maintainers arch'
> should be marked as such in the ebuild somehow instead.
Not all ebuilds have a single maintainer and not all herd members use the same 
architecture, so you'll have a jumping package-maintainer-arch keyword in the 
end. Don't know, if that's less complicated.

KEYWORDS="stable arch1 arch2 ~arch3"
KEYWORDS="arch1 +arch2 ~arch3"    
(as obvious, the + represents the maintainer arch here)

Is the former or the latter easier to implement in the current code base? Any 
differences in terms of calculation speed?


Carsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2FuTVwbzmvGLSW8RAu5vAJ9T3dn2eQsWj8zcYAdIORPGiWIWjACeLGB2
Sk5bd0ISviJTzSmXka7jexA=
=E70G
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proposed solution to arches/stable problem

[Aron Griffis]

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

foser wrote:	[Tue Jun 22 2004, 11:38:32AM EDT]
> As discussed on IRC, I think this is still overcomplicating the matter.
> The 'package maintainer' should be responsible for the overall health of
> a package, not an arch maintainer who just was eager to go stable.

For the most part, I agree with you.  I have seen cases where an arch
jumps ahead for good reasons, but that is not always the case.  (And
when an arch jumps ahead, there should be dialog with the maintainer.)

> The simplest & best solution is just to always wait for the 'maintainers
> arch' to go stable in normal circumstances, the 'maintainers arch'
> should be marked as such in the ebuild somehow instead. 

You're right.  This is actually the same as my proposal for a "stable"
keyword, just coded differently in the ebuild, and probably saner in
the long run.  In particular it doesn't require sprinkling a new
keyword into all the ebuilds.  We're already most of the way to this
solution.

Q: How do we mark the maintainer's arch?

A: Make the first arch in KEYWORDS always be the maintainer's arch.
   This is probably the case already in most ebuilds, so there's
   almost no transition involved.

> I think keeping it simple will avoid confusion and always leave the
> overall package responsibility to the herd, as it should be.

I agree.  As mentioned, I think there are exceptions.  But they should
be treated as such, and the general rule should be to following the
maintainer's lead.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] proposed solution to arches/stable problem

[Aron Griffis]

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

Chris Gianelloni wrote:	[Tue Jun 22 2004, 12:10:05PM EDT]
> This would probably fit in perfectly with GLEP 19, as they both propose
> the same KEYWORD addition.

Thanks, but at this point I withdraw my proposal of the "stable"
KEYWORD.  I think that it is effectively the same thing as calling out
the maintainer's arch in the ebuild, as mentioned by foser.  In my
previous email I suggest using the first arch in the KEYWORDS list to
indicate the maintainer's arch, which seems like a simpler solution
than adding "stable" throughout the tree.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] proposed solution to arches/stable problem

[Aron Griffis]

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

Carsten Lohrke wrote:	[Tue Jun 22 2004, 12:17:23PM EDT]
> Not all ebuilds have a single maintainer and not all herd members
> use the same architecture, so you'll have a jumping
> package-maintainer-arch keyword in the end. Don't know, if that's
> less complicated.

I think it's okay if the maintainer's arch jumps around.  To do
otherwise would be an unnecessary restriction.

If we go with my proposal to put the maintainer's arch first in the
list, then it's just a matter of reordering the list when the
maintainer marks a package stable.  I can put a simple feature into
ekeyword to make this easy.

I'll write up a GLEP, since clearly this is an enhancement proposal.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] proposed solution to arches/stable problem

[Carsten Lohrke]

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

On Tuesday 22 June 2004 18:25, Aron Griffis wrote:
> I think it's okay if the maintainer's arch jumps around.  To do
> otherwise would be an unnecessary restriction.

In what sense? I can't see any difference in rearranged keywords to a special 
prefix or extra keyword. Neither in internal representation nor in terms of 
implementing this in ekeyword. I dislike order dependent configurations much. 
It's not that visible, as the other two options.

Then again I'm pretty sure foser didn't meant using keywords; He said: "arch 
marked as such in the ebuild somehow"... um, "somehow" is nothing to rely 
on. :)


Carsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2GKoVwbzmvGLSW8RAl6iAJ4wxI/lQacQeqB2KQfESK2ffdluTACcCBsL
A2s57Y5n13Dys/Rah9JCo44=
=bY9u
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proposed solution to arches/stable problem

[Aron Griffis]

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

Carsten Lohrke wrote:	[Tue Jun 22 2004, 12:47:35PM EDT]
> On Tuesday 22 June 2004 18:25, Aron Griffis wrote:
> > I think it's okay if the maintainer's arch jumps around.  To do
> > otherwise would be an unnecessary restriction.
> 
> In what sense? 

Sorry if I wasn't clear.  I meant it would be an unnecessary
restriction to require that the maintainer's arch stays the same
between ebuild revisions.  It happens all the time that a developer
changes architectures.  For example we seem to have a lot of
developers that are changing from x86 to amd64 as their next machines.

> I can't see any difference in rearranged keywords to a special
> prefix or extra keyword.  Neither in internal representation nor in
> terms of implementing this in ekeyword. I dislike order dependent
> configurations much.  It's not that visible, as the other two
> options.

I agree, there isn't much of a difference.  Here are the differences:

    extra keyword: refrains from marking the maintainer's arch, but
        clearly marks when an ebuild is considered stable by the
        package maintainer.  At this point I'm thinking that *knowing*
        the maintainer's arch is nice information to have, and we get
        it for free with the other possibilities.  The "extra keyword"
        method requires a gradual transition throughout the tree.  I
        think this is the least desirable solution.

    special prefix: marks the maintainer's arch clearly, requires a
        gradual transition throughout the tree.

    first keyword: not as visible as special prefix.  However doesn't
        require a gradual transition for most packages, since in most
        cases the first keyword is already the maintainer's arch.
        This is true simply because the current keywords order
        indicates the order in which the keywords were added.  (This
        was standardized by drobbins sometime last year... I will try
        to dig up the email if you are interested)

IMHO it would be easiest to use the first keyword method, with the
option of transitioning to a special prefix eventually.  It would be
harder to transition in the other direction, so I would prefer to
start with the first keyword method.

Note regarding order dependence: I'm not a big fan of order dependence
myself.  I'm pushing for special significance on the first keyword in
the list purely because (1) we already have it, (2) the order of
keywords is already significant, (3) it's very non-invasive, (4) we
can change again later if it doesn't work out.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] proposed solution to arches/stable problem

[Aron Griffis]

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

Ferris McCormick wrote:	[Tue Jun 22 2004, 11:59:44AM EDT]
> I rather like this approach. I think it addresses the maintainers'
> concerns, and allows the arch maintainers to proceed if necessary.
> Maybe your suggestion can help cool off this discussion.

:-)  I'm glad you like it.

What do you think of my more recent suggestion, that we use the first
keyword in the list to indicate the maintainer's arch, thereby
alleviating the need for an additional keyword?

> (And it provides for useful feedback to the maintainer:  after all,
> if she sees her package going stable on all architectures but hers,
> that's useful information.)
> 
> But, truth in labeling requires me to identify myself as an
> arch-type (sparc)

I was just thinking about this at lunch.  I hope that I have a good
perspective, since I maintain numerous packages but also work on alpha
and ia64.  I really have one foot in each camp.  ;-)

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] proposed solution to arches/stable problem

[Ciaran McCreesh]

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

On Tue, 22 Jun 2004 13:36:53 -0400 Aron Griffis <agriffis@gentoo.org>
wrote:
| What do you think of my more recent suggestion, that we use the first
| keyword in the list to indicate the maintainer's arch, thereby
| alleviating the need for an additional keyword?

I think it won't work, because there are already stacks of packages in
the tree where the keywording order is arbitrary.

Why not put a <maintainernotes> in metadata.xml instead? Much cleaner,
provides much more information, doesn't imply meaning in an existing
field which does not currently provide any information.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] proposed solution to arches/stable problem

[Aron Griffis]

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

Travis Tilley wrote:	[Tue Jun 22 2004, 09:05:46AM EDT]
> On Tuesday 22 June 2004 10:44 am, Aron Griffis wrote:
> >     1. Repoman could check keyword changes, warning arch maintainers
> >        when they mark a version arch-stable that is not marked stable
> >        by the maintainer.
> 
> actually, i'd love to have something that's repoman-activated. that would also 
> be a great slap on the wrist reminder any time i'm tempted to do otherwise 
> without first talking to the herd maintainers. ^^;

*grin*

Yep, it can also show up in Mr_Bones_ daily full-tree repoman scan,
and would be a good candidate for aliz's report.  It would be easy to
see if there's a particular arch team that seems to be overstepping
itself.  At the very least it would be a useful statistic.

> i'd prefer a different variation.. perhaps a "known issues exist" or "beware 
> of dragons" flag of some sort. 

Ciaran mentioned the same idea on IRC:

    <@ciaranm> agriffis: i'd prefer a donotmarkthisstable keyword,
    personally, and i'd rather that it wasn't a keyword

    (Since Ciaran has been so kind as to help me with my misuse of the 
    English language, I'll point out that he should have used "weren't"
    instead of "wasn't" to indicate the conditional tense.  ;-)

I understand the desire for that sort of flag from the perspective of
an arch developer, but I'm very wary of it.  Here are the reasons:

    1. The lack of such a flag in a given ebuild would appear to be a
       green light to arch teams, but in reality it might simply be
       that the package maintainer hasn't updated their ebuild yet to
       contain the "beware" flag.

    2. Package maintainers then have the responsibility to add the
       "beware" flag whenever they receive notification of a bug
       against the package.  That's a lot of busy-work.

    3. The "beware" flag would undoubtedly sit in the ebuild even
       after the problem is resolved.  As a package maintainer I can't
       imagine having to toggle it on-and-off as problems come up and
       are solved.

    4. In reality, the package maintainer's arch *should* already
       contain that information, shouldn't it?  If it is marked ~arch,
       then it *should* mean the same thing as a "beware" flag.

I realize that #4 isn't always the case, but consider for a minute
what is the problem and what is the symptom....  If a package
languishes in ~arch for a long time, that is a symptom of the fact
that it is poorly maintained.  If we were to add a "beware" flag to
teh system, then it would not be well-maintained either!

> but any useful variation of this theme that's 
> repoman activated would be nice. *shrug* foser's idea of having an ebuild 
> mention the maintainer's arch(s) would probably also work if repoman knows 
> about it... but there are a lot of semi-but-not-really maintained ebuilds.

Yes.  The "semi-but-not-really maintained ebuilds" isn't something we
can really fix as part of the arch-vs-stable discussion,
unfortunately.  It's something that is on the gradual road of being
fixed via herds, teams, and recruitment of responsible developers.

> just to clarify: i dont think this is something to prevent archs from 
> determining special cases as needed, just something to force some extra 
> thinking and remind arch maintainers that there are probably extra steps 
> involved that should be taken first.

Agreed!  One such step would be attempting to communicate with the
package maintainer about the problem, if possible before making an
arch keyword change.  I think we all agree on this.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] proposed solution to arches/stable problem

[Aron Griffis]

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

Aron Griffis wrote:	[Tue Jun 22 2004, 01:33:19PM EDT]
>     first keyword: not as visible as special prefix.  However doesn't
>         require a gradual transition for most packages, since in most
>         cases the first keyword is already the maintainer's arch.
>         This is true simply because the current keywords order
>         indicates the order in which the keywords were added.  (This
>         was standardized by drobbins sometime last year... I will try
>         to dig up the email if you are interested)

Btw, although this is not *as* visible, it would still be very
visible to developers via repoman, which could be modified to warn (or
even require a flag similar to --ignore-other-arches) when jumping
ahead of the maintainer's arch.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] proposed solution to arches/stable problem

[Ferris McCormick]

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

On Tue, 22 Jun 2004, Aron Griffis wrote:

> Ferris McCormick wrote:	[Tue Jun 22 2004, 11:59:44AM EDT]
> > I rather like this approach. I think it addresses the maintainers'
> > concerns, and allows the arch maintainers to proceed if necessary.
> > Maybe your suggestion can help cool off this discussion.
> 
> :-)  I'm glad you like it.
> 
> What do you think of my more recent suggestion, that we use the first
> keyword in the list to indicate the maintainer's arch, thereby
> alleviating the need for an additional keyword?

I think I prefer the additional keyword.  I am more interested in the
maintainer's opinion than I am in the maintainer's architecture, and the
extra keyword makes it clear the maintainer is signing off.  After all,
if I or anyone else keywords a package without adding the 'stable,' it
is very clear that for some reason an architecture is compelled to jump
ahead.  I also want to know if there is an active maintainer ---

But then, I have been working in some dusty corners of the portage tree,
where I am not sure there even is a maintainer anymore.  I recently marked
a package stable for sparc, and the keywording on it now looks like this:

KEYWORDS="~x86 ~ppc sparc mips ~alpha arm ~hppa amd64 ~ia64 ppc64 s390"

Changelog indicates a lot of recent activity, metadata indicates no-herd,
no maintainer, and I haven't a clue which if any architecture controls.
I would value the opinion of whoever is lead on this package (unless it's
me??? ciaranm did tell me that if I touched it, it was mine....).

(Oh, what is it? This package is dev-lang/tcl-8.4.6, and a few recent
additions to Gentoo depend on it.  It is almost certainly stable on
everything, but all I can speak to is sparc.)

Regards,
Ferris

- --
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2HWtQa6M3+I///cRAuiVAKC49b0TnVfiwNbod2l8sXtuYeuUegCgvYKa
72KYA1FLgB5BHGavOsIlRrk=
=zVjY
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proposed solution to arches/stable problem

[Aron Griffis]

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

Hi Ciaran,

Ciaran McCreesh wrote:	[Tue Jun 22 2004, 01:52:36PM EDT]
> I think it won't work, because there are already stacks of packages
> in the tree where the keywording order is arbitrary.

I agree, there are many with an arbitrary order.  Hopefully--and
probably--not the packages that start these kinds of arguments.  I
suspect most of those presently start with the package maintainer's
arch, purely because they have been actively maintained instead of
willy-nilly.

Here are changes to ekeyword that I would consider *necessary* to make
this work without it being a burden:

1.  Warn when jumping ahead of maintainer's arch.  This should happen
    at repoman time as well.

2.  Automatically recognize a maintainer:

        (a) check metadata.xml for a match against either
            ECHANGELOG_USER or current username.

        (b) read herd from metadata.xml and cross-reference against
            herds.xml to determine if current user is part of the team
            maintaining this herd.

    If maintainer is recognized, then move stable keyword to front of
    KEYWORDS.  Of course, ekeyword should inform when it does this!

3.  Automatically recognize when non-maintainer appears to be marking
    first keyword in list stable, and warn about it.

> Why not put a <maintainernotes> in metadata.xml instead? Much cleaner,
> provides much more information, 

The problem I have with that approach is the weight of it.  All the
metadata.xml files would need that addition.  It's similar to doing a
"stable" keyword (my earlier suggestion, I admit) or using a special
marker on a keyword.  It would take a lot of time to implement
throughout the tree, whereas the solution I'm suggesting would be more
immediately available (though I agree with you that there are plenty
of ebuilds in the tree with an arbitrary order).

> doesn't imply meaning in an existing
> field which does not currently provide any information.

Actually, that isn't true.  It was established previously that the
order of keywords would indicate the order in which they were added to
an ebuild.  This was agreed upon about a year ago (I recall that
drobbins took part in the discussion).  Ekeyword adheres to that
established precedent, which means that presently there should be a
lot of ebuilds that contain the maintainer's arch first in the list.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] proposed solution to arches/stable problem

[Ferris McCormick]

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

On Tue, 22 Jun 2004, Ciaran McCreesh wrote:

> On Tue, 22 Jun 2004 13:36:53 -0400 Aron Griffis <agriffis@gentoo.org>
> wrote:
> | What do you think of my more recent suggestion, that we use the first
> | keyword in the list to indicate the maintainer's arch, thereby
> | alleviating the need for an additional keyword?
> 
> I think it won't work, because there are already stacks of packages in
> the tree where the keywording order is arbitrary.
> 
> Why not put a <maintainernotes> in metadata.xml instead? Much cleaner,
> provides much more information, doesn't imply meaning in an existing
> field which does not currently provide any information.
>
Assuming there is one, I like this better than the keyword.
 
> -- 
> Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
> Mail            : ciaranm at gentoo.org
> Web             : http://dev.gentoo.org/~ciaranm
> 
> 

- --
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2HbPQa6M3+I///cRAooqAKDWeYMQB2gr3jc7wMj52ZLJQoAPRQCfS4hS
QycszF+QenV95wwyCYqUGmM=
=TKeI
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proposed solution to arches/stable problem

[Carsten Lohrke]

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

On Tuesday 22 June 2004 19:54, Aron Griffis wrote:
> Btw, although this is not *as* visible, it would still be very
> visible to developers via repoman, which could be modified to warn (or
> even require a flag similar to --ignore-other-arches) when jumping
> ahead of the maintainer's arch.

I'm not editing ebuilds via repoman. ;) And it is not as non-invasive as you 
think. Quite a fey keyword lines would need to be reordered to adhere the new 
rule - by hand. It is far easier to use +arch and let portage and all tools 
interpret it as arch (as it is now, maybe printing a warning), until portage, 
all tools and ebuilds are ready to switch to the new explicit stable feature.


Carsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2Hr1VwbzmvGLSW8RAmWbAJ9ziGPsXSCyYmFDBNWdFxuCGIEcSQCfZb3D
Dtp1K5E4LTHyaUp3dth59BA=
=2krz
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proposed solution to arches/stable problem

[Ciaran McCreesh]

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

On Tue, 22 Jun 2004 14:12:04 -0400 Aron Griffis <agriffis@gentoo.org>
wrote:
| Actually, that isn't true.  It was established previously that the
| order of keywords would indicate the order in which they were added to
| an ebuild.  This was agreed upon about a year ago (I recall that
| drobbins took part in the discussion).  Ekeyword adheres to that
| established precedent, which means that presently there should be a
| lot of ebuilds that contain the maintainer's arch first in the list.

..which would be fine if packages had a single consistent maintainer who
used one single arch.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] proposed solution to arches/stable problem

[Aron Griffis]

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

Ciaran McCreesh wrote:	[Tue Jun 22 2004, 02:43:43PM EDT]
> ..which would be fine if packages had a single consistent maintainer who
> used one single arch.

Touché  :-)

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] proposed solution to arches/stable problem

[Aron Griffis]

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

Carsten Lohrke wrote:	[Tue Jun 22 2004, 02:31:11PM EDT]
> I'm not editing ebuilds via repoman. ;)

But you had better hope you're committing them that way. ;-)

> And it is not as non-invasive as you think. Quite a fey keyword
> lines would need to be reordered to adhere the new rule - by hand.
> It is far easier to use +arch and let portage and all tools
> interpret it as arch (as it is now, maybe printing a warning), until
> portage, all tools and ebuilds are ready to switch to the new
> explicit stable feature.

With modifications to ekeyword I don't think that there would (almost)
any by-hand reordering necessary.  It would happen automatically as
ekeyword is run on the packages by the p-maintainers and
a-maintainers.  (See my response to Ciaran on the topic of ekeyword
changes)

On the other hand, I'm not opposed completely to a specially marked
keyword.  But there are some things we need to realize: (1) each
approach will have its pros and cons, (2) whichever approach we choose
will likely compromise in one area to avoid compromising in another
area...

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] proposed solution to arches/stable problem

[Aron Griffis]

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

Ferris McCormick wrote:	[Tue Jun 22 2004, 02:08:42PM EDT]
> I think I prefer the additional keyword.  I am more interested in the
> maintainer's opinion than I am in the maintainer's architecture, and the
> extra keyword makes it clear the maintainer is signing off.  After all,
> if I or anyone else keywords a package without adding the 'stable,' it
> is very clear that for some reason an architecture is compelled to jump
> ahead.  I also want to know if there is an active maintainer ---

All good points.

> But then, I have been working in some dusty corners of the portage tree,
> where I am not sure there even is a maintainer anymore.  I recently marked
> a package stable for sparc, and the keywording on it now looks like this:
> 
> KEYWORDS="~x86 ~ppc sparc mips ~alpha arm ~hppa amd64 ~ia64 ppc64 s390"
> 
> Changelog indicates a lot of recent activity, metadata indicates no-herd,
> no maintainer, and I haven't a clue which if any architecture controls.

Yep, I see that regularly too.

I think that I will write another email on this thread summarizing the
current possible approaches, their pros and cons, and then hopefully
we can have a conclusive discussion to choose one of them.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] proposed solution to arches/stable problem

[Jason Huebel]

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

On Tuesday 22 June 2004 02:49 pm, Aron Griffis wrote:
> On the other hand, I'm not opposed completely to a specially marked
> keyword.  But there are some things we need to realize: (1) each
> approach will have its pros and cons, (2) whichever approach we choose
> will likely compromise in one area to avoid compromising in another
> area...

And 3) there are exceptions to the rule.  All I ask is that whatever decision 
is made isn't a hard requirement.  repoman complaining about who goes stable 
first is fine, but don't make us use "-I". :-)

- -- 
Jason Huebel
Gentoo/amd64 Strategic Lead
Gentoo Developer Relations/Recruiter

GPG Public Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9BA9E230

"Do not weep; do not wax indignant. Understand."
Baruch Spinoza (1632 - 1677)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2JShbNgbbJup4jARAhcZAKCbaNuDtWZ63+gNEgNpW3taU2zgBgCcDMQO
QOuy/TqubCo6USgY3RL2uNU=
=0HqV
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proposed solution to arches/stable problem

[Aron Griffis]

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

Jason Huebel wrote:	[Tue Jun 22 2004, 04:20:44PM EDT]
> On Tuesday 22 June 2004 02:49 pm, Aron Griffis wrote:
> > On the other hand, I'm not opposed completely to a specially marked
> > keyword.  But there are some things we need to realize: (1) each
> > approach will have its pros and cons, (2) whichever approach we choose
> > will likely compromise in one area to avoid compromising in another
> > area...
> 
> And 3) there are exceptions to the rule.  All I ask is that whatever decision 
> is made isn't a hard requirement.  repoman complaining about who goes stable 
> first is fine, but don't make us use "-I". :-)

I'm a little confused about what you're saying here.  I totally agree,
there are exceptions.  That fact has been stated numerous times in
these threads, and I don't think anybody disagrees.

Regarding avoiding a hard requirement, there would certainly be no
need to "cvs commit" to get around the checking done by repoman.
Personally I wouldn't be opposed to an option similar to -I to prevent
developers from accidentally submitting such changes.  Both -I and the
new flag are for overriding repoman's QA checks.  IMHO that is
something that should be done seldom enough that it's not asking a lot
from developers.  Do you really think it would be that painful? :-(

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Aron Griffis]

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

At this point I've made a couple suggestions, and developers have
voiced either support or objections, and raised some good arguments
either way.  I'm hoping this email will summarize the three suggested
approaches, their pros and cons, and we can eventually converge on a
single solution.

Proposed solutions:

    I. "stable" keyword
    -------------------
    pros
        - not tied to architecture keywords
        - not dependent on order of keywords
        - clearly nominates an ebuild as stable per the package
          maintainer without ambiguity
        - it's easy to tell which packages are following this standard
          and which ones are not

    cons
        - requires developer behavior change (marking ebuilds with
          "stable" keyword)
        - requires changes throughout the tree
        - uses another keyword
        - no indication of maintainer's arch (might be considered good
          or bad)
        - *requires* changes to portage on *user* systems to
          ignore/handle the "stable" keyword, otherwise portage spits
          out this error:
            IOError: Profile dir does not exist:
            /usr/local/home/agriffis/portage/profiles/default-stable-1.4

    II. "marked keyword" indicates maintainer's arch
    ------------------------------------------------
    pros
        - not dependent on order of keywords
        - clearly nominates an ebuild as stable per the package
          maintainer without ambiguity
        - easy to tell which packages are following this standard and
          which are not
        - doesn't use a new keyword
        - calls out maintainer's arch(es)
        - does not require developer behavior change, because it can
          be handled automatically by ekeyword and repoman

    cons
        - requires changes throughout the tree
        - depends on architecture keywords
        - *requires* changes to portage on *user* systems to
          ignore/handle the new marking, otherwise portage spits out
          this error:
            IOError: Profile dir does not exist:
            /usr/local/home/agriffis/portage/profiles/default-+x86-1.4

    III. first keyword marks maintainer's arch
    ------------------------------------------
    pros
        - takes advantage of existing order already present in *some*
          ebuilds
        - doesn't require changes throughout the tree, only in
          packages that aren't already following this standard
        - doesn't require any changes to portage on *user* systems,
          only developer systems (repoman and ekeyword changes)
        - does not require developer behavior change, because it can
          be handled automatically by ekeyword and repoman

    cons
        - dependent on order of keywords
        - not as unambiguous as the other two approaches
        - not easy to tell which packages are following this standard
          and which are not
        - doesn't use a new keyword
        - calls out only one of the maintainer's arch(es), so it might
          be misleading
        - keywords jump around in the list

    IV. <maintainernotes> in metadata.xml
    -------------------------------------
    This was suggested by Ciaran, and I'm including it for
    completeness, though I can't say I completely understand it.
    Ciaran's reasons were "much cleaner, provides much more
    information, doesn't imply meaning in an existing field which does
    not currently provide any information".  Ciaran, do you feel like
    following up with a better explanation for how this would work?

    Instinctively I'm against it because it requires more work on the
    part of the package maintainer, and I'm trying to avoid the extra
    work all around.  I *think* that suggestions I and II above both
    avoid the implication of meaning by making it explicit.
    Regarding providing "much more information", I'm concerned that
    could result in duplication of information between the bugs
    database and metadata.xml, a duplication that the package
    maintainer has to keep updated.

    All my objections stated :-) I would still like to hear about it
    if you think this is the better way to do things.  It's possible
    that I'm missing a key point.

Common attributes:

    - None of the proposed solutions attempts to enforce behavior.
    - Each provides a lightweight method of communication from the
      package maintainers to the arch maintainers.
    - Each can be recognized and maintained with ekeyword/repoman
      with very little developer behavior change.

Personal leaning:

    I like solution II, "marked keyword", best because it clearly
    calls out the maintainer's tested arch(es).  That seems like
    valuable information to me.  Additionally it doesn't require
    developer behavior change, since ekeyword could determine
    automatically (1) you're the package maintainer, (2) you're
    marking a package stable, (3) what arch you're currently running.
    (Of course ekeyword would also support explicitly marking instead
    of automatic.)  Not requiring developer behavior change these days
    is a lot easier than requiring it.  We have a lot of developers,
    and they don't change behavior quickly or easily.

    The only thing I really dislike about the "marked keyword"
    approach is that it requires changes in the *user's* portage to
    handle the marking.  But only solutions III and IV avoid that so
    far.

I would like to hear feedback so that we can make a choice, do the
necessary steps for implementation, and bring about a positive QA
change in the portage tree.  Hopefully along with an improvement in
the package/arch-maintainer relationship :-)

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] proposed solution to arches/stable problem

[foser]

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

On Tue, 2004-06-22 at 19:43 +0100, Ciaran McCreesh wrote:
> On Tue, 22 Jun 2004 14:12:04 -0400 Aron Griffis <agriffis@gentoo.org>
> wrote:
> | Actually, that isn't true.  It was established previously that the
> | order of keywords would indicate the order in which they were added to
> | an ebuild.  This was agreed upon about a year ago (I recall that
> | drobbins took part in the discussion).  Ekeyword adheres to that
> | established precedent, which means that presently there should be a
> | lot of ebuilds that contain the maintainer's arch first in the list.
> 
> ..which would be fine if packages had a single consistent maintainer who
> used one single arch.

I think it's more something to use while in transition to a keywords
specific marker, which is more flexible. It's a reasonable rule to start
out with.

- foser

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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Donnie Berkholz]

Aron Griffis said:
>     The only thing I really dislike about the "marked keyword"
>     approach is that it requires changes in the *user's* portage to
> handle the marking.  But only solutions III and IV avoid that so
> far.

This is really a pretty annoying problem. As far as I can see, it would
require some hacking backwards compatibility fake profiles to exist at
"default-+x86-1.4" and so forth to avoid breaking everyone's systems with
old portages.

Another option would be to avoid the KEYWORDS variable entirely and use a
new variable. This would avoid the annoying problem of backwards
compatibility and user change.

Examples:

Option 1:
MAINTAINER_ARCHS="x86 sparc"
This indicates that if either of these are stable, the PM(s) consider(s)
the package stable.

Option 2:
STABLE="yes"
STABLE="no"
This is pretty straightforward, so I won't go in depth here.

Thanks,
Donnie



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proposed solution to arches/stable problem

[Carsten Lohrke]

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

On Tuesday 22 June 2004 21:49, Aron Griffis wrote:
> With modifications to ekeyword I don't think that there would (almost)
> any by-hand reordering necessary.  It would happen automatically as
> ekeyword is run on the packages by the p-maintainers and
> a-maintainers.  (See my response to Ciaran on the topic of ekeyword
> changes)

Your response doesn't really say how ekeyword would deal with already existing 
_some_random_arch_ as first entry. It can't. And is it worth adding all the 
logic to ekeyword? You can't rely on that developers are using it all the 
time. E.g. when I'm doing QA and want to change a keyword, I'm editing the 
ebuild directly, without using ekeyword. Your first idea, creating a "stable" 
keyword, is far simpler imho.


Carsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2K20VwbzmvGLSW8RAuI5AJ9D9ZrxzLWPsD/EKt+oIx2xjCAZagCghLOz
6LxIfD6KkFt8zvl6XnNs0rU=
=v6hU
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proposed solution to arches/stable problem

[Carsten Lohrke]

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

On Tuesday 22 June 2004 19:52, Ciaran McCreesh wrote:
> Why not put a <maintainernotes> in metadata.xml instead? Much cleaner,
> provides much more information, doesn't imply meaning in an existing
> field which does not currently provide any information.

If we maybe later would like to implement the possibility that users can 
decide only to use package maintainer approved packages, portage would have 
to parse metadata.xml, too. I thought metadata.xml is more suited for less 
variable data!?


Carsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2LCJVwbzmvGLSW8RAhZ4AJoD+PIUzTK+NQhG1hoNm34oOPtiHACdEMmw
kFRfxlspABwTbg4cHFoVANk=
=8fQW
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Ferris McCormick]

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

On Tue, 22 Jun 2004, Aron Griffis wrote:

> At this point I've made a couple suggestions, and developers have
> voiced either support or objections, and raised some good arguments
> either way.  I'm hoping this email will summarize the three suggested
> approaches, their pros and cons, and we can eventually converge on a
> single solution.
> 
> Proposed solutions:
> 
>     I. "stable" keyword
>     -------------------
> 
>     II. "marked keyword" indicates maintainer's arch
>     ------------------------------------------------
>     III. first keyword marks maintainer's arch
>     ------------------------------------------
> 
>     IV. <maintainernotes> in metadata.xml
>     -------------------------------------
> Personal leaning:
> 
>     I like solution II, "marked keyword", best because it clearly
>     calls out the maintainer's tested arch(es).

> I would like to hear feedback so that we can make a choice, do the
> necessary steps for implementation, and bring about a positive QA
> change in the portage tree.  Hopefully along with an improvement in
> the package/arch-maintainer relationship :-)
>

If I understand II (which I missed or misread in the first wave of these
notes), it says something like "A keyword of '+amd64' means that 'the
maintainer believes that this package is a candidate for stable, and it
is in fact stable on amd64, which is where the maintainer tested it."
(And, I suppose, in an unusual situation, the maintainer could use
just 'amd64' to mean "For critical reasons this has to be stable on
amd64 even though I the maintainer am not all *that* confident." In
this case, the maintainer would be wearing ar architecture hat.)

If my first sentence is close to correct (everything up to the
hypothetical), my preference is also solution II.

Regards,
Ferris
 
> Regards,
> Aron
> 
> --
> Aron Griffis
> Gentoo Linux Developer
> 
> 

- --
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (sparc)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2LHsQa6M3+I///cRArIzAKCyawkllV+bOdhcJYwUTCXyGL5kngCfXQkA
yC9cBrSXFhKj+EDbNWpD3uA=
=rX0h
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Ciaran McCreesh]

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

On Tue, 22 Jun 2004 17:33:09 -0400 Aron Griffis <agriffis@gentoo.org>
wrote:
|     IV. <maintainernotes> in metadata.xml
|     -------------------------------------
|     This was suggested by Ciaran, and I'm including it for
|     completeness, though I can't say I completely understand it.
|     Ciaran's reasons were "much cleaner, provides much more
|     information, doesn't imply meaning in an existing field which does
|     not currently provide any information".  Ciaran, do you feel like
|     following up with a better explanation for how this would work?

Hypothetical example for an app named foo:

<maintainernotes><![CDATA[
>=foo-1.2 has problems when the alsa USE flag is enabled (see bug
#12345). Avoiding marking this as stable on x86 until this issue is
resolved. No other problems known.
]]>

This shows the arch teams that there are specific reasons to stick with
versions below 1.2 (rather than that the maintainer is just lazy and
doesn't pay much attention to the package). It also lets sparc
developers know that they can ignore the maintainer's arch and go ahead
and keyword later versions if necessary, since ALSA isn't available for
that arch.

The information provided is the kind of information arch teams would be
after when contacting the maintainer to find out why they were keeping
their arch's stable version down.

|     Instinctively I'm against it because it requires more work on the
|     part of the package maintainer, and I'm trying to avoid the extra
|     work all around.  I *think* that suggestions I and II above both
|     avoid the implication of meaning by making it explicit.
|     Regarding providing "much more information", I'm concerned that
|     could result in duplication of information between the bugs
|     database and metadata.xml, a duplication that the package
|     maintainer has to keep updated.

Regarding the amount of work, it's effectively the same as is required
for I and II. If a package maintainer *isn't* keeping a close enough
track of a package to know about the issues then chances are the arch
teams know just as much as the package maintainer anyway.

This method (like I and II) has the advantage that if nothing is
present, then arch teams can carry on using the existing method (ya
know, the one that's working fine), and if it *is* there, then the extra
information that would usually be obtained by pestering people on IRC is
already present. Contrast this with III, where we end up with a messy
situation that arch teams don't know whether the first keyword is really
the maintainer's arch or whether it just happens to be there, and
whether the maintainer is just not really maintaining the package or
whether they're holding back for a reason.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Carsten Lohrke]

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

On Tuesday 22 June 2004 23:54, Donnie Berkholz wrote:
> Aron Griffis said:
> >     The only thing I really dislike about the "marked keyword"
> >     approach is that it requires changes in the *user's* portage to
> > handle the marking.  But only solutions III and IV avoid that so
> > far.
>
> This is really a pretty annoying problem. As far as I can see, it would
> require some hacking backwards compatibility fake profiles to exist at
> "default-+x86-1.4" and so forth to avoid breaking everyone's systems with
> old portages.

Could you explain this, Donnie - please!? I'm not that deep into portage, that 
I know, what has to be changed in profiles and why it is a that big problem, 
that they could not be migrated smoothly.

Just had another thought about the "re-arranging arch" option. How do you 
implement this in a differend backend, e.g. a database, Aron?


Carsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2LwpVwbzmvGLSW8RAm5JAKCwZGgzcOph3kH+fdNXMQHEih/zeQCgnwUn
FyvhGXcBIoCUkgCcSla76Eo=
=va+l
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proposed solution to arches/stable problem

[Marius Mauch]

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

On 06/22/04  Carsten Lohrke wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Tuesday 22 June 2004 19:54, Aron Griffis wrote:
> > Btw, although this is not *as* visible, it would still be very
> > visible to developers via repoman, which could be modified to warn
> > (or even require a flag similar to --ignore-other-arches) when
> > jumping ahead of the maintainer's arch.
> 
> I'm not editing ebuilds via repoman. ;) And it is not as non-invasive
> as you think. Quite a fey keyword lines would need to be reordered to
> adhere the new rule - by hand. It is far easier to use +arch and let
> portage and all tools interpret it as arch (as it is now, maybe
> printing a warning), until portage, all tools and ebuilds are ready to
> switch to the new explicit stable feature.

Except that you'll need portage modifications first that have to be
propagated to all users, so prepare for a 3 month waiting period before
you can use that syntax.

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.

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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Marius Mauch]

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

On 06/23/04  Carsten Lohrke wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Tuesday 22 June 2004 23:54, Donnie Berkholz wrote:
> > Aron Griffis said:
> > >     The only thing I really dislike about the "marked keyword"
> > >     approach is that it requires changes in the *user's* portage
> > >     to
> > > handle the marking.  But only solutions III and IV avoid that so
> > > far.
> >
> > This is really a pretty annoying problem. As far as I can see, it
> > would require some hacking backwards compatibility fake profiles to
> > exist at"default-+x86-1.4" and so forth to avoid breaking everyone's
> > systems with old portages.
> 
> Could you explain this, Donnie - please!? I'm not that deep into
> portage, that I know, what has to be changed in profiles and why it is
> a that big problem, that they could not be migrated smoothly.

The problem is much deeper, currently the syntax for KEYWORDS is quite
strict, any enhancements require portage changes on user systems.

> Just had another thought about the "re-arranging arch" option. How do
> you implement this in a differend backend, e.g. a database, Aron?

What do you mean here, a backend for the tree, the cache or what?

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.

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

Re: [gentoo-dev] proposed solution to arches/stable problem

[Jason Huebel]

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

On Tuesday 22 June 2004 03:54 pm, Aron Griffis wrote:
> I'm a little confused about what you're saying here.  I totally agree,
> there are exceptions.  That fact has been stated numerous times in
> these threads, and I don't think anybody disagrees.
>
> Regarding avoiding a hard requirement, there would certainly be no
> need to "cvs commit" to get around the checking done by repoman.
> Personally I wouldn't be opposed to an option similar to -I to prevent
> developers from accidentally submitting such changes.  Both -I and the
> new flag are for overriding repoman's QA checks.  IMHO that is
> something that should be done seldom enough that it's not asking a lot
> from developers.  Do you really think it would be that painful? :-(

I only made another mention of that third requirement since you were outlining 
them again in a declarative way.  That is, these are the goals of 
implementing this new QA procedure.

I've only used -I a couple of times, myself. And in those cases, only because 
another arch's keywording was screwy.  My comment didn't advocate going 
around repoman's checks, only that it;s important that this QA check not 
cause repoman QA checking to fail entirely.

- -- 
Jason Huebel
Gentoo/amd64 Strategic Lead
Gentoo Developer Relations/Recruiter

GPG Public Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9BA9E230

"Do not weep; do not wax indignant. Understand."
Baruch Spinoza (1632 - 1677)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2NS9bNgbbJup4jARAmihAJ4+0H+lsvnAPP2gXAOWfhudN3Cx5QCfePlw
/7wneFGnt13Rlz2JK5fz/O8=
=xygh
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Jason Huebel]

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

Another possible solution that hasn't been considered is adding another 
variable to ebuilds, like so:

STABLE="yes"

If STABLE is set to "yes", then the ebuild is considered stable.  If STABLE is 
missing or set to "no", then it is not.  You could go a step further in this 
and say that if an ebuild is explicitly set to STABLE="no", then that can not 
move to stable on any arch (for instance, _pre or _rc releases).  There's no 
reason for a repoman QA check to have any effect whatsoever on the user, and 
this would avoid that.

PROS:
	- avoids the pitfalls of changing KEYWORDS behaviour
	- avoids issues with KEYWORDS order
	- Does not require immediate portage upgrade for users
	- Only requires changes to repoman behaviour

CONS:
	- another environment variable
	- probably something I'm missing, but I don't see what

The STABLE variable can be added to ebuilds at our leisure, when changes are 
committed to those ebuilds.  This doesn't necessarily have to be done by the 
ebuild maintainer, either.  A good rule of thumb could be:

If the ebuild is marked stable on x86, then the ebuild should have 
STABLE="yes" in it.

What do you think? Sure would be a lot less painful solutions.

- -- 
Jason Huebel
Gentoo/amd64 Strategic Lead
Gentoo Developer Relations/Recruiter

GPG Public Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9BA9E230

"Do not weep; do not wax indignant. Understand."
Baruch Spinoza (1632 - 1677)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2NefbNgbbJup4jARAvlUAJ0QstOCmOr0n0GM/K3eNGnWAsex5gCfVw0A
gxtlfIt3NZcVO/tgpKe6jrI=
=O/51
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Jason Huebel]

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

On Tuesday 22 June 2004 04:54 pm, Donnie Berkholz wrote:
> Option 2:
> STABLE="yes"
> STABLE="no"
> This is pretty straightforward, so I won't go in depth here.

Damn, Donnie beat me to this. I prefer this over all the other solutions 
presented.

- -- 
Jason Huebel
Gentoo/amd64 Strategic Lead
Gentoo Developer Relations/Recruiter

GPG Public Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9BA9E230

"Do not weep; do not wax indignant. Understand."
Baruch Spinoza (1632 - 1677)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2Nf1bNgbbJup4jARAtEnAKCBKrJXAHTuP6dlqi6Z+udj+4GoDgCfQ0k4
0arTk1OYlqvcmNs6NhMg+bI=
=BToz
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Ciaran McCreesh]

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

On Tue, 22 Jun 2004 17:54:03 -0400 (EDT) "Donnie Berkholz"
<spyderous@gentoo.org> wrote:
| STABLE="yes"
| STABLE="no"

STABLE="no, because <reason here>"

since just a "no" is useless. And having to copy paste it to all the
ebuilds over a given version? Messy.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Jason Huebel]

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

On Tuesday 22 June 2004 08:12 pm, Ciaran McCreesh wrote:
> STABLE="no, because <reason here>"

Too messy. Why not just include a #comment about why it's not STABLE?

- -- 
Jason Huebel
Gentoo/amd64 Strategic Lead
Gentoo Developer Relations/Recruiter

GPG Public Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9BA9E230

"Do not weep; do not wax indignant. Understand."
Baruch Spinoza (1632 - 1677)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD4DBQFA2NtMbNgbbJup4jARAkfDAJQLaSXcF81Hk9we6gGAS0Kp0dOiAJ4/6ZjQ
ok13IMHAnL9qXhtUoSG0Vw==
=bSMZ
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Paul de Vrieze]

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

On Tuesday 22 June 2004 23:33, Aron Griffis wrote:
> At this point I've made a couple suggestions, and developers have
> voiced either support or objections, and raised some good arguments
> either way.  I'm hoping this email will summarize the three suggested
> approaches, their pros and cons, and we can eventually converge on a
> single solution.

I think that before this all, we first and all need to get absolutely clear 
what we want to do with these keywords. As a package maintainer I know that 
it can sometimes be displeasing when other archs mark your package as stable. 
I do however not think that we need to spend that much effort on the problem.

If we want to spend the effort we however should first make clear the purpose, 
not just make clear what the arch maintainer's keyword is without making it 
clear what is the purpose of this knowledge.

Paul

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

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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[foser]

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

This is solution I & it is really duplication of information, because if
the arch maintainer thinks something can go stable, it's not more than
logical he will make it stable. So you only have to indicate which arch
(es) is/are the maintainers.

- foser

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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[foser]

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

On Tue, 2004-06-22 at 20:07 -0500, Jason Huebel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Tuesday 22 June 2004 04:54 pm, Donnie Berkholz wrote:
> > Option 2:
> > STABLE="yes"
> > STABLE="no"
> > This is pretty straightforward, so I won't go in depth here.
> 
> Damn, Donnie beat me to this. I prefer this over all the other solutions 
> presented.

Read my other reply to where you say the same thing : it's duplication
of info. Duplication is bad.

- foser

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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Jason Stubbs]

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

On Wednesday 23 June 2004 19:53, Paul de Vrieze wrote:
> On Tuesday 22 June 2004 23:33, Aron Griffis wrote:
> > At this point I've made a couple suggestions, and developers have
> > voiced either support or objections, and raised some good arguments
> > either way.  I'm hoping this email will summarize the three suggested
> > approaches, their pros and cons, and we can eventually converge on a
> > single solution.
>
> I think that before this all, we first and all need to get absolutely clear
> what we want to do with these keywords. As a package maintainer I know that
> it can sometimes be displeasing when other archs mark your package as
> stable. I do however not think that we need to spend that much effort on
> the problem.
>
> If we want to spend the effort we however should first make clear the
> purpose, not just make clear what the arch maintainer's keyword is without
> making it clear what is the purpose of this knowledge.

That's probably the most rational thing I've heard in this entire debate - not 
that it has all been irrational...

Regards,
Jason Stubbs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iQCVAwUBQNmHgVoikN4/5jfsAQL+egP/Yb98ac1FeztSFkEBEdmIqeQpOhwLNUql
e0w7gabShaFvl3loCgHkmkl9B5/06CsLpONmTjqGSVDW4VHZvry/8TZyBCsJu4Sx
aCglP0KMdYnGh7TainsyuM6DhB7t3x48fUUqubN9n6Ekx8AyhUQATYbGkYHcU6+W
GoNzvTOHIKc=
=62ch
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proposed solution to arches/stable problem

[Carsten Lohrke]

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

On Wednesday 23 June 2004 02:04, Marius Mauch wrote:
> Except that you'll need portage modifications first that have to be
> propagated to all users, so prepare for a 3 month waiting period before
> you can use that syntax.
Right. It's just staying at status quo for three months more.


Carsten

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2ZgHVwbzmvGLSW8RAsY8AJ4zebKy1JOPDym04t/lNleH42D06ACcD+TG
ByIVVl92SfecsEuBH/7msww=
=I4QV
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Carsten Lohrke]

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

On Wednesday 23 June 2004 02:15, Marius Mauch wrote:
> The problem is much deeper, currently the syntax for KEYWORDS is quite
> strict, any enhancements require portage changes on user systems.
O.k., I'm on thin ice here, because I don't know enough about portage. Why not 
stripping either "status" or "+" from the keyword list for all operations 
where it is not needed? Couldn't it be transiently stored in an extra field, 
until everything is in place to migrate users without any hassle?

> > Just had another thought about the "re-arranging arch" option. How do
> > you implement this in a differend backend, e.g. a database, Aron?
>
> What do you mean here, a backend for the tree, the cache or what?
A possible future - no file tree, but everything stored in a db. When each 
keyword is a column in a table, you cannot reorder them as in an ebuild


Carsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2ZvcVwbzmvGLSW8RAmvCAJ0WUmHFERcg3AeUDR0tgrJy3/Il/gCgnFe5
n91cT88yAXX6dQTDkjeV/dY=
=o459
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[foser]

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

On Wed, 2004-06-23 at 22:37 +0900, Jason Stubbs wrote:
> > I think that before this all, we first and all need to get absolutely clear
> > what we want to do with these keywords. As a package maintainer I know that
> > it can sometimes be displeasing when other archs mark your package as
> > stable. I do however not think that we need to spend that much effort on
> > the problem.
> >
> > If we want to spend the effort we however should first make clear the
> > purpose, not just make clear what the arch maintainer's keyword is without
> > making it clear what is the purpose of this knowledge.
> 
> That's probably the most rational thing I've heard in this entire debate - not 
> that it has all been irrational...

I found it to be most effortless comment so far, because all the reasons
are laid out perfectly fine so far in this thread. This is basicly just
QA, no more reasons needed than that. The implementation policy wise has
also been dealt with, i have no clue whatsoever he wants explained that
hasn't been most thoroughly scrutinized already.

And I wasn't gonna answer, because that tends to get another reply and
another one, but I can't keep myself from replying here.

- foser


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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Ferris McCormick]

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

On Wed, 23 Jun 2004, foser wrote:

> On Tue, 2004-06-22 at 20:07 -0500, Jason Huebel wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On Tuesday 22 June 2004 04:54 pm, Donnie Berkholz wrote:
> > > Option 2:
> > > STABLE="yes"
> > > STABLE="no"
> > > This is pretty straightforward, so I won't go in depth here.
> > 
> > Damn, Donnie beat me to this. I prefer this over all the other solutions 
> > presented.
> 
> Read my other reply to where you say the same thing : it's duplication
> of info. Duplication is bad.
> 
> - foser
>
I don't think it's just duplication.  There have been so many of these, I
am not sure which one to attach this thought to, so I picked this one
because it is short.  And, if I understand your point, this speaks to it.

I am arch(sparc), so for definiteness, I use sparc as a placeholder for
any architecture.

1.  In one instance, if I, as sparc, mark something as KEYWORDS=sparc, it
    means essentially one thing:  In my best judgment this package is 
    stable for use on sparc.  It doesn't say anything about other 
    architectures (except as evidence of goodness).

2.  In a second instance, I am sparc & package maintainer. Now, if I
    mark this package stable on sparc, I might mean one or more of at
    least two possibilities:
      a.  I am package maintainer, I believe this package is stable,
          and I happen to be on sparc.
      b.  I believe this package is stable on sparc, and I happen to
          be its maintainer.

If you are on hppa, say, these three possibilties have different weight
as external evidence on the package's current state; namely,

2.a > 2.b > 1

To be fair, I do not know if the distinction 2.a <--> 2.b I just set up
ever comes up in practice.  But I can imagine realistic cases in which
it could.  (I am sparc only.  Suppose I am working on something which
has endian issues.  I can say with confidence that it is stable on sparc,
but this is much closer to my 2.b example than 2.a, because I cannot test
what I think the vulnerabilities are.)

Maybe I am misunderstanding your point, of maybe I am raising a strawman
which never occurs.  In that case, you can safely ignore my comments.
But to me, the 2.a <--> 2.b distinction is real; perhaps it's one reason
ciaranm wants to see maintainer's reasons along with maintainer's 
judgement.

Regards,
Ferris


- --
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2ZzqQa6M3+I///cRAtTYAJ4/O6VSVl5B146ddSO/d1STuWFAeQCeJahF
kYQ/gyi55CHMbnvDyOUsL9Y=
=9za9
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Carsten Lohrke]

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

On Wednesday 23 June 2004 15:37, Jason Stubbs wrote:
> On Wednesday 23 June 2004 19:53, Paul de Vrieze wrote:
> > I think that before this all, we first and all need to get absolutely
> > clear what we want to do with these keywords. As a package maintainer I
> > know that it can sometimes be displeasing when other archs mark your
> > package as stable. I do however not think that we need to spend that much
> > effort on the problem.
> >
> > If we want to spend the effort we however should first make clear the
> > purpose, not just make clear what the arch maintainer's keyword is
> > without making it clear what is the purpose of this knowledge.
>
> That's probably the most rational thing I've heard in this entire debate -
> not that it has all been irrational...
Right. When I wrote the email, which was followed by Aron's with his "stable" 
keyword idea, I had something else in mind. One point is, that Ciaran and 
Travis rather aggressive defend the status quo to be able to declare some 
ebuild stable on a specific arch (Please don't hack on me you two, I'm just 
stating not assessing it.). So all discussed ideas try to avoid these 
communication problem and to allow different development speeds on different 
architectures and weaken the role of the package maintainer. I consider this 
not a bad thing for fast evolving architectures , but it may cause other 
problems, like comparable and interoperable releases* on all supported 
architectures.

* I know that we don't really have releases, but don't forget there are 
thoughts about enterprise Gentoo and that not the always evolving nature of 
Gentoo will be measured from outside, but 200X.Y releases.


Carsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2aGGVwbzmvGLSW8RAhyqAKCLnOtHMLCaM1/iHV7Xo8ZbzbZ8cgCdFV5y
Z8j/R/GIhpFdDZo2P7m943w=
=O9Hr
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Ciaran McCreesh]

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

On Wed, 23 Jun 2004 13:31:39 +0200 foser <foser@gentoo.org> wrote:
| This is solution I & it is really duplication of information, because
| if the arch maintainer thinks something can go stable, it's not more
| than logical he will make it stable. So you only have to indicate
| which arch(es) is/are the maintainers.

Not true. Simple example (maintainer's arch is x86):

"This would be marked stable except that the x86-only turbo super
accelerator (written in assembly) no longer works with files over
1GByte."

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Chris Gianelloni]

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

On Wed, 2004-06-23 at 11:38, Ciaran McCreesh wrote:
> Not true. Simple example (maintainer's arch is x86):
> 
> "This would be marked stable except that the x86-only turbo super
> accelerator (written in assembly) no longer works with files over
> 1GByte."

Would comments in the ebuild not be enough?  Look at the
vmware-workstation-4.5.2 ebuild for an example.

I don't see why it would not be easy enough to comment the reasons an
ebuild might not be marked stable.  Another example that I can think of
is the xorg-x11 ebuilds.  You can see an obvious TODO list before it is
considered stable.

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Jason Huebel]

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

On Wednesday 23 June 2004 06:34 am, foser wrote:
> On Tue, 2004-06-22 at 20:07 -0500, Jason Huebel wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Tuesday 22 June 2004 04:54 pm, Donnie Berkholz wrote:
> > > Option 2:
> > > STABLE="yes"
> > > STABLE="no"
> > > This is pretty straightforward, so I won't go in depth here.
> >
> > Damn, Donnie beat me to this. I prefer this over all the other solutions
> > presented.
>
> Read my other reply to where you say the same thing : it's duplication
> of info. Duplication is bad.
>
> - foser

This isn't duplication of information.  Whether or not an ebuild is considered 
stable by the arch maintainer is a QA issue and should not affect users.  
Changes to the behaviour of KEYWORDS affects users.  Adding a STABLE variable 
does not.  There's no reason for these changes to filter down to the user 
level.  Change repoman to check for the STABLE variable and portage doesn't 
need to be touched.  Change ebump and ekeyword to add/remove the STABLE 
variable as needed.

- -- 
Jason Huebel
Gentoo/amd64 Strategic Lead
Gentoo Developer Relations/Recruiter

GPG Public Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9BA9E230

"Do not weep; do not wax indignant. Understand."
Baruch Spinoza (1632 - 1677)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2cTIbNgbbJup4jARAgjdAJ4ncIOisSpJfG0So0FPMKcNk/DlTwCdFPZ4
bGi896cFCSPtNXnD+ostufg=
=lStT
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[foser]

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

On Wed, 2004-06-23 at 15:08 +0000, Ferris McCormick wrote:
> > Read my other reply to where you say the same thing : it's duplication
> > of info. Duplication is bad.
> > 
> > - foser
> >
> I don't think it's just duplication.  There have been so many of these, I
> am not sure which one to attach this thought to, so I picked this one
> because it is short.  And, if I understand your point, this speaks to it.
> 
> I am arch(sparc), so for definiteness, I use sparc as a placeholder for
> any architecture.
> 
> 1.  In one instance, if I, as sparc, mark something as KEYWORDS=sparc, it
>     means essentially one thing:  In my best judgment this package is 
>     stable for use on sparc.  It doesn't say anything about other 
>     architectures (except as evidence of goodness).

You are not the package maintainer, you should not mark it stable before
that happens. So your arch going stable has no wider significance.

> 2.  In a second instance, I am sparc & package maintainer. Now, if I
>     mark this package stable on sparc, I might mean one or more of at
>     least two possibilities:
>       a.  I am package maintainer, I believe this package is stable,
>           and I happen to be on sparc.
>       b.  I believe this package is stable on sparc, and I happen to
>           be its maintainer.

What is the difference between a & b, they look the same to me. If you
are the package maintainer and sparc is your arch, then that means that
it is now safe for other arches to move to stable as well (if they do
not have arch specific issues).

A 'package maintainer' is someone who is responsible for the general
ebuild, not it's arch specific parts. But naturally, the 'package
maintainer' is on some arch and will take care of needs specific for
that arch as well.

- foser

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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[foser]

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

On Wed, 2004-06-23 at 12:58 -0500, Jason Huebel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Wednesday 23 June 2004 06:34 am, foser wrote:
> > On Tue, 2004-06-22 at 20:07 -0500, Jason Huebel wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > On Tuesday 22 June 2004 04:54 pm, Donnie Berkholz wrote:
> > > > Option 2:
> > > > STABLE="yes"
> > > > STABLE="no"
> > > > This is pretty straightforward, so I won't go in depth here.
> > >
> > > Damn, Donnie beat me to this. I prefer this over all the other solutions
> > > presented.
> >
> > Read my other reply to where you say the same thing : it's duplication
> > of info. Duplication is bad.
> >
> > - foser
> 
> This isn't duplication of information.  Whether or not an ebuild is considered 
> stable by the arch maintainer is a QA issue and should not affect users.  

'maintainer arch' + stable state of the ebuild on the 'maintainers arch'
is the indication of stability, adding an extra line for that is
duplication. The question here is about how to indicate the maintainers
arch.

So STABLE is duplication. If you want to avoid changing keywords (what
the basis seems for your like of this solution) the solution is to add
MAINTAINERS_ARCH or INDICATOR_ARCH or something. Long term I personally
do think it's better to use KEYWORDS for this for simplicity sake, but
spyderous has a serious argument there with the backwards compatability.

- foser

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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Chris Gianelloni]

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

On Wed, 2004-06-23 at 13:58, Jason Huebel wrote:
> level.  Change repoman to check for the STABLE variable and portage doesn't 
> need to be touched.  Change ebump and ekeyword to add/remove the STABLE 
> variable as needed.

All of this has made me curious.  I know to use repoman, and use it for
any and every commit (except profile, license, and eclasses, of course),
but are we "supposed" to be using ebump and ekeyword rather than
adjusting them manually?

This conversation is the first I have ever heard of either application.

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Ferris McCormick]

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

On Wed, 23 Jun 2004, foser wrote:

> > >
> > I don't think it's just duplication.  There have been so many of these, I
> > am not sure which one to attach this thought to, so I picked this one
> > because it is short.  And, if I understand your point, this speaks to it.
> > 
> > I am arch(sparc), so for definiteness, I use sparc as a placeholder for
> > any architecture.
> > 
> > 1.  In one instance, if I, as sparc, mark something as KEYWORDS=sparc, it
> >     means essentially one thing:  In my best judgment this package is 
> >     stable for use on sparc.  It doesn't say anything about other 
> >     architectures (except as evidence of goodness).
> 
> You are not the package maintainer, you should not mark it stable before
> that happens. So your arch going stable has no wider significance.
>
Sure it does, unless the maintainer never makes mistakes.  It's more
evidence that the package is good (consider the endian problems which
come up now and then.  If maintainer is little-endian and sparc goes
stable, that suggests to other big-endian archs that there is probably
not an endian concern. Look at games, sys-cluster, and I think you'll
find examples where number of stable architectures matters.)
 
> > 2.  In a second instance, I am sparc & package maintainer. Now, if I
> >     mark this package stable on sparc, I might mean one or more of at
> >     least two possibilities:
> >       a.  I am package maintainer, I believe this package is stable,
> >           and I happen to be on sparc.
> >       b.  I believe this package is stable on sparc, and I happen to
> >           be its maintainer.
> 
> What is the difference between a & b, they look the same to me. If you
> are the package maintainer and sparc is your arch, then that means that
> it is now safe for other arches to move to stable as well (if they do
> not have arch specific issues).
>

For 2.b: Consider a LaTeX document class (there are some in portage) --
almost certainly architecture-neutral, and maintainer's blessing is
almost certainly definitive.

For 2.a: Consider a multiprocessor performance measurement tool working
at a very low level. -- almost certainly architecture-specific, and
maintainer's blessing might mean only that it's usable on a specific
architecture.

In case 2.b, if I am interested in the package, I should follow the
maintainer.  In 2.a, what the maintainer thinks could be completely
irrelevant to my arch, ranging from {-sparc, ~sparc, sparc}, and I
just thank the maintainer for the package.  (Portage has performance
measurement tools; I really don't know if any work at this level.)
 
> A 'package maintainer' is someone who is responsible for the general
> ebuild, not it's arch specific parts. But naturally, the 'package
> maintainer' is on some arch and will take care of needs specific for
> that arch as well.
> 

OK.  My example for 2.a is for packages which are almost all 
architecture-specific, so that the maintainer's view of the world has
little relevance to how other people look at it.


> - foser
> 

- --
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2dOnQa6M3+I///cRAnGVAJ4qCvGtI7vilZtsF+997dNGy6IhkQCggFDy
Bh1gT61PgppBYMW75OTM6Mo=
=5R76
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Donnie Berkholz]

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

On Wed, 2004-06-23 at 12:08, Chris Gianelloni wrote:
> I don't see why it would not be easy enough to comment the reasons an
> ebuild might not be marked stable.  Another example that I can think of
> is the xorg-x11 ebuilds.  You can see an obvious TODO list before it is
> considered stable.

Which, by the way, is out of date. Now that you've so kindly reminded
me, I'm updating it.
-- 
Donnie Berkholz
Gentoo Linux

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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Donnie Berkholz]

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

On Wed, 2004-06-23 at 14:39, foser wrote:
> On Wed, 2004-06-23 at 15:08 +0000, Ferris McCormick wrote:
> > > Read my other reply to where you say the same thing : it's duplication
> > > of info. Duplication is bad.
> > > 
> > > - foser
> > >
> > I don't think it's just duplication.  There have been so many of these, I
> > am not sure which one to attach this thought to, so I picked this one
> > because it is short.  And, if I understand your point, this speaks to it.
> > 
> > I am arch(sparc), so for definiteness, I use sparc as a placeholder for
> > any architecture.
> > 
> > 1.  In one instance, if I, as sparc, mark something as KEYWORDS=sparc, it
> >     means essentially one thing:  In my best judgment this package is 
> >     stable for use on sparc.  It doesn't say anything about other 
> >     architectures (except as evidence of goodness).
> 
> You are not the package maintainer, you should not mark it stable before
> that happens. So your arch going stable has no wider significance.

A package maintainer doubles as arch maintainer for that package and
shouldn't be forced to hold it back from stable on an arch it is stable
on just because it isn't stable on every arch.

That kind of freedom from essentially pointless inter-arch dependencies
is one of the things I enjoy about Gentoo.
-- 
Donnie Berkholz
Gentoo Linux

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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Chris Gianelloni]

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

On Wed, 2004-06-23 at 15:04, Donnie Berkholz wrote:
> On Wed, 2004-06-23 at 12:08, Chris Gianelloni wrote:
> > I don't see why it would not be easy enough to comment the reasons an
> > ebuild might not be marked stable.  Another example that I can think of
> > is the xorg-x11 ebuilds.  You can see an obvious TODO list before it is
> > considered stable.
> 
> Which, by the way, is out of date. Now that you've so kindly reminded
> me, I'm updating it.

*grin*

My point is still pretty valid.  This is especially true if bug #'s are
listed within the ebuild itself.

Perhaps a combination of this and "INDICATOR_ARCH" would be the proper
solution?

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Jason Huebel]

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

On Wednesday 23 June 2004 02:09 pm, Donnie Berkholz wrote:
> A package maintainer doubles as arch maintainer for that package and
> shouldn't be forced to hold it back from stable on an arch it is stable
> on just because it isn't stable on every arch.
>
> That kind of freedom from essentially pointless inter-arch dependencies
> is one of the things I enjoy about Gentoo.

I agree. Whether or not a package is stable on one arch should not be 
dependent on another. x86 is certainly the most widely used arch, but one 
arch shouldn't have control over all others.

I could be mistaken, but isn't this whole conversation basically splitting 
hairs over who controls what aspect of an ebuild's lifecycle?

Ebuild maintainers are supposed to write stable /ebuilds/ for Gentoo.  Arch 
maintainers are supposed to make sure the /applications/ installed by those 
ebuilds are stable during runtime.  There's a clear line between the two job 
functions.  Yes, it is common for a dev to fill both roles. But in the case 
of someone (like me) who is /only/ an arch maintainer, who wins out when 
determining the stability of the installed application?  I don't think it's 
the ebuild maintainer, since that individual may have no access to my arch.  
We're arch maintainers-- that's our job.

Our team tests packages all the time.  Just because x86 doesn't move their 
packages to stable doesn't mean other arches should have to wait on them.  
Our team has added on several new devs to address the issues we've had in the 
past with having a "stable" tree that is outdated.  We want our arch to 
remain as up-to-date as possible. We're arch maintainers-- that's our job.

The keywording policy has always been that a package must remain in "testing" 
for at least 30 days without a bug report being filed on it.  Our team has 
made an effort to move packages into stable as soon as they meet that 
criteria.  That policy has been very successful over the last year, with a 
very small number of exceptions.

- -- 
Jason Huebel
Gentoo/amd64 Strategic Lead
Gentoo Developer Relations/Recruiter

GPG Public Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9BA9E230

"Do not weep; do not wax indignant. Understand."
Baruch Spinoza (1632 - 1677)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2eClbNgbbJup4jARAvOVAJ0RqNBCSFq0T615/KbRfBAm0MvPegCePKwt
iXsnPPGAud7B5h0+FTIxLfE=
=9Ul/
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Chris Gianelloni]

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

On Wed, 2004-06-23 at 15:57, Jason Huebel wrote:
> The keywording policy has always been that a package must remain in "testing" 
> for at least 30 days without a bug report being filed on it.  Our team has 
> made an effort to move packages into stable as soon as they meet that 
> criteria.  That policy has been very successful over the last year, with a 
> very small number of exceptions.

This is all the more reason to make sure that you get the output of
"emerge info" when someone files a bug.  After all, how many bugs out
there have been arch specific, but it took the maintainer a while to
figure it out because the submitter wasn't clear?

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Carsten Lohrke]

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

On Wednesday 23 June 2004 21:01, Ferris McCormick wrote:
> On Wed, 23 Jun 2004, foser wrote:
> > You are not the package maintainer, you should not mark it stable before
> > that happens. So your arch going stable has no wider significance.
>
> Sure it does, unless the maintainer never makes mistakes.  It's more
> evidence that the package is good (consider the endian problems which
> come up now and then.  If maintainer is little-endian and sparc goes
> stable, that suggests to other big-endian archs that there is probably
> not an endian concern. Look at games, sys-cluster, and I think you'll
> find examples where number of stable architectures matters.)

It has significance for an architecture, but not in general. The package 
maintainer stays in contact with upstream development and knows if e.g. there 
is a problem under a special condition and waits for a new upstream release. 
That's why foser says arch maintainers shall wait for package maintainers, 
unless there is a critical problem with the current stable version on that 
arch.


Carsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2fCxVwbzmvGLSW8RAgOtAJ9rwa75UVp/vkAYMIbVfq48td7q+QCfVa9t
8Q8A5A9xiVmQUxy/pj7Dn9o=
=X7D+
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Donnie Berkholz]

Jason Huebel said:
> Ebuild maintainers are supposed to write stable /ebuilds/ for Gentoo.
> Arch  maintainers are supposed to make sure the /applications/ installed
> by those  ebuilds are stable during runtime.  There's a clear line
> between the two job  functions.  Yes, it is common for a dev to fill
> both roles. But in the case  of someone (like me) who is /only/ an arch
> maintainer, who wins out when  determining the stability of the
> installed application?  I don't think it's  the ebuild maintainer, since
> that individual may have no access to my arch.   We're arch
> maintainers-- that's our job.

It's not one or the other: it's both. Nobody needs to "win" the
maintainership battle here.

Here's how I see it. PMs are responsible for the whole package, including
arch-independent and arch-dependent aspects. Independently, PMs work to
ensure the arch-independent parts are stable. Together with AMs, the PMs
work to ensure the arch-dependent aspects are stable.

Until the day when AMs have equal amounts of time to spend on each package
as PMs, I don't see this changing.

Donnie



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Jason Huebel]

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

On Wednesday 23 June 2004 04:13 pm, Donnie Berkholz wrote:
> It's not one or the other: it's both. Nobody needs to "win" the
> maintainership battle here.
>
> Here's how I see it. PMs are responsible for the whole package, including
> arch-independent and arch-dependent aspects. Independently, PMs work to
> ensure the arch-independent parts are stable. Together with AMs, the PMs
> work to ensure the arch-dependent aspects are stable.
>
> Until the day when AMs have equal amounts of time to spend on each package
> as PMs, I don't see this changing.

Perhaps "win" is too strong of a word. "Precedence" is more what I mean.  But 
I can certainly see your point.

- -- 
Jason Huebel
Gentoo/amd64 Strategic Lead
Gentoo Developer Relations/Recruiter

GPG Public Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9BA9E230

"Do not weep; do not wax indignant. Understand."
Baruch Spinoza (1632 - 1677)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2feybNgbbJup4jARAs81AJ9TYrA4VoF+tOmvLDsIoRu/najPoACeKx00
1LTbpbtZR8tCdXhqnmHUgog=
=Iosx
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[foser]

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

On Wed, 2004-06-23 at 19:01 +0000, Ferris McCormick wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Wed, 23 Jun 2004, foser wrote:
> 
> > > >
> > > I don't think it's just duplication.  There have been so many of these, I
> > > am not sure which one to attach this thought to, so I picked this one
> > > because it is short.  And, if I understand your point, this speaks to it.
> > > 
> > > I am arch(sparc), so for definiteness, I use sparc as a placeholder for
> > > any architecture.
> > > 
> > > 1.  In one instance, if I, as sparc, mark something as KEYWORDS=sparc, it
> > >     means essentially one thing:  In my best judgment this package is 
> > >     stable for use on sparc.  It doesn't say anything about other 
> > >     architectures (except as evidence of goodness).
> > 
> > You are not the package maintainer, you should not mark it stable before
> > that happens. So your arch going stable has no wider significance.
> >
> Sure it does, unless the maintainer never makes mistakes.  It's more
> evidence that the package is good (consider the endian problems which
> come up now and then.  If maintainer is little-endian and sparc goes
> stable, that suggests to other big-endian archs that there is probably
> not an endian concern. Look at games, sys-cluster, and I think you'll
> find examples where number of stable architectures matters.)

Well, it only proves it is _more_ stable, but the significance of the
'maintainer arch' is that it is considered a general bugfree ebuild as
far as known bugs is concerned. Arch specific issues are for the arch
maintainers.
 
> For 2.b: Consider a LaTeX document class (there are some in portage) --
> almost certainly architecture-neutral, and maintainer's blessing is
> almost certainly definitive.
> 
> For 2.a: Consider a multiprocessor performance measurement tool working
> at a very low level. -- almost certainly architecture-specific, and
> maintainer's blessing might mean only that it's usable on a specific
> architecture.

Nah, we already earlier in the discussion special cased lowlevel
toolchain stuff. It's logical a more direct arch specific direction is
taken there. Anyway as said, the marking stable is more about known
general bugs being resolved and the ebuild being clean & bugfree.

This is more of a general Gentoo wide approach, where arch involvement
usually is limited to marking stable. The arch teams are much smaller
than the maintainers teams, thats pretty much the underlying thought.

- foser

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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Ferris McCormick]

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

On Wed, 23 Jun 2004, foser wrote:

> On Wed, 2004-06-23 at 19:01 +0000, Ferris McCormick wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On Wed, 23 Jun 2004, foser wrote:
> > 
> > > > >
> > > > 1.  In one instance, if I, as sparc, mark something as KEYWORDS=sparc, it
> > > >     means essentially one thing:  In my best judgment this package is 
> > > >     stable for use on sparc.  It doesn't say anything about other 
> > > >     architectures (except as evidence of goodness).
> > > 
> > > You are not the package maintainer, you should not mark it stable before
> > > that happens. So your arch going stable has no wider significance.
> > >
> > Sure it does, unless the maintainer never makes mistakes.  It's more
> > evidence that the package is good (consider the endian problems which
> > come up now and then.  If maintainer is little-endian and sparc goes
> > stable, that suggests to other big-endian archs that there is probably
> > not an endian concern. Look at games, sys-cluster, and I think you'll
> > find examples where number of stable architectures matters.)
> 
> Well, it only proves it is _more_ stable, but the significance of the
> 'maintainer arch' is that it is considered a general bugfree ebuild as
> far as known bugs is concerned. Arch specific issues are for the arch
> maintainers.
>

That's my point.  To me, _more_ stable is significant.  We are not in an
ideal world; consider how you yourself compare the following two cases
(assuming a sparc-ish outlook, x86 home), and would an unsuccessful test
surprise you more in one case than the other?:

KEYWORDS="x86 ~sparc ~a ~b ~c ~d ~e -f"
KEYWORDS="x86 ~sparc  a  b  c  ~d e"

That's all I am saying; don't try to make it more profound than
intended. :)

Sorry, I couldn't resist
Ferris  

- --
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (sparc)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2gQ8Qa6M3+I///cRAh5rAKDgQuVpfM3kc+Lb+4oexTRVtz1XoQCdFuY4
4FJwrxdGh/yhqdzycIrI9SM=
=M7vr
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Jason Stubbs]

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

On Thursday 24 June 2004 00:07, foser wrote:
> On Wed, 2004-06-23 at 22:37 +0900, Jason Stubbs wrote:
> > > I think that before this all, we first and all need to get absolutely
> > > clear what we want to do with these keywords. As a package maintainer I
> > > know that it can sometimes be displeasing when other archs mark your
> > > package as stable. I do however not think that we need to spend that
> > > much effort on the problem.
> > >
> > > If we want to spend the effort we however should first make clear the
> > > purpose, not just make clear what the arch maintainer's keyword is
> > > without making it clear what is the purpose of this knowledge.
> >
> > That's probably the most rational thing I've heard in this entire debate
> > - not that it has all been irrational...
>
> I found it to be most effortless comment so far, because all the reasons
> are laid out perfectly fine so far in this thread. This is basicly just
> QA, no more reasons needed than that. The implementation policy wise has
> also been dealt with, i have no clue whatsoever he wants explained that
> hasn't been most thoroughly scrutinized already.

My understanding is that one camp believes a stable keyword means that the 
package is stable overall but may have arch-specific issues. The other camp 
believes that a stable keyword has no implications beyond the architecture 
that is marked stable.

There needs to be agreement on the meaning of a stable keyword before a 
procedure that deals with them can be agreed upon...

Regards,
Jason Stubbs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iQCVAwUBQNoNXloikN4/5jfsAQIpbAP/SZwqk5wgWYg8TT/k+oY4v5OW7pBOEltO
RfnPogXrx88B0LXx/XT6ncNBsSKEg3uaqKu0A2W3n2PwZAPKSAylrpNS5rF2YiHm
O6SKcADWHc/RC6Y5QaQMnJDqjgHZrTMW3YyV9lDSo76H3mNiO+bgM2dson3nvWDW
WlWajun9Mw0=
=//lk
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Ciaran McCreesh]

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

On Thu, 24 Jun 2004 08:08:11 +0900 Jason Stubbs <jstubbs@gentoo.org>
wrote:
| My understanding is that one camp believes a stable keyword means that
| the package is stable overall but may have arch-specific issues. The
| other camp believes that a stable keyword has no implications beyond
| the architecture that is marked stable.

No no. Not that it has "no implications", merely that the maintainer's
keyword *does not necessarily* have any significance for other archs.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Aron Griffis]

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

Chris Gianelloni wrote:	[Wed Jun 23 2004, 02:59:46PM EDT]
> All of this has made me curious.  I know to use repoman, and use it for
> any and every commit (except profile, license, and eclasses, of course),
> but are we "supposed" to be using ebump and ekeyword rather than
> adjusting them manually?

No, repoman is required, echangelog is strongly encouraged, ebump and
ekeyword are entirely optional.

That said, you might want to look into them.  They're pretty nice
tools.  They both have man-pages for your reading pleasure.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Aron Griffis]

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

Carsten Lohrke wrote:	[Wed Jun 23 2004, 11:03:56AM EDT]
> > > Just had another thought about the "re-arranging arch" option. How do
> > > you implement this in a differend backend, e.g. a database, Aron?
> >
> > What do you mean here, a backend for the tree, the cache or what?
>
> A possible future - no file tree, but everything stored in a db. When each 
> keyword is a column in a table, you cannot reorder them as in an ebuild

If this were to ever happen, there would be huge changes necessary in
order to import nearly every ebuild into the database.  So I don't
think the question needs to play into this discussion.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Aron Griffis]

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

Donnie Berkholz wrote:	[Wed Jun 23 2004, 03:09:41PM EDT]
> A package maintainer doubles as arch maintainer for that package and
> shouldn't be forced to hold it back from stable on an arch it is stable
> on just because it isn't stable on every arch.
> 
> That kind of freedom from essentially pointless inter-arch dependencies
> is one of the things I enjoy about Gentoo.

Although I like the simplicity of the earlier proposals, I think that
Spyderous hits the nail on the head here.  Many people have been
talking this point back and forth, and both pauldv and jstubbs
recognized that there are two camps on this issue.

I'll be working on another round-up of the current discussion, taking
this into account.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Aron Griffis]

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

Donnie Berkholz wrote:	[Wed Jun 23 2004, 05:13:36PM EDT]
> Here's how I see it. PMs are responsible for the whole package, including
> arch-independent and arch-dependent aspects. Independently, PMs work to
> ensure the arch-independent parts are stable. Together with AMs, the PMs
> work to ensure the arch-dependent aspects are stable.
> 
> Until the day when AMs have equal amounts of time to spend on each package
> as PMs, I don't see this changing.

Well said, Donnie.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Aron Griffis]

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

foser wrote:	[Wed Jun 23 2004, 02:45:28PM EDT]
> 'maintainer arch' + stable state of the ebuild on the 'maintainers arch'
> is the indication of stability, adding an extra line for that is
> duplication. The question here is about how to indicate the maintainers
> arch.

You're right that there would be duplication in most cases.  But these
guys have a good point--tying stability of a package from the PM's
perspective to the arch on which they run isn't necessarily a box we
want to put ourselves in.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Aron Griffis]

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

Ferris McCormick wrote:	[Tue Jun 22 2004, 06:25:43PM EDT]
> If I understand II (which I missed or misread in the first wave of these
> notes), it says something like "A keyword of '+amd64' means that 'the
> maintainer believes that this package is a candidate for stable, and it
> is in fact stable on amd64, which is where the maintainer tested it."
> (And, I suppose, in an unusual situation, the maintainer could use
> just 'amd64' to mean "For critical reasons this has to be stable on
> amd64 even though I the maintainer am not all *that* confident." In
> this case, the maintainer would be wearing ar architecture hat.)
> 
> If my first sentence is close to correct (everything up to the
> hypothetical), my preference is also solution II.

You're correct, and this might untie arch-stability from
package-stability.  Good observation.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Aron Griffis]

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

Hi Ciaran,

Thanks for taking the time to write up this explanation.

Ciaran McCreesh wrote:	[Tue Jun 22 2004, 06:28:29PM EDT]
> <maintainernotes><![CDATA[
> >=foo-1.2 has problems when the alsa USE flag is enabled (see bug
> #12345). Avoiding marking this as stable on x86 until this issue is
> resolved. No other problems known.
> ]]>
> 
> This shows the arch teams that there are specific reasons to stick with
> versions below 1.2 (rather than that the maintainer is just lazy and
> doesn't pay much attention to the package). It also lets sparc
> developers know that they can ignore the maintainer's arch and go ahead
> and keyword later versions if necessary, since ALSA isn't available for
> that arch.

I see your point here.  I'm very concerned about this approach,
though.  First, it isn't checkable by repoman.  Second, it isn't
visible to arch maintainers unless they check for it.  Third, it
implies a green light when the information is missing, when it might
simply be that the package maintainer hasn't had a chance to add the
information to metadata.  Fourth, it's no longer enough for a package
maintainer to close a bug in the bug database, now it's required to
modify metadata.xml to show when major bugs are opened/closed.  Fifth,
this information is already available to arch maintainers by looking
in the bug database (and yes, this last one is part of the reason that
the current system, while not perfect, hasn't fallen apart entirely ;-)

> The information provided is the kind of information arch teams would be
> after when contacting the maintainer to find out why they were keeping
> their arch's stable version down.

*nod*  I agree that the stuff I have proposed so far is only a one-way
communication channel, and it's a unary channel at that.  What I mean
is that the proposals so far are only reliable if STABLE="yes" or
KEYWORDS="+x86" or whichever way you like.  If it's STABLE="no" then
you can't tell whether the maintainer might have been shopping for 9
weeks (was that brandy's record?)

Your proposal provides for much broader communication by caching a
broadcast message in metadata.

> |     Instinctively I'm against it because it requires more work on the
> |     part of the package maintainer, and I'm trying to avoid the extra
> |     work all around.  I *think* that suggestions I and II above both
> |     avoid the implication of meaning by making it explicit.
> |     Regarding providing "much more information", I'm concerned that
> |     could result in duplication of information between the bugs
> |     database and metadata.xml, a duplication that the package
> |     maintainer has to keep updated.
> 
> Regarding the amount of work, it's effectively the same as is required
> for I and II. If a package maintainer *isn't* keeping a close enough
> track of a package to know about the issues then chances are the arch
> teams know just as much as the package maintainer anyway.

Right, that is certainly the case sometimes.  However I disagree about
the amount of work.  You seem to be assuming that a PM has only one or
two packages that they take care of, so it shouldn't be too hard to
update metadata.xml with information like this.  But the fact is that
most package maintainers are working on a large number of packages, a
result of our herd system, natural relationships between packages, and
the simple fact that 20% of the developers do 80% of the work.

I think that whatever solution we choose should create as little extra
work as possible for developers.  (Of course, the hope is that the
extra communication channel and clearer bug responsibility will
actually decrease the amount of work.  That would be ideal!)
Unfortunately I don't think that adding phrases to metadata for that
communication is possible to do without increasing the workload.

> This method (like I and II) has the advantage that if nothing is
> present, then arch teams can carry on using the existing method (ya
> know, the one that's working fine),

*grin*

> and if it *is* there, then the extra
> information that would usually be obtained by pestering people on IRC is
> already present. Contrast this with III, where we end up with a messy
> situation that arch teams don't know whether the first keyword is really
> the maintainer's arch or whether it just happens to be there, and
> whether the maintainer is just not really maintaining the package or
> whether they're holding back for a reason.

I think you're right about III.  I proposed it, liked it, argued for
it, but it has such significant weaknesses that I don't think it is
a viable solution.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Aron Griffis]

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

Jason Huebel wrote:	[Tue Jun 22 2004, 09:06:29PM EDT]
> Another possible solution that hasn't been considered is adding another 
> variable to ebuilds, like so:
> 
> STABLE="yes"

Not a bad suggestion.  The only thing I don't like is adding another
variable.  But perhaps it's better than the other options presented so
far.  I'll consider this in my next round-up.  Thanks.  :-)

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Aron Griffis]

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

Chris Gianelloni wrote:	[Wed Jun 23 2004, 12:08:36PM EDT]
> Would comments in the ebuild not be enough?  Look at the
> vmware-workstation-4.5.2 ebuild for an example.
> 
> I don't see why it would not be easy enough to comment the reasons an
> ebuild might not be marked stable.  Another example that I can think of
> is the xorg-x11 ebuilds.  You can see an obvious TODO list before it is
> considered stable.

I don't think comments would be enough.  Many arch maintainers are
using ekeyword and ignoring the rest of the ebuild, because it is too
much to take the time to read through every ebuild looking for red
flags.  Also, comments make it impossible to use repoman to do the
checking unless they're in a specific format, and at that point you
might as well put things in a variable or in metadata

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Aron Griffis]

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

Paul de Vrieze wrote:	[Wed Jun 23 2004, 06:53:01AM EDT]
> I think that before this all, we first and all need to get absolutely clear 
> what we want to do with these keywords. As a package maintainer I know that 
> it can sometimes be displeasing when other archs mark your package as stable. 
> I do however not think that we need to spend that much effort on the problem.
> 
> If we want to spend the effort we however should first make clear the purpose, 
> not just make clear what the arch maintainer's keyword is without making it 
> clear what is the purpose of this knowledge.

Right now I am going to bed, but I will make sure to include an
explanation of the goal and rationale for change in my next round-up,
which I will send out tomorrow.  Thanks, I didn't mean to be pursuing
something that wasn't clear to everybody.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Alexander Futasz]

On Wed, 23 Jun 2004 20:45:28 +0200, foser wrote:
> 'maintainer arch' + stable state of the ebuild on the 'maintainers
> arch' is the indication of stability

Hahaha. Because software seems to run stable on one architecture doesn't
necessarily mean it is stable on another architecture. It of course
needs to be tested thouroughly on every architecture.

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: summary: proposed solutions to arches/stable problem

[Duncan]

Aron Griffis posted <20040624045157.GH18367@mustard.flatmonk.org>,
excerpted below,  on Thu, 24 Jun 2004 00:51:57 -0400:

> Jason Huebel wrote:	[Tue Jun 22 2004, 09:06:29PM EDT]
>> Another possible solution that hasn't been considered is adding another 
>> variable to ebuilds, like so:
>> 
>> STABLE="yes"
> 
> Not a bad suggestion.  The only thing I don't like is adding another
> variable.  But perhaps it's better than the other options presented so
> far.  I'll consider this in my next round-up.  Thanks.  :-)

What about namespace pollution?  Theoretically, some make file somewhere
might use something that generic.

What about something like gStable=yes, or GENSTABLE=yes?  These make it
*FAR* more unlikely there'll be an accidental namespace collision.

Also, are we going to support the general boolean (or tristate, if one
includes no mark) flexibility of yes/true/1 vs no/false/0?  Or will it
HAVE to be "yes" or "no"?

...

I'm not a Gentoo dev (yet, possibly documentation at some point.. someone
mentioned I might be good at it.. and I DID check the Gentoo development
policy and social contract first thing as I began to investigate Gentoo,
because I intend to be active wherever I'm at, and I'm moving to Gentoo
now), and not particularly good at development per se either, but not
considering namespace pollution in a case such as this just seems to go
against everything I've ever learned on the subject, and given that I was
recently reading comments in the xorg ebuild indicating a similar problem
with it (probably as XFree86) at one point (MAKE_OPTS with or without the
_), using Gentoo namespace specific env-vars should be a basic policy.

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Chris Gianelloni]

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

On Thu, 2004-06-24 at 00:54, Aron Griffis wrote:
> Chris Gianelloni wrote:	[Wed Jun 23 2004, 12:08:36PM EDT]
> > Would comments in the ebuild not be enough?  Look at the
> > vmware-workstation-4.5.2 ebuild for an example.
> > 
> > I don't see why it would not be easy enough to comment the reasons an
> > ebuild might not be marked stable.  Another example that I can think of
> > is the xorg-x11 ebuilds.  You can see an obvious TODO list before it is
> > considered stable.
> 
> I don't think comments would be enough.  Many arch maintainers are
> using ekeyword and ignoring the rest of the ebuild, because it is too
> much to take the time to read through every ebuild looking for red
> flags.  Also, comments make it impossible to use repoman to do the
> checking unless they're in a specific format, and at that point you
> might as well put things in a variable or in metadata

I was bringing up the point that a developer should not be marking a
package stable on their arch without looking for such things.  Many of
us are quite intelligent and don't have to have repoman tell us what to
do.  While it would be nice to have some form of automated check, I
think that for the time being the simplest and quickest solution would
just be to put comments above/below the KEYWORDS for anyone to quickly
see.  There's no need to read the entire ebuild, just skim quickly for
the KEYWORDS line and check for comments right around it.

Now, with all that said, I'd love to see some way to automate this
process, but I'm more of a fan of getting "something working" going
first, then adding polish later, than of sitting around and
bureaucratizing every last detail.  Adding comments is 100% backwards
compatible, requires no extra portage/repoman/e* programming, and is
quickly implemented.  Sounds like a perfect solution for the interim,
and one I plan on continuing to use.  *grin*

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

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

Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Jason Stubbs]

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

On Thursday 24 June 2004 13:55, Aron Griffis wrote:
> Paul de Vrieze wrote:	[Wed Jun 23 2004, 06:53:01AM EDT]
>
> > I think that before this all, we first and all need to get absolutely
> > clear what we want to do with these keywords. As a package maintainer I
> > know that it can sometimes be displeasing when other archs mark your
> > package as stable. I do however not think that we need to spend that much
> > effort on the problem.
> >
> > If we want to spend the effort we however should first make clear the
> > purpose, not just make clear what the arch maintainer's keyword is
> > without making it clear what is the purpose of this knowledge.
>
> Right now I am going to bed, but I will make sure to include an
> explanation of the goal and rationale for change in my next round-up,
> which I will send out tomorrow.  Thanks, I didn't mean to be pursuing
> something that wasn't clear to everybody.

I thank you for your effort and wish you to continue. I just want to say that 
there may or may not be people who are actually unclear. However, what we are 
all aiming at is quality and, to have quality, absolutely nothing can be 
assumed. If you can define this one uncertainty (sp?) and then address the 
issue accordinly, we'll just about be done here.

Regards,
Jason Stubbs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iQCVAwUBQNr/0FoikN4/5jfsAQJb+wQAp9751QhFGDuoSyqtPEsBhYZrJUHmHYrA
exxQLXIhdTuYA9vP9uRFv/EeRFS1yMJv6B2+vCbM3MJ6Iq2LsMVNwG6ZraiSdboW
NGQhHzFX6NqSquko5+tRU6iJVS8nDt+LkdGa2DBl5UjA2FLyEfh+6SoP2pAZjIg8
gLl9dPKDktA=
=LvT/
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: summary: proposed solutions to arches/stable problem

[Jason Huebel]

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

On Thursday 24 June 2004 06:48 am, Duncan wrote:
> What about namespace pollution?  Theoretically, some make file somewhere
> might use something that generic.
>
> What about something like gStable=yes, or GENSTABLE=yes?  These make it
> *FAR* more unlikely there'll be an accidental namespace collision.
>
> Also, are we going to support the general boolean (or tristate, if one
> includes no mark) flexibility of yes/true/1 vs no/false/0?  Or will it
> HAVE to be "yes" or "no"?

Sure, STABLE was just an example.  GENSTABLE, GENTOO_STABLE or EBUILD_STABLE 
or any combination/iteration of that would work.  The point is mainly just to 
avoid changing the behaviour of KEYWORDS, which in turn unnecessarily affects 
users on a simple QA issue.

- -- 
Jason Huebel
Gentoo/amd64 Strategic Lead
Gentoo Developer Relations/Recruiter

GPG Public Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9BA9E230

"Do not weep; do not wax indignant. Understand."
Baruch Spinoza (1632 - 1677)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2waObNgbbJup4jARArG4AJ9verlYi1NuneyPOGOb4HO5QOAnNACfS+DA
n5zXXTVclr3gmxW1dboJ9SA=
=y/4F
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: summary: proposed solutions to arches/stable problem

[Aron Griffis]

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

Duncan wrote:	[Thu Jun 24 2004, 07:48:23AM EDT]
> Aron Griffis posted <20040624045157.GH18367@mustard.flatmonk.org>,
> excerpted below,  on Thu, 24 Jun 2004 00:51:57 -0400:
> 
> > Jason Huebel wrote:	[Tue Jun 22 2004, 09:06:29PM EDT]
> >> Another possible solution that hasn't been considered is adding another 
> >> variable to ebuilds, like so:
> >> 
> >> STABLE="yes"
> > 
> > Not a bad suggestion.  The only thing I don't like is adding another
> > variable.  But perhaps it's better than the other options presented so
> > far.  I'll consider this in my next round-up.  Thanks.  :-)
> 
> What about namespace pollution?  Theoretically, some make file somewhere
> might use something that generic.

Namespace pollution isn't an issue here.  The variables declared at
the top of an ebuild aren't exported to the environment so they are
"invisible" to configure, make, scripts, etc.

That's not the case for CFLAGS, CXXFLAGS and a few others which are
specifically exported.  But most of the variables (like STABLE) are
purely shell variables, not available to sub-processes.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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