Avi Bryant <avi at beta4.com> wrote:
> Very true.  But once we have DVS packages always being loaded in by DVS,
> and not as changesets, is there any benefit left to using chunk format?
In the short term, it's important for compatibility reasons (people
using 3.2, people using other tools not designed for it), to make the
transition easy.

> Moving to an uambiguously declarative format (SIF, Rosetta, something
> else) would IMO be better than sticking with a declarative interpretation
> of a format designed to be imperative.  We lose a bit of tool support (the
> ChangeList, etc), but it might be worth it.
In the long term, quite possibly, but I don't see an important benefit,
at least not short term.
 
> What I'm thinking about doing is taking the existing Monticello code model
> (which is much better than what DVS uses), dropping (or ignoring) the
> merging and versioning parts, and mapping it to some to-be-determined
> textual representation.  This could then be plugged into the existing DVS
> UI, and we'd be in much better shape than we are now to look for things
> like overridden methods.

Something I didn't understand - will our improved ability to find
overriden methods come from changing the code model, or the textual
format? I don't see what the text format has to do with this.

I'm not sure I understand what you're aiming for.
Here's my take -
1. A user loads a package from SM or from an email attachment or from
the FileList. If the code overrides existing code definition, this
should be handled in a user-defined way.
2. Maintainers will post packages. Packages will generally not include
redefinition of existing code, because doing so will bring up warnings
for most users when they are loaded. Instead, if patches are needed,
these will be released separately, and noted as prerequisites.
3. Patches will be released as a package type that annotates what they
are explicitly. The mechanism for loading patch packages will not
complain about overriding stuff. In the future, it might complain in
other cases, for example, if it is applied to the wrong version of a
package.

The community level goal these stories help achieve is that packages
will be something loaded without fear of clashes. If packages require
patches to other packages, this is made explicit, and packaged
separately, to make it easier for the upstream developer to accept the
patch, restoring cleanliness as quickly as possible.

Daniel