Duh, I knew I forgot something:

= Testing

To make exhibit more suitable for open source hacking, having tests
would be of great help. Anyone with an idea on how to define those? If
not, I could poke jresig or other mozillians for ideas.

Axel

2008/3/11, Axel Hecht <[EMAIL PROTECTED]>:
> Hi David,
>
>  congrats to getting a job, I hope you like it. No comment on those
>  6.5, my Ph.D took about the same time ;-). Thanks, Mozilla.
>
>  Going forward, there are a few different issues that were raised in
>  the discussion:
>
>  = Developer man power
>   - MIT
>   - Open Sourcers
>
>  I think relying on the MIT for coding shouldn't go much longer than
>  David being there. I personally think that going the Open Source way
>  will add more thrust to exhibit and timeline, and I might actually
>  caugh up a patch, eventually.
>
>  As for Frankenmonsters and bad code, there's a well established
>  process to fix that, it's called peer review. David's not going to
>  fall off the planet, thanks to his new employer, so there is no need
>  or reason for arbitrary folks checking in arbitrary stuff without him
>  looking at it first.
>  http://developer.mozilla.org/en/docs/Getting_your_patch_in_the_tree is
>  how a big project like Mozilla handles this, I bet that we can figure
>  something out that looks less scary. I expect that new reviewers grow
>  out of the community that's contributing patches, and there's some
>  level in here somewhere where getting commit priviledges is a good
>  idea
>
>  = Source hosting
>   - MIT
>   - google
>   - SF
>
>  I'd go for the level of service here, in particular in terms of bug
>  tracking systems. SF.net is sadly enough dog-slow, ad-plastered, and
>  low-featured. I haven't worked on google code myself, but google
>  usually doesn't have performance problems, at least. I'm not sure if
>  MIT would offer to continue to host the sources, or even grant non-MIT
>  folks write access.
>
>  = Web hosting
>   - MIT
>   - google
>
>  I really think that SF.net is out of question here, their latency is
>  just yucky. It'd be nice if the MIT could continue to host the
>  projects, as that would ease our lives and we wouldn't have to get all
>  our urls changed. I'm not really sure what the requirements are,
>  though.
>
>  Are exhibit and timeline the only projects that are affected? We've
>  seen more messages about structural changes at simile, so maybe it'd
>  be interesting to see if there's a hosting solution out there that's
>  somewhat independent from MIT, but is supported by it in some way.
>  Other players interested in innovation on the internet might be able
>  to chime in, too.
>
>  = Incorporated projects
>
>  I haven't seen this being mentioned, but what's the relationship to
>  the tooling libs, like SimileAjax and friends?
>
>  Axel
>
>  2008/2/18, David Huynh <[EMAIL PROTECTED]>:
>
> > Hi all,
>  >
>  >  As you might know, I have recently finished my Ph.D. study, and within a
>  >  few months I'll be moving on to a "real job" at Metaweb.
>  >
>  >  The Metaweb folks have been kind to let me dedicate some time toward
>  >  open source involvement, which means that I can continue to work on
>  >  Timeline, Exhibit, etc. to some extent.
>  >
>  >  However, it is clear that I won't be able to dedicate as much time to
>  >  those projects as I can right now. So, it is crucial that we arrange for
>  >  more people to get involved in those projects so that those projects
>  >  continue to thrive.
>  >
>  >  One possibility is to move the code bases onto an open source foundry,
>  >  such as Google Code, and invite the more programming capable among
>  >  yourself to maintain and improve them further. Note that this solution
>  >  is even better than the current situation, as there will be more capable
>  >  people involved than just me alone. Together we'll work out the
>  >  knowledge transfer, etc. etc. over the next few months.
>  >
>  >  Please don't hesitate to chime in here if you have other ideas or just
>  >  want to speak your mind. The worst thing that can happen is that nobody
>  >  expresses their concerns, no transition gets made, and the good code
>  >  just withers away.
>  >
>  >  Thanks,
>  >
>  >  David
>  >
>  >  _______________________________________________
>  >  General mailing list
>  >  [email protected]
>  >  http://simile.mit.edu/mailman/listinfo/general
>  >
>
_______________________________________________
General mailing list
[email protected]
http://simile.mit.edu/mailman/listinfo/general

Reply via email to