On 14/05/12 09:46, David Kastrup wrote:
We don't have a canonical developer, one whose personal branch/repository would be official for the project.
GitHub and Launchpad both permit branches to be owned by groups as well as individuals. I'm sure other DVCS-based code hosts do as well, but those are the two I'm most familiar with.
We have automated regression testing taking a _lot_ of computation time. We have a history of our canonical repository _breaking_. We have a total dearth of high-level developers, and a number of volunteers at lower level.
What's the particular problem here -- is it that the regression tests are too heavy for users to run on their own machines prior to submitting a merge request, or is it that they can't be trusted to run them?
If you compare the complexity of the code base and infrastructure to the available manpower and skill sets, the logical verdict is death by bitrot. The red tape is doing a surprisingly good job at keeping the project from rusting in its tracks in spite of the large mismatch between project complexity and active workers. Partly because sufficiently hardened red tape can be replaced by automatic procedures. We have a fine-grained mesh of regression tests where _lots_ of stuff gets caught before making it into the code base.
Don't get me wrong. I'm not arguing against regression tests or careful review -- I strongly support them. My objection is that the way it's been implemented is unnecessary complicated:
-- you ask me to install a custom program, unique to LP, just in order to upload my code to your testing site. Why not let me upload to a repo of my choice (GitHub, Gitorious, Bitbucket, Google Code ...) and just submit to your testing system a repo location and branch name from which it can pull? Come to that, why can't I just manually upload a patch file like the one I emailed to the list? Or create and push to a personal repo on the testing system? -- this custom-built program can't readily handle git branches other than master. Yes, I can use the SHA1, but that's finnicky on the user side, an unnecessary complication. -- the custom-built program asks for my Google ID and password. Can I be sure that it handles them securely?
Yes, I have bursts of creativity where I bypass proper procedures for well-chosen subsets of patches in order to avoid getting into a tangle of diverging commits. But that is an exception to the rule. The "norm for DVCS-hosted software projects" is commit first, question later.
That's not my experience of DVCS-based projects. It's perfectly possible to run a contributor's merge request through a test suite before accepting it, or to request them to ensure the test suite passes before submitting such a request. What I don't see is that it's necessary to entangle the technical means for submitting (and tracking) the merge request with the technical means for applying the test procedure -- or to require project-specific programs to do either.
We don't have the amount of qualified cleanup personnel to deal with this style.
I'm not proposing "commit first, question later". I'm saying that the process of _submitting_ a patch or merge request should be trivial. That merge request can still be required to pass rigorous tests before it is accepted.
There also has to be some common sense involved. My _real_ objection here is that a tiny, spur-of-the-moment contribution done as a casual favour to the project was greeted with a request for me to go through a complicated submission procedure.
It's a trivial documentation patch and it's hardly onerous for a core developer to check that it's OK and just add it in.
_______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel