On Wed, Mar 20, 2013 at 12:42 PM, Erik Bray <erik.m.bray@gmail.com> wrote:
Quick question regarding open issues on Distribute (of which I have a handful assigned to me, and of which I intend to tackle a few others): Would it it make sense to just hold off on those until the merge is completed?
I'd personally say no, go ahead and do the work now, except that it might be making more work for Jason later at the repository-munging level. ;-) So, hopefully he'll chime in here with a yea or nay.
Also is there anything I can do to help with the merge? How is that coming along?
It's... somewhat of a mess, actually. As Jason mentioned, distribute didn't import setuptools' version history at the start, so it's being a bit of a challenge to merge in a way that maintains history. My original suggestion for merging was to just cherrypick patches and apply them to setuptools (w/appropriate credits), because apart from the added tests and new features, there's at most about 5% difference between setuptools and distribute by line count. (And the added tests and features are mostly in separate files, so can be added without worrying about conflicts. And a lot of the remaining added stuff is being taken out, anyway, because it's the stuff that distribute uses to pretend it's setuptools.) Some challenges that have arisen since, are that the more changes Jason makes to the distribute branch in our merged repo, the less an "hg annot" is actually going to show the real authors of stuff anyway when we get done. (For example, putting back in the missing entry_points.txt whose absence has been causing problems w/distribute lately.) And we're getting huge and (mostly meaningless) conflicts during attempted merges, too. So, if you have any thoughts on what can be done to fix that, by all means, suggest away. ;-)