For what it's worth, On Thu, Aug 26, 2010 at 15:10:30 +0200, Petr Rockai wrote: > > The solution is not to provide a cumbersome way to convert the old > > repo and a big warning that few read and even fewer understand
I agree with Dan and I think Ben that counting on users to read messages you emit would be a mistake. Digression: I'm also a bit concerned about our recent trend towards "helpful" chatter [all of which I've supported] btw, like the issue1599 stuff and the --no-set-default warning, or the "by the way, hashed repositories would be faster". I fear all three may be ineffective at best or counter-productive at worst, but I don't know what to do. Somebody lateral-think us out of this! > > , but to provide a straightforward and simple way to convert the old > > repo that everyone understands. > > > > And that is already there: 'darcs optimize -- > > upgrade' > > I think that you have convinced me. So I am in favour of keeping > optimize --upgrade as the migration path and refusing darcs get from > old-fashioned. Indeed, this seems a much better choice than get indeed! OK so repeating my original questions for context (and hoping they are are the right ones to ask): | 1. What kind of indefinite support should we provide for old-fashioned | repositories? Dan's observation helped us make progress on this. If we're going to drop down to the bare minimum, then that bare minimum should be optimize --upgrade. And it looks like provided we get #2 right, folks are comfortable with our support being restricted to just doing optimize --upgrade. | 2. What pre-requisites need to be fulfilled before we can withdraw | support for old-fashioned repositories? Note that these aren't | pre-requisites for agreeing on the withdrawal; they are things we | need to work towards if we should agree in principle. Nathan suggested that folks would be more comfortable if they could still interact with old-fashioned repositories after the upgrade to see how things go. I'd brought up a question of whether we should satisfy user concerns first or slash-and-burn first. While satisfying user concerns first (performance issues largely) sounds like the preferable behaviour, Petr suggests that it's impractical and that we'd be better placed to satisfy these concerns from a cleaner code base. So I guess the only thing we can really do is list these specific concerns, which I've done here: http://wiki.darcs.net/Roadmap#old-fashioned-phase-out so we can at least monitor them. | 3. What kind of schedule should we adopt in phasing out support for | old-fashioned repositories? Some factors here are A. how many phases? - big-bang (announce - kill) vs - gradual (announce, kill a bit, kill a bit more...)? B. how much time between phases? For #A, I guess a big-bang approach would actually be less painful in the long run than a gradual one (recalling the Makefile to Cabal transition, ugh!) For #B, the lower bound is switching to kill in Darcs 2.8 (which could be 6 months after Darcs 2.5 if we follow the current schedule, more on that later). I think the upper bound may depend on how the adventure branch goes. OK! So I personally am much more comfortable with the idea, and I think we've made an effort to do our homework first. Thanks to everybody for your input. If you have any concerns, or you think we may acting a little too hastily, please speak up! Better safe than sorry :-) -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> For a faster response, try +44 (0)1273 64 2905 or xmpp:[email protected] (Jabber or Google Talk only)
signature.asc
Description: Digital signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
