[Grok-dev] Re: Martian as an external in the Grok trunk
Martijn Faassen
faassen at startifact.com
Sat Jan 26 16:44:07 EST 2008
Tres Seaver wrote:
[snip]
>
> FWIW, I would prefer that the checkout of grok *not* include the
> dependencies: if a particular developer is testing a newer version of a
> dependency, then s/he should be comfortable with getting that version
> installed (e.g., via 'setup.py develop' in a checkout).
The Grok trunk won't *work* without the trunk version of Martian. What
are you suggesting as an alternative? Have people check out and install
Grok trunk and discover test failures? Do we then say: "we're sorry, in
order to develop Grok, you also need to check out a development version
of Martian. The installation system of the Grok trunk currently just
don't work and here are the manual instructions."
> Shipping unreleased dependencies in a checkout encourages lazy mistakes
> at release time, where they are catastropyic, to save effort for the
> person who is already offroading, and should thus be capabal of fixing
> whatever issues crop up.
I think it's an exaggeration to call mistakes at release time
catastrophic; a botched release is unfortunate.
I consider release time a good time to go through the dependencies and
see whether any updates need to be released of dependencies in order to
make the release work. This can be done by going through CHANGES.txt,
where such updated requirements will be marked, and by looking at
setup.py. Clearly though I hope we can release a new version of Martian
before release time.
I'm not sure why you describe me and those who paired with me at the
sprint as people "offroading". We're talking about developing Grok.
Sometimes the development of Grok needs some improvements or changes in
its dependencies. Sometimes a period of parallel development cannot be
easily avoided.
I can see a better way to avoid affecting the trunk. What I think we
should have done is branched Martian when we realized it needed
incompatible changes, and put in an external in *our* branch to depend
on that. Then when we're happy to merge the branch, we could have first
merged Martian, release a new version, and then merge things to the Grok
trunk and rely on the newer version. Perhaps this is a good guideline
for developing dependencies in general? (managing dependencies is and
will remain hard though; I think we cannot avoid *all* pain :)
Regards,
Martijn
More information about the Grok-dev
mailing list