Lieutenant needed: build and release process

[Dicebot via Digitalmars-d]

On Tuesday, 9 September 2014 at 13:54:15 UTC, Dragos Carp wrote:
> Are you satisfied with the current process?

Yes. I am not satisfied with certain parts of implementation of 
the process but the concept overall is a good as it can possibly 
be given manpower available and lack of any centralized 
collaboration. Think about it - despite the fact that there is no 
one actually responsible for release planning and no fully 
commited developers we still somehow manage to get those release 
out. This is quite an achievment if you think about it.

> Let me summarize some important drawbacks of the current 
> workflow:
>
> 1. No clear defined deadline for preparing a merge-able PR.

.. which allows maintainers to merge pull requests when they seem 
ready without any synchronization "locks" and does not interfere 
with release branches.

> 2. Unorganized PR merge campaigns. The people merging the PR 
> are doing a great job, but they do this triggered by arbitrary 
> events: too many open PRs, a cool new PR appears, somebody poke 
> them on forum, or simply have some time for this kind of work.

There is no such thing as "PR merge campaign" and there is not 
point in having one. It is everlasting process - stuff gets 
merged when its done, it is completly irrelevant to release 
planning. "simply have some time for this kind of work" is the 
only realistic criteria for any sort of maintenance activity 
here, you can't get any other without bunch of devs on salary.

It is a process which is almost exclusively blocked by maintainer 
time. It is quite telling that situation with Phobos (which has 
easier learning curve and more active maintainers overall) is 
much better than with DMD.

> 3. Somehow arbitrary merge criteria. Having a defined merge 
> window, when some people do just PR merges, will implicitly 
> produce more predictable and uniform acceptance criteria.

What makes you think so? It will only introduce arbitrary 
limitation on a time when you can merge pull requests. Merge 
criteria is an orthogonal topic - if it is possible to formalize 
one, it can also be done without introducing merge windows. 
Implicit uniform criteria is much better defined by the simple 
fact that those are the very same people doing merges (and there 
aren't many)

Only thing merge window will achieve is making pull reqeuests 
stockpile even more because developers won't be allowed to merge 
them when they have time to do so.

> 4. Lack of focus during test phase. Maybe this is the main 
> reason for the v2.066 regressions. Some people keep merging new 
> PRs, before the old ones are proven done during the test phase. 
> Even Walter was annoyed a couple of times by the multitude of 
> versions that the people are simultaneously working on

Main reason is that there are only few developers capable of 
fixing DMD regressions. If release beta happens when either of 
them is busy it will result in immediate slowdown. This is 
especially true about Kenji.

Do you realize that fixing release and merging new pull requests 
happens in _different_ branches? And merging even 1000 new 
features doesn't affect testing of the release beta? There were 
certain bad cases when major refactorings in master make it hard 
to port bug fixes to release branch but those were rare.

> 5. Rotting old PRs. The "merge window" phase would be a defined 
> recurrent occasion to review and decide about those.

There are no rotting old PRs now in Phobos despite the 
maintenance / release process is the same. Guess why? With recent 
addition of bunch of new maintainers we simply got the resources 
to clean and categorize those and this just immediately happened.

Unfortunately, there is no magic process can just create new 
developers out of the air :(