Bug 199333 - graphics/pdf2svg UNBREAK - add MASTER_SITES
Summary: graphics/pdf2svg UNBREAK - add MASTER_SITES
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-09 20:23 UTC by Chris Hutchinson
Modified: 2015-04-11 19:48 UTC (History)
3 users (show)

See Also:
bugzilla: maintainer-feedback? (martin.dieringer)


Attachments
svn diff to fix graphics/pdf2svg (992 bytes, patch)
2015-04-09 20:23 UTC, Chris Hutchinson
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Hutchinson 2015-04-09 20:23:44 UTC
Created attachment 155385 [details]
svn diff to fix graphics/pdf2svg

I see this port is marked for deletion. I use the
port, and hgave the source. So why not host it, along
with all the other ports I already host.

Following is a session that shows that the source is available, again:

# make fetch
===>   pdf2svg-0.2.2_3 depends on file: /usr/local/sbin/pkg - found
=> pdf2svg-0.2.2.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch http://BSDforge.com/projects/source/graphics/pdf2svg/pdf2svg-0.2.2.tar.gz
pdf2svg-0.2.2.tar.gz                          100% of   82 kB  288 MBps 00m00s
===> Fetching all distfiles required by pdf2svg-0.2.2_3 for building

# make extract
===>   pdf2svg-0.2.2_3 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by pdf2svg-0.2.2_3 for building
===>  Extracting for pdf2svg-0.2.2_3
=> SHA256 Checksum OK for pdf2svg-0.2.2.tar.gz.

While here, since I'm hosting the source, why not
add myself as MAINTAINER?

That's it!

Thanks!

--Chris
Comment 1 martin.dieringer 2015-04-10 11:11:44 UTC
Yes, why not? Yes, please!
Comment 2 John Marino freebsd_committer freebsd_triage 2015-04-11 11:26:10 UTC
I disagree. 

It's still hosted at city in the sky:
http://www.cityinthesky.co.uk/wp-content/uploads/2013/10/pdf2svg-0.2.2.tar.gz

Martin, are you still giving up maintainership?
Comment 3 commit-hook freebsd_committer freebsd_triage 2015-04-11 11:30:43 UTC
A commit references this bug:

Author: marino
Date: Sat Apr 11 11:30:09 UTC 2015
New revision: 383788
URL: https://svnweb.freebsd.org/changeset/ports/383788

Log:
  graphics/pdf2svg: Fix MASTER_SITES to unbreak (same site)

  The site was only reorganized, the distfile is still hosted on the
  same server.  Referenced PR was not used.

  PR:	199333

Changes:
  head/graphics/pdf2svg/Makefile
Comment 4 martin.dieringer 2015-04-11 11:37:34 UTC
Btw., it's also on github (it was all the time): https://github.com/db9052/pdf2svg/releases

And yes if someone else wants to maintain it, why not?
Comment 5 John Marino freebsd_committer freebsd_triage 2015-04-11 11:59:15 UTC
why not:

1) because the premise of the request was he was hosting the distfile which is not the case. 

2) Chris has picking up so many ports (including ports that require code fixing) I'm personally starting to doubt he can maintain them all.

It was also a boilerplate request, I just scanned about saw about 10 other nearly identical PRs.  I am skeptical that he actually uses all the ports he says he does.  This one is pretty interesting but others are pretty obscure.

There's sort of a tug-of-war going on with Chris.  Obviously many ports are worth saving, but there are many more ports that are very old and apparently unused and people just want to die a natural death and Chris has been saving those too (I think just for the sake of saving them, e.g. "who knows, somebody might need this later)".

anyway, the main answer to your question is #1, the rest is just background.  I assumed you wanted to maintain it at first for a reason.
Comment 6 martin.dieringer 2015-04-11 12:06:01 UTC
If you want me to stay the maintainer, I will. But I don't know if I'm a good one as I didn't even got notice of the "BROKEN" state ...
Comment 7 John Marino freebsd_committer freebsd_triage 2015-04-11 12:09:16 UTC
well, it's not what "I" want, but you.  However, I would prefer to close the PR as done meaning you remain as maintainer.

I think you would have gotten a notice if the port had been marked for deprecation but even then only 1-2 times a month.

