This is a FYI for people who are involved with the release. Please
read if you are! (And feel free to ignore if you're not.)
I've revised the procedures to reflect a change that we have
discussed. It's a minor change that I hope will help running things
more smoothly. To summarize it:
Before: * The release branch is created on the 15th
* "Strict" policy for merging after that (source of
arguments and delays)
* Testing begins "about two days" later (usually more)
The thing is that the two days was never completely formal, yet I kept
it since without it the release is basically some random creation
point, and there's no point arguing about changes that were an hour
late, or a day (and the line is of course vague). Instead it would
have been better to stabilize the master -- but that contradicts the
principle of no interference with the main line of work. (To clarify,
the original intention was to create the branch on the 15th and almost
immediately start testing, and I think that this would be pretty
unstable in the sense that there would often be reasons to restart
testing.)
So, after: * The release branch is created on the 7th
* Merges happen whenever the committer ask, pending the
committer's own judgment about the change
* Testing begins on the 15th (almost very strict, but might
move if there's sufficient activity, see below)
The idea is that now there's a week where people should be very aware
of the upcoming release. During this time you need to explicitly ask
for commits to be merged to the release -- and that should make you
rethink the changes on one hand, and make you naturally prioritize
your time towards making the to-be-released code stable on the other.
Theoretically, nothing stops you from committing a major change during
this week and ask for it to be merged, but the fact that you need to
explicitly ask for it should make you naturally more conservative, and
the fact that you need to ask means that there's at least one more
person who is aware of this merge and can alert you and/or others in
case of something that looks suspicious.
I expect this to remove the need to argue about commits going in or
not, since a week should be enough time to get what you want in
working order. Again, limited to finalizing near-complete work,
fixing bugs, and retracting or disabling unstable code that you can't
complete -- and this limit should be natural since you're aware of the
release and since you still need to ask. I expect that at the end of
this week such requests should naturally dwindle down to zero as
people are either satisfied with what goes out or learn to accept that
something they though would go in won't. There might be some
exceptions (eg, there's always the chance of a last minute
semi-disaster like some segfault etc), and in that case testing could
be stretched a bit, but -- I hope -- the chances of that happenning
should be smaller than the current chances, since a non-stress week is
more time for quality ironing than two stressful days.
Once the week has passed and testing begins, then commit merges
becomes extremely strict -- just like they are now at that time. Such
changes might lead to a very costly restarting of the tests, and
worse, to major bugs that go in undetected. So to do that, you really
have to be ready to convince people that your change is really worth
the risk (eg, a segfault), and/or that it is obvious enough to go in
without damage (eg, a typo fix), etc. Of course you need to be
convinced before you start arguing your case... In any case, at this
point there's really no change than the current state.
The revised text is in the same place:
https://internal.racket-lang.org/releases.html
Please go over it again. (And if you're involved with the release and
you've never read it, then it's about time!) (And if the same holds
and you can't read it, then tell me to set up access.)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
