At Wed, 5 Jun 2013 21:26:51 -0500, Robby Findler wrote: > For point 3., do you have a sense of what milestones we'd have to reach (at > what times) in order to have a successful release?
The milestones I can see are * Get DrDr working with the new layout. * Automate snapshot and release builds (i.e., setting up client machines and writing the coordinating layer on top of `make server' and `make client'). Those seem like "next week" milestones to me. Trying to characterize the milestones doesn't really seem to capture the potential danger at this point, though. If we can build installers that let users run DrRacket, then I think there's not so much that can go wrong in terms of delivering a release. There are some potential problems; for example, I think DrRacket's rule on when to compile packages in debugging mode needs a tweak. But that level of danger is different from, say, the dangers of re-implementing the snip, drawing, and GUI classes, where testing is more difficult. The big things that can go wrong are longer term, like finding that the package system doesn't do what we need and having to introduce a third package system. The catch is that it seems difficult to know more about what happens when we really adopt a way of working without really adopting it. At Wed, 5 Jun 2013 22:42:12 -0400, Sam Tobin-Hochstadt wrote: > - I'm not entirely happy with the -doc/-lib/etc split, since it seems > to make everything more verbose and difficult to work with. But I > haven't tried developing in that environment, so maybe it's not a big > deal. I also worry that it makes our repository less approachable to > new people. I agree. One possibility is that few packages will be split so finely --- only ones where the difference in dependencies is large and there are clients for the low-dependency "-lib" package (in constrained environments? in settings with frequent rebuilds?). If we don't anticipate such clients, however, maybe we shouldn't try it at all. > - We still don't have a ton of experience with the package system > itself -- it's designated as beta in the current release, and there > are very few packages with non-trivial dependencies. In contrast, the > core repository has a lot of dependencies. For example, how will we > deal with backwards-incompatible changes to the split itself, since > packages are intended to be permanently compatible? Yes. This is both a significant difference and an example of a point that's difficult to explore without the split. When we have a big core, lots of packages can have zero dependencies other than the implicit dependency on the core. When we have a small core, then there should be practically no packages without explicit dependencies --- when a package's dependencies are specified accurately, at least. At Wed, 05 Jun 2013 22:26:10 -0600, Neil Toronto wrote: > Figuring out the details will go 20 times faster when we're all > forced to work with them. I'm for #3. That's what I'm hoping. I think there are ways to gain more experience with the package system without committing to it for the next release. For example, we could have a parallel development track for a while. Those other options will have overhead (maintaining two automatic-build systems would not be fun, for example) and slow us down overall. I think we have time to make a new way work, especially if the new way is all we're trying to make work. _________________________ Racket Developers list: http://lists.racket-lang.org/dev
