Version control systems

[Duncan Coutts]

On Sat, 2008-08-09 at 15:46 +1000, Manuel M T Chakravarty wrote:

> Raising the bar for developers to contribute to a project has been  
> proven to be a very bad idea many times.  Let's not take GHC down that  
> path.

I don't especially relish having to learn another vcs tool or raising
the bar for contributions to Cabal either (we have lots of people who
make small one-off contributions).

Duncan

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Isaac Dupree]

Duncan Coutts wrote:
> On Sat, 2008-08-09 at 15:46 +1000, Manuel M T Chakravarty wrote:
>
>> Raising the bar for developers to contribute to a project has been  
>> proven to be a very bad idea many times.  Let's not take GHC down that  
>> path.
>
> I don't especially relish having to learn another vcs tool or raising
> the bar for contributions to Cabal either (we have lots of people who
> make small one-off contributions).

I wonder how many of the libraries are "core" in that they
need to be changed a lot for GHC?
- all the ones that depend on GHC internals, such as base.
(Except the current system has many of them use preprocessor
conditionals so that can they depend on various compilers'
internals, including nhc98 and hugs?  Because a lot of that
code is actually shared between implementations)
- Cabal, since it's needing a lot of extension to make GHC
work with it.

Do boot-libraries like unix typically need work by GHC devs?

On the other hand, it's looking like there's enough
intersection between GHC and other-haskell that it's not
such a helpful path to pursue.

not quite related: I wonder about various haskell libs
switching to darcs2 format.  A few new programs use it
already.  As distros include darcs2, it should become less
painful.  The conversion is less painful for code that's
branched less.  So maybe in the future a lot of Haskell libs
will be in the superior darcs2 format.

what an unpleasant situation!  But cross-converting between
darcs and git format for the same repo is probably even worse.

Last time I tried the darcs-all script (maybe a month ago,
using darcs 2.0.2), IIRC, it hung, or had some other problem
in one of the libraries.  Even though it was a clean copy
that I'd only ever pulled into (many times, and was getted
by darcs-1.0.9, but still).  And darcs-all on the libraries
has always been a slow sequential task.  So I'm not actually
all that enamoured of darcs for ghc development, even for
the libs.  Since I couldn't update anymore (despite going
into ghc-head/libraries/something and mucking around with
darcs-revert and such), I just deleted the tree and decided
to wait until GHC switches VCS before getting a new copy.
(trying git-cloning ghc.git sometime, took about 10 minutes,
nearly no CPU time, and 80 MB, so I'm pretty happy about
that random experience, but I didn't try to do anything with
the repo)

-Isaac
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Ian Lynagh]

On Sat, Aug 09, 2008 at 01:32:51AM +0100, Duncan Coutts wrote:
>
> If there's some way of having automated git mirrors of the upstream
> darcs repos then that's might be convenient for people building ghc.

I don't think that that really helps. If all you want to do is build
then the sync-all script will do the get/pull for you (as long as you
have both git and darcs installed).

If you want to make any changes at all then you really need to be using
the "native" repo format.

If someone thinks it is worth doing then it is possible, though.


Thanks
Ian

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Ian Lynagh]

On Sat, Aug 09, 2008 at 03:46:50PM +1000, Manuel M T Chakravarty wrote:
>
> Don was excited about getting more people to look at the source  
> when it is in git (see the comments he posted from reddit).

I am skeptical that this initial excitement and cloning will translate
into more developers. Also, for someone who's never used either VCS, I
think the overhead of learning to use darcs is far lower than of
learning to use git.

The move to git is more likely to help by not driving away people who
have had problems working with GHC in darcs, than by attracting
developers in the first place. New GHC developers come from GHC users,
not darcs/git users.

> I am not talking about all libs, I am talking about the core libs.  
> Most developers of the core libs are also GHC developers.

I'm not sure that's true. e.g. Malcolm and Ross both commit to the
bootlibs, and we get a lot of patches from various people in the
community.

> I *strongly* object to moving to git before this isn't sorted out.

FWIW, personally I would prefer staying with darcs. I prefer its
underlying philosophy, and I find its UI far more intuitive and easy to
use.

I don't suffer from its problems, though - but then, I don't maintain a
long-running HEAD branch, and I mostly don't use it on Windows.

However, there certainly are a number of people who are having problems
working with darcs (although in some cases this may be because they are
working in a way incompatible with darcs, e.g. one person had replaced
libraries/ with a symlink, for reasons he didn't explain).

Given darcs certainly has some problems, and I seem to be in a minority,
I don't feel I can stand in the way of a move. But I think we need a
wider discussion before we can think about moving the bootlibs to git.

If we are going to have a changeover, then the most convenient time in
GHC's development cycle to make it is in 4 or 5 weeks time.


Thanks
Ian

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Don Stewart-2]

chak:

> Ian Lynagh:
> >On Fri, Aug 08, 2008 at 12:04:15PM +1000, Manuel M T Chakravarty  
> >wrote:
> >>
> >>I seriously hope the plan is to move all *core* libraries (including
> >>GHC's cabal repo) etc over to git, too.  In other word, everything
> >>that you need to build the development version of GHC should come via
> >>git.  Having a mix of VCSs would be the worst option of all.
> >
> >No, the plan is to move only the GHC and testsuite repos to git, as  
> >the
> >others are also used by hugs, nhc98, etc.
> >
> >It would be possible to move GHC's Cabal repo over too, as that is
> >private to GHC, but given the other libraries will be using darcs  
> >anyway
> >I think it is simpler to keep all darcs repos using the same VCS.
>
> I think all *core* libraries must switch.  Seriously, requiring GHC  
> developer to use a mix of two vcs during development is a Very Bad  
> Idea.

I agree with this.

As Audrey says, you have to lower the barrier to entry. That means:

    * one build system
    * one vcs

to build ghc (and anything it requires, such as the core libraries).

This is a chance to make a big step towards accessibility, let's make that step.

-- Don
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Don Stewart-2]

dons:

> chak:
> > Ian Lynagh:
> > >On Fri, Aug 08, 2008 at 12:04:15PM +1000, Manuel M T Chakravarty  
> > >wrote:
> > >>
> > >>I seriously hope the plan is to move all *core* libraries (including
> > >>GHC's cabal repo) etc over to git, too.  In other word, everything
> > >>that you need to build the development version of GHC should come via
> > >>git.  Having a mix of VCSs would be the worst option of all.
> > >
> > >No, the plan is to move only the GHC and testsuite repos to git, as  
> > >the
> > >others are also used by hugs, nhc98, etc.
> > >
> > >It would be possible to move GHC's Cabal repo over too, as that is
> > >private to GHC, but given the other libraries will be using darcs  
> > >anyway
> > >I think it is simpler to keep all darcs repos using the same VCS.
> >
> > I think all *core* libraries must switch.  Seriously, requiring GHC  
> > developer to use a mix of two vcs during development is a Very Bad  
> > Idea.
>
> I agree with this.
>
> As Audrey says, you have to lower the barrier to entry. That means:
>
>     * one build system
>     * one vcs
>
> to build ghc (and anything it requires, such as the core libraries).
>
> This is a chance to make a big step towards accessibility, let's make that step.

I just want to add to this. We're offering an unusual product: a lazy,
purely functional language. This already separates us from the
mainstream. So how to we ensure we minimise the stress of adopting
something so unfamiliar?

By ensuring that in all other respects the environment they have to
learn is familiar and simple.

I think we risk isolating oursevles yet further -- and creating new
barriers to adoption, beyond those we can't avoid -- by adding more
complicated dependencies (two revision control systems, one of which,
darcs, is now firmly out of the maintstream).

Instead, if we just use ubiquitous, common tools -- like git -- for
everything, we minimise the pain for people, and sit firmly in the
mainstream of open source.

If anything has been learnt by Spencer and I while working on xmonad,
is:
    dependencies, dependencies, dependencies

reduce these, and you gain eyeballs, and ultimately developers. Increase
these, and you end up isolated and marginalised.

So let's capitalise on this switch to git, and take the opportunity to
remove one big dependency from the system.

-- Don
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Malcolm Wallace]

