On Saturday 04 March 2006 15:45, Danny van Dyk wrote:
Just to throw in my 2 cents into this discussion: I'm all against
die-ing during the update process. However, i think that stopping
before the update process would be the best solution at hand. I'd like
to propose the addition of a
Paul de Vrieze wrote:
On Saturday 04 March 2006 15:45, Danny van Dyk wrote:
Just to throw in my 2 cents into this discussion: I'm all against
die-ing during the update process. However, i think that stopping
before the update process would be the best solution at hand. I'd like
to propose
Mike Frysinger wrote:
On Wednesday 01 March 2006 21:53, Mark Loeser wrote:
Here is my updated version after some feedback from people:
* In case of emergency, or if package maintainers refuse to cooperate,
the QA team may take action themselves to fix the problem.
* The QA team may also
On Fri, 3 Mar 2006 22:44:22 +,
Stuart Herbert [EMAIL PROTECTED] wrote:
Unless a user looks inside the ebuild, they're not going to
understand why the USE flags they've selected has resulted in a
package that doesn't actually have those features.
...
This is going to *create* more support,
On Friday 03 March 2006 23:32, Grant Goodyear wrote:
Stuart Herbert wrote:
I agree. Adopting a policy like this is a low quality solution for
servers. I've no opinion on how this affects desktops, but packages
for servers need to be precise.A policy that says if two USE
flags
On Saturday 04 March 2006 00:29, Ciaran McCreesh wrote:
On Fri, 3 Mar 2006 23:14:41 + Stuart Herbert
[EMAIL PROTECTED] wrote:
| If we're going to do this, then at least we should be implementing a
| consistent standard across all ebuilds. F.ex, when SSL and TLS
| conflict, we should
Hi Thomas,
Am Samstag, 4. März 2006 14:24 schrieb Thomas de Grenier de Latour:
One point of view on this issues is that the ebuilds are wrong, because
they are abusing the said USE flags, and they should rather die. Imho,
it makes sense, but if such a strict policy was applied to every
Hi Ciaran,
On 3/3/06, Ciaran McCreesh [EMAIL PROTECTED] wrote:
And what of gtk vs qt, where for many packages one is clearly the
preferred choice, but which one this is varies between packages? Do
*you* know which GUI is the best option for gvim and why?
No, I don't. But that doesn't mean
Hi Mike,
On 3/4/06, Mike Frysinger [EMAIL PROTECTED] wrote:
bad idea ...
Yes it is a bad idea; policy belongs with users. It shouldn't be
hardcoded into ebuilds, whether across the whole tree or per package.
But ... I realise I'm flogging a dead horse here.
We'll come up with a new revision
Hi Danny,
On 3/4/06, Danny van Dyk [EMAIL PROTECTED] wrote:
Just to throw in my 2 cents into this discussion: I'm all against die-ing
during the update process. However, i think that stopping before the update
process would be the best solution at hand. I'd like to propose the addition
of a
Danny van Dyk [EMAIL PROTECTED] said:
Just to throw in my 2 cents into this discussion: I'm all against die-ing
during the update process. However, i think that stopping before the update
process would be the best solution at hand. I'd like to propose the addition
of a dedicated USE conflict
Stuart Herbert wrote:
[...]
Mark, in the discussions about the QA policy, your fallback
justification always seems to be Trust us. I think this week's
events have put a big dent in the credibility of that argument, if not
holed it below the water line. If the QA team followed processes
On Friday 03 March 2006 15:47, Jakub Moc wrote:
Please, until something is clarified/some consent reached, avoid changing
the docs w/ funny stuff like just flip a coin...
please, get a sense of humor, kthxbye
-mike
--
gentoo-dev@gentoo.org mailing list
Sending this from the right address this time
-g2boojum-
Grant Goodyear wrote:
Jakub Moc wrote:
Please, until something is clarified/some consent reached, avoid changing
the docs w/ funny stuff like just flip a coin...
I don't believe the text is meant to be funny. It's meant (I
On Fri, 3 Mar 2006 22:27:45 +0100
Jakub Moc [EMAIL PROTECTED] wrote:
What kind of point does it get across, exactly?
That you must choose one flag, or set of flags, to take precedence in
such situations, but that how you choose is quite immaterial. If there
is an obvious choice then use it,
Jakub Moc wrote:
Erm, how exactly will you find out that you need to recompile that package
after such extensive build? You'll spend a couple of hours debugging when
your server app stops working? Yay! :P
I had assumed that in such a case the ebuild would output a
scary-looking ewarn that
Stuart Herbert wrote:
I agree. Adopting a policy like this is a low quality solution for
servers. I've no opinion on how this affects desktops, but packages
for servers need to be precise.A policy that says if two USE
flags deliver the same benefits, but conflict, pick one is fine. But
On Fri, 3 Mar 2006 23:31:49 +0100
Jakub Moc [EMAIL PROTECTED] wrote:
Yeah, that's a wonderful message. Let users choose, they are not
idiots and such policy does more harm than good. Period.
You're completely missing the point here. The user has a choice, but if
his set of choices doesn't make
It prevents emerge from crashing out in the middle of what could be a
quite extensive build. Personally, I would rather rebuild one package
to get desired functionality _after_ the emerge completes than have to
fix the flags for that one package to be able to build everything else.
This
Stuart Herbert wrote:
It prevents emerge from crashing out in the middle of what could be a
quite extensive build. Personally, I would rather rebuild one package
to get desired functionality _after_ the emerge completes than have to
fix the flags for that one package to be able to build
Hi Grant,
On 3/3/06, Grant Goodyear [EMAIL PROTECTED] wrote:
Yep. Having a USE flag enabled turns out not to be a guarantee. That
said, package builds do become deterministic, so (for example) if one
needs to know if msmtp was built with openssl or gnutls it is easy
enough to pull the logic
On Fri, 3 Mar 2006 23:14:41 + Stuart Herbert
[EMAIL PROTECTED] wrote:
| If we're going to do this, then at least we should be implementing a
| consistent standard across all ebuilds. F.ex, when SSL and TLS
| conflict, we should have a standard saying that all ebuilds will
| consistenly favour
The whole argument here is that bailing out with conflicting use flags
breaks some extensive compiles. So you suppose users will be sitting in
front of their monitor and stare on the screen waiting for a scary warning?
No, they won't. And even if they were, how exactly is that warning better
No
On Friday 03 March 2006 18:14, Stuart Herbert wrote:
If we're going to do this, then at least we should be implementing a
consistent standard across all ebuilds. F.ex, when SSL and TLS
conflict, we should have a standard saying that all ebuilds will
consistenly favour one over the other.
Alec Warner wrote:
The whole argument here is that bailing out with conflicting use flags
breaks some extensive compiles. So you suppose users will be sitting in
front of their monitor and stare on the screen waiting for a scary
warning?
No, they won't. And even if they were, how exactly is
Hi Mark,
This draft seems to be effectively the same as the last one.
On 3/2/06, Mark Loeser [EMAIL PROTECTED] wrote:
* The QA team's purpose is to provide cross-team assistance in keeping
the tree in a good state. This is done primarily by finding and pointing
out issues to maintainers
On Thursday 02 March 2006 03:53, Mark Loeser wrote:
Here is my updated version after some feedback from people:
* The QA team's purpose is to provide cross-team assistance in keeping
the tree in a good state. This is done primarily by finding and
pointing out issues to maintainers and,
On Thu, 2006-03-02 at 09:01 +, Stuart Herbert wrote:
[snip]
* There's nothing in this policy about end users. If this QA team is
not *focused* on delivering benefit to end users, then (as has
happened this week) it becomes a self-serving team, focused instead on
what can only be described
Paul de Vrieze [EMAIL PROTECTED] said:
* Just because breaking policy breaks a QA tool, but is guaranteed to
never break itself (formatting policy, like space vs. tab etc.) does not
increase the severity of the breakage.
I had hoped something like this would have just been understood to
On Thursday 02 March 2006 14:09, Mark Loeser wrote:
Paul de Vrieze [EMAIL PROTECTED] said:
* Just because breaking policy breaks a QA tool, but is guaranteed to
never break itself (formatting policy, like space vs. tab etc.)
does not increase the severity of the breakage.
I had hoped
On Thu, 2 Mar 2006 11:35:12 +0100 Paul de Vrieze [EMAIL PROTECTED]
wrote:
| * Just because breaking policy breaks a QA tool, but is guaranteed to
| never break itself (formatting policy, like space vs. tab etc.)
| does not increase the severity of the breakage.
I'd argue against this one. See,
Lance Albertson [EMAIL PROTECTED] said:
Ciaran McCreesh wrote:
I'd argue against this one. See, it's possible to deliberately
circumvent some of repoman's checks by doing weird whitespace and syntax
trickery. There's also no way to fix repoman short of writing a fully
functional bash
On Thu, 02 Mar 2006 11:35:34 -0600 Lance Albertson
[EMAIL PROTECTED] wrote:
| QA shouldn't have to depend on the tools you use.
Sure. However, the tree is far too large to check manually for many
things. If we were to do the Sekrit Tool's IUSE check manually, for
example, we'd still be in
Ciaran McCreesh wrote:
On Thu, 02 Mar 2006 11:35:34 -0600 Lance Albertson
[EMAIL PROTECTED] wrote:
| QA shouldn't have to depend on the tools you use.
Sure. However, the tree is far too large to check manually for many
things. If we were to do the Sekrit Tool's IUSE check manually, for
On Thu, 02 Mar 2006 19:09:28 +0100 Simon Stelling [EMAIL PROTECTED]
wrote:
| Ciaran McCreesh wrote:
| On Thu, 02 Mar 2006 11:35:34 -0600 Lance Albertson
| [EMAIL PROTECTED] wrote:
| | QA shouldn't have to depend on the tools you use.
|
| Sure. However, the tree is far too large to check
Ciaran McCreesh [EMAIL PROTECTED] said:
It's a heck of a lot easier to do if you assume that developers will
use sane syntax. Where developers don't use sane syntax, the only way
to deal with it is to check it by hand. We don't have enough developers
to do that.
I don't see where anyone is
Ciaran McCreesh wrote:
On Thu, 02 Mar 2006 19:09:28 +0100 Simon Stelling [EMAIL PROTECTED]
wrote:
| Ciaran McCreesh wrote:
| On Thu, 02 Mar 2006 11:35:34 -0600 Lance Albertson
| [EMAIL PROTECTED] wrote:
| | QA shouldn't have to depend on the tools you use.
|
| Sure. However, the tree
On Thu, 02 Mar 2006 13:15:48 -0600 Lance Albertson
[EMAIL PROTECTED] wrote:
| It should be a basic thing to expect the QA tool knows how to bail out
| correctly and resume looking for more important critical issues.
Sure. But what if more important critical issues are being masked by
weird
On Thursday 02 March 2006 17:45, Ciaran McCreesh wrote:
On Thu, 2 Mar 2006 11:35:12 +0100 Paul de Vrieze [EMAIL PROTECTED]
wrote:
| * Just because breaking policy breaks a QA tool, but is guaranteed to
| never break itself (formatting policy, like space vs. tab etc.)
| does not increase
On Thu, 2 Mar 2006 21:10:02 +0100 Paul de Vrieze [EMAIL PROTECTED]
wrote:
| I'm also convinced that deliberate circumvention is easy to detect.
In that case, please provide a list of cases where !arch? flags are
being used to circumvent repoman warnings, where the correct solution
would be to use
On Thursday 02 March 2006 19:28, Mark Loeser wrote:
Ciaran McCreesh [EMAIL PROTECTED] said:
It's a heck of a lot easier to do if you assume that developers will
use sane syntax. Where developers don't use sane syntax, the only way
to deal with it is to check it by hand. We don't have enough
On 02-03-2006 20:19:19 +, Ciaran McCreesh wrote:
On Thu, 2 Mar 2006 21:10:02 +0100 Paul de Vrieze [EMAIL PROTECTED]
wrote:
| I'm also convinced that deliberate circumvention is easy to detect.
In that case, please provide a list of cases where !arch? flags are
being used to circumvent
On Thursday 02 March 2006 21:19, Ciaran McCreesh wrote:
On Thu, 2 Mar 2006 21:10:02 +0100 Paul de Vrieze [EMAIL PROTECTED]
wrote:
| I'm also convinced that deliberate circumvention is easy to detect.
In that case, please provide a list of cases where !arch? flags are
being used to
On Thu, 2 Mar 2006 21:29:30 +0100 Grobian [EMAIL PROTECTED] wrote:
| On 02-03-2006 20:19:19 +, Ciaran McCreesh wrote:
| On Thu, 2 Mar 2006 21:10:02 +0100 Paul de Vrieze [EMAIL PROTECTED]
| wrote:
| | I'm also convinced that deliberate circumvention is easy to
| | detect.
|
| In that
On Thu, 2 Mar 2006 21:38:33 +0100 Paul de Vrieze [EMAIL PROTECTED]
wrote:
| Then explain people that doing this is not the way.
Have done, repeatedly, as have many others.
| And is it really a qualityissue? In all cases? There must be cases
| where the problem is package + arch + useflag
Stuart Herbert [EMAIL PROTECTED] said:
Hi Mark,
This draft seems to be effectively the same as the last one.
I'm sorry, but personally I don't see how this draft is substantially
different from the one posted originally. It looks like you've
decided not to address the points I raised
On Thursday 02 March 2006 21:51, Ciaran McCreesh wrote:
On Thu, 2 Mar 2006 21:38:33 +0100 Paul de Vrieze [EMAIL PROTECTED]
wrote:
| Then explain people that doing this is not the way.
Have done, repeatedly, as have many others.
| And is it really a qualityissue? In all cases? There must be
On Thu, 2006-03-02 at 20:49 +, Ciaran McCreesh wrote:
Now, you've heard that dropping keywords is bad. But you have a clever
idea, and make the dep alsa? ( !sparc? ( alsa libraries ) ). This gets
past repoman just fine.
STOP As any arch can tell you, that's never stopped me - *IF* you do
On Thu, 02 Mar 2006 16:19:58 -0500 Michael Cummings
[EMAIL PROTECTED] wrote:
| On Thu, 2006-03-02 at 20:49 +, Ciaran McCreesh wrote:
| Now, you've heard that dropping keywords is bad. But you have a
| clever idea, and make the dep alsa? ( !sparc? ( alsa libraries ) ).
| This gets past
On Thursday 02 March 2006 16:19, Michael Cummings wrote:
On Thu, 2006-03-02 at 20:49 +, Ciaran McCreesh wrote:
Now, you've heard that dropping keywords is bad. But you have a clever
idea, and make the dep alsa? ( !sparc? ( alsa libraries ) ). This gets
past repoman just fine.
STOP As
On Thursday 02 March 2006 04:01, Stuart Herbert wrote:
* There is no proposal for a process to formulate, and gain wide
approval for new QA standards. This week, there's been an example of
the QA team documenting a QA standard *after* a bug was raised about a
QA violation ... and then that
On Wednesday 01 March 2006 21:53, Mark Loeser wrote:
Here is my updated version after some feedback from people:
* In case of emergency, or if package maintainers refuse to cooperate,
the QA team may take action themselves to fix the problem.
* The QA team may also offer to fix obvious
Mike Frysinger [EMAIL PROTECTED] said:
one thing i dont think we give enough emphasis to is that our tools arent
perfect ... sometimes we utilize QA violations to work around portage
limitations ... if you want to see some really sweet hacks, review any of the
toolchain related ebuilds and
Mark Loeser wrote:
Here is my updated version after some feedback from people:
* In the case of disagreement on policy among QA members, the majority
of established QA members must agree with the action.
What is an Established QA member?
I guess this won't be reviewed by the council
Alec Warner [EMAIL PROTECTED] said:
Mark Loeser wrote:
Here is my updated version after some feedback from people:
* In the case of disagreement on policy among QA members, the majority
of established QA members must agree with the action.
What is an Established QA member?
Listed on
Mark Loeser [EMAIL PROTECTED] said:
Here is my updated version after some feedback from people:
* The QA team's purpose is to provide cross-team assistance in keeping
the tree in a good state. This is done primarily by finding and pointing
out issues to maintainers and, where necessary,
Daniel Ostrow [EMAIL PROTECTED] said:
The above also has to be done on a case by case basis, if hardmasking a
package would cause wide tree breakage itself then another choice has to
be made.
I agree. We aren't here to make a situation even worse, and we
acknowledge that we won't always get
[deleted]
All seems fair enough, but please fix portage qa issues before this
policy is applied (see bug http://bugs.gentoo.org/show_bug.cgi?id=123733).
signature.asc
Description: OpenPGP digital signature
58 matches
Mail list logo
