[gentoo-dev] packages going into the tree with non-gentoo maintainers

[gentoo-dev] packages going into the tree with non-gentoo maintainers

[Kevin F. Quinn]

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

triggered by bug #77751: hspell lists a non-gentoo.org address for
the maintainer email, the herd as maintainer-needed, and no other
addresses.

Is this sort of thing now ok?

I don't think it's a good idea for devs to be putting stuff into the
tree without taking responsibility for it.  I would expect that either
the herd is set appropriately (which means either the committer be a
member of the herd, or the herd explicitly agree to be proxy), or the
committer be listed as a maintainer email address along with whoever is
being proxied.  Further I believe bugs against such packages should be
assigned to the @gentoo.org address (proxy maintainer if there is one,
herd otherwise), and CC'ed to the proxied maintainer address.


Packages affected:

app-arch/rzip
app-portage/getdelta
app-text/hspell
net-misc/vnc
sys-fs/dmraidcvs

All of the above list a non-gentoo.org address as mainainer, but do not
have either a proper herd, or a specific gentoo.org dev listed as
maintainer.

-- 
Kevin F. Quinn

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

Re: [gentoo-dev] packages going into the tree with non-gentoo maintainers

[Carsten Lohrke]

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

On Sunday 03 September 2006 11:20, Kevin F. Quinn wrote:
> triggered by bug #77751: hspell lists a non-gentoo.org address for
> the maintainer email, the herd as maintainer-needed, and no other
> addresses.
>
> Is this sort of thing now ok?

No.


Carsten

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

[gentoo-dev] Re: packages going into the tree with non-gentoo maintainers

[Stefan Schweizer]

Kevin F. Quinn wrote:
> I don't think it's a good idea for devs to be putting stuff into the
> tree without taking responsibility for it.  
sure I can put myself in there but it will help no one because I cannot test
the thing. Furthermore I am actually part of maintainer-needed and commit
fixes there. I am also on the maintainer-needed email alias.

Also maintainer-needed makes obvious to everyone that they do not have to
ask me to fix sth. or take over the package -> less communication overhead.

> I would expect that either 
> the herd is set appropriately (which means either the committer be a
> member of the herd, or the herd explicitly agree to be proxy), 
which is the case here.

> or the 
> committer be listed as a maintainer email address along with whoever is
> being proxied.  
the committer in this case has no interest in maintaining the thing. And for
proxying it does not matter who is proxying.

> Further I believe bugs against such packages should be 
> assigned to the @gentoo.org address (proxy maintainer if there is one,
> herd otherwise), and CC'ed to the proxied maintainer address.

this does not allow the actual maintainer to close the bug and causes a lot
of bugspam for a person who does not care about it and should be only
contacted in the end to commit fixes/patches/bumps.

Regards,
Stefan

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: packages going into the tree with non-gentoo maintainers

[Bryan Ãstergaard]

On Sun, Sep 03, 2006 at 01:57:10PM +0200, Stefan Schweizer wrote:
> Kevin F. Quinn wrote:
> > I don't think it's a good idea for devs to be putting stuff into the
> > tree without taking responsibility for it.  
> sure I can put myself in there but it will help no one because I cannot test
> the thing. Furthermore I am actually part of maintainer-needed and commit
> fixes there. I am also on the maintainer-needed email alias.
> 
> Also maintainer-needed makes obvious to everyone that they do not have to
> ask me to fix sth. or take over the package -> less communication overhead.
Ok, let me see if I can get this straight.. You're saying that
maintainer-needed requires less communication overhead compared to
ebuilds with maintainers assigned? And that maintainer-needed is
therefore better than ebuilds having maintainers.

I don't even want to comment on how insane I find that line of thought..
> 
> > I would expect that either 
> > the herd is set appropriately (which means either the committer be a
> > member of the herd, or the herd explicitly agree to be proxy), 
> which is the case here.
> 
Maintainer-needed being the waste basket for unmaintained packages in
the portage tree that doesn't give me a lot of confidence tbh.
> > or the 
> > committer be listed as a maintainer email address along with whoever is
> > being proxied.  
> the committer in this case has no interest in maintaining the thing. And for
> proxying it does not matter who is proxying.
Of course it matters. There's a big difference between a proxy
maintainer having to ask a *specific* dev that's proxying his ebuild
updates/changes or trying to find a random dev willing to help.
> 
> > Further I believe bugs against such packages should be 
> > assigned to the @gentoo.org address (proxy maintainer if there is one,
> > herd otherwise), and CC'ed to the proxied maintainer address.
> 
> this does not allow the actual maintainer to close the bug and causes a lot
> of bugspam for a person who does not care about it and should be only
> contacted in the end to commit fixes/patches/bumps.
Shouldn't matter too much as a gentoo dev is still responsible for the
package? Nobody shoud be adding stuff to portage without taking
responsibility for it.

Regards,
Bryan Østergaard
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: packages going into the tree with non-gentoo maintainers

[Kevin F. Quinn]

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

On Sun, 03 Sep 2006 13:57:10 +0200
Stefan Schweizer <genstef@gentoo.org> wrote:

