[gentoo-dev] Maintainer needed: dev-libs/icu

[gentoo-dev] Maintainer needed: dev-libs/icu

[Mike Gilbert]

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

This library is used for processing Unicode text in several high-profile
packages, including Chromium and other Webkit browsers, PHP, boost, and
many more.

Fair warning: ICU tends to break several packages with every major
release, so thorough testing is needed when bumping it.

This package is currently being maintained by proxy by a former Gentoo
developer, Arfrever. Given this package's potential to cause problems,
this situation is not ideal.

It would be really great if an active Gentoo developer would step
forward and take care of this one.

--
Mike Gilbert


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

Re: [gentoo-dev] Maintainer needed: dev-libs/icu

[Arfrever Frehtes Taifersar Arahesis]

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

2012-10-28 22:14:15 Mike Gilbert napisał(a):
> This library is used for processing Unicode text in several high-profile
> packages, including Chromium and other Webkit browsers, PHP, boost, and
> many more.
> 
> Fair warning: ICU tends to break several packages with every major
> release, so thorough testing is needed when bumping it.
> 
> This package is currently being maintained by proxy by a former Gentoo
> developer, Arfrever. Given this package's potential to cause problems,
> this situation is not ideal.
> 
> It would be really great if an active Gentoo developer would step
> forward and take care of this one.

I am actively maintaining ICU and test many reverse dependencies with new versions of ICU
(using a not package.masked version of GCC).

Members of proxy-maintainers team or others actively commit fixes/updates, so there
is no need to change current situation.

-- 
Arfrever Frehtes Taifersar Arahesis

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

Re: [gentoo-dev] Maintainer needed: dev-libs/icu

[Brian Harring]

On Sun, Oct 28, 2012 at 10:35:01PM +0100, Arfrever Frehtes Taifersar Arahesis wrote:
> 2012-10-28 22:14:15 Mike Gilbert napisa??(a):
> > This library is used for processing Unicode text in several high-profile
> > packages, including Chromium and other Webkit browsers, PHP, boost, and
> > many more.
> > 
> > Fair warning: ICU tends to break several packages with every major
> > release, so thorough testing is needed when bumping it.
> > 
> > This package is currently being maintained by proxy by a former Gentoo
> > developer, Arfrever. Given this package's potential to cause problems,
> > this situation is not ideal.
> > 
> > It would be really great if an active Gentoo developer would step
> > forward and take care of this one.
> 
> I am actively maintaining ICU and test many reverse dependencies with new versions of ICU
> (using a not package.masked version of GCC).
> 
> Members of proxy-maintainers team or others actively commit fixes/updates, so there
> is no need to change current situation.

Yeah... I don't agree with that.  Floppym wouldn't be looking 
for a new maintainer if that was accurate.

The package has been cranky enough in parallel with revdeps breaking 
everytime it's bumped that this needs a dev watching it, rather than 
whichever random proxy-maintainer member snags that version.

Anyone got the spare cycles for it?

~harring

Re: [gentoo-dev] Maintainer needed: dev-libs/icu

[Christoph Junghans]

2012/10/29 Brian Harring <ferringb@gmail.com>:
> On Sun, Oct 28, 2012 at 10:35:01PM +0100, Arfrever Frehtes Taifersar Arahesis wrote:
>> 2012-10-28 22:14:15 Mike Gilbert napisa??(a):
>> > This library is used for processing Unicode text in several high-profile
>> > packages, including Chromium and other Webkit browsers, PHP, boost, and
>> > many more.
>> >
>> > Fair warning: ICU tends to break several packages with every major
>> > release, so thorough testing is needed when bumping it.
>> >
>> > This package is currently being maintained by proxy by a former Gentoo
>> > developer, Arfrever. Given this package's potential to cause problems,
>> > this situation is not ideal.
>> >
>> > It would be really great if an active Gentoo developer would step
>> > forward and take care of this one.
>>
>> I am actively maintaining ICU and test many reverse dependencies with new versions of ICU
>> (using a not package.masked version of GCC).
>>
>> Members of proxy-maintainers team or others actively commit fixes/updates, so there
>> is no need to change current situation.
>
> Yeah... I don't agree with that.  Floppym wouldn't be looking
> for a new maintainer if that was accurate.
>
> The package has been cranky enough in parallel with revdeps breaking
> everytime it's bumped that this needs a dev watching it, rather than
> whichever random proxy-maintainer member snags that version.
>
> Anyone got the spare cycles for it?
If Arfrever keeps maintaining it for a while, I will take it.

Christoph

>
> ~harring
>



-- 
Christoph Junghans
http://dev.gentoo.org/~ottxor/

Re: [gentoo-dev] Maintainer needed: dev-libs/icu

[Diego Elio Pettenò]

On 29/10/2012 10:37, Christoph Junghans wrote:
> If Arfrever keeps maintaining it for a while, I will take it.

Do remember that whatever you commit, _You_ take responsibility for it.
After a screwup, the answer "I didn't do anything, I just committed what
Arfrever gave me" is not a good answer.

In particular, if I hear such an answer from anybody (be it for icu or
something else, be it for a minor inconsistency or a total fuckup), I'll
be requesting devrel to re-evaluate their commit rights, as they are
missing the understanding of "you're responsible for whatever you commit".

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Maintainer needed: dev-libs/icu

[Rich Freeman]

On Mon, Oct 29, 2012 at 2:00 PM, Diego Elio Pettenò
<flameeyes@flameeyes.eu> wrote:
> In particular, if I hear such an answer from anybody (be it for icu or
> something else, be it for a minor inconsistency or a total fuckup), I'll
> be requesting devrel to re-evaluate their commit rights, as they are
> missing the understanding of "you're responsible for whatever you commit".

While I do agree in principle, I think that talking about going to
devrel over "minor inconsistencies" is over-the-top.

Devs committing for proxies should be reviewing ebuilds, and also
applying some kind of QA (make sure it works, get feedback from
testers, etc).  However, mistakes can and will happen, and that's OK.
I'll take a package that has a mistake twice a year over a package
that isn't in the tree at all any day.

It seems like many of the ICU issues are upstream-related.  If your
library breaks on every release then somebody clearly doesn't
understand the purpose of sonames.  That puts anybody maintaining the
package at a distro level in a really bad position.

I think what is most needed here is a maintainer that can just
coordinate with the various downstream projects.  I don't care as much
whether ICU is perfectly consistent as long as projects like chromium
have a chance to test things out and catch issues before they hit the
tree.  That is actually part of the job of a proxy maintainer.

Rich

Re: [gentoo-dev] Maintainer needed: dev-libs/icu

[Diego Elio Pettenò]

On 29/10/2012 11:10, Rich Freeman wrote:
> While I do agree in principle, I think that talking about going to
> devrel over "minor inconsistencies" is over-the-top.

It's not about the inconsistencies, it's about the excuse. If the
maintainer owns up to the mistake, that's fine by me, shit happens and
so on. If the maintainer tries to cover behind "I'm just proxying", then
I'll be pissed.

> I'll take a package that has a mistake twice a year over a package
> that isn't in the tree at all any day.

That's fine if it's a fringe package or one that wouldn't get to the
tree otherwise — I agree with the spirit and methods. It's _not_ fine
for a package that, yes, only has 50 dependencies, but every time it
breaks everything goes KO.

> It seems like many of the ICU issues are upstream-related.  If your
> library breaks on every release then somebody clearly doesn't
> understand the purpose of sonames.  That puts anybody maintaining the
> package at a distro level in a really bad position.

The problem with ICU is worse than you expect. For once, with version
50, it changes ABI (but not soname as far as I can tell) depending on
which compiler you build it with. Yes, this is pretty much fucked up.

> I think what is most needed here is a maintainer that can just
> coordinate with the various downstream projects.  I don't care as much
> whether ICU is perfectly consistent as long as projects like chromium
> have a chance to test things out and catch issues before they hit the
> tree.  That is actually part of the job of a proxy maintainer.

Agreed. At the same time, we should have learnt that Arfrever is unable
to take up that job, given the repeated issues we've been having with
almost everything he maintained. Which is why we need to find someone else.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Maintainer needed: dev-libs/icu

[Alexandre Rostovtsev]

On Mon, 2012-10-29 at 11:35 -0700, Diego Elio Pettenò wrote:
> The problem with ICU is worse than you expect. For once, with version
> 50, it changes ABI (but not soname as far as I can tell) depending on
> which compiler you build it with. Yes, this is pretty much fucked up.

It's even worse than that: if you switch compilers, the declared API in
icu-50 headers will not match the ABI of the icu binary. I've just filed
https://bugs.gentoo.org/show_bug.cgi?id=440156 after hitting a linking
failure when building libreoffice using gcc-4.7 against icu-50 which had
been built with gcc-4.6.

[gentoo-dev] Re: Maintainer needed: dev-libs/icu

