Re: [HACKERS] More nuclear options
On Monday 10 July 2006 17:06, Josh Berkus wrote:
All,
At the request of Dave Page, here's the semi-final list after looking at
the code:
To be killed:
adddepends
tips
mSQL-interface
To be honest I don't know why people are against throwing the code on
pgfoundry with a hefty readme saying that the code is unmaintained and what
it's build status is on various versions. This may not seem too useful, but
if someone were to need this code, or we ever hope to get someone to update
it and/or maintain it, thier not going to find it in the contrib modules in
some small corner of the the ftp archive, but they might have a chance of
finding it on pgfoundry.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] More nuclear options
On Mon, 10 Jul 2006, Josh Berkus wrote: To be migrated to pgFoundry: dbmirror (need owner) I'll volunteer for this if no one else steps forward. I'm not planning on making any significant chances to dbmirror at this point stage but I can look after for the pgfoundry project. dbase (owner?) fulltextindex (owner?) mac (LER) userlock (Merlin) --Josh Berkus ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] More nuclear options
Robert, To be honest I don't know why people are against throwing the code on pgfoundry with a hefty readme saying that the code is unmaintained and what it's build status is on various versions ... because we don't want to litter pgFoundry with dead, broken projects which nobody uses and which confuse users and crowd the namespace. Quality quantity. In a year nobody has spoken up for those specific projects. Who's going to maintain them? Who's going to use them? --Josh Berkus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] More nuclear options
Robert, Given the current number of projects that have no code / files / anything associated with them on pgfoundry/gborg right now, this argument rings a little hollow. If you're so keen to add to the problem, you can have my spot as pgfoundry admin. Otherwise, the rule that the pgfoundry admins agreed on is that if a project had no code and no activity in 6 months we would contact the owner, and if no response kill it. That we've been lagging behind on this is a manpower issue (and to some degree a technical issue with GForge). People do get pointed at adddepends even today... certainly no one will do anything with these projects if you nuke them, but I like giving people options... your call though. I've already added adddepends to pgFoundry (as Old PG Upgrade), since people spoke up for it. I will assign one of them as admin of the project (not sure who yet). However, in the last year nobody has spoken up for the other three, not even you. --Josh ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] More nuclear options
On Tuesday 11 July 2006 12:55, Josh Berkus wrote:
Robert,
To be honest I don't know why people are against throwing the code on
pgfoundry with a hefty readme saying that the code is unmaintained and
what it's build status is on various versions
... because we don't want to litter pgFoundry with dead, broken projects
which nobody uses and which confuse users and crowd the namespace.
Quality quantity.
Given the current number of projects that have no code / files / anything
associated with them on pgfoundry/gborg right now, this argument rings a
little hollow.
In a year nobody has spoken up for those specific projects. Who's
going to maintain them? Who's going to use them?
People do get pointed at adddepends even today... certainly no one will do
anything with these projects if you nuke them, but I like giving people
options... your call though.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] More nuclear options
On 7/10/06, Josh Berkus josh@agliodbs.com wrote: All, userlock (Merlin) Ok, I will update the project description and maintain it. userlock is a great feature, and I tried contacting the original author to get him to relicense the project but could never get a hold of him. To be honest, the current userlock contrib module is just very thin wrappers over backend functions with little/no actual value. I think the user lock functality really belongs in the core project somehow. The other proposed features to userlock, namely enhancement to certain aspects of how they are handled in the backend were largely taken care of by tom for postgresql 8.1. By the way, some time back I started another project on gborg, postisam, but never received permission from my former employer to release the code. so if that is still there it can be nuked as well. merlin ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] More nuclear options
On Tuesday 11 July 2006 14:05, Josh Berkus wrote:
Robert,
Given the current number of projects that have no code / files / anything
associated with them on pgfoundry/gborg right now, this argument rings a
little hollow.
If you're so keen to add to the problem, you can have my spot as
pgfoundry admin.
No need to fly off the handle there Josh.
Otherwise, the rule that the pgfoundry admins agreed on is that if a
project had no code and no activity in 6 months we would contact the
owner, and if no response kill it. That we've been lagging behind on
this is a manpower issue (and to some degree a technical issue with
GForge).
No code, or no active code development? Seems there is an important
difference that plays in here... looking a m-SQL it has code and could be a
starting point for someone who was looking for that. I'll grant that tips
doesn't look like much more than an article stub... it should probably be
moved to the new techdocs rather than pgfoundry.
People do get pointed at adddepends even today... certainly no one will
do anything with these projects if you nuke them, but I like giving
people options... your call though.
I've already added adddepends to pgFoundry (as Old PG Upgrade), since
people spoke up for it. I will assign one of them as admin of the
project (not sure who yet).
However, in the last year nobody has spoken up for the other three, not
even you.
Perhaps no one knew they needed to speak up... perhaps people couldn't even
find them in contrib... how many people still ask if we have full text
indexing? contrib isn't exactly the most visible place...
All I am saying is that it couldn't hurt to put the information out there...
we're not hurting for disk space and none of this stuff appears inherently
wrong, just outdated, but it might still prove useful for some people.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] More nuclear options
Robert, No need to fly off the handle there Josh. I was hoping that you'd take me up on it in a rash moment. No code, or no active code development? No code was the rule we discussed. Other stuff would be a matter for discussion. The idea was that pgfoundry was supposed to be confined to real projects and not a repository of failed ideas. Seems there is an important difference that plays in here... looking a m-SQL it has code and could be a starting point for someone who was looking for that. So are you telling me you want to be responsible for it? I'll grant that tips doesn't look like much more than an article stub... it should probably be moved to the new techdocs rather than pgfoundry. That was what I started to do. Unfortunately, the README is instrucitons for some SQL and code files which are missing. I don't see any value in Techdocs for instructions that can't be followed. Perhaps no one knew they needed to speak up... perhaps people couldn't even find them in contrib... how many people still ask if we have full text indexing? contrib isn't exactly the most visible place... All I am saying is that it couldn't hurt to put the information out there... we're not hurting for disk space and none of this stuff appears inherently wrong, just outdated, but it might still prove useful for some people. Again, it's the same question. If *you* want to be the maintainer, I'll put it on pgfoundry. Otherwise, you're asking me to be responsible for the code because you don't want to throw it away. --Josh Berkus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] More nuclear options
On Tue, Jul 11, 2006 at 03:53:26PM -0400, Josh Berkus wrote: All I am saying is that it couldn't hurt to put the information out there... we're not hurting for disk space and none of this stuff appears inherently wrong, just outdated, but it might still prove useful for some people. Again, it's the same question. If *you* want to be the maintainer, I'll put it on pgfoundry. Otherwise, you're asking me to be responsible for the code because you don't want to throw it away. To present a somewhat external opinion - I've looked at pgfoundry in the past and been both confused and disappointed. Code that doesn't compile, with no maintainer gives me a dirty taste in my mouth, and my inner voice says what the heck is this crap? There are several open source projects that give me this taste. Please help PostgreSQL not be on this list by pruning dead projects, or poor quality projects from the public image. It's EMBARASSING! :-) Thanks. Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] More nuclear options
Robert, I really don't see how this will actually cause you any extra effort, but if you want to plug my name on there after you move it, that's fine with me. I meant maintain it, not just leave it there to age like a bad cheese. If it's going to be dead code, it can do so in the FTP /old section and the CVS archives easily enough. --Josh ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] More nuclear options
On Tuesday 11 July 2006 16:33, Josh Berkus wrote:
Robert,
I really don't see how this will actually cause you any extra effort, but
if you want to plug my name on there after you move it, that's fine with
me.
I meant maintain it, not just leave it there to age like a bad cheese.
If it's going to be dead code, it can do so in the FTP /old section
and the CVS archives easily enough.
I'm not going to actively maintain it, my intrest is just in exposing the
information so that others might find it. Putting it on foundry gives it a
chance at finding an active maintainer... leaving it in the archives of CVS
will guarantee you don't get one. Since most people seem comfortable with
that, so be it.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] More nuclear options
Ühel kenal päeval, T, 2006-07-11 kell 14:05, kirjutas Josh Berkus: Robert, Given the current number of projects that have no code / files / anything associated with them on pgfoundry/gborg right now, this argument rings a little hollow. If you're so keen to add to the problem, you can have my spot as pgfoundry admin Why not just make *one* project, called DeadProjects and keep one tarball + one README.TXT per directory under it, so that in the unlikely event that someone (pg_necromancer ?) does want to resurrect a dead project he/she/it has a place to get the code from. -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] More nuclear options
Given the current number of projects that have no code / files / anything associated with them on pgfoundry/gborg right now, this argument rings a little hollow. I would say that: Given the current number of projects that have no code / files / anything associated with them on pgfoundry/gborg right now, this argument rings a little hollow. Strengthens JoshB's argument, not lessens it. That is also an argument for Gforge admins, not hackers :) In a year nobody has spoken up for those specific projects. Who's going to maintain them? Who's going to use them? People do get pointed at adddepends even today... certainly no one will do anything with these projects if you nuke them, but I like giving people options... your call though. They will always be able to pull down the source from a previous release. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] More nuclear options
On Tuesday 11 July 2006 15:53, Josh Berkus wrote:
I'll grant that tips
doesn't look like much more than an article stub... it should probably be
moved to the new techdocs rather than pgfoundry.
That was what I started to do. Unfortunately, the README is
instrucitons for some SQL and code files which are missing. I don't
see any value in Techdocs for instructions that can't be followed.
The information for the sql / code is embedded within the readme. It probably
should be broken out into multiple files. That might make it project worthy
rather than article worthy.
Perhaps no one knew they needed to speak up... perhaps people couldn't
even find them in contrib... how many people still ask if we have full
text indexing? contrib isn't exactly the most visible place...
All I am saying is that it couldn't hurt to put the information out
there... we're not hurting for disk space and none of this stuff appears
inherently wrong, just outdated, but it might still prove useful for some
people.
Again, it's the same question. If *you* want to be the maintainer, I'll
put it on pgfoundry. Otherwise, you're asking me to be responsible for
the code because you don't want to throw it away.
I really don't see how this will actually cause you any extra effort, but if
you want to plug my name on there after you move it, that's fine with me.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] More nuclear options
I've already added adddepends to pgFoundry (as Old PG Upgrade), since people spoke up for it. I will assign one of them as admin of the project (not sure who yet). How is addepends in any way old pg upgrade?? ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] More nuclear options
Again, it's the same question. If *you* want to be the maintainer, I'll put it on pgfoundry. Otherwise, you're asking me to be responsible for the code because you don't want to throw it away. Josh, How about a general call for maintainers? Post it to general, hackers and advocacy (maybe even the front of PgFoundry and or PostgreSQL.Org?) that asks if anyone would like to take over maintainership of the handful? Have a closing date for it, e.g; leave it open for a week and then if no one steps up --- its over and we nuke them with prejudice. Sincerely, Joshua D. Drake --Josh Berkus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] More nuclear options
Folks, I was looking at migrating mSQL-interface to pgFoundry, but I'm not sure there's any reason to do so. It was never finished, doesn't build, and it's not like I run across mSQL databases in the field. Does anyone? Shall we just kill it? Also, tips is an apache log converter for which the source code appears to be completely missing (?). So barring objections, that one will get the ol' missle from space too. --Josh ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] More nuclear options
Josh Berkus wrote: Folks, I was looking at migrating mSQL-interface to pgFoundry, but I'm not sure there's any reason to do so. It was never finished, doesn't build, and it's not like I run across mSQL databases in the field. Does anyone? Shall we just kill it? Also, tips is an apache log converter for which the source code appears to be completely missing (?). So barring objections, that one will get the ol' missle from space too. Ka-boom! -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] More nuclear options
All, At the request of Dave Page, here's the semi-final list after looking at the code: To be killed: adddepends tips mSQL-interface To be migrated to pgFoundry: dbmirror (need owner) dbase (owner?) fulltextindex (owner?) mac (LER) userlock (Merlin) --Josh Berkus ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