> Kevin F. Quinn wrote:
> > I don't think it's a good idea for devs to be putting stuff into the
> > tree without taking responsibility for it.  
> sure I can put myself in there but it will help no one because I
> cannot test the thing.

Then you should not have committed it - as a dev it is your
responsibility to test any ebuilds your commit.  There's nothing
stopping you doing the normal checks on the ebuild, even if you can't
read Hebrew.  For example you should verify whether the '-j1' is really
necessary on emake.

> Furthermore I am actually part of
> maintainer-needed and commit fixes there. I am also on the
> maintainer-needed email alias.

For a start, "maintainer-needed" is just a mail alias, it is not a
herd and never can be, by definition. See
http://www.gentoo.org/proj/en/metastructure/herds/herds.xml.

The point of a herd is to provide a contact for maintenance of the
member packages - and maintainer-needed by definition does not do
maintenance.

> Also maintainer-needed makes obvious to everyone that they do not
> have to ask me to fix sth. or take over the package -> less
> communication overhead.

You can put notes into metadata.xml - see other instances for
examples; the easiest way is to have two maintainer entries, and in
the description field describe the maintenance arrangement.  Putting
"maintainer-needed" as the herd just means the package is essentially
unmaintained, and is a candidate for removal. We should not be putting
stuff into the official tree if no dev has taken responsibility for it.

> > I would expect that either 
> > the herd is set appropriately (which means either the committer be a
> > member of the herd, or the herd explicitly agree to be proxy), 
> which is the case here.

See above - maintainer-needed does not satisfy the requirements of the
herd entry.

> > or the 
> > committer be listed as a maintainer email address along with
> > whoever is being proxied.  
> the committer in this case has no interest in maintaining the thing.

Even more reason the package should acquire a dev to maintain it, or be
removed from the tree.

> And for proxying it does not matter who is proxying.

Proxying is more than just "doing whatever the non-dev says".  By
committing to the tree, you take full responsibility for those
commits.

> > Further I believe bugs against such packages should be 
> > assigned to the @gentoo.org address (proxy maintainer if there is
> > one, herd otherwise), and CC'ed to the proxied maintainer address.
> 
> this does not allow the actual maintainer to close the bug and causes
> a lot of bugspam for a person who does not care about it and should
> be only contacted in the end to commit fixes/patches/bumps.

Whoever does the commit takes formal responsibility for those commits.
Therefore they should take note of bug activity relating to those
commits.  If they don't care about that then they should not be acting
as proxy in that case.


Surely this is what the Sunrise overlay was for; user-supplied ebuilds
that don't have a a Gentoo dev to take responsibility for maintenance.

-- 
Kevin F. Quinn

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

Re: [gentoo-dev] Re: packages going into the tree with non-gentoo maintainers

[Paul de Vrieze]

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

On Sunday 03 September 2006 13:57, Stefan Schweizer wrote:
> Kevin F. Quinn wrote:
> > I don't think it's a good idea for devs to be putting stuff into the
> > tree without taking responsibility for it.
>
> sure I can put myself in there but it will help no one because I cannot
> test the thing. Furthermore I am actually part of maintainer-needed and
> commit fixes there. I am also on the maintainer-needed email alias.
>
> Also maintainer-needed makes obvious to everyone that they do not have to
> ask me to fix sth. or take over the package -> less communication overhead.

For this stuff, add a comment to the metadata.xml file. Don't do it in this 
less than obvious way. The maintainer must still be someone with a gentoo 
email.

Paul

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

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

[gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Stefan Schweizer]

Kevin F. Quinn wrote:
> Then you should not have committed it - as a dev it is your
> responsibility to test any ebuilds your commit.  There's nothing
> stopping you doing the normal checks on the ebuild, even if you can't
> read Hebrew.  For example you should verify whether the '-j1' is really
> necessary on emake.

