
Hey all, Those of you who follow the Haskell subreddit no doubt saw today's post regarding the status of Hackage 2. As has been said many times in the past, the primary blocker at this point to the adoption of Hackage 2 appears to be the lack of an administrator. It seems to me this is a poor reason for this effort to be held up. Having taken a bit of time to consider, I would be willing to put in some effort to get things moving and would be willing to maintain the haskell.org Hackage 2.0 instance going forward if necessary. I currently have a running installation on my personal machine and things seem to be working as they should. On the whole, installation was quite trivial, so it seems likely that the project is indeed at a point where it can take real use (although a "logout" option in the web interface would make testing a bit easier). That being said, it would in my opinion be silly to proceed without fixing the Hackage trac. It was taken down earlier this year due to spamming[1] and it seems the recovery project has been orphaned. I would be willing to help with this effort, but it seems like the someone more familiar with the haskel.org infrastructure might be better equipped to handle the situation. It seems that this process will go something like this, 1) Bring Hackage trac back from the dead 2) Bring up a Hackage 2 instance along-side the existing hackage.haskell.org 3) Enlist testers 4) Let things simmer for a few weeks/months ensuring nothing explodes 5) After it's agreed that things are stable, eventually swap the Hackage 1 and 2 instances This will surely be a non-trivial process but I would be willing to move things forward. Cheers, - Ben [1] http://www.haskell.org/pipermail/cabal-devel/2012-January/008427.html

Awesome!
I am willing to assist with any Happstack related technical problems or
questions that arise in trying to get this deployed.
- jeremy
On Mon, Feb 13, 2012 at 5:44 PM, Ben Gamari
Hey all,
Those of you who follow the Haskell subreddit no doubt saw today's post regarding the status of Hackage 2. As has been said many times in the past, the primary blocker at this point to the adoption of Hackage 2 appears to be the lack of an administrator.
It seems to me this is a poor reason for this effort to be held up. Having taken a bit of time to consider, I would be willing to put in some effort to get things moving and would be willing to maintain the haskell.org Hackage 2.0 instance going forward if necessary.
I currently have a running installation on my personal machine and things seem to be working as they should. On the whole, installation was quite trivial, so it seems likely that the project is indeed at a point where it can take real use (although a "logout" option in the web interface would make testing a bit easier).
That being said, it would in my opinion be silly to proceed without fixing the Hackage trac. It was taken down earlier this year due to spamming[1] and it seems the recovery project has been orphaned. I would be willing to help with this effort, but it seems like the someone more familiar with the haskel.org infrastructure might be better equipped to handle the situation.
It seems that this process will go something like this, 1) Bring Hackage trac back from the dead 2) Bring up a Hackage 2 instance along-side the existing hackage.haskell.org 3) Enlist testers 4) Let things simmer for a few weeks/months ensuring nothing explodes 5) After it's agreed that things are stable, eventually swap the Hackage 1 and 2 instances
This will surely be a non-trivial process but I would be willing to move things forward.
Cheers,
- Ben
[1] http://www.haskell.org/pipermail/cabal-devel/2012-January/008427.html
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Mon, Feb 13, 2012 at 3:44 PM, Ben Gamari
Hey all,
Those of you who follow the Haskell subreddit no doubt saw today's post regarding the status of Hackage 2. As has been said many times in the past, the primary blocker at this point to the adoption of Hackage 2 appears to be the lack of an administrator.
It seems to me this is a poor reason for this effort to be held up. Having taken a bit of time to consider, I would be willing to put in some effort to get things moving and would be willing to maintain the haskell.org Hackage 2.0 instance going forward if necessary.
You've just made my day :) Jason

On Mon, Feb 13, 2012 at 11:44:18PM +0000, Ben Gamari wrote:
Those of you who follow the Haskell subreddit no doubt saw today's post regarding the status of Hackage 2. As has been said many times in the past, the primary blocker at this point to the adoption of Hackage 2 appears to be the lack of an administrator.
It seems to me this is a poor reason for this effort to be held up. Having taken a bit of time to consider, I would be willing to put in some effort to get things moving and would be willing to maintain the haskell.org Hackage 2.0 instance going forward if necessary.
Hurrah! After 5 years, 1 month and 7 days of doing this, I'm keen to stop. (I've been waiting since Hackage 2 was announced in the Nov 2008 HCAR.)
It seems that this process will go something like this, 1) Bring Hackage trac back from the dead 2) Bring up a Hackage 2 instance along-side the existing hackage.haskell.org 3) Enlist testers 4) Let things simmer for a few weeks/months ensuring nothing explodes 5) After it's agreed that things are stable, eventually swap the Hackage 1 and 2 instances
Sounds like a good plan. I expect there are a number of small things that still need doing to make the new server a complete replacement.

