Re: [gentoo-dev] Maintainer needed: dev-libs/icu
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
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
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
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
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-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-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
On Mon, Oct 29, 2012 at 5:17 PM, Alexis Ballier wrote: > On Mon, 29 Oct 2012 15:07:15 -0700 > Diego Elio Pettenò 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/
Re: [gentoo-dev] Maintainer needed: dev-libs/icu
On Mon, 29 Oct 2012 15:07:15 -0700 Diego Elio Pettenò 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
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
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
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
On 10/29/2012 03:45 PM, Mike Gilbert wrote: On Mon, Oct 29, 2012 at 3:33 PM, Christoph Junghans wrote: 2012/10/29 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. 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
On Mon, Oct 29, 2012 at 3:33 PM, Christoph Junghans wrote: > 2012/10/29 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. > 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
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 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. 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
On Mon, 29 Oct 2012 19:30:40 +0100 Peter Stuge 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
On Mon, Oct 29, 2012 at 2:40 PM, Diego Elio Pettenò 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
On Mon, Oct 29, 2012 at 2:30 PM, Peter Stuge 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
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
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
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
On Mon, Oct 29, 2012 at 2:00 PM, Diego Elio Pettenò 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
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 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? 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
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-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.
[gentoo-dev] Maintainer needed: dev-libs/icu
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