From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2002-09-24 09:45:32
David Abrahams wrote:
> From: "Markus Schöpflin" <markus.schoepflin_at_[hidden]>
>> David Abrahams wrote:
>>> Anyway, it was only a half-serious suggestion. My point is that
>>> if people have patches which make the difference between Boost
>>> working and not working on a given platform, they should try to
>>> post them before we branch for release. After a release branch it
>>> becomes increasingly hard to roll fixes into the branch and still
>>> get them into the trunk correctly.
>> Hey, wait a second. I have been posting patches now almost
>> contantly for three weeks (or contacting library authors privately)
>> because I started working on AIX with VisualAge C++ three weeks
>> ago. I tried to fix the problems as I encountered them. Are you
>> trying to tell me that I should not post the patches just because a
>> branch for release just happened?
> No, but we should be clear about whether we're going to try to get
> this platform working for 1.29.0 or not. Did you expect these to go
> into the release candidate branch, or just the main trunk?
As most of the patches are only minor fixes it would be great if they
would go to the release branch and the main trunc. After all, the
release branch is for fixing bugs before release, isn't it? But if this
is too much of a problem it would be great to know that the patches at
least are not ignored or missed.
> Maybe we should be using the SF patch manager for these things, so
> that patches don't risk being forgotten if not immediately applied.
> On the other hand, some projects which do use the patch manager have
> a backlog of not-applied patches.
I think there is not much difference between the patches posted to the
mailing list and the SF patch manager if you don't have a person who is
doing the job of patch manager and assigning the patches to the library
authors or applies them himself.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk