On 11/5/13 2:02 PM, Andreas Stieger wrote:
> Isn't "producing an alpha" essentially just the same as pointing people
> at a specific tarball made from a trunk revision that the project
> considers worthy of testing? This already exists:
> http://subversion.apache.org/source-code.html#nightlies
> http://ci.apache.org/projects/subversion/nightlies/index.html
> I don't suppose you want whole signing off dance?
It would be more of a normal release process. So there would be a tag,
appropriately labeled releases (that when built show up as 1.9.0-alpha1) and
yes I intend to do the signing process.
> So doesn't this just boil down to a project communication to the
> intended audience outlining the state of development and inviting
> specific testing and feedback from interested users? That is, unless you
> also reach out to distribution package maintainers, binary vendors and
> integrators who may produce (properly marked) binaries?
Absolutely, a big difference here is the communication piece. We would be
sending out a release announcement for the alpha. We'd be encouraging
packagers and vendors to package and make it available in some place where it
can be appropriately flagged as unstable. So we'd get feedback from people
that would never test the nightly packages or a source tree checkout.
> Also, mind you, if you produce an alpha you encourage feedback on it
> while discouraging anything on changes later in trunk until you produce
> another. How does this compare to "test trunk_at_123 which has XZY, which
> we call alphaN"?
Well right now I'd argue that most people aren't going to test any of the
changes we've made on trunk.
This is largely driven by the desire to get feedback earlier. We didn't get
feedback from users that they didn't like the behavior of the conflict
resolution changes in 1.8.0 until fairly close to the final release. This left
us in the position of feeling that we needed to go ahead with the 1.8.0 release
and then we'd try to improve the conflict resolution later.
The idea here is to get more user feedback sooner while there's lots of time to
make significant changes.
Received on 2013-11-06 02:31:31 CET