Corehackers: The Wind of Change
Recently, I've been thinking a lot about corehackers and its place
in the perl5 universe. Change is in the air of p5p. The change is
slow but ongoing. We're beginning to ponder maint-* branches as
fully stable and unchanging, apart from bug fixes and security
patches. We're beginning to ponder a faster development cycle for
blead, potentially with regularly published snapshots. perl5 10.1
is almost upon us and we still have an open pumpking slot for perl5
12. The perl5 universe is changing, for the better I think. Given
all this change and the new ideas floating around, where does
corehackers fit in?
As discussed in an earlier post, there are two sides to
corehackers, as it stands right now. First, there is the codebase,
where crazy ideas can get integrated and tested. Second, there is
the community, where we try to get people involved, whether they're
newbies or masters.
While trying to maintain corehackers as both a codebase
and
a community, an issue kept cropping up. Maintaining the corehackers
repo is a major pain in the ass. When Chip first put forth the
idea, we wanted a common integration point for all the shiny
changes. Chip cloned the perl5 git repo and away we went. From a
maintainer's perspective, this decision was ... not a great one. It
requires me, as the repo maintainer, to keep the corehackers clone
up to date with blead and all the relevant branches, in case
someone wants to work on them. If we have custom patches in the
corehackers branch, which is kind of the point, I get to manage
merge conflicts as well. Yes, this work could be spread around to
other people but the work still has to happen. At the end of the
day, we put far more effort into keeping the repo up to date with
blead/maint than we do developing shiny new code.
I talked to folks about how to ease this pain. Could git magically
make this easy for me? No, it can't. There was talk of automation
but that only makes parts of the pain go away. I came to believe
that the issue wasn't technical. There was a fundamental flaw in
our approach.
A series of epiphanies ran me over at this point.
First, corehackers, as a code base, exists effectively as
perl5-unstable. Unstable patches get added, tested, and presented
to p5p. That's the theory at least.
Second, perl5 doesn't need perl5-unstable right now. In the current
universe, having stable maint- branches and an active blead is
enough. Perhaps more importantly, having a perl5-unstable repo does
a massive disservice to p5p and perl5 by fragmenting development
and potentially lowering the activity on blead.
Third, having a magical corehackers repo goes against the very idea
of distributed source control. DVCS lets us each have our own
repository with as many branches as we want. When we're ready, we
can ask like-minded souls to pull from our repository and provide
comments and/or testing. When we're ready to submit the change to
p5p, we can build a patch from our repository and send it in. There
is no need for a centralized corehackers repo. In fact, it adds an
additional totally unnecessary step.
Let's say we drop the corehackers repository. How do we support new
core development and wacky ideas? We encourage people to clone the
perl5 core repository and work in their own environment. We
document and provide links to repositories where new work is being
done. We teach people about the core and point them in the right
directions. In short, we become a community wrapped around the idea
of helping people learn and contribute, rather than partially
wrapped around being the caretakers of all new ideas and the
resultant code.
This is the direction I want us to go in. To support this, a few
changes are necessary. I'll detail those in smaller posts in the
coming days. For the vast majority of people involved in or
interested in corehackers, these changes will not be surprising nor
will they affect the work anyone is doing.