Not speaking for Barry or anyone else but myself. This is an explanation of how I understand the process and why I welcome it.
Scott Dial writes: > I don't understand who these alpha releases are supposed to be for, and > who they will serve. An alpha test is internal. It is comprised of those tests the developers working on the product (and/or an affiliated QA department) can imagine. Similarly, an alpha release is of, by, and for the developers. > I'm not sure what developer outside of the core community would > want to work with something missing key features and released > fairly arbitrarily. Developers outside of the core community are not targeted. That said, how do you know that key features are missing? Part of the point of a release is that it says "*this stuff* is working". I want *my* key feature to be part of "this stuff", not *your* key feature. Given "my feature," I download to give the team feedback as early as possible. Lacking yours, you don't. Next alpha, presumably our roles will be reversed. > More to the point, I don't know why a developer wouldn't just checkout > from SVN in any case. Certainly if they are going to help root out bugs, > then we would like them to be using the trunk if possible. I fear that > once an alpha is 2 weeks old, we will start saying "please check if its > still a problem on the trunk." Software development in practice is a matter of "take two steps back, then three steps forward." The point of an alpha release is to checkpoint what is a regression, and what is a temporary "feature" introduced by new development. The latter is admissible on the trunk, but the goal should be none from one alpha to the next. In other words, a bug introduced by new development should be fixed by the next alpha. If it can't be, the developer misjudged the timing of the merge to mainline; it wasn't ready yet. > A mild concern is how this effects checkins with individuals either > trying to meet a deadline or even wait until after an alpha release to > checkin a large change. I'm not sure this will happen, but having > releases scheduled without feature milestones attached certainly changes > the environment for work to be done in. Scheduling feature milestones assumes that people put priority on those features at a given time. Barry can't assume that yet. Once the rhythm is established, Barry can start asking for, and some people will start volunteering, milestone commitments for given releases. I think that it probably is desirable to to put that deadline pressure on. Individuals who rush to get their work in, and cause alpha-to- alpha regressions, can be advised to wait in the future in similar circumstances. Once the rhythm is established, people can expect that alphas will be consistently increasing in features and consistently decreasing in defects. If that's not true, something's wrong with the process, and the team needs to step back and do something about it. But in the nature of software development, *monotone improvement is not something you want to, or even can, impose on the trunk at all points in time*. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
