accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <>
Subject Re: [DISCUSS] Accumulo Bylaw fixes
Date Wed, 12 Mar 2014 18:23:35 GMT

On Wed, Mar 12, 2014 at 2:16 PM, Josh Elser <> wrote:

> 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).
> I'm not concerned about the changes that get reverted. That is an example
of the system working.

I am more concerned about the changes that might need to be reverted, but
then aren't. Because they're too big, or too complicated, or too messy, or
too whatever. Or they just need a little bit more work, so don't revert
them because I'll be done with it next week, I totally promise.

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 that.
>  >
>>> >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.

I put down a planned RC vote date because that seemed easier than a planned
release date. I'd be fine with either, but really want to include a goal
date so that people have something to shoot for once we start the process
instead of just floundering after feature freeze.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message