[racket-dev] updated proposal for moving to packages

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.