Yes. The difficulty is a3a65b56a7d09. Roman changed the stream representation in vector. These changes were part of what led to our ICFP paper. BOS made a giant patch that undid all these changes in the 0.10 branch, but they lived on in master. One issue with the change in representation is that they break compatibility with DPH. I have patches to fix this. However, the change in representation has not been extensively performance tested, so there may be performance regressions. Geoff On 06/26/2014 11:02 AM, Johan Tibell wrote:

Geoffrey, you did a bunch of hacking on vector at some point, right? Do you have an idea why the branches have diverged?

On Thu, Jun 26, 2014 at 4:42 PM, Gregory Collins mailto:greg@gregorycollins.net> wrote:

Hi all,

I've prepped a new minor version (0.10.12.0) of the 0.10 branch of vector so that we can release https://github.com/haskell/vector/pull/31, which I cherry-picked from master. Could someone please review this and do the upload? I'm not sure I have the right bit set.

Also, in a related topic, an aside: I tried to merge 0.10 into master and got a horrorshow:

# Unmerged paths: # (use "git add/rm <file>..." as appropriate to mark resolution) # #both modified: Data/Vector.hs #deleted by them: Data/Vector/Fusion/Bundle/Monadic.hs #both modified: Data/Vector/Fusion/Stream.hs #both modified: Data/Vector/Fusion/Stream/Monadic.hs #both modified: Data/Vector/Fusion/Stream/Size.hs #both modified: Data/Vector/Generic.hs #both modified: Data/Vector/Generic/Mutable.hs #deleted by them: Data/Vector/Generic/Mutable/Base.hs #both modified: Data/Vector/Generic/New.hs #both modified: Data/Vector/Mutable.hs #both modified: Data/Vector/Storable.hs #both modified: Data/Vector/Unboxed.hs #both modified: Data/Vector/Unboxed/Base.hs #both added: README.md #both modified: benchmarks/vector-benchmarks.cabal #both added: changelog #both modified: internal/unbox-tuple-instances #both modified: tests/vector-tests.cabal #both modified: vector.cabal

I'm curious why these branches have diverged like this, it doesn't smell good to me. Does anyone want to tackle doing this merge?

G -- Gregory Collins mailto:greg@gregorycollins.net>

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Dan, are you maintaining vector now? Do you want yourself listed as the maintainer in the .cabal file (right now it's libraries@haskell.org)? On Thu, Jun 26, 2014 at 5:06 PM, Edward Kmett wrote:

_Please_ talk to Dan Doel before another version of vector goes out through back channels as it were.

Sent from my iPhone

On Jun 26, 2014, at 10:42 AM, Gregory Collins wrote:

Hi all,

I've prepped a new minor version (0.10.12.0) of the 0.10 branch of vector so that we can release https://github.com/haskell/vector/pull/31, which I cherry-picked from master. Could someone please review this and do the upload? I'm not sure I have the right bit set.

Also, in a related topic, an aside: I tried to merge 0.10 into master and got a horrorshow:

# Unmerged paths: # (use "git add/rm <file>..." as appropriate to mark resolution) # # both modified: Data/Vector.hs # deleted by them: Data/Vector/Fusion/Bundle/Monadic.hs # both modified: Data/Vector/Fusion/Stream.hs # both modified: Data/Vector/Fusion/Stream/Monadic.hs # both modified: Data/Vector/Fusion/Stream/Size.hs # both modified: Data/Vector/Generic.hs # both modified: Data/Vector/Generic/Mutable.hs # deleted by them: Data/Vector/Generic/Mutable/Base.hs # both modified: Data/Vector/Generic/New.hs # both modified: Data/Vector/Mutable.hs # both modified: Data/Vector/Storable.hs # both modified: Data/Vector/Unboxed.hs # both modified: Data/Vector/Unboxed/Base.hs # both added: README.md # both modified: benchmarks/vector-benchmarks.cabal # both added: changelog # both modified: internal/unbox-tuple-instances # both modified: tests/vector-tests.cabal # both modified: vector.cabal

I'm curious why these branches have diverged like this, it doesn't smell good to me. Does anyone want to tackle doing this merge?

G -- Gregory Collins

_______________________________________________

Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Thu, Jun 26, 2014 at 5:25 PM, Edward Kmett wrote:

Given the way the last ad hoc release of vector went out and the problems that ensued I'd really appreciate it if he was the one to push any vector releases for now.

He's done a ton of work cleaning it up, and we've already gone behind his back once.

Yes I should have not implied with my email that "anybody in particular" should do the release, as that's not really what I meant -- instead that whoever has been doing them lately or who had been granted the release bit should do it. If Dan is going to coordinate or perform releases then we should make a note of this in the readme so that people know in the future. In relation to the patch, this particular change has turned out to be more controversial than I expected so if we follow Johan's proposal by splitting off a .Internal module then there is work to do still before the release can be made anyways. G -- Gregory Collins

On Thu, Jun 26, 2014 at 7:46 PM, Edward Kmett wrote:

Heretofore it has been more or less controlled chaos. That started when the package slid into community hands when Roman washed his hands of it, but it has led to the case where master and the stuff in wide use have been getting farther and farther out of sync.

Some of the libraries packages are quite actively being looked at by people, and others...not so much. A common scenario for pull requests to libraries packages is that they languish, untouched, for ages. Is anyone looking at the pull requests that have been coming in for X11, to give one example? My reaction to this scenario is that I subscribe to the notification stream and if pull requests come across that look relatively uncontroversial, I review and merge them, just to keep the peanuts rolling along. If, sometimes, like in this instance, we might have to go back and do a little bit of work to fix things up afterwards, because two steps forward and one back is better than nothing happening at all. Of course, sometimes when you go and do this, someone is actually actively tending to the repository in question, in which case we need to get a reminder of this put in the project's README. In general, as you noted, releases have been a little bit of a free-for-all lately (that's what you get with conscript labor) and maybe every repo libraries@ maintains should either have a dedicated release person or release instructions for community contributors in the readme. I also don't think that the full review process is necessarily right for every patch, although clearly this one should have stewed longer in discussion before being merged. Mea culpa. G -- Gregory Collins