[Ryan Hill]

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

On Mon, 29 Oct 2012 15:39:14 -0400
Alexandre Rostovtsev <tetromino@gentoo.org> wrote:

> On Mon, 2012-10-29 at 11:35 -0700, Diego Elio Pettenò wrote:
> > The problem with ICU is worse than you expect. For once, with version
> > 50, it changes ABI (but not soname as far as I can tell) depending on
> > which compiler you build it with. Yes, this is pretty much fucked up.
> 
> It's even worse than that: if you switch compilers, the declared API in
> icu-50 headers will not match the ABI of the icu binary. I've just filed
> https://bugs.gentoo.org/show_bug.cgi?id=440156 after hitting a linking
> failure when building libreoffice using gcc-4.7 against icu-50 which had
> been built with gcc-4.6.

Christ on a $#@%! crutch.  You can NOT auto-enable C++11 in your library based
on a configure test and then stuff flags that are not supported by previous
compiler versions into pkg-config for library consumers.  Somebody sane
please fix this.


-- 
gcc-porting
toolchain, wxwidgets          we were never more here, expanse getting broader
@ gentoo.org                          but bigger boats been done by less water

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

Re: [gentoo-dev] Re: Maintainer needed: dev-libs/icu

[Graham Murray]

Ryan Hill <dirtyepic@gentoo.org> writes:

> Christ on a $#@%! crutch.  You can NOT auto-enable C++11 in your library based
> on a configure test and then stuff flags that are not supported by previous
> compiler versions into pkg-config for library consumers.  Somebody sane
> please fix this.

Though is it not normally a reasonable assumption that the library
consumers will be built with the same or later compiler version as the
library? In which case it does no harm.

Re: [gentoo-dev] Re: Maintainer needed: dev-libs/icu

[Diego Elio Pettenò]

On 31/10/2012 23:13, Graham Murray wrote:
> Though is it not normally a reasonable assumption that the library
> consumers will be built with the same or later compiler version as the
> library? In which case it does no harm.

Not really, it's not.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: Maintainer needed: dev-libs/icu

[Peter Stuge]

Graham Murray wrote:
> > Christ on a $#@%! crutch.  You can NOT auto-enable C++11 in your library based
> > on a configure test and then stuff flags that are not supported by previous
> > compiler versions into pkg-config for library consumers.  Somebody sane
> > please fix this.
> 
> Though is it not normally a reasonable assumption that the library
> consumers will be built with the same or later compiler version as
> the library?

Well what about the consumers that have been built already? :)

Now, if all consumers could be rebuilt as part of the build of the
library (EAPI discussion about reverse dependencies) then I think
it's a very reasonable assumption. That would hopefully not be
required for very many libraries in the world, but if upstream is
broken enough then I think it would be a good thing to promote
awareness of that fact among users. I guess that they just don't
know how broken it is.


//Peter

[gentoo-dev] Re: Maintainer needed: dev-libs/icu

[Ryan Hill]

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

On Thu, 1 Nov 2012 07:21:38 +0100
Peter Stuge <peter@stuge.se> wrote:

> Graham Murray wrote:
> > > Christ on a $#@%! crutch.  You can NOT auto-enable C++11 in your library based
> > > on a configure test and then stuff flags that are not supported by previous
> > > compiler versions into pkg-config for library consumers.  Somebody sane
> > > please fix this.
> > 
> > Though is it not normally a reasonable assumption that the library
> > consumers will be built with the same or later compiler version as
> > the library?
> 
> Well what about the consumers that have been built already? :)
> 
> Now, if all consumers could be rebuilt as part of the build of the
> library (EAPI discussion about reverse dependencies) then I think
> it's a very reasonable assumption.

This has nothing to do with dependencies not getting rebuilt when the library
does.  It's about switching to an earlier compiler version and having
every single package depending on that library fail to build due to something
that is non-obvious and hard to track down.  You don't know that you have to
rebuild the library because you don't know which package that damned flag came
from.


-- 
gcc-porting
toolchain, wxwidgets          we were never more here, expanse getting broader
@ gentoo.org                          but bigger boats been done by less water

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

[gentoo-dev] Re: Maintainer needed: dev-libs/icu

[Ryan Hill]

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

On Thu, 1 Nov 2012 01:00:14 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:

> This has nothing to do with dependencies not getting rebuilt when the library
> does.  It's about switching to an earlier compiler version and having
> every single package depending on that library fail to build due to something
> that is non-obvious and hard to track down.  You don't know that you have to
> rebuild the library because you don't know which package that damned flag came
> from.

