"Trevor Daniels" <[email protected]> writes: > David Kastrup wrote Monday, March 18, 2013 11:14 AM > >> The way to do that is to bind people to their predictions of what can >> and cannot be achieved in a certain amount of time by agreeing on a >> timeline in advance and putting in deadlines for certain kinds of >> changes. > > This looks a promising approach. Suppose we ask developers to set out > what new features they would like to complete in time for a 2.18 > release, together with their estimate of the date by which they would > be implemented. Not bug-free, but steered through review and pushed > in a working state. The date would be firm, with the implication that > if it were not met the feature would automatically slip into 2.19. > > We could then review the list, vote as a community on the features to > be implemented in 2.18, and set a time for the release (obviously some > weeks after the last feature date.) Any feature not in the agreed > list would not be accepted for 2.18, and clearly a long estimated > implementation date for any feature might be enough to rule it out. > >> That means agreeing on a policy in advance rather than making decisions >> on the fly, based on the best currently available information. > > Would the above be a start on a policy?
Not really. > At least it would guarantee 2.18 would eventually be released. We'd > need to define 'feature', of course. The current standoff is not about which feature should be desirable or not, but rather what kind of change should be permitted into a stable release. A "feature" consists of functionality, programming APIs and user interfaces. Without well-fitting user interfaces, the functionality will not see a reasonable amount of testing and it will not be possible to make a good-faith effort to making that feature remain accessible in the same manner for more than one release. So it is pointless on focusing on a particular set of features for the release planning. In particular since this will severely disadvantage those programmers with conservative estimates about their work. Instead we need to set deadlines for the state any functionality may be in for the sake of being admitted into master. The first lockdown date will likely be for features of the "dump code now, think about user interface later" variety. They will need to be in a well-confined state where it is possible to just revert them in the stable branch if it turns out that the "think about user interface later" angle will not be satisfactorily addressed until the release. Similarly there will be a deadline for changes of the "this does not affect the actual current feature set, has large repercussions on code stability, but might come in handy some time in future" kind. We'll set up deadlines for various kinds of changes, and when they are voted to belong in a particular category, that means that after they passed the deadline, they will not pass into master. It does not preclude them being worked on in a separate feature branch. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
