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 the
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 dedic
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 con
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
> o
On Saturday 04 March 2006 23:45, Danny van Dyk wrote:
> 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
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 revisio
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 mea
4.3.2006, 2:57:51, 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
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
> eb
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 s
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
> > fla
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 s
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 m
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 exa
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.
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 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 fav
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
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 everythi
3.3.2006, 23:32:36, Grant Goodyear wrote:
> 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 th
> > 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.
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 m
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.
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 no
3.3.2006, 23:25:13, Stephen Bennett wrote:
> 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 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,
3.3.2006, 22:54:25, Grant Goodyear wrote:
>>> http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?root=gentoo&r1=1.31&r2=1.32
>>>
>>> What's the above again? QA policy? How does user benefit from flipping a
>>> coin wrt choosing a functionality? Sigh..
3.3.2006, 22:51:39, Mike Frysinger wrote:
> 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
Sorry, I don't find anyt
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
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
On 3/3/06, Jakub Moc <[EMAIL PROTECTED]> wrote:
> > It gets the point across effectively. I don't see your problem.
>
> What kind of point does it get across, exactly? That flipping a coin or
> forcing your personal preference is a better solution than letting users
> decide what kind of functional
3.3.2006, 22:19:33, Stephen Bennett wrote:
> On Fri, 3 Mar 2006 21:47:22 +0100
> Jakub Moc <[EMAIL PROTECTED]> wrote:
>> Please, until something is clarified/some consent reached, avoid
>> changing the docs w/ funny stuff like "just flip a coin"...
>>
>> http://www.gentoo.org/cgi-bin/viewcvs.cg
On Fri, 3 Mar 2006 21:47:22 +0100
Jakub Moc <[EMAIL PROTECTED]> wrote:
> Please, until something is clarified/some consent reached, avoid
> changing the docs w/ funny stuff like "just flip a coin"...
>
> http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.
3.3.2006, 6:31:17, Mark Loeser wrote:
> 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, r
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 process
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
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
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 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.
>
>
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 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.
>
As any arch can tell you, that's never stopped me - *IF* you do
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? Ther
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 rai
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 specif
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
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 c
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 circu
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 hav
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 us
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 incr
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 synta
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. H
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
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 ch
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, f
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 app-so
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
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 the severity of the breakage.
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,
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 ha
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 t
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 descri
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
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
[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
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 g
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 neces
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"?
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 cou
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, taking direct action.
* In case of emergen
70 matches
Mail list logo
