Mike Frysinger wrote:
On Monday 26 September 2005 12:01 am, Andrew Muraco wrote:
1) would ?arch become the old ~arch, if it was implemented?
2) would people actually try to run a full ?arch system?
3) #2, would it be possible without breakage?
if we went with a testing mask it'd mean that
In response to all replies Thus far,
I as a User,
I expect that arch works (no matter what) - no arguments there
I assume that ~arch will work 95% of the time.
I never ever touch anything in p.mask.
Now, where do we put packages that could work for most users, but they
might not work for the
On Monday 26 September 2005 12:01 am, Andrew Muraco wrote:
1) would ?arch become the old ~arch, if it was implemented?
2) would people actually try to run a full ?arch system?
3) #2, would it be possible without breakage?
if we went with a testing mask it'd mean that users would be forced to
On Friday 16 September 2005 23:51, Mike Frysinger wrote:
that's the problem, there's no way to flag which packages should be
consulted and which ones are a non-issue
This indeed kind of sums up my point.
Paul
--
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage:
On Sat, Sep 17, 2005 at 04:17:10PM -0400, Mike Frysinger wrote:
i really want to get away from the idea of 'package.mask is for testing
packages' ... its current dual role as both masking 'testing' packages and
'broken' packages is wrong imo
we dont want to try reeducating our users to not
Oh, and for the sake of completeness, also from
http://www.gentoo.org/doc/en/handbook/hb-portage-branches.xml
--snip--
1.c. Using Masked Packages
The package.unmask file
The Gentoo developers do not support the use of these files. Please
exercise due caution when doing so. Support requests
On Sun, 18 Sep 2005 08:46:37 +0200 Wernfried Haas [EMAIL PROTECTED]
wrote:
| Doesn't exactly sound like packages in ~arch should be ready to enter
| arch after 30 days (and or the other QA requirements). If someone
| wants to change that, that would be a major change to Gentoo,
| especially as it
Wernfried Haas [EMAIL PROTECTED] wrote:
Coming from the user side (forums) i fully agree. Common sense among
the users always used to be:
arch: stable
~arch: testing
p.mask: broken
And this is what it should be IMHO.
The solutions so far seem to introduce only a new testing layer, already
On Sun, Sep 18, 2005 at 01:32:32PM +0100, Ciaran McCreesh wrote:
Uhm. That's current policy and has been current policy for several
years. No GLEP needed.
If that's currenty policy, why does the handbook say something quite
different then? Does it need to be fixed?
If so, i truly don't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wernfried Haas wrote:
On Sun, Sep 18, 2005 at 01:32:32PM +0100, Ciaran McCreesh wrote:
Uhm. That's current policy and has been current policy for several
years. No GLEP needed.
If that's currenty policy, why does the handbook say something
On Sun, 18 Sep 2005 15:01:13 +0200 Wernfried Haas [EMAIL PROTECTED]
wrote:
| On Sun, Sep 18, 2005 at 01:32:32PM +0100, Ciaran McCreesh wrote:
| Uhm. That's current policy and has been current policy for several
| years. No GLEP needed.
|
| If that's currenty policy, why does the handbook say
050918 Alec Warner wrote:
Personally I like Ciaran's wording of the levels.
~arch - Canidate for Stable on Arch
arch - Stable on Arch
/spectate
As a mere user, that's how I read '~arch',
ie 'not known to be defective, but use at your own risk for now',
while 'arch' means 'the relevant
On Fri, Sep 16, 2005 at 04:16:22PM -0400, Aron Griffis wrote:
Vapier wrote:[Fri Sep 16 2005, 03:15:26PM EDT]
not really ... sometimes you want to keep a package in unstable
forever (like the cvs snapshots i make of e17), or until you work
some quirks/features out for a new revbump which you
How about if the maintainer wants wider testing, i.e. wants to move
it out of package.mask and into ~arch but isn't confident it's ready
yet for arch, adding a string variable to ebuilds indicating why the
maintainer considers the package unstable, eg:
UNSTABLE=#100435, #100345, unconfirmed break
On Sat, Sep 17, 2005 at 11:28:03AM +0200, Kevin F. Quinn wrote:
The 30-day could be calculated from the $Header: of ebuilds that have
no UNSTABLE, or where it's empty.
Doesn't work for N arches keywording, or ebuild dev doing minor
syntax touch ups.
~harring
pgp9GsjkqH1mC.pgp
Description:
On 17/9/2005 11:34:56, Brian Harring ([EMAIL PROTECTED]) wrote:
On Sat, Sep 17, 2005 at 11:28:03AM +0200, Kevin F. Quinn wrote:
The 30-day could be calculated from the $Header: of ebuilds that have
no UNSTABLE, or where it's empty.
Doesn't work for N arches keywording, or ebuild dev doing
On Saturday 17 September 2005 05:28 am, Kevin F. Quinn wrote:
How about if the maintainer wants wider testing, i.e. wants to move
it out of package.mask and into ~arch but isn't confident it's ready
yet for arch, adding a string variable to ebuilds indicating why the
maintainer considers the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Frysinger wrote:
On Saturday 17 September 2005 05:28 am, Kevin F. Quinn wrote:
How about if the maintainer wants wider testing, i.e. wants to move
it out of package.mask and into ~arch but isn't confident it's ready
yet for arch, adding a
On Saturday 17 September 2005 05:59 pm, Alec Warner wrote:
Mike Frysinger wrote:
On Saturday 17 September 2005 05:28 am, Kevin F. Quinn wrote:
How about if the maintainer wants wider testing, i.e. wants to move
it out of package.mask and into ~arch but isn't confident it's ready
yet for
On Fri, 2005-09-16 at 19:42 +0200, Paul de Vrieze wrote:
On Friday 16 September 2005 00:20, Mike Frysinger wrote:
actually this is came up in the meeting as something we would like to see
spelled out explicitly ... either as a GLEP itself or as a policy update to
current stabilization
On Fri, Sep 16, 2005 at 08:14:08PM +0200, Martin Schlemmer wrote:
On Fri, 2005-09-16 at 19:42 +0200, Paul de Vrieze wrote:
On Friday 16 September 2005 00:20, Mike Frysinger wrote:
actually this is came up in the meeting as something we would like to see
spelled out explicitly ... either
Paul de Vrieze wrote:
Ok, I do think that we will need a way for the maintainer to indicate that the
package is stable. I'd be happy to leave stabilizing out of my hands, but I
wouldn't want my packages to be stabilized before I deem it stable.
That's exactly what the maint keyword is for.
On Fri, 16 Sep 2005 19:42:36 +0200 Paul de Vrieze [EMAIL PROTECTED]
wrote:
| Ok, I do think that we will need a way for the maintainer to indicate
| that the package is stable. I'd be happy to leave stabilizing out of
| my hands, but I wouldn't want my packages to be stabilized before I
| deem it
On Fri, 16 Sep 2005 20:48:45 +0200 Paul de Vrieze [EMAIL PROTECTED]
wrote:
| Take it out of package.mask and leave it for thirty
| (package-dependent) days. If there is a pressing (eg security)
| reason for it to go to stable sooner than would normally be
| expected, file a bug and Cc: the
Ciaran McCreesh wrote:
Well, if it's in ~arch it's a candidate to go to stable after further
testing. If a package maintainer isn't prepared to have a package moved
to stable, they shouldn't take it out of package.mask.
The 30 days are just a rule, there are enough packages which surely need a
On Friday 16 September 2005 03:02 pm, Ciaran McCreesh wrote:
On Fri, 16 Sep 2005 20:48:45 +0200 Paul de Vrieze [EMAIL PROTECTED]
wrote:
| Take it out of package.mask and leave it for thirty
| (package-dependent) days. If there is a pressing (eg security)
| reason for it to go to stable
On Fri, 16 Sep 2005 21:12:56 +0200 Simon Stelling [EMAIL PROTECTED]
wrote:
| Ciaran McCreesh wrote:
| Well, if it's in ~arch it's a candidate to go to stable after
| further testing. If a package maintainer isn't prepared to have a
| package moved to stable, they shouldn't take it out of
On Fri, 16 Sep 2005 15:15:26 -0400 Mike Frysinger [EMAIL PROTECTED]
wrote:
| not really ... sometimes you want to keep a package in unstable
| forever (like the cvs snapshots i make of e17), or until you work
| some quirks/features out for a new revbump which you would want stable
Those should be
Vapier wrote:[Fri Sep 16 2005, 03:15:26PM EDT]
not really ... sometimes you want to keep a package in unstable
forever (like the cvs snapshots i make of e17), or until you work
some quirks/features out for a new revbump which you would want
stable
Why wouldn't you put these in package.mask?
Paul de Vrieze wrote:[Fri Sep 16 2005, 04:11:14PM EDT]
Those should be in package.mask. ~arch is for candidates for arch that
haven't yet proven themselves.
It's often the case that those ebuilds in principle work, but there
are other reasons for not marking stable yet. Some packages for
On Friday 16 September 2005 03:34 pm, Ciaran McCreesh wrote:
On Fri, 16 Sep 2005 15:15:26 -0400 Mike Frysinger [EMAIL PROTECTED]
wrote:
| not really ... sometimes you want to keep a package in unstable
| forever (like the cvs snapshots i make of e17), or until you work
| some quirks/features
On Fri, 2005-16-09 at 16:21 -0400, Aron Griffis wrote:
Paul de Vrieze wrote:[Fri Sep 16 2005, 04:11:14PM EDT]
Those should be in package.mask. ~arch is for candidates for arch that
haven't yet proven themselves.
It's often the case that those ebuilds in principle work, but there
are
On Fri, 16 Sep 2005 22:17:20 +0200 Carsten Lohrke [EMAIL PROTECTED]
wrote:
| On Friday 16 September 2005 21:34, Ciaran McCreesh wrote:
| Those should be in package.mask. ~arch is for candidates for arch
| that haven't yet proven themselves.
|
| No. Your idea how it should work simply doesn't
On Friday 16 September 2005 04:25 pm, Daniel Ostrow wrote:
His point (and it's an unfortunately valid one) as I understand it is
that our user base has been (mis)educated to avoid packages in p.mask
for fear of breaking things too badly. As such it gets an inherently far
smaller test base then
On Friday 16 September 2005 04:44 pm, Ciaran McCreesh wrote:
On Fri, 16 Sep 2005 16:33:13 -0400 Mike Frysinger [EMAIL PROTECTED]
wrote:
| ok, e17 packages dont count here. however, your hardcore view i
| still dont buy. how about the baselayout-1.9.x - baselayout-1.11.x
| stabilization
On Fri, 16 Sep 2005 16:59:56 -0400 Mike Frysinger [EMAIL PROTECTED]
wrote:
| baselayout is an example, any package can be used here (although not
| many are as critical)
|
| i'm saying that the maintainer may have a certain idea of when the
| package is ready for stable (a target feature set,
Ciaran McCreesh wrote:
There is nothing in this view that says consulting the package
maintainer is not part of the stable decision-making process for arch
teams.
So do I have to ask the maintainer first everytime I want mark a package stable?
Is that what you are currently doing?
--
Simon
On Friday 16 September 2005 22:38, Ciaran McCreesh wrote:
That's not my idea. That's policy. I just happen to a) have actually
read what policy says and b) agree with it.
First: I know you're proposing this regularly, but please show me the policy -
I'm sure your interpretation doesn't match
On Fri, 16 Sep 2005 23:20:58 +0200 Simon Stelling [EMAIL PROTECTED]
wrote:
| Ciaran McCreesh wrote:
| There is nothing in this view that says consulting the package
| maintainer is not part of the stable decision-making process for
| arch teams.
|
| So do I have to ask the maintainer first
On Fri, 16 Sep 2005 23:23:35 +0200 Carsten Lohrke [EMAIL PROTECTED]
wrote:
| On Friday 16 September 2005 22:38, Ciaran McCreesh wrote:
| That's not my idea. That's policy. I just happen to a) have actually
| read what policy says and b) agree with it.
|
| First: I know you're proposing this
On Fri, 2005-09-16 at 22:34 +0100, Ciaran McCreesh wrote:
There is a difference between using package.mask and ~arch for
ebuilds. The use of ~arch denotes an ebuild requires testing. The use
of package.mask denotes that the application or library itself is
deemed unstable.
| Second: a)
On Fri, 16 Sep 2005 23:41:21 +0200 Patrick Lauer [EMAIL PROTECTED]
wrote:
| Good time for package maintainers to start following policy
| properly, eh?
| Good time for policy to be adapted to match reality ;-)
Reality is that most people do exactly what policy says. Most bumps
don't warrant a
On Friday 16 September 2005 04:43 pm, Mike Frysinger wrote:
On Friday 16 September 2005 04:25 pm, Daniel Ostrow wrote:
His point (and it's an unfortunately valid one) as I understand it is
that our user base has been (mis)educated to avoid packages in p.mask
for fear of breaking things too
On Friday 16 September 2005 05:26 pm, Ciaran McCreesh wrote:
On Fri, 16 Sep 2005 23:20:58 +0200 Simon Stelling [EMAIL PROTECTED]
wrote:
| Ciaran McCreesh wrote:
| There is nothing in this view that says consulting the package
| maintainer is not part of the stable decision-making process
On Fri, 2005-09-16 at 16:59 -0400, Mike Frysinger wrote:
On Friday 16 September 2005 04:44 pm, Ciaran McCreesh wrote:
On Fri, 16 Sep 2005 16:33:13 -0400 Mike Frysinger [EMAIL PROTECTED]
wrote:
| ok, e17 packages dont count here. however, your hardcore view i
| still dont buy. how
On Sep 16, 2005, at 4:50 PM, Mike Frysinger wrote:
actually, going with say 'testing.mask' instead of '?arch' may be
better ...
reinforce the fact that this is a package-level issue rather than
arch-specific
I like that concept. A lot less communication overhead, and addresses
most of
On Friday 16 September 2005 05:57 pm, Martin Schlemmer wrote:
On Fri, 2005-09-16 at 16:59 -0400, Mike Frysinger wrote:
On Friday 16 September 2005 04:44 pm, Ciaran McCreesh wrote:
On Fri, 16 Sep 2005 16:33:13 -0400 Mike Frysinger [EMAIL PROTECTED]
wrote:
| ok, e17 packages dont
On Fri, Sep 16, 2005 at 05:50:39PM -0400, Mike Frysinger wrote:
actually, going with say 'testing.mask' instead of '?arch' may be better ...
reinforce the fact that this is a package-level issue rather than
arch-specific
Let me get things straight. We would want this because it's the least
On Friday 16 September 2005 23:50, Mike Frysinger wrote:
actually, going with say 'testing.mask' instead of '?arch' may be better
... reinforce the fact that this is a package-level issue rather than
arch-specific
-mike
That's nearly as bad as having to deal with package.mask all the time.
On Friday 16 September 2005 23:26, Ciaran McCreesh wrote:
No. You *can* ask the package maintainer, if you feel that such a move
would be useful and productive.
No. There're lot of issues an arch maintainer not necessarily knows about.
Without a way to indicate which ebuild is good, the whole
On Friday 16 September 2005 23:57, Martin Schlemmer wrote:
We still have KEYWORDS=-*.
I'd appreciate, if we disallow that and all use package.mask.
Carsten
pgpanBD00AO4P.pgp
Description: PGP signature
On Sat, 17 Sep 2005 00:43:02 +0200 Carsten Lohrke [EMAIL PROTECTED]
wrote:
| Good time for package maintainers to start following policy
| properly, eh?
|
| I'm sorry, not your idea of this policy.
Policy is rather specific about it. It's not a matter of interpretation
at all.
--
Ciaran
On Saturday 17 September 2005 01:00, Ciaran McCreesh wrote:
Policy is rather specific about it. It's not a matter of interpretation
at all.
That I disagree should prove that this is not a case. It's one thing to
consider an application to just work for the user and another having e.g.
the
On Thu, 2005-15-09 at 16:51 -0400, Aron Griffis wrote:
3. glep40: Standardizing arch keywording across all archs
Vote asked by Grant Goodyear
Approved.
What does that glep mean anyways ? Appart from the creation of the x86
team, is there any action to be taken?
- Is the maint keyword
On Thursday 15 September 2005 05:57 pm, Chris Gianelloni wrote:
On Thu, 2005-09-15 at 17:25 -0400, Olivier Crete wrote:
- Does it mean that devs who are not part of the x86 team can't move
packages from ~x86 to x86 ?
Correct. They can, however, make previous arrangements with the x86
arch
On Friday 16 September 2005 05:51, Aron Griffis wrote:
Regarding GLEP 31, the council is in favor of enforcement ASAP,
provided nano is confirmed to be capable of compliance. That will set
the bar to require UTF-8 capable editors for portage work.
Confirmed.
--
Jason Stubbs
56 matches
Mail list logo