yeah, I do those tests of course. Had not thought of -j1 though. You are
right - it is not needed. Sorry :( 

>> Furthermore I am actually part of
>> maintainer-needed and commit fixes there. I am also on the
>> maintainer-needed email alias.
> 
> The point of a herd is to provide a contact for maintenance of the
> member packages - and maintainer-needed by definition does not do
> maintenance.

yup. This is just so I can keep track of bugs filed against it while clearly
separating them from bugs for packages which I judge more important and
maintain directly. Support is provided by upstream and the user,
build-testing/committing/ebuildfixes is provided by maintainer-needed
(which is most likely me)

>> Also maintainer-needed makes obvious to everyone that they do not
>> have to ask me to fix sth. or take over the package -> less
>> communication overhead.
> 
> You can put notes into metadata.xml - see other instances for
> examples; the easiest way is to have two maintainer entries, and in
> the description field describe the maintenance arrangement.  

Give jeeves and herdstat support for reading notes and I might consider it.
What annoys me most when putting myself in is that arch teams will ask me
if I would want that stable. I honestly do not care.
The annoying thing about it is that I get more than one bugmailspam about it
and it also happens regularly for new versions :/
Such things the user should be able to decide himself.

> Putting 
> "maintainer-needed" as the herd just means the package is essentially
> unmaintained, and is a candidate for removal. 

that is what I want to imply by putting it in, you got me correctly.

> We should not be putting 
> stuff into the official tree if no dev has taken responsibility for it.

we are not putting new stuff in there, we are just fixing existing stuff so
that it does not need to be removed.

>> And for proxying it does not matter who is proxying.
> 
> Proxying is more than just "doing whatever the non-dev says".  By
> committing to the tree, you take full responsibility for those
> commits.

I do. And if it breaks anyone I will fix it of course.

> Whoever does the commit takes formal responsibility for those commits.
> Therefore they should take note of bug activity relating to those
> commits.  If they don't care about that then they should not be acting
> as proxy in that case.

I do take note of all maintainer-needed bug activity. I do not put in myself
to clearly separate those from the other bugs where I am directly
maintaining stuff myself.

> Surely this is what the Sunrise overlay was for; user-supplied ebuilds
> that don't have a a Gentoo dev to take responsibility for maintenance.

true. Sunrise is only for new ebuilds however. It is not designed as a place
to dump ebuilds from portage to and force users of them to use Sunrise.
If you or antarus or someone else wants to remove it from the tree feel free
to do so, I am not in metadata, I do not care. I just fixed the bug.

- Stefan

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Stefan Schweizer]

Paul de Vrieze wrote:
> For this stuff, add a comment to the metadata.xml file. Don't do it in
> this less than obvious way. 

arch teams for example will still contact me then for stabilizing, I do not
want that. jeeves and herdstat do not support comments and the metadata is
not often read directly.

> The maintainer must still be someone with a
> gentoo email.

is that written down somewhere? I was under the impression that it is
allowed and have seen it used for example
in /usr/portage/www-client/links/metadata.xml

- Stefan

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Stefan Schweizer]

Bryan Ãstergaard wrote:
> Ok, let me see if I can get this straight.. You're saying that
> maintainer-needed requires less communication overhead compared to
> ebuilds with maintainers assigned? And that maintainer-needed is
> therefore better than ebuilds having maintainers.

agreed. I prefer to fix ebuilds in maintainer-needed than maintained ebuilds
because communication takes eternally compared to fixing simple things
quickly.

>> the committer in this case has no interest in maintaining the thing. And
>> for proxying it does not matter who is proxying.
> Of course it matters. There's a big difference between a proxy
> maintainer having to ask a *specific* dev that's proxying his ebuild
> updates/changes or trying to find a random dev willing to help.

I will of course commit all fixes when anyone asks me to. But it does not
matter if I commit them or anyone else who cares and has access levels.

>> this does not allow the actual maintainer to close the bug and causes a
>> lot of bugspam for a person who does not care about it and should be only
>> contacted in the end to commit fixes/patches/bumps.
> Shouldn't matter too much as a gentoo dev is still responsible for the
> package? 

of course he is still responsible. Does not mean he likes to get 10 mails
about people asking for stable keywords and arches stabilizing every month.

> Nobody shoud be adding stuff to portage without taking 
> responsibility for it.

I am not adding stuff. I am fixing existing packages. And I am taking
responsibility. The maintainer can always assign me bugs if he thinks I
should take care of them and I read and take care of them anyway because I
am on maintainer-needed.

- Stefan

PS: mailing lists are a bit broken. 3 people answer me and ask almost the
same and I answer almost the same again ..

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Kevin F. Quinn]

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

On Sun, 03 Sep 2006 16:22:37 +0200
Stefan Schweizer <genstef@gentoo.org> wrote:

> Paul de Vrieze wrote:
> > For this stuff, add a comment to the metadata.xml file. Don't do it
> > in this less than obvious way. 
> 
> arch teams for example will still contact me then for stabilizing, I
> do not want that. jeeves and herdstat do not support comments and the
> metadata is not often read directly.

If you don't care whether a package is stable or not, just let the arch
team go ahead and do what they need to do to stabilise when they wish
to.  The role of package maintainer has nothing to do with
stabilisation, which is the preserve of the arch teams.

> > The maintainer must still be someone with a
> > gentoo email.
> 
> is that written down somewhere? I was under the impression that it is
> allowed and have seen it used for example
> in /usr/portage/www-client/links/metadata.xml

You'll notice that there are two maintainer blocks in there, one for
the non-gentoo "third-party" maintainer, and one for the Gentoo dev who
proxies - the "official Gentoo" maintainer.  There are several packages
like this.

What I'm conerned about is packages that have no Gentoo maintainer,
something that should obviously never happen for packages in the
official tree.

-- 
Kevin F. Quinn

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

[gentoo-dev] Re: packages going into the tree with non-gentoo maintainers

[Ryan Hill]

Kevin F. Quinn wrote:
> If you don't care whether a package is stable or not, just let the arch
> team go ahead and do what they need to do to stabilise when they wish
> to.  The role of package maintainer has nothing to do with
> stabilisation, which is the preserve of the arch teams.

