Mailing List Archive

Renat Lumpau <rl03@gentoo.org> said:
> So you're saying it's ok to have one team member who steps out of line and
> cannot be managed? Are all teams allowed that exception?

Did you read what I said? I talked to him and told him what I expect.
I'm telling you to not expect him to change, not that I expect QA team
members to behave that way.

--
Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86)
email - halcy0n AT gentoo DOT org
mark AT halcy0n DOT com
web - http://dev.gentoo.org/~halcy0n/
http://www.halcy0n.com

Mark Loeser wrote:

> I don't think you will find one person that is going to say they are
> capable of changing how Ciaran interacts with people. This is an
> entirely different issue though, and I have talked to Ciaran about it.
> What I was saying above is that I am not going to go and get involved
> every single time someone has a disagreement. This situation has
> obviously grown to be ridiculous and I have had a talk with him about
> it, so he knows my feelings on the situation, and what I expect.

I should note that if are a Gentoo Developer and have
problems/concerns/issues with Ciaran's attitude/actions, please comment
on bug #114944. (this bug is only open to Gentoo developers). Its better
if you say it yourself in this bug rather than letting other people
quoting what you say.

--
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key: <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

On Tue, 28 Feb 2006 18:13:57 -0600 Lance Albertson
<ramereth@gentoo.org> wrote:
| I should note that if are a Gentoo Developer and have
| problems/concerns/issues with Ciaran's attitude/actions, please
| comment on bug #114944. (this bug is only open to Gentoo developers).
| Its better if you say it yourself in this bug rather than letting
| other people quoting what you say.

I should note that if you are a Gentoo developer who has found my
advice helpful, you should comment on bug #114944 since certain people
are trying to turn Gentoo development into a popularity contest.

--
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail : ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm

On Tuesday 28 February 2006 19:28, Ciaran McCreesh wrote:
> On Tue, 28 Feb 2006 18:13:57 -0600 Lance Albertson
>
> <ramereth@gentoo.org> wrote:
> | I should note that if are a Gentoo Developer and have
> | problems/concerns/issues with Ciaran's attitude/actions, please
> | comment on bug #114944. (this bug is only open to Gentoo developers).
> | Its better if you say it yourself in this bug rather than letting
> | other people quoting what you say.
>
> I should note that if you are a Gentoo developer who has found my
> advice helpful, you should comment on bug #114944 since certain people
> are trying to turn Gentoo development into a popularity contest.

there's a lot more to the issue, but it's sad if that's all you see in the bug
-mike
--
gentoo-dev@gentoo.org mailing list

Lance Albertson wrote:

> I should note that if are a Gentoo Developer and have
> problems/concerns/issues with Ciaran's attitude/actions, please comment
> on bug #114944. (this bug is only open to Gentoo developers). Its better
> if you say it yourself in this bug rather than letting other people
> quoting what you say.

Since some people may read this the wrong way, let me please clarify.

