I wrote: >> What if there is a new feature or functionality that I happen to need >> that is still only in HEAD? That has happened in the past.
Sittampalam, Ganesh wrote: > That's qualitatively different from the basic requirement of being able > to get at your data, isn't it? Well, on a platform that has been deprecated, or recently EOLed, you just need to get at your data conveniently. Even there it needs to be convenient - those migrations are a big enough job as it is without basic infrastructure tools like the VC getting in your way. But on a platform where you are working actively, you need to be able to work conveniently with your data. For example, a very common use case for darcs is to have a central copy of the repo on a virtual server that team members sync to. That virtual server will likely be running Debian stable or equivalent. The darcs that runs there had better support all repo features that team members are using on their local machines. And also, there are times that people will want to do certain actions directly on the server in a shell. If there are any differences between how the darcs client on servers works and the darcs client those people are in the habit of using, you had better be extremely careful about the nature of those differences. And then there is the use case of people like me who are using prehistoric dinosaur computers - like, three years old - who need to use stable on the desktop. >> If my platform required some particular older tag or branch to >> compile, and there were some reliable easy way to find an always >> up-to-date source of clear instructions how to do that, I suppose >> that would do. It would feel unfriendly though. > Well, that would just be a sufficiently old release. Releases are tagged > too. We could list what releases supported what platforms to satisfy the > "instructions" bit of that. Sure. Plus an example at the top of what darcs command to plug that information into. Or, if it's from a branch, the URL for the appropriate branch. >> If the darcs team decides to disqualify everyone using Debian stable >> and equivalent from contributing to darcs, that of course is up to >> you. I personally have unfortunately not had the time to contribute >> so far *blushes*. > Again, this is moving rather beyond being able to get darcs at all for > your platform. Indeed. > ...whatever the range of GHC releases we support... > there is a substantial risk of breaking things. To > some extent the buildbots help with this, but once they flag a problem > it's still a burden for someone to identify and fix that problem. Yes. Obviously, you want to catch those things long before they get to the build bot. It might be a good idea to have a global cabal configuration that sets up the darcs development environment to make such breakage unlikely. >> The bottom line is: there are Linux users and developers (me one of >> them) who use Debian stable quite heavily. > I'd be interested to know whether development on stable is commonplace. > It feels like a somewhat unnatural thing to do to me, but obviously it's > not for you :-) Not the most common scenario, obviously. But it does happen for rather mundane reasons. And there are other reasons why older platforms need to be kept in mind, such as darcs on virtual servers. Regards, Yitz _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