>>>> I seriously hope the plan is to move all *core* libraries  
>>>> (including
>>>> GHC's cabal repo) etc over to git, too.

>    * one build system
>    * one vcs
> This is a chance to make a big step towards accessibility, let's  
> make that step.

Ultimately, I don't think git would make ghc any more accessible to  
new contributors.  Darcs is not especially offputting to any beginner  
who already knows something about VCS in general.

What the move to git is about, is making life easier for the  
*existing* HQ and core contributors.  Evaluate it on that basis, and  
not in terms of unknown (and unknowable) benefits to current non-
contributors.  Indeed, you should also consider how many contributors  
you might lose in a move.

I do hear some significant current contributors having doubts. I can  
certainly appreciate that having to run 2 VCS in parallel might be  
confusing and simply make matters worse than at present.

The libraries question is a difficult one.  We have made a lot of  
effort over the last 5 years to build infrastructure and code that is  
shared and portable across multiple implementations of the language.  
Is this the time to fork those supposedly "common" core libraries into  
ghc versions vs the rest?

As someone who is not a contributor to GHC, and has never experienced  
anything more than trivial problems with darcs, I have not felt  
qualified to comment on the proposal to change GHC's VCS.  But as a  
frequent fixer of breakage in the core libraries, I would be reluctant  
to have to move to a different VCS there.  If the core libraries do  
move, it will be increasingly difficult to avoid also needing to move  
nhc98 and Hugs and goodness-knows how many other libraries.  For me,  
it would be un-forced, annoying, and I may not have the extra time  
available to keep up.

So there is a danger that the community will be left with a single  
(albeit very high quality) compiler, with no need for a Haskell Prime  
(or any other Standard) in future.

If there are technical solutions that can reduce the pain, whilst  
keeping multiple stake-holders happy, then I think they should be  
investigated.

Regards,
     Malcolm
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Norman Ramsey]

As a very part-time, temporarily inactive GHC developer I will offer
some opinions which should carry no weight:

  * When I saw the announcement, I cheered!  Last fall, I lost 2 weeks
    of a 9-week visit to darcs hell.  While the alleged features may
    be alluring, the software simply doesn't do what it says on the
    box.  The highly touted 'theory of patches' is not published
    anywhere in any form that can be understood and checked by anyone
    with a little bit of mathematics (e.g., group theory or algebra).
    All these truths make me eager to be rid of darcs.

  * It seems clear that git offers a richer user interface than darcs
    and that the UI is harder to master.  Moreover, because everyone I
    have talked to finds the git documentation less than completely
    helpful, git is probably harder to learn than darcs.  Git's
    advantages are that it is robust, fast, and popular.

  * A number of people I trust and respect have urged me to adopt git.
    Since 2005, nobody has urged me to adopt darcs.  A number of
    people I trust and respect have said they wished to abandon darcs.
    Nobody has suggested abandoning git.

  * I violently agree with whomever (Don? Malcolm?) said that the
    Haskell community will prosper to the degree that we have *one*
    build system and *one* version-control system.  And when the build
    system or version-control system is standard, we gain eyeballs and
    developers.  I haven't found a standard build system that I am
    willing to use, but I think git is good enough to be used.

  * Our long-term goal should be to get the *entire* Haskell
    development community to agree on a version-control system---one
    that is not darcs.  We should expect this process to take several
    years, and we should expect it to cost money.  Would Microsoft or
    Galois or York or other large players be willing to donate part of
    an expert's time to migrate to the new version-control system?

I'm no particular fan of git.  But in a worse-is-better sort of way, I
think it's in---it will fill the niche of free, distributed version
control.  It would be good to identify a way of helping to smooth the
path not only for GHC and *all* the libraries but for Hugs, York,
xmonad, everybody.


Norman, whose most popular open-source software still lives under RCS!
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Manuel M T Chakravarty]