On 02/13/2012 06:44 PM, Ben Gamari wrote:
I currently have a running installation on my personal machine and things seem to be working as they should. On the whole, installation was quite trivial, so it seems likely that the project is indeed at a point where it can take real use (although a "logout" option in the web interface would make testing a bit easier).
I'm not certain that this is the case, honestly. It's very close, to be sure, but there are enough rough edges and possible concerns that I think it'll need some polishing before it's ready for full use. At any rate, I had independently decided to start tinkering with the Hackage 2 codebase after being frustrated at the lack of progress. I have a publicly-accessible instance running at http://hackage2.uptoisomorphism.net:8080/ that's currently pretty empty, but I'll be doing at least a partial mirror of Hackage onto it in the near future as well as some hacking on the code. Feel free to check it out but please don't do anything too abusive to the server. I've also uploaded the hackage2 source to my GitHub at the urging of people on IRC, which should make it easier for more people to get the code and hack on it if they feel inspired: https://github.com/isomorphism/hackage2 - C.

Hi Ben,
On 13 February 2012 23:44, Ben Gamari
Hey all,
Those of you who follow the Haskell subreddit no doubt saw today's post regarding the status of Hackage 2. As has been said many times in the past, the primary blocker at this point to the adoption of Hackage 2 appears to be the lack of an administrator.
Yes, much of it is lack of an individual to keep momentum up and keep everyone else motivated. While I'm keen that hackage moves forward, my volunteer time is spread too thin to be that person keeping everything organised. That said, where I spend my volunteer time is to a large part directed by what other people are doing, it's much more fun and motivating if there's other people working with you. Speaking of which, I spent much of this evening fixing things, more details below.
It seems to me this is a poor reason for this effort to be held up. Having taken a bit of time to consider, I would be willing to put in some effort to get things moving and would be willing to maintain the haskell.org Hackage 2.0 instance going forward if necessary.
That would be great. So in the short term I'm very happy to get the help and in the longer term I'm happy to hand over to anyone sensible who puts in the effort. That person could be you, someone else or a team of several people. More immediately, my general policy with commit access is to give it to anyone who's sent a few good patches. Currently there are 7 people with write access to the darcs repo on code.h.o. It is of course also fine for people to maintain their own public branches (which they can do using git or darcs, whichever).
I currently have a running installation on my personal machine and things seem to be working as they should. On the whole, installation was quite trivial, so it seems likely that the project is indeed at a point where it can take real use (although a "logout" option in the web interface would make testing a bit easier).
Yes, we're at the stage where we can run a public testing instance. You'll see there's a bit more to implement and test for a switchover.
That being said, it would in my opinion be silly to proceed without fixing the Hackage trac. It was taken down earlier this year due to spamming[1] and it seems the recovery project has been orphaned. I would be willing to help with this effort, but it seems like the someone more familiar with the haskel.org infrastructure might be better equipped to handle the situation.
I spent a couple hours on this this evening and I've finally fixed it (I hope). I still need to purge a bit of wiki/ticket spam (help apreciated there). Sadly I've had to blow away the previos login accounts, but I've semi-restored by copying the ghc trac accounts. So if you happen to have an account on the ghc trac, then your login should work for the hackage trac. Otherwise you'll need to re-register as if it was a new account.
It seems that this process will go something like this, 1) Bring Hackage trac back from the dead
Check.
2) Bring up a Hackage 2 instance along-side the existing hackage.haskell.org
Yes, now that the trac is back, you can see what notes we have on the switchover process at: http://hackage.haskell.org/trac/hackage/wiki/HackageDB/2.0 Note also that the nice people at factisresearch.com have given us a VM with enough memory (8GB) for the purpose of running a public test with the full package set (in principle it should not need so much memory, but we currently keep unnecessary package metadata in memory). So thanks to you and others this evening motivating me, I've also taken Max's latest patches to my tar package (which coincidentally I released yesterday) and the corresponding hackage-server patch and set it running at: http://hackage.factisresearch.com/ This is running the latest upstream darcs version. I have also fired off a one-shot mirroring operation. This will mirror all the existing packages from hackage. It'll probably take half a day or so to complete since there's something like 30-40k tarballs to be copied over. I'll check the logs tomorrow hopefully and after that kick off a live/continuous mirror so it'll get new updates from the main hackage within 20-30 min or so. Last time Max and I tried this we were able to mirror almost all packages. Most of the unmirrorable ones at the time were due to packages with quirks in their tar format, which is what his tar patches were aimed at. So I'm hopeful we'll now have only a tiny handful of unmirrorable packages.
3) Enlist testers 4) Let things simmer for a few weeks/months ensuring nothing explodes 5) After it's agreed that things are stable, eventually swap the Hackage 1 and 2 instances
Right, that's more or less it. Other details on the wiki (and if there's anything missing, edit it). You'll see that there are still some missing components. In particular while I finished the live mirroring client, and Max has done a doc builder client, I think we're still missing a normal build client (one would start with Max's doc client).
This will surely be a non-trivial process but I would be willing to move things forward.
Taking an organisational / management / cheerleader role would be imensely useful (as well as technical obviously). I can help because I know more or less what needs to be done and I'm very happy to answer questions, grant push access etc. Duncan

On 14 February 2012 01:53, Duncan Coutts
Hi Ben,
On 13 February 2012 23:44, Ben Gamari
wrote: Hey all,
Those of you who follow the Haskell subreddit no doubt saw today's post regarding the status of Hackage 2. As has been said many times in the past, the primary blocker at this point to the adoption of Hackage 2 appears to be the lack of an administrator.
Yes, much of it is lack of an individual to keep momentum up and keep everyone else motivated. While I'm keen that hackage moves forward, my volunteer time is spread too thin to be that person keeping everything organised. That said, where I spend my volunteer time is to a large part directed by what other people are doing, it's much more fun and motivating if there's other people working with you.
Ah, here's the link to my last go at getting people to self-organise. http://www.haskell.org/pipermail/cabal-devel/2011-October/007803.html You should find it somewhat useful. It gives an overview of people who are / have been involved. We did get another reasonable push at the time. In particular Max did a lot of good work. I'm not quite sure why it petered out again, I'd have to ask Max what went wrong, if it was my fault for letting things block on me or if it was just holidays/christmas. Maintaining momentum is hard. Duncan

On Tue, 14 Feb 2012 02:06:16 +0000, Duncan Coutts
On 14 February 2012 01:53, Duncan Coutts
wrote: Hi Ben, snip
Ah, here's the link to my last go at getting people to self-organise. http://www.haskell.org/pipermail/cabal-devel/2011-October/007803.html
Excellent. I'll give it a read-through.
You should find it somewhat useful. It gives an overview of people who are / have been involved.
It seems the first task will be to identify exactly what needs to be done before we can begin the transition and record these tasks in a single place. I don't have a particularly strong opinion concerning where this should be (Trac, the Hackage wiki, the github issue tracker that's been mentioned), but we should consolidate everything we have in a single place.
We did get another reasonable push at the time. In particular Max did a lot of good work. I'm not quite sure why it petered out again, I'd have to ask Max what went wrong, if it was my fault for letting things block on me or if it was just holidays/christmas. Maintaining momentum is hard.
This is quite true. I'll try to keep a constant push. On another note, how did your full mirroring go last night? Cheers, - Ben P.S. Duncan, sorry for the duplicate message.

