Re: [B2-devel] Thoughts on SheepShaver and Basilisk II

[Alexei S. <ale...@gm...>]

On Sat, Jun 16, 2012 at 2:47 AM, Robert Munafo <mr...@gm...> wrote:

> On Fri, Jun 15, 2012 at 12:08 PM, Alexander von Gluck wrote:
> >> Right now i'm pouring over the other existing forks on Github of
> >> SheepShaver and cherrypicking patches not in the
> >> SheepShaver codebase (giving the other authors credit)
>
> Wow, you're not kidding -- I found four other forks of SheepShaver on
> GitHub!
>
> Regardless of the rest of the questions, like how to improve the UI or
> make development easier, we should definitely check these out --
> there's obviously a lot of creative energy out there. Some of them
> could probably benefit from the work we've done. I noticed one version
> has "enable JIT on 64-bit MacOS" as their latest change, and we've
> done other improvements since then.
>
> Any Mac users using any of those forks would want my CD-ROM eject fix,
> for example.
>

I think regardless of any new SCM we switch to, we definitely need a better
process to getting code to upstream. In the past, I've tried to encourage
people to send patches to this list for this, so that we could discuss them
if necessary and I would land them. This model works very well for some
other projects, like ffmpeg.

But it hasn't really worked too well here. Often times people don't send
patches - either they post them to emaculation.com forums and I need to
periodically monitor these and look for these gems - or they don't share
them and just post builds there - or they commit them to their own git
works without telling anyone.

You may argue that the last workflow should be fine - i.e. people
committing stuff to their own forks and upstream (me) then looking over
what's been done and pulling stuff I'm interested in. I disagree. A lot of
such changes don't provide enough context as to what they're fixing or why
that change is being made. And I don't feel comfortable merging in stuff
randomly without understanding it. There needs to be a place for discussion.

For example, let's take this commit by Tycho which kallisti5 pulled:

https://github.com/tycho/sheepshaver/commit/ceed8dca09fd5e5fe4e1bf9127d628382cb0f350

Presumably this makes something faster. Maybe it does, it looks plausible -
instead of checking the cache just at the beginning, check it at every
iteration so that presumably if the next pc is in the cache, we could get
it from there. Maybe. I'm not sure that my description is correct - the
code is pretty complicated there. Does it really improve performance?
Something like this could actually degrade performance. I don't see any
reference to benchmarks or improvements in the commit description. When I
try running some random benchmark programs I have lying around, I don't see
any difference. I can't justify pulling that into upstream unless I know
what improvement that provides - otherwise it's just unnecessary code churn.

-Alexei