I've had someone try to make the argument that we don't really "support" users
mixing packages built by different compiler versions.  It is true that doing
so can sometimes lead to problems with ABI compatibility, unsupported flags,
and so forth, as well as more subtle issues due to compiler bugs, etc.
Sometimes there is nothing we can reasonably do about this and we have to
live with it.  Other times there are solutions, such as making sure that
ABI-changing options don't get propagated down to other packages through
foo-config/pkg-config scripts, or ensuring packages honor the users compiler
flags (see for a topical example bug #202059), and we should and do fix these
things when we encounter them.

What we don't do is make the situation worse by actively introducing these
things into the tree, knowing full well the problems they can cause, and hide
behind the excuse that it's unsupported.


-- 
gcc-porting
toolchain, wxwidgets          we were never more here, expanse getting broader
@ gentoo.org                          but bigger boats been done by less water

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

Re: [gentoo-dev] Re: Maintainer needed: dev-libs/icu

["Paweł Hajdan, Jr."]

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

On 10/31/12 11:13 PM, Graham Murray wrote:
> Ryan Hill <dirtyepic@gentoo.org> writes:
> 
>> Christ on a $#@%! crutch.  You can NOT auto-enable C++11 in your library based
>> on a configure test and then stuff flags that are not supported by previous
>> compiler versions into pkg-config for library consumers.  Somebody sane
>> please fix this.
> 
> Though is it not normally a reasonable assumption that the library
> consumers will be built with the same or later compiler version as the
> library? In which case it does no harm.

To clarify: same compiler can support different versions of C++
standard. Those versions are not guaranteed to be compatible, and e.g.
chromium fails to compile when -std=gnu++11 is forced
(<https://bugs.gentoo.org/show_bug.cgi?id=439698>), while is otherwise
compatible with gcc-4.7.



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

Re: [gentoo-dev] Re: Maintainer needed: dev-libs/icu

[Peter Stuge]

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

Ryan Hill wrote:
> You can NOT

I am not saying that it is a good idea, but of course you can. It has
pretty sucky effects on how your library can be used, disabling
various smart stuff that modern systems do, but I guess the upstream
practises may be from a different time.


> Somebody sane please fix this.

I both agree and I don't. I guess it will be difficult for
representatives from a given distribution to "fix" very much
upstream, if possible I think that the distribution should instead be
fixed to deal with the limits imposed by upstream practises. In this
case I think it means the EAPI reverse dependency rebuild discussion.

Would that be sufficient to address the problem?


//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

[gentoo-dev] Re: Maintainer needed: dev-libs/icu

[Ryan Hill]

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

On Thu, 1 Nov 2012 07:30:06 +0100
Peter Stuge <peter@stuge.se> wrote:

> Ryan Hill wrote:
> > You can NOT
> 
> I am not saying that it is a good idea, but of course you can. It has
> pretty sucky effects on how your library can be used, disabling
> various smart stuff that modern systems do, but I guess the upstream
> practises may be from a different time.

No, you can not do it because I will not let you.

> > Somebody sane please fix this.
> 
> I both agree and I don't. I guess it will be difficult for
> representatives from a given distribution to "fix" very much
> upstream, if possible I think that the distribution should instead be
> fixed to deal with the limits imposed by upstream practises.

I think you're missing something here.  This breakage was added to the Gentoo
ebuild by the "maintainer".  In fact, it immediately follows a bit of
code that sanitizes compiler flags from the pkg-config files, which was added
*specifically so we don't run into issues like this*.

> In this case I think it means the EAPI reverse dependency rebuild discussion.

Again, this has absolutely nothing to do with what I'm talking about.


-- 
gcc-porting
toolchain, wxwidgets          we were never more here, expanse getting broader
@ gentoo.org                          but bigger boats been done by less water

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

[gentoo-dev] Re: Maintainer needed: dev-libs/icu

[Ryan Hill]

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

On Thu, 1 Nov 2012 07:30:06 +0100
Peter Stuge <peter@stuge.se> wrote:

> I guess it will be difficult for representatives from a given distribution to
> "fix" very much upstream, if possible I think that the distribution should
> instead be fixed to deal with the limits imposed by upstream practises.

Also, the amount of naïveté in that statement is truly heartwarming.  I thank
you sir.


-- 
gcc-porting
toolchain, wxwidgets          we were never more here, expanse getting broader
@ gentoo.org                          but bigger boats been done by less water

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

Re: [gentoo-dev] Maintainer needed: dev-libs/icu

[Peter Stuge]

Diego Elio Pettenò wrote:
> the understanding of "you're responsible for whatever you commit".

A load of bull IMO. Is this rooted in some stupid US law thing (via
the foundation) or merely in some cowardly individual disconnected
from the real world, phrasing stupid blanket rules? Or something else?

Isn't it outrageous to claim that people who create and
contribute to and around Gentoo without being developers
are any less responsible for what they do than devs are?

I have personal experience from several cases of the reverse,
but that doesn't make me think that it's the norm for devs to
behave irresponsibly.


Diego, what you wrote does nothing other than make it seem like you
have a personal agenda against Arfrever. If so, that situation is
something you must obviously work on resolving elsewhere.


I expect that anyone and everyone who contribute to any open source
project will do their damndest to contribute only "perfect" work. I
know that this is a pipe dream, but it does happen. I think the way
to make it happen more often is education, but not everyone is able
to educate and so, there is a gap..

Threats aren't an excellent way to try to close any gap IMO. WTF.


//Peter

Re: [gentoo-dev] Maintainer needed: dev-libs/icu

[Diego Elio Pettenò]

On 29/10/2012 11:30, Peter Stuge wrote:
> A load of bull IMO. Is this rooted in some stupid US law thing (via
> the foundation) or merely in some cowardly individual disconnected
> from the real world, phrasing stupid blanket rules? Or something else?

You're free to disagree and not become a developer. But with commit
_rights_ come commit _responsibility_. If you commit something for
somebody else, you're still responsible if it breaks somebody else's
package, it doesn't exempt you from not doing _your_ work.

> Isn't it outrageous to claim that people who create and
> contribute to and around Gentoo without being developers
> are any less responsible for what they do than devs are?

No. It seems stupid to me to pretend that those that actually got
through evaluation feel they can drop responsibility for what others
give to them to commit.

Especially, how do you expect people to keep up with a project's
policies, if they can't be asked to own up to their own mistakes?

> Diego, what you wrote does nothing other than make it seem like you
> have a personal agenda against Arfrever. If so, that situation is
> something you must obviously work on resolving elsewhere.

No. _I_ don't have a personal agenda against him. But _We_, as in
Gentoo, have an history instead. A history that keeps repeating. A
history that, if hiding behind the "I'm just committing his stuff", will
keep repeating.

There is a reason why he's been kicked out, and I wasn't the only one
taking that decision. Committing stuff for him, from him, without
actually checking it, testing it, _owning_ it, is showing a lack of
respect for the _whole_ project.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Maintainer needed: dev-libs/icu

[Rich Freeman]

On Mon, Oct 29, 2012 at 2:40 PM, Diego Elio Pettenò
<flameeyes@flameeyes.eu> wrote:
> You're free to disagree and not become a developer. But with commit
> _rights_ come commit _responsibility_. If you commit something for
> somebody else, you're still responsible if it breaks somebody else's
> package, it doesn't exempt you from not doing _your_ work.

++

We do have a trust with our users.  It doesn't mean that non-devs
don't write good code.  They do.  However, the purpose of vetted
developers is to be a gatekeeper to what runs on our user's systems.

Devs also should be good at spotting problems with ebuilds that cause
issues that might not be apparent from simply running emerge.

That's the value Gentoo adds as a distro.  Anybody can publish an
overlay, but devs are required to get stuff in the tree.

All that said, anything we can do to lower barriers to contribution
while maintaining quality is a good thing.  I don't want devs to be
afraid of committing things, but they should be making an honest
effort to catch issues.

Rich

Re: [gentoo-dev] Maintainer needed: dev-libs/icu

[Rich Freeman]

On Mon, Oct 29, 2012 at 2:30 PM, Peter Stuge <peter@stuge.se> wrote:
> I expect that anyone and everyone who contribute to any open source
> project will do their damndest to contribute only "perfect" work.

Setting aside issues of tone, I want to touch on the more direct issue
of "quality" and "perfection."

I do think that most developers aim for high quality, but quality
means something different to everybody.

Quality could be:
1.  Having a newer package in the tree, perhaps with resolved upstream issues.
2.  Having more integration testing.
3.  Having good documentation.
4.  Having good communications to the end users about impending changes.
5.  Being better integrated with other projects (such as chromium in this case).
6.  Maintainability of the actual ebuild code.
7.  Compliance with formal policies.

All of those have a connotation of quality, and they are at odds with
each other.  The more time you spend on any of them the less time you
have to spend on others.  Complying with any of #2-7 takes time, and
thus conflicts with #1.

I think we should have a pool of developer proxies who are interested
in supporting proxy maintenance.  I don't think we get anywhere by
punishing them when the inevitable mistake occurs.  However, we also
don't get anywhere by turning a blind eye to real issues that
repeatedly come up.  It sounds like there are some of those with ICU.

I don't think we need drastic action.  Maybe we just need a proxy dev
who can be a little more closely associated with the package so
they're aware of the issues that routinely come up and can help
prevent them.  Maybe Arfrever can work a little more closely with some
of the other teams.

I do think we need reasonable quality policies so that we're all on
the same page.  Testing packages should at least be confirmed as
generally working and free of obvious problems.  Stable packages
should have been in testing for 30 days.  Packages with highly
impactful changes should have news items before being unmasked or
stabilized.  And so on.  They don't have to be out-of-hand, and we
don't have to shoot our wounded either.

Rich

Re: [gentoo-dev] Maintainer needed: dev-libs/icu

[Jeroen Roovers]

On Mon, 29 Oct 2012 19:30:40 +0100
Peter Stuge <peter@stuge.se> wrote:

> Diego Elio Pettenò wrote:
> > the understanding of "you're responsible for whatever you commit".
> 

>> Outrageours rant deleted <<

> Isn't it outrageous to claim that people who create and
> contribute to and around Gentoo without being developers
> are any less responsible for what they do than devs are?

I guess Diego's response is rooted in seeing bug reports about or
finding bugs in ebuilds that have been tagged with "proxymaint". I've
recently seen quite a few things with the same label that should not
have been committed in the first place.

> I have personal experience from several cases of the reverse,
> but that doesn't make me think that it's the norm for devs to
> behave irresponsibly.

That's good to hear, but it says nothing about the (arguably) fringe
cases of bad commits.

> Diego, what you wrote does nothing other than make it seem like you
> have a personal agenda against Arfrever.

I don't normally agree with anything Diego says, mind you.

> I expect that anyone and everyone who contribute to any open source
> project will do their damndest to contribute only "perfect" work.

Yes. And everyone makes mistakes when they fail to spot the
imperfections. That's just human. But no one should ever hide behind
the lame excuse that it was somebody else's work when it obviously was
not the contributor/proxy developer who did the commit.

At the other end of the spectrum, recently some people like to tie red
tape around everything, hold up progress for months, and call that "QA".

> I know that this is a pipe dream, but it does happen. I think the way
> to make it happen more often is education, but not everyone is able
> to educate and so, there is a gap..
> 
> Threats aren't an excellent way to try to close any gap IMO. WTF.

Since it is a pipe dream, you have to expect and deal with careless
commits as and when they occur, and keeping people on their toes is one
way to help prevent it, rather than fix the mess afterwards.


     jer

Re: [gentoo-dev] Maintainer needed: dev-libs/icu

[Christoph Junghans]

2012/10/29 Diego Elio Pettenò <flameeyes@flameeyes.eu>:
> On 29/10/2012 10:37, Christoph Junghans wrote:
>> If Arfrever keeps maintaining it for a while, I will take it.
>
> Do remember that whatever you commit, _You_ take responsibility for it.
> After a screwup, the answer "I didn't do anything, I just committed what
> Arfrever gave me" is not a good answer.
Ok, I should have been more precise here. I will take it, but as I am
new to the insides of icu, it will take me a bit to
understand/fix/workaround it's issues and for that time having
Arfrever will be more than useful.

> In particular, if I hear such an answer from anybody (be it for icu or
> something else, be it for a minor inconsistency or a total fuckup), I'll
> be requesting devrel to re-evaluate their commit rights, as they are
> missing the understanding of "you're responsible for whatever you commit".
Please, go ahead. I am happy with having less rights and less responsibilities.

>
> --
> Diego Elio Pettenò — Flameeyes
> flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
>



-- 
Christoph Junghans
http://dev.gentoo.org/~ottxor/

Re: [gentoo-dev] Maintainer needed: dev-libs/icu

[Mike Gilbert]

On Mon, Oct 29, 2012 at 3:33 PM, Christoph Junghans <ottxor@gentoo.org> wrote:
> 2012/10/29 Diego Elio Pettenò <flameeyes@flameeyes.eu>:
>> On 29/10/2012 10:37, Christoph Junghans wrote:
>>> If Arfrever keeps maintaining it for a while, I will take it.
>>
>> Do remember that whatever you commit, _You_ take responsibility for it.
>> After a screwup, the answer "I didn't do anything, I just committed what
>> Arfrever gave me" is not a good answer.
> Ok, I should have been more precise here. I will take it, but as I am
> new to the insides of icu, it will take me a bit to
> understand/fix/workaround it's issues and for that time having
> Arfrever will be more than useful.
>

Arfrever will probably continue to send patches, but we need someone
who can dig in deeper than I have been. Just make sure you verify and
test everything he sends you, and have someone with a tinderbox test
it on version bumps.

I'm also happy to help in whatever way I can, other than having my
name attached to it. :-)

Re: [gentoo-dev] Maintainer needed: dev-libs/icu

[Anthony G. Basile]

On 10/29/2012 03:45 PM, Mike Gilbert wrote:
> On Mon, Oct 29, 2012 at 3:33 PM, Christoph Junghans<ottxor@gentoo.org>  wrote:
>> 2012/10/29 Diego Elio Pettenò<flameeyes@flameeyes.eu>:
>>> On 29/10/2012 10:37, Christoph Junghans wrote:
>>>> If Arfrever keeps maintaining it for a while, I will take it.
>>> Do remember that whatever you commit, _You_ take responsibility for it.
>>> After a screwup, the answer "I didn't do anything, I just committed what
>>> Arfrever gave me" is not a good answer.
>> Ok, I should have been more precise here. I will take it, but as I am
>> new to the insides of icu, it will take me a bit to
>> understand/fix/workaround it's issues and for that time having
>> Arfrever will be more than useful.
>>
> Arfrever will probably continue to send patches, but we need someone
> who can dig in deeper than I have been. Just make sure you verify and
> test everything he sends you, and have someone with a tinderbox test
> it on version bumps.
>
> I'm also happy to help in whatever way I can, other than having my
> name attached to it. :-)
>