Duncan Coutts:

> On Sat, 2008-08-09 at 15:46 +1000, Manuel M T Chakravarty wrote:
>
>> Raising the bar for developers to contribute to a project has been
>> proven to be a very bad idea many times.  Let's not take GHC down  
>> that
>> path.
>
> I don't especially relish having to learn another vcs tool or raising
> the bar for contributions to Cabal either (we have lots of people who
> make small one-off contributions).

I don't think it matters what vcs Cabal uses.  GHC does already for a  
while use a separate repo for its version of Cabal, and the GHC Cabal  
repo needs to be explicitly updated to ensure that changes to Cabal do  
not randomly break GHC.  To be honest, if I had to say anything, I  
would say that GHC has to uses fixed, stable versions of Cabal (like  
it does of gmp).  So, it really doesn't matter what vcs Cabal uses.

A completely different matter are libraries like base which are deeply  
connected to GHC.

Manuel

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Manuel M T Chakravarty]

Isaac Dupree:

> Duncan Coutts wrote:
>> On Sat, 2008-08-09 at 15:46 +1000, Manuel M T Chakravarty wrote:
>>> Raising the bar for developers to contribute to a project has  
>>> been  proven to be a very bad idea many times.  Let's not take GHC  
>>> down that  path.
>> I don't especially relish having to learn another vcs tool or raising
>> the bar for contributions to Cabal either (we have lots of people who
>> make small one-off contributions).
>
> I wonder how many of the libraries are "core" in that they need to  
> be changed a lot for GHC?

The boot libraries, ie, those needed to build the HEAD of the ghc repo:

   SUBDIRS  = ghc-prim $(INTEGER_LIBRARY) base array packedstring
   SUBDIRS += containers bytestring old-locale old-time filepath  
directory
   ifeq "$(GhcLibsWithUnix)" "YES"
   SUBDIRS += unix
   endif
   ifeq "$(Windows)" "YES"
   SUBDIRS += $(wildcard Win32)
   endif
   SUBDIRS += process pretty hpc template-haskell editline Cabal  
random haskell98

Here Cabal, is ghc variant of the Cabal repo, not the actually Cabal  
head.

The whole point is to make sure that anybody who decides to hack GHC  
needs to install and learn just one vcs, not two.

Manuel

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Manuel M T Chakravarty]

Ian Lynagh:
> On Sat, Aug 09, 2008 at 03:46:50PM +1000, Manuel M T Chakravarty  
> wrote:
>> I am not talking about all libs, I am talking about the core libs.
>> Most developers of the core libs are also GHC developers.
>
> I'm not sure that's true. e.g. Malcolm and Ross both commit to the
> bootlibs, and we get a lot of patches from various people in the
> community.

Ross does commit patches to ghc (according to darcs changes).  So,  
either he stops that or has to learn git anyway.

I don't think we are talking about random contributions from the  
community.  If anything, we need to compare two numbers

(1) developers who need to start using git when the ghc repo changes and
(2) library developers (ie, people with commit bits regularly  
contributing to the boot libs) who do not contribute to ghc and hence  
could avoid learning git if the boot libs stay in a darcs repo.

>> I *strongly* object to moving to git before this isn't sorted out.
>
> FWIW, personally I would prefer staying with darcs. I prefer its
> underlying philosophy, and I find its UI far more intuitive and easy  
> to
> use.

Personally, I am more than happy to stay with darcs, too, but my  
understanding was that at least the Simons decided that we are going  
to move from darcs to git.  All I am saying is that whatever vcs ghc  
uses, you need to be able to *easily* get, modify, and commit patches  
to the HEAD and the boot libs with *just one* vcs.  Using two vcs is  
going to make the current situation worse, not better.

For example, SimonPJ said one reason for switching vcs is that interns  
had trouble getting started because they did have trouble obtaining  
the head as darcs caused them grief.  If the boot libs stay under  
darcs control.  Nothing is one, the same interns still won't get going  
any quicker.  Presumably, they are going to take even longer, because  
they can now get into trouble with darcs and git.

