Fixing elasticsearch maintainer

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Fixing elasticsearch maintainer

Patrick Lauer
Ohey,

as you might have noticed I've just corrected the metadata.xml of all
elasticsearch-related packages.
For some strange reason I was listed there as maintainer, but since no
one wanted to listen to my ideas I guess I wasn't. So now last person
who touched it gets stuck with it.

Since proxy-maint refuses to be removed from packages (especially since
they were unconditionally added to all packages with a non-gentoo-dev
maintainer in metadata) they are the de facto maintainers, and overrule
everything else.
I've tried multiple strategies including removing them from metadata,
but ... see app-admin/elasticsearch, proxy-maint is like the toe fungus
that always comes back (e.g. commit
f0925c10834464e62ce7209f2afa7797b594d350 )

Sometimes it's almost absurdly funny, especially when you commit
RESTRICT="test" because tests fail reliably just to have that reverted.
(See dev-python/elasticsearch-py )

Bonus mention:
bbdc5412061adf598ed935697441a7d6b05f7614
     app-admin/logstash-bin: drop old

     Signed-off-by: Andrew Savchenko <[hidden email]>

That removed the versions I was using, so I better maintain the versions
I use in an overlay. Well ok then.

Since I, as maintainer, can't ... anything, well [CENSORED] this, now
they are your packages. Don't try to reassign or drop them: You've
demanded, insisted, to be maintainers ... wish granted.

So, err, well, is like ... wtf? I'm not sure how this all makes sense,
but it's Not My Problem now. Take care now, bye bye then.

Oh, and Erki Ferenc was in metadata too, he's been inactive but told me
that he wants to continue maintaining these packages in the near future.
If he asks I'd recommend adding him back.

Patrick

P.S. If this sounds a bit incoherent, well ... the whole situation is, I
have no idea what's going on or why I was in metadata ;)

Reply | Threaded
Open this post in threaded view
|

Re: Fixing elasticsearch maintainer

Mart Raudsepp-2
Ühel kenal päeval, K, 17.05.2017 kell 18:38, kirjutas Patrick Lauer:
> as you might have noticed I've just corrected the metadata.xml of
> all 
> elasticsearch-related packages.

Reassignments should probably be coupled with bug reassignments as
well. You clearly need that, with having well over a hundred open. To
whom you reassigned doesn't seem correct, though.


Mart

Reply | Threaded
Open this post in threaded view
|

Re: Fixing elasticsearch maintainer

Andrew Savchenko
In reply to this post by Patrick Lauer
On Wed, 17 May 2017 18:38:28 +0200 Patrick Lauer wrote:

> Ohey,
>
> as you might have noticed I've just corrected the metadata.xml of all
> elasticsearch-related packages.
> For some strange reason I was listed there as maintainer, but since no
> one wanted to listen to my ideas I guess I wasn't. So now last person
> who touched it gets stuck with it.
>
> Since proxy-maint refuses to be removed from packages (especially since
> they were unconditionally added to all packages with a non-gentoo-dev
> maintainer in metadata) they are the de facto maintainers, and overrule
> everything else.
> I've tried multiple strategies including removing them from metadata,
> but ... see app-admin/elasticsearch, proxy-maint is like the toe fungus
> that always comes back (e.g. commit
> f0925c10834464e62ce7209f2afa7797b594d350 )
>
> Sometimes it's almost absurdly funny, especially when you commit
> RESTRICT="test" because tests fail reliably just to have that reverted.
> (See dev-python/elasticsearch-py )
>
> Bonus mention:
> bbdc5412061adf598ed935697441a7d6b05f7614
>      app-admin/logstash-bin: drop old
>
>      Signed-off-by: Andrew Savchenko <[hidden email]>
Use the full quote please:

commit bbdc5412061adf598ed935697441a7d6b05f7614
Author: Tomas Mozes <[hidden email]>
Date:   Mon Feb 13 14:02:21 2017 +0100

    app-admin/logstash-bin: drop old

    Signed-off-by: Andrew Savchenko <[hidden email]>

I applied the commit made by the proxied maintainer as a part of
his pull request https://github.com/gentoo/gentoo/pull/3948
required to fix bug 609132. (By the way you ignored that bug.)