I just generated the list of dependencies, 28 packages, see below.  
Compile tests against each are easy enough.  Run tests against 
non-library packages are easy too.  It would be harder to do an 
exhaustive test against, say, dev-libs/boost because then we are a 
couple of libraries levels deep.  Not sure how deep is enough with this one.

# Reverse dependencies for dev-libs/icu
app-i18n/ibus-qt
app-office/libreoffice
# One of the following USE flag combinations is required:
#	icu
x11-libs/qt-webkit
# One of the following USE flag combinations is required:
#	icu
dev-libs/boost
# One of the following USE flag combinations is required:
#	icu
app-text/sword
# One of the following USE flag combinations is required:
#	icu
dev-libs/xerces-c
# One of the following USE flag combinations is required:
#	icu
dev-db/sqlite
app-text/calibre
# One of the following USE flag combinations is required:
#	intl
dev-lang/php
# One of the following USE flag combinations is required:
#	calligra_features_kexi
app-office/calligra
net-libs/webkit-gtk
# One of the following USE flag combinations is required:
#	unicode
media-libs/raptor
# One of the following USE flag combinations is required:
#	icu
net-nds/openldap
# One of the following USE flag combinations is required:
#	!dedicated,icu
games-simulation/openttd
# One of the following USE flag combinations is required:
#	icu
x11-libs/qt-core
dev-tex/bibtexu
www-client/uzbl
# One of the following USE flag combinations is required:
#	cxx
dev-libs/beecrypt
app-text/bibletime
# One of the following USE flag combinations is required:
#	icu
app-accessibility/brltty
dev-db/firebird
# One of the following USE flag combinations is required:
#	icu
gnustep-base/gnustep-base
# One of the following USE flag combinations is required:
#	cjk
net-misc/suite3270
sys-apps/gptfdisk
www-client/chromium
# One of the following USE flag combinations is required:
#	icu
dev-libs/libxml2
dev-db/couchdb
# One of the following USE flag combinations is required:
#	icu
dev-libs/yaz



-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535

Re: [gentoo-dev] Maintainer needed: dev-libs/icu

[Diego Elio Pettenò]

On 29/10/2012 13:19, Anthony G. Basile wrote:
> I just generated the list of dependencies, 28 packages, see below. 
> Compile tests against each are easy enough.  Run tests against
> non-library packages are easy too.  It would be harder to do an
> exhaustive test against, say, dev-libs/boost because then we are a
> couple of libraries levels deep.  Not sure how deep is enough with this
> one.

Are you sure about your numbers? My script shows 52, not 28 packages.

Among others, your list does not show libreoffice-bin, which is what
this time would have caused the most damage.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Maintainer needed: dev-libs/icu

[Anthony G. Basile]

On 10/29/2012 04:59 PM, Diego Elio Pettenò wrote:
> On 29/10/2012 13:19, Anthony G. Basile wrote:
>> I just generated the list of dependencies, 28 packages, see below.
>> Compile tests against each are easy enough.  Run tests against
>> non-library packages are easy too.  It would be harder to do an
>> exhaustive test against, say, dev-libs/boost because then we are a
>> couple of libraries levels deep.  Not sure how deep is enough with this
>> one.
> Are you sure about your numbers? My script shows 52, not 28 packages.
>
> Among others, your list does not show libreoffice-bin, which is what
> this time would have caused the most damage.
>

I used reverse-dependencies.py from the arch-tools repo.  greping the 
tree shows the following 53 packages. (I'm either not using 
reverse-dependencies.py correctly or the tool is missing something.  
I'll try to figure that out later.)

Anyhow, the question really remains, how to "deeply" test this package 
before adding it to the tree even ~arch?


app-accessibility/brltty
app-arch/unar
app-emulation/vmware-workstation
app-emulation/open-vm-tools
app-emulation/vmware-view-open-client
app-i18n/ibus-qt
app-i18n/fcitx
app-misc/tracker
app-office/calligra
app-office/libreoffice-bin
app-office/libreoffice
app-text/calibre
app-text/sword
app-text/bibletime
dev-db/couchdb
dev-db/firebird
dev-db/sqlite
dev-lang/php
dev-lang/R
dev-lang/parrot
dev-libs/389-adminutil
dev-libs/xerces-c
dev-libs/beecrypt
dev-libs/boost
dev-libs/dee
dev-libs/yaz
dev-libs/xalan-c
dev-libs/libxml2
dev-tex/bibtexu
dev-util/dwdiff
dev-vcs/veracity
games-simulation/openttd
games-strategy/megaglest
gnustep-base/gnustep-base
media-libs/harfbuzz
media-libs/raptor
media-sound/music-file-organizer
media-sound/mpfc
net-libs/qmf
net-libs/webkit-gtk
net-misc/suite3270
net-nds/389-admin
net-nds/openldap
net-nds/389-ds-base
net-nntp/tin
sci-geosciences/mapnik
sys-apps/gptfdisk
sys-apps/prefix-chain-utils
www-apps/389-dsgw
www-client/uzbl
www-client/chromium
x11-libs/qt-webkit
x11-libs/qt-core

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535

Re: [gentoo-dev] Maintainer needed: dev-libs/icu

[Diego Elio Pettenò]

On 29/10/2012 14:37, Anthony G. Basile wrote:
> 
> Anyhow, the question really remains, how to "deeply" test this package
> before adding it to the tree even ~arch?

a) check that there is nothing depending on =${oldver} — if there is,
notify maintainer;
b) check the documentation to see if there is something extremely
obvious that will break (with icu unfortunately that doesn't happen);
c) try to get betas and rcs in asap _but masked_;
d) call for a tinderbox run (I can do that with a quick email);

In this case all should have stopped at a) since libreoffice-bin has a
=49* dep, for obvious reasons.

Since there was no hurry of security issues to get icu-50 in, I don't
see why this was all forced through -50_rc without giving time to the
_one_ package that was using an older version to update.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Maintainer needed: dev-libs/icu

[Alexis Ballier]

On Mon, 29 Oct 2012 15:07:15 -0700
Diego Elio Pettenò <flameeyes@flameeyes.eu> wrote:

[...]
> d) call for a tinderbox run (I can do that with a quick email);

For that part, I think everyone would benefit from an official
tinderbox, infra-hosted and with a documented interface; not everyone
has the horsepower to build libreoffice or run boost's test suite.
It is also probably not obvious to everyone that one should ask you for
help, or even what is eligible for a tinderbox run (I remember you
refused when I asked you to make a tinderbox run for ffmpeg).

It would also save you the electricity bill and, being official, rants
about how bugs are filled.

Re: [gentoo-dev] Maintainer needed: dev-libs/icu

[Diego Elio Pettenò]

