On 4 February 2015 at 16:43, Christoph Berg <christoph.b...@credativ.de> wrote:
> Re: Scott Kitterman 2015-02-04 <2026939.ppIJUsApvY@scott-latitude-e6320> >> > > pgtune hasn't seen a new upstream release since about the medieval >> > > ages, and the last git commit isn't very current either. The >> > > postgresql.conf it produces is worse than the defaults in some >> > > aspects, so people are rather harmed than helped by this tool. Let's >> > > get rid of it, in unstable and jessie. It doesn't have any rdeps. >> > > >> > > Please remove pgtune. >> > >> > I'm still using it to set 'best practice' defaults based on hardware specs. >> > >> > Yes, some of the recommendations are bogus and none of the maintainers >> > interested in fixing it. However it does give me a starting point >> > which I can then fix (capping shared_buffers to 8GB is the critical >> > one). Without pgtune, I'd need to rewrite pgtune rather than my >> > current approach of fixing its failures. > > Frankly I've never seen pgtune apply any settings even near to that, > though that might be because no options were passed in. But of course > that's what people out there tend to be doing. As Andres put it on IRC > yesterday, "I've earned quite some amount of money fixing the results > of running pgtune". Yes, its a tool and needs to be applied correctly. I also agree it is a flawed tool and needs to be applied with great care. >> Are you willing to take over maintenance? If it's dead upstream and >> unmaintained in Debian (the removal bug equates to the current maintainer >> declining to further maintain it and stating removal is better than it being >> unmaintained in Debian) then it should be removed. > > What should be done is someone forking pgtune on github or elsewhere, > and produce a new version that is more foolproof than the current > footgun. Agreed. >> If so, you've got about 10 days to get it fixed in Testing or it'll be >> removed. >> If not, then it should go and you can keep your own local package for your >> purposes. > > I don't think it's possible to get the necessary amount of changes > into testing. What we could probably do is to just remove it from > testing, and keep it in unstable for later updating. > > Stuart? It depends on what you consider necessary changes. I spoke up because I still find it useful in its current state. If you feel it is a disservice to Debian users or too much effort to keep it around in its current state, then yes it should be removed. It won't immediately affect me and I'll have quite a bit of time to implement alternatives or maybe even resurrect the upstream project. -- Stuart Bishop <stuart.bis...@canonical.com> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
