Before we establish either bylaws or guidelines which distinguish
between "major" and "minor" releases, I think we need to establish
release versioning standards first. Perhaps that discussion is a
prerequisite to this one? Personally, I think the results of that
discussion would make an excellent first amendment to the bylaws.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Wed, Mar 12, 2014 at 12:09 PM, Mike Drob <mad...@cloudera.com> wrote:
Inline.
On Wed, Mar 12, 2014 at 10:50 AM, Billie Rinaldi
<billie.rina...@gmail.com>wrote:
I disagree with Mike on point 4. This is not a matter of people
not
having
authority, and I don't see a lack of release plans / managers as
the problem behind our major releases not occurring as often as we'd like.
I
wouldn't be opposed to adding a release plan / manager vote as an
optional
step that can be taken when preparing for a release (perhaps a
strongly encouraged or even required step when it's a major release).
In theory, I think this makes sense. Major releases are important
enough and difficult enough that I'd really like to require a release manager.
In
practice our minors tend to be pretty significant minors that still
require
a significant amount of care and preparation, so I think release
managers will still be useful.
I also think
we should consider making the vote lazy consensus, falling back to
majority
approval if a -1 is received.
+0. I think shows stronger support if actually voted on up front,
+but
this
is not a deal breaker for me. Our current process is close to this
already.
However, adding this step will not solve our release woes. Perhaps
something that might help would be to develop a set of suggested
guidelines
to follow or strategies to take when working towards the final
stages
of a
release, post code freeze. At least some of these should be
responsibilities of all committers, not just a release manager.
I did not mean to suggest that this was the only thing needed to
improve our process. Simply that it is an easy solution that I
expect to have positive outcomes. While I agree that all committers
should be held responsible for driving towards a release, different
people will always have different opinions on what needs to be part of any
given release.
What
I think is trivial, you might consider a blocker, and vice versa.
The incomplete feature that I think needs just a little more work,
you could think is immature and should be pulled entirely.
Delegating authority to
a
release manager makes these decisions simpler, while still giving us
flexibility to write the code we each want.
Some guesses for what could go on this list:
- always select a new date when a previously selected date has
passed
Who is responsible for this? If dates are chosen by fiat, then they
quickly
become meaningless. This actually sounds like a great argument _for_
a release manager.
- initiate discussion of remaining tickets / tasks regularly (every
week?)
This can be a very daunting task.
- 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.
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."""
On Tue, Mar 11, 2014 at 1:20 PM, Sean Busbey
<busbey+li...@cloudera.com
wrote:
Moving this over to its own DISCUSS thread so we can keep the
VOTE
easier
to follow.
wrt #4, I'm with Mike on this. One of our big problems, as a
community,
is
lack of steady release cadence. Even once we decide on a feature
freeze,
we
don't have enough rigor in driving to release. For example, 1.6.0
hit feature freeze 4.5 months ago[1]. I think John is doing fine
given the circumstances, but without a date to drive towards it's
hard to
justify
throwing stuff off the raft.
Since we'll presumably be updating the bylaws for the next vote,
I'd
like
to see a definition for the Release Manager role since we
reference
it.
[1]: http://s.apache.org/accumulo_1.6.0_feature_freeze_vote
-Sean
On Tue, Mar 11, 2014 at 1:17 PM, Mike Drob <mad...@cloudera.com>
wrote:
1) Agree w/ Bill.
2) Agree w/ Bill.
3) In my understanding, codebase includes the site svn, the
primary
git
repository, and all contrib repositories. Adoption of a new
codebase generally refers to the creation of a new contrib repository.
However,
I
could see it also expanded to cover things like re-doing the
entire
site
look and feel, or merging a contrib project into the primary
codebase.
Christopher, do you have any proposed verbiage that you would
like
to
see
specifically?
4) I very much disagree, Christopher. Having a dedicated
release
manager
is
critical to having a release occur in a timely manner. Further,
the community needs to be able to make hard decisions, like
setting a
feature
or code freeze date, or pulling incomplete work out of a branch.
Right
now,
we have release managers in name only, and I would love to see
us
give
them
more authority on performing the release - right now we have a
steady
stream of small changes that developers feel should be exempt
from
the
freeze, something I'm guilty of myself as well. I see the lack
of a formalized release plan as one reason for why releases
tend to drag
on
for
far too long.
In short, if we don't have a release manager pushing for them,
then releases just won't happen. It's a gruelling task, and we
need to
have
procedure to bless somebody to do it.
Mike
On Mon, Mar 10, 2014 at 11:03 PM, Bill Havanki <
bhava...@clouderagovt.com
wrote:
My sense from the conversations leading up to the vote:
1) I believe the list is comprehensive, in that no other
voting
actions
are
contemplated. If we realize we need a new one, we can add it
later.
2) We determined that a committer, by ASF rules, cannot truly
lose committer status [1], so no removal procedure is
defined. Removal
of
a
PMC
member is up to the ASF Board [2], so no procedure is defined.
3) I see no harm in adding a definition.
4) I think the "release plan" is the process for cutting a
release,
while
"product release" is for approving a specific RC as the release.
For
me,
a
boilerplate release plan with customizations (who is the RM,
what
tests
are
needed, time frame for freezes, etc.) would be nice to have
laid
out.
[1]
http://www.apache.org/dev/committers.html#committer-set-term
[2] http://www.apache.org/dev/pmc.html#pmc-removal
On Mon, Mar 10, 2014 at 5:52 PM, Christopher
<ctubb...@apache.org
wrote:
Since I didn't technically vote, I guess I will now:
I'm going to give it a -1, pending the resolution the
following issues, and for an opportunity to correct the
minor
punctuation/typos.
Specifically, I'd like these addressed before I change my vote:
1) clarification of whether the ACTIONS list is
comprehensive
2) clarify reinstatement in the absence of a lack of
removal
procedures
3) codebase defined (or at least, Adoption of New Codebase
clarified)
4) remove "release plan" as requiring a vote (or discuss),
because
while it is nice to coordinate release candidates through a
release
manager, I'm not sure it should be strictly necessary that
release
candidates be planned, or limited to that release manager.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Mon, Mar 10, 2014 at 5:08 PM, Christopher <
ctubb...@apache.org>
wrote:
***Punctuation:
PMC section:
"PMC from a Foundation perspective is" -> "PMC, from a
Foundation
perspective, is"
"Secondly " -> "Secondly,"
"long term" -> "long-term"
"not coding - but to ensure" -> "not coding, but to ensure"
"Within the ASF we worry" -> "Within the ASF, we worry"
VETOES section (comma):
"veto - merely that" -> "veto, merely that"
***Typos:
APPROVALS section (typo):
"that -1 votes" -> "than -1 votes"
***Definitions:
I would like to see "codebase" defined. It's used
throughout,
but
is
never clearly defined... particularly in the "Adoption of
New Codebase" section of the ACTIONS section.
***Other:
In the ACTIONS section, it describes reinstatement
actions,
but
not
removal actions, so it's not clear what reinstatement means.
It should also be made clear that the ACTIONS section is
not a comprehensive list of actions.
I'm also not sure that the "Release plan" should require
a
vote,
as
this seems covered by the "Product release" situation.
The
other
actions seem to imply a vote is required for that action.
Are
we
saying that planning to release requires a vote? If so, I
can
get
on
board... I just don't remember that happening in the
past, so
this
isn't so much a formalization of our existing practices,
but
also
establishing a new one as well. And, in this case, I'm
not
sure
it's
one we need.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
