Обсуждение: Update on replication
Update on replication: We have several things happening with Postgres-R replication: o Someone is porting the 7.2-based Postgres-R code to 7.3o Darren and I are in discussion with the Spread folks, attemptingto get a more BSD-friendly license from themo People are evaluating the Postgres-R approach and comparing itto more traditional 2-phase commit replication. With these things moving forward, we will be in a much better position to get synchronous replication integrated in PostgreSQL. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> o People are evaluating the Postgres-R approach and comparing > it to more traditional 2-phase commit replication. Not that the Postgres-R approach can replace 2-phase commit methods. 2PC is still needed for support with external transaction managers (XA drivers for JDBC). -- Rod Taylor <rbt@rbt.ca> PGP Key: http://www.rbt.ca/rbtpub.asc
Rod Taylor wrote: -- Start of PGP signed section. > > o People are evaluating the Postgres-R approach and comparing > > it to more traditional 2-phase commit replication. > > Not that the Postgres-R approach can replace 2-phase commit methods. > > 2PC is still needed for support with external transaction managers (XA > drivers for JDBC). Yes, good point. Let me add that eventually, I think we will have: sync replication (Postgres-R?)async replication, using PITRPITRtwo-phase commit for distributed transactions -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Tue, Dec 17, 2002 at 12:56:45PM -0500, Bruce Momjian wrote: > Update on replication: > > We have several things happening with Postgres-R replication: > > o Someone is porting the 7.2-based Postgres-R code to 7.3 You mean 7.4devel? > With these things moving forward, we will be in a much better position > to get synchronous replication integrated in PostgreSQL. What about asynchronous (triggered?) replication? Is something like rserv or dbmirror going to be moved to main? -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "Porque francamente, si para saber manejarse a uno mismo hubiera que rendir examen... ¿Quién es el machito que tendría carnet?" (Mafalda)
Alvaro Herrera wrote: > On Tue, Dec 17, 2002 at 12:56:45PM -0500, Bruce Momjian wrote: > > Update on replication: > > > > We have several things happening with Postgres-R replication: > > > > o Someone is porting the 7.2-based Postgres-R code to 7.3 > > You mean 7.4devel? Sorry, right. > > With these things moving forward, we will be in a much better position > > to get synchronous replication integrated in PostgreSQL. > > What about asynchronous (triggered?) replication? Is something like > rserv or dbmirror going to be moved to main? I think eventually we will have some async replication in the main server, probably using PITR logs in some way. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
I just got my copy of SysAdmin Magazine and was surprised to see an article about Usogres -- The PostgreSQL Replication Tool. I don't remember seeing it mentioned on this or the General list. Though I just started reading the article and don't have a firm grasp on it yet, I do remember a discussion of replication using this technique - described in the first two paragraphs. Fyi, Rod -- "Open Source Software - Sometimes you get more than you paid for..."
Roderick A. Anderson wrote: > I just got my copy of SysAdmin Magazine and was surprised to see an > article about Usogres -- The PostgreSQL Replication Tool. > > I don't remember seeing it mentioned on this or the General list. Though > I just started reading the article and don't have a firm grasp on it yet, > I do remember a discussion of replication using this technique - described > in the first two paragraphs. I saw Usogres when I was first in Japan. Interesting in that is intercepts queries and passes them two different servers. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Tue, 17 Dec 2002, Alvaro Herrera wrote: > What about asynchronous (triggered?) replication? Is something like > rserv or dbmirror going to be moved to main? From what I've been able to tell *so far*, Postgres-R is going to preclude the ability for either to work ... Vadim is currently reviewing the code, and based on his assessment of whether or not that is the case, I'm going to be pushing for postgres-r to be its own project/fork of PostgreSQL, like RedHat Database ...
Marc G. Fournier wrote: > On Tue, 17 Dec 2002, Alvaro Herrera wrote: > > > What about asynchronous (triggered?) replication? Is something like > > rserv or dbmirror going to be moved to main? > > From what I've been able to tell *so far*, Postgres-R is going to preclude > the ability for either to work ... Vadim is currently reviewing the code, > and based on his assessment of whether or not that is the case, I'm going > to be pushing for postgres-r to be its own project/fork of PostgreSQL, > like RedHat Database ... How is Postgres-R going to prevent async replication from also being adopted in CVS? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
ooops, sorry, that was what I meant (its been one of those days *grin*)
On Tue, 17 Dec 2002, Mikheev, Vadim wrote:
> > From what I've been able to tell *so far*, Postgres-R is
> > going to preclude the ability for either to work ...
> > Vadim is currently reviewing the code,
>
> Not the code, just Darren' pdf ("slide show" -:()
> and discussion in hackers' list.
>
>
> _____________________________________________________
> Sector Data, LLC, is not affiliated with Sector, Inc., or SIAC
>
> Not the code, just Darren' pdf ("slide show" -:()
> and discussion in hackers' list.
>
You might want to read this paper. Its not very long, and
will give you much more insite on the postgres-r work.
http://www.cs.mcgill.ca/~kemme/papers/vldb00.html
Darren
"Marc G. Fournier" <scrappy@hub.org> writes:
> On Tue, 17 Dec 2002, Alvaro Herrera wrote:
>> What about asynchronous (triggered?) replication? Is something like
>> rserv or dbmirror going to be moved to main?
>> From what I've been able to tell *so far*, Postgres-R is going to preclude
> the ability for either to work ...
Why do you say that? If it can't coexist with other solutions, then it
surely will not be accepted, but I can't think of any reason why it
would preclude other approaches.
regards, tom lane
On Tue, 17 Dec 2002, Tom Lane wrote: > "Marc G. Fournier" <scrappy@hub.org> writes: > > On Tue, 17 Dec 2002, Alvaro Herrera wrote: > >> What about asynchronous (triggered?) replication? Is something like > >> rserv or dbmirror going to be moved to main? > > >> From what I've been able to tell *so far*, Postgres-R is going to preclude > > the ability for either to work ... > > Why do you say that? If it can't coexist with other solutions, then it > surely will not be accepted, but I can't think of any reason why it > would preclude other approaches. Okay, if this is the case, that does change things somewhat, but Bruce seems to indiate that co-existance will be a problem: ======== > On Tue, 17 Dec 2002, Bruce Momjian wrote: > > > > The other concern is how does integrating Postgres-R affect the ability to > > > investigate other solutions? > > > > > > As I said, I don't doubt taht there are aspects of Postgres-R that would > > > benefit the server as a whole, and those bits-n-pieces should be looked at > > > on an individual basis, but to just slap it in completely and hope that it > > > doesn't cause problems for alternative solutions is kinda irresponsible > > > ... > > > > It certainly will cause problems with other replication solutions.
When I said: > > > It certainly will cause problems with other replication solutions. I meant it would cause other solutions to be less desirable, meaning. as you said, "affect the ability to investigate other solutions?" With a working solution, others may be less likely to investigate because Postgres-R will be our official solution. (I believe that was your major negative point.) However, with the hooks already there, people may be _more_ likely to investigate solutions, so there is really no way to know. --------------------------------------------------------------------------- Marc G. Fournier wrote: > On Tue, 17 Dec 2002, Tom Lane wrote: > > > "Marc G. Fournier" <scrappy@hub.org> writes: > > > On Tue, 17 Dec 2002, Alvaro Herrera wrote: > > >> What about asynchronous (triggered?) replication? Is something like > > >> rserv or dbmirror going to be moved to main? > > > > >> From what I've been able to tell *so far*, Postgres-R is going to preclude > > > the ability for either to work ... > > > > Why do you say that? If it can't coexist with other solutions, then it > > surely will not be accepted, but I can't think of any reason why it > > would preclude other approaches. > > Okay, if this is the case, that does change things somewhat, but Bruce > seems to indiate that co-existance will be a problem: > > > ======== > > On Tue, 17 Dec 2002, Bruce Momjian wrote: > > > > > > The other concern is how does integrating Postgres-R affect the ability to > > > > investigate other solutions? > > > > > > > > As I said, I don't doubt taht there are aspects of Postgres-R that would > > > > benefit the server as a whole, and those bits-n-pieces should be looked at > > > > on an individual basis, but to just slap it in completely and hope that it > > > > doesn't cause problems for alternative solutions is kinda irresponsible > > > > ... > > > > > > It certainly will cause problems with other replication solutions. > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Tue, 17 Dec 2002, Bruce Momjian wrote: > I meant it would cause other solutions to be less desirable, meaning. as > you said, "affect the ability to investigate other solutions?" With a > working solution, others may be less likely to investigate because > Postgres-R will be our official solution. (I believe that was your > major negative point.) However, with the hooks already there, people > may be _more_ likely to investigate solutions, so there is really no way > to know. Okay, but if we are just adding hooks to allow Postgres-R to tie in, can't those hooks be done in such a way as to be loadable, not compiled in?
> Marc G. Fournier wrote: > > On Tue, 17 Dec 2002, Alvaro Herrera wrote: > > > > > What about asynchronous (triggered?) replication? Is something like > > > rserv or dbmirror going to be moved to main? > > > > From what I've been able to tell *so far*, Postgres-R is going to preclude > > the ability for either to work ... Vadim is currently reviewing the code, > > and based on his assessment of whether or not that is the case, I'm going > > to be pushing for postgres-r to be its own project/fork of PostgreSQL, > > like RedHat Database ... > > How is Postgres-R going to prevent async replication from also being > adopted in CVS? As far as I know, all trigger based async replication solutions have a limitation. They do not handle high load (and probably cannot handle large objects. am I correct?). I think we should move to other async replication soltions, such as PostgreSQL-R or (not yet existing) transaction log based replications. -- Tatsuo Ishii
> I just got my copy of SysAdmin Magazine and was surprised to see an > article about Usogres -- The PostgreSQL Replication Tool. > > I don't remember seeing it mentioned on this or the General list. Though > I just started reading the article and don't have a firm grasp on it yet, > I do remember a discussion of replication using this technique - described > in the first two paragraphs. Glad to hear that. Usogres was developed in Japan and pretty popular ammong Japanese PostgreSQL community. BTW, there is a commercial product called QueryMaster, which takes similar approach to Usogres. It copies the input query and distribute to multiple PostgreSQL servers. As long as one of a server is working, users even do not notice some of them are failing. -- Tatsuo Ishii
On Wed, 18 Dec 2002, Tatsuo Ishii wrote: > > I just got my copy of SysAdmin Magazine and was surprised to see an > > article about Usogres -- The PostgreSQL Replication Tool. > > > > I don't remember seeing it mentioned on this or the General list. Though > > I just started reading the article and don't have a firm grasp on it yet, > > I do remember a discussion of replication using this technique - described > > in the first two paragraphs. > > Glad to hear that. Usogres was developed in Japan and pretty popular > ammong Japanese PostgreSQL community. > > BTW, there is a commercial product called QueryMaster, which takes > similar approach to Usogres. It copies the input query and distribute > to multiple PostgreSQL servers. As long as one of a server is working, > users even do not notice some of them are failing. How come these solutions are such well kept secrets? I've heard of neither in relation to past discussions about replication, or have I just missed them? :(
On Tue, 2002-12-17 at 19:38, Marc G. Fournier wrote: > On Wed, 18 Dec 2002, Tatsuo Ishii wrote: > > > > I just got my copy of SysAdmin Magazine and was surprised to see an > > > article about Usogres -- The PostgreSQL Replication Tool. > > > > > > I don't remember seeing it mentioned on this or the General list. Though > > > I just started reading the article and don't have a firm grasp on it yet, > > > I do remember a discussion of replication using this technique - described > > > in the first two paragraphs. > > > > Glad to hear that. Usogres was developed in Japan and pretty popular > > ammong Japanese PostgreSQL community. > > > > BTW, there is a commercial product called QueryMaster, which takes > > similar approach to Usogres. It copies the input query and distribute > > to multiple PostgreSQL servers. As long as one of a server is working, > > users even do not notice some of them are failing. > > How come these solutions are such well kept secrets? I've heard of > neither in relation to past discussions about replication, or have I just > missed them? :( > Good questions. I've heard of Usogres, more or less in passing, but heard it didn't work very well. Also heard that it wasn't reliable or a serious solution. I seem to remember hearing that it only worked on much older versions of PostgreSQL. Of course, I'm not attempting to assert any true to what I've heard but since it's being talking about, perhaps someone can clarify how well it REALLY works. Perhaps even provide some more details on it? Never heard of QueryMaster. Perhaps someone would like to talk a little more about that as well? -- Greg Copeland <greg@copelandconsulting.net> Copeland Computer Consulting
On Tue, 17 Dec 2002, Greg Copeland wrote:
> On Tue, 2002-12-17 at 19:38, Marc G. Fournier wrote:
> > On Wed, 18 Dec 2002, Tatsuo Ishii wrote:
> >
> > > > I just got my copy of SysAdmin Magazine and was surprised to see an
> > > > article about Usogres -- The PostgreSQL Replication Tool.
> > > >
> > > > I don't remember seeing it mentioned on this or the General list. Though
> > > > I just started reading the article and don't have a firm grasp on it yet,
> > > > I do remember a discussion of replication using this technique - described
> > > > in the first two paragraphs.
> > >
> > > Glad to hear that. Usogres was developed in Japan and pretty popular
> > > ammong Japanese PostgreSQL community.
> > >
> > > BTW, there is a commercial product called QueryMaster, which takes
> > > similar approach to Usogres. It copies the input query and distribute
> > > to multiple PostgreSQL servers. As long as one of a server is working,
> > > users even do not notice some of them are failing.
> >
> > How come these solutions are such well kept secrets? I've heard of
> > neither in relation to past discussions about replication, or have I just
> > missed them? :(
> >
>
> Good questions. I've heard of Usogres, more or less in passing, but
> heard it didn't work very well. Also heard that it wasn't reliable or a
> serious solution. I seem to remember hearing that it only worked on
> much older versions of PostgreSQL. Of course, I'm not attempting to
> assert any true to what I've heard but since it's being talking about,
> perhaps someone can clarify how well it REALLY works. Perhaps even
> provide some more details on it?
>
> Never heard of QueryMaster. Perhaps someone would like to talk a little
> more about that as well?
Just checked on Usogres, and it appears to be relatively up to date, in
that it is known to work up to 7.2.1:
http://usogres.good-day.net/working.php3
Searching Google for QueryMaster finds a few Japanese sites, but I can't
read Japanese :(
Tatsuo, can you help?
Marc G. Fournier wrote: > Just checked on Usogres, and it appears to be relatively up to date, in > that it is known to work up to 7.2.1: > > http://usogres.good-day.net/working.php3 > > Searching Google for QueryMaster finds a few Japanese sites, but I can't > read Japanese :( > > Tatsuo, can you help? Use Altavista: http://world.altavista.com/ They have a Japense/English translation. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> > Glad to hear that. Usogres was developed in Japan and pretty popular > > ammong Japanese PostgreSQL community. > > > > BTW, there is a commercial product called QueryMaster, which takes > > similar approach to Usogres. It copies the input query and distribute > > to multiple PostgreSQL servers. As long as one of a server is working, > > users even do not notice some of them are failing. > > How come these solutions are such well kept secrets? I've heard of > neither in relation to past discussions about replication, or have I just > missed them? :( As far as I can remember, Usogres has appeared on this list for several times. About QueryMaster: it is born in US and is a fairly new product. Unfortunately I couldn't find web pages for it. I'll talk to a person who is selling it in Japan if he could provide info in English... -- Tatsuo Ishii
On Tue, Dec 17, 2002 at 07:43:05PM -0600, Greg Copeland wrote: > On Tue, 2002-12-17 at 19:38, Marc G. Fournier wrote: > > How come these solutions are such well kept secrets? I've heard of > > neither in relation to past discussions about replication, or have I just > > missed them? :( > > Good questions. I've heard of Usogres, more or less in passing, but > heard it didn't work very well. I'm sure this is because there little or no documentation of the system in english. I tried Usogres sometime ago, and felt really lost. I managed to install it and maybe even got it to work, but the documentation was so lacking that I didn't feel confident enough with it. I think the same can be said of QueryMaster, plus it isn't mentioned anywhere. How can I possibly search for documentation on a project if I don't know it even exists? One would be tempted to say that GBorg is a good place to list PostgreSQL related projects. Sadly, GBorg doesn't even have a connection to the outside world. What value does it have if people don't know it exists, or can't remember how to get to it? Let alone use it to find a project... -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "Now I have my system running, not a byte was off the shelf; It rarely breaks and when it does I fix the code myself. It's stable, clean and elegant, and lightning fast as well, And it doesn't cost a nickel, so Bill Gates can go to hell."
On Wed, 18 Dec 2002, Tatsuo Ishii wrote: > > > Glad to hear that. Usogres was developed in Japan and pretty popular > > > ammong Japanese PostgreSQL community. > > > > > > BTW, there is a commercial product called QueryMaster, which takes > > > similar approach to Usogres. It copies the input query and distribute > > > to multiple PostgreSQL servers. As long as one of a server is working, > > > users even do not notice some of them are failing. > > > > How come these solutions are such well kept secrets? I've heard of > > neither in relation to past discussions about replication, or have I just > > missed them? :( > > As far as I can remember, Usogres has appeared on this list for > several times. > > About QueryMaster: it is born in US and is a fairly new > product. Unfortunately I couldn't find web pages for it. I'll talk to > a person who is selling it in Japan if he could provide info in > English... *rofl* I like that ... a US product, but all the pdf's and docs I can find on it are in Japanese ... I think its almost time to learn a third language :)
On Tue, 2002-12-17 at 20:07, Alvaro Herrera wrote: > On Tue, Dec 17, 2002 at 07:43:05PM -0600, Greg Copeland wrote: > > On Tue, 2002-12-17 at 19:38, Marc G. Fournier wrote: > > > > How come these solutions are such well kept secrets? I've heard of > > > neither in relation to past discussions about replication, or have I just > > > missed them? :( > > > > Good questions. I've heard of Usogres, more or less in passing, but > > heard it didn't work very well. > > I'm sure this is because there little or no documentation of the system > in english. I tried Usogres sometime ago, and felt really lost. I > managed to install it and maybe even got it to work, but the > documentation was so lacking that I didn't feel confident enough with > it. > > I think the same can be said of QueryMaster, plus it isn't mentioned > anywhere. How can I possibly search for documentation on a project if I > don't know it even exists? > > One would be tempted to say that GBorg is a good place to list > PostgreSQL related projects. Sadly, GBorg doesn't even have a > connection to the outside world. What value does it have if people > don't know it exists, or can't remember how to get to it? Let alone use > it to find a project... There are a couple of links to it from PostgreSQL's site, but you sorta have to look and hunt around. I've requested higher visibility but for whatever reason it seemed to be snubbed rather quickly. I do agree, GBorg needs MUCH higher visibility! -- Greg Copeland <greg@copelandconsulting.net> Copeland Computer Consulting
On Tue, 17 Dec 2002, Greg Copeland wrote: > There are a couple of links to it from PostgreSQL's site, but you sorta > have to look and hunt around. I've requested higher visibility but for > whatever reason it seemed to be snubbed rather quickly. > > I do agree, GBorg needs MUCH higher visibility! Dave is pretty much ready to put teh portal in place (http://wwwdevel.postgresql.org) which has several links to GBorg right off the main page ...
> There are a couple of links to it from PostgreSQL's site, but you sorta > have to look and hunt around. I've requested higher visibility but for > whatever reason it seemed to be snubbed rather quickly. > > I do agree, GBorg needs MUCH higher visibility! Yes - I would love to move phpPgAdmin back to GBorg to attract some actual interested developers, but I'm not sure it would... Chris
On Tue, 2002-12-17 at 21:33, Greg Copeland wrote: > I do agree, GBorg needs MUCH higher visibility! I'm just curious: why do we need GBorg at all? Does it offer anything that SourceForge, or a similar service does not offer? Especially given that (a) most other OSS projects don't have a site for "related projects" (unless you count something like CPAN, which is totally different) (b) GBorg is completely unknown to anyone outside the PostgreSQL community and even to many people within it... Cheers, Neil -- Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
Neil Conway wrote: > On Tue, 2002-12-17 at 21:33, Greg Copeland wrote: > > I do agree, GBorg needs MUCH higher visibility! > > I'm just curious: why do we need GBorg at all? Does it offer anything > that SourceForge, or a similar service does not offer? > > Especially given that (a) most other OSS projects don't have a site for > "related projects" (unless you count something like CPAN, which is > totally different) (b) GBorg is completely unknown to anyone outside the > PostgreSQL community and even to many people within it... I think gborg allows us to collect all relivant projects in one place. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Tue, 2002-12-17 at 22:00, Bruce Momjian wrote: > I think gborg allows us to collect all relivant projects in one place. Yes, but so would a webpage with a list of URLs, or a freshmeat/google/dmoz directory, or an SF foundry, or [ any number of other mechanisms for collecting groups of related websites ]. (Not to mention that you're assuming that GBorg includes "all relevant projects" -- it doesn't do that now, nor is it likely to in the future.) Cheers, Neil -- Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
On Tue, 2002-12-17 at 20:55, Neil Conway wrote: > On Tue, 2002-12-17 at 21:33, Greg Copeland wrote: > > I do agree, GBorg needs MUCH higher visibility! > > I'm just curious: why do we need GBorg at all? Does it offer anything > that SourceForge, or a similar service does not offer? > > Especially given that (a) most other OSS projects don't have a site for > "related projects" (unless you count something like CPAN, which is > totally different) (b) GBorg is completely unknown to anyone outside the > PostgreSQL community and even to many people within it... > Part I can answer, part I can not. Since I'm not the one that pushed the projects to that site, I can't answer that part of the equation. Addressing the part of your question that I think I can, I do like the concept of one-stop-shopping for all PostgreSQL needs. All Things ProgreSQL is a pretty neat concept. Of course, it rather defeats the whole purpose if no one, including potential developers, have no idea it exists. -- Greg Copeland <greg@copelandconsulting.net> Copeland Computer Consulting
Neil Conway wrote: > On Tue, 2002-12-17 at 22:00, Bruce Momjian wrote: > > I think gborg allows us to collect all relivant projects in one place. > > Yes, but so would a webpage with a list of URLs, or a > freshmeat/google/dmoz directory, or an SF foundry, or [ any number of > other mechanisms for collecting groups of related websites ]. > > (Not to mention that you're assuming that GBorg includes "all relevant > projects" -- it doesn't do that now, nor is it likely to in the future.) Good point. I put my stuff on there because it was PostgreSQL-specific, and it had nice features. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
The reason I favour a GBorg is that VA Linux (who own sourceforge) have yet to turn in a profit and so maylook to trim some of it's assets in order to improve profitability at some point in the future. I think it would be a bad move to shift everything to sourceforge, only to find that a year or more down the line the site dissappears/degrades to a level where it causes problems for the project, and loose the time we could have spent building up the reputation of GBorg. Al. ----- Original Message ----- From: "Neil Conway" <neilc@samurai.com> To: "Greg Copeland" <greg@CopelandConsulting.Net> Cc: "Alvaro Herrera" <alvherre@dcc.uchile.cl>; "Marc G. Fournier" <scrappy@hub.org>; "Tatsuo Ishii" <t-ishii@sra.co.jp>; <raanders@acm.org>; "PostgresSQL Hackers Mailing List" <pgsql-hackers@postgresql.org> Sent: Wednesday, December 18, 2002 2:55 AM Subject: [mail] Re: [HACKERS] Update on replication > On Tue, 2002-12-17 at 21:33, Greg Copeland wrote: > > I do agree, GBorg needs MUCH higher visibility! > > I'm just curious: why do we need GBorg at all? Does it offer anything > that SourceForge, or a similar service does not offer? > > Especially given that (a) most other OSS projects don't have a site for > "related projects" (unless you count something like CPAN, which is > totally different) (b) GBorg is completely unknown to anyone outside the > PostgreSQL community and even to many people within it... > > Cheers, > > Neil > -- > Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster >
> I'm just curious: why do we need GBorg at all? Does it offer anything > that SourceForge, or a similar service does not offer? SAY NO TO SOURCEFORGE ! Please find enclosed some extracts from licensing terms (http://sourceforge.net/tos/tos.php) : a) Acceptance of Terms "We reserve the right, at our discretion, to change, modify, add or remove portions of these terms periodically. Such modifications shall be effective immediately upon posting of the modified agreement to the website. Your continued use of the SourceForge.net website following the posting of changes to these terms and conditions will mean that you accept those changes." -> My point of view : SourceForge has an unlimited right to change the content of the TOS. A simpe post of the modified TOS is sufficient. For example, they may at any time charge access to their web site. b) Licensing of code "In each such case, the submitting user grants SourceForge.net the royalty-free, perpetual, irrevocable, non-exclusive and fully sublicensable right and license to use, reproduce, modify, adapt, publish, translate, create derivative works from, distribute, perform and display such Content (in whole or part) worldwide and/or to incorporate it in other works in any form, media, or technology now known or later developed, all subject to the terms of any applicable approved license." -> My point of view : More surprisingly, SourceForge owns all content posted on SourceForge. For legal reasons, SF licensing agreement is subject to the terms of any applicable approved license. But, the words *** or later development *** are thrilling. c) Termination "We may terminate a user's account in our absolute discretion and for any reason. We are especially likely to terminate for reasons that include, but are not limited to, the following: 1.) violation of these Terms; 2.) abuse of site resources or attempt to gain unauthorized entry to the site or site resources; 3.) use of Service in a manner inconsistent with the Purpose; 4.) a user's request for such termination; and 5.) requirement of applicable law, regulation, court or governing agency order. -> My point of view : As a consequence, SourceForge does not allow a user to unregister from SourceForge. I tried to unregister a project from SF, without success. Why? Because SF owns the (your) project rights. d) Incompatibility with local european laws This contract does not comply with the European laws : - SF may change the licensing terms at any time, without limitation of the future modified clauses. In the European Union, you cannot grant an ***unlimited right*** on your ***future and undefined*** work without a ***defined counterpart*** (example=a salary). - In French law, an author right is devided in two separate rights : the owner right and the moral right. Every author (or community of authors) owns a moral right on his/her work, even after the selling of rights. It has several consequences which I wron't bother you with (even in RedHat attitude = the renaming of a software is unmoral, bacause it makes you believe RedHat is the original author of PostgreSQL). e) SourceForge is a closed-source service SourceForge migrated (=rewrote) their database server-side code from PostgreSQL to Oracle, mainly for legal reasond. This new work gives them the ability to change licences. As a consequence, SF did not release their code for a year or so. SF can now be considered as a closed-source service. f) I would discourage anyone from registering on SourceForge. Any organization is meant to be created, to live ... and die. Microsoft, Oracle and SourceForge will probably die sooner or later. On the other hand, open-source project provider, like Savannah or better GBOrg, which are owned by non-profit organization or individuals releasing their source code under the GNU, will never die. This make a huge difference. Now, what if Microsoft purchased OSDN? What would be the consequences? Cheers, Jean-Michel
Jean-Michel POURE <jm.poure@freesurf.fr> writes: > a) Acceptance of Terms > > "We reserve the right, at our discretion, to change, modify, add or remove > portions of these terms periodically. Such modifications shall be effective > immediately upon posting of the modified agreement to the website. Your > continued use of the SourceForge.net website following the posting of changes > to these terms and conditions will mean that you accept those changes." > > -> My point of view : SourceForge has an unlimited right to change the content > of the TOS. A simpe post of the modified TOS is sufficient. For example, they > may at any time charge access to their web site. This is standard legalities. They are a corporate entity; if there is a gap that leaves them liable for someone else's actions, they have to either be able to update their TOS -- or they must stop providing the service. > b) Licensing of code > > "In each such case, the submitting user grants SourceForge.net the > royalty-free, perpetual, irrevocable, non-exclusive and fully sublicensable > right and license to use, reproduce, modify, adapt, publish, translate, > create derivative works from, distribute, perform and display such Content > (in whole or part) worldwide and/or to incorporate it in other works in any > form, media, or technology now known or later developed, all subject to the > terms of any applicable approved license." > > -> My point of view : More surprisingly, SourceForge owns all content posted > on SourceForge. For legal reasons, SF licensing agreement is subject to the > terms of any applicable approved license. But, the words *** or later > development *** are thrilling. That is simply their legal way of saying "You may only publish 'open source' software and content on SourceForge" -- which is made clear when you sign up for a new project anyway. If you want them to distribute your software over the Internet, why do you care if they later distribute it over Planetnet? (The "in any ... technology ... later developed" does not scare me.) You must choose which license to use; if you do not want to use any of the approved licenses, *then* you might not want to use SourceForge. > c) Termination > > "We may terminate a user's account in our absolute discretion and for any > reason. We are especially likely to terminate for reasons that include, but > are not limited to, the following: 1.) violation of these Terms; 2.) abuse of > site resources or attempt to gain unauthorized entry to the site or site > resources; 3.) use of Service in a manner inconsistent with the Purpose; 4.) > a user's request for such termination; and 5.) requirement of applicable law, > regulation, court or governing agency order. > > -> My point of view : As a consequence, SourceForge does not allow a user to > unregister from SourceForge. I tried to unregister a project from SF, without > success. Why? Because SF owns the (your) project rights. Your project has nothing to do with their ability to terminate accounts. When I tried to unregister a project from SF, it took months, but they eventually did it. Maybe it helped that we were just renaming the project to something else on SF and had already moved the CVS tree. > d) Incompatibility with local european laws > > This contract does not comply with the European laws : > > - SF may change the licensing terms at any time, without limitation of the > future modified clauses. In the European Union, you cannot grant an > ***unlimited right*** on your ***future and undefined*** work without a > ***defined counterpart*** (example=a salary). Where does it say SF may change the licensing terms? If you do not want them to change the licensing terms much, you can do something like using GPL instead of BSD. Neither do they claim any right at all on your future work, unless you send those works to them -- "Licensing of code" merely says that once you send them something, they have an unlimited right to use and redistribute it. > - In French law, an author right is devided in two separate rights : the owner > right and the moral right. Every author (or community of authors) owns a > moral right on his/her work, even after the selling of rights. It has several > consequences which I wron't bother you with (even in RedHat attitude = the > renaming of a software is unmoral, bacause it makes you believe RedHat is the > original author of PostgreSQL). This is partially a license issue, and partially an international law issue, but it has little bearing on whether one uses SourceForge or not; *any* user of the code can exercise the same rights. You say below that you prefer Savannah over SourceForge, but Savannah does little enough to acknowledge that their code is based on SourceForge's code. Why criticize RedHat for doing the same thing? > e) SourceForge is a closed-source service > > SourceForge migrated (=rewrote) their database server-side code from > PostgreSQL to Oracle, mainly for legal reasond. This new work gives them the > ability to change licences. > > As a consequence, SF did not release their code for a year or so. SF can now > be considered as a closed-source service. Last time I checked, SourceForge 2.5 and before were still GPLed, and some people do work to maintain it. However, use of a service is different than licensing software. Google is closed source -- do you refuse to use the services they provide? > f) I would discourage anyone from registering on SourceForge. Any organization > is meant to be created, to live ... and die. Microsoft, Oracle and > SourceForge will probably die sooner or later. Microsoft, Oracle, SourceForge, and the FSF can all die, yes. > On the other hand, open-source project provider, like Savannah or better > GBOrg, which are owned by non-profit organization or individuals releasing > their source code under the GNU, will never die. This make a huge difference. Why not? People get hit by busses. Organizations lose favor, or run low on funding, and eventually go away too. Licensing and wide distribution of the code is what guarantees it will never die, not the mass distributor(s). > Now, what if Microsoft purchased OSDN? What would be the consequences? What if Microsoft hired all of the Postgres committers? (Empty questions can be easily turned around, so it is better to be specific in your concerns.) Michael Poole