Re: Libraries in the repo

I don't think the current situation has worked well, due to people forgetting to push/send to the upstream repos, but if we use a prehook script to stop people accidentally breaking the rules then (1) is probably the best solution for the HEAD. For stable branches, in order to avoid releasing wit

Re: Libraries in the repo

2009/9/11 Ian Lynagh : > On Fri, Aug 28, 2009 at 10:06:36AM +0100, Simon Marlow wrote: >> On 27/08/2009 11:25, José Pedro Magalhães wrote: >>> Hello, >>> >>> On Wed, Aug 26, 2009 at 18:15, Simon Marlow >> > wrote: >>> >>> >>>       * Boot libraries are of several kinds: >

Re: Libraries in the repo

On Fri, Aug 28, 2009 at 10:06:36AM +0100, Simon Marlow wrote: > On 27/08/2009 11:25, José Pedro Magalhães wrote: >> Hello, >> >> On Wed, Aug 26, 2009 at 18:15, Simon Marlow > > wrote: >> >> >> * Boot libraries are of several kinds: >>- INDEPENDENT: Independe

Re: Libraries in the repo

Duncan Coutts wrote: On Fri, 2009-08-28 at 11:42 +0100, Simon Marlow wrote: Can anyone think of a good reason not to upgrade darcs to 2.3.0 on darcs.haskell.org? I can think of 3 reasons to do so: - this script, for preventing accidental divergence from upstream - faster pushes, due to t

Re: Libraries in the repo

On Fri, 2009-08-28 at 11:42 +0100, Simon Marlow wrote: > Can anyone think of a good reason not to upgrade darcs to 2.3.0 on > darcs.haskell.org? I can think of 3 reasons to do so: > > - this script, for preventing accidental divergence from upstream > - faster pushes, due to transfer-mode >

Re: Libraries in the repo

On 28/08/2009 10:05, Simon Marlow wrote: On 27/08/2009 11:37, Sittampalam, Ganesh wrote: Simon Marlow wrote: Simon Marlow wrote: I suggest if we stick with the independent repo approach that we have some automation to check that changes are indeed getting pushed upstream. [snip unhelpful sug

Re: Libraries in the repo

On 27/08/2009 11:25, José Pedro Magalhães wrote: Hello, On Wed, Aug 26, 2009 at 18:15, Simon Marlow mailto:marlo...@gmail.com>> wrote: * Boot libraries are of several kinds: - INDEPENDENT: Independently maintained (e.g. time, haskeline) - COUPLED: Tightly coupled to GHC, bu

Re: Libraries in the repo

On 27/08/2009 11:37, Sittampalam, Ganesh wrote: Simon Marlow wrote: Simon Marlow wrote: I suggest if we stick with the independent repo approach that we have some automation to check that changes are indeed getting pushed upstream. [snip unhelpful suggestion from me] Yes, it tells you that

Re: Libraries in the repo

Incedentally, the reason I'd like us to make a decision on this now is because I'm about to add two new boot libraries: - binary, to support a binary cache of GHC's package database (INDEPENDENT) - bin-package-db, the code to read and write the binary package database (SPECIFIC, sha

RE: Libraries in the repo

Simon Marlow wrote: Simon Marlow wrote: >> >> I suggest if we stick with the independent repo approach that we >> have some automation to check that changes are indeed getting >> pushed upstream. [snip unhelpful suggestion from me] > > Yes, it tells you that you've screwed up

Re: Libraries in the repo

On 27/08/2009 11:24, Sittampalam, Ganesh wrote: Simon Marlow wrote: On 27/08/2009 11:18, Sittampalam, Ganesh wrote: Simon Marlow wrote: I suggest if we stick with the independent repo approach that we have some automation to check that changes are indeed getting pushed upstream. Agreed. Ca

Re: Libraries in the repo

On 27/08/2009 00:55, Don Stewart wrote: marlowsd: Simon and I have been chatting about how we accommodate libraries in the GHC repository. After previous discussion on this list, GHC has been gradually migrating towards having snapshots of libraries kept as tarballs in the repo (currently only

Re: Libraries in the repo

Hello, On Wed, Aug 26, 2009 at 18:15, Simon Marlow wrote: > > * Boot libraries are of several kinds: > - INDEPENDENT: Independently maintained (e.g. time, haskeline) > - COUPLED: Tightly coupled to GHC, but used by others (base) > - SPECIFIC: Totally specific to GHC (e.g. template-haskell

RE: Libraries in the repo

Simon Marlow wrote: > On 27/08/2009 11:18, Sittampalam, Ganesh wrote: >> Simon Marlow wrote: I suggest if we stick with the independent repo approach that we have some automation to check that changes are indeed getting pushed upstream. >>> >>> Agreed. Can you think of an eas

Re: Libraries in the repo

On 27/08/2009 11:18, Sittampalam, Ganesh wrote: Simon Marlow wrote: I suggest if we stick with the independent repo approach that we have some automation to check that changes are indeed getting pushed upstream. Agreed. Can you think of an easy way to automate it? How about a cronjob that

RE: Libraries in the repo

Simon Marlow wrote: >> >> I suggest if we stick with the independent repo approach that we have >> some automation to check that changes are indeed getting pushed >> upstream. > > Agreed. Can you think of an easy way to automate it? How about a cronjob that runs darcs send --to= ? Ganesh =

Re: Libraries in the repo

On 26/08/2009 22:32, Duncan Coutts wrote: On Wed, 2009-08-26 at 17:15 +0100, Simon Marlow wrote: * Sometimes we want to make local modifications to INDEPENDENT libraries: - when GHC adds a new warning, we need to fix instances of the warning in the library to keep the GH

Re: Libraries in the repo

marlowsd: > Simon and I have been chatting about how we accommodate libraries in the > GHC repository. After previous discussion on this list, GHC has been > gradually migrating towards having snapshots of libraries kept as > tarballs in the repo (currently only "time" falls into this catego

Re: Libraries in the repo

On Wed, 2009-08-26 at 17:15 +0100, Simon Marlow wrote: > * Sometimes we want to make local modifications to INDEPENDENT > libraries: > - when GHC adds a new warning, we need to fix instances of the > warning in the library to keep the GHC build warning-free. I have to say I th

Re: Libraries in the repo

On Wed, Aug 26, 2009 at 9:15 AM, Simon Marlow wrote: > Simon and I have been chatting about how we accommodate libraries in the GHC > repository.  After previous discussion on this list, GHC has been gradually > migrating towards having snapshots of libraries kept as tarballs in the repo > (current