Since the proxied maintainer doesn't have the direct access to the
tree, I facilitated him and I see nothing wrong with this.

> That removed the versions I was using, so I better maintain the versions
> I use in an overlay. Well ok then.

Discuss this with your co-maintainers. I see nothing wrong in
removing old packages from the tree if this doesn't break any deps
and don't result in keywords being dropped.

> Since I, as maintainer, can't ... anything, well [CENSORED] this, now
> they are your packages. Don't try to reassign or drop them: You've
> demanded, insisted, to be maintainers ... wish granted.

Commit from any listed maintainer either direct or proxied is OK.

Best regards,
Andrew Savchenko

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fixing elasticsearch maintainer

Alec Warner-2
In reply to this post by Patrick Lauer


On Wed, May 17, 2017 at 12:38 PM, Patrick Lauer <[hidden email]> wrote:
Ohey,

as you might have noticed I've just corrected the metadata.xml of all elasticsearch-related packages.
For some strange reason I was listed there as maintainer, but since no one wanted to listen to my ideas I guess I wasn't. So now last person who touched it gets stuck with it.

Since proxy-maint refuses to be removed from packages (especially since they were unconditionally added to all packages with a non-gentoo-dev maintainer in metadata) they are the de facto maintainers, and overrule everything else.
I've tried multiple strategies including removing them from metadata, but ... see app-admin/elasticsearch, proxy-maint is like the toe fungus that always comes back (e.g. commit f0925c10834464e62ce7209f2afa7797b594d350 )

Sometimes it's almost absurdly funny, especially when you commit RESTRICT="test" because tests fail reliably just to have that reverted.
(See dev-python/elasticsearch-py )

Bonus mention:
bbdc5412061adf598ed935697441a7d6b05f7614
    app-admin/logstash-bin: drop old

    Signed-off-by: Andrew Savchenko <[hidden email]>

That removed the versions I was using, so I better maintain the versions I use in an overlay. Well ok then.

I don't quite get this gripe. Gentoo is a rolling distro. Versions of things "you are using" get removed and replaced with newer versions all the time. Why is this a big deal now?

-A
 

Since I, as maintainer, can't ... anything, well [CENSORED] this, now they are your packages. Don't try to reassign or drop them: You've demanded, insisted, to be maintainers ... wish granted.

So, err, well, is like ... wtf? I'm not sure how this all makes sense, but it's Not My Problem now. Take care now, bye bye then.

Oh, and Erki Ferenc was in metadata too, he's been inactive but told me that he wants to continue maintaining these packages in the near future. If he asks I'd recommend adding him back.

Patrick

P.S. If this sounds a bit incoherent, well ... the whole situation is, I have no idea what's going on or why I was in metadata ;)


Reply | Threaded
Open this post in threaded view
|

Re: Fixing elasticsearch maintainer

Michał Górny-5
In reply to this post by Patrick Lauer
On Wed, 2017-05-17 at 18:38 +0200, Patrick Lauer wrote:
> Bonus mention:
> bbdc5412061adf598ed935697441a7d6b05f7614
>      app-admin/logstash-bin: drop old
>
>      Signed-off-by: Andrew Savchenko <[hidden email]>
>
> That removed the versions I was using, so I better maintain the versions
> I use in an overlay. Well ok then.
>

I'm sorry that the situation turned out badly for you. However, I would
like to point out that problems like this are rarely unilateral,
and usually involve issues on both ends.

I'd like to ask you a very simple question: what did you do to ensure
that the versions you are using are not accidentally removed?

I could have a few ideas, such as:

a. slotting the package to indicate that multiple versions might be
meaningful,

b. opening a bug requesting the old version to be kept,

c. leaving a comment in the ebuild (unlikely to help but still),

d. just mailing proxy-maint@ to let us know of the issue.

However, as far as I'm aware none of this happened. Note that I might
have missed the mail, or it might have been sent before I joined --
correct me if that is the case.

As Alec pointed out, it is a normal procedure in Gentoo to remove old
versions of software if there is no explicit indication that they need
to be kept. Therefore, I don't see anything wrong with the proxied
maintainer wishing to clean the old versions up and/or not requesting
your explicit permission for that. If you needed the old versions, you
should have made that clear.

