On Thursday, 29 November 2012 at 09:37:57 UTC, Manu wrote:
On 29 November 2012 03:48, deadalnix <deadal...@gmail.com>
wrote:
On Thursday, 29 November 2012 at 01:29:12 UTC, Jonathan M
Davis wrote:
Since master will almost certainly be the development branch,
I don't see
how
that's a problem. The stable branch will be a separate
branch, and
whoever is
managing the stable branch will merge stuff from the master
branch into
it.
In this case, all bug fixes are mixed with new feature and
then have to be
separated afterward and remerged into the stable branch. This
is useless
work and it is likely to cause merge conflict in the stable
branch.
Additionnaly, this become to really suck when several new
features are dev
at the same time.
Finally, yhis is completely inconsistent with how github work
in the first
place.
master make sense as an unstable branch, a release candidate,
a beta or
whatever, but certainly not a dev branch.
Why don't you document precisely what branches you think should
exist, and
the working merge/rebase policies.
I'm actually very curious to know.
Granted, major stuff like 64-bit Windows support and UDAs
should probably
be
introduced on branches separate from master, and it's still a
problem if
they're not, but it won't affect the stable branch if they're
not.
It will become all bigfixes will be based on code that
contains the new
feature.
Manu:
This was mentioned in the group numerous times before, here's one
more time to increase awareness even more:
git flow - http://nvie.com/posts/a-successful-git-branching-model/
should be easily adapted for the D development process.
Walter:
a champion cannot solve this issue as this requires participation
of all (core) developers. Otherwise we get a _lot_ of redundant
after the fact maintenance work. The only way to succeed long
term is to remove all single points of failures - the single
master branch on the technical side, and a single decision making
person (you) on the management side. It can only be possible if
you agree to relinquish some control and allow other core
developers to _fully_ participate. that includes - review/pull
powers, managing their own branches, taking part in the decision
making process as to what feature is mature enough to be
"released" on the stable branch. No champion can do any of that
as it requires your agreement and participation.
Until such changes happen and D becomes _a community process_ (as
I see Andrei is rightfully pushing for) there is little chance of
a bigger D success.
Also, just to touch the multiple compiler versions overhead you
mentioned - The point of maintaining multiple branches is to
_minimize_ such overhead, not increase it. This allows for easier
management of features, a more gradual release process to prevent
regressions and breakage on the release branch, it gives _more
control_ and allows for scaling of management to more developers.
more branches => less work for you.
