>> One "shortcut" that can be taken when a /single file/ must be changed (and as discussed on the list, that change already has consensus), would be to roll the next candidate on a shorter 24 approval clock, provided that everyone had full opportunity to review the candidate, and that rest of the package had already met with general approval.
+1. Couldn't agree more. Thanks, Neha On Tue, Nov 29, 2011 at 10:38 AM, William A. Rowe Jr. <wr...@rowe-clan.net>wrote: > On 11/29/2011 11:30 AM, sebb wrote: > >> On 29 November 2011 16:59, Robert Burrell Donkin >> <robertburrelldon...@gmail.com**> wrote: >> >>> On Tue, Nov 29, 2011 at 4:37 PM, Bertrand Delacretaz >>> <bdelacre...@apache.org> wrote: >>> >>> I agree that a non-minimal NOTICE might not warrant rejecting a podling >>>> release, but the next release should fix that. >>>> >>> >>> This is one of those areas that's difficult and time consuming for the >>> legal team to get right in enough detail to allow simple fixes. Unless >>> more volunteers step up to help, rejecting a release for minimality is >>> likely to mean a lengthy delay. In general, better to note points for >>> improvement and have the team fix them in trunk. >>> >> >> But if the team already agrees that the changes need to be made, why >> not do so and re-roll? >> > > One "shortcut" that can be taken when a /single file/ must be changed > (and as discussed on the list, that change already has consensus), > would be to roll the next candidate on a shorter 24 approval clock, > provided that everyone had full opportunity to review the candidate, > and that rest of the package had already met with general approval. > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > general-unsubscribe@incubator.**apache.org<general-unsubscr...@incubator.apache.org> > For additional commands, e-mail: > general-help@incubator.apache.**org<general-h...@incubator.apache.org> > >