Um, sure it does.  We're not going to stabilize something without 
attempting to contact the maintainer first.  If it's maintainer-needed 
we'll just go ahead though.

--de.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: packages going into the tree with non-gentoo maintainers

[Kevin F. Quinn]

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

On Sun, 03 Sep 2006 17:54:33 -0600
Ryan Hill <dirtyepic.sk@gmail.com> wrote:

> Kevin F. Quinn wrote:
> > If you don't care whether a package is stable or not, just let the
> > arch team go ahead and do what they need to do to stabilise when
> > they wish to.  The role of package maintainer has nothing to do with
> > stabilisation, which is the preserve of the arch teams.
> 
> Um, sure it does.  We're not going to stabilize something without 
> attempting to contact the maintainer first.  If it's
> maintainer-needed we'll just go ahead though.

Yeah; I meant that ebuild maintainers don't do stabilisation, the arch
teams do, and that if the ebuild maintainer isn't interested in whether
the package is stable or not, they can leave it for the arch team (and
ATs) to do.

-- 
Kevin F. Quinn

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

Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Andrej Kacian]

On Sun, 03 Sep 2006 16:36:14 +0200
Stefan Schweizer <genstef@gentoo.org> wrote:

> >> this does not allow the actual maintainer to close the bug and
> >> causes a lot of bugspam for a person who does not care about it
> >> and should be only contacted in the end to commit
> >> fixes/patches/bumps.
> > Shouldn't matter too much as a gentoo dev is still responsible for
> > the package? 
> 
> of course he is still responsible. Does not mean he likes to get 10
> mails about people asking for stable keywords and arches stabilizing
> every month.

That comes with being responsible for a package in Gentoo. Live with
it.

> > Nobody shoud be adding stuff to portage without taking 
> > responsibility for it.
> 
> I am not adding stuff. I am fixing existing packages. And I am taking
> responsibility. The maintainer can always assign me bugs if he thinks
> I should take care of them and I read and take care of them anyway
> because I am on maintainer-needed.

That's fine and all, but it sort of sets a precedent - not everyone is
on maintainer-needed.

> PS: mailing lists are a bit broken. 3 people answer me and ask almost
> the same and I answer almost the same again ..

Then answer in only one subthread, and rest of them will die... :)

Kind regards,
-- 
Andrej Kacian

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Carsten Lohrke]

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

On Sunday 03 September 2006 16:36, Stefan Schweizer wrote:
> I am not adding stuff. I am fixing existing packages. And I am taking
> responsibility.

How wonderful this sort of "maintenance" is you can read here:

https://bugs.gentoo.org/show_bug.cgi?id=146626

Am I the only one who has a problem with this?


Carsten

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

Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Stephen P. Becker]

Carsten Lohrke wrote:
> On Sunday 03 September 2006 16:36, Stefan Schweizer wrote:
>> I am not adding stuff. I am fixing existing packages. And I am taking
>> responsibility.
> 
> How wonderful this sort of "maintenance" is you can read here:
> 
> https://bugs.gentoo.org/show_bug.cgi?id=146626
> 
> Am I the only one who has a problem with this?

I find this not at all surprising considering that one of his recent 
mentees failed so many of the ebuild quiz questions so badly as to be 
outright denied (which is not at all the recruit's fault).  In any case, 
if you don't appreciate Stefan "taking responsibility" for stuff which 
he has no business touching in the first place, you have every right to 
tell him to piss off.

-Steve
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] packages going into the tree with non-gentoo maintainers

[Mike Frysinger]

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

lets try resending this since our shitty mail servers seemed to have eaten it

On Sunday 03 September 2006 05:20, Kevin F. Quinn wrote:
> or the
> committer be listed as a maintainer email address along with whoever is
> being proxied.

maybe extend metadata.xml syntax ... add a proxy dev maintainer tag and leave 
the external non-gentoo as the maintainer

> Further I believe bugs against such packages should be  
> assigned to the @gentoo.org address (proxy maintainer if there is one,
> herd otherwise), and CC'ed to the proxied maintainer address.

i dont think this really matters ... assign it to the guy doing the fixing and 
cc the guy doing the committing
-mike

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

Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Brian Harring]

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

