Excerpts from Dave Page's message of mié abr 27 16:15:33 -0300 2011:
> On Wed, Apr 27, 2011 at 8:12 PM, Alvaro Herrera
> wrote:
> > BTW I just swapped the compiler details for those two animals in the
> > buildfarm database.
>
> I thought Andrew did that already?
He hadn't gotten around to actu
On 04/27/2011 03:15 PM, Dave Page wrote:
On Wed, Apr 27, 2011 at 8:12 PM, Alvaro Herrera
wrote:
Excerpts from Dave Page's message of mié mar 02 16:38:00 -0300 2011:
Should be. Moa is definitely Sun Studio:
-bash-3.00$ /opt/sunstudio12.1/bin/cc -V
cc: Sun C 5.10 SunOS_i386 2009/06/03
usage
On Wed, Apr 27, 2011 at 8:12 PM, Alvaro Herrera
wrote:
> Excerpts from Dave Page's message of mié mar 02 16:38:00 -0300 2011:
>
>> Should be. Moa is definitely Sun Studio:
>>
>> -bash-3.00$ /opt/sunstudio12.1/bin/cc -V
>> cc: Sun C 5.10 SunOS_i386 2009/06/03
>> usage: cc [ options] files. Use 'cc
Excerpts from Dave Page's message of mié mar 02 16:38:00 -0300 2011:
> Should be. Moa is definitely Sun Studio:
>
> -bash-3.00$ /opt/sunstudio12.1/bin/cc -V
> cc: Sun C 5.10 SunOS_i386 2009/06/03
> usage: cc [ options] files. Use 'cc -flags' for details
>
> And Huia is GCC:
>
> -bash-3.00$ /us
Andres Freund writes:
> On Saturday 05 March 2011 17:46:13 Tom Lane wrote:
>> Andres Freund writes:
* Collation-related regression failure on buildfarm member pika. This
is clearly a bug we need to identify, but maybe we can ship the alpha
without a fix --- for one thing, getting
On tis, 2011-03-08 at 17:43 -0500, Tom Lane wrote:
> Mph. Well, I guess in the case of the pg_statistic stats we can
> declare by fiat that we calculate the stats according to the default
> collation. They'll be a bit off when used for a query that is
> comparing according to some other collation
Peter Eisentraut writes:
> On mån, 2011-03-07 at 12:40 -0500, Tom Lane wrote:
>> Fair enough, but throwing in fmgr_info_collation(DEFAULT_COLLATION)
>> anytime we have a problem seems to me to introduce the exact same
>> issue. Who's to say that that's really the appropriate value to use?
> It
On mån, 2011-03-07 at 12:40 -0500, Tom Lane wrote:
> Fair enough, but throwing in fmgr_info_collation(DEFAULT_COLLATION)
> anytime we have a problem seems to me to introduce the exact same
> issue. Who's to say that that's really the appropriate value to use?
It normally isn't the appropriate val
On Mon, 2011-03-07 at 11:00 -0800, Josh Berkus wrote:
> >
> > At the risk of hijacking this thread to talk about the subject of
> this
> > thread, when are we going to cut alpha4?
>
> Any reason not to release it this week, like Thursday?
Let's release it before PGEast, please -- I will be there
On Mon, Mar 7, 2011 at 4:59 PM, Peter Eisentraut wrote:
> On mån, 2011-03-07 at 15:19 -0500, Robert Haas wrote:
>> Sorry, you're right. Still, as happy as I am that we've made so much
>> progress with PL/python (and other things) this CommitFest, I think
>> it's time to pick a date and time to sh
On mån, 2011-03-07 at 15:19 -0500, Robert Haas wrote:
> Sorry, you're right. Still, as happy as I am that we've made so much
> progress with PL/python (and other things) this CommitFest, I think
> it's time to pick a date and time to ship alpha4 and call this one
> good. If the patch makes it, gr
On Mon, Mar 7, 2011 at 3:28 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> Still, as happy as I am that we've made so much progress with
>> PL/python (and other things) this CommitFest, I think it's time to
>> pick a date and time to ship alpha4 and call this one good. If
>> the patch makes
Robert Haas wrote:
> Still, as happy as I am that we've made so much progress with
> PL/python (and other things) this CommitFest, I think it's time to
> pick a date and time to ship alpha4 and call this one good. If
> the patch makes it, great; if not, oh well. We can't keep letting
> this dr
On Mon, Mar 7, 2011 at 3:15 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> Tom Lane wrote:
>
>>> Well, a prerequisite for cutting an alpha is closing the
>>> commitfest, which at this point reduces to deciding what we are
>>> going to do with the plpython traceback patch.
>
>> AFAIK, there's
Robert Haas wrote:
> Tom Lane wrote:
>> Well, a prerequisite for cutting an alpha is closing the
>> commitfest, which at this point reduces to deciding what we are
>> going to do with the plpython traceback patch.
> AFAIK, there's nothing particularly special about that patch,
> other than th
On Mon, Mar 7, 2011 at 2:43 PM, Tom Lane wrote:
> Robert Haas writes:
>> At the risk of hijacking this thread to talk about the subject of this
>> thread, when are we going to cut alpha4?
>
> Well, a prerequisite for cutting an alpha is closing the commitfest,
> which at this point reduces to dec
Robert Haas writes:
> At the risk of hijacking this thread to talk about the subject of this
> thread, when are we going to cut alpha4?
Well, a prerequisite for cutting an alpha is closing the commitfest,
which at this point reduces to deciding what we are going to do with
the plpython traceback
On 3/7/11 10:59 AM, Robert Haas wrote:
> On Mon, Mar 7, 2011 at 1:42 PM, Andres Freund wrote:
>> that looks like it should be corrected btw:
>> src/backend/tsearch/{wparser_def.c,ts_locale.c}
>> Oid collation = DEFAULT_COLLATION_OID; /*TODO*/
>>
>> Thats occuring 6 times in the
On Mon, Mar 7, 2011 at 1:42 PM, Andres Freund wrote:
> that looks like it should be corrected btw:
> src/backend/tsearch/{wparser_def.c,ts_locale.c}
> Oid collation = DEFAULT_COLLATION_OID; /*TODO*/
>
> Thats occuring 6 times in there...
At the risk of hijacking this thread to
Hi,
On Monday, March 07, 2011 06:40:55 PM Tom Lane wrote:
> Peter Eisentraut writes:
> > On sön, 2011-03-06 at 12:16 -0500, Tom Lane wrote:
> >> I'm still not thrilled with the plan of sprinkling the code with
> >> random fmgr_info_collation() calls to make up for the lack of a sane
> >> default
Peter Eisentraut writes:
> On sön, 2011-03-06 at 12:16 -0500, Tom Lane wrote:
>> I'm still not thrilled with the plan of sprinkling the code with
>> random fmgr_info_collation() calls to make up for the lack of a sane
>> default. IMO, that *is* a default, just a badly implemented one.
> We have
On sön, 2011-03-06 at 12:16 -0500, Tom Lane wrote:
> I'm still not thrilled with the plan of sprinkling the code with
> random fmgr_info_collation() calls to make up for the lack of a sane
> default. IMO, that *is* a default, just a badly implemented one.
We have touched upon this point several t
Andres Freund writes:
> -
> fmgr_info_collation(irel->rd_index->indcollation.values[attnum-1],
> + fmgr_info_collation(irel->rd_indcollation[attnum-1],
> locinfo);
BTW, I went ahead and committed this part, since the b
Andres Freund writes:
> Ah. Finally after trying to stare down the code for some more time the issue
> is pretty simple.
> -
> fmgr_info_collation(irel->rd_index->indcollation.values[attnum-1],
> + fmgr_info_collation(irel->rd_indcollation[attnum-1],
Good catch ... but
On Sat, Mar 5, 2011 at 7:22 AM, Robert Haas wrote:
> Here's a rough attempt at filtering the post-alpha3 commit log down to
> approximately the set of things worth adding to the alpha4 release
> notes.
>
Seems that support LIKE and ILIKE index searches via contrib/pg_trgm indexes
is not mentione
On Sat, Mar 5, 2011 at 5:28 PM, Tom Lane wrote:
> "David E. Wheeler" writes:
>> On Mar 4, 2011, at 7:44 PM, Robert Haas wrote:
>>> So it seems like the only thing that is an absolute must-do is write
>>> some release notes.
>
>> What about this?
>>> http://archives.postgresql.org/message-id/27152
Robert,
Some minor fixes:
197
198
199 Implement a truly serializable isolation
level
200
201
Should be:
Implement Serializable Snapshot Isolation, in order to provide
a more robust serializable transaction mode
212 Allow multiple co
Ah. Finally after trying to stare down the code for some more time the issue
is pretty simple.
index_getprocinfo did this:
/* Initialize the lookup info if first time through */
if (locinfo->fn_oid == InvalidOid)
{
...
fmgr_info_cxt(procId, locinfo, irel->
"David E. Wheeler" writes:
> On Mar 4, 2011, at 7:44 PM, Robert Haas wrote:
>> So it seems like the only thing that is an absolute must-do is write
>> some release notes.
> What about this?
>> http://archives.postgresql.org/message-id/27152(dot)1299015062(at)sss(dot)pgh(dot)pa(dot)us
Well, nobod
On Mar 4, 2011, at 7:44 PM, Robert Haas wrote:
> So it seems like the only thing that is an absolute must-do is write
> some release notes.
What about this?
> Yeah, the real problem in my mind is not so much citext as whether the
> current representation of a type's collation property is sane in
On lör, 2011-03-05 at 12:43 -0500, Tom Lane wrote:
> Why aren't we just setting finfo.fn_collation to DEFAULT_COLLATION_OID
> by default, or maybe better letting places that inspect it take zero
> as meaning default collation?
Because then you'd just get silently wrong results instead of an error.
On Sat, Mar 5, 2011 at 10:33 AM, Andy Colson wrote:
> On 03/05/2011 08:54 AM, Robert Haas wrote:
>>
>> On Sat, Mar 5, 2011 at 9:44 AM, Andy Colson wrote:
Support unlogged tables. The contents of an unlogged table are
WAL-logged;
>>>
>>> um.. are _not_ WAL-logged?
>>
>> Uh, yeah.
On Sat, Mar 5, 2011 at 10:17 AM, Andy Colson wrote:
> On 03/05/2011 08:54 AM, Robert Haas wrote:
>>
>> On Sat, Mar 5, 2011 at 9:44 AM, Andy Colson wrote:
Support unlogged tables. The contents of an unlogged table are
WAL-logged;
>>>
>>> um.. are _not_ WAL-logged?
>>
>> Uh, yeah.
On Saturday 05 March 2011 18:43:31 Tom Lane wrote:
> Andres Freund writes:
> > I have a WIP patch fixing one of the two issues.
> >
> > Several places in selfuncs.c didn't setup collations. That lead for
> > example to errors during patternsel.
>
> Hmm. I have to say that this seems like quite
Andres Freund writes:
> I have a WIP patch fixing one of the two issues.
> Several places in selfuncs.c didn't setup collations. That lead for example
> to
> errors during patternsel.
Hmm. I have to say that this seems like quite the wrong way to go.
If everyplace in the system that could be
On Saturday 05 March 2011 18:37:30 Andres Freund wrote:
> On Saturday 05 March 2011 17:46:13 Tom Lane wrote:
> > Andres Freund writes:
> I am currently looking at the other one. Its quite strange:
The backtrace during the operations described earlier:
0 index_getprocinfo (irel=0x7f5426cbc820, at
On Saturday 05 March 2011 17:46:13 Tom Lane wrote:
> Andres Freund writes:
> > On Saturday 05 March 2011 04:44:20 Robert Haas wrote:
> >>> * Collation-related regression failure on buildfarm member pika. This
> >>> is clearly a bug we need to identify, but maybe we can ship the alpha
> >>> withou
On Sat, Mar 05, 2011 at 11:46:13AM -0500, Tom Lane wrote:
> Andres Freund writes:
> > On Saturday 05 March 2011 04:44:20 Robert Haas wrote:
> >>> * Collation-related regression failure on buildfarm member pika. This
> >>> is clearly a bug we need to identify, but maybe we can ship the alpha
> >>>
Andres Freund writes:
> On Saturday 05 March 2011 04:44:20 Robert Haas wrote:
>>> * Collation-related regression failure on buildfarm member pika. This
>>> is clearly a bug we need to identify, but maybe we can ship the alpha
>>> without a fix --- for one thing, getting more than one report of th
On lör, 2011-03-05 at 09:33 -0600, Andy Colson wrote:
> Can we add a line saying "-j still doesnt work, dont use it yet" or
> "make -j2 works great now". I admit I've never tried to use -j
> before... is this telling me its ok to use now?
Has make -j ever made any sense? Other than for locking u
On 03/05/2011 08:54 AM, Robert Haas wrote:
On Sat, Mar 5, 2011 at 9:44 AM, Andy Colson wrote:
Support unlogged tables. The contents of an unlogged table are
WAL-logged;
um.. are _not_ WAL-logged?
Uh, yeah. It looks like I fixed that in the version I committed, but
introduced another, simi
On 03/05/2011 08:54 AM, Robert Haas wrote:
On Sat, Mar 5, 2011 at 9:44 AM, Andy Colson wrote:
Support unlogged tables. The contents of an unlogged table are
WAL-logged;
um.. are _not_ WAL-logged?
Uh, yeah. It looks like I fixed that in the version I committed, but
introduced another, simi
On Sat, Mar 5, 2011 at 9:44 AM, Andy Colson wrote:
>> Support unlogged tables. The contents of an unlogged table are
>> WAL-logged;
>
> um.. are _not_ WAL-logged?
Uh, yeah. It looks like I fixed that in the version I committed, but
introduced another, similar mistake which I have now also fixed
On 03/04/2011 10:22 PM, Robert Haas wrote:
On Fri, Mar 4, 2011 at 10:44 PM, Robert Haas wrote:
So it seems like the only thing that is an absolute must-do is write
some release notes.
Here's a rough attempt at filtering the post-alpha3 commit log down to
approximately the set of things worth
On Sat, Mar 5, 2011 at 8:41 AM, Robert Haas wrote:
> On Fri, Mar 4, 2011 at 11:22 PM, Robert Haas wrote:
>> On Fri, Mar 4, 2011 at 10:44 PM, Robert Haas wrote:
>>> So it seems like the only thing that is an absolute must-do is write
>>> some release notes.
>>
>> Here's a rough attempt at filteri
On Sat, Mar 5, 2011 at 8:48 AM, Alexander Korotkov wrote:
> On Sat, Mar 5, 2011 at 7:22 AM, Robert Haas wrote:
>>
>> Here's a rough attempt at filtering the post-alpha3 commit log down to
>> approximately the set of things worth adding to the alpha4 release
>> notes.
>
>
> Seems that support LIKE
On Fri, Mar 4, 2011 at 11:22 PM, Robert Haas wrote:
> On Fri, Mar 4, 2011 at 10:44 PM, Robert Haas wrote:
>> So it seems like the only thing that is an absolute must-do is write
>> some release notes.
>
> Here's a rough attempt at filtering the post-alpha3 commit log down to
> approximately the s
On Saturday 05 March 2011 04:44:20 Robert Haas wrote:
> > * Collation-related regression failure on buildfarm member pika. This
> > is clearly a bug we need to identify, but maybe we can ship the alpha
> > without a fix --- for one thing, getting more than one report of the
> > problem would be he
Robert Haas writes:
> So it seems like the only thing that is an absolute must-do is write
> some release notes.
The buildfarm is showing that I broke MSVC builds, but other than that,
yeah.
What needs to happen for MSVC is that the rules for installing DATA
files need to be applied for the pl d
On Fri, Mar 4, 2011 at 10:44 PM, Robert Haas wrote:
> So it seems like the only thing that is an absolute must-do is write
> some release notes.
Here's a rough attempt at filtering the post-alpha3 commit log down to
approximately the set of things worth adding to the alpha4 release
notes.
--
Ro
Let's review where we are.
On Tue, Mar 1, 2011 at 3:35 PM, Tom Lane wrote:
> * Regression test failures from recent plpython patches. These are
> affecting enough machines to make them "must fix before alpha", IMO.
> There are some variations in error message wording, which are not too
> terribl
On Thu, Mar 3, 2011 at 12:54 AM, Andrew Dunstan wrote:
>
>
> On 03/02/2011 02:16 PM, Dave Page wrote:
>>
>> On Thu, Mar 3, 2011 at 12:42 AM, Alvaro Herrera
>> wrote:
>>>
>>> Excerpts from Andrew Dunstan's message of mié mar 02 14:02:30 -0300 2011:
On 03/02/2011 11:49 AM, Tom Lane wrote
On 03/02/2011 02:16 PM, Dave Page wrote:
On Thu, Mar 3, 2011 at 12:42 AM, Alvaro Herrera
wrote:
Excerpts from Andrew Dunstan's message of mié mar 02 14:02:30 -0300 2011:
On 03/02/2011 11:49 AM, Tom Lane wrote:
Well, we can eliminate that last theory, because there were both 32 and
64 bit b
On 03/02/2011 02:12 PM, Alvaro Herrera wrote:
Excerpts from Andrew Dunstan's message of mié mar 02 14:02:30 -0300 2011:
On 03/02/2011 11:49 AM, Tom Lane wrote:
Well, we can eliminate that last theory, because there were both 32 and
64 bit buildfarm machines showing the crash, cf bobcat and cr
On Thu, Mar 3, 2011 at 12:42 AM, Alvaro Herrera
wrote:
> Excerpts from Andrew Dunstan's message of mié mar 02 14:02:30 -0300 2011:
>>
>> On 03/02/2011 11:49 AM, Tom Lane wrote:
>> > Well, we can eliminate that last theory, because there were both 32 and
>> > 64 bit buildfarm machines showing the c
Excerpts from Andrew Dunstan's message of mié mar 02 14:02:30 -0300 2011:
>
> On 03/02/2011 11:49 AM, Tom Lane wrote:
> > Well, we can eliminate that last theory, because there were both 32 and
> > 64 bit buildfarm machines showing the crash, cf bobcat and crake.
> > BTW, I see the former is now r
On Mar 2, 2011, at 9:02 AM, Andrew Dunstan wrote:
> That's because David apparently hasn't run update_personality.pl, although he
> has in the past.
Is this something we can run against crazier community members?
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
On Wed, Mar 02, 2011 at 12:02:30PM -0500, Andrew Dunstan wrote:
> On 03/02/2011 11:49 AM, Tom Lane wrote:
> >Well, we can eliminate that last theory, because there were both 32 and
> >64 bit buildfarm machines showing the crash, cf bobcat and crake.
> >BTW, I see the former is now running F14, not
On 03/02/2011 11:49 AM, Tom Lane wrote:
Well, we can eliminate that last theory, because there were both 32 and
64 bit buildfarm machines showing the crash, cf bobcat and crake.
BTW, I see the former is now running F14, not F13 as claimed on the
buildfarm dashboard,
That's because David appa
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> FWIW I looked at these patches yesterday when I was trying to reproduce
> the bug, but did not find anything interesting. It's mostly for stuff in
> the standard library. I haven't tried building Python with all of of
> these patches though, and did not f
On 02/03/11 16:28, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> On 02/03/11 14:25, Robert Haas wrote:
>>> But does bumping the ref count then create a leak the rest of the time?
>
>> Not really, because you never want to garbage collect the spiexceptions
>> module (just like you
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> On 02/03/11 14:25, Robert Haas wrote:
>> But does bumping the ref count then create a leak the rest of the time?
> Not really, because you never want to garbage collect the spiexceptions
> module (just like you don't want to GC th plpy module, or the plp
On 02/03/11 14:25, Robert Haas wrote:
> On Wed, Mar 2, 2011 at 6:14 AM, Jan Urbański wrote:
>>> That seems to have fixed it, so I have applied the patch. Would you like
>>> to supply some comments to got with it?
>>
>> The comment would be something like
>>
>> /* XXX it appears that in some circum
On Wed, Mar 2, 2011 at 6:14 AM, Jan Urbański wrote:
>> That seems to have fixed it, so I have applied the patch. Would you like
>> to supply some comments to got with it?
>
> The comment would be something like
>
> /* XXX it appears that in some circumstantes the reference count of the
> spiexcept
On 02/03/11 01:05, Andrew Dunstan wrote:
>
>
> On 03/01/2011 05:19 PM, Jan Urbański wrote:
>> On 01/03/11 22:07, Andrew Dunstan wrote:
>>>
>>> On 03/01/2011 03:53 PM, Jan Urbański wrote:
On 01/03/11 21:35, Tom Lane wrote:
> Josh Berkus writes:
>> I'm ok with closing things as of th
On 03/01/2011 05:19 PM, Jan Urbański wrote:
On 01/03/11 22:07, Andrew Dunstan wrote:
On 03/01/2011 03:53 PM, Jan Urbański wrote:
On 01/03/11 21:35, Tom Lane wrote:
Josh Berkus writes:
I'm ok with closing things as of the end of the 15 days, say
Thursday or
Friday.
It might be a good ide
On 01/03/11 22:07, Andrew Dunstan wrote:
>
>
> On 03/01/2011 03:53 PM, Jan Urbański wrote:
>> On 01/03/11 21:35, Tom Lane wrote:
>>> Josh Berkus writes:
I'm ok with closing things as of the end of the 15 days, say
Thursday or
Friday.
>>> It might be a good idea to make a list of w
"David E. Wheeler" writes:
> On Mar 1, 2011, at 1:12 PM, Tom Lane wrote:
>> The question is what collation property the
>> citext type needs to have, and how we get it to have that setting during
>> an upgrade from 9.0. See
>> http://archives.postgresql.org/message-id/11548.1297983...@sss.pgh.pa.
On Tue, Mar 1, 2011 at 22:20, Dimitri Fontaine wrote:
> Tom Lane writes:
>> Any other "must fix" items on people's minds?
>
> I'd like it if Magnus could commit his last round of work on
> pg_basebackup to stream the WALs in a subprocess. It's been about ready
> and waiting for more tests and co
Tom Lane writes:
> Any other "must fix" items on people's minds?
I'd like it if Magnus could commit his last round of work on
pg_basebackup to stream the WALs in a subprocess. It's been about ready
and waiting for more tests and code review while I've been ill. I
should be able to get there by
On Mar 1, 2011, at 1:12 PM, Tom Lane wrote:
> Collation, not correlation.
Yeah, I'm fat-fingered today.
> The question is what collation property the
> citext type needs to have, and how we get it to have that setting during
> an upgrade from 9.0. See
> http://archives.postgresql.org/message-
"David E. Wheeler" writes:
> On Mar 1, 2011, at 12:35 PM, Tom Lane wrote:
>> * Collation-related changes still needed in contrib/citext. If we don't
>> have this done before alpha4, I'm afraid we'll have to generate a 1.1
>> update script to fix it for alpha4 users. I'd just as soon not deal
>>
On tis, 2011-03-01 at 12:50 -0800, David E. Wheeler wrote:
> On Mar 1, 2011, at 12:35 PM, Tom Lane wrote:
>
> > * Collation-related changes still needed in contrib/citext. If we don't
> > have this done before alpha4, I'm afraid we'll have to generate a 1.1
> > update script to fix it for alpha4
On 03/01/2011 03:53 PM, Jan Urbański wrote:
On 01/03/11 21:35, Tom Lane wrote:
Josh Berkus writes:
I'm ok with closing things as of the end of the 15 days, say Thursday or
Friday.
It might be a good idea to make a list of what we have left to do before
we can wrap an alpha. Here are some t
On 01/03/11 21:35, Tom Lane wrote:
> Josh Berkus writes:
>> I'm ok with closing things as of the end of the 15 days, say Thursday or
>> Friday.
>
> It might be a good idea to make a list of what we have left to do before
> we can wrap an alpha. Here are some things on my list. Not all of them
>
On Mar 1, 2011, at 12:35 PM, Tom Lane wrote:
> * Collation-related changes still needed in contrib/citext. If we don't
> have this done before alpha4, I'm afraid we'll have to generate a 1.1
> update script to fix it for alpha4 users. I'd just as soon not deal
> with that overhead.
What needs t
On 3/1/11 12:35 PM, Tom Lane wrote:
> * Generate alpha release notes. This is at least half a day's work
> for somebody, I think, even with our fairly low standards for alpha
> release notes.
I can help with this. Possibly Selena can too.
--
-- Josh Berkus
Josh Berkus writes:
> I'm ok with closing things as of the end of the 15 days, say Thursday or
> Friday.
It might be a good idea to make a list of what we have left to do before
we can wrap an alpha. Here are some things on my list. Not all of them
are necessarily release blockers, but we need
78 matches
Mail list logo
