Обсуждение: Alpha 1 for 9.2
Hi, Is there a plan to wrap up 9.2 Alpha 1 before the next commitfest? Regards, -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
Devrim G�ND�Z wrote: > Is there a plan to wrap up 9.2 Alpha 1 before the next commitfest? We talked about it on core and no one seems interested in doing the packaging. :-( -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Tue, 2011-09-06 at 10:06 -0400, Bruce Momjian wrote: > > Devrim GNDZ wrote: > > Is there a plan to wrap up 9.2 Alpha 1 before the next commitfest? > > We talked about it on core and no one seems interested in doing the > packaging. :-( Oh, what if noone will be interested in packaging until the last commitfest? We need people to start testing features, without having to use git or such. -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
2011/9/6 Bruce Momjian <bruce@momjian.us>: > Devrim GÜNDÜZ wrote: >> Is there a plan to wrap up 9.2 Alpha 1 before the next commitfest? > > We talked about it on core and no one seems interested in doing the > packaging. :-( Well I don't particularly mind pushing a tag and bundling it, but I guess the question is whether we actually want to do alpha releases at all. I assume that core's reluctance to do this stems from being dubious about its value, which seems like something that we should discuss more broadly. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas wrote: > 2011/9/6 Bruce Momjian <bruce@momjian.us>: > > Devrim G?ND?Z wrote: > >> Is there a plan to wrap up 9.2 Alpha 1 before the next commitfest? > > > > We talked about it on core and no one seems interested in doing the > > packaging. ?:-( > > Well I don't particularly mind pushing a tag and bundling it, but I > guess the question is whether we actually want to do alpha releases at > all. I assume that core's reluctance to do this stems from being > dubious about its value, which seems like something that we should > discuss more broadly. Yes, it has always been a time vs. value question. I am not sure how I feel on the matter but I am away too often to help anyway. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
> Yes, it has always been a time vs. value question. I am not sure how I > feel on the matter but I am away too often to help anyway. I think the alphas have been extremely valuable for testing. And with some of the stuff going into CF1 and CF2 for 9.2, we really need some early testing. Or, to put it another way: if we don't release an Alpha2, then we're going to need to do a packaged alpha with Haas's performance patches anyway. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On tis, 2011-09-06 at 17:25 +0300, Devrim GÜNDÜZ wrote: > Oh, what if noone will be interested in packaging until the last > commitfest? Then nothing will happen. > We need people to start testing features, without having to use git or > such. You can download daily snapshot tarballs.
On tis, 2011-09-06 at 13:38 -0400, Robert Haas wrote: > 2011/9/6 Bruce Momjian <bruce@momjian.us>: > > Devrim GÜNDÜZ wrote: > >> Is there a plan to wrap up 9.2 Alpha 1 before the next commitfest? > > > > We talked about it on core and no one seems interested in doing the > > packaging. :-( > > Well I don't particularly mind pushing a tag and bundling it, but I > guess the question is whether we actually want to do alpha releases at > all. I assume that core's reluctance to do this stems from being > dubious about its value, which seems like something that we should > discuss more broadly. One point, which was already raised last year around this time, was that it does seem weird to have alphas for release N+1 while beta for release N is still going on. This year the start of N+1 was even earlier than last year.
On tis, 2011-09-06 at 11:41 -0700, Josh Berkus wrote: > I think the alphas have been extremely valuable for testing. That's not my recollection. Obviously, it's hard to measure this one way or the other, but I don't recall there being a lot of test reports from people who are not already contributors and could have used some other way to get the code.
> That's not my recollection. Obviously, it's hard to measure this one > way or the other, but I don't recall there being a lot of test > reports > from people who are not already contributors and could have used some > other way to get the code. Do we have download stats for the alphas? Dave? --Josh
On 09/10/2011 02:52 PM, Peter Eisentraut wrote: > On tis, 2011-09-06 at 11:41 -0700, Josh Berkus wrote: >> I think the alphas have been extremely valuable for testing. > > That's not my recollection. Obviously, it's hard to measure this one > way or the other, but I don't recall there being a lot of test reports > from people who are not already contributors and could have used some > other way to get the code. > > As a tester, I'll pull from git. I like a quick update from git pull. When I'm playing with patches, its a simple: git reset --hard patch < ... I can't speak for others, but I find no benefit from a packaged alpha release. -Andy
<br /><br />On Saturday, September 10, 2011, Joshua Berkus <<a href="mailto:josh@agliodbs.com">josh@agliodbs.com</a>>wrote:<br />><br />>> That's not my recollection. Obviously,it's hard to measure this one<br /> >> way or the other, but I don't recall there being a lot of test<br/>>> reports<br />>> from people who are not already contributors and could have used some<br />>>other way to get the code.<br />><br /> > Do we have download stats for the alphas? Dave?<br /><br />Downloadnumbers for the installers were bordering on noise compared to the GA builds last time I looked, double figuresiirc. I don't know about the tarballs offhand and can't check ATM.<br /><br />-- <br />Dave Page<br />Blog: <a href="http://pgsnake.blogspot.com"target="_blank">http://pgsnake.blogspot.com</a><br />Twitter: @pgsnake<br /><br />EnterpriseDBUK: <a href="http://www.enterprisedb.com" target="_blank">http://www.enterprisedb.com</a><br /> The EnterprisePostgreSQL Company<br /><br />
On Sat, Sep 10, 2011 at 22:52, Peter Eisentraut <peter_e@gmx.net> wrote: > but I don't recall there being a lot of test reports > from people who are not already contributors and could have used some > other way to get the code. I, for one, do use alpha tarballs on my dev machines (when working on apps that use PostgreSQL). It gives me a concrete schedule to update them that's not too frequent and I can tell whether they need updating just by glancing at the version string. If I was using git, I'd probably have some machines lagging hopelessly behind and always confused about which version is which. I also maintain an Arch Linux community package for testing versions, that has at least one other user: https://aur.archlinux.org/packages.php?ID=31562 But it's probably not worth releasing alphas for us two alone. :) Regards, Marti
Peter Eisentraut <peter_e@gmx.net> writes:
> On tis, 2011-09-06 at 11:41 -0700, Josh Berkus wrote:
>> I think the alphas have been extremely valuable for testing.
> That's not my recollection. Obviously, it's hard to measure this one
> way or the other, but I don't recall there being a lot of test reports
> from people who are not already contributors and could have used some
> other way to get the code.
Presumably the people an alpha release would serve are those who aren't
in a position to build the code from source; since those who are can use
a nightly snapshot or just build from a git pull. So the question is
how big an audience is interested in testing alpha-grade code but do not
have build infrastructure. I would agree that that's a small fraction
on the Unix side of the fence, but I'm a lot less convinced that there's
no market for it among Windows users.
Of course, this means that just building a source tarball marked
"alpha1" isn't real useful. If we're going to do alpha releases, we
have to have buy-in from packagers (or at least from the Windows
installer team) to do follow-on package wrapping.
Josh asked about what was the download count for the alpha installers.
I don't think that's a relevant statistic; the number of people willing
to test alphas is certainly going to be small. What matters is the
value of test reports we get back from them. I'm not sure that we have
that information; people may specify that they're testing alphaN, but
they tend not to say whether they got an installer or built it
themselves.
regards, tom lane
> Download numbers for the installers were bordering on noise compared > to the GA builds last time I looked, double figures iirc. I don't > know about the tarballs offhand and can't check ATM. Can you check when you get a chance? I know that the DL numbers for the first alphas were very low, but I'm wondering aboutAlpha 3, 4 and 5. The main value of the alphas is that our Windows users aren't going to do any testing which requires source code compile. But if they're not doing any testing anyway, then there's no real point. There's PR value in doing the alphas, but not enough to justify the effort involved. If we're not going to do regular alphas, I would push to do one special alpha release which includes all of the locking codeimprovements and similar features added to date.
On lör, 2011-09-10 at 23:29 +0300, Marti Raudsepp wrote: > I, for one, do use alpha tarballs on my dev machines (when working on > apps that use PostgreSQL). It gives me a concrete schedule to update > them that's not too frequent and I can tell whether they need updating > just by glancing at the version string. > > If I was using git, I'd probably have some machines lagging hopelessly > behind and always confused about which version is which. Well, that's another point. If you're doing constant testing, do we really want you testing code that is several weeks old? If you discovered an issue, the first response would most likely be, upgrade to the latest state of development.
On lör, 2011-09-10 at 16:34 -0400, Tom Lane wrote: > Of course, this means that just building a source tarball marked > "alpha1" isn't real useful. If we're going to do alpha releases, we > have to have buy-in from packagers (or at least from the Windows > installer team) to do follow-on package wrapping. Yeah, and we aimed for that initially, but it didn't happen. And especially the Windows installers have the highest overhead of any of the packaging efforts, so it's unclear how to get them on board consistently.
On Tue, 2011-09-06 at 16:49 +0300, Devrim GÜNDÜZ wrote: > Is there a plan to wrap up 9.2 Alpha 1 before the next commitfest? <...> Ok, so if noone is willing to produce alpha's (which is sad), we need to change the text in here: http://www.postgresql.org/developer/alpha -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
On Sat, Sep 10, 2011 at 9:47 PM, Joshua Berkus <josh@agliodbs.com> wrote: > >> Download numbers for the installers were bordering on noise compared >> to the GA builds last time I looked, double figures iirc. I don't >> know about the tarballs offhand and can't check ATM. > > Can you check when you get a chance? I know that the DL numbers for the first alphas were very low, but I'm wonderingabout Alpha 3, 4 and 5. 186_www=# select count(*) from clickthrus where path like '%postgresql-9.1alpha1.tar.%' and ts >= '2009-09-01';count ------- 1431 (1 row) 186_www=# select count(*) from clickthrus where path like '%postgresql-9.1alpha2.tar.%' and ts >= '2009-09-01';count ------- 1335 (1 row) 186_www=# select count(*) from clickthrus where path like '%postgresql-9.1alpha3.tar.%' and ts >= '2009-09-01';count ------- 1127 (1 row) 186_www=# select count(*) from clickthrus where path like '%postgresql-9.1alpha4.tar.%' and ts >= '2009-09-01';count ------- 2011 (1 row) 186_www=# select count(*) from clickthrus where path like '%postgresql-9.1alpha5.tar.%' and ts >= '2009-09-01';count ------- 929 (1 row) and for comparison: 186_www=# select count(*) from clickthrus where path like '%postgresql-9.0.3.tar.%' and ts >= '2009-09-01';count -------26211 (1 row) 186_www=# select count(*) from clickthrus where path like '%postgresql-9.0.4.tar.%' and ts >= '2009-09-01';count -------34769 (1 row) Note that these are only numbers from people who click through the flags pages on the website. We don't have numbers for people who download directly from the FTP site or a mirror. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 9/12/11 2:23 AM, Dave Page wrote: > Note that these are only numbers from people who click through the > flags pages on the website. We don't have numbers for people who > download directly from the FTP site or a mirror. I'd say that 1200 downloads of each alpha is pretty significant. If even 1/4 of those people actually do testing, then that's a lot more than we had for 8.3. It's also a heck of a lot more than I'd expect. Sure, it's 5% of an update versions' downloads. So what? We don't expect most people do to alpha testing. But if *hundreds* of people are doing alpha testing, we want them to keep doing it. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Mon, Sep 12, 2011 at 5:23 AM, Dave Page <dpage@pgadmin.org> wrote: > On Sat, Sep 10, 2011 at 9:47 PM, Joshua Berkus <josh@agliodbs.com> wrote: >>> Download numbers for the installers were bordering on noise compared >>> to the GA builds last time I looked, double figures iirc. I don't >>> know about the tarballs offhand and can't check ATM. >> >> Can you check when you get a chance? I know that the DL numbers for the first alphas were very low, but I'm wonderingabout Alpha 3, 4 and 5. > > [ >1100 downloads for alphas1-3, >2000 downloads for alpha4, ~900 downloads for alpha5 ] Hmm, that seems pretty respectable, all things considered. Honestly, I'm not sure how to feel about this. As a practical matter, I suspect that the value of alphas early in the release cycle is limited. Most of the big ticket features that people are going to be interested in testing tend to arrive late in the release cycle. If you look at the 9.1 release notes, the first commit to implement any portion of a feature that made the "major features" list for the release was my commit to add SECURITY LABEL, which happened on September 27, 2010. As of the turn of the year, we had 2.5 of the 10 features that ultimately made that list in the tree. IMHO, we should be making a more concerted effort to get more of our major features done and committed sooner, but since we aren't, testing of early alphas seems likely to be a fairly unrewarding activity. Stability testing is likely going to be largely useless (because there will be lots more code churn just before feature freeze), and feature testing is going to be confined to the relatively limited amount of stuff that gets done and committed early. I certainly think there is value in pushing an alpha release after CF4, and maybe even after CF3. Whether or not it's worthwhile to do them for earlier CFs I'm less certain about, but there seem to be several people speaking up and saying that they like having alpha releases, and if the hold-up here is just that we need someone to tag and bundle, I'm certainly willing to sign on the dotted line for that much. We'd still need someone to write release notes, though, probably someone to arrange for the minimal amount of necessary PR work (announcements, etc.), and (somewhat optionally) packagers. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On mån, 2011-09-12 at 10:00 -0400, Robert Haas wrote: > I certainly think there is value in pushing an alpha release after > CF4, and maybe even after CF3. Yes, that makes sense. Although I was surprised to see that the download numbers dropped off significantly for the later alphas. > Whether or not it's worthwhile to do > them for earlier CFs I'm less certain about, but there seem to be > several people speaking up and saying that they like having alpha > releases, and if the hold-up here is just that we need someone to tag > and bundle, I'm certainly willing to sign on the dotted line for that > much. We'd still need someone to write release notes, though, Writing the release notes is really the main part of the work. Bundling the release takes 15 minutes, writing the announcement takes 15 minutes (copy and paste), writing the release notes takes about 2 days. > probably someone to arrange for the minimal amount of necessary PR > work (announcements, etc.), and (somewhat optionally) packagers. We've tried that in the past, and haven't had much impact.
On Mon, Sep 12, 2011 at 10:30 AM, Peter Eisentraut <peter_e@gmx.net> wrote: > On mån, 2011-09-12 at 10:00 -0400, Robert Haas wrote: >> I certainly think there is value in pushing an alpha release after >> CF4, and maybe even after CF3. > > Yes, that makes sense. Although I was surprised to see that the > download numbers dropped off significantly for the later alphas. IIUC, alpha4 got the most, I guess because that was the first one that was alleged to be feature-complete. alpha5 had the least, but that's probably because it was just a bunch of bug fixes over alpha4, but not enough to make the result beta-quality, thus less interesting. Also, I think that may have been the one we forgot to announce. >> Whether or not it's worthwhile to do >> them for earlier CFs I'm less certain about, but there seem to be >> several people speaking up and saying that they like having alpha >> releases, and if the hold-up here is just that we need someone to tag >> and bundle, I'm certainly willing to sign on the dotted line for that >> much. We'd still need someone to write release notes, though, > > Writing the release notes is really the main part of the work. Bundling > the release takes 15 minutes, writing the announcement takes 15 minutes > (copy and paste), writing the release notes takes about 2 days. Yep. So perhaps the question is whether anyone's willing to do that work. >> probably someone to arrange for the minimal amount of necessary PR >> work (announcements, etc.), and (somewhat optionally) packagers. > > We've tried that in the past, and haven't had much impact. I think we at least need to announce the releases. Packaging is optional, but it's nice if people are willing to do it, and I would assume most packagers have this fairly well automated. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
> Writing the release notes is really the main part of the work. Bundling > the release takes 15 minutes, writing the announcement takes 15 minutes > (copy and paste), writing the release notes takes about 2 days. Yeah, but this shaved a lot of effort/delay off doing the final release notes. Also, you could get more community help on the release notes if you wikified them the way you did the first time. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On mån, 2011-09-12 at 09:43 -0700, Josh Berkus wrote: > > Writing the release notes is really the main part of the work. Bundling > > the release takes 15 minutes, writing the announcement takes 15 minutes > > (copy and paste), writing the release notes takes about 2 days. > > Yeah, but this shaved a lot of effort/delay off doing the final release > notes. It did? AFAICT, the final release notes were created from scratch and the alpha release notes deleted.
Peter Eisentraut wrote: > On m?n, 2011-09-12 at 09:43 -0700, Josh Berkus wrote: > > > Writing the release notes is really the main part of the work. Bundling > > > the release takes 15 minutes, writing the announcement takes 15 minutes > > > (copy and paste), writing the release notes takes about 2 days. > > > > Yeah, but this shaved a lot of effort/delay off doing the final release > > notes. > > It did? AFAICT, the final release notes were created from scratch and > the alpha release notes deleted. Yes, that is what happened. I did the 9.1 release notes from scratch, and Robert Haas looked over the alpha notes and mine and found mine more complete. He did move some wording from the alpha releases into the final release notes. I think Robert has the best perspective on this issue. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Mon, Sep 12, 2011 at 8:39 PM, Bruce Momjian <bruce@momjian.us> wrote: > Peter Eisentraut wrote: >> On m?n, 2011-09-12 at 09:43 -0700, Josh Berkus wrote: >> > > Writing the release notes is really the main part of the work. Bundling >> > > the release takes 15 minutes, writing the announcement takes 15 minutes >> > > (copy and paste), writing the release notes takes about 2 days. >> > >> > Yeah, but this shaved a lot of effort/delay off doing the final release >> > notes. >> >> It did? AFAICT, the final release notes were created from scratch and >> the alpha release notes deleted. > > Yes, that is what happened. I did the 9.1 release notes from scratch, > and Robert Haas looked over the alpha notes and mine and found mine more > complete. He did move some wording from the alpha releases into the > final release notes. I think Robert has the best perspective on this > issue. I don't have much of an opinion on this, honestly. I think that whoever did the alpha release notes tried to hit the highlights, whereas Bruce went for something more in-depth. You could make an argument for either approach. I think if the alpha release notes were done with a clear idea in mind of producing something like what Bruce turned out, it wouldn't be necessary for Bruce to do it over again. The problem is that once you start leaving things out, it's very difficult to figure out exactly what got left out without redoing the whole process ab initio. On the flip side, I cross-referenced the alpha release notes with Bruce's, and found a few things that Bruce had mysteriously omitted or to which he had given short shrift. So there is potentially at least a little bit of value in doing the process twice - it helps you catch things that may have gotten dropped. Having done some work on this, I do NOT believe the previously-offered contention that this work can't be done incrementally. I think it could. After each CF, Bruce, or someone else, could go through all the commits and produce a list of items. As the release wore on, it might be necessary to subdivide some of the categories or recategorize things, but that I don't think it would be unmanageable. The whole process seems reasonably straightforward, just somewhat time-consuming. The main challenge seems to be making sure you don't lose things. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company