Nathan Hartman wrote: > The branch worked for me when I last tested it and I saw no glaring > issues so I have no objections to merging it soon. That said, I would > encourage, if at all feasible, that we try to do two things first: > decouple the format 32 and pod525 feature, and decide what the > user-facing feature and its CLI switches should be called so that our > internal "plumbing" names won't stick forever as the user-visible > terms... If we can only do one of these, it should probably be the naming.
For "decouple the format 32 and pod525 feature", see email thread "Pristines-on-demand=enabled == format 32?" <https://lists.apache.org/thread/bwctyvt0n5s81x1d5gpmncdmw4bn77m9>. Naming ====== What naming do we want? I'm perhaps too close to the code. Some potentially good ideas have been floated in the past, none very obviously best but perhaps we can pick a good one from them. Some suggestions were along the lines of: * "bare WC" * "blob-optimised WC" * "[no] local cache" (of text-bases) * "[no] trade space for speed" (just off the top of my head). The feature name hardly appears in the UI, so far. The places I can think of are: * a progress notification: "Fetching text bases...", * perhaps a dedicated option name for checkout/upgrade, as being discussed in the "decouple" thread mentioned above; * release notes; * user guide (where currently a place-holder 'POD525' is used for the feature name). - Julian