On 15 February 2012 00:16, Ben Gamari
On Tue, 14 Feb 2012 02:06:16 +0000, Duncan Coutts
wrote: On 14 February 2012 01:53, Duncan Coutts
wrote: Hi Ben, snip
Ah, here's the link to my last go at getting people to self-organise. http://www.haskell.org/pipermail/cabal-devel/2011-October/007803.html
Excellent. I'll give it a read-through.
You should find it somewhat useful. It gives an overview of people who are / have been involved.
It seems the first task will be to identify exactly what needs to be done before we can begin the transition and record these tasks in a single place. I don't have a particularly strong opinion concerning where this should be (Trac, the Hackage wiki, the github issue tracker that's been mentioned), but we should consolidate everything we have in a single place.
just my 2c, but I'd find it much easier to see project activity, active branches and open issues if it was all on github :) Conrad.
We did get another reasonable push at the time. In particular Max did a lot of good work. I'm not quite sure why it petered out again, I'd have to ask Max what went wrong, if it was my fault for letting things block on me or if it was just holidays/christmas. Maintaining momentum is hard.
This is quite true. I'll try to keep a constant push.
On another note, how did your full mirroring go last night?
Cheers,
- Ben
P.S. Duncan, sorry for the duplicate message.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hi Duncan,
I just wanted to thank you and all the other guys pushing Hackage 2
towards a public release. I just tested the
http://hackage.factisresearch.com/
instance and it's blazingly fast. Cool stuff! The reverse dependencies
are also very useful. I know that sending patches instead of thanks
would help more. I'll try that in a (hopefully) not too distant future
:-)
best regards and thanks again,
Simon
2012/2/14 Duncan Coutts
Hi Ben,
On 13 February 2012 23:44, Ben Gamari
wrote: Hey all,
Those of you who follow the Haskell subreddit no doubt saw today's post regarding the status of Hackage 2. As has been said many times in the past, the primary blocker at this point to the adoption of Hackage 2 appears to be the lack of an administrator.
Yes, much of it is lack of an individual to keep momentum up and keep everyone else motivated. While I'm keen that hackage moves forward, my volunteer time is spread too thin to be that person keeping everything organised. That said, where I spend my volunteer time is to a large part directed by what other people are doing, it's much more fun and motivating if there's other people working with you.
Speaking of which, I spent much of this evening fixing things, more details below.
It seems to me this is a poor reason for this effort to be held up. Having taken a bit of time to consider, I would be willing to put in some effort to get things moving and would be willing to maintain the haskell.org Hackage 2.0 instance going forward if necessary.
That would be great. So in the short term I'm very happy to get the help and in the longer term I'm happy to hand over to anyone sensible who puts in the effort. That person could be you, someone else or a team of several people.
More immediately, my general policy with commit access is to give it to anyone who's sent a few good patches. Currently there are 7 people with write access to the darcs repo on code.h.o. It is of course also fine for people to maintain their own public branches (which they can do using git or darcs, whichever).
I currently have a running installation on my personal machine and things seem to be working as they should. On the whole, installation was quite trivial, so it seems likely that the project is indeed at a point where it can take real use (although a "logout" option in the web interface would make testing a bit easier).
Yes, we're at the stage where we can run a public testing instance. You'll see there's a bit more to implement and test for a switchover.
That being said, it would in my opinion be silly to proceed without fixing the Hackage trac. It was taken down earlier this year due to spamming[1] and it seems the recovery project has been orphaned. I would be willing to help with this effort, but it seems like the someone more familiar with the haskel.org infrastructure might be better equipped to handle the situation.
I spent a couple hours on this this evening and I've finally fixed it (I hope). I still need to purge a bit of wiki/ticket spam (help apreciated there). Sadly I've had to blow away the previos login accounts, but I've semi-restored by copying the ghc trac accounts. So if you happen to have an account on the ghc trac, then your login should work for the hackage trac. Otherwise you'll need to re-register as if it was a new account.
It seems that this process will go something like this, 1) Bring Hackage trac back from the dead
Check.
2) Bring up a Hackage 2 instance along-side the existing hackage.haskell.org
Yes, now that the trac is back, you can see what notes we have on the switchover process at: http://hackage.haskell.org/trac/hackage/wiki/HackageDB/2.0
Note also that the nice people at factisresearch.com have given us a VM with enough memory (8GB) for the purpose of running a public test with the full package set (in principle it should not need so much memory, but we currently keep unnecessary package metadata in memory).
So thanks to you and others this evening motivating me, I've also taken Max's latest patches to my tar package (which coincidentally I released yesterday) and the corresponding hackage-server patch and set it running at:
http://hackage.factisresearch.com/
This is running the latest upstream darcs version. I have also fired off a one-shot mirroring operation. This will mirror all the existing packages from hackage. It'll probably take half a day or so to complete since there's something like 30-40k tarballs to be copied over. I'll check the logs tomorrow hopefully and after that kick off a live/continuous mirror so it'll get new updates from the main hackage within 20-30 min or so.
Last time Max and I tried this we were able to mirror almost all packages. Most of the unmirrorable ones at the time were due to packages with quirks in their tar format, which is what his tar patches were aimed at. So I'm hopeful we'll now have only a tiny handful of unmirrorable packages.
3) Enlist testers 4) Let things simmer for a few weeks/months ensuring nothing explodes 5) After it's agreed that things are stable, eventually swap the Hackage 1 and 2 instances
Right, that's more or less it. Other details on the wiki (and if there's anything missing, edit it).
You'll see that there are still some missing components. In particular while I finished the live mirroring client, and Max has done a doc builder client, I think we're still missing a normal build client (one would start with Max's doc client).
This will surely be a non-trivial process but I would be willing to move things forward.
Taking an organisational / management / cheerleader role would be imensely useful (as well as technical obviously). I can help because I know more or less what needs to be done and I'm very happy to answer questions, grant push access etc.
Duncan
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Mon, Feb 13, 2012 at 5:44 PM, Ben Gamari
Hey all,
Those of you who follow the Haskell subreddit no doubt saw today's post regarding the status of Hackage 2. As has been said many times in the past, the primary blocker at this point to the adoption of Hackage 2 appears to be the lack of an administrator.
It seems to me this is a poor reason for this effort to be held up. Having taken a bit of time to consider, I would be willing to put in some effort to get things moving and would be willing to maintain the haskell.org Hackage 2.0 instance going forward if necessary.
I currently have a running installation on my personal machine and things seem to be working as they should. On the whole, installation was quite trivial, so it seems likely that the project is indeed at a point where it can take real use (although a "logout" option in the web interface would make testing a bit easier).
One thing that made testing hard for me last time was that existing 'cabal install' client treats the server "hackage.haskell.org" different from any other server you put in your config files, so simulating the effect of a cutover on existing users can be tricky. If you don't know what I'm talking about I can look it up. I had a hacked 'cabal' client at one point, and I could probably re-create the patches. Antoine

On Mon, Feb 13, 2012 at 10:17 PM, Antoine Latter
On Mon, Feb 13, 2012 at 5:44 PM, Ben Gamari
wrote: Hey all,
Those of you who follow the Haskell subreddit no doubt saw today's post regarding the status of Hackage 2. As has been said many times in the past, the primary blocker at this point to the adoption of Hackage 2 appears to be the lack of an administrator.
It seems to me this is a poor reason for this effort to be held up. Having taken a bit of time to consider, I would be willing to put in some effort to get things moving and would be willing to maintain the haskell.org Hackage 2.0 instance going forward if necessary.
I currently have a running installation on my personal machine and things seem to be working as they should. On the whole, installation was quite trivial, so it seems likely that the project is indeed at a point where it can take real use (although a "logout" option in the web interface would make testing a bit easier).
One thing that made testing hard for me last time was that existing 'cabal install' client treats the server "hackage.haskell.org" different from any other server you put in your config files, so simulating the effect of a cutover on existing users can be tricky.
Oh, and it isn't absolutely terrible - it only affects the 'upload' command, I think (and the upload + check).
If you don't know what I'm talking about I can look it up. I had a hacked 'cabal' client at one point, and I could probably re-create the patches.
Antoine

I apologize, But does hackage.haskell.org being down for some hours already has something with the process of bringing up Hackage 2? Kind regards, Kirill Zaborsky P.S. Previous mail was rejected by maillist

On Tue, 14 Feb 2012 02:59:27 -0800 (PST), Kirill Zaborsky
I apologize, But does hackage.haskell.org being down for some hours already has something with the process of bringing up Hackage 2?
Nope, it will be some time before we are in a position to touch hackage.haskell.org. Cheers, - Ben

Hi,
Are there any news how things are going? What remains there to be done to
get us to Hackage 2?
I found this list of tickets:
https://github.com/haskell/cabal/issues?labels=hackage2&page=1&state=open
Is there anything more to be done?
Best regards,
Krzysztof Skrzętnicki
On Tue, Feb 14, 2012 at 12:44 AM, Ben Gamari
Hey all,
Those of you who follow the Haskell subreddit no doubt saw today's post regarding the status of Hackage 2. As has been said many times in the past, the primary blocker at this point to the adoption of Hackage 2 appears to be the lack of an administrator.
It seems to me this is a poor reason for this effort to be held up. Having taken a bit of time to consider, I would be willing to put in some effort to get things moving and would be willing to maintain the haskell.org Hackage 2.0 instance going forward if necessary.
I currently have a running installation on my personal machine and things seem to be working as they should. On the whole, installation was quite trivial, so it seems likely that the project is indeed at a point where it can take real use (although a "logout" option in the web interface would make testing a bit easier).
That being said, it would in my opinion be silly to proceed without fixing the Hackage trac. It was taken down earlier this year due to spamming[1] and it seems the recovery project has been orphaned. I would be willing to help with this effort, but it seems like the someone more familiar with the haskel.org infrastructure might be better equipped to handle the situation.
It seems that this process will go something like this, 1) Bring Hackage trac back from the dead 2) Bring up a Hackage 2 instance along-side the existing hackage.haskell.org 3) Enlist testers 4) Let things simmer for a few weeks/months ensuring nothing explodes 5) After it's agreed that things are stable, eventually swap the Hackage 1 and 2 instances
This will surely be a non-trivial process but I would be willing to move things forward.
Cheers,
- Ben
[1] http://www.haskell.org/pipermail/cabal-devel/2012-January/008427.html
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Krzysztof Skrzętnicki
Hi,
Are there any news how things are going?
Things have been pretty stagnant yet again. I was more than a bit over-optimistic concerning the amount of time I'd have available to put into this project. Moreover, the tasks required to get Hackage into a usable state weren't nearly as clear as I originally thought. Unfortunately, those who have historically been very active in Hackage development and would have been responsible for much of the recent work in advancing Hackage 2 to where it is now have other demands on their time. My understanding is there is a fair amount of half-completed code floating around.
What remains there to be done to get us to Hackage 2?
I found this list of tickets: https://github.com/haskell/cabal/issues?labels=hackage2&page=1&state=open
Is there anything more to be done?
This list is definitely a start. One of the issues that was also realized is the size of the server's memory footprint. Unfortunately acid-state's requirement that all data either be in memory or have no ACID guarantees was found to be a bit of a limitation. If I recall correctly some folks were playing around with restructuring the data structures a bit to reduce memory usage. I really don't know what happened to these efforts. On the other hand, it seems that the test server is still ticking away at http://hackage.factisresearch.com/ with an up-to-date package index, so things are looking alright on that front. At this point, it seems that we are in a situation yet again where someone just needs to start applying gentle pressure and figure out where we stand. I'm afraid especially now I simply don't have time to take on this project in any serious capacity. Perhaps one way forward would be to propose the project again as a GSoC project next year. That being said, there is no guarantee that someone would step up to finish it. Just my two cents. Cheers, - Ben

