Simon,
| I think its a matter of scalability. The "testing by pushing to head"
approach | that you seem to advocate worked well enough when few people were
hacking GHC. | However, it seems that the number of GHC developers has been
growing quite a bit | in recent times
I agree completely. It's a nice problem to have (lots of developers), but it
is a real problem, and I know you are fed up with wasting time.
In my mind I see, in order of increasing cost:
A) The status quo B) Last good snapshot C) Something more elaborate
Because the cost goes up, it might be worth trying (B) before (C), and we
have not tried it yet. It's clearly better than what we have been working
with for the last 10 yrs, but it's still cheap. Perhaps it'll fix 90% of the
pain for 10% of the cost.
Sorry if I haven't expressed myself clearly, I am all for (B).
If that doesn't work, then perhaps something more elaborate will be needed.
But to be concrete, what specifically do you recommend for (C)? A
self-discipline on developers that they don't check in changes until they
have tested them? I'm sure they already try not to (e.g. I run the
typechecker test suite before checking in a typechecker patch),
I don't really see self-discipline as a scheme that is alternative to (B); it's
complementary. It is a matter of a higher standard before a patch goes into the
head. The idea is simply thus:
* Anybody who has commit access is responsible for testing patches before
pushing them (and commit access is only granted to people who are trusted
to be sufficiently responsible).
* Anybody who submits patches by email must state how they were tested. If the
tests are deemed insufficient (or the code looks suspect) whoever receives the
patch sends it back with a request for further testing or other improvement.
This is standard in other open source projects.
but partial tests are by definition not comprehensive.
All tests are partial. The buildbot is, too, as we witness regularly. I am not
after a perfect solution. The head will break. It just would be nice if it'd
happen less often (rather than as it seems now with increasing frequency).
As an example, take the recent change of Clemens Fruhwirth introducing .type
directives. Linker/asm changes are clearly OS sensitive. So, unless tested on
multiple OSes, it just doesn't go into the head. Here I explicitly don't care
about how Clemens tests his patch. Maybe he has access to a windows box or he
asks somebody with access to a windows box to do it for him. The key point is,
testing is Clemens responsibility, not that of the poor people who happen to
work on windows and pull from head after he pushed.
| more people waste their time with a broken head. Even if we have the |
"guaranteed to be buildable" snapshots, there is an overhead in trying the
head, | discovering it is broken, and moving to a snapshot.
What I'm missing is this: why not *always* pull from the snapshot? By going
for the bleeding edge you by definition expose yourself to instability, (C)
included. If some vital fix is needed specifically for the NDP branch, maybe
whoever makes that patch (eg me) should do it on your branch?
Taking ndp as an example, we usually pull from the head for three reasons:
* There are patches we know we needed (very often patches by you). You could
do them on the branch, but with many of those, there is a significant
likelihood that you'll get other conflicting patches on the head over time.
Then, we have to merge manually, which we try to avoid.
* Packages change and we need head patches to be able to compile current
packages.
* We just want the latest stuff if only to avoid conflicts further down the
road.
In the last case, we can easily pull off the snapshot. In the second cases, it
depends on when the package changed; and in the first case, we need the head.
In short, are you convinced that (B) is unworkable? what do you have in mind
for (C)?
I think (B) is good. However, largely orthogonal to (B) is the question of how
much testing a patch should receive before it goes into the head.
In any case, I propose to merge the ghc-ndp branch into the head and continue
development there. Most of our development is in an extra sub-directory adding
an extra core pass that is only activated if the -fvectorise option is passed.
As long as we keep it compiling, it is very unlikely to break other components
(certainly much less likely than the changes that have caused us much grief
recently). By doing that, at least we safe the time of maintaining the branch.
Manuel
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
