Front page | perl.perl5.porters |
Postings from December 2009
Re: towards a docpatch wiki
Thread Previous
|
Thread Next
From:
David Nicol
Date:
December 2, 2009 10:16
Subject:
Re: towards a docpatch wiki
Message ID:
934f64a20912021016u22c5002anc6f73507047a788d@mail.gmail.com
On Wed, Dec 2, 2009 at 11:24 AM, jesse <jesse@fsck.com> wrote:
> On Wed, Dec 02, 2009 at 11:02:44AM -0600, David Nicol wrote:
>> On Wed, Dec 2, 2009 at 10:12 AM, jesse <jesse@fsck.com> wrote:
>>
>> > So long as it has a shepherd
>>
>> or a well-defined "shepherd" capability that can be associated with an
>> authenticated identity. There are a bunch of cards ahead of this in my
>> deck, so nobody hold your breath.
>
> No. I really do mean a shepherd. Or a pumpkin. Or something. But I would
> be really unhappy to see a tool set up to enable contributions with
> nobody committing to make sure that contributions get quality-checked
> and forwarded on. A tool that's not being tended is worse than no tool and
> can be a horrible discouragement to new contributors.
So the tending of the tool, which would mean regularly updating its
origin branch, would have to be automated.
> I'd love to see a tool like this, but it's important that it not be a
> "fire and forget" sort of thing.
>
> -Jesse
The deliverables produced by the tool would be well-formatted patches
against origin that had passed through the tool's internal governance
process.
The goal of the tool -- the immediate pain it would attempt to relieve
-- would be reducing list traffic resulting from half-baked stuff like
my work of last night.
Which git is supposed to be able to accomplish, provided all parties
are git experts.
Current occasional patch creation procedures, such as
http://wiki.github.com/rakudo/rakudo/steps-to-create-a-patch
are burdensome, and must be followed repeatedly.
I'm further wondering if a patch wiki system that supported ad-hoc
interest teams (such as those created by "update me on motion on this
ticket" controls in bug tracking systems) would work for code too.
Diminishing returns begins applying; questions of approach -- add a
direct code editing facility to Trac, and per-ticket access controls,
and a make-and-build-in-per-ticket-sandbox-all-from-the-web-browser
kind of thing, and hey presto, Trac (or perhaps a fancy new feature on
github, backed by thousands of as-needed virtual machines (simple
chroot jails would be adequate, also possibly just plain old accounts
and non-priv'd build scripts) for the builds, using the differential
overlay features from BTRFS to share disk space containing common
data) becomes an IDE.
Thread Previous
|
Thread Next