Subject: Re: Please Revert newlock2
To: Bucky Katz <email@example.com>
From: Thor Lancelot Simon <firstname.lastname@example.org>
Date: 02/18/2007 10:32:22
On Sat, Feb 17, 2007 at 09:52:45PM -0800, Bucky Katz wrote:
> Eric Haszlakiewicz <email@example.com> writes:
> > If you'll refer to Andrew's email announcing the merge, you'll see
> > he claims that it DID pass a minimum of tests.
> He also said he knew it was broken on a bunch of architectures. It's a
> bad practice to check in code you _know_ is broken, especially when
> there's no rush.
It used to be the case that we stalled features for long periods of time
waiting for portmasters to confirm or deny that they worked on their
ports (or write the code to make them work). We experimented perhaps
five years ago with a new workflow of committing the code after warning
the portmasters and expecting them to quickly clean up afterwards. It
appeared to work better.
It clearly does *not* work better in the case of an MIA portmaster and
very active external developers using the port with the MIA portmaster.
We accidentally screwed you over and we have to find a way to not do
that in the future.
That said, I don't think newlock2 is going anywhere, so it seems to me
our priorities should be:
1) Make ARM compile and get the present 1:1 threads working so they pass
the regression tests.
2) Either cause them to perform acceptably for your application, or else
endeavor to get M:N back in a supported state for uniprocessors.
It may be the case that we need to adjust the portmastership for the
ARM ports to get these things done. I personally think ARM is an
example of an architecture where there ought to be a portmaster-committee
for the whole set of ARM ports, to put all the relevant expertise in one
place, rather than one portmaster per port, who often drifts away because
each individual port has few users.