[gentoo-dev] Closing bugs

[gentoo-dev] Closing bugs

[justin]

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

Hi all,

is the following comment an adequate way to close bugs with
RESOLVED/INVALID? If so, I will change the way I handle bugs and use it too.

""
virtual/os-headers:  2.6.35 (sys-kernel/linux-headers)
ACCEPT_KEYWORDS="amd64"

you mix stable & unstable -> your problem
""

Cheers Justin


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] Closing bugs

["Paweł Hajdan, Jr."]

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

On 9/11/10 11:51 AM, justin wrote:
> is the following comment an adequate way to close bugs with
> RESOLVED/INVALID? If so, I will change the way I handle bugs and use it too.
> 
> ""
> virtual/os-headers:  2.6.35 (sys-kernel/linux-headers)
> ACCEPT_KEYWORDS="amd64"
> 
> you mix stable & unstable -> your problem
> ""

I think that closing as INVALID is fine in that case, but would say
"please do not mix stable and unstable" instead of "your problem".

We should be polite when handling bugs.

Paweł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Closing bugs

[Petteri Räty]

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

On 09/11/2010 09:51 PM, justin wrote:
> Hi all,
> 
> is the following comment an adequate way to close bugs with
> RESOLVED/INVALID? If so, I will change the way I handle bugs and use it too.
> 
> ""
> virtual/os-headers:  2.6.35 (sys-kernel/linux-headers)
> ACCEPT_KEYWORDS="amd64"
> 
> you mix stable & unstable -> your problem
> ""
> 

Only if the problem will not eventually manifest itself with a pure
~arch or arch setup. Even then if it's easy to fix I would myself fix it
although we don't officially support it.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] Closing bugs

[Ciaran McCreesh]

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

On Sat, 11 Sep 2010 20:51:56 +0200
justin <jlec@gentoo.org> wrote:
> is the following comment an adequate way to close bugs with
> RESOLVED/INVALID? If so, I will change the way I handle bugs and use
> it too.
> 
> ""
> virtual/os-headers:  2.6.35 (sys-kernel/linux-headers)
> ACCEPT_KEYWORDS="amd64"
> 
> you mix stable & unstable -> your problem

Would the problem also occur if the user used unstable, but hadn't
gotten around to updating every single package on their system all in
one go?

Or does the problem only occur if you mix keywords and ignore
dependencies?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Closing bugs

[Richard Freeman]

On 09/11/2010 03:04 PM, Ciaran McCreesh wrote:
> Or does the problem only occur if you mix keywords and ignore
> dependencies?
>

I think that if a package doesn't work in a mixed environment, that 
points to a likely dependency problem.  Sooner or later there is a good 
chance it will bite somebody.

Personally, I try to keep package dependencies correct.  If a package in 
unstable needs a library version in unstable, I depend on that version - 
not on the library itself.  Then we won't get burned in six months when 
I forget all about this or am not around and things start going stable 
in the wrong order.

Sure, if the issue is something really exotic maybe we should just say 
"don't do that," but usually there is a better fix.

Personally I welcome these kinds of bugs, as they're the easiest way to 
uncover non-obvious dependency issues that might otherwise make their 
way into stable.  Maybe we can't fix them all, but we ought not to just 
dismiss them out of hand.  I certainly wouldn't want to see the 
bug-wranglers screening for them, for instance.

Rich

Re: [gentoo-dev] Closing bugs

[Alistair Bush]

> On 09/11/2010 03:04 PM, Ciaran McCreesh wrote:
> > Or does the problem only occur if you mix keywords and ignore
> > dependencies?
> 
> I think that if a package doesn't work in a mixed environment, that
> points to a likely dependency problem.  Sooner or later there is a good
> chance it will bite somebody.
> 
> Personally, I try to keep package dependencies correct.  If a package in
> unstable needs a library version in unstable, I depend on that version -
> not on the library itself.  Then we won't get burned in six months when
> I forget all about this or am not around and things start going stable
> in the wrong order.
> 
> Sure, if the issue is something really exotic maybe we should just say
> "don't do that," but usually there is a better fix.
> 
> Personally I welcome these kinds of bugs, as they're the easiest way to
> uncover non-obvious dependency issues that might otherwise make their
> way into stable.  Maybe we can't fix them all, but we ought not to just
> dismiss them out of hand.  I certainly wouldn't want to see the
> bug-wranglers screening for them, for instance.
> 
> Rich

++

There should be nothing stopping a user from running a mixed arch/~arch 
system.   Those problems just point to our dependency information not being 
recorded correctly.   It might be understandable that this info can be 
incredibly hard to get correct but that doesn't mean it isn't a valid bug.

- Alistair

[gentoo-dev] Re: Closing bugs

[Ryan Hill]

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

On Sun, 12 Sep 2010 20:59:25 +1200
Alistair Bush <ali_bush@gentoo.org> wrote:


> There should be nothing stopping a user from running a mixed arch/~arch 
> system.   Those problems just point to our dependency information not being 
> recorded correctly.   It might be understandable that this info can be 
> incredibly hard to get correct but that doesn't mean it isn't a valid bug.

It's invalid as soon as you bring system-set packages into the mix, which
falls outside of dependency correctness.

The trouble is knowing if this applies in the situation you're looking into.


-- 
fonts, gcc-porting,             we hold our breath, we spin around the world
toolchain, wxwidgets            you and me cling to the outside of the earth
@ gentoo.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Closing bugs

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1503 bytes --]

On Saturday, September 11, 2010 22:51:23 Ryan Hill wrote:
> On Sun, 12 Sep 2010 20:59:25 +1200 Alistair Bush wrote:
> > There should be nothing stopping a user from running a mixed arch/~arch
> > system.   Those problems just point to our dependency information not
> > being recorded correctly.   It might be understandable that this info
> > can be incredibly hard to get correct but that doesn't mean it isn't a
> > valid bug.
> 
> It's invalid as soon as you bring system-set packages into the mix, which
> falls outside of dependency correctness.
> 
> The trouble is knowing if this applies in the situation you're looking
> into.

indeed.  for people who disagree, feel free to go through every single stable 
package in the tree that breaks with glibc-2.12, or linux-headers-2.6.35, or 
make-3.82, or xxx and add a blocker against the newer versions of these 
packages.  and then do it every time we get a new version.

or, let's keep our sanity and continue doing what we've been doing over the 
years -- stabilize newer versions of packages that do work with the stable & 
unstable versions of the packages they build against.

people who install unstable core system packages way before we're interested 
in stabilizing and then file bugs that only apply to stable get INVALID->their 
problem.  especially when a simple bugzilla search would have told them that 
their issue is already fixed in the unstable version of whatever package is 
failing for them.
-mike

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

Re: [gentoo-dev] Closing bugs

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 596 bytes --]

On Saturday, September 11, 2010 15:04:45 Ciaran McCreesh wrote:
> On Sat, 11 Sep 2010 20:51:56 +0200 justin wrote:
> > is the following comment an adequate way to close bugs with
> > RESOLVED/INVALID? If so, I will change the way I handle bugs and use
> > it too.
> > 
> > ""
> > virtual/os-headers:  2.6.35 (sys-kernel/linux-headers)
> > ACCEPT_KEYWORDS="amd64"
> > 
> > you mix stable & unstable -> your problem
> 
> Would the problem also occur if the user used unstable, but hadn't
> gotten around to updating every single package on their system all in
> one go?

no
-mike

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

Re: [gentoo-dev] Closing bugs

[Maciej Mrozowski]

[-- Attachment #1: Type: Text/Plain, Size: 1951 bytes --]

On Saturday 11 of September 2010 20:51:56 justin wrote:
> Hi all,
> 
> is the following comment an adequate way to close bugs with
> RESOLVED/INVALID? If so, I will change the way I handle bugs and use it
> too.
> 
> ""
> virtual/os-headers:  2.6.35 (sys-kernel/linux-headers)
> ACCEPT_KEYWORDS="amd64"
> 
> you mix stable & unstable -> your problem
> ""

This is common misconception.

Let me quote myself from on of Diego's blogs, accusing me of not giving a crap 
about quality wrt FEATURES=test.

Some people say that mixing testing and stable subtrees is ‘broken’ and not 
supported.

It is because they apparently have no idea how package stabilization process 
works.

‘tinderbox’ idea of full ~arch integration tests is broken by design!

Why? Gentoo is distribution with rolling updates and packages being stabilized 
are hand picked from ~arch and integrated within existing stable environment 
(along with possible dependencies).

Now the question arises – since Gentoo stable is our ultimate target release 
(and not ~arch) - what is the point in testing how these packages interact 
with full testing ~arch? The answer is NONE!

If any, following tests should be run:

 - regression tests – ONLY within full stable arch, typical tinderbox of just 
chroot would fit there well, it could prevent issues like Gentoo LiveCD 
autobuilds failing since 8 April…

 - integration tests – in similar way stabilization process is performed:
stable system as a base, picking packages or package sets for tests along with 
their possible dependencies (best version visible, if not visible within 
stable arch, then best visible within testing arch or some other algorithm, 
usually just relying on ebuild dependencies) and testing whether it works so 
that stabilization process is a formality.

Running ~arch as 'test' platform is in many cases counter productive.

-- 
regards
MM

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