You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Joe Schaefer <jo...@yahoo.com> on 2013/01/12 18:07:52 UTC
[DISCUSS] Expressing priorities about release reviews
One of my long time pet peeves with how we
PMC members participate in vetting releases
is our penchant for focusing too much on the
policies surrounding license and notice info.
I really think our exclusive focus on things
that really don't pose any organizational risk
to either the org nor the project participants
serves us well in our other, often unexpressed
but far more relevant, goals about encouraging
committers to participate in active review of
their project's commit activity.
Just think about this for a second, what's more
likely for people to start suing us over, some
bug in the NOTICE file or an undetected backdoor
in one of our programs? I am personally far more
concerned about the current state of the actual
review going on in our podlings than I am about
NOTICE minutia.
Maybe we should compile some list of which committers
are actually subscribed to their project's commit lists?
It's crude but it may be useful data to look at to
a first order.
Re: [DISCUSS] Expressing priorities about release reviews
Posted by Roman Shaposhnik <rv...@apache.org>.
On Sat, Jan 12, 2013 at 9:07 AM, Joe Schaefer <jo...@yahoo.com> wrote:
> Just think about this for a second, what's more
> likely for people to start suing us over, some
> bug in the NOTICE file or an undetected backdoor
> in one of our programs? I am personally far more
> concerned about the current state of the actual
> review going on in our podlings than I am about
> NOTICE minutia.
I agree with your general concern of us missing the
forest for the trees. Yet, I have no silver bullet for
how to visualize the forest either except for trying
to infuse the sense of urgency around these issues
into the incubating PMCs.
Thus I view us being pedantic when it comes to licensing
minutia as a double edge sword. On one hand, we should
never forget that this is but the simplest way of us harping
on one of the most important issue for the foundation and
NOT a end in and of itself. On the other hand, if we stop
using licensing nits as a forcing function to make PMC aware,
I'm not sure we are left with too many chance of having
that type of a conversation with the project.
Thanks,
Roman.
P.S. I know this could be difficult for the veterans to appreciate,
but I constantly come across fresh grads not understanding
licensing implication *at all*. This is especially true for those who
by the luck of a draw ended up interning/etc for the service-oriented
companies like Google/Twitter/Facebook/Yahoo (cue RMS with
AGPL ;-)).
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Expressing priorities about release reviews
Posted by Dave Fisher <da...@comcast.net>.
On Jan 12, 2013, at 11:29 AM, Joe Schaefer wrote:
> Yes you make a good point- that any effort
> towards review is welcome and appreciated.
> It's just that having an exclusive focus
> on the things we can actually review here,
> namely adherence to License and Notice policy,
> can leave people with the mistaken impression
> that that's all that a PMC should concern itself
> with. All of that daily effort that goes into
> validating commits on a project really should
> garner more appreciation from the PMC, if we
> could just find a way to be more trusting about
> who we let issue binding votes on behalf of
> the org.
>
>
> Really is it so bad to say to a project with
> a bug in their license and notice info: fix
> this in trunk and show me the revision and
> I'll go ahead and approve your release as-is.
>
> Running through iterations of this is very
> labor-intensive for the project, and anything
> we can do to cut down on the pain involved
> in cutting incubator releases is IMO worthwhile.
It is a mentoring issue. Some projects push commits onto their dev lists which forces attention, but others do not for legitimate reasons.
I like your idea of a commit list subscriber report. Perhaps there should be a monthly email from infra that reports to a project or podling the following:
(1) Subscribers to commit list.
(2) Table of commits to either svn or git with totals of commits and size of changes along with information for the top 10 (or all) commits.
Since the list of subscribers should be private this can go to the PPMC monthly and the monthly or quarterly report can go to the IPMC on the report schedule.
With Mentor's guidance projects will be gently guided into paying enough attention. The IPMC can start paying attention to this data as it is a quick way to get an opinion about how a podling is doing.
Regards,
Dave
>
>
>
>
>
>> ________________________________
>> From: Sergio Fernández <se...@salzburgresearch.at>
>> To: general@incubator.apache.org
>> Cc: Joe Schaefer <jo...@yahoo.com>
>> Sent: Saturday, January 12, 2013 2:22 PM
>> Subject: Re: [DISCUSS] Expressing priorities about release reviews
>>
>> Joe,
>>
>> personally I appreciate such policies checking from the IPMC members. The technical quality of a release is responsibility of the project itself, which could be hard to be evaluated by people working on other topics. Therefore, all additional checkpoints are useful and grateful.
>>
>> Cheers,
>>
>>
>> On 12/01/13 18:07, Joe Schaefer wrote:
>>> One of my long time pet peeves with how we
>>> PMC members participate in vetting releases
>>> is our penchant for focusing too much on the
>>> policies surrounding license and notice info.
>>> I really think our exclusive focus on things
>>> that really don't pose any organizational risk
>>> to either the org nor the project participants
>>> serves us well in our other, often unexpressed
>>> but far more relevant, goals about encouraging
>>> committers to participate in active review of
>>> their project's commit activity.
>>>
>>> Just think about this for a second, what's more
>>> likely for people to start suing us over, some
>>> bug in the NOTICE file or an undetected backdoor
>>> in one of our programs? I am personally far more
>>> concerned about the current state of the actual
>>> review going on in our podlings than I am about
>>> NOTICE minutia.
>>>
>>> Maybe we should compile some list of which committers
>>> are actually subscribed to their project's commit lists?
>>> It's crude but it may be useful data to look at to
>>> a first order.
>>>
>>
>> -- Sergio Fernández
>> Salzburg Research
>> +43 662 2288 318
>> Jakob-Haringer Strasse 5/II
>> A-5020 Salzburg (Austria)
>> http://www.salzburgresearch.at
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Expressing priorities about release reviews
Posted by Benson Margulies <bi...@gmail.com>.
On Sun, Jan 13, 2013 at 5:34 PM, Craig L Russell
<cr...@oracle.com> wrote:
> There have been many opinions expressed over the last few years about what
> constitutes a "release". At least one opinion was that having the source in
> SCM that is freely available constitutes "release" and therefore best
> practice is to mark the source directory with the appropriate source LICENSE
> and NOTICE.
>
> Obviously, the LICENSE and NOTICE might be different for binary releases
> that include some dependencies that are distributed only with convenience
> binary releases.
>
> But many of the incubator release issues I've seen could have been avoided
> simply by including the LICENSE and NOTICE files in the source root, making
> it very difficult to release source without these files.
I'm happy to state a best practice here. At the same time, I'd like to
establish a firm basis of actual requirements that we can refer to,
which I why I opened LEGAL-155.
>
> Craig
>
>
> On Jan 13, 2013, at 2:14 PM, Benson Margulies wrote:
>
>> Is it actually required to have these files in SCM in any particular
>> location, or just to have a build/packaging process that delivers them
>> in the package?
>>
>>
>> On Sun, Jan 13, 2013 at 3:30 PM, Craig L Russell
>> <cr...@oracle.com> wrote:
>>>
>>> We can also add a checklist item to the top level checklists, to be done
>>> as
>>> part of the source migration:
>>>
>>> Add LICENSE and NOTICE files to the top level repository directory. [I
>>> don't
>>> know if there is anything more specific than that, because where a
>>> project
>>> is using project/trunk, project/site, project/branches style it would go
>>> into the project/trunk directory and thence propagated to branches etc.]
>>>
>>> Craig
>>>
>>>
>>> On Jan 13, 2013, at 7:51 AM, Andy Seaborne wrote:
>>>
>>>> On 13/01/13 12:45, Benson Margulies wrote:
>>>> ...
>>>>>
>>>>>
>>>>> 3. Most of the reviewing in this area is done by sebb. We're lucky to
>>>>> have him paying attention to this at all, because it sure seems
>>>>> sometimes as if no one else does.
>>>>>
>>>>> Adding all of this up, I've got a very modest proposal. Let's create a
>>>>> checklist, put it prominently at the top of the relevant doc, and then
>>>>> see if we can't improve the visibility of this. Sebb, could I ask you
>>>>> to dump your checklist into this email thread?
>>>>
>>>>
>>>>
>>>> +1
>>>>
>>>> We need to clone sebb's reviewing process as good practice and it would
>>>> pull together the knowledge about N&L.
>>>>
>>>> Andy
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>
>>>
>>> Craig L Russell
>>> Architect, Oracle
>>> http://db.apache.org/jdo
>>> 408 276-5638 mailto:Craig.Russell@oracle.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> Craig L Russell
> Architect, Oracle
> http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@oracle.com
> P.S. A good JDO? O, Gasp!
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Expressing priorities about release reviews
Posted by Craig L Russell <cr...@oracle.com>.
There have been many opinions expressed over the last few years about
what constitutes a "release". At least one opinion was that having the
source in SCM that is freely available constitutes "release" and
therefore best practice is to mark the source directory with the
appropriate source LICENSE and NOTICE.
Obviously, the LICENSE and NOTICE might be different for binary
releases that include some dependencies that are distributed only with
convenience binary releases.
But many of the incubator release issues I've seen could have been
avoided simply by including the LICENSE and NOTICE files in the source
root, making it very difficult to release source without these files.
Craig
On Jan 13, 2013, at 2:14 PM, Benson Margulies wrote:
> Is it actually required to have these files in SCM in any particular
> location, or just to have a build/packaging process that delivers them
> in the package?
>
>
> On Sun, Jan 13, 2013 at 3:30 PM, Craig L Russell
> <cr...@oracle.com> wrote:
>> We can also add a checklist item to the top level checklists, to be
>> done as
>> part of the source migration:
>>
>> Add LICENSE and NOTICE files to the top level repository directory.
>> [I don't
>> know if there is anything more specific than that, because where a
>> project
>> is using project/trunk, project/site, project/branches style it
>> would go
>> into the project/trunk directory and thence propagated to branches
>> etc.]
>>
>> Craig
>>
>>
>> On Jan 13, 2013, at 7:51 AM, Andy Seaborne wrote:
>>
>>> On 13/01/13 12:45, Benson Margulies wrote:
>>> ...
>>>>
>>>> 3. Most of the reviewing in this area is done by sebb. We're
>>>> lucky to
>>>> have him paying attention to this at all, because it sure seems
>>>> sometimes as if no one else does.
>>>>
>>>> Adding all of this up, I've got a very modest proposal. Let's
>>>> create a
>>>> checklist, put it prominently at the top of the relevant doc, and
>>>> then
>>>> see if we can't improve the visibility of this. Sebb, could I ask
>>>> you
>>>> to dump your checklist into this email thread?
>>>
>>>
>>> +1
>>>
>>> We need to clone sebb's reviewing process as good practice and it
>>> would
>>> pull together the knowledge about N&L.
>>>
>>> Andy
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>
>> Craig L Russell
>> Architect, Oracle
>> http://db.apache.org/jdo
>> 408 276-5638 mailto:Craig.Russell@oracle.com
>> P.S. A good JDO? O, Gasp!
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@oracle.com
P.S. A good JDO? O, Gasp!
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Expressing priorities about release reviews
Posted by Benson Margulies <bi...@gmail.com>.
Is it actually required to have these files in SCM in any particular
location, or just to have a build/packaging process that delivers them
in the package?
On Sun, Jan 13, 2013 at 3:30 PM, Craig L Russell
<cr...@oracle.com> wrote:
> We can also add a checklist item to the top level checklists, to be done as
> part of the source migration:
>
> Add LICENSE and NOTICE files to the top level repository directory. [I don't
> know if there is anything more specific than that, because where a project
> is using project/trunk, project/site, project/branches style it would go
> into the project/trunk directory and thence propagated to branches etc.]
>
> Craig
>
>
> On Jan 13, 2013, at 7:51 AM, Andy Seaborne wrote:
>
>> On 13/01/13 12:45, Benson Margulies wrote:
>> ...
>>>
>>> 3. Most of the reviewing in this area is done by sebb. We're lucky to
>>> have him paying attention to this at all, because it sure seems
>>> sometimes as if no one else does.
>>>
>>> Adding all of this up, I've got a very modest proposal. Let's create a
>>> checklist, put it prominently at the top of the relevant doc, and then
>>> see if we can't improve the visibility of this. Sebb, could I ask you
>>> to dump your checklist into this email thread?
>>
>>
>> +1
>>
>> We need to clone sebb's reviewing process as good practice and it would
>> pull together the knowledge about N&L.
>>
>> Andy
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> Craig L Russell
> Architect, Oracle
> http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@oracle.com
> P.S. A good JDO? O, Gasp!
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Expressing priorities about release reviews
Posted by Craig L Russell <cr...@oracle.com>.
We can also add a checklist item to the top level checklists, to be
done as part of the source migration:
Add LICENSE and NOTICE files to the top level repository directory. [I
don't know if there is anything more specific than that, because where
a project is using project/trunk, project/site, project/branches style
it would go into the project/trunk directory and thence propagated to
branches etc.]
Craig
On Jan 13, 2013, at 7:51 AM, Andy Seaborne wrote:
> On 13/01/13 12:45, Benson Margulies wrote:
> ...
>> 3. Most of the reviewing in this area is done by sebb. We're lucky to
>> have him paying attention to this at all, because it sure seems
>> sometimes as if no one else does.
>>
>> Adding all of this up, I've got a very modest proposal. Let's
>> create a
>> checklist, put it prominently at the top of the relevant doc, and
>> then
>> see if we can't improve the visibility of this. Sebb, could I ask you
>> to dump your checklist into this email thread?
>
> +1
>
> We need to clone sebb's reviewing process as good practice and it
> would pull together the knowledge about N&L.
>
> Andy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@oracle.com
P.S. A good JDO? O, Gasp!
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Expressing priorities about release reviews
Posted by Andy Seaborne <an...@apache.org>.
On 13/01/13 12:45, Benson Margulies wrote:
...
> 3. Most of the reviewing in this area is done by sebb. We're lucky to
> have him paying attention to this at all, because it sure seems
> sometimes as if no one else does.
>
> Adding all of this up, I've got a very modest proposal. Let's create a
> checklist, put it prominently at the top of the relevant doc, and then
> see if we can't improve the visibility of this. Sebb, could I ask you
> to dump your checklist into this email thread?
+1
We need to clone sebb's reviewing process as good practice and it would
pull together the knowledge about N&L.
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Expressing priorities about release reviews
Posted by Benson Margulies <bi...@gmail.com>.
On Sun, Jan 13, 2013 at 12:51 PM, Marvin Humphrey
<ma...@rectangular.com> wrote:
> On Sun, Jan 13, 2013 at 4:45 AM, Benson Margulies <bi...@gmail.com> wrote:
>> 1. Why are podlings having so much trouble getting the legal metadata
>> correct?
>
> * Our documentation on legal metadata is ill-organized, voluminous, and
> ultimately overwhelming.
> * The NOTICE construct is fundamentally confusing.
> * Few software developers have the patience, the temperament, and more than
> anything else the raw hours to acquire a lot of expertise about licensing.
>
>> Adding all of this up, I've got a very modest proposal. Let's create a
>> checklist, put it prominently at the top of the relevant doc, and then
>> see if we can't improve the visibility of this.
>
> I am skeptical that the information necessary to build LICENSE and NOTICE can
> be expressed in a checklist. The problem is that LICENSE and NOTICE still
> start as blank pages, and filling them in from scratch requires expertise
> which is costly to acquire.
>
> I suspect that a "LICENSE-o-matic" approach will yield better results, because
> it relieves the developer from having to conceive of a basic structure for
> LICENSE and NOTICE. Here is some sample pseudocode for appending dependency
> information to NOTICE:
>
> SUBROUTINE append_to_notice(notice, dependency):
>
> # Only bundled dependencies get considered for NOTICE!
> IF NOT dependency.bundled:
> RETURN
>
> IF dependency.license IS MIT_X11:
> PASS # No NOTICE requirement
> ELIF dependency.license IS THREE_CLAUSE_BSD:
> PASS # No NOTICE requirement
> ELIF dependency.license IS APACHE_LICENSE_V2:
> IF has_notice_file(dependency):
> IF is_apache_product(dependency):
> ...
> ELSE
> ...
> ELIF dependency.license IS FOUR_CLAUSE_BSD:
> ...
>
> ...
>
> # Recurse for nested dependencies.
> FOR nested_dependency IN dependency.nested_dependencies:
> append_to_notice(notice, nested_dependency)
>
> For the beginning of such a document, see...
>
> How-to guide for "Assembling LICENSE and NOTICE"
> https://issues.apache.org/jira/browse/INCUBATOR-125
>
> PS: This thread was originally about how our hyper-focus on LICENSE and
> NOTICE distracts us from more important concerns, both legal and social.
> I agree with that assessment and regret contributing to the diversion once
> more.
Let me start from the p.s.. I agree that we currently seem to spend a
depressingly large amount of time on these. However, I don't see how
to fix that by just telling ourselves that they are not very
important. I think we need to fix this by finding a way to make it
much easier to get them right. I'm all ears as to all possible ways to
accomplish this.
In terms of the other possible areas of attention, I sadly think that
this becomes the same old discussion about mentors. The people who are
supposed to be ensuring adequate supervision for what gets committed
are the mentors. If we continue to be unable to maintain adequate
levels of mentor involvement, we have a bigger problem.
Sebb's critique's of NOTICE and LICENSE are rarely at the level of
'hey, this would be the right license in the right file but it's an
MIT license so you don't need to bother.' More of the time, as I see
it, the critique is that one or both is missing altogether, or that
completely backwards contents are present in them.
I will add some comments to the JIRA.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Expressing priorities about release reviews
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Sun, Jan 13, 2013 at 4:45 AM, Benson Margulies <bi...@gmail.com> wrote:
> 1. Why are podlings having so much trouble getting the legal metadata
> correct?
* Our documentation on legal metadata is ill-organized, voluminous, and
ultimately overwhelming.
* The NOTICE construct is fundamentally confusing.
* Few software developers have the patience, the temperament, and more than
anything else the raw hours to acquire a lot of expertise about licensing.
> Adding all of this up, I've got a very modest proposal. Let's create a
> checklist, put it prominently at the top of the relevant doc, and then
> see if we can't improve the visibility of this.
I am skeptical that the information necessary to build LICENSE and NOTICE can
be expressed in a checklist. The problem is that LICENSE and NOTICE still
start as blank pages, and filling them in from scratch requires expertise
which is costly to acquire.
I suspect that a "LICENSE-o-matic" approach will yield better results, because
it relieves the developer from having to conceive of a basic structure for
LICENSE and NOTICE. Here is some sample pseudocode for appending dependency
information to NOTICE:
SUBROUTINE append_to_notice(notice, dependency):
# Only bundled dependencies get considered for NOTICE!
IF NOT dependency.bundled:
RETURN
IF dependency.license IS MIT_X11:
PASS # No NOTICE requirement
ELIF dependency.license IS THREE_CLAUSE_BSD:
PASS # No NOTICE requirement
ELIF dependency.license IS APACHE_LICENSE_V2:
IF has_notice_file(dependency):
IF is_apache_product(dependency):
...
ELSE
...
ELIF dependency.license IS FOUR_CLAUSE_BSD:
...
...
# Recurse for nested dependencies.
FOR nested_dependency IN dependency.nested_dependencies:
append_to_notice(notice, nested_dependency)
For the beginning of such a document, see...
How-to guide for "Assembling LICENSE and NOTICE"
https://issues.apache.org/jira/browse/INCUBATOR-125
PS: This thread was originally about how our hyper-focus on LICENSE and
NOTICE distracts us from more important concerns, both legal and social.
I agree with that assessment and regret contributing to the diversion once
more.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Expressing priorities about release reviews
Posted by Benson Margulies <bi...@gmail.com>.
I'd like to try to break this down a bit. I'm ignoring, for this
reply, the questions Joe raises about supervising things other than
the legal metadata.
1. Why are podlings having so much trouble getting the legal metadata
correct? Every single existing Apache release is a sample. The top
problem area seems to be NOTICE and LICENSE, with notices on
individual source files far behind.
2. I agree with some in this thread that problems in this area are not
sufficient reason to block any _single_ release. Copyright comes into
existence whether or not you paste a notice on it. Failing to respect
a third-party notice requirement is rude, but, as someone pointed out,
is not a giant legal exposure. I also have a suspicion that many
podling _releases_ (i.e. the source) have, in fact, no third-party
license exposure at all.
While it might not deserve to block any one release, I agree with the
point that we can't be graduating podlings who don't know how to
maintain this metadata. If (and I'm not being rhetorical here) we
treat these as 'fix it next time', we'd better be sure that there is a
next time.
3. Most of the reviewing in this area is done by sebb. We're lucky to
have him paying attention to this at all, because it sure seems
sometimes as if no one else does.
Adding all of this up, I've got a very modest proposal. Let's create a
checklist, put it prominently at the top of the relevant doc, and then
see if we can't improve the visibility of this. Sebb, could I ask you
to dump your checklist into this email thread?
On Sat, Jan 12, 2013 at 5:59 PM, Craig L Russell
<cr...@oracle.com> wrote:
> The way I look at release reviews is that releases are the things that
> expose the Apache Foundation to the greatest legal risk, so it's critical
> that podlings learn to get them right. If they (podlings) don't get releases
> right in the incubator, what chance is there that they will succeed as a
> PMC?
>
> Technical review can only be done by folks who are knowledgeable about the
> code base. These are the committers on the project. Process review can be
> done by mentors. Ideally, license and notice reviews should be done first by
> mentors. But I don't expect that mentors will necessarily know as much as
> people in IPMC (and other volunteer release reviewers) about the legal
> requirements for release.
>
> From my perspective, even though it is at times painful, the release process
> works well. Everyone in the incubator contributes what they can to make sure
> that podlings learn how to release, and how important it is to release clean
> code. Even if the code doesn't work, the process does.
>
> Craig
>
>
>
> On Jan 12, 2013, at 11:29 AM, Joe Schaefer wrote:
>
>> Yes you make a good point- that any effort
>> towards review is welcome and appreciated.
>> It's just that having an exclusive focus
>> on the things we can actually review here,
>> namely adherence to License and Notice policy,
>> can leave people with the mistaken impression
>> that that's all that a PMC should concern itself
>> with. All of that daily effort that goes into
>> validating commits on a project really should
>> garner more appreciation from the PMC, if we
>> could just find a way to be more trusting about
>> who we let issue binding votes on behalf of
>> the org.
>>
>>
>> Really is it so bad to say to a project with
>> a bug in their license and notice info: fix
>> this in trunk and show me the revision and
>> I'll go ahead and approve your release as-is.
>>
>> Running through iterations of this is very
>> labor-intensive for the project, and anything
>> we can do to cut down on the pain involved
>> in cutting incubator releases is IMO worthwhile.
>>
>>
>>
>>
>>
>>> ________________________________
>>> From: Sergio Fernández <se...@salzburgresearch.at>
>>> To: general@incubator.apache.org
>>> Cc: Joe Schaefer <jo...@yahoo.com>
>>> Sent: Saturday, January 12, 2013 2:22 PM
>>> Subject: Re: [DISCUSS] Expressing priorities about release reviews
>>>
>>> Joe,
>>>
>>> personally I appreciate such policies checking from the IPMC members. The
>>> technical quality of a release is responsibility of the project itself,
>>> which could be hard to be evaluated by people working on other topics.
>>> Therefore, all additional checkpoints are useful and grateful.
>>>
>>> Cheers,
>>>
>>>
>>> On 12/01/13 18:07, Joe Schaefer wrote:
>>>>
>>>> One of my long time pet peeves with how we
>>>> PMC members participate in vetting releases
>>>> is our penchant for focusing too much on the
>>>> policies surrounding license and notice info.
>>>> I really think our exclusive focus on things
>>>> that really don't pose any organizational risk
>>>> to either the org nor the project participants
>>>> serves us well in our other, often unexpressed
>>>> but far more relevant, goals about encouraging
>>>> committers to participate in active review of
>>>> their project's commit activity.
>>>>
>>>> Just think about this for a second, what's more
>>>> likely for people to start suing us over, some
>>>> bug in the NOTICE file or an undetected backdoor
>>>> in one of our programs? I am personally far more
>>>> concerned about the current state of the actual
>>>> review going on in our podlings than I am about
>>>> NOTICE minutia.
>>>>
>>>> Maybe we should compile some list of which committers
>>>> are actually subscribed to their project's commit lists?
>>>> It's crude but it may be useful data to look at to
>>>> a first order.
>>>>
>>>
>>> -- Sergio Fernández
>>> Salzburg Research
>>> +43 662 2288 318
>>> Jakob-Haringer Strasse 5/II
>>> A-5020 Salzburg (Austria)
>>> http://www.salzburgresearch.at
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>>>
>
> Craig L Russell
> Architect, Oracle
> http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@oracle.com
> P.S. A good JDO? O, Gasp!
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Expressing priorities about release reviews
Posted by Craig L Russell <cr...@oracle.com>.
The way I look at release reviews is that releases are the things that
expose the Apache Foundation to the greatest legal risk, so it's
critical that podlings learn to get them right. If they (podlings)
don't get releases right in the incubator, what chance is there that
they will succeed as a PMC?
Technical review can only be done by folks who are knowledgeable about
the code base. These are the committers on the project. Process review
can be done by mentors. Ideally, license and notice reviews should be
done first by mentors. But I don't expect that mentors will
necessarily know as much as people in IPMC (and other volunteer
release reviewers) about the legal requirements for release.
From my perspective, even though it is at times painful, the release
process works well. Everyone in the incubator contributes what they
can to make sure that podlings learn how to release, and how important
it is to release clean code. Even if the code doesn't work, the
process does.
Craig
On Jan 12, 2013, at 11:29 AM, Joe Schaefer wrote:
> Yes you make a good point- that any effort
> towards review is welcome and appreciated.
> It's just that having an exclusive focus
> on the things we can actually review here,
> namely adherence to License and Notice policy,
> can leave people with the mistaken impression
> that that's all that a PMC should concern itself
> with. All of that daily effort that goes into
> validating commits on a project really should
> garner more appreciation from the PMC, if we
> could just find a way to be more trusting about
> who we let issue binding votes on behalf of
> the org.
>
>
> Really is it so bad to say to a project with
> a bug in their license and notice info: fix
> this in trunk and show me the revision and
> I'll go ahead and approve your release as-is.
>
> Running through iterations of this is very
> labor-intensive for the project, and anything
> we can do to cut down on the pain involved
> in cutting incubator releases is IMO worthwhile.
>
>
>
>
>
>> ________________________________
>> From: Sergio Fernández <se...@salzburgresearch.at>
>> To: general@incubator.apache.org
>> Cc: Joe Schaefer <jo...@yahoo.com>
>> Sent: Saturday, January 12, 2013 2:22 PM
>> Subject: Re: [DISCUSS] Expressing priorities about release reviews
>>
>> Joe,
>>
>> personally I appreciate such policies checking from the IPMC
>> members. The technical quality of a release is responsibility of
>> the project itself, which could be hard to be evaluated by people
>> working on other topics. Therefore, all additional checkpoints are
>> useful and grateful.
>>
>> Cheers,
>>
>>
>> On 12/01/13 18:07, Joe Schaefer wrote:
>>> One of my long time pet peeves with how we
>>> PMC members participate in vetting releases
>>> is our penchant for focusing too much on the
>>> policies surrounding license and notice info.
>>> I really think our exclusive focus on things
>>> that really don't pose any organizational risk
>>> to either the org nor the project participants
>>> serves us well in our other, often unexpressed
>>> but far more relevant, goals about encouraging
>>> committers to participate in active review of
>>> their project's commit activity.
>>>
>>> Just think about this for a second, what's more
>>> likely for people to start suing us over, some
>>> bug in the NOTICE file or an undetected backdoor
>>> in one of our programs? I am personally far more
>>> concerned about the current state of the actual
>>> review going on in our podlings than I am about
>>> NOTICE minutia.
>>>
>>> Maybe we should compile some list of which committers
>>> are actually subscribed to their project's commit lists?
>>> It's crude but it may be useful data to look at to
>>> a first order.
>>>
>>
>> -- Sergio Fernández
>> Salzburg Research
>> +43 662 2288 318
>> Jakob-Haringer Strasse 5/II
>> A-5020 Salzburg (Austria)
>> http://www.salzburgresearch.at
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>>
Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@oracle.com
P.S. A good JDO? O, Gasp!
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Expressing priorities about release reviews
Posted by Benson Margulies <bi...@gmail.com>.
I don't think that it's up to the IPMC to decide that the legal
notices aren't worth getting right unless a corporate elephant decided
to trumpet about them. My view is that we, as a PMC, are responsible
for only shipping releases that meet some minimum standard. I am
trying to extract a definition of that minimum standard from legal.
On Mon, Jan 14, 2013 at 12:50 PM, Joe Schaefer <jo...@yahoo.com> wrote:
> Trust me, nobody here has any legal training either.
> We're just more familiar with policy, not so much the
> rationale behind it. And no I'm not saying this
> kind of review is worthless, I'm just trying to
> adjust priorities to better match reality- we can
> provide this "legal" feedback in other ways than simply
> voting against a release, and that's what I'm
> pointing out here.
>
>
>
>
> ----- Original Message -----
>> From: Alex Harui <ah...@adobe.com>
>> To: Joe Schaefer <jo...@yahoo.com>; "general@incubator.apache.org" <ge...@incubator.apache.org>
>> Cc:
>> Sent: Monday, January 14, 2013 12:46 PM
>> Subject: Re: [DISCUSS] Expressing priorities about release reviews
>>
>>
>>
>>
>> On 1/14/13 9:20 AM, "Joe Schaefer" <jo...@yahoo.com>
>> wrote:
>>
>>> The thing is Alex, all of this effort
>>> to dot our i's and cross our t's on the legal
>>> issues really is only for the benefit
>>> of major corporations who want to incorporate
>>> our work into some corporate-branded application.
>>> Actual end users of our software do not benefit
>>> one iota from the type of nitpicking we do on
>>> general@incubator, nor does the org's reputation
>>> for clean IP hinge on these considerations.
>>>
>>> My attitude is to let the elephants in our projects
>>> provide their own feedback directly to the projects
>>> on the legal nitpicks that cause them pain- we do not
>>> need to police these minor issues on their behalf in a
>>> generic way.
>>>
>> I'm not sure I know what an "elephant" is in this context. And
>> I'm not
>> quite sure what issues are considered 'i' and 't'. IMO, it was
>> a good
>> lesson for our podling to see that we can get delayed by not getting the
>> LICENSE and NOTICE and other files right, so we had proper expectations set
>> for when we became a TLP. And IMO, because IANAL and nobody else in the
>> podling is either, it was good to have other sets of eyes on the reviews.
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Expressing priorities about release reviews
Posted by Joe Schaefer <jo...@yahoo.com>.
Trust me, nobody here has any legal training either.
We're just more familiar with policy, not so much the
rationale behind it. And no I'm not saying this
kind of review is worthless, I'm just trying to
adjust priorities to better match reality- we can
provide this "legal" feedback in other ways than simply
voting against a release, and that's what I'm
pointing out here.
----- Original Message -----
> From: Alex Harui <ah...@adobe.com>
> To: Joe Schaefer <jo...@yahoo.com>; "general@incubator.apache.org" <ge...@incubator.apache.org>
> Cc:
> Sent: Monday, January 14, 2013 12:46 PM
> Subject: Re: [DISCUSS] Expressing priorities about release reviews
>
>
>
>
> On 1/14/13 9:20 AM, "Joe Schaefer" <jo...@yahoo.com>
> wrote:
>
>> The thing is Alex, all of this effort
>> to dot our i's and cross our t's on the legal
>> issues really is only for the benefit
>> of major corporations who want to incorporate
>> our work into some corporate-branded application.
>> Actual end users of our software do not benefit
>> one iota from the type of nitpicking we do on
>> general@incubator, nor does the org's reputation
>> for clean IP hinge on these considerations.
>>
>> My attitude is to let the elephants in our projects
>> provide their own feedback directly to the projects
>> on the legal nitpicks that cause them pain- we do not
>> need to police these minor issues on their behalf in a
>> generic way.
>>
> I'm not sure I know what an "elephant" is in this context. And
> I'm not
> quite sure what issues are considered 'i' and 't'. IMO, it was
> a good
> lesson for our podling to see that we can get delayed by not getting the
> LICENSE and NOTICE and other files right, so we had proper expectations set
> for when we became a TLP. And IMO, because IANAL and nobody else in the
> podling is either, it was good to have other sets of eyes on the reviews.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Expressing priorities about release reviews
Posted by Ted Dunning <te...@gmail.com>.
Frankly, having skeletons in the closet that a company like SCO could
exploit to try to kill an open source project like Linux *is* a big deal to
end users. They may not know about it until it bites them, but if and when
it does they will for darn sure care.
It isn't that big a deal to get this right.
On Mon, Jan 14, 2013 at 9:20 AM, Joe Schaefer <jo...@yahoo.com>wrote:
> The thing is Alex, all of this effort
> to dot our i's and cross our t's on the legal
> issues really is only for the benefit
> of major corporations who want to incorporate
> our work into some corporate-branded application.
> Actual end users of our software do not benefit
> one iota from the type of nitpicking we do on
> general@incubator, nor does the org's reputation
> for clean IP hinge on these considerations.
>
> My attitude is to let the elephants in our projects
> provide their own feedback directly to the projects
> on the legal nitpicks that cause them pain- we do not
> need to police these minor issues on their behalf in a
> generic way.
>
>
>
>
>
> >________________________________
> > From: Alex Harui <ah...@adobe.com>
> >To: "general@incubator.apache.org" <ge...@incubator.apache.org>; Joe
> Schaefer <jo...@yahoo.com>
> >Sent: Monday, January 14, 2013 12:15 PM
> >Subject: Re: [DISCUSS] Expressing priorities about release reviews
> >
> >
> >
> >
> >On 1/14/13 7:01 AM, "Chen, Pei" <Pe...@childrens.harvard.edu> wrote:
> >
> >>> Really is it so bad to say to a project with a bug in their license and
> >>> notice info:
> >>> fix this in trunk and show me the revision and I'll go ahead and
> approve your
> >>> release as-is.
> >>> Running through iterations of this is very labor-intensive for the
> project,
> >>> and
> >>> anything we can do to cut down on the pain involved in cutting
> incubator
> >>> releases is IMO worthwhile.
> >>
> >> + 1 for this!
> >> Perhaps it would be nice for the podling to just come up with a list of
> all of
> >> the 3rd party libraries in a Jira and have a group (possibly from
> legal) that
> >> reviews them and helps them officially construct the LICENSE/NOTICE
> files the
> >> first time around (There are usually a lot of grey areas and not an easy
> >> straight reference to an outdated list of approved compatible
> licenses). Most
> >> of the committers are developers and not lawyers- so it would be nice
> to have
> >> developers do what they do best and focus on building awesome code.
> >I don't agree. As a member of a recently graduated podling, it was
> >impressed on me that the point of incubation was to not only figure out
> the
> >Apache Way of meritocracy and voting, but also to get the legal aspects
> >right. IMO, Apache is not GitHub: it is a corporation with bylaws and is
> a
> >legal entity, so we have to get the legal stuff right and it is our
> >responsibility as developers to learn enough about the legal stuff to get
> it
> >right. If there is a grey area, err on the side of caution or ask Apache
> >Legal. Yes, it is painful and slows you down, but usually, the same laws
> >also protect you.
> >
> >--
> >Alex Harui
> >Flex SDK Team
> >Adobe Systems, Inc.
> >http://blogs.adobe.com/aharui
> >
> >
> >
> >
>
Re: [DISCUSS] Expressing priorities about release reviews
Posted by Alex Harui <ah...@adobe.com>.
On 1/14/13 9:20 AM, "Joe Schaefer" <jo...@yahoo.com> wrote:
> The thing is Alex, all of this effort
> to dot our i's and cross our t's on the legal
> issues really is only for the benefit
> of major corporations who want to incorporate
> our work into some corporate-branded application.
> Actual end users of our software do not benefit
> one iota from the type of nitpicking we do on
> general@incubator, nor does the org's reputation
> for clean IP hinge on these considerations.
>
> My attitude is to let the elephants in our projects
> provide their own feedback directly to the projects
> on the legal nitpicks that cause them pain- we do not
> need to police these minor issues on their behalf in a
> generic way.
>
I'm not sure I know what an "elephant" is in this context. And I'm not
quite sure what issues are considered 'i' and 't'. IMO, it was a good
lesson for our podling to see that we can get delayed by not getting the
LICENSE and NOTICE and other files right, so we had proper expectations set
for when we became a TLP. And IMO, because IANAL and nobody else in the
podling is either, it was good to have other sets of eyes on the reviews.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Expressing priorities about release reviews
Posted by Joe Schaefer <jo...@yahoo.com>.
The thing is Alex, all of this effort
to dot our i's and cross our t's on the legal
issues really is only for the benefit
of major corporations who want to incorporate
our work into some corporate-branded application.
Actual end users of our software do not benefit
one iota from the type of nitpicking we do on
general@incubator, nor does the org's reputation
for clean IP hinge on these considerations.
My attitude is to let the elephants in our projects
provide their own feedback directly to the projects
on the legal nitpicks that cause them pain- we do not
need to police these minor issues on their behalf in a
generic way.
>________________________________
> From: Alex Harui <ah...@adobe.com>
>To: "general@incubator.apache.org" <ge...@incubator.apache.org>; Joe Schaefer <jo...@yahoo.com>
>Sent: Monday, January 14, 2013 12:15 PM
>Subject: Re: [DISCUSS] Expressing priorities about release reviews
>
>
>
>
>On 1/14/13 7:01 AM, "Chen, Pei" <Pe...@childrens.harvard.edu> wrote:
>
>>> Really is it so bad to say to a project with a bug in their license and
>>> notice info:
>>> fix this in trunk and show me the revision and I'll go ahead and approve your
>>> release as-is.
>>> Running through iterations of this is very labor-intensive for the project,
>>> and
>>> anything we can do to cut down on the pain involved in cutting incubator
>>> releases is IMO worthwhile.
>>
>> + 1 for this!
>> Perhaps it would be nice for the podling to just come up with a list of all of
>> the 3rd party libraries in a Jira and have a group (possibly from legal) that
>> reviews them and helps them officially construct the LICENSE/NOTICE files the
>> first time around (There are usually a lot of grey areas and not an easy
>> straight reference to an outdated list of approved compatible licenses). Most
>> of the committers are developers and not lawyers- so it would be nice to have
>> developers do what they do best and focus on building awesome code.
>I don't agree. As a member of a recently graduated podling, it was
>impressed on me that the point of incubation was to not only figure out the
>Apache Way of meritocracy and voting, but also to get the legal aspects
>right. IMO, Apache is not GitHub: it is a corporation with bylaws and is a
>legal entity, so we have to get the legal stuff right and it is our
>responsibility as developers to learn enough about the legal stuff to get it
>right. If there is a grey area, err on the side of caution or ask Apache
>Legal. Yes, it is painful and slows you down, but usually, the same laws
>also protect you.
>
>--
>Alex Harui
>Flex SDK Team
>Adobe Systems, Inc.
>http://blogs.adobe.com/aharui
>
>
>
>
Re: [DISCUSS] Expressing priorities about release reviews
Posted by Alex Harui <ah...@adobe.com>.
On 1/14/13 7:01 AM, "Chen, Pei" <Pe...@childrens.harvard.edu> wrote:
>> Really is it so bad to say to a project with a bug in their license and
>> notice info:
>> fix this in trunk and show me the revision and I'll go ahead and approve your
>> release as-is.
>> Running through iterations of this is very labor-intensive for the project,
>> and
>> anything we can do to cut down on the pain involved in cutting incubator
>> releases is IMO worthwhile.
>
> + 1 for this!
> Perhaps it would be nice for the podling to just come up with a list of all of
> the 3rd party libraries in a Jira and have a group (possibly from legal) that
> reviews them and helps them officially construct the LICENSE/NOTICE files the
> first time around (There are usually a lot of grey areas and not an easy
> straight reference to an outdated list of approved compatible licenses). Most
> of the committers are developers and not lawyers- so it would be nice to have
> developers do what they do best and focus on building awesome code.
I don't agree. As a member of a recently graduated podling, it was
impressed on me that the point of incubation was to not only figure out the
Apache Way of meritocracy and voting, but also to get the legal aspects
right. IMO, Apache is not GitHub: it is a corporation with bylaws and is a
legal entity, so we have to get the legal stuff right and it is our
responsibility as developers to learn enough about the legal stuff to get it
right. If there is a grey area, err on the side of caution or ask Apache
Legal. Yes, it is painful and slows you down, but usually, the same laws
also protect you.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [DISCUSS] Expressing priorities about release reviews
Posted by "Chen, Pei" <Pe...@childrens.harvard.edu>.
> Really is it so bad to say to a project with a bug in their license and notice info:
> fix this in trunk and show me the revision and I'll go ahead and approve your
> release as-is.
> Running through iterations of this is very labor-intensive for the project, and
> anything we can do to cut down on the pain involved in cutting incubator
> releases is IMO worthwhile.
+ 1 for this!
Perhaps it would be nice for the podling to just come up with a list of all of the 3rd party libraries in a Jira and have a group (possibly from legal) that reviews them and helps them officially construct the LICENSE/NOTICE files the first time around (There are usually a lot of grey areas and not an easy straight reference to an outdated list of approved compatible licenses). Most of the committers are developers and not lawyers- so it would be nice to have developers do what they do best and focus on building awesome code.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Expressing priorities about release reviews
Posted by Joe Schaefer <jo...@yahoo.com>.
Yes you make a good point- that any effort
towards review is welcome and appreciated.
It's just that having an exclusive focus
on the things we can actually review here,
namely adherence to License and Notice policy,
can leave people with the mistaken impression
that that's all that a PMC should concern itself
with. All of that daily effort that goes into
validating commits on a project really should
garner more appreciation from the PMC, if we
could just find a way to be more trusting about
who we let issue binding votes on behalf of
the org.
Really is it so bad to say to a project with
a bug in their license and notice info: fix
this in trunk and show me the revision and
I'll go ahead and approve your release as-is.
Running through iterations of this is very
labor-intensive for the project, and anything
we can do to cut down on the pain involved
in cutting incubator releases is IMO worthwhile.
>________________________________
> From: Sergio Fernández <se...@salzburgresearch.at>
>To: general@incubator.apache.org
>Cc: Joe Schaefer <jo...@yahoo.com>
>Sent: Saturday, January 12, 2013 2:22 PM
>Subject: Re: [DISCUSS] Expressing priorities about release reviews
>
>Joe,
>
>personally I appreciate such policies checking from the IPMC members. The technical quality of a release is responsibility of the project itself, which could be hard to be evaluated by people working on other topics. Therefore, all additional checkpoints are useful and grateful.
>
>Cheers,
>
>
>On 12/01/13 18:07, Joe Schaefer wrote:
>> One of my long time pet peeves with how we
>> PMC members participate in vetting releases
>> is our penchant for focusing too much on the
>> policies surrounding license and notice info.
>> I really think our exclusive focus on things
>> that really don't pose any organizational risk
>> to either the org nor the project participants
>> serves us well in our other, often unexpressed
>> but far more relevant, goals about encouraging
>> committers to participate in active review of
>> their project's commit activity.
>>
>> Just think about this for a second, what's more
>> likely for people to start suing us over, some
>> bug in the NOTICE file or an undetected backdoor
>> in one of our programs? I am personally far more
>> concerned about the current state of the actual
>> review going on in our podlings than I am about
>> NOTICE minutia.
>>
>> Maybe we should compile some list of which committers
>> are actually subscribed to their project's commit lists?
>> It's crude but it may be useful data to look at to
>> a first order.
>>
>
>-- Sergio Fernández
>Salzburg Research
>+43 662 2288 318
>Jakob-Haringer Strasse 5/II
>A-5020 Salzburg (Austria)
>http://www.salzburgresearch.at
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
>
Re: [DISCUSS] Expressing priorities about release reviews
Posted by Sergio Fernández <se...@salzburgresearch.at>.
Joe,
personally I appreciate such policies checking from the IPMC members.
The technical quality of a release is responsibility of the project
itself, which could be hard to be evaluated by people working on other
topics. Therefore, all additional checkpoints are useful and grateful.
Cheers,
On 12/01/13 18:07, Joe Schaefer wrote:
> One of my long time pet peeves with how we
> PMC members participate in vetting releases
> is our penchant for focusing too much on the
> policies surrounding license and notice info.
> I really think our exclusive focus on things
> that really don't pose any organizational risk
> to either the org nor the project participants
> serves us well in our other, often unexpressed
> but far more relevant, goals about encouraging
> committers to participate in active review of
> their project's commit activity.
>
> Just think about this for a second, what's more
> likely for people to start suing us over, some
> bug in the NOTICE file or an undetected backdoor
> in one of our programs? I am personally far more
> concerned about the current state of the actual
> review going on in our podlings than I am about
> NOTICE minutia.
>
> Maybe we should compile some list of which committers
> are actually subscribed to their project's commit lists?
> It's crude but it may be useful data to look at to
> a first order.
>
--
Sergio Fernández
Salzburg Research
+43 662 2288 318
Jakob-Haringer Strasse 5/II
A-5020 Salzburg (Austria)
http://www.salzburgresearch.at
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Expressing priorities about release reviews
Posted by Joe Schaefer <jo...@yahoo.com>.
If we ran infra the way this PMC
manages its own constituency, we
wouldn't have a single volunteer
willing to work constructively
with us. Sometimes it's better
to let go of control and let people
work to impress you with the karma
you have given them.
>________________________________
> From: "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>
>To: "general@incubator.apache.org" <ge...@incubator.apache.org>; Joe Schaefer <jo...@yahoo.com>
>Sent: Saturday, January 12, 2013 12:44 PM
>Subject: Re: [DISCUSS] Expressing priorities about release reviews
>
>Totally agree, Joe.
>
>Cheers,
>Chris
>
>On 1/12/13 9:37 AM, "Joe Schaefer" <jo...@yahoo.com> wrote:
>
>>The thing is, as far as risk management
>>goes, the vetting we do on general@incubator
>>is largely ceremonial. The real responsible
>>review work is done by people who are reviewing
>>commit activity, and it is a shame we don't
>>do a better job of empowering these conscientious
>>reviewers with a binding vote on a release.
>>
>>
>>
>>
>>
>>>________________________________
>>> From: "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>
>>>To: "general@incubator.apache.org" <ge...@incubator.apache.org>; Joe
>>>Schaefer <jo...@yahoo.com>
>>>Sent: Saturday, January 12, 2013 12:30 PM
>>>Subject: Re: [DISCUSS] Expressing priorities about release reviews
>>>
>>>I agree with you on this Joe. A lot of times my metric is more
>>>responsiveness and participation than in legal/language intricacies. More
>>>power to folks who are good at that, it's just not me.
>>>
>>>Cheers,
>>>Chris
>>>
>>>On 1/12/13 9:07 AM, "Joe Schaefer" <jo...@yahoo.com> wrote:
>>>
>>>>One of my long time pet peeves with how we
>>>>PMC members participate in vetting releases
>>>>is our penchant for focusing too much on the
>>>>policies surrounding license and notice info.
>>>>I really think our exclusive focus on things
>>>>that really don't pose any organizational risk
>>>>to either the org nor the project participants
>>>>serves us well in our other, often unexpressed
>>>>but far more relevant, goals about encouraging
>>>>committers to participate in active review of
>>>>their project's commit activity.
>>>>
>>>>Just think about this for a second, what's more
>>>>likely for people to start suing us over, some
>>>>bug in the NOTICE file or an undetected backdoor
>>>>in one of our programs? I am personally far more
>>>>concerned about the current state of the actual
>>>>review going on in our podlings than I am about
>>>>NOTICE minutia.
>>>>
>>>>Maybe we should compile some list of which committers
>>>>are actually subscribed to their project's commit lists?
>>>>It's crude but it may be useful data to look at to
>>>>a first order.
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
>
Re: [DISCUSS] Expressing priorities about release reviews
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Totally agree, Joe.
Cheers,
Chris
On 1/12/13 9:37 AM, "Joe Schaefer" <jo...@yahoo.com> wrote:
>The thing is, as far as risk management
>goes, the vetting we do on general@incubator
>is largely ceremonial. The real responsible
>review work is done by people who are reviewing
>commit activity, and it is a shame we don't
>do a better job of empowering these conscientious
>reviewers with a binding vote on a release.
>
>
>
>
>
>>________________________________
>> From: "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>
>>To: "general@incubator.apache.org" <ge...@incubator.apache.org>; Joe
>>Schaefer <jo...@yahoo.com>
>>Sent: Saturday, January 12, 2013 12:30 PM
>>Subject: Re: [DISCUSS] Expressing priorities about release reviews
>>
>>I agree with you on this Joe. A lot of times my metric is more
>>responsiveness and participation than in legal/language intricacies. More
>>power to folks who are good at that, it's just not me.
>>
>>Cheers,
>>Chris
>>
>>On 1/12/13 9:07 AM, "Joe Schaefer" <jo...@yahoo.com> wrote:
>>
>>>One of my long time pet peeves with how we
>>>PMC members participate in vetting releases
>>>is our penchant for focusing too much on the
>>>policies surrounding license and notice info.
>>>I really think our exclusive focus on things
>>>that really don't pose any organizational risk
>>>to either the org nor the project participants
>>>serves us well in our other, often unexpressed
>>>but far more relevant, goals about encouraging
>>>committers to participate in active review of
>>>their project's commit activity.
>>>
>>>Just think about this for a second, what's more
>>>likely for people to start suing us over, some
>>>bug in the NOTICE file or an undetected backdoor
>>>in one of our programs? I am personally far more
>>>concerned about the current state of the actual
>>>review going on in our podlings than I am about
>>>NOTICE minutia.
>>>
>>>Maybe we should compile some list of which committers
>>>are actually subscribed to their project's commit lists?
>>>It's crude but it may be useful data to look at to
>>>a first order.
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Expressing priorities about release reviews
Posted by Joe Schaefer <jo...@yahoo.com>.
The thing is, as far as risk management
goes, the vetting we do on general@incubator
is largely ceremonial. The real responsible
review work is done by people who are reviewing
commit activity, and it is a shame we don't
do a better job of empowering these conscientious
reviewers with a binding vote on a release.
>________________________________
> From: "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>
>To: "general@incubator.apache.org" <ge...@incubator.apache.org>; Joe Schaefer <jo...@yahoo.com>
>Sent: Saturday, January 12, 2013 12:30 PM
>Subject: Re: [DISCUSS] Expressing priorities about release reviews
>
>I agree with you on this Joe. A lot of times my metric is more
>responsiveness and participation than in legal/language intricacies. More
>power to folks who are good at that, it's just not me.
>
>Cheers,
>Chris
>
>On 1/12/13 9:07 AM, "Joe Schaefer" <jo...@yahoo.com> wrote:
>
>>One of my long time pet peeves with how we
>>PMC members participate in vetting releases
>>is our penchant for focusing too much on the
>>policies surrounding license and notice info.
>>I really think our exclusive focus on things
>>that really don't pose any organizational risk
>>to either the org nor the project participants
>>serves us well in our other, often unexpressed
>>but far more relevant, goals about encouraging
>>committers to participate in active review of
>>their project's commit activity.
>>
>>Just think about this for a second, what's more
>>likely for people to start suing us over, some
>>bug in the NOTICE file or an undetected backdoor
>>in one of our programs? I am personally far more
>>concerned about the current state of the actual
>>review going on in our podlings than I am about
>>NOTICE minutia.
>>
>>Maybe we should compile some list of which committers
>>are actually subscribed to their project's commit lists?
>>It's crude but it may be useful data to look at to
>>a first order.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
>
Re: [DISCUSS] Expressing priorities about release reviews
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
I agree with you on this Joe. A lot of times my metric is more
responsiveness and participation than in legal/language intricacies. More
power to folks who are good at that, it's just not me.
Cheers,
Chris
On 1/12/13 9:07 AM, "Joe Schaefer" <jo...@yahoo.com> wrote:
>One of my long time pet peeves with how we
>PMC members participate in vetting releases
>is our penchant for focusing too much on the
>policies surrounding license and notice info.
>I really think our exclusive focus on things
>that really don't pose any organizational risk
>to either the org nor the project participants
>serves us well in our other, often unexpressed
>but far more relevant, goals about encouraging
>committers to participate in active review of
>their project's commit activity.
>
>Just think about this for a second, what's more
>likely for people to start suing us over, some
>bug in the NOTICE file or an undetected backdoor
>in one of our programs? I am personally far more
>concerned about the current state of the actual
>review going on in our podlings than I am about
>NOTICE minutia.
>
>Maybe we should compile some list of which committers
>are actually subscribed to their project's commit lists?
>It's crude but it may be useful data to look at to
>a first order.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org