I should also point out that the steps you've taken (and listed in this
mail) are not really relevant. They make you look like a sloppy
maintainer, and a bad Gentoo developer at the best -- and I doubt anyone
would connect removing proxy-maint team with a necessity of keeping
an old version.

--
Best regards,
Michał Górny

signature.asc (1007 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fixing elasticsearch maintainer

Patrick Lauer
In reply to this post by Alec Warner-2
On 05/18/2017 07:17 PM, Alec Warner wrote:

>
>
> On Wed, May 17, 2017 at 12:38 PM, Patrick Lauer <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Ohey,
>
>     as you might have noticed I've just corrected the metadata.xml of
>     all elasticsearch-related packages.
>     For some strange reason I was listed there as maintainer, but since
>     no one wanted to listen to my ideas I guess I wasn't. So now last
>     person who touched it gets stuck with it.
>
>     Since proxy-maint refuses to be removed from packages (especially
>     since they were unconditionally added to all packages with a
>     non-gentoo-dev maintainer in metadata) they are the de facto
>     maintainers, and overrule everything else.
>     I've tried multiple strategies including removing them from
>     metadata, but ... see app-admin/elasticsearch, proxy-maint is like
>     the toe fungus that always comes back (e.g. commit
>     f0925c10834464e62ce7209f2afa7797b594d350 )
>
>     Sometimes it's almost absurdly funny, especially when you commit
>     RESTRICT="test" because tests fail reliably just to have that reverted.
>     (See dev-python/elasticsearch-py )
>
>     Bonus mention:
>     bbdc5412061adf598ed935697441a7d6b05f7614
>         app-admin/logstash-bin: drop old
>
>         Signed-off-by: Andrew Savchenko <[hidden email]
>     <mailto:[hidden email]>>
>
>     That removed the versions I was using, so I better maintain the
>     versions I use in an overlay. Well ok then.
>
>
> I don't quite get this gripe. Gentoo is a rolling distro. Versions of
> things "you are using" get removed and replaced with newer versions all
> the time. Why is this a big deal now?
>

I "was" package maintainer and relied on these versions.

If I as maintainer have no control over such things, why am I
maintainer, and why do I need an overlay?


... that sounds exquisitely confused, I have no idea why this discussion
even exists.


Reply | Threaded
Open this post in threaded view
|

Re: Fixing elasticsearch maintainer

Patrick Lauer
In reply to this post by Michał Górny-5
On 05/19/2017 03:10 PM, Michał Górny wrote:

> On Wed, 2017-05-17 at 18:38 +0200, Patrick Lauer wrote:
>> Bonus mention:
>> bbdc5412061adf598ed935697441a7d6b05f7614
>>      app-admin/logstash-bin: drop old
>>
>>      Signed-off-by: Andrew Savchenko <[hidden email]>
>>
>> That removed the versions I was using, so I better maintain the versions
>> I use in an overlay. Well ok then.
>>
>
> I'm sorry that the situation turned out badly for you. However, I would
> like to point out that problems like this are rarely unilateral,
> and usually involve issues on both ends.
>
> I'd like to ask you a very simple question: what did you do to ensure
> that the versions you are using are not accidentally removed?
>
> I could have a few ideas, such as:
>
> a. slotting the package to indicate that multiple versions might be
> meaningful,
>
> b. opening a bug requesting the old version to be kept,
>
> c. leaving a comment in the ebuild (unlikely to help but still),
>
> d. just mailing proxy-maint@ to let us know of the issue.


I tried removing proxy-maint from metadata after multiple discussions
failed. Extra happiness towards monsieurp "but the GH PR is over 3 days
old, I have to commit" and gokturk "Yes I understand. I commit anyway"

This has been an uphill struggle since about October, around New Year I
stopped actively caring, and since these two commits:

12c3eacda7c4d23686eaf10eab21d810cc95ea49
f42d6679c038c3efcc257d38547267d01823aea9

I see no way to fix this situation that doesn't involve a review board
in front of all proxy-maint commits. Because we discussed this in IRC,
and still ... "but is open bug"

> However, as far as I'm aware none of this happened. Note that I might
> have missed the mail, or it might have been sent before I joined --
> correct me if that is the case.

There were multiple discussions in IRC, which the involved people
usually forgot within about 20 minutes and then resumed doing stuff.

I tried removing proxy-maint from metadata, which was reverted (sooo how
does one *not* have constant interference?)

> As Alec pointed out, it is a normal procedure in Gentoo to remove old
> versions of software if there is no explicit indication that they need
> to be kept. Therefore, I don't see anything wrong with the proxied
> maintainer wishing to clean the old versions up and/or not requesting
> your explicit permission for that. If you needed the old versions, you
> should have made that clear.

One could ask, maybe. I guess I can (mis)understand this to mean that I
can do with packages with you in metadata what I want because ... err...
shiny!

> I should also point out that the steps you've taken (and listed in this
> mail) are not really relevant. They make you look like a sloppy
> maintainer, and a bad Gentoo developer at the best -- and I doubt anyone
> would connect removing proxy-maint team with a necessity of keeping
> an old version.

