On 7/9/2005 3:10:12, Stuart Longland ([EMAIL PROTECTED]) wrote:
Ciaran McCreesh wrote:
On Mon, 5 Sep 2005 9:44:41 +0200 Kevin F. Quinn [EMAIL PROTECTED]
wrote:
| On 5/9/2005 1:29:57, Ciaran McCreesh ([EMAIL PROTECTED]) wrote:
| On Mon, 5 Sep 2005 1:12:54 +0200 Kevin F. Quinn
| [EMAIL
On Wed, 2005-09-07 at 08:46 +0200, Kevin F. Quinn wrote:
If nobody on x86 is using a given package, is there a need to worry
about marking it ~x86/x86?
When I said 'All', I didn't mean to include stuff that's not in x86.
What I was trying to get at, was the idea that if the x86 arch team
5.9.2005, 22:09:28, Stuart Herbert wrote:
I kept PHP5 masked for those 14 months, and (as Jakub and others can
confirm) most of the feedback has been limited to unmask that
puppy (sometimes put in stronger terms ;-) There were some bugs from
users who had found issues, but not many.
Well,
On Sun, 2005-09-04 at 22:46 +0200, Simon Stelling wrote:
Stuart Herbert wrote:
I've no personal problem with arch teams sometimes needing to do their
own thing, provided it's confined to a specific class of package.
Outside of the core packages required to boot maintain a platform,
when
Chris Gianelloni wrote:
On Sun, 2005-09-04 at 22:46 +0200, Simon Stelling wrote:
Stuart Herbert wrote:
I've no personal problem with arch teams sometimes needing to do their
own thing, provided it's confined to a specific class of package.
Outside of the core packages required to boot
On Sun, Sep 04, 2005 at 10:39:44PM +0100, Stuart Herbert wrote:
At the moment, the only way for a package maintainer to mark a package
stable is to mark it stable on a real arch. Creating the maintainer
arch solves this very problem.
Yes, but please don't call it the maintainer arch. This
On Tue, 6 Sep 2005 17:22:09 +0200 Sven Vermeulen [EMAIL PROTECTED]
wrote:
| On Sun, Sep 04, 2005 at 10:39:44PM +0100, Stuart Herbert wrote:
| At the moment, the only way for a package maintainer to mark a
| package stable is to mark it stable on a real arch. Creating the
| maintainer arch
On Tuesday 06 September 2005 19:11, Joshua Baergen wrote:
Sven Vermeulen wrote:
MAINTENANCE=~x86 # Maintainer uses x86, package not deemed stable
I would even suggest not indicating maintainer arch at all. If ATs are
going to be responsible for keywording we should blackbox the process to
On Tue, 2005-09-06 at 12:25 -0400, Luis F. Araujo wrote:
Chris Gianelloni wrote:
On Sun, 2005-09-04 at 22:46 +0200, Simon Stelling wrote:
Stuart Herbert wrote:
I've no personal problem with arch teams sometimes needing to do their
own thing, provided it's confined to a
On Tue, 2005-09-06 at 17:22 +0200, Sven Vermeulen wrote:
On Sun, Sep 04, 2005 at 10:39:44PM +0100, Stuart Herbert wrote:
At the moment, the only way for a package maintainer to mark a package
stable is to mark it stable on a real arch. Creating the maintainer
arch solves this very problem.
Chris Gianelloni wrote:
You'd have a really long list of maintenance architectures for me. Like
I said, I don't use a single machine. The idea of *any* architecture
being my primary one just doesn't really fit. There's also the simple
fact that it doesn't matter *at all* what the maintainer
Chris Gianelloni wrote:
On Tue, 2005-09-06 at 12:25 -0400, Luis F. Araujo wrote:
Chris Gianelloni wrote:
On Sun, 2005-09-04 at 22:46 +0200, Simon Stelling wrote:
Stuart Herbert wrote:
I've no personal problem with arch teams sometimes needing to do their
own
On Tue, 06 Sep 2005 12:35:31 -0700 Donnie Berkholz
[EMAIL PROTECTED] wrote:
| Chris Gianelloni wrote:
| You'd have a really long list of maintenance architectures for me.
| Like I said, I don't use a single machine. The idea of *any*
| architecture being my primary one just doesn't really fit.
On Tue, 2005-09-06 at 20:47 +0100, Ciaran McCreesh wrote:
On Tue, 06 Sep 2005 12:35:31 -0700 Donnie Berkholz
[EMAIL PROTECTED] wrote:
| Chris Gianelloni wrote:
| You'd have a really long list of maintenance architectures for me.
| Like I said, I don't use a single machine. The idea of
On Tue, 06 Sep 2005 23:19:43 +0200 Martin Schlemmer [EMAIL PROTECTED]
wrote:
| What about !arch or something (to connect with the one reply to the
| summary thread) to really indicate unstable on that arch? Should
| cover those things that sorda work on the arch, but you rather want
| developers
Ciaran McCreesh wrote:
On Tue, 06 Sep 2005 23:19:43 +0200 Martin Schlemmer [EMAIL PROTECTED]
wrote:
| What about !arch or something (to connect with the one reply to the
| summary thread) to really indicate unstable on that arch? Should
| cover those things that sorda work on the arch, but you
Ciaran McCreesh wrote:
On Tue, 06 Sep 2005 23:19:43 +0200 Martin Schlemmer [EMAIL PROTECTED]
wrote:
| What about !arch or something (to connect with the one reply to the
| summary thread) to really indicate unstable on that arch? Should
| cover those things that sorda work on the arch, but you
On Tue, 2005-09-06 at 22:31 +0100, Ciaran McCreesh wrote:
On Tue, 06 Sep 2005 23:19:43 +0200 Martin Schlemmer [EMAIL PROTECTED]
wrote:
| What about !arch or something (to connect with the one reply to the
| summary thread) to really indicate unstable on that arch? Should
| cover those things
On Tue, 06 Sep 2005 17:46:40 -0400 Stephen P. Becker
[EMAIL PROTECTED] wrote:
| This is true, however it requires users to possibly make a gazillion
| entries in their /etc/portage/package.unmask if they want to use a
| lot of what are considered truly unstable packages.
There are dozens of
On Tue, 06 Sep 2005 17:41:35 -0400 warnera6 [EMAIL PROTECTED]
wrote:
| Speaking of flexabilty, are there tools out there to perform look-ups
| into p.masks to figure out why things are masked?
emerge -pv
--
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail:
Ciaran McCreesh wrote:
On Tue, 06 Sep 2005 17:41:35 -0400 warnera6 [EMAIL PROTECTED]
wrote:
| Speaking of flexabilty, are there tools out there to perform look-ups
| into p.masks to figure out why things are masked?
emerge -pv
emerge -pv would be a cludge for what many are after. If I
On 9/6/05, Martin Schlemmer [EMAIL PROTECTED] wrote:
arch- in theory stable~arch - in theory should work, but needs testing-arch - do not work at all
Just out of curiosity, why are there know broken packages in portage?
Wouldn't -arch packages best be handled outside of the official
portage tree
Dave Shanker wrote:
On 9/6/05, *Martin Schlemmer* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
arch - in theory stable
~arch - in theory should work, but needs testing
-arch - do not work at all
Just out of curiosity, why are there know broken packages in portage?
What
Ciaran McCreesh wrote:
On Mon, 5 Sep 2005 9:44:41 +0200 Kevin F. Quinn [EMAIL PROTECTED]
wrote:
| On 5/9/2005 1:29:57, Ciaran McCreesh ([EMAIL PROTECTED]) wrote:
| On Mon, 5 Sep 2005 1:12:54 +0200 Kevin F. Quinn
| [EMAIL PROTECTED]
| wrote:
| | 3) All packages need to be assigned an x86
On Sunday 04 September 2005 23:39, Stuart Herbert wrote:
Hi Grant,
On Sun, 2005-09-04 at 15:53 -0500, Grant Goodyear wrote:
I'm still thinking about the concept of a maint option. This
question I can answer, however. It's not unheard of for a package
with a lot of dependencies to be
On Mon, Sep 05, 2005 at 01:12:54AM +0200, Kevin F. Quinn [EMAIL PROTECTED]
wrote:
We seem to be heading towards a situation where the x86 arch
team do all marking of stuff stable on x86. This I like.
Some observations - these may be phrased in the affirmative
but please take them as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul de Vrieze schrieb:
| I agree with this. It should also be a simple, backwards compatible
| solution. Just don't call it maintainer, but maint or something like
| that ;-)
In case this should really be done, please call it 'stable'...
Danny
- --
Danny van Dyk wrote:
Paul de Vrieze schrieb:
| I agree with this. It should also be a simple, backwards compatible
| solution. Just don't call it maintainer, but maint or something like
| that ;-)
In case this should really be done, please call it 'stable'...
so we get ~stable? ;)
--
Simon
Ciaran McCreesh wrote:
If it isn't fit to be marked stable, it shouldn't be out of
package.mask. ~arch means candidate for going stable after more
testing, not might work.
It's a bit of both. When you put a package into ~arch, it's in testing, so
that says it needs further testing since there
On Monday 05 September 2005 20:21, Simon Stelling wrote:
Ciaran McCreesh wrote:
If it isn't fit to be marked stable, it shouldn't be out of
package.mask. ~arch means candidate for going stable after more
testing, not might work.
It's a bit of both. When you put a package into ~arch, it's
On 5/9/2005 13:41:54, Jason Stubbs ([EMAIL PROTECTED]) wrote:
On Monday 05 September 2005 20:21, Simon Stelling wrote:
Ciaran McCreesh wrote:
If it isn't fit to be marked stable, it shouldn't be out of
package.mask. ~arch means candidate for going stable after more
testing, not might
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kevin F. Quinn wrote:
Well, it strikes me that most if not all of the organisational questions
are not relevant to a tester; the only technical question that is
relevant is 9 (keyword marking), and even that would be reworded for the
tester
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Martin wrote:
I'm not sure I like this. I think it would be too slow. I'd rather have
a concept of maintainer arch (the reason I still like the old keyword
ordering, because there was at least *some* idea of maintainer arch. In
fact, I used to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kevin F. Quinn wrote:
On 5/9/2005 13:41:54, Jason Stubbs ([EMAIL PROTECTED]) wrote:
On Monday 05 September 2005 20:21, Simon Stelling wrote:
Ciaran McCreesh wrote:
If it isn't fit to be marked stable, it shouldn't be out of
package.mask. ~arch
On Mon, 5 Sep 2005 11:21:03 +0100 Tom Martin [EMAIL PROTECTED] wrote:
| Maybe I'm seeing this all wrong, but the fact is, the number of
| packages that need x86 arch team lovin' are pretty small, despite the
| number of overall keyworded packages being large. I don't think the
| x86 arch team
On Mon, 5 Sep 2005 9:44:41 +0200 Kevin F. Quinn [EMAIL PROTECTED]
wrote:
| On 5/9/2005 1:29:57, Ciaran McCreesh ([EMAIL PROTECTED]) wrote:
| On Mon, 5 Sep 2005 1:12:54 +0200 Kevin F. Quinn
| [EMAIL PROTECTED]
| wrote:
| | 3) All packages need to be assigned an x86 arch team member
| |
On Mon, 5 Sep 2005 20:41:54 +0900 Jason Stubbs [EMAIL PROTECTED]
wrote:
| Testing of the ebuild rather than of the package, though. This is the
| point where people sometimes get confused.
You can't consider an ebuild stable unless the code it installs is also
reasonably stable.
--
Ciaran
Kevin F. Quinn wrote:
On 5/9/2005 1:29:57, Ciaran McCreesh ([EMAIL PROTECTED]) wrote:
On Mon, 5 Sep 2005 1:12:54 +0200 Kevin F. Quinn [EMAIL PROTECTED]
wrote:
| 3) All packages need to be assigned an x86 arch team member
|responsible.
Why?
Because if only the x86 arch team can
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Luis F. Araujo wrote:
| Kevin F. Quinn wrote:
|
| On 5/9/2005 1:29:57, Ciaran McCreesh ([EMAIL PROTECTED]) wrote:
|
|
| On Mon, 5 Sep 2005 1:12:54 +0200 Kevin F. Quinn [EMAIL PROTECTED]
| wrote:
| | 3) All packages need to be assigned an x86 arch
Mike Doty wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Luis F. Araujo wrote:
| Kevin F. Quinn wrote:
|
| On 5/9/2005 1:29:57, Ciaran McCreesh ([EMAIL PROTECTED]) wrote:
|
|
| On Mon, 5 Sep 2005 1:12:54 +0200 Kevin F. Quinn
[EMAIL PROTECTED]
| wrote:
| | 3) All packages need to be
On Mon, 2005-09-05 at 17:01 +0100, Ciaran McCreesh wrote:
Doesn't solve the coordination problem.
Agreed. If there's going to be an x86 team, it needs to be a full arch
team, and not some /dev/null that pretends to be one.
Best regards,
Stu
--
Stuart Herbert
On Sun, 2005-09-04 at 20:09 -0500, Daniel Goller wrote:
agreed talk/communcation is fine, if the maintainer is only trying to flex
muscles and does not have a good reason, the arch team ought to be able to do
what is best for gentoo and not be shot down by a (hm) stubborn(?)
maintainer, if
On Mon, 05 Sep 2005 20:20:28 +0100 Stuart Herbert [EMAIL PROTECTED]
wrote:
| Still, it'd only be fair for the arch team to assume the support
| burden for the package version if they do this w/out the support of
| the package maintainer.
If the package maintainer doesn't think their package is
On Sun, 2005-09-04 at 20:12 -0500, Daniel Goller wrote:
sounds like you suggest to trick ~arch users into testing unripe
ebuilds/bumps/versions by sending it into ~arch to get the testing done while
someone in a chroot would be much better equipped for doing the testing with?
No.
You've
Ciaran McCreesh wrote:
| I'm asking that you assume any support burden that you create. It
| only seems fair.
Stabling a package which is not in packahe.mask is only a support
burden if package maintainers are abusing ~arch.
I absolutely agree with you, the only point is:
People are abusing
On Mon, 2005-09-05 at 21:34 +0100, Ciaran McCreesh wrote:
Stabling a package which is not in packahe.mask is only a support
burden if package maintainers are abusing ~arch.
If you don't agree that it should be stable, don't move it out out of
package.mask. ~arch is for stable candidates, and
On Mon, 05 Sep 2005 21:52:56 +0100 Stuart Herbert [EMAIL PROTECTED]
wrote:
| I've put my point across, but you're determined not to address it
| directly. I guess there's nothing else to say on this topic.
Bah, I'm not changing the subject at all. It's the same issue. Marking
something as stable
On Mon, 2005-09-05 at 22:42 +0200, Simon Stelling wrote:
Ciaran McCreesh wrote:
| I'm asking that you assume any support burden that you create. It
| only seems fair.
Stabling a package which is not in packahe.mask is only a support
burden if package maintainers are abusing ~arch.
Dear all,
Here's a GLEP that I'm thinking about right now. It's not yet
official, since I'd like to get some feedback beforehand (which helps to
ensure that I'm not abusing my GLEP-editor powers). If you have
additional arguments either pro or con, please send them my way so that
I may
On Sun, 4 Sep 2005 09:37:11 -0500 Grant Goodyear [EMAIL PROTECTED]
wrote:
| There will be a considerable one-time cost involved in establishing a
| robust x86 arch team.
Justify this please. If there is a cost associated, the details of this
cost should be provided.
--
Ciaran McCreesh : Gentoo
On Sunday 04 September 2005 10:37 am, Grant Goodyear wrote:
This policy for x86 is quite different from how every other arch marks
packages stable. For the non-x86 archs, each arch has a specific arch
team which is responsible for moving packages from ``~arch`` to ``arch``.
This approach has
Hi Grant,
On Sun, 2005-09-04 at 09:37 -0500, Grant Goodyear wrote:
Dear all,
Here's a GLEP that I'm thinking about right now. It's not yet
official, since I'd like to get some feedback beforehand (which helps to
ensure that I'm not abusing my GLEP-editor powers). If you have
additional
On Sun, 04 Sep 2005 20:48:52 +0100 Stuart Herbert [EMAIL PROTECTED]
wrote:
| Introduce a new arch keyword maint, to turn the concept of the
| maintainer arch from an intangible into something real. Package
| maintainers can then mark packages ~maint or maint as required,
| and leave the real arch
On Sun, 2005-09-04 at 14:16 -0500, Grant Goodyear wrote:
* Having bodies on [EMAIL PROTECTED] is just the starting point. The
more difficult part will be convincing people that it is in their
best interests to do things this way. Similarly, what do we do with
devs who refuse? All
On Sun, 2005-09-04 at 21:05 +0100, Ciaran McCreesh wrote:
Workable for a certain category of packages so long as it's advisory
only.
Workable for the vast majority of packages in the tree I expect.
Arch teams need to be allowed to override maintainers where
appropriate,
Why not talk to
Stuart Herbert wrote:
The introduction of the x86 arch
team will, at some point, turn the x86 arch team into a bottleneck (just
like all the other arch teams already are)
A possible way to alleviate this is proactivity on the maintainer's
part. Our current rule for going testing-stable is
Vapier wrote: [Sun Sep 04 2005, 01:00:41PM CDT]
this isnt quite true ... non-x86 archs usually take their queues for
when packages should be moved to stable from the maintainer of the
package
Perfectly reasonable.
in other words, arch teams generally defer to maintainers (and rightly
so) as
On Sun, 4 Sep 2005 15:53:07 -0500 Grant Goodyear [EMAIL PROTECTED]
wrote:
| I'm still thinking about the concept of a maint option. This
| question I can answer, however. It's not unheard of for a package
| with a lot of dependencies to be marked stable when one of the
| dependencies has not yet
On Sun, 2005-09-04 at 14:40 -0600, Joshua Baergen wrote:
A possible way to alleviate this is proactivity on the maintainer's
part. Our current rule for going testing-stable is 30 days. If we
could alert the arch teams x number of days in advance they could
test
it before the end of the
On Sunday 04 September 2005 22:53, Grant Goodyear wrote:
I tend to think that's fair. At least in my view, the goal is not to
minimize the importance of package maintainers, but simply to separate
package maintainance from tree maintainance.
That's right. I think this is good, as a maintainer.
On Sun, 4 Sep 2005 15:43:11 -0500
Grant Goodyear [EMAIL PROTECTED] wrote:
I agree that the arch teams shouldn't be marking packages stable in
advance of when the the maintainer thinks it's ready. At the same
time, it's the respective arch teams, as owners of their entire
stable tree, who (in
Hi Grant,
On Sun, 2005-09-04 at 15:53 -0500, Grant Goodyear wrote:
I'm still thinking about the concept of a maint option. This
question I can answer, however. It's not unheard of for a package with
a lot of dependencies to be marked stable when one of the dependencies
has not yet been so
On Sun, 2005-09-04 at 21:57 +0100, Ciaran McCreesh wrote:
Yeah, foser's on holiday. Good time to push the GLEP through.
How typical of you to try and drag this discussion down into something
personal :( If you keep feeling the need to do this, do everyone a
favour and keep your mouth shut
On Sunday 04 September 2005 23:35, Jason Wever wrote:
For the most part, this makes sense, However we do have times where a
particular arch team may need to stabilize a package sooner in the case
where earlier versions are broken.
Why this remembers me xine-lib on sparc? :))
--
Diego
On Sun, 2005-09-04 at 21:59 +0100, Ciaran McCreesh wrote:
If it isn't fit to be marked stable, it shouldn't be out of
package.mask. ~arch means candidate for going stable after more
testing, not might work.
Agreed, but we both know that it's just not how many devs work atm.
Perhaps that is a
On Sun, 2005-09-04 at 15:45 -0600, Jason Wever wrote:
This is the current policy, though it gets violated quite often.
Maybe the answer is to have separate trees for arches and general
packages then? That would be one solution.
(Although not one that I'd personally prefer. I'd rather the
On Sun, 04 Sep 2005 22:54:02 +0100
Stuart Herbert [EMAIL PROTECTED] wrote:
Maybe the answer is to have separate trees for arches and general
packages then? That would be one solution.
(Although not one that I'd personally prefer. I'd rather the package
maintainers learned to work within
On Sun, 04 Sep 2005 22:43:20 +0100 Stuart Herbert [EMAIL PROTECTED]
wrote:
| On Sun, 2005-09-04 at 21:57 +0100, Ciaran McCreesh wrote:
| Yeah, foser's on holiday. Good time to push the GLEP through.
|
| How typical of you to try and drag this discussion down into something
| personal :( If you
On Mon, 5 Sep 2005 1:12:54 +0200 Kevin F. Quinn [EMAIL PROTECTED]
wrote:
| 3) All packages need to be assigned an x86 arch team member
|responsible.
Why?
| 6) I notice the amd64 team requre their arch testers to
|take the ebuild quiz; I think this is a bit harsh, as
|arch testers are
On Mon, 2005-09-05 at 01:12 +0200, Kevin F. Quinn wrote:
6) I notice the amd64 team requre their arch testers to
take the ebuild quiz; I think this is a bit harsh, as
arch testers are regular users without commit access to
CVS etc. A simpler quiz targetted at ensuring the arch
On Sunday 04 September 2005 03:59 pm, Ciaran McCreesh wrote:
On Sun, 04 Sep 2005 21:26:37 +0100 Stuart Herbert [EMAIL PROTECTED]
wrote:
| Arch teams need to be allowed to override maintainers where
| appropriate,
|
| Why not talk to the package maintainers instead, and convince them
|
On Sunday 04 September 2005 04:52 pm, Stuart Herbert wrote:
On Sun, 2005-09-04 at 21:59 +0100, Ciaran McCreesh wrote:
If it isn't fit to be marked stable, it shouldn't be out of
package.mask. ~arch means candidate for going stable after more
testing, not might work.
Agreed, but we both
72 matches
Mail list logo
