i don't have the feeling that most of the recent breakage is due to
negligence, nor do i think that asking contributors to be more
responsible will solve the main issues. yes, there have been a few
cases where typos or incomplete commits caused breakage and,
yes, re-building, *after* pull, *before* send, should be a minimal
requirement. and an easy to use testsuite can help.
but then there's multiple platforms and multiple branches, and asking
contributors to "somehow" make sure that they won't break any of
that is only likely to reduce the number of contributions. what is needed
is a workflow that guarantees that (a) people with limited resources
can still contribute, (b) variations and portability are still supported,
(c) somewhere there'll be access to stable versions of all of that.
the current workflow seems to be intended to work something like:
0 get a copy
1 develop in your local copy
2 update your copy, build, test
3 if successful, submit to central repo, else return to 1
4 buildbots check out from central repo
5 if something breaks on some setting/branch/platform
then fix it and continue at 2
else you're done; perhaps go back to 0
with more and more variants and developers, there are a few flaws
in this, though: 0/1 can happen concurrently, but since all these
independent developments will be merged at 3, 2 is the first step
that can go wrong unexpectedly (how are you supposed to test
your changes against the current state if you can't find a stable
version of the current state?). and if you get to 3, what the buildbots
check out in 4 will be a mixture of your changes and others, so if
something breaks in 5, it may not be clear that whether it is due
to your changes (if it is blatantly clear at this stage, it might have
been at 2 as well?). and while you're trying to fix it (2-5), the
target keeps moving.
the suggested last-known-good repos would add a step to this
mess, intended to partially isolate checkouts from the instabilities:
6 if a buildbot succeeds, it pushes to a stable repo
but if the loop 2-5 suffers from interference between multiple
patchers, it might take a while for any or some of the buildbots
to succeed, and there's no guarantee that there'll ever be a
time when all buildbots succeed.
the suggested and partially used 'FIX BUILD' labels, in contrast
are meant to allow instable checkouts to stabilize more quickly:
a checkout current head, which might not be stable
b try to build
c if successful, you're done, else keep pulling 'FIX BUILD'
patches *only* and return to b
again, this will only work if fixing builds has absolute priority,
and the 2-5 loop stabilizes quickly.
but as you have suggested, the "push to test" approach seems
to work less and less with more variants and more developers.
nevertheless, it is currently the only way to employ the buildbots
in order to test patches on branches/platforms which the
developer might not have access to.
personally, i don't think that limitations in darcs should be
allowed to hamper setting up a good workflow for ghc. but
even if 6 works, each of the stable repos will only be stable
from the view of a single buildbot.
i hope this summary of what i see as the current workflow
and its problems might help to focus the discussion on the
issues that need to be addressed (whereas the responsibility
argument doesn't help developers to do what they have to).
if you want developers to have added responsibilities, you
also need to give them the means to discharge those. in
particular, if the current "test locally, push to test globally"
doesn't work anymore, there'd need to be an organised
way for many concurrent developers to use the buildbots
for testing many possibly conflicting patches on the main
platforms/variants before pushing the patches to the
central repo.
so much for the analysis. how could that be made to work?
i'm not a fan of cpp, but two things it was good for in other
projects was
- to have many branches evolving in one code base,
with an easy way to switch between and test all
- to let new code grow inside the main code base
with an easy way to switch it on or off as needed
thinking of this, if there was a buildbot for each branch or
platform, developers could check in non-trivial changes
protected by cpp-directives, enabled only for the branch/
platform they have checked. then the buildbots would be
responsible for
a) tracking changes (identifying code that is disabled
on "their" variant, but is up for testing there)
b) testing changes (temporarily enabling code that was
disabled, but up for testing on "their" variant)
c) validating changes (permanently enabling code, for
"their" variant, that was previously disabled there,
but checked out allright when temporarily enabled
for "their" build/test
d) reporting failed changes (permanently disabling
code, for "their" variant, that was previously disabled,
but up for testing, and that has failed "their" build/test.
this would work better for new features than for modifications.
developers on OSX would -after testing- check in something like:
#if (OSX || TEST(WIN) || TEST(LINUX) ..)
.. new feature ..
#endif
which buildbot WIN would turn into
#if (OSX || WIN || TEST(LINUX) ..)
.. new feature ..
#endif
or into
#if (OSX || FAILED_TEST(WIN) || TEST(LINUX) ..)
.. new feature ..
#endif
depending on build/test outcome. TEST(X) would be false for
any non-X variant, true for the X-buildbot. FAILED_TEST(X)
would be false everywhere.
all the buildbots would need to push would be changes to the
cpp-directives. do you think that could work?
claus
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
