On Sun, 15 Jul 2012 18:28:36 -0700, Adam Wilson <flybo...@gmail.com> wrote:
On Sun, 15 Jul 2012 18:11:12 -0700, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
On 7/15/12 7:44 PM, Adam Wilson wrote:
I should note that we use this exact model for every project we have
where I work and that it is been highly successful at keeping those
five
points of tension moderated. And our users can actually get work done
without waiting for weeks and months because thing X is just plain
broken, which in turn makes us look good. (Improving Loyalty)
Allow me to propose something.
Right now all dmd changes get merged in the head. Suppose we find a
volunteer in the community who is:
1. Highly motivated
2. With a good understanding of D
3. Expert with git
4. Reliable
I wonder if it's possible that that person cherry-picks commits from
HEAD into two separate branches: bugfixes and unstable. It should be
easy to create installers etc. for those.
If we see this works well and gathers steady interest, we can improve
it and make it the practice of the entire team.
Would this be possible?
Andrei
I like this, A LOT! This is a nice twist on the proposed model and I
think it improves on the process. It certainly means that no release is
predicated on the state of HEAD, which is a fantastic achievement. And
this process certainly wasn't possible prior to git.
It also achieves to goal of separate branches for unstable work and
stable bugfixes.
I may just co-opt this for my projects at work!
However, this is all predicated on finding such a person, of which few
exist. But I would argue that it should NOT fall on to someone in the
core team (Walter, Kenji, Braddr, Don, etc.), they should be working on
the compiler HEAD.
There must be someone out there with decent knowledge of the internals
and yet doesn't consider themselves core team, but the biggest them I
think is going to be the time, which is why I think it shouldn't be a
core team member.
Actually, here is another idea. How about we train someone who maybe has
some experience with the compiler but might not know what to do in all
situations. If they had direct access to Walter and the Core Team, they
could be quickly brought up to speed on the job so to speak. And it
would widen our potential volunteer poll.
Plus it would widen the number of team members who are deeply involved
with the compiler. Reducing our bus-factor is always a very good thing.
If the core team was willing to accept an apprentice, then I would be
willing to learn. As far as git goes, the only thing I don't have much
experience with is reversions, the rest I can handle, we use git
internally at work so it's very familiar to me. But I'd want to see if
anyone else more qualified than I was willing to volunteer first!
As an addition to my training proposal, I submit that we make it two
people, to account for vacations and other times when one person may not
be available. Although I imagine that anything beyond two people might be
a little more than the core team can handle, and I can't see it being that
much work that we'd need three people.
--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
