Date: Thu, 18 Aug 2011 02:57:17 +0200 From: "Julian H. Stacey" <jhs@berklix.com> To: Mark Linimon <linimon@lonesome.com> Cc: ports@freebsd.org, ben@freebsd.org, Poul-Henning Kamp <phk@phk.freebsd.dk>, Chris Rees <utisoft@gmail.com> Subject: Re: sysutils/diskcheckd needs fixing and a maintainer Message-ID: <201108180057.p7I0vH1B070035@fire.js.berklix.net> In-Reply-To: Your message "Wed, 17 Aug 2011 11:15:54 CDT." <20110817161554.GA2496@lonesome.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Mark, > On Wed, Aug 17, 2011 at 04:36:23PM +0200, Julian H. Stacey wrote: > > Better to leave the port marked as having some run errors in some > > circumstances, that we dont have manpower for, but leave port in > > tree. > > Then we have the situation of a user spends the time to install it only > to figure out it's obsolete, broken, junk. This is not desirable. > > > At least it compiles. If removed, some people who look for such a > > tool might not know it exists & is already ported. > > But doesn't work. As for contacting: > > > Jeremy Chadwick <koitsu@FreeBSD.org> > > no longer involved with the project (since 2008). > > > David W. Chapman Jr. (dwcjr@FreeBSD.org) > > no longer involved with the project (since 2001). > > While FreeBSD can't make the statement "all ports in our Ports Collection > are useful and secure", we can at least make the attempt to weed out > obviously obsolete and/or broken and/or abandoned ports, so that prospective > users of them don't waste their time. > That's what this whole deprecation and cleanup work is for: to get rid of > the bitrot. I can live with whatever Chris, you & ports team decide on this port, But .. I'd question _why_ valuable people like you & Chris would allow your time to be distracted merely to try to get repair run time capability of a port. Run time performance should be beyond priority remit of central ports team, There's more important work for their rare skills. As Vadim Goncharov just wrote to arch@ Wed, 17 Aug 2011 23:10:19 +0000 (UTC) on another thread: "we often have not enough \n time/resources" Only a limited number of people are skilled in ports/ variables & arcane macros etc, many shy away. A great deal more normal *Unix* generic people are perfectly capable of fixing many normal post build problems, eg the run time problems of this port. Ports team members with rare understanding of arcane ports make variables & macros, should be concentrating on that, to enhance the general automatic build capability, so less ports fight with each other & break at build time. Colliding & breaking ports has been The most serious problem of ports for years. far more serious than bit rot in odd old obscure ports, eg run time errors. So, after repeating I can live with whatever Chris, you & ports team decide on this port, I'd suggest ports team spend minimal time on this port & other similar bit rot ports. Don't try to fix run time performance/errors. Don't lose time on merit or de-merit of deleting a port that builds, to allow 2 send-pr to be deleted. Instead invent & apply new variable[s] eg INSTALL_OR_RUN_DEPRECATED="summary of 2 send-prs" aka eg RUN_DEPENDS BUILD_DEPENDS etc Consider that sufficient to allow a closure of send-pr after copying send-prs to a README dir in the port. Leave it & other easy ports runtime problems for less [ports]skilled users to fix. & conserve your valuable time for the hard stuff, eg More compatability automation between competing ports. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with "> "; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201108180057.p7I0vH1B070035>