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

2012-11-01 Thread 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

2012-11-01 Thread 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
flamee...@flameeyes.eu — http://blog.flameeyes.eu/



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

2012-11-01 Thread 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

2012-11-01 Thread 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 200 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
flamee...@flameeyes.eu — http://blog.flameeyes.eu/



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

2012-10-30 Thread Arfrever Frehtes Taifersar Arahesis
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


signature.asc
Description: This is a digitally signed message part.


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

2012-10-30 Thread Arfrever Frehtes Taifersar Arahesis
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


signature.asc
Description: This is a digitally signed message part.


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

2012-10-30 Thread 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
flamee...@flameeyes.eu — http://blog.flameeyes.eu/



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

2012-10-29 Thread 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

2012-10-29 Thread Christoph Junghans
2012/10/29 Brian Harring ferri...@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

2012-10-29 Thread 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
flamee...@flameeyes.eu — http://blog.flameeyes.eu/



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

2012-10-29 Thread Rich Freeman
On Mon, Oct 29, 2012 at 2:00 PM, Diego Elio Pettenò
flamee...@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

2012-10-29 Thread 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

2012-10-29 Thread 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
flamee...@flameeyes.eu — http://blog.flameeyes.eu/



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

2012-10-29 Thread 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
flamee...@flameeyes.eu — http://blog.flameeyes.eu/



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

2012-10-29 Thread Rich Freeman
On Mon, Oct 29, 2012 at 2:30 PM, Peter Stuge pe...@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

2012-10-29 Thread Rich Freeman
On Mon, Oct 29, 2012 at 2:40 PM, Diego Elio Pettenò
flamee...@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

2012-10-29 Thread Jeroen Roovers
On Mon, 29 Oct 2012 19:30:40 +0100
Peter Stuge pe...@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

2012-10-29 Thread Christoph Junghans
2012/10/29 Diego Elio Pettenò flamee...@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
 flamee...@flameeyes.eu — http://blog.flameeyes.eu/




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



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

2012-10-29 Thread 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.




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

2012-10-29 Thread Mike Gilbert
On Mon, Oct 29, 2012 at 3:33 PM, Christoph Junghans ott...@gentoo.org wrote:
 2012/10/29 Diego Elio Pettenò flamee...@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

2012-10-29 Thread Anthony G. Basile

On 10/29/2012 03:45 PM, Mike Gilbert wrote:

On Mon, Oct 29, 2012 at 3:33 PM, Christoph Junghansott...@gentoo.org  wrote:

2012/10/29 Diego Elio Pettenòflamee...@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: bluen...@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

2012-10-29 Thread 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
flamee...@flameeyes.eu — http://blog.flameeyes.eu/



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

2012-10-29 Thread 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: bluen...@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

2012-10-29 Thread 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
flamee...@flameeyes.eu — http://blog.flameeyes.eu/



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

2012-10-29 Thread Alexis Ballier
On Mon, 29 Oct 2012 15:07:15 -0700
Diego Elio Pettenò flamee...@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

2012-10-29 Thread Diego Elio Pettenò
On Mon, Oct 29, 2012 at 5:17 PM, Alexis Ballier aball...@gentoo.org wrote:
 On Mon, 29 Oct 2012 15:07:15 -0700
 Diego Elio Pettenò flamee...@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
flamee...@flameeyes.eu — http://blog.flameeyes.eu/



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

2012-10-28 Thread Mike Gilbert
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



signature.asc
Description: OpenPGP digital signature


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

2012-10-28 Thread Arfrever Frehtes Taifersar Arahesis
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


signature.asc
Description: This is a digitally signed message part.