[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Doc build hanging (with memory leak?)

From: Joseph Rushton Wakeling
Subject: Re: Doc build hanging (with memory leak?)
Date: Mon, 14 May 2012 11:16:16 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]