We want to lower the barrier to entry, not raise it.  By effectively  
adding a complications (namely git) and not removing any, matters will  
get worse.

Manuel

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Manuel M T Chakravarty]

Listen to Don, he is a wise man!

Manuel

Don Stewart:

>> I agree with this.
>>
>> As Audrey says, you have to lower the barrier to entry. That means:
>>
>>    * one build system
>>    * one vcs
>>
>> to build ghc (and anything it requires, such as the core libraries).
>>
>> This is a chance to make a big step towards accessibility, let's  
>> make that step.
>
> I just want to add to this. We're offering an unusual product: a lazy,
> purely functional language. This already separates us from the
> mainstream. So how to we ensure we minimise the stress of adopting
> something so unfamiliar?
>
> By ensuring that in all other respects the environment they have to
> learn is familiar and simple.
>
> I think we risk isolating oursevles yet further -- and creating new
> barriers to adoption, beyond those we can't avoid -- by adding more
> complicated dependencies (two revision control systems, one of which,
> darcs, is now firmly out of the maintstream).
>
> Instead, if we just use ubiquitous, common tools -- like git -- for
> everything, we minimise the pain for people, and sit firmly in the
> mainstream of open source.
>
> If anything has been learnt by Spencer and I while working on xmonad,
> is:
>    dependencies, dependencies, dependencies
>
> reduce these, and you gain eyeballs, and ultimately developers.  
> Increase
> these, and you end up isolated and marginalised.
>
> So let's capitalise on this switch to git, and take the opportunity to
> remove one big dependency from the system.
>
> -- Don

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Roman Leshchinskiy]

On 10/08/2008, at 14:40, Manuel M T Chakravarty wrote:

> Personally, I am more than happy to stay with darcs, too, but my  
> understanding was that at least the Simons decided that we are going  
> to move from darcs to git.  All I am saying is that whatever vcs ghc  
> uses, you need to be able to *easily* get, modify, and commit  
> patches to the HEAD and the boot libs with *just one* vcs.  Using  
> two vcs is going to make the current situation worse, not better.


I suspect that if GHC switches to git, it will become the standard vcs  
in the Haskell community sooner or later. Expecting that people  
(especially newcomers) will use different vcs for different libraries/
compilers is just unrealistic. Really, why should they? Any advantages  
in usability that darcs might have over git will be overshadowed by  
the inconvenience of having to remember two different sets of  
commands. I expect that many new projects will use git and old  
projects will start switching to it over time. So if the move is made,  
it should IMO include as big a chunk of the infrastructure as  
possible. Eventually, it will migrate to git anyway and the earlier it  
does, the simpler life will be for the developers.

As to whether the switch should be made at all, I'm not sure. I've had  
my share of problems with darcs and I don't think it's suitable for a  
project of GHC's size at the moment. On the other hand, I suspect that  
a mixture of git and darcs repos will be even more problematic than  
what we have now. Maybe investing some time in fixing the most obvious  
darcs problems would be a better solution?

Roman


_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Roman Leshchinskiy]

On 10/08/2008, at 05:38, Don Stewart wrote:

> Instead, if we just use ubiquitous, common tools -- like git -- for
> everything, we minimise the pain for people, and sit firmly in the
> mainstream of open source.

While I agree with this in general, I'm not sure it really applies to  
vcs (especially darcs) all that much. I don't think anyone who has  
ever worked with a vcs will need more than a day to learn how to use  
darcs (or any other sane vcs, for that matter). Really, the problem  
with darcs is not that it is not mainstream; rather, it's just that it  
simply doesn't work sometimes.

Roman


_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Jason Dagit-2]

On Sat, Aug 9, 2008 at 10:44 PM, Roman Leshchinskiy <rl@...> wrote:

Maybe investing some time in fixing the most obvious darcs problems would be a better solution?