On Mon, Oct 29, 2012 at 5:17 PM, Alexis Ballier <aballier@gentoo.org> wrote:
> On Mon, 29 Oct 2012 15:07:15 -0700
> Diego Elio Pettenò <flameeyes@flameeyes.eu> wrote:
>
> [...]
>> d) call for a tinderbox run (I can do that with a quick email);
>
> For that part, I think everyone would benefit from an official
> tinderbox, infra-hosted and with a documented interface; not everyone
> has the horsepower to build libreoffice or run boost's test suite.
> It is also probably not obvious to everyone that one should ask you for
> help, or even what is eligible for a tinderbox run (I remember you
> refused when I asked you to make a tinderbox run for ffmpeg).
>
> It would also save you the electricity bill and, being official, rants
> about how bugs are filled.

Luckily I'm not paying the electricity bill of the new tinderbox.

As for the rest, yes I'd welcome an official one as well, the problem
is that there really isn't an "interface". Every time I spoke about
building one, the answer has been "$project will make it
obsolete/useless" (be it somebody else's personal project, or a GSoC
one).

The whole code is open, I'll try to find some more time to document it
over the week as I discussed with Brian, maybe that can help.

Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Maintainer needed: dev-libs/icu

[Arfrever Frehtes Taifersar Arahesis]

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

2012-10-29 23:07:15 Diego Elio Pettenò napisał(a):
> c) try to get betas and rcs in asap _but masked_;

>=sys-devel/gcc-4.7.0, whose usage is required to trigger some problems, is already package.masked.

> d) call for a tinderbox run (I can do that with a quick email);

One of major problems with this tinderbox is that it cannot be used to test packages against newer versions of packages
present in overlays [1], but it can be very useful. E.g. before release of Python 3.3.0 I had tested about 200 packages
against snapshots of Python 3.3 found in an overlay. Besides founding problems in about 10% of packages, I also found
some regressions in Python 3.3 [2], which were later fixed before final release of Python 3.3.0.

> In this case all should have stopped at a) since libreoffice-bin has a
> =49* dep, for obvious reasons.
> 
> Since there was no hurry of security issues to get icu-50 in, I don't
> see why this was all forced through -50_rc without giving time to the
> _one_ package that was using an older version to update.

Maintainers of app-office/libreoffice-bin always build it against stable versions of its dependencies,
so maintainers of app-office/libreoffice-bin can be asked to build it against ICU 50 after stabilization of ICU 50.

[1] http://blog.flameeyes.eu/2010/08/fixed-in-overlay-read-not-fixed
[2] http://bugs.python.org/issue15925
    http://bugs.python.org/issue15926

-- 
Arfrever Frehtes Taifersar Arahesis

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

Re: [gentoo-dev] Maintainer needed: dev-libs/icu

[Arfrever Frehtes Taifersar Arahesis]

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

2012-10-31 04:18:14 Arfrever Frehtes Taifersar Arahesis napisał(a):
> Besides founding problems in about 10% of packages

s/founding/finding/

-- 
Arfrever Frehtes Taifersar Arahesis

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

Re: [gentoo-dev] Maintainer needed: dev-libs/icu

[Diego Elio Pettenò]

On 30/10/2012 20:18, Arfrever Frehtes Taifersar Arahesis wrote:
> One of major problems with this tinderbox is that it cannot be used
> to test packages against newer versions of packages present in
> overlays [1]

Which is not a problem since we're _not_ talking about packages in
overlays but of a bump in the main tree which is not fixed.

Really, I would like to ask you to step off of the discussion, you've
proven yourself incapable to work within the constraint of the tree
already a long time ago.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Maintainer needed: dev-libs/icu

[Peter Stuge]

Diego Elio Pettenò wrote:
> > One of major problems with this tinderbox is that it cannot be
> > used to test packages against newer versions of packages present
> > in overlays [1]
> 
> Which is not a problem since we're _not_ talking about packages
> in overlays but of a bump in the main tree which is not fixed.

Um, so how come an overlay isn't the obvious method for testing,
before putting things in the main tree? What other method is *more*
convenient for testing?

Hell, I am *not* a developer exactly *because* overlays are so
convenient.


> Really, I would like to ask you to step off of the discussion, you've
> proven yourself incapable to work within the constraint of the tree
> already a long time ago.

Diego, I would like to ask you to step off Arfrever.

Try for a second to appreciate the time he has contributed and from
the sound of it continues to contribute, even if he does not use the
methods that you would have made him use if you were paying his
salary.

You're sounding like a complete ass in this thread, and I don't see
the point of that at all. I expect that you're better than that.

Especially snapping back at him with some unrelated bull personal
remark when he points out what seems to me to be a very legitimate
shortcoming of your darling baby is not especially excellent.

Maybe it would have been possible for you to reply something like
"yes, that would be a cool feature actually, if you send me a perfect
patch I'll be happy to deploy it" or "well, I don't see the point in
doing that, but if it would help you then send me a perfect patch and
I'll be happy to deploy it" instead.

I guess you see how such an answer would have communicated something
different from the answer that you chose.


//Peter

Re: [gentoo-dev] Maintainer needed: dev-libs/icu

[Diego Elio Pettenò]

On 31/10/2012 23:18, Peter Stuge wrote:
> Um, so how come an overlay isn't the obvious method for testing,
> before putting things in the main tree? What other method is *more*
> convenient for testing?

package.mask

> Diego, I would like to ask you to step off Arfrever.

And I would like that developers didn't try to workaround Devrel's and
QA's shared choices.

> Try for a second to appreciate the time he has contributed and from
> the sound of it continues to contribute, even if he does not use the
> methods that you would have made him use if you were paying his
> salary.

Honestly, from my point of view (and I doubt it's only mine given that
he got quite a list of people scorned) he contributed mostly headaches.

> Especially snapping back at him with some unrelated bull personal
> remark when he points out what seems to me to be a very legitimate
> shortcoming of your darling baby is not especially excellent.

It's not a shortcoming as much as an intentional design. So thank you
very, much stop second guessing me.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Maintainer needed: dev-libs/icu

[Peter Stuge]

Diego Elio Pettenò wrote:
> > Um, so how come an overlay isn't the obvious method for testing,
> > before putting things in the main tree? What other method is *more*
> > convenient for testing?
> 
> package.mask

Can you clarify? Do you propose that developers carry out wild
experiments by committing things that probably don't work and
masking them?

I don't know, that seems like it will create a pretty dirty tree
history, something I would want to avoid as far as possible.
Overlays seem like a perfect gateway to me.


> > Diego, I would like to ask you to step off Arfrever.
> 
> And I would like that developers didn't try to workaround Devrel's
> and QA's shared choices.

I don't understand. The topic was how your tinderbox could be even
more useful for Gentoo, but you make personal remarks and bring up
devrel and QA? That's confusing.


> > Try for a second to appreciate the time he has contributed and from
> > the sound of it continues to contribute, even if he does not use the
> > methods that you would have made him use if you were paying his
> > salary.
> 
> Honestly, from my point of view (and I doubt it's only mine given that
> he got quite a list of people scorned) he contributed mostly headaches.

I guess that if you review the testing of the couple of hundred
Python packages that he mentioned you would find one or two valuable
items.


> > Especially snapping back at him with some unrelated bull personal
> > remark when he points out what seems to me to be a very legitimate
> > shortcoming of your darling baby is not especially excellent.
> 
> It's not a shortcoming as much as an intentional design. So thank
> you very, much stop second guessing me.

I'm sure you're open to the idea that your design can be made even
more useful, if only for others, in ways you didn't think of yourself.


//Peter

Re: [gentoo-dev] Maintainer needed: dev-libs/icu

[Diego Elio Pettenò]

On 31/10/2012 23:42, Peter Stuge wrote:
> Can you clarify? Do you propose that developers carry out wild
> experiments by committing things that probably don't work and
> masking them?

Dirty experiments, no. Testing stuff that's almost ready, yes. If you
run the tinderbox against dirty experiments, the time _I_ pour in to
sort through the logs report bugs is wasted because they'll hit stupid
hacks that fail to work.

_If_ it's ready to be tested it is ready to be in package.mask and
vice-versa, as it's expected to work *but has to be tested*. If it's not
expected to work, why should I spend time on the tinderbox?

> I don't understand. The topic was how your tinderbox could be even
> more useful for Gentoo, but you make personal remarks and bring up
> devrel and QA? That's confusing.

You ask me to step off Arfrever, I'm telling you why I'm not.

> I guess that if you review the testing of the couple of hundred
> Python packages that he mentioned you would find one or two valuable
> items.

Blah blah blah blah. Seriously you can fix 2000000000000000000 packages
_for your own toy reason_ but if you break the tree every three months
by committing shit that is not tested, or is tested for a very peculiar
corner case only, you're creating more trouble than you're worth. And
that's, once again, not just my opinion. If it's not your opinion, I'd
say we disagree and that's it. I won't try to convince you, please stop
demanding that I bow to your opinion.

> I'm sure you're open to the idea that your design can be made even
> more useful, if only for others, in ways you didn't think of yourself.

