accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Re: [DISCUSS] Accumulo Bylaw fixes
Date Wed, 12 Mar 2014 18:16:16 GMT
On 3/12/14, 12:09 PM, Mike Drob wrote:
>> - once a .0-SNAPSHOT branch has been created, every committer should follow
>> >some specified procedure before committing changes to it (I don't mean a
>> >voting procedure, more like soul-searching -- or perhaps a simple
>> >flowchart: Are you committing this change against a blocker or
>> >documentation-only ticket? No => Don't commit or merge it to this branch).
>> >
> Soul searching is a very fuzzy concept that I am not comfortable with for
> being used to drive releases. We've had an implicit (read: unwritten)
> policy that only bug fixes can go into release branches, but many
> developers (myself included) have stretched both the definition of bug and
> the definition of fix. I'm completely on board with always making code
> better, but it's also good to draw a line in the sand somewhere and
> actually make releases.

I think I would actually prefer keeping things looser rather than having 
to ask permission before making a fix (it just slows things down more). 
That feels more in line with our CTR. I also don't think we've really 
had a problem in this department before with changes being applied that 
were then reverted (despite lines being stretched).

Also, even if the only bug-fixes in release branches wasn't written 
down, I don't think there is any ambiguity or disagreement on following 

>> >
>> >Any thoughts or other suggestions on strategies to document?
>> >
> Maybe we can add some release plan/manager basics to the bylaws?
> """A release plan consists of:
>          * a release manager
>          * a proposed version number
>          * a feature freeze date (bug fixes and documentation only)
>          * a code freeze date (documentation only)
>          * a planned rc vote date
> Should any of these dates be missed, the release manager is responsible for
> selecting new dates."""

A planned RC vote might be a bit aggressive. It's hard to judge whether 
or not CI/RW tests will unearth some unknown bug. I like the other 
items, though.

View raw message