We're working on that over at Darcs HQ, but there is no guarantee that we'd come close to fixing the problems within the 4-5 week window that Ian mentioned.  Supposing that the main problems GHC has with darcs 2 format get solved in the next month, would that give GHC reason enough to keep using darcs?  It seems many of you are eager to use git; perhaps even if darcs was working to satisfaction.

People will be working on making darcs work better with the GHC repo as a test case either way.  And personally, since I'm not a GHC dev, the decision doesn't affect my life.  Having said that, I'm still obviously biased.  I'd love for darcs to work well enough that this never came up.

Let me throw out one more idea:
What if, as a GHC contributor, I could pick equally between git and darcs?  My understanding is that, while not optimal, you could use tailor[1] to synchronize a darcs repository with a git one.  Offer up both repositories and keep them in sync.  Let the masses decide?

Jason

[1] http://progetti.arstecnica.it/tailor

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Brandon S. Allbery KF8NH]

On 2008 Aug 10, at 2:12, Jason Dagit wrote:

On Sat, Aug 9, 2008 at 10:44 PM, Roman Leshchinskiy <rl@...> wrote:

Maybe investing some time in fixing the most obvious darcs problems would be a better solution?

We're working on that over at Darcs HQ, but there is no guarantee that we'd come close to fixing the problems within the 4-5 week window that Ian mentioned.  Supposing that the main problems GHC has with darcs 2 format get solved in the next month, would that give GHC reason enough to keep using darcs?  It seems many of you are eager to use git; perhaps even if darcs was working to satisfaction.

Some people are.  I'm more on the side of "are we creating a bigger problem than we already have?"  It's not at all clear to me that switching to git would solve more problems than it would cause --- and if you toss in core libraries possibly needing to stay in darcs, or other projects being abruptly forced to switch to git because the core libs did, it's pretty clearly on the "biting off more than we can chew" side of things.

Let me throw out one more idea:
What if, as a GHC contributor, I could pick equally between git and darcs?  My understanding is that, while not optimal, you could use tailor[1] to synchronize a darcs repository with a git one.  Offer up both repositories and keep them in sync.  Let the masses decide?

There has been some discussion along those lines, but doing that bidirectionally is logitically difficult.

-- 

brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@...

system administrator [openafs,heimdal,too many hats] allbery@...

electrical and computer engineering, carnegie mellon university    KF8NH

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Manuel M T Chakravarty]

Malcolm Wallace:

>>>>> I seriously hope the plan is to move all *core* libraries  
>>>>> (including
>>>>> GHC's cabal repo) etc over to git, too.
>
>>   * one build system
>>   * one vcs
>> This is a chance to make a big step towards accessibility, let's  
>> make that step.
>
> Ultimately, I don't think git would make ghc any more accessible to  
> new contributors.  Darcs is not especially offputting to any  
> beginner who already knows something about VCS in general.
>
> What the move to git is about, is making life easier for the  
> *existing* HQ and core contributors.  Evaluate it on that basis, and  
> not in terms of unknown (and unknowable) benefits to current non-
> contributors.  Indeed, you should also consider how many  
> contributors you might lose in a move.

I am not advocating to move.  I am just saying, if ghc moves, every  
component needs to move on which the HEAD build depends and that is  
needed in its current development form (eg, *not* alex, happy, cabal).

> I do hear some significant current contributors having doubts. I can  
> certainly appreciate that having to run 2 VCS in parallel might be  
> confusing and simply make matters worse than at present.

It is confusing and it is going to make matters worse as two failure  
points are worse than one.  And two extra tools to learn worse than one.

> The libraries question is a difficult one.  We have made a lot of  
> effort over the last 5 years to build infrastructure and code that  
> is shared and portable across multiple implementations of the  
> language.  Is this the time to fork those supposedly "common" core  
> libraries into ghc versions vs the rest?

It would be a pity to fork, but to be honest, I'd rather fork the libs  
than have to use two vcs for GHC.  The only other alternative is to  
decouple more library releases from ghc releases.

Manuel

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Manuel M T Chakravarty]

Jason Dagit:

