Thread: New News Entry
A new entry has been added to the news database. Database Admin: http://www.postgresql.org/admin/edit_news.php?201 Submitted by: justin@postgresql.org Headline: 3rd Beta of PostgreSQL Master -> Multi-slave replication system Summary: <a href=\"http://gborg.postgresql.org/project/slony1/projdisplay.php\">Slony 1</a>, the successor to the eRServer replicationproject used for hosting the .org and .info domain names has entered it\'s third beta testing phase. Target release date is 1st July 2004. Story: <a href=\"http://www.slony.org\">Slony 1</a>, the successor to the eRServer Replication project used for hosting the .organd .info domain name registries, has entered it\'s third beta testing phase. <a href=\"http://www.slony.org\">http://www.slony.org</a> Slony 1 is designed for high volume sites and has been masterminded by Jan Wieck, a member of the PostgreSQL Core Team. It is a working, advanced Master to Multi-Slave replication system written in C, works with PostgreSQL 7.3 and 7.4, and isBSD licenced. Due for production release on 1st July 2004, Slony 1 has just entered it\'s third beta phase and is very well worth checkingout by those with an interest in PostgreSQL replication. More testers and contributors are welcome of course! Changes from beta 2 are: <ul> <li>Fixed broken \"make distclean\" target (<a href=\"http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?825\">bug825</a>). <li>Added several HOWTO documents. <li>Added a polling interval to the remote listener code so that reset connections get detected and the slave reconnectsafter network outages. <li>Performance enhancements by replacing the possibly huge IN transactionId query parts with custom C functions. <li>Performance enhancement through grouping of multiple replication queries into one PQexec() call. <li>Fixed a flex scanner problem causing slonik coredumps on larger input files. </ul>
People: > Submitted by: justin@postgresql.org > Headline: 3rd Beta of PostgreSQL Master -> Multi-slave replication system > Summary: I'd like to veto this. We don't need a blow-by-blow on the main news page for each incremental step in Slony development. -- Josh Berkus Aglio Database Solutions San Francisco
Dear Josh Berkus , >>Submitted by: justin@postgresql.org >>Headline: 3rd Beta of PostgreSQL Master -> Multi-slave replication system >>Summary: >> >> > >I'd like to veto this. We don't need a blow-by-blow on the main news page >for each incremental step in Slony development. > > If it was a simple shell scrpit for blah blah then your veto is justified but since Slony is addresing a much needed feature exceptions can be made. Lets see what others say ? -- Regards, Vishal Kashyap Director / Lead Software Developer, Sai Hertz And Control Systems Pvt Ltd, http://saihertz.rediffblogs.com Yahoo IM: mailforvishal[ a t ]yahoo.com
World Wide Web Owner wrote: > <a > href=\"http://gborg.postgresql.org/project/slony1/projdisplay.php\">S >lony 1</a>, the successor to the eRServer replication project used for > hosting the .org and .info domain names has entered it\'s third beta > testing phase. The spelling is "Slony-I".
I've started to reject posts to -announce about it as well ... On Thu, 17 Jun 2004, Josh Berkus wrote: > People: > >> Submitted by: justin@postgresql.org >> Headline: 3rd Beta of PostgreSQL Master -> Multi-slave replication system >> Summary: > > I'd like to veto this. We don't need a blow-by-blow on the main news page > for each incremental step in Slony development. > > -- > Josh Berkus > Aglio Database Solutions > San Francisco > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Thu, 17 Jun 2004, V i s h a l Kashyap @ [Sai Hertz And Control Systems] wrote: > Dear Josh Berkus , > >>> Submitted by: justin@postgresql.org >>> Headline: 3rd Beta of PostgreSQL Master -> Multi-slave replication >>> system >>> Summary: >>> >> >> I'd like to veto this. We don't need a blow-by-blow on the main news >> page for each incremental step in Slony development. >> > If it was a simple shell scrpit for blah blah then your veto is justified but > since Slony is addresing a much needed > feature exceptions can be made. > > Lets see what others say ? If we approve the blow-by-blow of development for a single project, the only news left on the web site will be for Slony-I ... beta software, IMHO, doesn't belong on the news section (and that includes when PostgreSQL itself goes beta) ... a release is news, not development stages ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: <snip> > If we approve the blow-by-blow of development for a single project, the > only news left on the web site will be for Slony-I ... beta software, > IMHO, doesn't belong on the news section (and that includes when > PostgreSQL itself goes beta) ... a release is news, not development > stages ... Sure, but it was a beta2 release last week, and now it's in beta3 and its due for proper "release" soon. I'm trying to get it as widely tested as possible before 1.0.0 release of course. Instead of leaving the beta2 blurb there, it's been removed and replaced with a beta3 one as that's more accurate. Hope that makes sense. :) Regards and best wishes, Justin Clift > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
Peter Eisentraut wrote: <snip> > The spelling is "Slony-I". Thanks Peter. Now fixed. :) + Justin > > ---------------------------(end of broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match
On Fri, 18 Jun 2004, Justin Clift wrote: > Marc G. Fournier wrote: > <snip> >> If we approve the blow-by-blow of development for a single project, the >> only news left on the web site will be for Slony-I ... beta software, >> IMHO, doesn't belong on the news section (and that includes when >> PostgreSQL itself goes beta) ... a release is news, not development stages >> ... > > Sure, but it was a beta2 release last week, and now it's in beta3 and its due > for proper "release" soon. I'm trying to get it as widely tested as possible > before 1.0.0 release of course. > > Instead of leaving the beta2 blurb there, it's been removed and replaced with > a beta3 one as that's more accurate. > > Hope that makes sense. :) As long as that is the new policy for the News section, makes perfect sense to me ... but that means that software announce related to PostgreSQL now has to be approved, regardless of its development state ... We should post that policy somewhere, make sure that both open source and commercial companies are aware of the change ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: <snip> > We should post that policy somewhere, make sure that both open source > and commercial companies are aware of the change ... ;-) Errr, I wasn't aware of a solid policy, so I've just been playing it by ear. So to speak. :) Regards and best wishes, Justin Clift > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Fri, 18 Jun 2004, Justin Clift wrote: > Marc G. Fournier wrote: > <snip> >> We should post that policy somewhere, make sure that both open source and >> commercial companies are aware of the change ... > > ;-) > > Errr, I wasn't aware of a solid policy, so I've just been playing it by > ear. So to speak. :) Well, I think its only fair that if we are going to consider every little development milestone news for one project, other projects should be given the exact same consideration ... its not like there aren't a half dozen other replication solutions out there ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Folks,
My personal opinion on policy:
For software (or hardware) which is not PostgreSQL community, but is "useful"
or "newsy" as we define it, we announce it when it either
1) goes production for the first time,
2) supports postgresql for the first time
and never post news about that particular piece of software again unless
there's a compelling reason to make an exception.
For software which is PostgreSQL community, we allow announcements when it:
1) is created as a project;
2) first goes beta (if it needs testers);
3) first goes production;
4) achieves a major (e.g. 2.0) version milestone
but leave it up to the project admin what they want to try and post.
agreement/disagreement/rude noises?
I simply can't see any circumstance under which we would want to post
individual beta releases on the main page. Heck, we don't do that for
PostgreSQL itself ... one beta or RC version, and that's it.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
On Fri, 18 Jun 2004, Josh Berkus wrote: > Folks, > > My personal opinion on policy: > > For software (or hardware) which is not PostgreSQL community, but is "useful" > or "newsy" as we define it, we announce it when it either > 1) goes production for the first time, > 2) supports postgresql for the first time > and never post news about that particular piece of software again unless > there's a compelling reason to make an exception. I'd extend 2 to include major version releases ... > For software which is PostgreSQL community, we allow announcements when it: > 1) is created as a project; > 2) first goes beta (if it needs testers); > 3) first goes production; > 4) achieves a major (e.g. 2.0) version milestone Sounds reasonable to me ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc, > > For software (or hardware) which is not PostgreSQL community, but is "useful" > I'd extend 2 to include major version releases ... I wouldn't. Keep in mind that this includes a lot of commercial software. EMS Hitech, for example, seems to have a "major version release" every week. -- -Josh Berkus Aglio Database Solutions San Francisco
On Fri, 18 Jun 2004, Josh Berkus wrote: > Marc, > >>> For software (or hardware) which is not PostgreSQL community, but is > "useful" >> I'd extend 2 to include major version releases ... > > I wouldn't. Keep in mind that this includes a lot of commercial software. > EMS Hitech, for example, seems to have a "major version release" every week. Use discretion? My big beef was that it was almost getting to the point that when Jan scratched his butt, a news item was going up for it ... Slony going Beta is news worthy .. Slony being released is news worthy ... Slony going into its 3rd Beta is not news worth ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
"Marc G. Fournier" <scrappy@postgresql.org> writes:
> On Fri, 18 Jun 2004, Josh Berkus wrote:
>>> I'd extend 2 to include major version releases ...
>>
>> I wouldn't. Keep in mind that this includes a lot of commercial software.
>> EMS Hitech, for example, seems to have a "major version release" every week.
> Use discretion?
I think Josh is trying to minimize the amount of discretion needed,
so that whoever makes these calls can't be accused of favoritism.
Personally I think it's reasonable to have some guidelines, not
hard rules. In this case maybe we could suggest a time constraint:
"major release" announcements are ok if they're at least a year apart.
(Or six months, or whatever we feel is appropriate.)
regards, tom lane
On Fri, 18 Jun 2004, Tom Lane wrote: > "Marc G. Fournier" <scrappy@postgresql.org> writes: >> On Fri, 18 Jun 2004, Josh Berkus wrote: >>>> I'd extend 2 to include major version releases ... >>> >>> I wouldn't. Keep in mind that this includes a lot of commercial software. >>> EMS Hitech, for example, seems to have a "major version release" every week. > >> Use discretion? > > I think Josh is trying to minimize the amount of discretion needed, > so that whoever makes these calls can't be accused of favoritism. > > Personally I think it's reasonable to have some guidelines, not > hard rules. In this case maybe we could suggest a time constraint: > "major release" announcements are ok if they're at least a year apart. > (Or six months, or whatever we feel is appropriate.) I think EMS Hitech is an extreme case ... but, if I recall right, weren't they doing an announce per minor release? ie. 1.1.1 v 1.1.2? But, I do agree about the time constraints ... maybe throw in a 'past track record' also? for instance, we release 7.5.0, and it will generally be ~1 month before 7.5.1 comes out, but it may be 3 before 7.5.2 does ... in our case, we might have a short time between minors right after a major release, but we also don't send out a minor release just cause we happen to have backpatched a single feature ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > On Fri, 18 Jun 2004, Tom Lane wrote: > > > "Marc G. Fournier" <scrappy@postgresql.org> writes: > >> On Fri, 18 Jun 2004, Josh Berkus wrote: > >>>> I'd extend 2 to include major version releases ... > >>> > >>> I wouldn't. Keep in mind that this includes a lot of commercial software. > >>> EMS Hitech, for example, seems to have a "major version release" every week. > > > >> Use discretion? > > > > I think Josh is trying to minimize the amount of discretion needed, > > so that whoever makes these calls can't be accused of favoritism. > > > > Personally I think it's reasonable to have some guidelines, not > > hard rules. In this case maybe we could suggest a time constraint: > > "major release" announcements are ok if they're at least a year apart. > > (Or six months, or whatever we feel is appropriate.) > > I think EMS Hitech is an extreme case ... but, if I recall right, weren't > they doing an announce per minor release? ie. 1.1.1 v 1.1.2? > > But, I do agree about the time constraints ... maybe throw in a 'past > track record' also? for instance, we release 7.5.0, and it will generally > be ~1 month before 7.5.1 comes out, but it may be 3 before 7.5.2 does ... > in our case, we might have a short time between minors right after a major > release, but we also don't send out a minor release just cause we happen > to have backpatched a single feature ... Just have Jan scratch his butt right before we release, and we can piggyback on that announcement. :-) -- 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, Pennsylvania 19073
Tom, > > Personally I think it's reasonable to have some guidelines, not > > hard rules. In this case maybe we could suggest a time constraint: > > "major release" announcements are ok if they're at least a year apart. > > (Or six months, or whatever we feel is appropriate.) Absolutely. The reason why I brought it up is that it's apparent that not everyone on this list, even, agrees what the guidelines ought to be. We need a consensus. > But, I do agree about the time constraints ... maybe throw in a 'past > track record' also? Well, that's where we make exceptions, sometimes. For example, if OpenACS sent us an announcement that wasn't a major release, we might put it up anyway -- becuase they're very friendly to postgres, they're OSS, and they have yet to post an announcement of any kind. Bricolage, on the other hand, we'd stick to the "rules"; David sends me an announcement every patch release. for instance, we release 7.5.0, and it will generally > be ~1 month before 7.5.1 comes out, but it may be 3 before 7.5.2 does ... Oh, for the PostgreSQL project we post whatever we want. It *is* the postgresql.org web site, after all. -- Josh Berkus Aglio Database Solutions San Francisco