On Wed, Jun 20, 2012 at 11:06 AM, Ben Gamari
This list is definitely a start. One of the issues that was also realized is the size of the server's memory footprint. Unfortunately acid-state's requirement that all data either be in memory or have no ACID guarantees was found to be a bit of a limitation. If I recall correctly some folks were playing around with restructuring the data structures a bit to reduce memory usage. I really don't know what happened to these efforts.
I am one of those people, but as I (hopefully) mentioned at the time, I had some other tasks I had to address first (namely, the release of Happstack 7 and clckwrks). However, starting this week I am finally looking at some acid-state related issues. Part of this will be building some tools to help analyze where all your RAM is going. My current hypothesis is that for hackage 2, we should be able to reduce RAM usage by 10 to 100 fold. The size of the data on disk is only a few MB.. I currently can not think of any good reason why it should take anywhere as much RAM as it currently does. So, it must be doing it for some bad reason :) Though, I won't know until I do the analysis. You'll probably see some blog articles as I work out the process. - jeremy
participants (12)
-
Antoine Latter
-
Ben Gamari
-
Casey McCann
-
Conrad Parker
-
Duncan Coutts
-
Jason Dagit
-
Jeremy Shaw
-
Kirill Zaborsky
-
Krzysztof Skrzętnicki
-
Ross Paterson
-
Simon Meier
-
Simon Michael