On Friday, 11 January 2013 at 18:03:33 UTC, mist wrote:
My understanding is that your understanding is somewhat
different from initial proposal but that is where discussion
has flow to since then and that makes me sad :)
They very reason to have staging is to have better replacement
to beta process which simply does not work good enough
currently. Is good to have a single branch all the time, which
some obscure project maintainer can check from time to time to
make sure his stuff still compiles and fire regression bug
reports if needed. He may even have add this test to own
continuous integration suite (I'd do this if I had a serious D
project) to be notified when stuff goes wrong without paying
any constant attention.
Attention is a key here. How many D projects are out there? How
many of their maintainers pay close attention to newsgroup and
read beta mail list? Compare this to being able to check your
stuff on very next release at any moment you have time and want
to.
I stand at the point that for open source projects release and
development processes should care most about end users and
developers and least - about maintainers. Maintainers should
have perfect git and process knowledge anyway, or at some
scales thing are doomed to be crewed (2.061 anyone?).
Thus I vote for a persistent staging branch.
My understanding was that staging is worked on only during the
(short) time span from initiating a new release and finalizing
that release.
Andrei
I don't understand the problem you seem to see in the process.
I've been away from the PC so couldn't respond earlier but I did
manage to read most of the wiki page and I think Johnathan did a
very good job explaining the various concepts. The only thing
missing IMO is CI:
It's already agreed that master is the development channel in the
proposed process. The next logical step would be to generate
nightly builds off of that branch. The staging branch is the
"beta" channel - and also makes sense to have a periodical beta
build. This depends on the release time span but something like
fortnight or monthly beta builds makes sense to me.
the additional manual builds described on the wiki on staging or
even before an official release on the version branch will be
something like RCs.
Regarding pull requests targeting master, the current model *is*
geared around that. Most contributions _should_ go to master (aka
devel) and go through the full process. pull-requests for staging
are meant for fixing regressions and critical bugs only, where
there is _higher urgency_ for the fix that justifies the
short-cut. Regular "bug fixes" should simply go through the
regular process and will be released in the _next_ release.