Basically a big sweep happened and about 300+ ports were marked all at once.  Nobody got notified.
Comment 8 martin.dieringer 2015-04-11 12:13:54 UTC
Then close it. I found the notification ;)
Comment 9 John Marino freebsd_committer freebsd_triage 2015-04-11 12:15:33 UTC
Oh great!  I just assumed nobody was notified.  Thanks!
Comment 10 Chris Hutchinson 2015-04-11 17:54:08 UTC
(In reply to John Marino from comment #5)
> why not:
> 
> 1) because the premise of the request was he was hosting the distfile which
> is not the case. 
> 
> 2) Chris has picking up so many ports (including ports that require code
> fixing) I'm personally starting to doubt he can maintain them all.
I'm not requesting/maintaing more than I can manage.
Should I find my list growing beyond my ability to give them the
attention they deserve/require, I can/will give them back to ports@ :)
> 
> It was also a boilerplate request, I just scanned about saw about 10 other
> nearly identical PRs.  I am skeptical that he actually uses all the ports he
> says he does.  This one is pretty interesting but others are pretty obscure.
In going through the list, I found ports that while *seemingly*
somewhat obscure, appeared to have value. To *me* anyway.
> 
> There's sort of a tug-of-war going on with Chris.  Obviously many ports are
> worth saving, but there are many more ports that are very old and apparently
> unused and people just want to die a natural death and Chris has been saving
> those too (I think just for the sake of saving them, e.g. "who knows,
> somebody might need this later)".
Downloads from my site (thus far) indicate [a] reasonable amount
usage.
> 
> anyway, the main answer to your question is #1, the rest is just background.
> I assumed you wanted to maintain it at first for a reason.

I have no desire to take a port from anyone that is a Maintainer. But
after a bit of investigation, those that I substituted myself for,
appeared to have been using distcache for some time -- often for more than
a year.
As to "boilerplate"; I had only a small window to work from the day I
investigated those ports, so recycled much of the dialog, in an effort
to do the necessary preliminary work, for them (save time).

All the best.

--Chris
Comment 11 John Marino freebsd_committer freebsd_triage 2015-04-11 18:03:24 UTC
(In reply to Chris Hutchinson from comment #10)
> Should I find my list growing beyond my ability to give them the
> attention they deserve/require, I can/will give them back to ports@ :)

Unfortunately, this is the exact scenario that I fear.  People want port X to die because they are sick of it.  Then if you claim it, we pretty much have to assign it to you, but if then release it later on, it's going to hang around until it's finally deprecated again.  In this scenario, people would rather it just die instead of coming back in unmaintained.  I know you are coming from it with the Point of View that you are doing everyone a favor, but hopefully now you can see it's not always viewed as a positive thing.  This is why I have been recommending that you limit this to ports you actually use.


> In going through the list, I found ports that while *seemingly*
> somewhat obscure, appeared to have value. To *me* anyway.


I interpret the above as a confirmation that I was right -- that you don't actually use the port, but somehow it appears valuable and worth saving anyway.  This is the situation I was warning against.  We have all the ports in version control, so any can be revived if somebody actually wants it.

> I have no desire to take a port from anyone that is a Maintainer. But
> after a bit of investigation, those that I substituted myself for,
> appeared to have been using distcache for some time -- often for more than
> a year.


Well, please that the file wasn't just moved on the same server (as in this case) or if the exact same file is readily available somewhere else.  The length it was pulling from distcache really doesn't indicate anything -- only that nobody noticed.