On Wed, Sep 06, 2006 at 10:37:21PM -0400, Stephen P. Becker wrote:
> Carsten Lohrke wrote:
> >On Sunday 03 September 2006 16:36, Stefan Schweizer wrote:
> >>I am not adding stuff. I am fixing existing packages. And I am taking
> >>responsibility.
> >
> >How wonderful this sort of "maintenance" is you can read here:
> >
> >https://bugs.gentoo.org/show_bug.cgi?id=146626
> >
> >Am I the only one who has a problem with this?
> 
> I find this not at all surprising considering that one of his recent 
> mentees failed so many of the ebuild quiz questions so badly as to be 
> outright denied (which is not at all the recruit's fault).  In any case, 
> if you don't appreciate Stefan "taking responsibility" for stuff which 
> he has no business touching in the first place, you have every right to 
> tell him to piss off.

Maybe I'm just a moron (well, likely I am), but why are you two 
posting this shit on the dev ml?

Conflict for a change, fine, carlo go revert it. 

Crazy notion, but it's a one minute revert, yes it's not your mess but 
it is your package and _your_ users, leaving your users hanging 
because you're trying to make genstef clean something up screws the 
users over.

The proper forum for crap like this is via taking it up with 
QA/devrel.

Screaming about a change on the ml doesn't accomplish anything more 
then making you look like a jack ass trying to publically embarass 
someone you're pissed at; at least carlo has a reason, stephen you're 
just being an asshole.

Further, Stephen shouldn't even know about a candidates failing, let 
alone go stating it on a public ml.

Really nice one there; someone tries to help, deemed not yet skilled 
enough to have access to the tree, and you're bringing it up as a way 
to take potshots at genstef.

Further, you're taking a potshot at a dev candidate who via going 
through the process was at least *trying* to contribute, even if they 
didn't pass the quiz.

Carlo, go talk to devrel, stephen, go do your monthly mips stabling.
Meanwhile spare us the idiocy, and do something productive.

Screaming on a ml won't solve the conflict, just makes the screamer 
look childish.
~harring

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

Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Mike Frysinger]

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

lets try resending this since our shitty mail servers seemed to have eaten it

On Sunday 03 September 2006 10:22, Stefan Schweizer wrote:
> Paul de Vrieze wrote:
> > The maintainer must still be someone with a
> > gentoo email.
>
> is that written down somewhere? I was under the impression that it is
> allowed and have seen it used for example
> in /usr/portage/www-client/links/metadata.xml

except that metadata has something the ones in question here do not: a contact 
at gentoo.org if the non-gentoo.org is AFK
-mike

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

Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Alec Warner]

Carsten Lohrke wrote:
> On Sunday 03 September 2006 16:36, Stefan Schweizer wrote:
>> I am not adding stuff. I am fixing existing packages. And I am taking
>> responsibility.
> 
> How wonderful this sort of "maintenance" is you can read here:
> 
> https://bugs.gentoo.org/show_bug.cgi?id=146626
> 
> Am I the only one who has a problem with this?
> 
> 
> Carsten

I would agree on principle, however this is NOT the correct venue for
this.  If you have an issue with another developer; you don't go
complain on a public ML; you TALK to the developer.  If you can't work
it out, you talk to your project lead.  If THEY can't work it out, you
talk to the ombudsman, and so forth.  Everyone knows the policy and yet
no one follows it.  I don't want to see this thread continue; you know
what you have to do.[1]

[1] http://www.gentoo.org/proj/en/devrel/policy.xml
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Luca Barbato]

Carsten Lohrke wrote:
> On Sunday 03 September 2006 16:36, Stefan Schweizer wrote:
>> I am not adding stuff. I am fixing existing packages. And I am taking
>> responsibility.
> 
> How wonderful this sort of "maintenance" is you can read here:
> 
> https://bugs.gentoo.org/show_bug.cgi?id=146626
> 
> Am I the only one who has a problem with this?
> 

Genstef PLEASE always contact the related herd before adding stuff.

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: Re: packages going into the tree with non-gentoo maintainers

[Stefan Schweizer]

Luca Barbato wrote:

> Carsten Lohrke wrote:
>> On Sunday 03 September 2006 16:36, Stefan Schweizer wrote:
>>> I am not adding stuff. I am fixing existing packages. And I am taking
>>> responsibility.
>> 
>> How wonderful this sort of "maintenance" is you can read here:
>> 
>> https://bugs.gentoo.org/show_bug.cgi?id=146626
>> 
>> Am I the only one who has a problem with this?
>> 
> 
> Genstef PLEASE always contact the related herd before adding stuff.

I am part of the kde herd, thanks.

- Stefan

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Stuart Herbert]

On 9/7/06, Carsten Lohrke <carlo@gentoo.org> wrote:
> How wonderful this sort of "maintenance" is you can read here:
>
> https://bugs.gentoo.org/show_bug.cgi?id=146626
>
> Am I the only one who has a problem with this?

No.  And I'm sure I'm not the only one who has a problem with your
comment in that bug either.  Bugzilla isn't there for flaming other
devs.

There was a time when we used to suspend devs for doing that.

Best regards,
Stu
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Danny van Dyk]

Am Donnerstag, 7. September 2006 11:11 schrieb Stuart Herbert:
> On 9/7/06, Carsten Lohrke <carlo@gentoo.org> wrote:
> > How wonderful this sort of "maintenance" is you can read here:
> >
> > https://bugs.gentoo.org/show_bug.cgi?id=146626
> >
> > Am I the only one who has a problem with this?
>
> No.  And I'm sure I'm not the only one who has a problem with your
> comment in that bug either.  Bugzilla isn't there for flaming other
> devs.
>
> There was a time when we used to suspend devs for doing that.
Sadly we don't suspend developers for extended history of QA violations.

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

Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Jon Portnoy]

