[m-rev.] for review: Add support for weak pointers to the C RTS

[Paul Bone]

On Mon, Jul 21, 2014 at 09:41:15AM +1000, Julien Fischer wrote:
> On Fri, 18 Jul 2014, Paul Bone wrote:
>
>> On Fri, Jul 18, 2014 at 03:30:37PM +1000, Julien Fischer wrote:
>>>
>>> On Fri, 18 Jul 2014, Paul Bone wrote:
>>>
>>>> On Tue, Apr 15, 2014 at 10:20:01PM +1000, Paul Bone wrote:
>>>>> For review by anyone.
>>>>>
>>>>
>>>> No-one has reviewed these changes in the last three months so I've committed
>>>> them:
>>>>
>>>> + Make version_array's rewind code use constant stack space.
>>>> + Add missing MR_GC_malloc_atomic procedure
>>>> + Add support for weak pointers to the C RTS
>>>
>>> It would have been preferable to have posted a reminder mail about
>>> them requiring a review than just committing them.  Are these
>>> changes necessary for the 14.01 branch?  I ask, because I had almost
>>> finished testing the current 14.01.1-beta on Windows (in all the various
>>> combination of build environment / C compilers) and this means I will
>>> have to do so all over again.
>>
>> Not necessary but desirable.  They improve things for ODASE.
>
> Ok.
>
>> You're welcome
>> to do a post-commit review.  Also, when did we 'freeze'
>> version-14_01-branch?
>
> We didn't per se, but it's a release branch, so it exists in a
> semi-frozen state anyway.

In general we've been treating this as somewhat ambiguous.  We should
make it very clear what is a bug fix and what isn't.

> My main concern is that this change involves a lot of low-level GC
> stuff, and such stuff has a history of not being portable (e.g. because
> various things in the Boehm GC are not implemented on Windows etc).
> That's not an objection to this change, but it does mean that it needs
> to be tested on a wide range of platforms / C compilers.

That's a fair point.  I agree.

>> I didn't know that you were nearly ready to release.
>
> 14.01.1 has been nearly ready for several months now; the main reason
> it hasn't been released is due to limitations on my time.
>

To improve things in the future I think we need to generalise this process,
so that it's less dependent on any one person.  We should also create some
release policies so that releases can occur on a more predictable nature.
This will certainly help our users, especially our commercial users.


I suggest we make a full release once every 6 months, by branching and
freezing master, one month after the freeze we should make the release,
regardless of how many bugs are fixed, and then make point releases once a
month for 9 months on the two most recent release branches.

The release process should be documented and refined so that building the
pre-release and testing it is so simple it will not be bothersome to do it
once a month.


-- 
Paul Bone