[pkg-go] Bug#818580: ITP: golang-github-prometheus-client-model -- data model artifacts for Prometheus

Dmitry Smirnov onlyjob at debian.org
Wed Mar 23 03:09:03 UTC 2016


On Wednesday, 23 March 2016 2:29:53 AM AEDT Martín Ferrari wrote:
> On 23/03/16 01:36, Dmitry Smirnov wrote:
> > There is no drama about that. You can drop duplicated file from your
> > -common package since upstream no longer ship it as part of
> > prometheus-common.
> Sorry, but you are completely off-base.
> 
> You have uploaded a package that is not used at all, because you did not
> check what you were uploading. It is your error, not mine.

I can not agree with that. Maybe it is not used any more but new package I 
uploaded ship file with correct name space. A file that your package should 
not be shipping.


> >> * You are packaging the whole upstream tree, which is supposed to
> >> provide bindings for many different languages, which you are not
> >> providing, nor the naming of the source package is reflecting.
> > 
> > You are welcome to work on that if you wish.
> 
> I have no intention on picking up the pieces of what you do, and I
> certainly don't appreciate your condescending tone.

You've suggested improvement and I'm certainly not in your way if you wish to 
improve things. Remember that you are the one who blames and speaks on behalf 
of the team so it is a bit strange that you already divided things to yours 
and mine.


> > I could but I've chosen to package dependency instead to preserve name
> > space. Why do you have problem with that?
> 
> Because:
> 
> * This is not a direct dependency of nomad. Have you checked the code?

Let's stay on topic please. From name space prospective it does not matter 
whether it is a legitimate dependency. If file in question is not a 
dependency of anything then why did you include it to your package?


> * This was already packaged and working correctly.

With incorrect namespace. How do you expect people to discover file if it is 
shipped by the wrong package? Why don't you take this opportunity to reduce 
your maintenance burden and remove "metrics.pb.go" from prometheus-common?


> * This is useless and clutters the debian archive.

Which can be said about many other packages. Golang is much about 
micropackaging and it is indeed unpleasant to have small barely used packages 
shipping just few files. However new package uses correct upstream source and 
name space so what is your problem? Even if package is not a direct 
dependency at this time it does not mean it is useless as it might be 
eventually used by something else.


> > I see... Thanks for explaining. However please note that Nomad-0.3.1
> > dropped some dependencies that I packaged in order to upload 0.3.0.
> 
> I don't know what you are talking about. In the git repo that you
> uploaded Nomad DOES NOT use prometheus directly, adding this as a
> dependency in nomad is a bug in the packaging.

Duly noted, thank you, I will check and correct as advised.


> > I hate to bring that argument but I'm not thrilled to be the most active
> > maintainer on the team.
> 
> I don't know why you mention this, care to elaborate?

Because one won't make any mistakes whatsoever by doing nothing.


> > I need to get things done within very limited time
> > that I often borrow heavily from my sleep.
> 
> I don't know why you need to do this in such a rush, but clearly the
> rush is affecting the quality of what is left for the team.

Disagreed. I did not ignore your feedback. I had a look and decided that 
there is nothing wrong with introducing another package. Will you stop 
blaming me already?


> > Could you please explain to which
> > of my actions specifically upset you? Packaging of minor dependency that
> > your package provides but really shouldn't?
> 
> See above.
 
Sorry, it is still unclear to me what the fuss is about...


> > You are really complaining about minor thing and FYI when I got your
> > email
> > I've already uploaded client-model package. I could not take immediate
> > action
> Sorry, but that is because you failed to do your job properly.

Nice. :(


> Otherwise, you would have never uploaded this.

Since I'm still not convinced that I shouldn't have uploaded, I very much 
doubt that.


> So you are happy about uploading something you don't need that disrupts
> the team work

Let's not exaggerate please. "Disrupts the team work"? Really?


> and clutters the archive?

Maybe just a little. At a time it looked like legitimate dependency.
Anyway for whatever reason you decided to ship "metrics.pb.go" in your 
package so I suppose it is not entirely worthless. Now it is shipped in its 
own proper package.


> You should have noticed that you did not need this package at all. If
> you had needed it, you should have talked with the team to find a proper
> solution.

I may have overlooked which package needs client_model so I may have done 
some extra work by packaging indirect dependency. I believe the proper 
solution is to ship client_model in its own package which is exactly what I 
did.

> >> It is already the third time I have to tell you that you are about to
> >> upload a duplicate package because you had not looked before.
> > 
> > Wow. I'm surprised. Could you please kindly refresh my memory about two
> > other incidents?
> 
> #798161 and #798158. September 2015

Wow, I'm "glad" you counting. But those were harmless mistakes originating 
from the fact that your packages don't follow naming policy so you can very 
well blame those incidents on yourself just as much as you hold me guilty for 
that. Otherwise it looks like poor attempt to discredit my competency.

You are worrying too much.

-- 
Best wishes,
 Dmitry Smirnov.

---

You can always count on Americans to do the right thing - after they've
tried everything else.
        -- Winston Churchill
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/attachments/20160323/df567ba0/attachment-0001.sig>


More information about the Pkg-go-maintainers mailing list