Alright. I just removed the entire line. It jives with what Bertrand suggested anyways.
Let’s try to avoid “carried votes” and just go with simplified revoting… From my perspective we’ve spent more than enough time on a really insignificant issue. On Dec 9, 2014, at 9:45 AM, Alex Harui <aha...@adobe.com> wrote: > Crud, Unfortunately, I didn’t like either offering. It can’t be the > “same” due diligence since the requestor didn’t examine the current > artifacts. I say we either: > > 1) remove it entirely. This simplifies the guidelines but may complicate > a situation where we don’t have enough voters with enough time. Maybe we > should gamble on that and discuss carryover should we ever need it. > 2) Require that folks requesting carry over state how they conclude the > bits are good (based on git logs, reports from those who did vote, maybe > that they didn’t agree the issue was critical in the first place). This > would provide a “paper trail”. > 3) Not have any additional sentence per my first proposal and trust folks > to use carryover properly > 4) Keep trying to find better words. > 5) Go with Erik’s version anyway. > > Right now I like option #1. > > -Alex > > On 12/8/14, 11:11 PM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: > >> I had to read the 'oversight' line twice to catch it's meaning. I have >> suggested an alternative, please take a look. >> >> EdB >> >> >> >> On Tue, Dec 9, 2014 at 7:58 AM, Harbs <harbs.li...@gmail.com> wrote: >>> Done. I added a sentence defining “carrying” as “oversight”. >>> >>> On Dec 9, 2014, at 2:18 AM, Alex Harui <aha...@adobe.com> wrote: >>> >>>> Maybe I’m being too picky, but the vote proposal said: "I suggest that >>>> at >>>> any point in the release process a vote should be carried over if the >>>> person voting indicates they wish the vote should carry over.” >>>> >>>> The current wiki version says: "The release manager can carry over of >>>> votes from previous release candidates to the new release candidate if >>>> changes between release candidates contain no code changes or changes >>>> to >>>> legally significant documents.” >>>> >>>> I would suggest either removing that section entirely and hoping we >>>> always >>>> have enough folks willing to re-check, or re-wording to: “If a PMC >>>> member >>>> voted on a release candidate, and the release manager creates a new >>>> one, >>>> the PMC member can state that they want their vote to be carried over”. >>>> >>>> And I would suggest moving that point below the one that says that you >>>> don’t have to re-check everything (since re-checking changes is >>>> preferred). >>>> >>>> I wouldn't put any qualifications on what changes do or don’t qualify >>>> for >>>> carryover. I trust each PMC member to be a good judge of when a >>>> carryover >>>> is proper, and we can avoid later arguments on what constitutes a code >>>> change. >>>> >>>> -Alex >>>> >>>> On 12/8/14, 2:18 PM, "Harbs" <harbs.li...@gmail.com> wrote: >>>> >>>>> I don’t see my last two emails in the archives. Sorry if this is going >>>>> out more than once… >>>>> >>>>> Here is a link to the modified wiki.[1] I think the changes are pretty >>>>> minor… I removed mention of carried votes from the voting timeframe >>>>> section, and clarified the wording in the “Product Release” section. >>>>> >>>>> Harbs >>>>> >>>>> [1]https://cwiki.apache.org/confluence/display/FLEX/Guidelines >>>>> >>>> >>> >> >> >> >> -- >> Ix Multimedia Software >> >> Jan Luykenstraat 27 >> 3521 VB Utrecht >> >> T. 06-51952295 >> I. www.ixsoftware.nl >
