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

[Giulio P. <giu...@gm...>]

Il 16/06/2012 17:52, Alexei Svitkine ha scritto:
> 
> 
> On Sat, Jun 16, 2012 at 2:47 AM, Robert Munafo <mr...@gm...
> <mailto: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
> <http://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.

Github "Network" facilities will greatly help you with this: people
commits in their own repositories and you can see how those changes
relate to yours.

> 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.

In github (but also in bare git) there is also the "Pull request" method
that is: if someone wants to contribute a set of commits with you, just
selects the set of commits, writes a few notes about them and send the
request to you. You can ask for further details in a forum-like
discussion and when you are convinced can accept or reject the changes.
It works quite fine.

> 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
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> 
> 
> 
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel