Hi all,
I just reread this thread again. Is this one of these situations where *almost
everyone agrees, but the fix just didn't happen*?
In particular, there is still no formal relationship between versions of
the compiler and versions of the testsuite that tests it -- that seems odd!
Can we
Simon and I discussed this a little today. I think there are several
legitimate points made throughout the threads here, but the problem is
clear: consistent builds are difficult, if not legitimately impossible.
That's a very big problem.
Right now, it is far too late into release cycle to do
August 2013 20:31
To: Ryan Newton
Cc: ghc-devs@haskell.org; Edward Kmett
Subject: Re: how to checkout proper submodules
Simon and I discussed this a little today. I think there are several legitimate
points made throughout the threads here, but the problem is clear: consistent
builds are difficult
Of *Austin
Seipp
*Sent:* 22 August 2013 20:31
*To:* Ryan Newton
*Cc:* ghc-devs@haskell.org; Edward Kmett
*Subject:* Re: how to checkout proper submodules
** **
Simon and I discussed this a little today. I think there are several
legitimate points made throughout the threads here
On 09/06/13 17:51, Ian Lynagh wrote:
On Sun, Jun 09, 2013 at 11:15:37AM -0500, Austin Seipp wrote:
I'm referring to Joachim Breitner's work on
splitting the base.
So what's the timeline here?
As soon as possible after 7.8 is branched.
Has there been a decision somewhere on what to do?
. For instance,
libraries/base has newer commits. And of cource, building fails.
Please tell us how to checkout proper submodules against a specific
GHC tree.
--Kazu
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo
On 06/12/2013 12:37 PM, Ian Lynagh wrote:
On Wed, Jun 12, 2013 at 12:54:38AM +0200, Daniel Trstenjak wrote:
I guess [the merge commits] may not cause any actual problems,
but it's certainly nicer
not having them (which is what using submodules gives us).
Just to clarify, my problem isn't so
On Mon, Jun 10, 2013 at 01:13:37PM +0200, Daniel Trstenjak wrote:
On Mon, Jun 10, 2013 at 11:45:22AM +0100, Ian Lynagh wrote:
Is this possible with subtrees?:
* Initially ghc's Cabal repo is at the same commit as upstream
* We make a local commit 123 in Cabal to fix some bug
* Cabal
Hi Ian,
I guess they may not cause any actual problems, but it's certainly nicer
not having them (which is what using submodules gives us).
I don't quite understand how you should get rid of these merge commits
by using submodules, because at the end every submodule is just a git repository
On Mon, Jun 10, 2013 at 1:32 PM, Roman Cheplyaka r...@ro-che.info wrote:
* John Lato jwl...@gmail.com [2013-06-10 07:59:55+0800]
On Mon, Jun 10, 2013 at 1:32 AM, Roman Cheplyaka r...@ro-che.info
wrote:
What I'm trying to say here is that there's hope for a portable base.
Maybe not
Hi Geoffrey,
I am of the opinion that major feature branches should be rebased
*and* that they should then be merged with --no-ff.
I totally agree with you. :-)
--Kazu
___
ghc-devs mailing list
ghc-devs@haskell.org
Hi,
I think you've to differentiate the case of merging a feature branch
into the master branch and the case of merging a local with a remote
branch, like just calling git pull/push on the master branch.
I just wanted to say that first forward merge loses information about
which sequence of
On Mon, 2013-06-10 at 11:45 +0100, Ian Lynagh wrote:
Side note: the fingerprint script *didn't even work* for almost
a year after it was introduced; see commit 73ce2e70.
Which implies that wanting to go back in time is rare, so making it
easy
should be given low weight when considering
On 06/10/2013 11:49 AM, Nicolas Trangez wrote:
On Mon, 2013-06-10 at 11:45 +0100, Ian Lynagh wrote:
Side note: the fingerprint script *didn't even work* for almost
a year after it was introduced; see commit 73ce2e70.
Which implies that wanting to go back in time is rare, so making it
easy
On 08/06/13 08:38, Geoffrey Mainland wrote:
On 06/06/2013 09:44 PM, Simon Marlow wrote:
On 05/06/13 16:59, Ian Lynagh wrote:
On Tue, Jun 04, 2013 at 09:05:58PM -0500, Austin Seipp wrote:
I know we had this discussion sometime recently I think, but can
someone *please* explain why we
Hi Austin,
I apologize for not having read the full email yet (I'm in a hurry right
now), but...
* Austin Seipp ase...@pobox.com [2013-06-09 00:23:22-0500]
-- Let's just put base and testsuite inside the GHC repository
directly. No submodules, no floating repos. Just put it directly
inside
Hi Roman,
On Sun, Jun 9, 2013 at 1:44 AM, Roman Cheplyaka r...@ro-che.info wrote:
I'm a strong -1 on this. As one example, we have forks of base and
ghc-prim for Haskell suite:
https://github.com/haskell-suite/base
https://github.com/haskell-suite/ghc-prim
which would be much more
On Sun, Jun 9, 2013 at 3:47 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote:
I admire your talent for writing emails ;-)
You can be honest and just call them what they are: horribly written novellas.
As you wrote in your email I'm totally for including testsuite into GHC,
because it is
On Sun, Jun 09, 2013 at 11:15:37AM -0500, Austin Seipp wrote:
I'm referring to Joachim Breitner's work on
splitting the base.
So what's the timeline here?
As soon as possible after 7.8 is branched.
Thanks
Ian
___
ghc-devs mailing list
You can be honest and just call them what they are: horribly written
novellas.
Actually, I was thinking that instead of posting to the list you might consider
publishing your
emails as papers on workshops or symposia ;)
for high-traffic repositories, some of the concerns are disconcerning.
Oh, and I've been made aware that git 1.7 and later can checkout a subdirectory
of a repo - this
partially invalidates my previous argument. I'm saying partially, because it is
a bit more
difficult than dealing with a library that has its own repo + it seems that
some potential
contributors
* Austin Seipp ase...@pobox.com [2013-06-09 11:15:37-0500]
Hi Roman,
On Sun, Jun 9, 2013 at 1:44 AM, Roman Cheplyaka r...@ro-che.info wrote:
I'm a strong -1 on this. As one example, we have forks of base and
ghc-prim for Haskell suite:
https://github.com/haskell-suite/base
On Mon, Jun 10, 2013 at 1:32 AM, Roman Cheplyaka r...@ro-che.info wrote:
What I'm trying to say here is that there's hope for a portable base.
Maybe not in the form of split base — I don't know.
But it's the direction we should be moving anyways.
And usurping base by GHC is a move in the
* John Lato jwl...@gmail.com [2013-06-10 07:59:55+0800]
On Mon, Jun 10, 2013 at 1:32 AM, Roman Cheplyaka r...@ro-che.info wrote:
What I'm trying to say here is that there's hope for a portable base.
Maybe not in the form of split base — I don't know.
But it's the direction we should be
On 06/06/2013 09:44 PM, Simon Marlow wrote:
On 05/06/13 16:59, Ian Lynagh wrote:
On Tue, Jun 04, 2013 at 09:05:58PM -0500, Austin Seipp wrote:
I know we had this discussion sometime recently I think, but can
someone *please* explain why we are in this situation of half
submodules, half
On 5 Jun 2013, at 16:47, Austin Seipp wrote:
testsuite and base are also useful for other compilers,
such as nhc98 (and indeed, nhc uses base itself.)
Useful, perhaps, but not actually used in practice. Since the base library
repo moved from darcs to git, I think that ghc is the only
Daniel,
On Wed, 2013-06-05 at 15:49 +0200, Daniel Trstenjak wrote:
Hi Nicolas,
On Wed, Jun 05, 2013 at 03:27:09PM +0200, Nicolas Trangez wrote:
As my experience with submodules is positive (though limimted), could
you elaborate on the difficulties/hassle here?
If you would like to
Hi Kazu,
On Thu, Jun 06, 2013 at 10:42:03AM +0900, Kazu Yamamoto wrote:
Please read A successful Git branching model to know why fast-forward
is not used recently.
I think you've to differentiate the case of merging a feature branch
into the master branch and the case of merging a local with
On 05/06/13 16:59, Ian Lynagh wrote:
On Tue, Jun 04, 2013 at 09:05:58PM -0500, Austin Seipp wrote:
I know we had this discussion sometime recently I think, but can
someone *please* explain why we are in this situation of half
submodules, half random-floating-git-repository-checkouts?
| Cc: ghc-devs@haskell.org
| Subject: Re: how to checkout proper submodules
|
| I absolutely agree here, FWIW. We should only do this if there is a
| clear consensus on doing so and everyone doing active development is
| comfortable with it. And it's entirely possible submodules are
| inadequate
/wiki/Repositories/Upstream.
Simon
| -Original Message-
| From: ghc-devs-boun...@haskell.org [mailto:ghc-devs-boun...@haskell.org]
| On Behalf Of Austin Seipp
| Sent: 05 June 2013 07:35
| To: Johan Tibell
| Cc: ghc-devs@haskell.org
| Subject: Re: how to checkout proper
: 05 June 2013 07:35
| To: Johan Tibell
| Cc: ghc-devs@haskell.org
| Subject: Re: how to checkout proper submodules
|
| I absolutely agree here, FWIW. We should only do this if there is a
| clear consensus on doing so and everyone doing active development is
| comfortable
David Terei wrote:
Either way, I'm glad git bisect may soon work.
Having git bisect work on the GHC tree would be a plus!
Erik
--
--
Erik de Castro Lopo
http://www.mega-nerd.com/
g/trac/ghc/wiki/Repositories/Upstream.
Simon
| -Original Message-
| From: ghc-devs-boun...@haskell.org [mailto:ghc-devs-boun...@haskell.org]
| On Behalf Of Austin Seipp
| Sent: 05 June 2013 07:35
| To: Johan Tibell
| Cc: ghc-devs@haskell.org
| Subject: Re: how to checkout proper submodu
For me the biggest plus of switching to submodules would be keeping GHC and
testsuite in sync. If
there are any reasons not to change in-tree library repos to submodules, then I
would at least
want testsuite to be changed to a submodule.
I also use github for my daily work on GHC and being
On 06/05/2013 10:10 AM, David Terei wrote:
On 5 June 2013 01:43, Manuel M T Chakravarty c...@cse.unsw.edu.au wrote:
I agree with Austin and Johan. It's a bizarre setup. Submodules have their
pain points (which we already have to deal with), but the ability to
properly snapshot and branch the
David Terei davidte...@gmail.com:
On 5 June 2013 01:43, Manuel M T Chakravarty c...@cse.unsw.edu.au wrote:
I agree with Austin and Johan. It's a bizarre setup. Submodules have their
pain points (which we already have to deal with), but the ability to properly
snapshot and branch the whole
checkout bb2795db36b36966697c228315ae20767c4a8753
% git submodule update
But this does not checkout proper submodules. For instance,
libraries/base has newer commits. And of cource, building fails.
Please tell us how to checkout proper submodules against
/Upstream.
Simon
| -Original Message-
| From: ghc-devs-boun...@haskell.org
[mailto:ghc-devs-boun...@haskell.org]
| On Behalf Of Austin Seipp
| Sent: 05 June 2013 07:35
| To: Johan Tibell
| Cc: ghc-devs@haskell.org
| Subject: Re: how to checkout proper submodules
|
| I absolutely
Hi Geoffrey,
I don't know much about subtrees, but that might be another possibility?
the main point about subtrees is, that you've just one repository and
you're merging a directory of this repository with 'git subtree' with
some other git repository.
subtrees and submodules both try to
On Wed, 2013-06-05 at 15:24 +0200, Daniel Trstenjak wrote:
because a lot of workflows (like branching) are such
a hassle with submodules.
As my experience with submodules is positive (though limimted), could
you elaborate on the difficulties/hassle here?
Thanks,
Nicolas
Hi Nicolas,
On Wed, Jun 05, 2013 at 03:27:09PM +0200, Nicolas Trangez wrote:
As my experience with submodules is positive (though limimted), could
you elaborate on the difficulties/hassle here?
If you would like to develop some kind of feature which involves
changes on multiple
I'm back after sleep.
A few points:
1) Subtree is - in my opinion - basically not an option. It has a nice
workflow from the small amount of time I spent with it. But it's not
installed by default with git, it's unclear if it ever will be.
Although subtree gives the appearance of a unified
1) We could now delete ./sync-all if this happened.
In that case I would vote for replacing sync-all with a script that aids in
managing branches in
multiple subrepos. I implemented such a script for myself in a very ad hoc way.
Having something
more robust would be great.
2) One thing this
Hi Austin,
On Wed, Jun 05, 2013 at 09:41:56AM -0500, Austin Seipp wrote:
But it's not installed by default with git, it's unclear if it ever will be.
I think subtree has been part of git since 1.7.x .
I have just installed the default git package (git 1.8.1.2) of Ubuntu
13.04 and the subtree
On Wed, Jun 5, 2013 at 10:20 AM, Daniel Trstenjak
daniel.trsten...@gmail.com wrote:
I think subtree has been part of git since 1.7.x .
I have just installed the default git package (git 1.8.1.2) of Ubuntu
13.04 and the subtree command is just there.
It's *part* of mainline git, but it is not
On Tue, Jun 04, 2013 at 09:05:58PM -0500, Austin Seipp wrote:
I know we had this discussion sometime recently I think, but can
someone *please* explain why we are in this situation of half
submodules, half random-floating-git-repository-checkouts?
Submodules are very handy for libraries that
I think that testsuite should be included in the main GHC repo. I don't recall
any other project
that has its tests placed in a separate repository. The nhc argument doesn't
convince me - after
all, most test that are added nowadays are GHC specific.
Janek
There are a lot of things to recommend moving to github. I do hate
(non-empty) merge commits, though, so I'm not a fan of github's pull
request mechanism.
Please read A successful Git branching model to know why fast-forward
is not used recently.
Git flow:
has newer commits. And of cource, building fails.
Please tell us how to checkout proper submodules against a specific
GHC tree.
--Kazu
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
the range of commits, so I did:
% git checkout bb2795db36b36966697c228315ae20767c4a8753
% git submodule update
But this does not checkout proper submodules. For instance,
libraries/base has newer commits. And of cource, building fails.
Please tell us how to checkout proper submodules
submodule update
But this does not checkout proper submodules. For instance,
libraries/base has newer commits. And of cource, building fails.
Please tell us how to checkout proper submodules against a
specific GHC tree.
--Kazu
Is there a reason why some submodules are proper git repos
submodules. For instance,
libraries/base has newer commits. And of cource, building fails.
Please tell us how to checkout proper submodules against a specific
GHC tree.
--Kazu
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org
On Tue, Jun 4, 2013 at 7:05 PM, Austin Seipp ase...@pobox.com wrote:
I know we had this discussion sometime recently I think, but can
someone *please* explain why we are in this situation of half
submodules, half random-floating-git-repository-checkouts? It's
terrible. I'm frankly surprised
54 matches
Mail list logo