If you have *anything* (good or bad) to add to the bug, please feel free
to (If you're a developer). I'm not trying to single out one developer,
rather I felt that informing developers about it (since there has been a
lot of frustration shown on this list) was a good idea.

Sorry if it seemed more biased one way or the other. It was not my
intention at all. I assumed people would read that and realize that they
could also add good comments if they wanted to.

--
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key: <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

1.3.2006, 1:40:53, Mike Frysinger wrote:

> On Tuesday 28 February 2006 19:28, Ciaran McCreesh wrote:
>> On Tue, 28 Feb 2006 18:13:57 -0600 Lance Albertson
>>
>> <ramereth@gentoo.org> wrote:
>> | I should note that if are a Gentoo Developer and have
>> | problems/concerns/issues with Ciaran's attitude/actions, please
>> | comment on bug #114944. (this bug is only open to Gentoo developers).
>> | Its better if you say it yourself in this bug rather than letting
>> | other people quoting what you say.
>>
>> I should note that if you are a Gentoo developer who has found my
>> advice helpful, you should comment on bug #114944 since certain people
>> are trying to turn Gentoo development into a popularity contest.

> there's a lot more to the issue, but it's sad if that's all you see in the bug
> -mike

Indeed. Ciaran, that bug is not about technical competence; it's about your
civil communication skills, that are as lacking as penguins on the Sahara
desert in your case. Technical skills themselves are not useful for a
project the requires you to communicate w/ other people in a civilized
manner.

As someone else noted, certains "skills" might be fit for a car salesmen but
not for developers of a Linux distro. If a company hires a technically
brilliant QA guy only to find out later on that this brilliant guy has
killed the whole team while communicating his finding to others in such
style you have shown on this thread and on many other occasions before,
it'll be the QA guy who gets booted out, not the whole team. If that doesn't
happen soon enough, the rest of the team can leave meanwhile and the whole
business is doomed.

--

jakub

28.2.2006, 16:31:26, Ciaran McCreesh wrote:

> On Tue, 28 Feb 2006 16:17:20 +0100 Paul de Vrieze <pauldv@gentoo.org>
> wrote:
> | On Tuesday 28 February 2006 15:52, Ciaran McCreesh wrote:
> |
> | Where is a coding style problem related to quality of code in general
> | and assurance in particular?

> It's more relevant than you might think. Screwing up layout like that
> breaks various QA checking tools that assume that things are in the
> standard format.

A tool that chokes on coding style (like tabs and whitespaces) should be
ifself fixed.


--

jakub

28.2.2006, 16:29:10, Ciaran McCreesh wrote:

> On Tue, 28 Feb 2006 16:08:05 +0100 Jakub Moc <jakub@gentoo.org> wrote:
> | 28.2.2006, 15:39:40, Ciaran McCreesh wrote:
> |
> |
> | No, it isn't.

> 'Fraid it is. Everything in the devrel handbook that isn't explicitly
> marked as a guideline is policy.

Sorry, such procedure is not acceptable until you change the whole
metastructure of the project so that a bunch of people is allowed to dictate
to others whatever they think is fit. (Another question is how many people
will want to work on such project.) Until that's done, things should be
discussed and some form of consent reached.

> | When and where has been the following change discussed and who |
> approved that? | |
> http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?r1=1.25&r2=1.26&root=gentoo

> Wouldn't know. That was nothing to do with me. I just wrote the
> original text (or actually, that might not even have been me). It
> finding its way into the policy docs was devrel's doing.

Again, see above.

> |
> |
> | No, it isn't. If you want something to have as a policy, it needs to
> | be error-free, reasonably applicable and not doing more harm than if
> | it isn't applied at all. And implementing such stuff requires a
> | proper discussion, considering the consequences and some sort of
> | consent among affected developers. (Also, that howto example is less
> | than fortunate/clear, like some user noted in Bug 124401).

> built_with_use isn't a question of conflicting USE flags. It's a
> separate question of dependency resolution, and in this situation it
> *can't* be solved using the method that's been standard for four years
> or more.

Sure it is. You can't silently enable/disable some feature if other ebuilds
are checking for that feature using those very use flags that you have
ignored/overriden/bypassed. Such checks are useless then and more stuff gets
broken than gets fixed.

> | No, it doesn't, you can't reasonably favour one of two completely |
> different functionalities based on some automagic | assumption/developer
> discretion. That doesn't benefit users in any | way and just produces
> unexpected results (hey, I explicitely enabled | "recode" use flag and php
> compiled without, the ebuild is broken, | fix0r it!)

> By all means warn the user. There's nothing in policy disallowing that.

That doesn't work, it breaks other things as explained above. Please, don't
use a hammer where watchmaker's screwdriver is a proper tool, otherwise
you'll severely damage the whole thing. One minute spent on tweaking use
flags is much less important than a bunch of useful features missing just
because you've hammered the whole stuff together.

> | No, noone should enforce a policy that
> |
> | - doesn't exist (see above)

> The whole devrel handbook is policy, except where otherwise noted. See
> Mike's reply.

Then any significant change there requires a sane procedure.


--

jakub

Am Mittwoch, 1. März 2006 08:21 schrieb Jakub Moc:
> 28.2.2006, 16:31:26, Ciaran McCreesh wrote:
> > On Tue, 28 Feb 2006 16:17:20 +0100 Paul de Vrieze <pauldv@gentoo.org>
> > | On Tuesday 28 February 2006 15:52, Ciaran McCreesh wrote:
> | >> Yes, it's an utterly trivial problem, but it is a QA violation.
> | >> Getting a complete list is something that takes a heck of a lot
> | >> longer, and I have yet to be convinced that my time would not be
> | >> better spent elsewhere.
> > |
> > | Where is a coding style problem related to quality of code in general
> > | and assurance in particular?
> >
> > It's more relevant than you might think. Screwing up layout like that
> > breaks various QA checking tools that assume that things are in the
> > standard format.
>
> A tool that chokes on coding style (like tabs and whitespaces) should be
> ifself fixed.
Hmm, you never used repoman, right? repoman checks for whitespace and tab
oddities and warns you, if you want to commit them.

Danny
--
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project

--
gentoo-dev@gentoo.org mailing list

1.3.2006, 11:29:47, Danny van Dyk wrote:

>> > | Where is a coding style problem related to quality of code in general
>> > | and assurance in particular? > > It's more relevant than you might
>> think. Screwing up layout like that > breaks various QA checking tools
>> that assume that things are in the > standard format.
>>
>> A tool that chokes on coding style (like tabs and whitespaces) should be
>> ifself fixed.
> Hmm, you never used repoman, right? repoman checks for whitespace and tab
> oddities and warns you, if you want to commit them.


Sure I did... that's not the breakage of a QA tool ciaranm has been talking
about, though. If some tool stops to work b/c of spacing/indenting issues,
then it's broken. Meanwhile, if you can't bear formating/whitespace issues,
then either fix it yourself or file a bug and wait until someone gets to it
or fixes it when next revbump/another bunch of more important fixes is due.

Expecting that someone will fix a cosmetic issue within five minutes from
the time when a bug is filed and ranting about it on #gentoo-qa and mailing
lists isn't useful but rather plain annoying.

--

jakub

On Tuesday 28 February 2006 21:20, Ciaran McCreesh wrote:
> On Tue, 28 Feb 2006 20:09:02 +0100 Jakub Moc <jakub@gentoo.org> wrote:
> | 28.2.2006, 18:38:10, Ciaran McCreesh wrote:
> | > Sheesh, you'll probably claim that this isn't broken next too:
> | >
> | > if [ "${IS_UPGRADE}" = "1" ] ; then
> | > einfo "Removing old version ${REMOVE_PKG}"
> | >
> | > emerge -C "${REMOVE_PKG}"
> | > fi
> |
> | No, I won't claim that... I'd rather love to know why didn't you
> | point out to an obvious eclass flaw about 30 emails and many hours
> | ago, saving us from all the eclass formating, slotting and ewarn
> | blurb.
>
> Why didn't you look before accusing me of not having valid issues? I
> mean, it's pretty frickin' hard to miss that one.

This code (or an equivalent kludge/hack) does however allow features that are
of great value to our users. While I agree that such hacks should be avoided
if possible, I think in this case it is not. As such the appropriate response
is to isolate the hack in a central place, where it is clear to be seen and
can easilly be fixed. This allows the quality of the hack to be ensured,
relieving many webapps from doing hacks themselves.

While this hack is being used, some effort should be put into constructively
creating a proper solution for the problems that were hacked around. Saying
"this is not allowed because of X policy" is not helpful as the costs of
disallowing it greatly outweigh the costs of overlooking it in a controlled
manner.

Paul

--
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

On Wednesday 01 March 2006 00:08, Mike Frysinger wrote:
>
> dont get me wrong, i wasnt implying that bugs shouldnt be filed ... i was
> addressing the incorrect idea that it isnt a valid QA issue unless a user
> experiences it and complains via bugzilla

I agree with this. I would however also like to ask QA to allow exceptions to
policy for well-discussed reasons. Sometimes ugly hacks are needed, and as
long as they are understood to be ugly, they must not be banned outright. I
don't think it is a problem if those issues have LATER bugs on them blocking
on some feature request bug. I can even agree with it that a feature request
bug must be written for such a hack to be allowed.

With respect to webapp-config. I know it's ugly, I know it does perform jobs
that should be performed by portage. Portage however doesn't, and
webapp-config does provide valuable features for many users. As such, as long
as portage does not offer the features that webapp-config provides, I am of
the opinion that the webapp.eclass should be allowed to use "minimal" hacks
to provide the webapp features. QA's role in this case is to ensure that no
hacks are added, and to signal it when the hacks break.

Paul

--
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

1.3.2006, 13:09:55, Paul de Vrieze wrote:

> On Tuesday 28 February 2006 21:20, Ciaran McCreesh wrote:

>> | > if [ "${IS_UPGRADE}" = "1" ] ; then
>> | > einfo "Removing old version ${REMOVE_PKG}"
>> | >
>> | > emerge -C "${REMOVE_PKG}"
>> | > fi

> This code (or an equivalent kludge/hack) does however allow features that are
> of great value to our users. While I agree that such hacks should be avoided
> if possible, I think in this case it is not. As such the appropriate response
> is to isolate the hack in a central place, where it is clear to be seen and
> can easilly be fixed. This allows the quality of the hack to be ensured,
> relieving many webapps from doing hacks themselves.

> While this hack is being used, some effort should be put into
> constructively creating a proper solution for the problems that were
> hacked around. Saying "this is not allowed because of X policy" is not
> helpful as the costs of disallowing it greatly outweigh the costs of
> overlooking it in a controlled manner.

Well yeah, but the problem here is that portage doesn't allow such stuff to
be used safely (locking issues, race conditions). And yeah, it's kinda
lacking sort of feature that would have its use in a couple of places.

--

jakub

On Tuesday 28 February 2006 16:31, Ciaran McCreesh wrote:
> On Tue, 28 Feb 2006 16:17:20 +0100 Paul de Vrieze <pauldv@gentoo.org>
>
> wrote:
> | On Tuesday 28 February 2006 15:52, Ciaran McCreesh wrote:
> | > Yes, it's an utterly trivial problem, but it is a QA violation.
> | > Getting a complete list is something that takes a heck of a lot
> | > longer, and I have yet to be convinced that my time would not be
> | > better spent elsewhere.
> |
> | Where is a coding style problem related to quality of code in general
> | and assurance in particular?
>
> It's more relevant than you might think. Screwing up layout like that
> breaks various QA checking tools that assume that things are in the
> standard format.

Then fix the damn tools. I've had runins with broken tools earlier. If you
want the ebuild format to be stricter, well, make portage complain.
Otherwise, fix up your parser.

> Proper coding style is part of being proper.

Coding style issues exist in degrees. White space issues such as these are of
very low priority. Broken QA tools should not be an excuse to give them
higher priority.

Paul

--
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

Ciaran McCreesh wrote:
> On Tue, 28 Feb 2006 18:30:24 +0100 Jakub Moc <jakub@gentoo.org> wrote:
> | OK, so kernel-2.eclass is abusing the slot as well, go scream on
> | kernel devs.
>
> No. kernel-2 installs sources, not an actual package.

Not exactly. The webapp stuff gets installed to /usr/share/webapps/${PN}/${PVR},
which is about the equivalent of /usr/src/linux because you will never point
your webserver to that directory. If you do, you're just dumb and deserve a
security flaw. webapp-config installs the packages to /var/www (equivalent of
/boot), where the webserver should make it available. So the SLOT="${PVR}" is
not an issue in this case.

--
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
--
gentoo-dev@gentoo.org mailing list

On Wednesday 01 March 2006 02:37, Jakub Moc wrote:
> 28.2.2006, 16:29:10, Ciaran McCreesh wrote:
> > The whole devrel handbook is policy, except where otherwise noted. See
> > Mike's reply.
>
> Then any significant change there requires a sane procedure.

which does not change the fact that the devrel handbook is policy unless
otherwise noted as suggestion or guideline
-mike
--
gentoo-dev@gentoo.org mailing list