The cooperation that I had with ferki was pretty good (mostly because we
sat next to each other in the office). The contributions from Tomas were
on average pretty ok, just needed some minor cleanups here and there.

The blind "but PR is open for 3 days" commits from proxy-maint made it
extremely hard to review what changed in a timely manner, so that I
basically didn't want to care for this pile of stupid for the last,
ahem, 6 months or so. Especially since whenever I wanted to review
things some joker made some new changes which made me go "eh whut how
you? banana banana!" so I pushed reviewing a week into the future and ...

I have no idea how I could have fixed this without the QA+Comrel
banhammer combo, which is a totally insane "fix" to a problem that
shouldn't even exist. But I see no other options how to make people
understand that "No means no".

Is this the new normal?

Reply | Threaded
Open this post in threaded view
|

Re: Fixing elasticsearch maintainer

Kristian Fiskerstrand-2
On 05/19/2017 06:50 PM, Patrick Lauer wrote:
>
> I have no idea how I could have fixed this without the QA+Comrel
> banhammer combo, which is a totally insane "fix" to a problem that
> shouldn't even exist. But I see no other options how to make people
> understand that "No means no".
>
> Is this the new normal?

As far as I can see you were never the maintainer of at least
app-misc/elasticsearch (I didn't check other possibly related packages),
it was first proxied maintained through chainsaw, then later through
proxy-maintainers herd (since 2015) which was converted to the project
once herds were deprecated. I don't notice you showing up in the git log
(with cvs history grafted) until 2016 in a commit that removed proxy
maint seemingly without corrabolation, and as such got reverted.

I'm really struggling to understand what you're trying to say here, if
it is "can I take any package I want without consulting with existing
maintainers", then yes, its the normal (its not new)

--
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fixing elasticsearch maintainer

Kent Fredric-2
On Fri, 19 May 2017 19:27:15 +0200
Kristian Fiskerstrand <[hidden email]> wrote:

> As far as I can see you were never the maintainer of at least
> app-misc/elasticsearch (I didn't check other possibly related
> packages), it was first proxied maintained through chainsaw, then
> later through proxy-maintainers herd (since 2015) which was converted
> to the project once herds were deprecated. I don't notice you showing
> up in the git log (with cvs history grafted) until 2016 in a commit
> that removed proxy maint seemingly without corrabolation, and as such
> got reverted.

It probably helps better understand what's going on if you pay careful
attention, not to the name "Patrick" but to Ferenc Erki.

Given they're working side-by-side and so there's room for Patrick to
be operating in the capacity indicated by Ferenc without it necessarily
being visible in the history ( leading to confusion )

Then a few small, but important changes become apparent:

40258029bda18564b0d3e21f0644ffcd40fd4974 - 2015-06-12 ( Gentoo history )

Chainsaw adds Ferenc as a maintainer, where Chainsaw opts to be the
proxy.

20c1bcbaa6346c6e4643f50b904deaa8e9c06af2 - 2015-12-16

Idella4 adds proxy-maint with Chainsaws ack

f279fce9617b2e3ddbf3ef99df8f65629617e959 - 2015-12-16

Idella4 removes Chainsaw, assumingly part of the previous change,
moving the proxy from Chainsaw to Proxy-Maint project.

ef2b2458815ba4e4694e0d5f3bbce239505ffbc8 - 2015-12-20

Idella4's last commit on this package.

3d70356565d3213c370e1f64a85b55c3ded259f5 - 2016-01-06

Patricks first direct commit to this package.

<<a dozen version bumps by patrick here>>

e6175815b5792f09acd90627af5fe23f616ad245 - 2016-09-02

Patrick adds himself and Tomas, and removes Proxy Maint.

^^^

This last commit is, as I understand, where most this conflict comes
from.

Because to an untrained eye, in isolation looks like an antagonistic
dev just going in and changing stuff they have no right to change.

But it makes more sense to realise who the primary proxied maintainer
was at this time, who can be considered "owning" the package, and has
the right to dictate which gentoo dev's maintain their packages for
them.

And it certainly makes sense given the working relationship and the
existing commit history of contribution, that Patrick is already
functioning as a primary maintainer at this point, working under the
assumption that he just does what Ferenc wants.

Proxy-Maint are the unwanted element in this equation, but it seems to
me proxy-maint over-reacted based on not having the full picture, and
so both sides have some miscommunication and misunderstanding about
what the other is doing.

Everything *after* that commit looks like after-the-fact
edit-wars+confusion.


attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fixing elasticsearch maintainer

Kristian Fiskerstrand-2
On 05/20/2017 12:43 AM, Kent Fredric wrote:

> ef2b2458815ba4e4694e0d5f3bbce239505ffbc8 - 2015-12-20
>
> Idella4's last commit on this package.
>
> 3d70356565d3213c370e1f64a85b55c3ded259f5 - 2016-01-06
>
> Patricks first direct commit to this package.
>
> <<a dozen version bumps by patrick here>>
>
> e6175815b5792f09acd90627af5fe23f616ad245 - 2016-09-02
>
> Patrick adds himself and Tomas, and removes Proxy Maint.
>
> ^^^
>
> This last commit is, as I understand, where most this conflict comes
> from.
fwiw, Thomas explicitly requested proxy-maint to stay on as maintainer
at this point. "Given this information, I'd
like to return the proxy maintainers team to the metadata so I'm able to
open PR via github and manage changes even without Patrick."


>
> But it makes more sense to realise who the primary proxied maintainer
> was at this time, who can be considered "owning" the package, and has
> the right to dictate which gentoo dev's maintain their packages for
> them.

At some point they likely should establish a project and discuss things
internally before making changes. But on a post-hoc-basis the
determination will need to be based on documented history.

--
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fixing elasticsearch maintainer

Tomas Mozes-2
In reply to this post by Patrick Lauer


On Wed, May 17, 2017 at 6:38 PM, Patrick Lauer <[hidden email]> wrote:
For some strange reason I was listed there as maintainer, but since no one wanted to listen to my ideas I guess I wasn't. So now last person who touched it gets stuck with it.


For elasticsearch, you added yourself to the maintainers, so why are you surprised to be there (e6175815b5792f09acd90627af5fe23f616ad245)?

You also added yourself to other packages, for example elasticsearch-cutor (bd21ed1ef20cb2d27a87a4dadf780565236a72cd) without asking the maintainer (me at that time).

And where exactly have you expressed your ideas?

 

Since proxy-maint refuses to be removed from packages (especially since they were unconditionally added to all packages with a non-gentoo-dev maintainer in metadata) they are the de facto maintainers, and overrule everything else.
I've tried multiple strategies including removing them from metadata, but ... see app-admin/elasticsearch, proxy-maint is like the toe fungus that always comes back (e.g. commit f0925c10834464e62ce7209f2afa7797b594d350 )


Why did you add me as the maintainer of elasticsearch without asking and then removing proxy-maint so I cannot make any changes to elasticsearch at all? If you want to make all the changes, then I don't need to be there and I can just open regular bug reports and you merge them.

 

Sometimes it's almost absurdly funny, especially when you commit RESTRICT="test" because tests fail reliably just to have that reverted.
(See dev-python/elasticsearch-py )

Regarding RESTRICT="test", I was the one to revert your change because I thought it's a mistake as the tests passed for me. As soon as we discussed this via irc that it only happens in chroot, it got back. Now a few days ago @mrueg accidentally removed the restriction but after mailing him he reverted his change so it's as you made it.

 

Bonus mention:
bbdc5412061adf598ed935697441a7d6b05f7614
    app-admin/logstash-bin: drop old

    Signed-off-by: Andrew Savchenko <[hidden email]>

That removed the versions I was using, so I better maintain the versions I use in an overlay. Well ok then.


Logstash is yet another package where you made yourself a maintainer without asking the maintainer (again, it was me). I don't remember you ever wanting to keep the old version of logstash in the repo. Plus, you don't need to update and you can mask the update. If you really want to use and old version (we already had multiple version of 5.x in the tree by that time), you can keep in your overlay.

Reply | Threaded
Open this post in threaded view
|

Re: Fixing elasticsearch maintainer

Tomas Mozes-2
In reply to this post by Patrick Lauer


On Fri, May 19, 2017 at 6:38 PM, Patrick Lauer <[hidden email]> wrote:

I "was" package maintainer and relied on these versions.

If I as maintainer have no control over such things, why am I maintainer, and why do I need an overlay?


... that sounds exquisitely confused, I have no idea why this discussion even exists.



The elastic stack is moving pretty fast. As you might have noticed, several security issues were fixed during the development, but still we kept really old versions in portage. I'm fine with keeping older branches if they are maintained, but we kept unmaintained branches (for example we had almost 20 versions of elasticseach).
Reply | Threaded
Open this post in threaded view
|

Re: Fixing elasticsearch maintainer

Tomas Mozes-2
In reply to this post by Patrick Lauer


On Fri, May 19, 2017 at 6:50 PM, Patrick Lauer <[hidden email]> wrote:
I tried removing proxy-maint from metadata after multiple discussions failed. Extra happiness towards monsieurp "but the GH PR is over 3 days old, I have to commit" and gokturk "Yes I understand. I commit anyway"

This has been an uphill struggle since about October, around New Year I stopped actively caring, and since these two commits:

12c3eacda7c4d23686eaf10eab21d810cc95ea49
f42d6679c038c3efcc257d38547267d01823aea9

I see no way to fix this situation that doesn't involve a review board in front of all proxy-maint commits. Because we discussed this in IRC, and still ... "but is open bug"

However, as far as I'm aware none of this happened. Note that I might
have missed the mail, or it might have been sent before I joined --
correct me if that is the case.

There were multiple discussions in IRC, which the involved people usually forgot within about 20 minutes and then resumed doing stuff.

I tried removing proxy-maint from metadata, which was reverted (sooo how does one *not* have constant interference?)

As Alec pointed out, it is a normal procedure in Gentoo to remove old
versions of software if there is no explicit indication that they need
to be kept. Therefore, I don't see anything wrong with the proxied
maintainer wishing to clean the old versions up and/or not requesting
your explicit permission for that. If you needed the old versions, you
should have made that clear.

One could ask, maybe. I guess I can (mis)understand this to mean that I can do with packages with you in metadata what I want because ... err... shiny!

I should also point out that the steps you've taken (and listed in this
mail) are not really relevant. They make you look like a sloppy
maintainer, and a bad Gentoo developer at the best -- and I doubt anyone
would connect removing proxy-maint team with a necessity of keeping
an old version.