See what I wrote above. If you don't understand _why_ I'm avoiding
overlays with reason, then I'm seriously wasting my time responding to you.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

[gentoo-dev] Re: Maintainer needed: dev-libs/icu

[Steven J. Long]

On Wed, Oct 31, 2012 at 11:50:13PM -0700, Diego Elio Pettenò wrote:
> Dirty experiments, no. Testing stuff that's almost ready, yes. If you
> run the tinderbox against dirty experiments, the time _I_ pour in to
> sort through the logs report bugs is wasted because they'll hit stupid
> hacks that fail to work.
> 
> _If_ it's ready to be tested it is ready to be in package.mask and
> vice-versa, as it's expected to work *but has to be tested*. If it's not
> expected to work, why should I spend time on the tinderbox?
> 
> > I don't understand. The topic was how your tinderbox could be even
> > more useful for Gentoo, but you make personal remarks and bring up
> > devrel and QA? That's confusing.
> 
> You ask me to step off Arfrever, I'm telling you why I'm not.
>
He's right tho: the topic was "Why doesn't your tinderbox work with
overlays?" Your response was to insult Arfrever and not actually answer
the point.
 
> > I'm sure you're open to the idea that your design can be made even
> > more useful, if only for others, in ways you didn't think of yourself.
> 
> See what I wrote above. If you don't understand _why_ I'm avoiding
> overlays with reason, then I'm seriously wasting my time responding to you.
> 
Well yeah, you finally explained something, after several emails of bullshit.
Bully for you. Sure you're not burning out?

For anyone else not sure about reasons, there's some more here:
http://blog.flameeyes.eu/2010/08/fixed-in-overlay-read-not-fixed 

Not that I agree with the argument: a tinderbox that can handle overlays sounds
much more useful. The process outlined is that you can do special runs against
p.masked packages, given an email from the developer. Adding the overlay is
just as easy to script, so same amount of work, or less. Of course if the overlay
is badly maintained, you don't have to do anything you don't want.

But if you don't want to support that workflow *at all* (or only if all the
overlay packages are first introduced to the main tree and p.masked in line with
_your_ preferred workflow) that is of course your choice. Just don't be surprised
when people who work in overlays for whatever reason choose another tinderbox, or
deem your tinderbox irrelevant to _their_ workflow.

After all, it is: by design, as you've so politely explained.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: Maintainer needed: dev-libs/icu

[Rich Freeman]

On Thu, Nov 1, 2012 at 10:23 PM, Steven J. Long
<slong@rathaus.eclipse.co.uk> wrote:
> He's right tho: the topic was "Why doesn't your tinderbox work with
> overlays?" Your response was to insult Arfrever and not actually answer
> the point.

Well, nobody is paying Diego to make a tinderbox that works with
overlays.  He actually mentioned that he was going to be spending some
time better documenting how it works, which I think is a big win for
everybody.  Perhaps others will extend his work.

That said, I don't think it is helpful to drive off outside
contributors either.  Ultimately those with commit access need to use
discretion when applying it.

Boost/ICU/etc are obviously a bit of a mess for what appears to be a
variety of reasons.  It would be best for those who actually care to
invest in them (whether devs or not) to work together to find the best
way of doing so.  If what they come up with causes issues for others,
then they should point it out and escalate as appropriate.

But, the rest of us should keep in mind that caring for things like
libraries is a bit of a thankless job.  Nobody says, gee, thanks for
getting that libjpeg bump into the tree, I can really appreciate the
slight refinement in the API the way they might appreciate a new KDE
release or whatever.  However, libraries are a ton of work when it
comes to coordinating with various other Gentoo teams, and some
upstream practices don't make it easier.

And QA can be a bit of a thankless job as well, since the sign of a
really effective QA process is that end users don't even realize it is
there.  However, even when done perfectly there can be hurt
feelings...

Rich

Re: [gentoo-dev] Re: Maintainer needed: dev-libs/icu

[Diego Elio Pettenò]

On 01/11/2012 19:23, Steven J. Long wrote:
> He's right tho: the topic was "Why doesn't your tinderbox work with
> overlays?" Your response was to insult Arfrever and not actually answer
> the point.

_Arfrever himself_ point to my reason in that blog post, FFS.

> Not that I agree with the argument: a tinderbox that can handle overlays sounds
> much more useful. The process outlined is that you can do special runs against
> p.masked packages, given an email from the developer. Adding the overlay is
> just as easy to script, so same amount of work, or less. Of course if the overlay
> is badly maintained, you don't have to do anything you don't want.

Yeah it _could_ be the same amount of work _if_ the overlay is
well-maintained. But since those overlays are pretty rare, I'm not going
to go out of my way just because.

> Just don't be surprised
> when people who work in overlays for whatever reason choose another tinderbox, or
> deem your tinderbox irrelevant to _their_ workflow.

I'm not surprised. And I honestly don't give a rat's ass about it.

Gnome works in an overlay, but there is a tipping point when the overlay
content is stable enough that it enters the tree under p.mask. Qt did
the same as well. Both of them had asked me runs in the past, and it's fine.

Now of course there are "experimental" overlays. I don't care about
those, they'll probably add noise rather than signal, so, there they go,
out of the window.

What about those overlays who're never targeting into the tree? Well,
duh, I don't care about those because if it's not in the main tree, for
me it's not Gentoo, full stop.

Do you still fail to see why I don't find it a _limitation_? The only
moment when I can actually get decent signal out of a tinderbox run is
when the package _is_ good enough to get into p.mask; if _all_ packages
fail to build because the API is totally broken and nobody fixed it,
it'll just add to the number of open bugs I have.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

[gentoo-dev] Re: Re: Maintainer needed: dev-libs/icu

[Steven J. Long]

On Thu, Nov 01, 2012 at 07:32:54PM -0700, Diego Elio Pettenò wrote:
> On 01/11/2012 19:23, Steven J. Long wrote:
> > He's right tho: the topic was "Why doesn't your tinderbox work with
> > overlays?" Your response was to insult Arfrever and not actually answer
> > the point.
> 
> _Arfrever himself_ point to my reason in that blog post, FFS.

Yeah, my bad, sorry: I just had that url in log following our "discussion" in
#openrc when you pretty much displayed the same attitude, ie "no overlays" and
no explanation.
 
> > Not that I agree with the argument: a tinderbox that can handle overlays sounds
> > much more useful. The process outlined is that you can do special runs against
> > p.masked packages, given an email from the developer. Adding the overlay is
> > just as easy to script, so same amount of work, or less. Of course if the overlay
> > is badly maintained, you don't have to do anything you don't want.
> 
> Yeah it _could_ be the same amount of work _if_ the overlay is
> well-maintained. But since those overlays are pretty rare, I'm not going
> to go out of my way just because.

No-one's asking you to. You just give the impression of being the "official QA
and tinderbox" guy, and speak with assumed authority, but as I said, no explanation.
I appreciate that it's old ground for you, but it would be better imo if you
posted your own explanation urls upfront, instead of letting someone else do it for
you several emails into the discussion, after it's got difficult.

After all, we're busy people too, and if you're prescribing methodology, it's helpful
if you present the reasoning.

And again, it's actually less work all round, since all that's needed is a chroot with
tree and a single overlay added, no need for a variety of things to be added to tree
under p.mask, and no need for that variety to be added to unmask in the chroot. No
need for automated bug reports, and the associated costs, either.

> > Just don't be surprised
> > when people who work in overlays for whatever reason choose another tinderbox, or
> > deem your tinderbox irrelevant to _their_ workflow.
> 
> I'm not surprised. And I honestly don't give a rat's ass about it.

Good, then stop telling everyone they *must* package.mask from overlay or their QA
is automatically bad. As that's the impression you leave, and frankly it's bogus.

> Gnome works in an overlay, but there is a tipping point when the overlay
> content is stable enough that it enters the tree under p.mask. Qt did
> the same as well. Both of them had asked me runs in the past, and it's fine.

Does that mean runs where you tried out their overlay, or runs where they were
forced to add loads of packages to the tree, and then back them out again to fix
any problems?

Cos yeah, that sounds like a wonderfuel process to iterate over.

> Now of course there are "experimental" overlays. I don't care about
> those, they'll probably add noise rather than signal, so, there they go,
> out of the window.
> 
> What about those overlays who're never targeting into the tree? Well,
> duh, I don't care about those because if it's not in the main tree, for
> me it's not Gentoo, full stop.
> 
> Do you still fail to see why I don't find it a _limitation_?

Not at all: you don't care about overlays at all, so of course it's not a
limitation from your point of view.

Do you still fail to see why people who do care about overlays, and want to get
their sets of packages into a better state than p.masked before pushing to tree,
might find your method completely useless, and prefer to use a tinderbox that
can cope with layman -a?

> The only
> moment when I can actually get decent signal out of a tinderbox run is
> when the package _is_ good enough to get into p.mask; if _all_ packages
> fail to build because the API is totally broken and nobody fixed it,
> it'll just add to the number of open bugs I have.

