Обсуждение: 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
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 bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
All, At the request of Dave Page, here's the semi-final list after looking at the code: To be killed:adddependstipsmSQL-interface To be migrated to pgFoundry:dbmirror (need owner)dbase (owner?)fulltextindex (owner?)mac (LER)userlock (Merlin) --Josh Berkus
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
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 majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >
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
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
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
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
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
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
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
--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | 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
bindthem...
http://mark.mielke.cc/
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 inthe FTP /old section and the CVS archives easily enough. --Josh
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
Ü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
> 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 solutionssince 1997 http://www.commandprompt.com/
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
> 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"??
> 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 solutionssince 1997 http://www.commandprompt.com/