On Tue, Nov 16, 2010 at 00:48:29 +0100, Guillaume Hoffmann wrote: > Possible options for OF support in 2.8 are:
Keeping in mind that we already agree in principle that we should try remove old-fashioned support. The question is if it's practical to aim for it in 2.8. If we don't reach any sort of consensus, I offer to commit to removing OF support by Darcs 2.8 if you are willing to do the job of adequately preparing users for what's ahead. I think this means getting the communications under control (darcs users may not read darcs-users or any darcs mediums) and also making sure that Darcs 2.5.1 does the right things. > 1) Keeping full OF support > 2) Keeping all read-only support > 3) Keeping only darcs optimize --upgrade support We didn't do enough to prepare darcs users (who don't all read the mailing list) for withdrawing old-fashioned. If we want to remove old-fashioned support in 2.8, we should probably release a darcs 2.5.1 which works harder at preparing users for what's ahead. > My proposal on how we hack our way towards this objective is to make a > series of easily reviewable patches, that remove features associated > to OF repositories one after another. The following commands can be > successively removed: optimize --relink-pristine, get --old, put > --old, init --old, and then (one by one) all commands that write into > repositories. Whatsnew and diff should be deprecated for OF also: > although they are read-only, they require a pristine. Easily reviewable self-contained chunks are indeed more likely to land in HEAD. > Lastly, I do not think we should commit to the contract "if, by 2.8, > hashed repos are not as fast as OF repos we should put back full OF > support in the code". I don't think anybody was suggesting that :-) If it helps, I think that we should shift our general emphasis from performance to code quality. This includes being willing to make cleanups that introduce performance regressions and letting certain performance regressions stay regressed. It's a different story if we introduce something catastrophic. I have a rough outline in my head that goes like this: - short term : performance - medium term : code quality - long term : darcs 3 I think we're in the transition between short/medium term. We still have fast get over networks and faster annotate lined up, but after that, darcs library all the way? -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> For a faster response, try +44 (0)1273 64 2905 or xmpp:ko...@jabber.fr (Jabber or Google Talk only)
signature.asc
Description: Digital signature
_______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users