On Thu, Sep 07, 2006 at 12:17:27PM +0200, Danny van Dyk wrote:
> Am Donnerstag, 7. September 2006 11:11 schrieb Stuart Herbert:
> > On 9/7/06, Carsten Lohrke <carlo@gentoo.org> wrote:
> > > How wonderful this sort of "maintenance" is you can read here:
> > >
> > > https://bugs.gentoo.org/show_bug.cgi?id=146626
> > >
> > > Am I the only one who has a problem with this?
> >
> > No.  And I'm sure I'm not the only one who has a problem with your
> > comment in that bug either.  Bugzilla isn't there for flaming other
> > devs.
> >
> > There was a time when we used to suspend devs for doing that.
> Sadly we don't suspend developers for extended history of QA violations.
> 

Not true, unfortunately these problems seem to very rarely get 
communicated to devrel...

-- 
Jon Portnoy
avenj/irc.freenode.net
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Carsten Lohrke]

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

On Thursday 07 September 2006 11:11, Stuart Herbert wrote:
> And I'm sure I'm not the only one who has a problem with your
> comment in that bug either.  Bugzilla isn't there for flaming other
> devs.

I did not do an ad hominem attack, but have a problem with a single action and 
listed my points. I wonder what is supposed to count as flaming nowadays... 


Carsten

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

Re: [gentoo-dev] Re: Re: Re: packages going into the tree with non-gentoo maintainers

[Carsten Lohrke]

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

On Thursday 07 September 2006 07:58, Stefan Schweizer wrote:
> I am part of the kde herd, thanks.

To my knowledge you have never asked to join the KDE team, nor did I see you 
helping tracking down KDE bug reports ever. Just adding yourself doesn't 
work.


Carsten







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

Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Simon Stelling]

Alec Warner wrote:
> If you can't work
> it out, you talk to your project lead.  If THEY can't work it out, you
> talk to the ombudsman, and so forth.  Everyone knows the policy and yet
> no one follows it.  I don't want to see this thread continue; you know
> what you have to do.[1]
> 
> [1] http://www.gentoo.org/proj/en/devrel/policy.xml

Don't even have to go that way. It's far simpler:

(quoting the devrel policy you linked to:)

"Issues not necessarily related to personal conflict, such as
intentional or repeated policy breaches, malicious or abrasive behavior
to users or developers, or similar developer-specific behavioral
problems should be brought directly to Developer Relations via
devrel@gentoo.org. These should be dealt with on a case-by-case basis by
Developer Relations and may require disciplinary action."

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Diego 'Flameeyes' Pettenò]

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

On Thursday 07 September 2006 04:09, Carsten Lohrke wrote:
> How wonderful this sort of "maintenance" is you can read here:
I'll try to overlook the reverted changes in kdelibs for bug fixes, the 
improper ${ROOT} injected in my changes where it wasn't supposed to be, the 
broken opengl on kdelibs checks that appeared last month, unhelpful comments 
when trying to achieve something from the users, a bug lingering for an year 
and a half because my solution wasn't good enough, and that was the solution 
that now kde 3.5.4 implements, decisions against the interest and request of 
all the users and developers, QA bugs opened without checking facts, GWN 
articles sent without notes on kde@g.o alias for what I can see ...

No, I'm not referring to Stefan. He's human and he did mistakes, but if 
someone would be allowed to put them in public, that would be his lead (that 
in this case is Caleb, not you), or the QA team.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Stephen P. Becker]

Brian Harring wrote:
> On Wed, Sep 06, 2006 at 10:37:21PM -0400, Stephen P. Becker wrote:
>> Carsten Lohrke wrote:
>>> On Sunday 03 September 2006 16:36, Stefan Schweizer wrote:
>>>> I am not adding stuff. I am fixing existing packages. And I am taking
>>>> responsibility.
>>> How wonderful this sort of "maintenance" is you can read here:
>>>
>>> https://bugs.gentoo.org/show_bug.cgi?id=146626
>>>
>>> Am I the only one who has a problem with this?
>> I find this not at all surprising considering that one of his recent 
>> mentees failed so many of the ebuild quiz questions so badly as to be 
>> outright denied (which is not at all the recruit's fault).  In any case, 
>> if you don't appreciate Stefan "taking responsibility" for stuff which 
>> he has no business touching in the first place, you have every right to 
>> tell him to piss off.
> 
> Maybe I'm just a moron (well, likely I am), but why are you two 
> posting this shit on the dev ml?
> 
> Conflict for a change, fine, carlo go revert it. 
> 
> Crazy notion, but it's a one minute revert, yes it's not your mess but 
> it is your package and _your_ users, leaving your users hanging 
> because you're trying to make genstef clean something up screws the 
> users over.

So what is wrong with making people accountable for stuff which *they* 
broke?

> 
> The proper forum for crap like this is via taking it up with 
> QA/devrel.
> 
> Screaming about a change on the ml doesn't accomplish anything more 
> then making you look like a jack ass trying to publically embarass 
> someone you're pissed at; at least carlo has a reason, stephen you're 
> just being an asshole.

Yes, I am, because it pisses me off when people outright break things 
because they had no clue what they were doing.  Furthermore, he did 
break mips with that change, so that makes it my business to whip out 
the cluestick.  My previous email was intended to show that he doesn't 
seem to have any idea what he was doing.

> 
> Further, Stephen shouldn't even know about a candidates failing, let 
> alone go stating it on a public ml.
> 
> Really nice one there; someone tries to help, deemed not yet skilled 
> enough to have access to the tree, and you're bringing it up as a way 
> to take potshots at genstef.

Note that I have no idea who this person is, and that I also stated it 
is not their fault at all.  Pretty much anybody is capable of learning 
the skills required to have access to the tree.  Failing the ebuild quiz 
is a reflection on the mentor, which was my point.

> 
> Further, you're taking a potshot at a dev candidate who via going 
> through the process was at least *trying* to contribute, even if they 
> didn't pass the quiz.

No, I'm not, see above.  I encourage this candidate to keep 
contributing, and to ask questions of anybody who can help.

> 
> Carlo, go talk to devrel, stephen, go do your monthly mips stabling.
> Meanwhile spare us the idiocy, and do something productive.

That's a funny statement, coming from you.

> 
> Screaming on a ml won't solve the conflict, just makes the screamer 
> look childish.

That's an even funnier statement, coming from you.

-Steve
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Jakub Moc]

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

