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 :(
