[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
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.
- Re: Doc build hanging (with memory leak?), (continued)
- Re: Doc build hanging (with memory leak?), Joseph Rushton Wakeling, 2012/05/12
- Re: Doc build hanging (with memory leak?), David Kastrup, 2012/05/12
- Re: Doc build hanging (with memory leak?), Joseph Rushton Wakeling, 2012/05/12
- Re: Doc build hanging (with memory leak?), James, 2012/05/12
- Re: Doc build hanging (with memory leak?), Joseph Rushton Wakeling, 2012/05/12
- Re: Doc build hanging (with memory leak?), James, 2012/05/12
- Re: Doc build hanging (with memory leak?), Joseph Rushton Wakeling, 2012/05/13
- Re: Doc build hanging (with memory leak?), Graham Percival, 2012/05/14
- Re: Doc build hanging (with memory leak?), Joseph Rushton Wakeling, 2012/05/14
- Re: Doc build hanging (with memory leak?), David Kastrup, 2012/05/14
- Re: Doc build hanging (with memory leak?),
Joseph Rushton Wakeling <=
- Re: Doc build hanging (with memory leak?), David Kastrup, 2012/05/14
- Re: Doc build hanging (with memory leak?), Joseph Rushton Wakeling, 2012/05/14
- Re: Doc build hanging (with memory leak?), David Kastrup, 2012/05/14
- Re: Doc build hanging (with memory leak?), Joseph Rushton Wakeling, 2012/05/14
- Re: Doc build hanging (with memory leak?), David Kastrup, 2012/05/14
- Re: Doc build hanging (with memory leak?), Colin Campbell, 2012/05/14
- Re: Doc build hanging (with memory leak?), Graham Percival, 2012/05/14
- Re: Doc build hanging (with memory leak?), David Kastrup, 2012/05/14
- Re: Doc build hanging (with memory leak?), Graham Percival, 2012/05/12