Stephen P. Becker wrote:
> Brian Harring wrote:
>> The proper forum for crap like this is via taking it up with QA/devrel.
>>
>> Screaming about a change on the ml doesn't accomplish anything more
>> then making you look like a jack ass trying to publically embarass
>> someone you're pissed at; at least carlo has a reason, stephen you're
>> just being an asshole.
> 
> Yes, I am, because it pisses me off when people outright break things
> because they had no clue what they were doing.  Furthermore, he did
> break mips with that change, so that makes it my business to whip out
> the cluestick.  My previous email was intended to show that he doesn't
> seem to have any idea what he was doing.

I wonder how exactly genstef broke mips, 'cos mind you, he just reverted
to what the ebuild was doing before Bug 114161 was fixed by
hard-disabling of hspell [1]. Since mips doesn't have hspell keyworded,
it wasn't affected by that bug before it's been fixed and it wasn't
affected after the bug has been reintroduced now [2] (Additionally there
shouldn't be any problem now except for one called automagic
dependencies since the blocker for incompatible versions was there).

[1]
http://sources.gentoo.org/viewcvs.py/gentoo-x86/kde-base/kdelibs/kdelibs-3.5.0.ebuild?hideattic=0&r1=1.4&r2=1.5

[2]
http://sources.gentoo.org/viewcvs.py/gentoo-x86/kde-base/kdelibs/kdelibs-3.5.4-r1.ebuild?r1=1.3&r2=1.4

So, how exactly is this public bitching useful?

-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)


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

Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Carsten Lohrke]

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

On Thursday 07 September 2006 13:48, Jakub Moc wrote:
> I wonder how exactly genstef broke mips, 'cos mind you, he just reverted
> to what the ebuild was doing before Bug 114161 was fixed by
> hard-disabling of hspell [1]. Since mips doesn't have hspell keyworded,
> it wasn't affected by that bug before it's been fixed and it wasn't
> affected after the bug has been reintroduced now [2] (Additionally there
> shouldn't be any problem now except for one called automagic
> dependencies since the blocker for incompatible versions was there).

You're right. It was very early in the morning, I saw the dependency not 
matching architectures, but wasn't aware that blocker dependencies are not 
taken into account with regards to tree breakage. So:


Dear Stefan,

I was wrong, you didn't break the tree. Please excuse that I did accuse you 
doing this. I regret not having verfied my position, before i filed the bug. 
Furthermore I'd like to add that, as blubb put it in an private email, my 
intention wasn't to put you down, but to shed light on the issue - apparently 
making myself a fool.



One question remains: Is it needed/correct that Portage doesn't take blockers 
for architecture breakages into account? Such a line/prefix is easily changed 
and when someone - whatever the bad reason is - uses cvs commit, a real tree 
breakage is the cause.


Carsten

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

Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Carsten Lohrke]

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

On Thursday 07 September 2006 13:25, Diego 'Flameeyes' Pettenò wrote:
> I'll try to overlook the reverted changes in kdelibs for bug fixes, the
> improper ${ROOT} injected in my changes where it wasn't supposed to be, the
> broken opengl on kdelibs checks that appeared last month, unhelpful
> comments when trying to achieve something from the users, a bug lingering
> for an year and a half because my solution wasn't good enough, and that was
> the solution that now kde 3.5.4 implements, decisions against the interest
> and request of all the users and developers, QA bugs opened without
> checking facts, GWN articles sent without notes on kde@g.o alias for what I
> can see ...

I do make mistakes too, yes. That I did revert your changes was a problem with 
a local script - still - my mistake. No idea what you're referring to with 
your "unhelpful comments" stanza as well as the "bug lingering around". There 
are a lot of bugs lingering around and I do not have a todo list tracking 
them in a specific time frame. QA bug_s_? Regarding the GWN, you should have 
gotten the email, in  which I pointed out that it's time to remove KDE 3.4 
from the tree.