Are you really missing the fact that by testing someone's overlay, the package
would by definition not be in the tree, and you wouldn't have to file any bugs
at all, just (automatically) email the output back to the overlay developer?

Quite apart from the fact that you appear to be missing that you could work
with overlay developers (who are targetting the tree) on a much less stressful
basis, and keep the beta releases out of the tree altogether; which is why many
use overlays. It's also a helluva a lot easier for testers to work with, which
is a major factor in the process.

Anyhow, no worries: good luck with your work.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: Re: Maintainer needed: dev-libs/icu

[Diego Elio Pettenò]

On 05/11/2012 07:31, Steven J. Long wrote:
> Are you really missing the fact that by testing someone's overlay, the package
> would by definition not be in the tree, and you wouldn't have to file any bugs
> at all, just (automatically) email the output back to the overlay developer?

Which means I wouldn't be filing bugs for the problems with the
_existing_ packages that are in tree, which is what the users actually
_use_ by default.

If the users are forced to use overlays to get working packages, then I
feel I'm perfectly right with screaming at the developers who are using
overlays for development because they leave users in a sorry state.

Let me try to re-explain this to you: let's say I import overlay $foobar
and $foobar has library A and packages B C D E and F. Now there's
package G in main tree that also uses library A. It fails in the
tinderbox run. Who I have to report it to? Well, I first have to figure
out where the fuck the version of library A is coming from when it
failed, which is far from easy. Then I have to report it to the overlay
maintainer (And you say it's easier by email? FFS you have no idea how
bugs work, do you?) who might or might not act on it, and in the mean
time I'd be overlooking _real_ bugs in the tree.

Now let's say I add more one overlay and there are _three_ copies of
library A each with a different set up, parameters, flags etc. and the
packages between these don't work correctly. Who do I report bugs for?

So seriously, you've got to get a grip on the _trouble_ that overlays
cause, and that about every developer had to face at one point or
another. You're romanticizing overlays because they give _you_ as an
user power, but you're ignoring all the headaches that the developer get
from them.

And you're also failing to understand how the whole tinderbox works. I
suggest you read the two posts I wrote on the topic, which will form a
basis for the documentation of the tinderbox:

http://goo.gl/SM9Rp
http://goo.gl/SF0Dz

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: Re: Maintainer needed: dev-libs/icu

[Michael Orlitzky]

On 11/05/2012 10:39 AM, Diego Elio Pettenò wrote:
> On 05/11/2012 07:31, Steven J. Long wrote:
>> Are you really missing the fact that by testing someone's overlay, the package
>> would by definition not be in the tree, and you wouldn't have to file any bugs
>> at all, just (automatically) email the output back to the overlay developer?
> 
> Which means I wouldn't be filing bugs for the problems with the
> _existing_ packages that are in tree, which is what the users actually
> _use_ by default.
> 
> If the users are forced to use overlays to get working packages, then I
> feel I'm perfectly right with screaming at the developers who are using
> overlays for development because they leave users in a sorry state.

Do other people agree that something should be done about this? I see
two reasons to prefer overlays to the main tree:

  1) Over time, unstable has become too stable (I know, I know). People
     expect things to work, and nobody wants to break working systems
     by committing works-in-progress to ~arch.

  2) CVS sucks; git is much more fun to use. It also makes user
     contributions easier.

The first I think could be helped with a third level of stability, say,
!arch, which stands for it-aint-gonna-fuckin-work-on-'arch'. Devs could
pile anything that's eventually headed for the tree here, and catch
conflicts early. I'm not entirely joking about the name -- it would have
to be clear that this is a staging area and no one should use it in
production. But this is a big change.

The second will be helped by the git transition, but what about the
overlay situation now? For work/school, at a minimum, I need,

  * sunrise[1]
  * gentoo-haskell[2]
  * science[3]

And nice-to-have:

  * emacs[4]

All of these are already in git, and run by developers. Why not have
them all (and the other dev-run git overlays) in the same repo? Just
give everyone commit access. Then when you're ready to push something to
the tree, you already know that it won't break anything.


[1] http://git.overlays.gentoo.org/gitweb/?p=proj/sunrise-reviewed.git
[2] https://github.com/gentoo-haskell/gentoo-haskell
[3] http://git.overlays.gentoo.org/gitweb/?p=proj/sci.git
[4] http://git.overlays.gentoo.org/gitweb/?p=proj/emacs.git

Re: [gentoo-dev] Re: Re: Maintainer needed: dev-libs/icu

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/11/12 12:00 PM, Michael Orlitzky wrote:
> 
> 1) Over time, unstable has become too stable (I know, I know).
> People expect things to work, and nobody wants to break working
> systems by committing works-in-progress to ~arch.
> 

We have p.mask for that, though, so dev's could get in the habit of
committing and hard-masking things more, rather than using overlays.


> The first I think could be helped with a third level of stability,
> say, !arch, which stands for it-aint-gonna-fuckin-work-on-'arch'.

well, per ~arch p.mask is possible here, as is removing keywords.  For
things that definitely don't work we also have '-arch' (usually used
as -*) but that tends to be more permanent.


 Devs could
> pile anything that's eventually headed for the tree here, and
> catch conflicts early. I'm not entirely joking about the name -- it
> would have to be clear that this is a staging area and no one
> should use it in production. But this is a big change.

- From p.mask'ing?  *shrug*


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlCX9E4ACgkQ2ugaI38ACPD/BgD/cQgLXh8uE3hE0XziaeWzu5FZ
hlPif1icqOvZkMMAvBYA/ig4YAtBSc0lTkIztnHKQYCh6gJPe9oOf2rJ7EZENvzR
=J+Ib
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: Re: Maintainer needed: dev-libs/icu

[Michael Orlitzky]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/05/2012 12:15 PM, Ian Stakenvicius wrote:
> On 05/11/12 12:00 PM, Michael Orlitzky wrote:
> 
>> 1) Over time, unstable has become too stable (I know, I know). 
>> People expect things to work, and nobody wants to break working 
>> systems by committing works-in-progress to ~arch.
> 
> 
> We have p.mask for that, though, so dev's could get in the habit of
> committing and hard-masking things more, rather than using 
> overlays.
> 
> 
>> The first I think could be helped with a third level of 
>> stability, say, !arch, which stands for 
>> it-aint-gonna-fuckin-work-on-'arch'.
> 
> well, per ~arch p.mask is possible here, as is removing keywords. 
> For things that definitely don't work we also have '-arch'
> (usually used as -*) but that tends to be more permanent.
> 
> 
> Devs could
>> pile anything that's eventually headed for the tree here, and 
>> catch conflicts early. I'm not entirely joking about the name -- 
>> it would have to be clear that this is a staging area and no one
>>  should use it in production. But this is a big change.
> 
> - From p.mask'ing?  *shrug*
> 

Being hard masked is a little bit stronger than what I had in mind. I
was thinking, "no known problems, but it hasn't been tested
thoroughly." Users with a death wish could run it, and it might work.
That would leave package.mask for known brokenness: build failures,
security issues, etc.

But anyway, I replied where I did because it was pointed out that not
enough people are using package.mask to test -- they're using overlays
instead, and that makes life difficult for end users. I'd just like to
see more stuff wind up in the tree, or at least in one big (git)
overlay to catch conflicts. If everything in those overlays was in the
tree but masked, that'd be awesome.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJQl/gsAAoJEBxJck0inpOiYB4P/14RM6RwtS1pW9xducpGS2qW
5wIHhW+5wNK9FNSpnMU3knOaMxwQTlVQt6BXHhttNKPD2v2SsnESyd88PA1ht0+8
NTPlrbKO9dyLyRfU+hxKGGbET45x7dLT2zDe0skc1dF78A9T5QDpwKlDfQSctxzT
rTZ3HYa/Ff7PCvb9FzEWlr3KqdC+ictju2R+F7CjZKOjNUgPvPEIBOEP7vRYYJSe
7aK8cCN2yuKcK/ykaA4qiiRM18oRljG/5gEhvZ98JoVSiOwIr+RZeuVxw+XGxCY8
6+XntBjPPi/bkvSVVExWTpPAP+he75Zm/9vvrVDR3log6nLRx7pW0EIfzcBBVMc5
LujBTIK0EJFjtvELIPdq5HD85jgC5rNn3Kv7xGvp6K0VVWzegZ2RgKsG56qkITC3
2KYq4qN3FLaFM08NKdUfE8FRPd9M+jYowG6etTdU++46p8Al/qu/lV4c5frWzGik
Q0EHOpOk94M2OeWEoxauozUyy5Z2oBISgaVx8HWrS/qHgEnvuUe2g7EA9XbIpFHI
rIF1oRYBrh/9/SX4R6BSisNx57NXMcRBODezEPBYuQ5fY0kWcvSnJAx2SKzRBanX
+09R9sxDOGnczUHgfNwOMDRbTIUUnQEucIVewYSe7C/DKBtYlyStuY6lm5ytQ46n
6JDD46PWiKfewYE5c+yj
=nb95
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: Re: Maintainer needed: dev-libs/icu

[Diego Elio Pettenò]

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

On 05/11/2012 09:32, Michael Orlitzky wrote:
> Being hard masked is a little bit stronger than what I had in mind. I
> was thinking, "no known problems, but it hasn't been tested
> thoroughly." Users with a death wish could run it, and it might work.
> That would leave package.mask for known brokenness: build failures,
> security issues, etc.

Build failures shouldn't be p.masked, build failures should be fixed or
removed. Ibidem for security issues in the most cases.

Seriously, open the package.mask file and just look for the word
"testing" then come back to argue that it's not what it's for, please.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/


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

Re: [gentoo-dev] Re: Re: Maintainer needed: dev-libs/icu

[Diego Elio Pettenò]

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

On 05/11/2012 09:15, Ian Stakenvicius wrote:
> We have p.mask for that, though, so dev's could get in the habit of
> committing and hard-masking things more, rather than using overlays.

Amen.

That's what I've been saying for the past week or so, and before as well.

Get it in p.mask, so that you're sure it's aligned with the rest of the
tree, and it can be tested, and you don't have to guess where a package
is coming from.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/


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

[gentoo-dev] Re: Maintainer needed: dev-libs/icu

[Duncan]

Diego Elio Pettenò posted on Mon, 05 Nov 2012 07:39:19 -0800 as excerpted:

> On 05/11/2012 07:31, Steven J. Long wrote:
>> Are you really missing the fact that by testing someone's overlay, the
>> package would by definition not be in the tree, and you wouldn't have
>> to file any bugs at all, just (automatically) email the output back to
>> the overlay developer?
> 
> Which means I wouldn't be filing bugs for the problems with the
> _existing_ packages that are in tree, which is what the users actually
> _use_ by default.
> 
> If the users are forced to use overlays to get working packages, then I
> feel I'm perfectly right with screaming at the developers who are using
> overlays for development because they leave users in a sorry state.

I'm not sure if this is what SL had in mind, but it's what I thought of 
when I read his suggestion, triggered here by the "won't have to file 
bugs at all" bit.

What about doing overlays, but ONLY one-at-a-time, and ONLY on special-
request-runs, presumably immediately pre-tree-introduction?  Among other 
things that might help for stuff like kde where a whole slew of packages 
are introduced to the tree (and should be tested) together, something 
that's easier done from a staging overlay.

That way, any overlay runs would be pre-requested by the overlay person/
project, so they'd be specifically expecting results.  Thus the "could 
(if desired) skip filing bugs, just direct-mail" part SL mentioned, or 
automated bug filing but in this case it'd be ENTIRELY by request and 
expected, since they would have pre-arranged for the tinderbox run and 
would be expecting/prepared-for the results.

Additionally, one-overlay-at-a-time would automatically mean what's ever 
there is tested only against the tree and other packages in that overlay, 
limiting the "where'd it come from" problem.  In fact, a pre-arranged 
unmask file (say tinderbox.unmask) in the profile could be used 
effectively as a whitelist to specify specific packages and versions for 
the tinderbox run.  If it's in the whitelist, it's from the overlay, 
otherwise it's from the tree.  This would let the overlay folks keep 
their live-builds, etc, out of tinderbox run, since they're presumably 
not tinderbox-test-ready anyway, as well as nicely solving the "where'd 
it come from" question.

And tree packages would still be heavily emphasized, since all testing 
except for other packages in that specific overlay test would be against 
the tree.

> Let me try to re-explain this to you: let's say I import overlay $foobar
> and $foobar has library A and packages B C D E and F. Now there's
> package G in main tree that also uses library A. It fails in the
> tinderbox run. Who I have to report it to?

This one would then be easy.  Package G is in the main tree but you're 
doing a specifically requested overlay run, and it's failing built 
against overlay library A.  You file the bug with the overlay maintainer, 
since that's specifically what you're testing, and library A is in 
tinderbox.unmask so the overlay version is specifically being tested in 
this run.

But here's the kicker.  Now you're more or less simply providing the 
tinderbox testing service.  You don't have all the usual results analysis 
to do yourself (tho you might want to do a quick check from time to time 
to make sure it's still working as expected/intended), you pretty much 
simply forward them as-is to the overlay maintainer, giving them the test 
results they requested.  They get to figure out where the problem is and 
adjust (or if it's a tree-only bug that just happened to popup in this 
test, duplicate it as such, and file the bug accordingly) as necessary.

> Now let's say I add more one overlay

That won't happen in this one-overlay-at-a-time scenario.  Again, the 
tree remains the primary focus, since all non-tinderbox.unmask-listed 
packages are by definition in-tree.  You're simply providing a very 
specific overlay-against-tree tinderbox testing service, giving the 
requesting maintainers a bit more flexibility there, in exchange for 
offloading some of the responsibility you'd normally have for bug pre-
analysis, etc, to them.  They get both the additional flexibility of an 
overlay test, and rawer results that they have to do more work to parse, 
in the same package deal, but the focus remains the tree.  There's no 
possibility or complexity of multiple overlays at once.

> And you're also failing to understand how the whole tinderbox works. I
> suggest you read the two posts I wrote on the topic, which will form a
> basis for the documentation of the tinderbox:
> 
> http://goo.gl/SM9Rp http://goo.gl/SF0Dz

FWIW I'm subscribed to your feed and gentoo-planet both, so saw those.  I 
read/skimmed them, but some of it was beyond me for just reading, tho 
it'd definitely be useful if I were actually implementing a tinderbox 
here.  So if I missed something obvious therein, and this idea isn't 
practical either, forgive the waste of time.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Maintainer needed: dev-libs/icu

[Diego Elio Pettenò]

On 05/11/2012 13:45, Duncan wrote:
> 
> What about doing overlays, but ONLY one-at-a-time, and ONLY on special-
> request-runs, presumably immediately pre-tree-introduction?  Among other 
> things that might help for stuff like kde where a whole slew of packages 
> are introduced to the tree (and should be tested) together, something 
> that's easier done from a staging overlay.

It's actually easier done by package.mask as Ian already pointed out.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: Maintainer needed: dev-libs/icu

[Patrick Lauer]

On 11/06/12 05:45, Duncan wrote:
> Diego Elio Pettenò posted on Mon, 05 Nov 2012 07:39:19 -0800 as excerpted:
> 
>> On 05/11/2012 07:31, Steven J. Long wrote:
>>> Are you really missing the fact that by testing someone's overlay, the
>>> package would by definition not be in the tree, and you wouldn't have
>>> to file any bugs at all, just (automatically) email the output back to
>>> the overlay developer?
>>
>> Which means I wouldn't be filing bugs for the problems with the
>> _existing_ packages that are in tree, which is what the users actually
>> _use_ by default.
>>
>> If the users are forced to use overlays to get working packages, then I
>> feel I'm perfectly right with screaming at the developers who are using
>> overlays for development because they leave users in a sorry state.
> 
> I'm not sure if this is what SL had in mind, but it's what I thought of 
> when I read his suggestion, triggered here by the "won't have to file 
> bugs at all" bit.
> 
> What about doing overlays, but ONLY one-at-a-time, and ONLY on special-
> request-runs, presumably immediately pre-tree-introduction?  Among other 
> things that might help for stuff like kde where a whole slew of packages 
> are introduced to the tree (and should be tested) together, something 
> that's easier done from a staging overlay.
> 
> That way, any overlay runs would be pre-requested by the overlay person/
> project, so they'd be specifically expecting results.  Thus the "could 
> (if desired) skip filing bugs, just direct-mail" part SL mentioned, or 
> automated bug filing but in this case it'd be ENTIRELY by request and 
> expected, since they would have pre-arranged for the tinderbox run and 
> would be expecting/prepared-for the results.

I've been doing this for some overlays - kde, qt, sunrise

It's still a lot of work to set things up (keywords, blockers, useflags
mostly), and it takes lots of time - the "small" qt overlay took me
about 4 days walltime to process (I'd estimate somewhere near a CPU-day)

But why rely on Diego or me for such things? All you need to do is setup
a chroot, configure it well, emerge `cat pkglist` and watch the fallout.

> 
> Additionally, one-overlay-at-a-time would automatically mean what's ever 
> there is tested only against the tree and other packages in that overlay, 
> limiting the "where'd it come from" problem.  
Aye, it gives pretty good results, but comes with extra setup time.

... but as you mentioned, if the overlays provided specific files with
e.g. unmask lists it'd be easier, and anyone with reasonably fast
hardware can do it themselves anyway.

Happy compiling,

Patrick