On Thu, Aug 26, 2010 at 08:39:31PM +0100, Eric Kow wrote: > 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.
I'm okay with this. > | 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 might have this satisfied already. If 2.5.0 is fast enough, then we have a version that can do both old-fashioned and hashed repositories. Or even if it is not fast enough to switch to, it is still available for conversing between the two formats. So even if 2.8.0 drops old-fashioned support, there is a tool that we can use in an emergency. > 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. Well, and performance is the only thing that is keeping my dependence on old-fashioned repos. If dropping old-fashioned support means performance is going to take off, I will probably be happy about it. > 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!) I would rather have a big-bang approach. It is easier to document. It might be easier to code, as well. > 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. If I understand it, the adventure branch is where a lot of this refactoring and testing is going to take place. I see no point in doing the same thing in the main branch. Once adventure is right, then we drop support for old-fashioned in main, because adventure becomes main. > 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 :-) I am very grateful to all the darcs developers who are working so hard to address all these issues, and listening to user concerns, and making darcs better (faster, more intuitive). -kolibrie
signature.asc
Description: Digital signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