> On Sat, Aug 9, 2008 at 10:44 PM, Roman Leshchinskiy <rl@...
> > wrote:
>
> Maybe investing some time in fixing the most obvious darcs problems  
> would be a better solution?
>
> We're working on that over at Darcs HQ, but there is no guarantee  
> that we'd come close to fixing the problems within the 4-5 week  
> window that Ian mentioned.  Supposing that the main problems GHC has  
> with darcs 2 format get solved in the next month, would that give  
> GHC reason enough to keep using darcs?  It seems many of you are  
> eager to use git; perhaps even if darcs was working to satisfaction.
>
> People will be working on making darcs work better with the GHC repo  
> as a test case either way.  And personally, since I'm not a GHC dev,  
> the decision doesn't affect my life.  Having said that, I'm still  
> obviously biased.  I'd love for darcs to work well enough that this  
> never came up.

Same here, and fwiw I won't change any of my many other darcs repos  
any time soon.

However, as I have said before, if ghc is to switch, it must be a  
clean switch, and no messy use of two vcs at the same time for ghc and  
boot libs.

> Let me throw out one more idea:
> What if, as a GHC contributor, I could pick equally between git and  
> darcs?  My understanding is that, while not optimal, you could use  
> tailor[1] to synchronize a darcs repository with a git one.  Offer  
> up both repositories and keep them in sync.  Let the masses decide?

I don't think that this technical feasible.  I used tailor once to  
convert a CVS repo to darcs, and while that was better than throwing  
away the history, it was pretty messy and nothing that you would want  
to do on a regular basis.  Besides, even if the actual conversion  
would work smoothly (which I strongly doubt), you'd immediately be  
faced with problems of atomicity and associated race conditions of  
commits to the two repos.

Manuel

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Ian Lynagh]

On Sat, Aug 09, 2008 at 06:56:23PM -0400, Norman Ramsey wrote:

>
>   * I violently agree with whomever (Don? Malcolm?) said that the
>     Haskell community will prosper to the degree that we have *one*
>     build system and *one* version-control system.  And when the build
>     system or version-control system is standard, we gain eyeballs and
>     developers.  I haven't found a standard build system that I am
>     willing to use, but I think git is good enough to be used.
>
>   * Our long-term goal should be to get the *entire* Haskell
>     development community to agree on a version-control system---one
>     that is not darcs.  We should expect this process to take several
>     years, and we should expect it to cost money.  Would Microsoft or
>     Galois or York or other large players be willing to donate part of
>     an expert's time to migrate to the new version-control system?

It is, of course, up to people with money what they spend it on, but
personally I would much prefer to see money spent on making darcs
better, for reasons I won't repeat again.

If it makes a difference, I would expect a research paper on how
conflictors work would be easy to produce as a side-effect, as we would
need to get a good description of how it works, and proofs that it does,
anyway.

Also, I expect we could get a BSDed darcs as a result.


Thanks
Ian

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Ian Lynagh]

On Sun, Aug 10, 2008 at 02:16:25PM +1000, Manuel M T Chakravarty wrote:

> Duncan Coutts:
> >
> >I don't especially relish having to learn another vcs tool or raising
> >the bar for contributions to Cabal either (we have lots of people who
> >make small one-off contributions).
>
> I don't think it matters what vcs Cabal uses.  GHC does already for a  
> while use a separate repo for its version of Cabal, and the GHC Cabal  
> repo needs to be explicitly updated to ensure that changes to Cabal do  
> not randomly break GHC.  To be honest, if I had to say anything, I  
> would say that GHC has to uses fixed, stable versions of Cabal (like  
> it does of gmp).  So, it really doesn't matter what vcs Cabal uses.

Unless we do get to a point where we are literally using tarballs[1] of
Cabal, I don't think using a mixture of VCSs for Cabal is a good idea.
Having to convert patches from one VCS format to the other sounds like a
recipe for a lot of pain and suffering.

[1] which I think is a bad idea anyway, as it makes it a lot more hassle
to fix Cabal bugs that GHC+bootlibs expose.


Thanks
Ian

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users