Thanks
Comment 12 Chris Hutchinson 2015-04-11 19:09:03 UTC
(In reply to John Marino from comment #11)
> (In reply to Chris Hutchinson from comment #10)
> > Should I find my list growing beyond my ability to give them the
> > attention they deserve/require, I can/will give them back to ports@ :)
> 
> Unfortunately, this is the exact scenario that I fear.  People want port X
> to die because they are sick of it.  Then if you claim it, we pretty much
> have to assign it to you, but if then release it later on, it's going to
> hang around until it's finally deprecated again.
Speaking for *this* port. I had looked for *quite* some time for a port
that did *exactly* what this port did. I don't know if that constitutes/
defines "obscure". But I can't tell you how happy I was to have discovered
this port.

If you really want a port to die. IMHO it might be more effective to
issue an EOL/DEPRECIATION  warning:
Heads up, this port is slated for removal on XXXX-XX-XX because it
doesn't appear to be of any significant value to anyone.

You could then easily determine it's *actual* value based on the
response to the message.

> In this scenario, people
> would rather it just die instead of coming back in unmaintained.  I know you
> are coming from it with the Point of View that you are doing everyone a
> favor, but hopefully now you can see it's not always viewed as a positive
> thing.  This is why I have been recommending that you limit this to ports
> you actually use.
See just above.

> 
> 
> > In going through the list, I found ports that while *seemingly*
> > somewhat obscure, appeared to have value. To *me* anyway.
> 
> 
> I interpret the above as a confirmation that I was right -- that you don't
> actually use the port, but somehow it appears valuable and worth saving
> anyway.  This is the situation I was warning against.  We have all the ports
> in version control, so any can be revived if somebody actually wants it.
> 
> > I have no desire to take a port from anyone that is a Maintainer. But
> > after a bit of investigation, those that I substituted myself for,
> > appeared to have been using distcache for some time -- often for more than
> > a year.
> 
> 
> Well, please that the file wasn't just moved on the same server (as in this
> case) or if the exact same file is readily available somewhere else.  The
> length it was pulling from distcache really doesn't indicate anything --
> only that nobody noticed.
I didn't see that in this case. I *did* attempt to find the file
on the web site, but w/o success. Glad you (two) were able to discover
otherwise. Especially in the case of the GitHub version.

Thanks John, for your thoughtful reply.

I don't know how you effectively determine that a port must die, nor
how you have determined (exactly) how many ports I am capable of
(effectively) maintaining. But I can assure you, I give reasonable
consideration to those ports I *choose* to maintain.
I have also been unable to find the list of ports that everyone wants
to die. ;)

Thanks, again.

--Chris
> 
> Thanks
Comment 13 John Marino freebsd_committer freebsd_triage 2015-04-11 19:48:14 UTC
> Speaking for *this* port. I had looked for *quite* some time for a port
> that did *exactly* what this port did. I don't know if that constitutes/
> defines "obscure". But I can't tell you how happy I was to have discovered
> this port.

I already said this port was an exception, that it was "interesting".  I saved it on my own so obviously I think it's useful.  I found this PR because I was saving the PR.


> If you really want a port to die. IMHO it might be more effective to
> issue an EOL/DEPRECIATION  warning:
> Heads up, this port is slated for removal on XXXX-XX-XX because it
> doesn't appear to be of any significant value to anyone.


Almost every port I'm talking about had deprecation warnings.  That never stopped anyone before.  We don't need to make funny deprecation messages.


> You could then easily determine it's *actual* value based on the
> response to the message.

How?  Talking historically, you were the only one that responded to the message, but it was enough to block the removal.  (I'm still bitter about that gnats port)


> I don't know how you effectively determine that a port must die,

Look at the ports history.  If it has not had a maintainer in years, and the only commits to it are infrastructure changes and it's several releases behind, that's generally a port that people want to do.  Especially if the previous maintainer was reset or just quit.  The logs give a good idea of how many PRs there were and how much interest it had in it's history.  It's pretty obvious when nobody has interest.


> how you have determined (exactly) how many ports I am capable of
(effectively) maintaining. 

well, pretty much the same as anyone else.  50?  But my point was more -- you've actually said you wanted to continue development on certain ports so I'd lower the number.  At some number of ports, people drop behind on the release updates, handing PRs, etc.  There is a ceiling.  I'm worried about anyone with over 100 because any given day they can send in a request to drop all their ports.  

> But I can assure you, I give reasonable consideration to those ports I
> *choose* to maintain. 

That might indeed be the case, but I would be lying if I said I understand every selection you've made.  And I've successfully talked you out of some of them!

Anyway, in this case I thought the request was quite aggressive.  The port had only been broken for a couple of days and it had an active maintainer that hadn't indicated he was looking to give it up.  And it was quite easy to find the new location by going to home page, it only took about 20 seconds.  Anyway, we've talked poor martin's ear off by now...