The cooperation that I had with ferki was pretty good (mostly because we sat next to each other in the office). The contributions from Tomas were on average pretty ok, just needed some minor cleanups here and there.

The blind "but PR is open for 3 days" commits from proxy-maint made it extremely hard to review what changed in a timely manner, so that I basically didn't want to care for this pile of stupid for the last, ahem, 6 months or so. Especially since whenever I wanted to review things some joker made some new changes which made me go "eh whut how you? banana banana!" so I pushed reviewing a week into the future and ...

I have no idea how I could have fixed this without the QA+Comrel banhammer combo, which is a totally insane "fix" to a problem that shouldn't even exist. But I see no other options how to make people understand that "No means no".

Is this the new normal?



Everybody makes mistakes, but let's look from another perspective. Elasticsearch 5.0 got released - a new major version. You did the bump, but it didn't work (it was clearly pushed to the repo untested as openrc/systemd version both failed:
https://bugs.gentoo.org/show_bug.cgi?id=598732
https://bugs.gentoo.org/show_bug.cgi?id=597454
Why didn't you fix it yourself?

Why did you commit a broken ebuild to the repo and never fixed it after yourself? These bugs were open for weeks and months, not days...

Reply | Threaded
Open this post in threaded view
|

Re: Fixing elasticsearch maintainer

Michał Górny-5
On sob, 2017-05-20 at 21:57 +0200, Tomas Mozes wrote:

> On Fri, May 19, 2017 at 6:50 PM, Patrick Lauer <[hidden email]> wrote:
>
> > I tried removing proxy-maint from metadata after multiple discussions
> > failed. Extra happiness towards monsieurp "but the GH PR is over 3 days
> > old, I have to commit" and gokturk "Yes I understand. I commit anyway"
> >
> > This has been an uphill struggle since about October, around New Year I
> > stopped actively caring, and since these two commits:
> >
> > 12c3eacda7c4d23686eaf10eab21d810cc95ea49
> > f42d6679c038c3efcc257d38547267d01823aea9
> >
> > I see no way to fix this situation that doesn't involve a review board in
> > front of all proxy-maint commits. Because we discussed this in IRC, and
> > still ... "but is open bug"
> >
> > However, as far as I'm aware none of this happened. Note that I might
> > > have missed the mail, or it might have been sent before I joined --
> > > correct me if that is the case.
> > >
> >
> > There were multiple discussions in IRC, which the involved people usually
> > forgot within about 20 minutes and then resumed doing stuff.
> >
> > I tried removing proxy-maint from metadata, which was reverted (sooo how
> > does one *not* have constant interference?)
> >
> > As Alec pointed out, it is a normal procedure in Gentoo to remove old
> > > versions of software if there is no explicit indication that they need
> > > to be kept. Therefore, I don't see anything wrong with the proxied
> > > maintainer wishing to clean the old versions up and/or not requesting
> > > your explicit permission for that. If you needed the old versions, you
> > > should have made that clear.
> > >
> >
> > One could ask, maybe. I guess I can (mis)understand this to mean that I
> > can do with packages with you in metadata what I want because ... err...
> > shiny!
> >
> > I should also point out that the steps you've taken (and listed in this
> > > mail) are not really relevant. They make you look like a sloppy
> > > maintainer, and a bad Gentoo developer at the best -- and I doubt anyone
> > > would connect removing proxy-maint team with a necessity of keeping
> > > an old version.
> > >
> >
> > The cooperation that I had with ferki was pretty good (mostly because we
> > sat next to each other in the office). The contributions from Tomas were on
> > average pretty ok, just needed some minor cleanups here and there.
> >
> > The blind "but PR is open for 3 days" commits from proxy-maint made it
> > extremely hard to review what changed in a timely manner, so that I
> > basically didn't want to care for this pile of stupid for the last, ahem, 6
> > months or so. Especially since whenever I wanted to review things some
> > joker made some new changes which made me go "eh whut how you? banana
> > banana!" so I pushed reviewing a week into the future and ...
> >
> > I have no idea how I could have fixed this without the QA+Comrel banhammer
> > combo, which is a totally insane "fix" to a problem that shouldn't even
> > exist. But I see no other options how to make people understand that "No
> > means no".
> >
> > Is this the new normal?
> >
> >
>
> Everybody makes mistakes, but let's look from another perspective.
> Elasticsearch 5.0 got released - a new major version. You did the bump, but
> it didn't work (it was clearly pushed to the repo untested as
> openrc/systemd version both failed:
> https://bugs.gentoo.org/show_bug.cgi?id=598732
> https://bugs.gentoo.org/show_bug.cgi?id=597454
> Why didn't you fix it yourself?
>
> Same for logstash:
> https://bugs.gentoo.org/show_bug.cgi?id=597452
> https://bugs.gentoo.org/show_bug.cgi?id=598422
> Why did you commit a broken ebuild to the repo and never fixed it after
> yourself? These bugs were open for weeks and months, not days...
Tomas, please don't go this road. We all know Patrick does a shitty job
as Gentoo developer, both technically and socially but you do not have
to try to match him.