Carsten



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

Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Simon Stelling]

Carsten Lohrke wrote:
> One question remains: Is it needed/correct that Portage doesn't take blockers 
> for architecture breakages into account? Such a line/prefix is easily changed 
> and when someone - whatever the bad reason is - uses cvs commit, a real tree 
> breakage is the cause.

The behaviour is correct. The depstring in question was
"!<app-text/hunspell-1.0", which means that you can't have <hunspell-1.0
and kdelibs installed on a system at the same time. Reason for this
could e.g. be file collisions that got fixed in hunspell-1.0.

If the depstring was "!<app-text/hunspell-1.0 app-text/hunspell", (same
as ">=app-text/hunspell-1.0", just retarded)  repoman would complain loudly.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Jakub Moc]

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

Simon Stelling wrote:
> Carsten Lohrke wrote:
>> One question remains: Is it needed/correct that Portage doesn't take blockers 
>> for architecture breakages into account? Such a line/prefix is easily changed 
>> and when someone - whatever the bad reason is - uses cvs commit, a real tree 
>> breakage is the cause.
> 
> The behaviour is correct. The depstring in question was
> "!<app-text/hunspell-1.0", which means that you can't have <hunspell-1.0
> and kdelibs installed on a system at the same time. Reason for this
> could e.g. be file collisions that got fixed in hunspell-1.0.
> 
> If the depstring was "!<app-text/hunspell-1.0 app-text/hunspell", (same
> as ">=app-text/hunspell-1.0", just retarded)  repoman would complain loudly.

Well, now the ebuild is broken even worse, since the blocker is gone [1]
and hspell is still not disabled, so it will go kaboom when someone
installs the stable version.

[1]
http://sources.gentoo.org/viewcvs.py/gentoo-x86/kde-base/kdelibs/kdelibs-3.5.4-r1.ebuild?r1=1.4&r2=1.5

carlo, you might want to revert it properly, instead of reverting only
half of the previous commit you've been complaining about here.

-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)


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

Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Simon Stelling]

Jakub Moc wrote:
> carlo, you might want to revert it properly, instead of reverting only
> half of the previous commit you've been complaining about here.

Could you please take such stuff where it belongs next time? (To the
bug, that is.) There's really no need to point out such things on -dev,
because this is not a "hey everybody, look, $dev did something stupid!"
list. It doesn't matter whether $dev is genstef or carlo or anybody
else. The bitching ain't gonna stop if you just "give back".

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Kevin F. Quinn]

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

On Thu, 07 Sep 2006 16:42:11 +0200
Simon Stelling <blubb@gentoo.org> wrote:

> Carsten Lohrke wrote:
> > One question remains: Is it needed/correct that Portage doesn't
> > take blockers for architecture breakages into account? Such a
> > line/prefix is easily changed and when someone - whatever the bad
> > reason is - uses cvs commit, a real tree breakage is the cause.
> 
> The behaviour is correct. The depstring in question was
> "!<app-text/hunspell-1.0", which means that you can't have
> <hunspell-1.0 and kdelibs installed on a system at the same time.
> Reason for this could e.g. be file collisions that got fixed in
> hunspell-1.0.
> 
> If the depstring was "!<app-text/hunspell-1.0 app-text/hunspell",
> (same as ">=app-text/hunspell-1.0", just retarded)  repoman would
> complain loudly.

1,$ s/hunspell/hspell/g

:)

To follow up in the use of a blocker - obviously blocking something
like kdelibs, a core part of a major package suite, against a utility
like hspell is less than ideal (to put it politely).  This was not the
case before - kdelibs and hspell could happily be installed on the same
system, just kdelibs wouldn't make use of hspell.  Adding the blocker
unnecessarily restricts the system, and was the wrong thing to do.

One point that illustrates this clearly, is that if kdelibs is blocked
by hspell, a corollary is that hspell should block kdelibs.  However
since hspell wasn't blocking kdelibs, you would fail to install kdelibs
until hspell was unmerged.  Unmerging hspell would allow kdelibs to
merge, then you could happily install hspell again and end up with a
confused dep tree.

Also, to my understanding, having configure automagically build support
for hspell if it's available on the system is not the way we're
supposed to handle such dependencies.

-- 
Kevin F. Quinn

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

Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Carsten Lohrke]

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

What have we learnt now, Jakub? Keep it in the bug report. ;)


Carsten

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

Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Jakub Moc]

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

Carsten Lohrke wrote:
> On Thursday 07 September 2006 16:42, Simon Stelling wrote:
>> "!<app-text/hunspell-1.0", which means that you can't have <hunspell-1.0
>> and kdelibs installed on a system at the same time.
> 
> This is clear to me. My point was, if there's a specific need to allow to not 
> to break arch keywording this way. I'd find it more foolproof and consistent, 
> if repoman would catch this and Portage would warn.

Warn about what exactly? About blocker that $arch doesn't have even
keyworded? I fail too see why this would be useful.



-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)


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