Okay. Good point about the relative difficulties of testing too. I am for 3.
Robby On Thursday, June 6, 2013, Matthew Flatt wrote: > 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 >
_________________________ Racket Developers list: http://lists.racket-lang.org/dev