--
Best regards,
Michał Górny

signature.asc (1007 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fixing elasticsearch maintainer

Kristian Fiskerstrand-2
On 05/20/2017 10:46 PM, Michał Górny wrote:
> Tomas, please don't go this road. We all know Patrick does a shitty job
> as Gentoo developer, both technically and socially but you do not have
> to try to match him.

Was this comment really necessary?

--
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fixing elasticsearch maintainer

Michał Górny-5
On sob, 2017-05-20 at 22:51 +0200, Kristian Fiskerstrand wrote:
> On 05/20/2017 10:46 PM, Michał Górny wrote:
> > Tomas, please don't go this road. We all know Patrick does a shitty job
> > as Gentoo developer, both technically and socially but you do not have
> > to try to match him.
>
> Was this comment really necessary?
>

Yes, it was. It's enough that Patrick does public lashing here, I don't
want Tomas to do the counter-lashing. Show's over, move along, etc.

--
Best regards,
Michał Górny

signature.asc (1007 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fixing elasticsearch maintainer

Kristian Fiskerstrand-2
On 05/20/2017 11:06 PM, Michał Górny wrote:

> On sob, 2017-05-20 at 22:51 +0200, Kristian Fiskerstrand wrote:
>> On 05/20/2017 10:46 PM, Michał Górny wrote:
>>> Tomas, please don't go this road. We all know Patrick does a shitty job
>>> as Gentoo developer, both technically and socially but you do not have
>>> to try to match him.
>>
>> Was this comment really necessary?
>>
>
> Yes, it was. It's enough that Patrick does public lashing here, I don't
> want Tomas to do the counter-lashing. Show's over, move along, etc.
>
I'm more concerned about the tone of the message, we really should
strive to be more collegial in our commenting in official Gentoo channels.

In this case it seems to be a matter of communication between various
maintainers of a package that likely should belong in private before
being aired on a public mailing list. Given the number of maintainers,
I'm wondering if it shouldn't be a project handling it to begin with,
but certain parts of the history looks odd from the outside.

--
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fixing elasticsearch maintainer

Andreas K. Huettel
In reply to this post by Michał Górny-5
>
> Tomas, please don't go this road. We all know Patrick does...

Oh please cut it.

--
Andreas K. Hüttel
[hidden email]
Gentoo Linux developer (council, perl, libreoffice)

signature.asc (1000 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fixing elasticsearch maintainer

Sam Jorna (wraeth)
In reply to this post by Patrick Lauer
On 18/05/17 02:38, Patrick Lauer wrote:
> Since proxy-maint refuses to be removed from packages (especially since they
> were unconditionally added to all packages with a non-gentoo-dev maintainer in
> metadata) they are the de facto maintainers, and overrule everything else.

Just to clarify, the Proxy Maintainers project is not required to be
added to all packages maintained by non-Gentoo maintainers. If a Gentoo
developer is willing to work with and proxy commits for maintainer(s)
without commit access, Proxy Maintainers are happy to be removed. There
are several metadata.xml's in the tree with examples, including a few
for which you are one of the maintainers.

--
Sam Jorna (wraeth)
GnuPG Key: D6180C26

signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fixing elasticsearch maintainer

Patrick Lauer
In reply to this post by Kristian Fiskerstrand-2
On 05/20/2017 10:51 PM, Kristian Fiskerstrand wrote:
> On 05/20/2017 10:46 PM, Michał Górny wrote:
>> Tomas, please don't go this road. We all know Patrick does a shitty job
>> as Gentoo developer, both technically and socially but you do not have
>> to try to match him.
>
> Was this comment really necessary?
>
Yes it was, because now I point out how mgorny fails at stuff, then we
throw ~30 mails around, someone invokes ComRel, and after a week the
whole thing dies down.

Then in a month or so the same cycle begins.


... Now that we know how it goes we can skip the rest and just glare at
Michal for not being a reasonable person once more, and just continue
doing useful stuff.

12