Finally found time to respond to this (while waiting for AIR 14 beta SDK
to download)

On 6/27/14 3:50 AM, "DarkStone" <darkst...@163.com> wrote:

>Hi folks,
>
>Could I have my humble suggestions:
>
>1. Alex is doing so much things, we can see he is very busy these days.
>So about the Legal Issues, can Apache assign someone specifically to do
>the Legal works (Licence & Notice etc.), instead of having Alex to do it.
Unfortunately, Apache doesn't have folks to do the legal stuff.  It is our
responsibility as PMC members with binding votes to get it right.

Justin is correct that legal stuff trumps just about everything at Apache.
 This is a "tax" we have to pay for the promise that more large companies
(and more people in general) will use our product than if we were a GitHub
project.

>
>2. I like the attitude of Justin, he always pays attentions to the very
>details, we actually need that kind of spirit!
I definitely feel better about releasing something Justin has vote +1 on.

>
>3. However, I do agree with Erik that we should move on now, sometimes we
>need to make a compromise, that's life.
I don't know if I would use the word "compromise" regarding legal stuff,
but yes, in general, I try to keep the bigger picture in mind.  For anyone
raising an issue with a release candidate that will require the release
manager to make another release candidate, the thing to consider is: does
it help the community to delay this release for that issue?

And then, if your answer is yes, as a release manager, I would request a
couple of things:

1) check yourself first.  If you find a problem, make sure you did your
test right.
2) provide solutions, not just problems.  In theory all of us are trying
to get the release out as soon as possible so saving the release manager
time should be a goal when providing feedback.  Your feedback should be
formatted like a mini-bug, as in "I got this result, I expected this
result"
3) Try to provide enough detail so the RM doesn't have to duplicate your
steps or guess what your steps were.
4) Make simple changes yourself.  For sure, making controversial changes
to the LICENSE or NOTICE while under heavy debate is not a good idea, but
if you find a typo in README or RELEASE_NOTES and you are a committer,
just fix it (in the release branch, of course).  Otherwise, everyone else
has to read it and wonder if they should fix it.

A goal here should be to make releases "easy" (without violating policy,
of course).  Otherwise it discourages others from volunteering to be an
RM.  Being an RM totally burned out Justin.  I only do it because nobody
else is stepping up and I get paid to do it.  And consider the flip-side:
if we make releasing easier and faster, it might cause us to release more
often so we can pick up some of the minor stuff in the next release.

The LICENSE/NOTICE issue was not minor during its first days: we needed to
make sure we handled third-party subcomponents correctly.  But now I think
we have got it close enough to ship.  We conform to the documents and
guidance, and at least folks can discover that there is non-ASF stuff in
the package.  I also find it interesting that the guidance discouraged
including copyright, but at least folks can google for it.

And so, I'm actually going to spend some cycles on adding more ant scripts
to automate more of the release candidate publishing phase.  Justin has
some shell scripts, but ant is more cross-platform.

-Alex

Reply via email to