Re: saving a few ports from death
On 05/01/2011 00:12, mato wrote: Regarding hosting the files -- one of the goals of the foundation is to provide infrastructure for the project. And this seems like one of the opportunities to do so. Besides, all of the ports mentioned have their distfiles already mirrored on FreeBSD's FTP. I think you misunderstand the purpose of mirroring the distfiles. It's done as a service to FreeBSD users to deal with temporary upstream problems, not as a primary source. Bandwidth costs money, and we don't want to abuse the generosity of those who contribute their systems to FreeBSD. The fact remains that if people want these ports saved then the appropriate resources have to be forthcoming. That includes person-hours to maintain the ports, as well as hosting for the distfiles. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
Doug Barton wrote: On 04/25/2011 17:28, martinko wrote: Ok, I skimmed through the list of deprecated ports and I identifed the following that I may be using or at least used in past and I could take over their maintenance to save them from death: Generally by the time that a port has deteriorated to the point where the distfiles are gone, and it has no maintainer, it's usually a pretty good sign that it's time to move on. This isn't just because of the distfile issue. Every port in the tree consumes resources, whether it's for pointyhat runs, space on the package sites (including the mirrors), etc. They also consume time to deal with when they get broken by changes in the OS, etc. What we're trying to do here is to eliminate ports that are no longer useful. You might want to consider whether or not some of these can be replaced by different alternatives. misc/wmweather Give misc/wmweather+ a try. It's actively developed and maintained. sysutils/wmmemmon There are a million other dockapps that do similar jobs, and this one does not seem that special. :) As for the gimp thing that you mentioned, I don't know anything about it, but if you wish to become its maintainer the polite thing to do would be to provide resources to host its distfile(s). Doug Well, I actually use both weather dockapps you mentioned and would like to keep them. The same goes for wmmemmon. Diversity is good, people have different tastes and I hope no one is going to make (unnecessary) decisions for them. Regarding hosting the files -- one of the goals of the foundation is to provide infrastructure for the project. And this seems like one of the opportunities to do so. Besides, all of the ports mentioned have their distfiles already mirrored on FreeBSD's FTP. Cheers, M. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
On 27 Apr 2011 21:04, "Mikhail T." wrote: >> cvs's Attic can be easily restored if people take up the slack. I see >> no reason to change this policy > > No, not easily. It requires the CVS tree, which is not automatically installed. What are you on about? Just do an anonymous checkout, like every other time you access cvs for reading. Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
On 04/27/2011 13:54, Eitan Adler wrote: Which is a*major* drain of resources. One of the reasons for ceasing the building of packages for broken/completely obsolete is to avoid draining the computer time building said packages. ... and in addition to CPU cycles there is also storage on the dozens of mirrors for packages, distfiles, cvs, etc. Almost all of those mirrors are provided by organizations that donate their resources to help the FreeBSD community. Many of them are already stretched thin. I don't think the view that "we don't provide a warranty" is realistic. If you took 100 FreeBSD users and asked them, "Would you be surprised to find a known-bad version of something in the ports tree?" I think 99 of them would say, "yes!" Those who want to keep EOL stuff around also seem to be ignoring that in FreeBSD the model is generally "maintainer knows best." To take apache13 as a specific example, the maintainers of that port have said pretty clearly, "it's a bad idea to keep using this, and we want to get rid of it ASAP." At least one of those maintainers is part of the ASF, so I tend to take his word on such things. Finally, as someone else pointed out, if you decide for yourself that you really really need something that's been removed from the ports tree, you can always dig it out of CVS. Yes, I realize that's extra work on your part, but that's part of the "price" of "free" software. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
On 2011-04-27 17:59, Mikhail T. wrote: > On -10.01.-28163 14:59, Robert Huff wrote: >> It is also possible it is only important to a fairly small >> number ... but to those it is absolutely crucial. > Or the port might become useful/essential/critical to somebody in the > future... > > What is not broken -- just old, like databases/db2 or www/apache13*, for > example -- should be left alone (until it becomes both broken and > unmaintained). > And even then, the removal should not be mass-scale/automatic... What are you missing in the db2 implementation of FreeBSD which is in the OS and maintained by the OS developers? For myself I see the apache13 EOL with a whining and a laughing eye, and can understand if users don't want to upgrade to 22/24 because of complex and working configurations. But I also look at the future development of the OS and environment where such old dinosaur should see a ice time to make room for new live. Within the apache13/20 deprecation also other ports will go since they are not compatible with newer apache version. For anyone interested I've done a quick grep over my local build logs to get a list of ports which depends on apache13/20 http://people.freebsd.org/~ohauer/diffs/apache_ports/apache13_ports.log http://people.freebsd.org/~ohauer/diffs/apache_ports/apache20_ports.log Most of the ports have equivalents for apache22. http://people.freebsd.org/~ohauer/diffs/apache_ports/apache22_ports.log All those ports where build with the following setting in bsd.apache.mk DEFAULT_APACHE_VERSION= 22 APACHE_SUPPORTED_VERSION= 22 13 20 -- olli ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
On Wed, Apr 27, 2011 at 05:05:57PM -0400, Eitan Adler wrote: > >> apache13 is EOL upstream. We should not have ports for EOL software. > > > > Why not, exactly?.. > > What happens if a security hole or a bug is found? Are we the ones to > fix it? If yes are we to host the patches? Where should the bug > reports go to - our bug tracker? What if our implementation ceases to > match established documentation? Should we host the docs too? "We"? Who is this "we" you keep talking about here? If a port has a security hole then it is up to the maintainer to find a fix for it - if this fix is a patch he/she comes up with or a switch to a newer upstream version is irrelevant. If there is no maintainer and nobody else provides a fix either, it is time to mark the port as FORBIDDEN and DEPRECATED and remove it after the deprecation period expires, just like how other broken ports are handled. > > The ports collection is one of *third party* software (with a couple > of small exceptions). If the third party says "this program is done, > has bugs which won't be fixed, etc" we should no longer support it. Depends on what you mean by "support", but removing a port just because upstream development has ceased is just plain silly. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
Eitan, you are entitled to your opinions, but not to your own facts. My factual corrections are inline below. Arguing about opinions and policy is useless until the facts are accepted as such by all participants: On 27.04.2011 16:54, Eitan Adler wrote: The upstream maintainer already called it "end of life". FreeBSD does not and will not ever take over the development of dead upstream ports (and in this case there is a upstream version) I never suggested, we undertake /development/ of upstream software -- EOLed or not. Fact 1. The same entity(ies), that currently busy themselves marking things>"deprecated". The ports marked "broken with no one to fix them" (shortened to 'deprecated') take a significant amount of time and energy to fix. db2 was not broken. Neither is apache13... Fact 2. Which is a *major* drain of resources. "Major"? Didn't you say earlier, that the most recent sweep -- only deleted about 3% of the ports? I'd say, this is Fact 3, but, maybe, even 3% qualifies as "major" in your view... And was not this sweep the largest in our history? What you fail to understand is that we are NOT marking ports as 'obsolete' or 'bad' or 'there exists a better program' but as broken and unmaintained. I can only repeat the example of db2. It was never broken, but deleted nonetheless... The same is about to happen to apache13... -mi ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
Quoth Ade Lovett on Wednesday, 27 April 2011:
> On Apr 27, 2011, at 13:46 , Chip Camden wrote:
> >
> > Modifying the script that was posted earlier, we can list out all
> > installed ports that are currently deprecated, and why:
>
> Won't work -- need to handle slave ports etc, where the DEPRECATED may be in
> the MASTER_PORT.
>
> Try this:
>
> #!/bin/sh
> #
> PORTSDIR=${1-"/usr/ports"}
> for port in $(pkg_info -oa | grep /)
> do
> dep=$(make -C ${PORTSDIR}/${port} -V DEPRECATED)
> [ -n "${dep}" ] && echo "${port}: ${dep}"
> done
>
>
> -aDe
>
> ___
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Nice, thanks!
--
.O. | Sterling (Chip) Camden | http://camdensoftware.com
..O | sterl...@camdensoftware.com | http://chipsquips.com
OOO | 2048R/D6DBAF91 | http://chipstips.com
pgp5qYJQh9YGn.pgp
Description: PGP signature
Re: saving a few ports from death
On Wed 27 Apr 2011 at 14:05:57 PDT Eitan Adler wrote: apache13 is EOL upstream. We should not have ports for EOL software. Why not, exactly?.. What happens if a security hole or a bug is found? Are we the ones to fix it? No. The rule of caveat emptor should apply. We don't warranty anything else in the portstree, why would you think that there's an implied warranty in this scenario? If yes are we to host the patches? The question is moot, given a negative answer to the preceding one. Where should the bug reports go to - our bug tracker? If they do get submitted there, they should be immediately closed as "Won't Fix". What if our implementation ceases to match established documentation? Should we host the docs too? Same answers as above. The ports collection is one of *third party* software (with a couple of small exceptions). If the third party says "this program is done, has bugs which won't be fixed, etc" we should no longer support it. Keeping it in the tree != obligation to provide support, i.e., bugfixes for anything except the port Makefile and other port-related files. As long as there's a maintainer willing to do the work to keep it running (warts and all) on the currently-supported FreeBSD releases, I don't see any reason why it can't be kept in the tree. If upstream says it's dead, who are we to keep it alive? We are a major Operating System project, which maintains ports of third-party applications for the convenience of our users. An EOL-declaration by the authors does not mean, the users must stop using it immediately -- it simply says, the authors will not be releasing updates/bug-fixes. Correct. However (a) if the third party gave an upgrade path we should encourage our users to use it and (b) if there *are* known bugs and especially security holes we should cease to make it available through our tree. Agree with (a) but maybe not (b). That's a decision that should be left to the users. If a user says "I found an issue with X and it is EOL upstream" the correct response is to "upgrade to a supported version". See above. However this discussion is different to the one that we started with (namely that of deprecated ports) so lets try and get back on track :-) Actually, it's a closely related question. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
>> apache13 is EOL upstream. We should not have ports for EOL software. > > Why not, exactly?.. What happens if a security hole or a bug is found? Are we the ones to fix it? If yes are we to host the patches? Where should the bug reports go to - our bug tracker? What if our implementation ceases to match established documentation? Should we host the docs too? The ports collection is one of *third party* software (with a couple of small exceptions). If the third party says "this program is done, has bugs which won't be fixed, etc" we should no longer support it. >> >> If upstream says it's dead, who are we to keep it alive? > > We are a major Operating System project, which maintains ports of > third-party applications for the convenience of our users. An > EOL-declaration by the authors does not mean, the users must stop using it > immediately -- it simply says, the authors will not be releasing > updates/bug-fixes. Correct. However (a) if the third party gave an upgrade path we should encourage our users to use it and (b) if there *are* known bugs and especially security holes we should cease to make it available through our tree. If a user says "I found an issue with X and it is EOL upstream" the correct response is to "upgrade to a supported version". However this discussion is different to the one that we started with (namely that of deprecated ports) so lets try and get back on track :-) -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
On 27.04.2011 16:47, Wesley Shields wrote: apache13 is EOL upstream. We should not have ports for EOL software. Why not, exactly?.. If upstream says it's dead, who are we to keep it alive? We are a major Operating System project, which maintains ports of third-party applications for the convenience of our users. An EOL-declaration by the authors does not mean, the users must stop using it immediately -- it simply says, the authors will not be releasing updates/bug-fixes. -mi ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
>dougb is anxious to delete apache13 as well instead of simply disowning it... The upstream maintainer already called it "end of life". FreeBSD does not and will not ever take over the development of dead upstream ports (and in this case there is a upstream version) >The same entity(ies), that currently busy themselves marking things >>"deprecated". The ports marked "broken with no one to fix them" (shortened to 'deprecated') take a significant amount of time and energy to fix. Think of the warning as a "call to fix" for those parts. If you feel > No, not easily. It requires the CVS tree, which is not automatically > installed. /usr/ports/obsoleted, on the other hand, would be rolled out > together with the rest of the ports-tree. And for those who want to use old, and likely broken ports, they can take that effort to install the tree. > And, under my proposal, the > packages for the "obsolete" stuff will continue building. Which is a *major* drain of resources. One of the reasons for ceasing the building of packages for broken/completely obsolete is to avoid draining the computer time building said packages. Take a guess how long it takes to build from start to completion a complete set of packages. I'll bet you get it wrong. Furthermore in order to continue building packages the ports have to *work* which most of them presently do not. What you fail to understand is that we are NOT marking ports as 'obsolete' or 'bad' or 'there exists a better program' but as broken and unmaintained. What we ARE saying is that "this port does not presently work and no one took up the mantle to (a) fix it (b) maintain it (c) continue to the maintain it in the future. There are hundreds if not thousands of obsolete ports in the tree. This is because someone decided to MAINTAIN the ports. We can not support BROKEN ports unless someone does the work. [snip] > Same goes for apache13 -- last change was an upgrade to 1.3.42 (February > 2010) -- it does not seem to require much work. Apache 1.3 is DEAD and been supplanted upstream. If you wish to fork apache 1.3 and make a new project we will GLADY host a port for it (if someone decided to maintain it) I strongly doubt that you have any idea of the amount of work it takes to support 23,000 ports. Furthermore it seems that your proposals fail to consider the amount of infrastructure work that must be delayed or even prevented due to sheer number of broken and unmaintained ports. -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
On Wed, Apr 27, 2011 at 04:03:58PM -0400, Mikhail T. wrote: > On 27.04.2011 14:16, Eitan Adler wrote: > > Then bapt@ marked the ports*deprecated* which does not mean deleted. It > > was a warning that people who were interested should step up and take up > > the work. If after N amount of time no one does so they will be > > individually deleted. > The ports I listed -- db2 and apache13* family -- are/were not broken. What > "work" are you talking about? > > Yet, mandree deleted db2 on April 12th and dougb is anxious to delete > apache13 as well instead of simply disowning it... apache13 is EOL upstream. We should not have ports for EOL software. I don't care if it works perfectly fine and someone wants to hand-roll patches back to it. If upstream says it's dead, who are we to keep it alive? -- WXS ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
On 27.04.2011 14:16, Eitan Adler wrote: Then bapt@ marked the ports*deprecated* which does not mean deleted. It was a warning that people who were interested should step up and take up the work. If after N amount of time no one does so they will be individually deleted. The ports I listed -- db2 and apache13* family -- are/were not broken. What "work" are you talking about? Yet, mandree deleted db2 on April 12th and dougb is anxious to delete apache13 as well instead of simply disowning it... > Maybe, for cleanliness and neatness, we should have a separate directory > (and category): "obsolete" -- where ports can go to die peacefully. But it > should not be cvs' "Attic"... Who will be the ones to deal with that category, ensuring new infrastructure works, etc? The port maintainer? oh wait! The same entity(ies), that currently busy themselves marking things "deprecated". But it was just a proposal -- for those, who don't like to see "obsolete" software mixed with the latest and greatest. I'm perfectly satisfied with not touching "obsolete" things at all. Certainly not until they break -- and stay broken for "too long". cvs's Attic can be easily restored if people take up the slack. I see no reason to change this policy No, not easily. It requires the CVS tree, which is not automatically installed. /usr/ports/obsoleted, on the other hand, would be rolled out together with the rest of the ports-tree. And, under my proposal, the packages for the "obsolete" stuff will continue building. The "if people take up the slack" seems to imply need to continuously work on the software. But the db2 needed no serious changes since 2004 and the last meaningful change was in 2008... The only reason to kill it was "too old"... Now all current users of db2 have to move onto later dbX, which means not only patching up the API-calls in their source-code (if the source code is even available!), but recreating their databases too -- because Berkeley DB files are not backwards-compatible. And for what reason?.. Same goes for apache13 -- last change was an upgrade to 1.3.42 (February 2010) -- it does not seem to require much work. There may well be good reasons to hate it, but somebody with a custom module, for example, may be perfectly satisfied with it... I happen to know one such site, for example. There may be more. If apache@ does not want it, they can drop maintainership. But deletion is not called for. Upgrading the OS should not /require/ upgrading (and replacing!) the applications. Yours, -mi ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
On Apr 27, 2011, at 13:46 , Chip Camden wrote:
>
> Modifying the script that was posted earlier, we can list out all
> installed ports that are currently deprecated, and why:
Won't work -- need to handle slave ports etc, where the DEPRECATED may be in
the MASTER_PORT.
Try this:
#!/bin/sh
#
PORTSDIR=${1-"/usr/ports"}
for port in $(pkg_info -oa | grep /)
do
dep=$(make -C ${PORTSDIR}/${port} -V DEPRECATED)
[ -n "${dep}" ] && echo "${port}: ${dep}"
done
-aDe
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Re: saving a few ports from death
Quoth Eitan Adler on Wednesday, 27 April 2011:
> > What is not broken -- just old, like databases/db2 or www/apache13*, for
> > example -- should be left alone (until it becomes both broken and
> > unmaintained). And even then, the removal should not be
> > mass-scale/automatic...
>
> This recent sweep was neither mass scale nor automatic.
> 536/22816 ports is only 3.234% of all the ports. Furthermore bapt@,
> myself, and a few other people went through each of the categories
> ensuring the projects were actually dead (not necessarily that the
> distfile couldn't be found). Then bapt@ marked the ports *deprecated*
> which does not mean deleted. It was a warning that people who were
> interested should step up and take up the work. If after N amount of
> time no one does so they will be individually deleted.
>
> > Maybe, for cleanliness and neatness, we should have a separate directory
> > (and category): "obsolete" -- where ports can go to die peacefully. But it
> > should not be cvs' "Attic"...
>
> Who will be the ones to deal with that category, ensuring new
> infrastructure works, etc? The port maintainer? oh wait!
> cvs's Attic can be easily restored if people take up the slack. I see
> no reason to change this policy.
>
> --
> Eitan Adler
Modifying the script that was posted earlier, we can list out all
installed ports that are currently deprecated, and why:
#!/bin/sh
prefix=/usr/ports/
makefile=/Makefile
for file in `pkg_info -oxa | grep "/"`
do
yes=`grep DEPRECATED= ${prefix}${file}${makefile}`
if [ -n "$yes" ]
then
echo $file $yes
fi
done
When I ran this on my system, I found only lang/libutils. It must have been
needed by something I've since uninstalled, because nothing depends on it
now -- so I deleted it.
--
.O. | Sterling (Chip) Camden | http://camdensoftware.com
..O | sterl...@camdensoftware.com | http://chipsquips.com
OOO | 2048R/D6DBAF91 | http://chipstips.com
pgpxU3jAVMkAt.pgp
Description: PGP signature
Re: saving a few ports from death
On 04/27/2011 08:59, Mikhail T. wrote: What is not broken -- just old, like ... or www/apache13* apache13 is way past EOL, and the apache team is working hard to move the default to apache22, at which point I personally hope that apache13 dies a quick and painful death :) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Re: saving a few ports from death
> What is not broken -- just old, like databases/db2 or www/apache13*, for > example -- should be left alone (until it becomes both broken and > unmaintained). And even then, the removal should not be > mass-scale/automatic... This recent sweep was neither mass scale nor automatic. 536/22816 ports is only 3.234% of all the ports. Furthermore bapt@, myself, and a few other people went through each of the categories ensuring the projects were actually dead (not necessarily that the distfile couldn't be found). Then bapt@ marked the ports *deprecated* which does not mean deleted. It was a warning that people who were interested should step up and take up the work. If after N amount of time no one does so they will be individually deleted. > Maybe, for cleanliness and neatness, we should have a separate directory > (and category): "obsolete" -- where ports can go to die peacefully. But it > should not be cvs' "Attic"... Who will be the ones to deal with that category, ensuring new infrastructure works, etc? The port maintainer? oh wait! cvs's Attic can be easily restored if people take up the slack. I see no reason to change this policy. -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Re: saving a few ports from death
On -10.01.-28163 14:59, Robert Huff wrote: It is also possible it is only important to a fairly small number ... but to those it is absolutely crucial. Or the port might become useful/essential/critical to somebody in the future... What is not broken -- just old, like databases/db2 or www/apache13*, for example -- should be left alone (until it becomes both broken and unmaintained). And even then, the removal should not be mass-scale/automatic... Maybe, for cleanliness and neatness, we should have a separate directory (and category): "obsolete" -- where ports can go to die peacefully. But it should not be cvs' "Attic"... -mi ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
On Wed, Apr 27, 2011 at 08:02:34AM -0700, Chip Camden wrote: > Quoth Eric on Wednesday, 27 April 2011: ... > > >> My search for "popularity" metrics is intended to point me, as a > > >> maintainer, to ports I might want to adopt now, rather than wait for > > >> someone to complain about them. Everything *I* use is already > > >> maintained, so I've moved on to looking for things other people might > > >> need. But I don't want to waste my time on something that nobody uses. > > >> :) I have suggested in the past that part of the ports infrastructure could toggle a count somewhere each time a port is made. This should be opt in of course. It would make it very easy to see which port might need a maintainer. - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db Why leave money to our children if we don't leave them the Earth? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
On Wed, Apr 27, 2011 at 1:00 AM, Mark Linimon wrote: > I need to migrate portsmon to another server so that we can start up > these periodic emails again. > > mcl > ___ > With the large number of ports to be maintained , tasks to be performed becomes very complex . The current structure of problem report submitting and e-mails about current problems may be modified to reduce the tasks to be performed even for slightly. On the problem report submitting page , http://www.freebsd.org/send-pr.html the following fields may be added to make it more structured and to be able to generate e-mails to maintainers directly : Remove field Category . Add the following fields : FreeBSD Version : ( Selected from a drop-down list like Category ) FreeBSD Architecture : ( Selected from list ... ) Related to ( Radio Button ) Base : Program Name : ... in Directory : ... - Port : Port Name in .../Latest/ Directory : ... Port Version : If there is a working version in another operating system Name : ... operating system Version : ... Port Name : ... Port Version : ... Source Repository URL : - Into Class field : Add item : Feature Suggestion . Under the box "How to repeat the problem" , addWhich tests are applied : addTesting software available : addTesting Software URL : With the above structure , it is possible . to generate e-mails to maintainers automatically , . to eliminate problem reports when operating system or port version numbers of the respective ports changes by moving them to an archive . Problem report query page http://www.freebsd.org/cgi/query-pr-summary.cgi?query may be adapted accordingly . ... In e-mails , a more structured listing will be helpful : PR FreeBSD FreeBSDPort Port NumberVersion ArchitectureName Version Description ---- --- -- - In the present system , mentioning only the category with vague descriptions causes difficulty to understand structure of the problem , at least for persons foreigner to port maintenance . Also , supplying a link to problem report numbers during generation of e-mails automatically makes them easily accessible . Thank you very much . Mehmet Erol Sanliturk ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
Quoth Eric on Wednesday, 27 April 2011:
> > From: Anton Shterenlikht
> > Date: Wed, 27 Apr 2011 10:14:41 +0100
> > To:
> > Subject: Re: saving a few ports from death
> >
> > On Tue, Apr 26, 2011 at 03:55:56PM -0700, Charlie Kester wrote:
> >>
> >> My search for "popularity" metrics is intended to point me, as a
> >> maintainer, to ports I might want to adopt now, rather than wait for
> >> someone to complain about them. Everything *I* use is already
> >> maintained, so I've moved on to looking for things other people might
> >> need. But I don't want to waste my time on something that nobody uses.
> >> :)
> >
> > Interesting..
> >
> > I used this sh(1) script to find
> > unmaintained ports that I use.
> > (I couldn't find a way to do the
> > job with the existing tools like
> > pkg_info or portmaster):
> >
> > #!/bin/sh
> >
> > prefix=/usr/ports/
> > makefile=/Makefile
> >
> > for file in `pkg_info -oxa | grep "/"`
> > do
> > yes=`grep MAIN ${prefix}${file}${makefile} | grep ports`
> > if [ -n "$yes" ]
> > then
> > echo $file
> > fi
> > done
> >
>
> [SNIP]
>
> Small observation, since that script picks up all of us who use 'ports' in
> our maintainer email addresses (myself for example), might I suggest the
> following tweak to your script (full address and checking for file
> existence):
>
> #!/bin/sh
>
> prefix=/usr/ports/
> makefile=/Makefile
>
> for file in `pkg_info -oxa | grep "/"`
> do
> if test -f ${prefix}${file}${makefile}
> then
> yes=`grep MAIN ${prefix}${file}${makefile} | grep -i 'ports@freebsd\.org'`
> if [ -n "$yes" ]
> then
>echo $file
> fi
> fi
> Done
>
Good catch -- even with that change, my list has 57 ports in it
(including, ironically, sysutils/bsdstats). A lot of the ones on my list
are requirements for other ports, though.
--
.O. | Sterling (Chip) Camden | http://camdensoftware.com
..O | sterl...@camdensoftware.com | http://chipsquips.com
OOO | 2048R/D6DBAF91 | http://chipstips.com
pgpg87PzKQ9DK.pgp
Description: PGP signature
Re: saving a few ports from death
> From: Anton Shterenlikht
> Date: Wed, 27 Apr 2011 10:14:41 +0100
> To:
> Subject: Re: saving a few ports from death
>
> On Tue, Apr 26, 2011 at 03:55:56PM -0700, Charlie Kester wrote:
>>
>> My search for "popularity" metrics is intended to point me, as a
>> maintainer, to ports I might want to adopt now, rather than wait for
>> someone to complain about them. Everything *I* use is already
>> maintained, so I've moved on to looking for things other people might
>> need. But I don't want to waste my time on something that nobody uses.
>> :)
>
> Interesting..
>
> I used this sh(1) script to find
> unmaintained ports that I use.
> (I couldn't find a way to do the
> job with the existing tools like
> pkg_info or portmaster):
>
> #!/bin/sh
>
> prefix=/usr/ports/
> makefile=/Makefile
>
> for file in `pkg_info -oxa | grep "/"`
> do
> yes=`grep MAIN ${prefix}${file}${makefile} | grep ports`
> if [ -n "$yes" ]
> then
> echo $file
> fi
> done
>
[SNIP]
Small observation, since that script picks up all of us who use 'ports' in
our maintainer email addresses (myself for example), might I suggest the
following tweak to your script (full address and checking for file
existence):
#!/bin/sh
prefix=/usr/ports/
makefile=/Makefile
for file in `pkg_info -oxa | grep "/"`
do
if test -f ${prefix}${file}${makefile}
then
yes=`grep MAIN ${prefix}${file}${makefile} | grep -i 'ports@freebsd\.org'`
if [ -n "$yes" ]
then
echo $file
fi
fi
Done
Although in only greping makefiles that exist it doesn't alert you to your
installed ports when the port has been removed from the tree...
It's an interesting situation and I wonder if there is a tool (I suppose
akin to portaudit) that alerts sys admins when ports they have installed are
depreciated or maintainers drop them? Obviously one can sign up for the
various types of alerts from Freshports, but I expect a few people here have
rolled their own periodic alert tools...
Regards
Eric
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
On Tue, Apr 26, 2011 at 03:55:56PM -0700, Charlie Kester wrote:
>
> My search for "popularity" metrics is intended to point me, as a
> maintainer, to ports I might want to adopt now, rather than wait for
> someone to complain about them. Everything *I* use is already
> maintained, so I've moved on to looking for things other people might
> need. But I don't want to waste my time on something that nobody uses.
> :)
Interesting..
I used this sh(1) script to find
unmaintained ports that I use.
(I couldn't find a way to do the
job with the existing tools like
pkg_info or portmaster):
#!/bin/sh
prefix=/usr/ports/
makefile=/Makefile
for file in `pkg_info -oxa | grep "/"`
do
yes=`grep MAIN ${prefix}${file}${makefile} | grep ports`
if [ -n "$yes" ]
then
echo $file
fi
done
I got:
print/libpaper
graphics/libwmf
print/mgv
x11-toolkits/open-motif
devel/t1lib
print/transfig
textproc/urlview
graphics/xfig
all of which I use daily,
either directly of via
dependencies (xpdf or
ImageMagick). So if you have
the time and determination,
I'd be extremely grateful
if you decide to take up
the maintainership of
either of these ports.
Many thanks
Anton
--
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
> Where is the current list of deprecated ports? > You can find the deprecated ones here http://www.freshports.org/ports-deprecated.php and the one set to expire there : http://www.freshports.org/ports-expiration-date.php regards, Bapt ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
I need to migrate portsmon to another server so that we can start up these periodic emails again. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
Adam, On Tue, Apr 26, 2011 at 10:51:39PM -0500, Adam Vande More wrote: >On Tue, Apr 26, 2011 at 10:41 PM, Robert Huff wrote: > >> >> Garance A Drosehn writes: >> >> > Speaking of which, I haven't noticed the old lists of >> > "FreeBSD unmaintained ports which are currently marked broken" >> > and >> > "FreeBSD ports which are currently scheduled for deletion" >> > >> > show up recently. I did have some mixup in my email account >> > for a short period, so I assume I just missed an announcement >> > on how that is handled now. >> >> I get regular e-mails for "marked as broken". >> > >Last one I have is from Jan 21, prior to that it was twice monthly. > Must be they were scheduled for deletion ;) last ones I received here for the two first listed subjects above were recieved January. -- Regards, (jhell) Jason Hellenthal pgpcLCljljQNW.pgp Description: PGP signature
Re: saving a few ports from death
On Tue, Apr 26, 2011 at 10:41 PM, Robert Huff wrote: > > Garance A Drosehn writes: > > > Speaking of which, I haven't noticed the old lists of > > "FreeBSD unmaintained ports which are currently marked broken" > > and > > "FreeBSD ports which are currently scheduled for deletion" > > > > show up recently. I did have some mixup in my email account > > for a short period, so I assume I just missed an announcement > > on how that is handled now. > > I get regular e-mails for "marked as broken". > Last one I have is from Jan 21, prior to that it was twice monthly. -- Adam Vande More ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
Garance A Drosehn writes: > Speaking of which, I haven't noticed the old lists of > "FreeBSD unmaintained ports which are currently marked broken" > and > "FreeBSD ports which are currently scheduled for deletion" > > show up recently. I did have some mixup in my email account > for a short period, so I assume I just missed an announcement > on how that is handled now. I get regular e-mails for "marked as broken". Robert Huff ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
On 4/25/11 8:28 PM, martinko wrote: Ok, I skimmed through the list of deprecated ports Speaking of which, I haven't noticed the old lists of "FreeBSD unmaintained ports which are currently marked broken" and "FreeBSD ports which are currently scheduled for deletion" show up recently. I did have some mixup in my email account for a short period, so I assume I just missed an announcement on how that is handled now. Where is the current list of deprecated ports? -- Garance Alistair Drosehn= g...@gilead.netel.rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Instituteor dro...@rpi.edu ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
On 04/26/2011 15:09, Charlie Kester wrote: Now that I have my code proved out, I'm going to expand it to look at all unmaintained ports regardless of category. Any suggestions for where I should post the results? (That is, unless you think the bitbucket is the only suitable place for it.) As a matter of curiosity, sure, put it on a web site somewhere, no worries. Meanwhile, I think you might be missing the point. :) We should not be looking for reasons to save unmaintained ports. We should be providing resources for those that would like to adopt them, pointing users to suitable alternatives, marking them deprecated so as to encourage maintainers to come forward, etc. In other words, exactly what we have been doing. Yes, there will likely be a period after the ports actually disappear where some of them will need to be resurrected because someone will finally be motivated to step forward. But that's easily done. Meanwhile, let's nuke as much as we can, as fast as we can. We're rapidly closing in on 23,000 ports, which is already an unmanageable mess. We need to be able to delete the cruft if we have any hope of keeping the ship afloat. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
On Tue 26 Apr 2011 at 15:15:54 PDT Jerry wrote: If no one steps up claiming to need the port, then good riddance. If on the other hand a user claims a valid use of the port, let them take responsibility for it or find someone who will. Leaving intact ports that either don't build, cannot be fetched, etcetera does not really make a lot of sense. No disagreement here. Just now I ran a query on freshports and found almost 5000 ports with maintainer=po...@freebsd.org. That's way too many! My search for "popularity" metrics is intended to point me, as a maintainer, to ports I might want to adopt now, rather than wait for someone to complain about them. Everything *I* use is already maintained, so I've moved on to looking for things other people might need. But I don't want to waste my time on something that nobody uses. :) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
On Tue, 26 Apr 2011 14:54:05 -0700 Doug Barton articulated: > On 04/26/2011 14:18, Robert Huff wrote: > > It is also possible it is only important to a fairly small > > number ... but to those it is absolutely crucial. > > Fair enough, then one of them needs to step forward to maintain the > port. :) > > FWIW, I think that the person who suggested deleting the port as a > way to gain a metric of its popularity was joking ... Sorry, but I was dead serious. "Don't Know What You Got (Till It's Gone)" "Cinderella" If no one steps up claiming to need the port, then good riddance. If on the other hand a user claims a valid use of the port, let them take responsibility for it or find someone who will. Leaving intact ports that either don't build, cannot be fetched, etcetera does not really make a lot of sense. -- Jerry ✌ jerry+po...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
On Tue 26 Apr 2011 at 14:34:00 PDT Charlie Kester wrote: On Tue 26 Apr 2011 at 14:27:47 PDT Charlie Kester wrote: FWIW, here are some popularity/vitality stats from freshmeat for unmaintained ports in the sysutils category. Drat, the mailinglist rejected the attachment. If anyone wants to see it, send me a private email and I'll reply with a copy. Here are the top ten most "popular" unmaintained ports from this category, in case someone's looking for one to adopt: "name""popularity" "vitality" "k3b" 754.12 120.91 "sg3_utils" 444.46 41.9 "LPRng" 303.65 5.13 "afio"292.62 2.44 "anteater"237.11 4.26 "bchunk" 215.97 2.71 "userinfo"211.26 23.51 "ddrescue"210.72 8.82 "cpuburn" 207.73 1 "cw" 207.28 11.25 k3b looks like an obvious choice. I restricted my search to this category while hammering out my approach. Now that I have my code proved out, I'm going to expand it to look at all unmaintained ports regardless of category. Any suggestions for where I should post the results? (That is, unless you think the bitbucket is the only suitable place for it.) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
On 04/26/2011 14:18, Robert Huff wrote: It is also possible it is only important to a fairly small number ... but to those it is absolutely crucial. Fair enough, then one of them needs to step forward to maintain the port. :) FWIW, I think that the person who suggested deleting the port as a way to gain a metric of its popularity was joking ... Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
On Tue 26 Apr 2011 at 14:27:47 PDT Charlie Kester wrote: On Tue 26 Apr 2011 at 09:34:24 PDT Charlie Kester wrote: I'm not a web programmer and don't have access to the freshports sourcecode. So all I can do there is make a suggestion. But perhaps I'll take some time to go through the list of unmaintained ports and manually check them against the popularity ratings on a site like freshmeat. It's a bit of a leap to assume that a program that's popular on Linux will be as popular on BSD, but it's the best data we have for the time being. FWIW, here are some popularity/vitality stats from freshmeat for unmaintained ports in the sysutils category. Freshmeat calculates these stats as follows: popularity = ((record hits + URL hits) * (subscriptions + 1))^(1/2) where record hits = hits on the freshmeat project page, url hits = clickthroughs to author's projectpage or download site, and subscriptions = freshmeat users following the project. vitality = ((announcements * age) / (last_announcement))^(1/2) "The number of announcements a project has made is multiplied by the number of days it has existed in the database, which is then divided by the days passed since the last release. This way, projects with lots of announcements that have been around for a long time and have recently come out with a new release earn a high vitality score, and old projects that have only been announced once get a low vitality score." For comparison and to give a sense of scale, here are the stats for some well-known projects: NamePopularity Vitality mplayer 3,995.2045.16 MySQL 3,310.5573.39 mutt1,032.7142.53 conky 173.67 3.60 exaile 64.48 3.75 In the attached file, ports listed with popularity and vitality scores = 0 are those where there is no entry in the freshmeat database. I made no effort to verify that a freshmeat project with the same name as the port is in fact the same program, so there might be some false positives in the data. Drat, the mailinglist rejected the attachment. If anyone wants to see it, send me a private email and I'll reply with a copy. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
On Tue 26 Apr 2011 at 09:34:24 PDT Charlie Kester wrote: I'm not a web programmer and don't have access to the freshports sourcecode. So all I can do there is make a suggestion. But perhaps I'll take some time to go through the list of unmaintained ports and manually check them against the popularity ratings on a site like freshmeat. It's a bit of a leap to assume that a program that's popular on Linux will be as popular on BSD, but it's the best data we have for the time being. FWIW, here are some popularity/vitality stats from freshmeat for unmaintained ports in the sysutils category. Freshmeat calculates these stats as follows: popularity = ((record hits + URL hits) * (subscriptions + 1))^(1/2) where record hits = hits on the freshmeat project page, url hits = clickthroughs to author's projectpage or download site, and subscriptions = freshmeat users following the project. vitality = ((announcements * age) / (last_announcement))^(1/2) "The number of announcements a project has made is multiplied by the number of days it has existed in the database, which is then divided by the days passed since the last release. This way, projects with lots of announcements that have been around for a long time and have recently come out with a new release earn a high vitality score, and old projects that have only been announced once get a low vitality score." For comparison and to give a sense of scale, here are the stats for some well-known projects: NamePopularity Vitality mplayer 3,995.2045.16 MySQL 3,310.5573.39 mutt1,032.7142.53 conky 173.67 3.60 exaile 64.48 3.75 In the attached file, ports listed with popularity and vitality scores = 0 are those where there is no entry in the freshmeat database. I made no effort to verify that a freshmeat project with the same name as the port is in fact the same program, so there might be some false positives in the data. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
Chip Camden writes: > > If you want to definitively ascertain the popularity of an application, > > just remove it from the ports structure and see how many users complain. > > There could be quite a delay in that reaction -- it might not hit > home until the port needs to be rebuilt. It is also possible it is only important to a fairly small number ... but to those it is absolutely crucial. Robert Huff ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
Quoth Jerry on Tuesday, 26 April 2011: > On Tue, 26 Apr 2011 09:34:24 -0700 > Charlie Kester articulated: > > > It's a bit of a leap to assume that a program that's popular on Linux > > will be as popular on BSD, but it's the best data we have for the time > > being. > > If you want to definitively ascertain the popularity of an application, > just remove it from the ports structure and see how many users complain. > There could be quite a delay in that reaction -- it might not hit home until the port needs to be rebuilt. -- .O. | Sterling (Chip) Camden | http://camdensoftware.com ..O | sterl...@camdensoftware.com | http://chipsquips.com OOO | 2048R/D6DBAF91 | http://chipstips.com pgpyiCaUBhmgH.pgp Description: PGP signature
Re: saving a few ports from death
On Tue, 26 Apr 2011 09:34:24 -0700 Charlie Kester articulated: > It's a bit of a leap to assume that a program that's popular on Linux > will be as popular on BSD, but it's the best data we have for the time > being. If you want to definitively ascertain the popularity of an application, just remove it from the ports structure and see how many users complain. -- Jerry ✌ jerry+po...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
On Mon 25 Apr 2011 at 22:55:10 PDT Ade Lovett wrote: On Apr 25, 2011, at 21:41 , Charlie Kester wrote: Maybe freshports could implement a voting system like the one at osx.iusethis.com? "Voting" implies some kind of democracy. I just thought it might be useful to get some actual data to support the inference that an unmaintained port is likely to be an unused and therefore unneeded port. I have no objection to your argument that what gets done is what someone is willing to do. And I am sensitive to the fact that every port imposes some additional burden on the system. I'm all for cleaning out the cruft. I'm not a web programmer and don't have access to the freshports sourcecode. So all I can do there is make a suggestion. But perhaps I'll take some time to go through the list of unmaintained ports and manually check them against the popularity ratings on a site like freshmeat. It's a bit of a leap to assume that a program that's popular on Linux will be as popular on BSD, but it's the best data we have for the time being. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
On Apr 25, 2011, at 21:41 , Charlie Kester wrote: > Maybe freshports could implement a voting system like the one at > osx.iusethis.com? "Voting" implies some kind of democracy. This may come as a shock to folks, but FreeBSD in general is in fact not democratic. It's based around the concept of folks putting in their own time to keep a part of the Project alive. Whether it's a device driver, some chunk of base userland, ports//, or support for an entire architecture and/or release of FreeBSD -- doesn't matter. Without at least a modicum of active maintainership (hint: MAINTAINER= po...@freebsd.org is _not_ active) then it will eventually fall by the wayside and die. For ports, there's a non-zero cost associated with each and every single one in the tree. Directly, in terms of clusters trying to build packages for the combination of supported releases and architectures, and indirectly, in case of infrastructural changes affecting chunks of the tree, when it comes to determining whether port breakage is a result of said changes, or whether it was broken already. Generally speaking, such "dead" ports are marked DEPRECATED with a sizable amount of time before being reaped. Honestly, I'd personally prefer the variable to be named PUT_UP_OR_SHUT_UP (but that's just me). The fact remains though, that that is _exactly_ what it is. If, in the period between a port being marked DEPRECATED and it being removed from the tree, and especially in the case of UNMAINTANED=YES (that'd be po...@freebsd.org for those in the back), no-one steps up to (a) fix the problem, (b) take maintainership and (c) _continue_ with maintainership. Well, in that case, the port does not _deserve_ to live. After all, no-one cares about it. If they did, they'd take care of (a) thru (c) above. -aDe ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
26.04.2011 04:28, martinko пишет: Ok, I skimmed through the list of deprecated ports and I identifed the following that I may be using or at least used in past and I could take over their maintenance to save them from death: graphics/gimp-greycstoration Use graphics/gimp-gmic-plugin instead. Please see http://www.FreeBSD.org/cgi/query-pr.cgi?pr=ports/154596 for details. -- Regards, Ruslan ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
On Mon 25 Apr 2011 at 17:48:31 PDT Doug Barton wrote: What we're trying to do here is to eliminate ports that are no longer useful. If we had some popularity stats, it would be interesting to see where the unmaintained ports fall on the list. Unfortunately, bsdstats doesn't include this anymore. Maybe freshports could implement a voting system like the one at osx.iusethis.com? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
On Mon, Apr 25, 2011 at 7:48 PM, Doug Barton wrote: > On 04/25/2011 17:28, martinko wrote: >> >> Ok, >> I skimmed through the list of deprecated ports and I identifed the >> following that I may be using or at least used in past and I could take >> over their maintenance to save them from death: > > Generally by the time that a port has deteriorated to the point where the > distfiles are gone, and it has no maintainer, it's usually a pretty good > sign that it's time to move on. This isn't just because of the distfile > issue. Every port in the tree consumes resources, whether it's for pointyhat > runs, space on the package sites (including the mirrors), etc. They also > consume time to deal with when they get broken by changes in the OS, etc. > What we're trying to do here is to eliminate ports that are no longer > useful. > > You might want to consider whether or not some of these can be replaced by > different alternatives. > >> misc/wmweather > > Give misc/wmweather+ a try. It's actively developed and maintained. > >> sysutils/wmmemmon > > There are a million other dockapps that do similar jobs, and this one does > not seem that special. :) > > As for the gimp thing that you mentioned, I don't know anything about it, http://registry.gimp.org/node/137 "GREYCstoration has been discontinued, and is now replaced by the G'MIC project, which contains all the former GREYCstoration features, but also much much much more !" http://gmic.sourceforge.net/gimp.shtml (G'MIC project) Cheers, Mezz > but if you wish to become its maintainer the polite thing to do would be to > provide resources to host its distfile(s). > > > Doug > > -- > > Nothin' ever doesn't change, but nothin' changes much. > -- OK Go > > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/ > > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: saving a few ports from death
On 04/25/2011 17:28, martinko wrote: Ok, I skimmed through the list of deprecated ports and I identifed the following that I may be using or at least used in past and I could take over their maintenance to save them from death: Generally by the time that a port has deteriorated to the point where the distfiles are gone, and it has no maintainer, it's usually a pretty good sign that it's time to move on. This isn't just because of the distfile issue. Every port in the tree consumes resources, whether it's for pointyhat runs, space on the package sites (including the mirrors), etc. They also consume time to deal with when they get broken by changes in the OS, etc. What we're trying to do here is to eliminate ports that are no longer useful. You might want to consider whether or not some of these can be replaced by different alternatives. misc/wmweather Give misc/wmweather+ a try. It's actively developed and maintained. sysutils/wmmemmon There are a million other dockapps that do similar jobs, and this one does not seem that special. :) As for the gimp thing that you mentioned, I don't know anything about it, but if you wish to become its maintainer the polite thing to do would be to provide resources to host its distfile(s). Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
saving a few ports from death
Ok, I skimmed through the list of deprecated ports and I identifed the following that I may be using or at least used in past and I could take over their maintenance to save them from death: graphics/gimp-greycstoration misc/wmweather sysutils/wmmemmon All of them have already distfiles mirrored on FreeBSD's FTP. M. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
