[racket-dev] updated proposal for moving to packages

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20130606/adec8ed0/attachment-0001.html>