You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Jukka Zitting <ju...@gmail.com> on 2014/05/28 17:32:09 UTC
Continuous release review
Hi,
It looks like my recent tweet [1] is making more waves than I
expected, so I guess I should expand on it here instead of getting
caught up on too many private debates. I hope to avoid conflicting too
much with Marvin and others in the effort to clarify existing release
policy; as he pointed out, this should be considered a separate
discussion.
The reason behind my tweet is a worry about the overall direction of
the discussion that seems to end up treating a release as a
bureaucratic act guarded by high ceremony. For example, breaking down
the review requirements from the recent draft [2], we have:
Before casting +1 binding votes, individuals are REQUIRED to
a) download all signed source code packages onto their own hardware,
b) verify that they meet all requirements of ASF policy on
releases as described below,
c) validate all cryptographic signatures,
d) compile as provided, and
e) test the result on their own platform.
Steps a, c, d and e are all things that would arguably be better and
more reliably done by a CI server. In Jackrabbit we use a release
checker script for these steps (see [3]), and our CI builds already do
steps a, d and e for each individual commit.
Step b is a complex task that, if done properly, would take hours or
days to complete if you don't take previous reviews into account. In
practice it makes more sense to consider only what changed since the
last reviewed release and see whether the policy implications (LICENSE
updates, etc.) of any of the changes have been implemented. Even
better if such policy implications are addressed directly in the same
commit that introduces the relevant chance (we try to do this in
Jackrabbit).
In summary all of the steps (apart from c which in any case is easy to
automate) can and in many ways should be done already for each commit
instead of just during the release vote.
Thus I question the focus we're putting on the release as the point
where all this review is supposed happens. Instead I'd rather see this
becoming more of an ongoing task to be done at the level of each
commit or push, with the release review more just a final confirmation
that such a process has been followed. Something like that would help
relax the somewhat awkward rules we now have on restricting access to
unreleased stuff. If everything we had was always ready for release,
such rules wouldn't be needed and it would be much easier for projects
to release early and often.
This idea has been raised in different forms by others on a few
occasions already earlier, but with all the focus on the existing
release policy and the associated ceremony it seems like many are
missing the point of the argument. I hope this post helps frame the
idea a bit better.
[1] https://twitter.com/jukkaz/status/471304315412705280
[2] https://github.com/rectang/asfrelease/blob/6ad23f6909ccbe71080e4b6c36c5552f863e829f/release.md
[3] https://dist.apache.org/repos/dist/dev/jackrabbit/check-release.sh
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Fwd: Continuous release review
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
Maybe interesting
---------- Forwarded message ----------
From: "Jukka Zitting" <ju...@gmail.com>
Date: 29 May 2014 01:32
Subject: Continuous release review
To: "Legal Discuss" <le...@apache.org>
Cc:
Hi,
It looks like my recent tweet [1] is making more waves than I
expected, so I guess I should expand on it here instead of getting
caught up on too many private debates. I hope to avoid conflicting too
much with Marvin and others in the effort to clarify existing release
policy; as he pointed out, this should be considered a separate
discussion.
The reason behind my tweet is a worry about the overall direction of
the discussion that seems to end up treating a release as a
bureaucratic act guarded by high ceremony. For example, breaking down
the review requirements from the recent draft [2], we have:
Before casting +1 binding votes, individuals are REQUIRED to
a) download all signed source code packages onto their own hardware,
b) verify that they meet all requirements of ASF policy on
releases as described below,
c) validate all cryptographic signatures,
d) compile as provided, and
e) test the result on their own platform.
Steps a, c, d and e are all things that would arguably be better and
more reliably done by a CI server. In Jackrabbit we use a release
checker script for these steps (see [3]), and our CI builds already do
steps a, d and e for each individual commit.
Step b is a complex task that, if done properly, would take hours or
days to complete if you don't take previous reviews into account. In
practice it makes more sense to consider only what changed since the
last reviewed release and see whether the policy implications (LICENSE
updates, etc.) of any of the changes have been implemented. Even
better if such policy implications are addressed directly in the same
commit that introduces the relevant chance (we try to do this in
Jackrabbit).
In summary all of the steps (apart from c which in any case is easy to
automate) can and in many ways should be done already for each commit
instead of just during the release vote.
Thus I question the focus we're putting on the release as the point
where all this review is supposed happens. Instead I'd rather see this
becoming more of an ongoing task to be done at the level of each
commit or push, with the release review more just a final confirmation
that such a process has been followed. Something like that would help
relax the somewhat awkward rules we now have on restricting access to
unreleased stuff. If everything we had was always ready for release,
such rules wouldn't be needed and it would be much easier for projects
to release early and often.
This idea has been raised in different forms by others on a few
occasions already earlier, but with all the focus on the existing
release policy and the associated ceremony it seems like many are
missing the point of the argument. I hope this post helps frame the
idea a bit better.
[1] https://twitter.com/jukkaz/status/471304315412705280
[2]
https://github.com/rectang/asfrelease/blob/6ad23f6909ccbe71080e4b6c36c5552f863e829f/release.md
[3] https://dist.apache.org/repos/dist/dev/jackrabbit/check-release.sh
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Joe Schaefer <jo...@yahoo.com>.
Why are disposable build servers fodder for lawyers to pick over, and if we really want an opinion, shouldn't we actually engage counsel instead of pretending to be practicing attorneys?
On Wednesday, May 28, 2014 2:04 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
>
>
>On Wed, May 28, 2014 at 8:32 AM, Jukka Zitting <ju...@gmail.com> wrote:
>> I hope to avoid conflicting too
>> much with Marvin and others in the effort to clarify existing release
>> policy; as he pointed out, this should be considered a separate
>> discussion.
>
>Should there be any change to the existing policy page before the recast
>policy makes it through the gauntlet, I will happily update the draft as
>appropriate.
>
>In the meantime, I am pleased that the proposal seems to have had the side
>effect of catalyzing support for long-overdue policy reforms around CI.
>If those actually come through, it will have been worth annoying Jukka. ;)
>
>> Before casting +1 binding votes, individuals are REQUIRED to
>> a) download all signed source code packages onto their own hardware,
>> b) verify that they meet all requirements of ASF policy on
>> releases as described below,
>> c) validate all cryptographic signatures,
>> d) compile as provided, and
>> e) test the result on their own platform.
>>
>> Steps a, c, d and e are all things that would arguably be better and
>> more reliably done by a CI server.
>
>As mentioned elsewhere: +1
>
>Personally, I think we should be going further and exploring the legal
>implications of disposable build servers -- do they reduce the liability risk
>of org-sanctioned binaries to an acceptable level?
>
>Marvin Humphrey
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>For additional commands, e-mail: legal-discuss-help@apache.org
>
>
>
>
Re: Continuous release review
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Wed, May 28, 2014 at 8:32 AM, Jukka Zitting <ju...@gmail.com> wrote:
> I hope to avoid conflicting too
> much with Marvin and others in the effort to clarify existing release
> policy; as he pointed out, this should be considered a separate
> discussion.
Should there be any change to the existing policy page before the recast
policy makes it through the gauntlet, I will happily update the draft as
appropriate.
In the meantime, I am pleased that the proposal seems to have had the side
effect of catalyzing support for long-overdue policy reforms around CI.
If those actually come through, it will have been worth annoying Jukka. ;)
> Before casting +1 binding votes, individuals are REQUIRED to
> a) download all signed source code packages onto their own hardware,
> b) verify that they meet all requirements of ASF policy on
> releases as described below,
> c) validate all cryptographic signatures,
> d) compile as provided, and
> e) test the result on their own platform.
>
> Steps a, c, d and e are all things that would arguably be better and
> more reliably done by a CI server.
As mentioned elsewhere: +1
Personally, I think we should be going further and exploring the legal
implications of disposable build servers -- do they reduce the liability risk
of org-sanctioned binaries to an acceptable level?
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Jim Jagielski <ji...@jaguNET.com>.
In general, unless there is lazy consensus, 3 +1 votes
are required for code that makes its way into a releasable
artifact.
There is the normal review of code, then there is the
review of a releasable artifact. They are 2 different
things.
On May 28, 2014, at 12:17 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 5/28/14 8:32 AM, "Jukka Zitting" <ju...@gmail.com> wrote:
>>
>> Thus I question the focus we're putting on the release as the point
>> where all this review is supposed happens. Instead I'd rather see this
>> becoming more of an ongoing task to be done at the level of each
>> commit or push, with the release review more just a final confirmation
>> that such a process has been followed.
> Just wondering, if 3 humans are required to validate the
> headers/LICENSE/NOTICE, does that mean 3 humans are required to review
> each commit/push? That sounds like more energy than focusing a review on
> the actual package, but I guess that's a reasonable option to me. I would
> worry about accumulated error and tendency to get loose with the rules
> having to do all of these reviews for highly active code bases.
>
> I'm all for tooling that tries to summarize and flag interesting changes
> between two tags. An interesting problem is when code is deleted that had
> licensing implications, like replacing a Category B implementation with a
> Category A. But it might be possible.
>
> But yeah, I'm all for automation where we can get it. I'm just not sure
> we can ever fully automate. IIRC, the other place were a human is
> required is in the signing of the release artifacts. That still has to be
> done on that human's computer, right? It can't be done on a CI server?
>
> Thanks,
> -Alex
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, May 28, 2014 at 12:17 PM, Alex Harui <ah...@adobe.com> wrote:
> Just wondering, if 3 humans are required to validate the
> headers/LICENSE/NOTICE, does that mean 3 humans are required to review
> each commit/push?
A general guideline we've been following is that any significant
change that introduces new dependencies or otherwise might have policy
implications should be subjected to review before commit. Such an
approach allows normal code changes to go on without extra overhead.
> IIRC, the other place were a human is required is in the signing of the
> release artifacts.
Yes, generating the release candidate is a different topic, for now
I'm just focusing on the review requirements.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Alex Harui <ah...@adobe.com>.
On 5/28/14 8:32 AM, "Jukka Zitting" <ju...@gmail.com> wrote:
>
>Thus I question the focus we're putting on the release as the point
>where all this review is supposed happens. Instead I'd rather see this
>becoming more of an ongoing task to be done at the level of each
>commit or push, with the release review more just a final confirmation
>that such a process has been followed.
Just wondering, if 3 humans are required to validate the
headers/LICENSE/NOTICE, does that mean 3 humans are required to review
each commit/push? That sounds like more energy than focusing a review on
the actual package, but I guess that's a reasonable option to me. I would
worry about accumulated error and tendency to get loose with the rules
having to do all of these reviews for highly active code bases.
I'm all for tooling that tries to summarize and flag interesting changes
between two tags. An interesting problem is when code is deleted that had
licensing implications, like replacing a Category B implementation with a
Category A. But it might be possible.
But yeah, I'm all for automation where we can get it. I'm just not sure
we can ever fully automate. IIRC, the other place were a human is
required is in the signing of the release artifacts. That still has to be
done on that human's computer, right? It can't be done on a CI server?
Thanks,
-Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by David Jencks <da...@yahoo.com>.
Aren't you distorting what Alex is asking by selective quotation? My understanding of Alex's proposed release process is roughly:
- "release" will involve more than one release candidate, RC1….RCn
- Process from RC1 to acceptable RCn will take >= 72 hours and require 3+ affirmative votes and more + than -
- Each RCi will get at least 24 hour consideration before being accepted as the final release (RCi may be replaced by RCi+1 in less than 24 hours)
- Requests for more time for a particular RCi will be honored
I think you are focusing on item 3 and ignoring item 2. I personally don't have a problem with what Alex is proposing as an option for projects that want to follow this. I'd expect that if there are contributors that object the PMC wouldn't adopt it.
thanks
david jencks
On May 30, 2014, at 10:28 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> On May 30, 2014, at 1:09 PM, Alex Harui <ah...@adobe.com> wrote:
>>
>> The question is, if I get those votes in the first 24 hours, and
>> historically, after key folks who typically vote have voted (usually,
>> 24-48 hours), what value is there to waiting the full 72?
>>
>
> The possibility of a -1... or more than 1 -1...??
>
> The impression that opinions and inputs of people who
> don't work full-time, and paid, on a project, are important
> and valued?
>
> Those are 2 just off the top of my head. Of course,
> if someone doesn't care about the social collaborative
> aspects of Apache projects, then they would not consider
> those reasons as sufficient.
>
> But they would be wrong.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Alex Harui <ah...@adobe.com>.
On 5/30/14 12:03 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>> But under that logic, why not make it 75 hours or 96 hours? I don't
>>think
>> Flex will make it 1 hour or even 8 hours, especially for the first RC.
>
>I'm not sure where you are getting these numbers from , looking at the
>last couple of Apache Flex releases we have (roughly):
>Flex 4.12.1 RC2 votes in 4 hours, 20 hours, 48 hours and 68 hours (all
>+1)
>Flex JS RC3 votes in 43 hours, 48 hours, 70 hours and 72 hours (all +1)
>Flex JX RC4 votes in 43 hours, 48 hours and 72 hours (all +1)
Because the vote at 72 hours is probably from me. I would have voted at
48 hours and 1 minute if it would have gotten the release out sooner.
-Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> But under that logic, why not make it 75 hours or 96 hours? I don't think
> Flex will make it 1 hour or even 8 hours, especially for the first RC.
I'm not sure where you are getting these numbers from , looking at the last couple of Apache Flex releases we have (roughly):
Flex 4.12.1 RC2 votes in 4 hours, 20 hours, 48 hours and 68 hours (all +1)
Flex JS RC3 votes in 43 hours, 48 hours, 70 hours and 72 hours (all +1)
Flex JX RC4 votes in 43 hours, 48 hours and 72 hours (all +1)
Early RCs may get a -1 vote early one, but in that case the release manage has the option of cancelling the vote early if it is a significant issue.
> We have tried to encourage their participation in voting on release candidates but we
> rarely get more than a one or two non-PMC votes even though we do wait the
> 72 hours.
I agree this is an issue, although quite of few of the nonPMC voters have ended up become committers so it is encouraging some community involvement.
The main issues I see is getting more people to take on the roles of being the release manager and making a new releases once issues are found, but that's more resources/time required to fix an issue rather than than not being able to vote on a new release in under 72 hours.
> They don't want to spend the time testing an RC when that RC may not
> be the one that makes it out the door and then have to find more time to
> test the next RC.
A new RC (even one with issues) is going to have a lot more bugs fixed and features than the previous official release. I think we just need to promote the advantages of the new RCs more.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Alex Harui <ah...@adobe.com>.
On 5/30/14 10:28 AM, "Jim Jagielski" <ji...@jaguNET.com> wrote:
>
>On May 30, 2014, at 1:09 PM, Alex Harui <ah...@adobe.com> wrote:
>>
>> The question is, if I get those votes in the first 24 hours, and
>> historically, after key folks who typically vote have voted (usually,
>> 24-48 hours), what value is there to waiting the full 72?
>>
>
>The possibility of a -1... or more than 1 -1...??
But under that logic, why not make it 75 hours or 96 hours? I don't think
Flex will make it 1 hour or even 8 hours, especially for the first RC.
>
>The impression that opinions and inputs of people who
>don't work full-time, and paid, on a project, are important
>and valued?
Actually, Flex cannot get 3 votes without votes from part-time unpaid
volunteers. So at least some of them have had their say, but once they've
spoken, if the probability a bug will be found by waiting another 24 hours
is less than by distributing sooner (because then more folks actually try
the code and start reporting bugs), why aren't we showing we value the
community more by shipping sooner?
>
>Those are 2 just off the top of my head. Of course,
>if someone doesn't care about the social collaborative
>aspects of Apache projects, then they would not consider
>those reasons as sufficient.
>
>But they would be wrong.
Actually, I think I am suggesting that social collaboration is more
important than a 72 hour rule. IOW, that the vote period be determined by
community behavior. If the key voters vote early, we could send out a
"last call" and see if anyone else is even planning to vote. And again,
for late RC's with only minor changes to README/RELEASE_NOTES, if our
community behavior trends indicate relatively few in the community are
interested in going through the approval process for some minor change,
can we count their votes from previous RCs, or can they vote without truly
following every step, and can we close out the vote short of 72 hours?
That said, I am open to the notion that there is some tweak needed to the
Apache Flex community. I believe they are accustomed to the Adobe days
where they were passive sheep being fed Adobe releases. We have tried to
encourage their participation in voting on release candidates but we
rarely get more than a one or two non-PMC votes even though we do wait the
72 hours. But in the 72 hours after we ship an Apache Flex release, we
usually get reports of regressions. I assume it is just because these
folks are busy and counting on the PMC is going to do all of the
heavy-lifting like Adobe did. They want it to be official before trying
it. They don't want to spend the time testing an RC when that RC may not
be the one that makes it out the door and then have to find more time to
test the next RC. Suggestions on how to get more folks involved are
certainly welcome.
Thanks,
-Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Jim Jagielski <ji...@jaguNET.com>.
On May 30, 2014, at 1:09 PM, Alex Harui <ah...@adobe.com> wrote:
>
> The question is, if I get those votes in the first 24 hours, and
> historically, after key folks who typically vote have voted (usually,
> 24-48 hours), what value is there to waiting the full 72?
>
The possibility of a -1... or more than 1 -1...??
The impression that opinions and inputs of people who
don't work full-time, and paid, on a project, are important
and valued?
Those are 2 just off the top of my head. Of course,
if someone doesn't care about the social collaborative
aspects of Apache projects, then they would not consider
those reasons as sufficient.
But they would be wrong.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Alex Harui <ah...@adobe.com>.
On 5/30/14 11:30 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>> Apache Flex (I cannot speak about Cordova since I am not a member of
>>their
>> community) has key PMC members in Europe and our most prolific bug-fixer
>> is actually in Australia.
>
>When this topic has come up before on the Flex dev list some of the
>suggestions were the opposite ie. 72 hours wasn't enough time to review
>the release and not putting the the vote out over a weekend.
And we have waited when folks asked for more time. And for early RCs,
with lots of code changes, I'd go with at least 24 hours to at least let
folks as for more time. Then we know who we're waiting for instead of
watching the clock tick wondering if we'll get any other votes. And I'd
add more time if the vote wraps a weekend or known holidays where key
folks are. But for later RCs, I'm pretty sure a study will show that
Flex gets way more useful info in the 72 hours after we announce the
release than we do waiting the 72 hours to close the vote.
-Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Apache Flex (I cannot speak about Cordova since I am not a member of their
> community) has key PMC members in Europe and our most prolific bug-fixer
> is actually in Australia.
When this topic has come up before on the Flex dev list some of the suggestions were the opposite ie. 72 hours wasn't enough time to review the release and not putting the the vote out over a weekend.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Alex Harui <ah...@adobe.com>.
Hi Martin,
Actually, I think your assumptions about the motivations and goals are
incorrect. Let me re-state the principle and rationale behind the hope
that we do not make 72 hours mandatory.
Apache Flex (I cannot speak about Cordova since I am not a member of their
community) has key PMC members in Europe and our most prolific bug-fixer
is actually in Australia. All are volunteers working in their spare time.
The flagship Flex SDK has enough i18n code in it, that as an RM, I am
always hoping to get at least one vote from someone outside the US.
The question is, if I get those votes in the first 24 hours, and
historically, after key folks who typically vote have voted (usually,
24-48 hours), what value is there to waiting the full 72?
And then, historically, no Flex release ships without more than 1 RC.
Around RC 3 and above, the changes are quite simple. Once, it was to
correct the JIRA id of a bug listed in the Release Notes. After that RC is
posted, do we really need to wait 72 hours? In fact, do we really need 3
votes?
When we reported to board on this issue, it was suggested that we could do
"carryover" voting for RCs with little content change. We have done that,
but current policy does not explicitly allow it.
To summarize, the idea here is "community over time". Once enough votes
indicate that there has been sufficient coverage for the changes contained
in the RC, that should be sufficient. Waiting more time doesn't really
help for most Flex RCs. Getting releases out to the customers helps more.
I can't imagine the main Flex SDK release ever taking less than 72 hours
from first RC to final RC, so someone like you will have time to test at
least one RC, and you can always email with a request for more time and
what we might get out of waiting. As an RM, I would probably wait. But
for the alpha-level next-generation SDK we are working on, we might want
to have a faster cadence. There aren't folks using the new SDK in
production work or promises of backwards compatibility, so getting it out
in less than 72 hours might better serve the community.
So for Marvin's policy document one question is:
Is it really 3 votes per RC or 3 votes accumulated over the set of RCs for
a release?
And related:
If the differences between two RCs is small can some of the build and test
steps be skipped? (Gotta download to at least prove the sigs are ok).
Thanks,
-Alex
On 5/30/14 4:05 AM, "Martijn Dashorst" <ma...@gmail.com> wrote:
>Alex (and several folks from the Cordova community),
>
>I find the constant push for having less than 72 hour wait period to
>be a very excluding, corporate and US centric position.
>
>The world spans 24 hours, contributors (can) come from anywhere. Going
>shorter than 72 hours will prohibit folks from other geographies to
>properly participate in your community: where I count being able to
>properly vote on the culmination of the work that is poured into the
>ASF: i.e. the Release.
>
>I also see it as pure corporate driven: where you are being paid to do
>work on flex (you use your adobe@ address for posting), many folks can
>only contribute outside the 9-5 timeframe and have to do so outside
>the limited hours available to them between tending to their families,
>their health and other activities. Having a smaller timeframe than 72
>hours will severely limit their ability to participate in release
>voting. Or is your proposal to have the ability to function on a PMC
>to be a small, elitist group with corporate backers?
>
>I don't see the 72 hour period to be holding me back: it keeps the
>Community forward looking. It grants folks the opportunity to
>participate, even if they are not yet part of the PMC. If your problem
>is that you have limited participation in checking the release: fix
>that! It might even grow your community. Be inclusive: don't limit the
>ability of your community to participate to your office hours.
>
>Martijn
>
>
>On Wed, May 28, 2014 at 7:16 PM, Alex Harui <ah...@adobe.com> wrote:
>>
>>
>> On 5/28/14 9:56 AM, "Jim Jagielski" <ji...@jaguNET.com> wrote:
>>
>>>Let's look at it this way... We need to recall that the ASF
>>>is a legal entity, a Delaware corporation with 501(c)3
>>>classification. We are also a *significant* player, resource
>>>and source in the IT eco-system.
>>>
>>>People want to play as if we were selling our
>>>kitchen made cookies at a yard sale; we just bake 'em,
>>>sell em, put the money in an old cigar box and
>>>basically just take it all easy and relaxed. Instead,
>>>we are more like Nabisco selling Nutter Butters
>>>(ignore any implication of quality, etc in this
>>>"analogy")... This is serious stuff we are doing,
>>>stuff that people take seriously, stuff that
>>>interests the IRS, the gov't, "partners", etc...
>> I get that there is a difference between potlucks and manufactured food.
>>
>> What I think several of us want to explore is whether the current
>>release
>> policy/process can be automated in places and still be serious about it.
>>
>> For example, I bought some real estate last year, which I consider a
>> serious process, and was pleasantly surprised to see that some of the
>> paperwork could be digitally signed via web apps (but the final closing
>> document required traditional signing). That was quite different that
>> when I last bought real estate merely 5 years ago. Back then, it was
>>all
>> paper and faxing and couriers.
>>
>> And several of us are pushing on this topic because, I'm pretty sure
>>that
>> any bank that still requires all paper and faxing and couriers is
>>finding
>> itself at a competitive disadvantage against the banks that allow
>>digital
>> signing.
>>
>> So the question I have is: where can we use the differences in
>>technology
>> over the past five years to save us time in the release process without
>> sacrificing being "serious". I would offer that at least a couple of
>> things have changed:
>>
>> 1) smartphones make email available to many people virtually 24/7,
>> eliminating some of the reason for waiting 72 hours to close votes
>> 2) CI servers and automated testing frameworks and security software has
>> evolved to the point where you can safely and securely create valid
>> artifacts without human intervention.
>>
>> Thoughts?
>> -Alex
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>
>
>
>--
>Become a Wicket expert, learn from the best: http://wicketinaction.com
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Martijn Dashorst <ma...@gmail.com>.
Alex (and several folks from the Cordova community),
I find the constant push for having less than 72 hour wait period to
be a very excluding, corporate and US centric position.
The world spans 24 hours, contributors (can) come from anywhere. Going
shorter than 72 hours will prohibit folks from other geographies to
properly participate in your community: where I count being able to
properly vote on the culmination of the work that is poured into the
ASF: i.e. the Release.
I also see it as pure corporate driven: where you are being paid to do
work on flex (you use your adobe@ address for posting), many folks can
only contribute outside the 9-5 timeframe and have to do so outside
the limited hours available to them between tending to their families,
their health and other activities. Having a smaller timeframe than 72
hours will severely limit their ability to participate in release
voting. Or is your proposal to have the ability to function on a PMC
to be a small, elitist group with corporate backers?
I don't see the 72 hour period to be holding me back: it keeps the
Community forward looking. It grants folks the opportunity to
participate, even if they are not yet part of the PMC. If your problem
is that you have limited participation in checking the release: fix
that! It might even grow your community. Be inclusive: don't limit the
ability of your community to participate to your office hours.
Martijn
On Wed, May 28, 2014 at 7:16 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 5/28/14 9:56 AM, "Jim Jagielski" <ji...@jaguNET.com> wrote:
>
>>Let's look at it this way... We need to recall that the ASF
>>is a legal entity, a Delaware corporation with 501(c)3
>>classification. We are also a *significant* player, resource
>>and source in the IT eco-system.
>>
>>People want to play as if we were selling our
>>kitchen made cookies at a yard sale; we just bake 'em,
>>sell em, put the money in an old cigar box and
>>basically just take it all easy and relaxed. Instead,
>>we are more like Nabisco selling Nutter Butters
>>(ignore any implication of quality, etc in this
>>"analogy")... This is serious stuff we are doing,
>>stuff that people take seriously, stuff that
>>interests the IRS, the gov't, "partners", etc...
> I get that there is a difference between potlucks and manufactured food.
>
> What I think several of us want to explore is whether the current release
> policy/process can be automated in places and still be serious about it.
>
> For example, I bought some real estate last year, which I consider a
> serious process, and was pleasantly surprised to see that some of the
> paperwork could be digitally signed via web apps (but the final closing
> document required traditional signing). That was quite different that
> when I last bought real estate merely 5 years ago. Back then, it was all
> paper and faxing and couriers.
>
> And several of us are pushing on this topic because, I'm pretty sure that
> any bank that still requires all paper and faxing and couriers is finding
> itself at a competitive disadvantage against the banks that allow digital
> signing.
>
> So the question I have is: where can we use the differences in technology
> over the past five years to save us time in the release process without
> sacrificing being "serious". I would offer that at least a couple of
> things have changed:
>
> 1) smartphones make email available to many people virtually 24/7,
> eliminating some of the reason for waiting 72 hours to close votes
> 2) CI servers and automated testing frameworks and security software has
> evolved to the point where you can safely and securely create valid
> artifacts without human intervention.
>
> Thoughts?
> -Alex
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Rob Vesse <rv...@dotnetrdf.org>.
On 28/05/2014 19:10, "Alex Harui" <ah...@adobe.com> wrote:
>
>3 +1 votes: It is my understanding that we want humans to review the
>license/notice/headers in the artifacts because it is like proof-reading.
>A single person can still miss something and thus 3 reviewers is the
>current tolerance of human error allowed. If that is the true rationale
>for 3 votes, then the next question will be: could any amount of
>automation reduce that need? For example, it is my understanding that
>there are 'plagiarism' servers on the web where students upload papers and
>the their work is scored against whether they copied it from somewhere or
>actually wrote it themselves. If Apache were to create a similar service
>that scoured the web for each commit and help determine its provenance,
>would that reduce the need for 3 human reviewers down to 2 or 1 or 0?
No I personally don't believe it can ever significantly reduce the need
for human reviewers. As I've discussed in the past when this was raised
on the Incubator general list in the context of using Black Duck software
(http://s.apache.org/4GQ) while such tools do exist the suggestion that
they save work is something of a fallacy since the false positive rate of
these tools is frustratingly high.
Usually such tools require users to then go through the matches identified
and individually agree/disagree with each potential incident of plagiarism
and where you disagree and some justification. And of course if you agree
with the match then you have to go take the relevant remedial action to
remove the offending code/update LICENSE & NOTICE etc. If anything such
tools can often generate more work rather than less work.
And of course such tools only flag genuine plagiarism if the code being
examined has corresponding code/code signatures in the database of the
plagiarism checker. So this does not protect us from things like
contributors copying and pasting code from private repositories that they
may have access to in the course of their work but do not have the rights
to contribute.
Automation may help to some extent but I worry that automating too much
gives people a false sense of security about the quality of reviews that
have occurred
Rob
>
>
>-Alex
>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>For additional commands, e-mail: legal-discuss-help@apache.org
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Alex Harui <ah...@adobe.com>.
On 5/28/14 10:24 AM, "Jim Jagielski" <ji...@jaguNET.com> wrote:
>
>On May 28, 2014, at 1:16 PM, Alex Harui <ah...@adobe.com> wrote:
>>
>> What I think several of us want to explore is whether the current
>>release
>> policy/process can be automated in places and still be serious about it.
>>
>
>Sure, and of course I'm sure there are places where
>some stuff can be automated. But it seems to me that
>most people are chaffing against the "3 +1 votes" and
>the "72 hour" rules... We need to recall that creating
>a release != actually releasing the release, as well :)
I'm not sure what you meant by the last statement, but for sure, those
pushing for reduced overhead for releases have questioned every step of
the process, even the 3 +1s. But the answer that that it is current
policy is not going to satisfy folks. We need to try to reduce these
requests down to the fundamental elements, for example:
3 +1 votes: It is my understanding that we want humans to review the
license/notice/headers in the artifacts because it is like proof-reading.
A single person can still miss something and thus 3 reviewers is the
current tolerance of human error allowed. If that is the true rationale
for 3 votes, then the next question will be: could any amount of
automation reduce that need? For example, it is my understanding that
there are 'plagiarism' servers on the web where students upload papers and
the their work is scored against whether they copied it from somewhere or
actually wrote it themselves. If Apache were to create a similar service
that scoured the web for each commit and help determine its provenance,
would that reduce the need for 3 human reviewers down to 2 or 1 or 0?
72 hours: I was pleasantly surprised to see that it is not currently a
requirement. I posted arguments as to why it is better to have some
flexibility in another post, but it comes down to the fact that folks can
get email more often these days, and that each community has different
patterns of behaviors, even for each RC. For Flex, later RCs rarely see
-1 votes in the late hours of a vote so I think we'd find and fix issues
sooner if we could shorten the vote waiting period in certain situations.
Unless there is a legal risk to the foundation, I'm not sure 72 hours
should be a requirement. Trust the PMCs to make sure their quality bar is
otherwise high enough and potential voters do not feel left out.
-Alex
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Stephen Connolly <st...@gmail.com>.
I wonder also if there is a requirement for the "build" in "download, build
and test"... in which case it's just download and test against the legal
requirements for a release...
the build and verify the built software works is mostly a moral
requirement... but being technical and moral folks we seem to favour
focusing on this part
On 29 May 2014 17:02, Stephen Connolly <st...@gmail.com>
wrote:
> My understanding of the "test" in "download, build and test" is test the
> source bundle against the *legal* requirements. I don't think there is any
> legal requirement for us to ship working software... only moral
> requirements ;-)
>
>
> On 29 May 2014 16:48, Alex Harui <ah...@adobe.com> wrote:
>
>> (Trying to reel this thread back into productivity)
>>
>> Apache is supposed to be a meritocracy where issues are discussed on the
>> merits. Short answers of just "No" without justification doesn't help,
>> nor does telling someone they are pounding their head in the sand.
>>
>> Also, can we table the discussion of how we might change these
>> requirements, or at least, fork it to a new thread? I imagine changing
>> these requirements will take a long time, and I am more interested in
>> understanding what we can do under the current rules.
>>
>> So Jim, please explain to me, a new member, what are the "merits" of
>> requiring that PMC members download, build, and test? Is it just
>> statistical probability that some platform or machine-specific issue might
>> get found before release?
>>
>> What does it mean to "test"? Can it be a simple smoke test, or testing of
>> some simple application against the built sources?
>>
>> Can these steps be done automatically and just generate a report for
>> review or is there some value to having to manually execute these steps?
>>
>> Thanks,
>> -Alex
>>
>>
>> On 5/29/14 8:31 AM, "Emmanuel Lécharny" <el...@gmail.com> wrote:
>>
>> >Le 29/05/2014 16:04, Jim Jagielski a écrit :
>> >> FWIW, my response could be:
>> >>
>> >> You can pound your head in the sand, expecting that every release
>> >> does not need to be downladed, compiled, tested by every PMC member
>> >> casting a +1, or simply accept the idea that, yes, an automated and
>> >> potentially buggy CI process is no substitute for a healthy, engaged
>> >> and responsible PMC.
>> >>
>> >> See how I did that?
>> >Sure.
>> >
>> >But I can check a CI script, when I can't be on every PMC's back to
>> >double check that they are doing their homeworks.
>> >
>> >Anticpiating your answer, yes, I know, *if* I do the chekcs myself, I
>> >will be able to know that X Y or Z is not fulfilling his/her duty. And
>> >now what ? Should I tell them to either comply, or stop casting a vote ?
>> >
>> >
>> >---------------------------------------------------------------------
>> >To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> >For additional commands, e-mail: legal-discuss-help@apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
>
Re: Continuous release review
Posted by Stephen Connolly <st...@gmail.com>.
My understanding of the "test" in "download, build and test" is test the
source bundle against the *legal* requirements. I don't think there is any
legal requirement for us to ship working software... only moral
requirements ;-)
On 29 May 2014 16:48, Alex Harui <ah...@adobe.com> wrote:
> (Trying to reel this thread back into productivity)
>
> Apache is supposed to be a meritocracy where issues are discussed on the
> merits. Short answers of just "No" without justification doesn't help,
> nor does telling someone they are pounding their head in the sand.
>
> Also, can we table the discussion of how we might change these
> requirements, or at least, fork it to a new thread? I imagine changing
> these requirements will take a long time, and I am more interested in
> understanding what we can do under the current rules.
>
> So Jim, please explain to me, a new member, what are the "merits" of
> requiring that PMC members download, build, and test? Is it just
> statistical probability that some platform or machine-specific issue might
> get found before release?
>
> What does it mean to "test"? Can it be a simple smoke test, or testing of
> some simple application against the built sources?
>
> Can these steps be done automatically and just generate a report for
> review or is there some value to having to manually execute these steps?
>
> Thanks,
> -Alex
>
>
> On 5/29/14 8:31 AM, "Emmanuel Lécharny" <el...@gmail.com> wrote:
>
> >Le 29/05/2014 16:04, Jim Jagielski a écrit :
> >> FWIW, my response could be:
> >>
> >> You can pound your head in the sand, expecting that every release
> >> does not need to be downladed, compiled, tested by every PMC member
> >> casting a +1, or simply accept the idea that, yes, an automated and
> >> potentially buggy CI process is no substitute for a healthy, engaged
> >> and responsible PMC.
> >>
> >> See how I did that?
> >Sure.
> >
> >But I can check a CI script, when I can't be on every PMC's back to
> >double check that they are doing their homeworks.
> >
> >Anticpiating your answer, yes, I know, *if* I do the chekcs myself, I
> >will be able to know that X Y or Z is not fulfilling his/her duty. And
> >now what ? Should I tell them to either comply, or stop casting a vote ?
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >For additional commands, e-mail: legal-discuss-help@apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: Continuous release review
Posted by Jim Jagielski <ji...@jaguNET.com>.
Here is the underlying issue.
Recall that for Apache, what is of main concern is a healthy
and viable community around a project, which implies a
healthy and viable PMC.
Now early on, what got us first started was when the old
NCSA web server was dropped, cold, when Rob went to work
on Netscape. There was no community (of developers) around
it. So a bootstrapped community came together, with the
promise that no other users (community) would be hit
how we were.
The way to ensure that was to build up a community of personally
invested and engagement people around a project. The development
and the release of a codebase was a *communal* action, and we
wanted to ensure that, since we were all doing this in our
"spare" time, as volunteers, that a project could survive the
inevitable ebb-and-flow of developer free time. So as long
as there were 3 people, engaged in a projects, that seemed
enough. It was the "magic" number to get patches committed
and the number required to "bless" a release.
Taken in this light, it should be obvious that a release is
the primary communal action of the PMC. It is the last stage
before a codebase is released to the public for us; a release
is when the License "kicks in" and it's when the developers,
the ASF and the RM takes on legal liability.
So the merits of requiring at least 3 PMC members to approve
a release are:
1. Ensures that we still have 3 *active* and *engaged* people,
since it takes some level of effort to do so.
2. Makes the release a *personal* action by the PMC.
3. Serves as a final, hands-on "QA" check before something
is released.
4. Emphasizes that a project and codebase is a personal
and communal artifact, which helps ensure that a
community grows and develops around the project.
All within the ASF there is a dual concentration on the
community and the individual thereof. Merit, for example, is
individual and based on a lot of metrics, not just lines-of-
code-written, for example. Our concern over healthy, viable,
self-sustaining communities affect all aspects of our processes.
And our successes "prove" the validity of those processes.
I guess a simpler way of explaining it would be to compare
the differences between mass-produced beer and hand-crafted
micro-brews.
On May 29, 2014, at 11:48 AM, Alex Harui <ah...@adobe.com> wrote:
> (Trying to reel this thread back into productivity)
>
> Apache is supposed to be a meritocracy where issues are discussed on the
> merits. Short answers of just "No" without justification doesn't help,
> nor does telling someone they are pounding their head in the sand.
>
> Also, can we table the discussion of how we might change these
> requirements, or at least, fork it to a new thread? I imagine changing
> these requirements will take a long time, and I am more interested in
> understanding what we can do under the current rules.
>
> So Jim, please explain to me, a new member, what are the "merits" of
> requiring that PMC members download, build, and test? Is it just
> statistical probability that some platform or machine-specific issue might
> get found before release?
>
> What does it mean to "test"? Can it be a simple smoke test, or testing of
> some simple application against the built sources?
>
> Can these steps be done automatically and just generate a report for
> review or is there some value to having to manually execute these steps?
>
> Thanks,
> -Alex
>
>
> On 5/29/14 8:31 AM, "Emmanuel Lécharny" <el...@gmail.com> wrote:
>
>> Le 29/05/2014 16:04, Jim Jagielski a écrit :
>>> FWIW, my response could be:
>>>
>>> You can pound your head in the sand, expecting that every release
>>> does not need to be downladed, compiled, tested by every PMC member
>>> casting a +1, or simply accept the idea that, yes, an automated and
>>> potentially buggy CI process is no substitute for a healthy, engaged
>>> and responsible PMC.
>>>
>>> See how I did that?
>> Sure.
>>
>> But I can check a CI script, when I can't be on every PMC's back to
>> double check that they are doing their homeworks.
>>
>> Anticpiating your answer, yes, I know, *if* I do the chekcs myself, I
>> will be able to know that X Y or Z is not fulfilling his/her duty. And
>> now what ? Should I tell them to either comply, or stop casting a vote ?
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Alex Harui <ah...@adobe.com>.
(Trying to reel this thread back into productivity)
Apache is supposed to be a meritocracy where issues are discussed on the
merits. Short answers of just "No" without justification doesn't help,
nor does telling someone they are pounding their head in the sand.
Also, can we table the discussion of how we might change these
requirements, or at least, fork it to a new thread? I imagine changing
these requirements will take a long time, and I am more interested in
understanding what we can do under the current rules.
So Jim, please explain to me, a new member, what are the "merits" of
requiring that PMC members download, build, and test? Is it just
statistical probability that some platform or machine-specific issue might
get found before release?
What does it mean to "test"? Can it be a simple smoke test, or testing of
some simple application against the built sources?
Can these steps be done automatically and just generate a report for
review or is there some value to having to manually execute these steps?
Thanks,
-Alex
On 5/29/14 8:31 AM, "Emmanuel Lécharny" <el...@gmail.com> wrote:
>Le 29/05/2014 16:04, Jim Jagielski a écrit :
>> FWIW, my response could be:
>>
>> You can pound your head in the sand, expecting that every release
>> does not need to be downladed, compiled, tested by every PMC member
>> casting a +1, or simply accept the idea that, yes, an automated and
>> potentially buggy CI process is no substitute for a healthy, engaged
>> and responsible PMC.
>>
>> See how I did that?
>Sure.
>
>But I can check a CI script, when I can't be on every PMC's back to
>double check that they are doing their homeworks.
>
>Anticpiating your answer, yes, I know, *if* I do the chekcs myself, I
>will be able to know that X Y or Z is not fulfilling his/her duty. And
>now what ? Should I tell them to either comply, or stop casting a vote ?
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 29/05/2014 16:04, Jim Jagielski a écrit :
> FWIW, my response could be:
>
> You can pound your head in the sand, expecting that every release
> does not need to be downladed, compiled, tested by every PMC member
> casting a +1, or simply accept the idea that, yes, an automated and
> potentially buggy CI process is no substitute for a healthy, engaged
> and responsible PMC.
>
> See how I did that?
Sure.
But I can check a CI script, when I can't be on every PMC's back to
double check that they are doing their homeworks.
Anticpiating your answer, yes, I know, *if* I do the chekcs myself, I
will be able to know that X Y or Z is not fulfilling his/her duty. And
now what ? Should I tell them to either comply, or stop casting a vote ?
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 01/06/2014 21:29, Marvin Humphrey a écrit :
> On Fri, May 30, 2014 at 4:40 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>> On May 30, 2014, at 1:51 AM, Marvin Humphrey <ma...@rectangular.com> wrote:
>>> If I set up CI and it runs extended tests for an RC on 10 different platforms
>>> I don't have and I pore over the logs and doublecheck the checksums... I'd
>>> like to think most people would see that as "engaged" and "responsible".
>> Of course... I was simply turning the argument around as it were.
> But apparently such a vote is unacceptable to you nonetheless,
We can still start a vote. Jim has one vote, and he may cast a -1. This
is how a democracy works, isn't it ?
Now, there are many ways that a vote can be invalidated, for instance if
it break the bylaws.
But IMHO, we are far from a vote, just because the best possible action
at this point is to build consensus...
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Jim Jagielski <ji...@jaguNET.com>.
I've never said what criteria is required for someone
to vote a +1.
On Jun 1, 2014, at 3:29 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
> On Fri, May 30, 2014 at 4:40 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>> On May 30, 2014, at 1:51 AM, Marvin Humphrey <ma...@rectangular.com> wrote:
>
>>> If I set up CI and it runs extended tests for an RC on 10 different platforms
>>> I don't have and I pore over the logs and doublecheck the checksums... I'd
>>> like to think most people would see that as "engaged" and "responsible".
>>
>> Of course... I was simply turning the argument around as it were.
>
> But apparently such a vote is unacceptable to you nonetheless, because the
> requirement to build and test each RC manually is sacrosanct -- no matter how
> effectively the social aspect is satisfied through other means.
>
> I think that's unreasonable. I have other priorities now, but at some point
> in the future, I'll submit a patch.
>
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Fri, May 30, 2014 at 4:40 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> On May 30, 2014, at 1:51 AM, Marvin Humphrey <ma...@rectangular.com> wrote:
>> If I set up CI and it runs extended tests for an RC on 10 different platforms
>> I don't have and I pore over the logs and doublecheck the checksums... I'd
>> like to think most people would see that as "engaged" and "responsible".
>
> Of course... I was simply turning the argument around as it were.
But apparently such a vote is unacceptable to you nonetheless, because the
requirement to build and test each RC manually is sacrosanct -- no matter how
effectively the social aspect is satisfied through other means.
I think that's unreasonable. I have other priorities now, but at some point
in the future, I'll submit a patch.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Jim Jagielski <ji...@jaguNET.com>.
On May 30, 2014, at 1:51 AM, Marvin Humphrey <ma...@rectangular.com> wrote:
> On Thu, May 29, 2014 at 7:04 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>> FWIW, my response could be:
>>
>> You can pound your head in the sand, expecting that every release
>> does not need to be downladed, compiled, tested by every PMC member
>> casting a +1, or simply accept the idea that, yes, an automated and
>> potentially buggy CI process is no substitute for a healthy, engaged
>> and responsible PMC.
>
> If I set up CI and it runs extended tests for an RC on 10 different platforms
> I don't have and I pore over the logs and doublecheck the checksums... I'd
> like to think most people would see that as "engaged" and "responsible".
>
Of course... I was simply turning the argument around as it were.
> Even if a CI rig happens to be buggy, the potential failure modes are
> perfectly manageable in the context of releasing.
>
> I'd still download every source package and diff the expanded content against
> an export from version control for security and other reasons. But as far as
> building and testing release candidates, CI gets the job done better with less
> effort -- freeing up time for the community to focus on other tasks.
>
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Thu, May 29, 2014 at 7:04 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> FWIW, my response could be:
>
> You can pound your head in the sand, expecting that every release
> does not need to be downladed, compiled, tested by every PMC member
> casting a +1, or simply accept the idea that, yes, an automated and
> potentially buggy CI process is no substitute for a healthy, engaged
> and responsible PMC.
If I set up CI and it runs extended tests for an RC on 10 different platforms
I don't have and I pore over the logs and doublecheck the checksums... I'd
like to think most people would see that as "engaged" and "responsible".
Even if a CI rig happens to be buggy, the potential failure modes are
perfectly manageable in the context of releasing.
I'd still download every source package and diff the expanded content against
an export from version control for security and other reasons. But as far as
building and testing release candidates, CI gets the job done better with less
effort -- freeing up time for the community to focus on other tasks.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Jim Jagielski <ji...@jaguNET.com>.
FWIW, my response could be:
You can pound your head in the sand, expecting that every release
does not need to be downladed, compiled, tested by every PMC member
casting a +1, or simply accept the idea that, yes, an automated and
potentially buggy CI process is no substitute for a healthy, engaged
and responsible PMC.
See how I did that?
On May 29, 2014, at 9:43 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
> Le 29/05/2014 13:50, Jim Jagielski a écrit :
>> On May 28, 2014, at 2:41 PM, Jukka Zitting <ju...@gmail.com> wrote:
>>
>>> For example, do we really need for everyone to download, compile and
>>> test the code before casting a +1, when a CI server can do this just
>>> as well if not better.
>> Yes. Yes we do.
>
> Jim, you can pound your head in the sand, expecting that every release
> *is* downladed, compiled, tested by every PMC member casting a +1, or
> acccept the idea that, yes, a well designed and validated CI build could
> be a valid substitute for a human error prone/lazzy prone process (ie,
> I'm 100% sure that most of the voters aren't following this process)
> (and I'm quite sure that this is one of the reason we are using
> computers, all in all).
>
> Or you can *think* about what you are saying, and realize that it's
> plain pseudo-legal nonsense.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Chip Childers <ch...@apache.org>.
On Fri, May 30, 2014 at 02:52:49PM +0100, Stephen Connolly wrote:
> Well I have not seen anyone address my specific point with regard to
> separating the concerns w.r.t. voting.
>
> We vote on releases for legal and social reasons.
+1
>
> The legal reasons mandate that we need to download the archive and verify
> that it is something we can legally ship. There are a set of criteria with
> regards to shipping. Some of these criteria are things like:
>
> * Does it include the LICENSE an NOTICE files
> * All the source code of the project must be covered by the Apache License,
> version 2.0.
> * The license must be included in each source file.
> * Has the code been contributed by an individual covered by an appropriate
> contributor license agreement, or have otherwise been licensed to the
> Foundation and passed through IP clearance.
> * Are bundled 3rd party dependencies compatible with the Apache License,
> version 2.0.
I agree that, IMO, the items above are the areas best indicated as MUST
in any policy.
>
> The social reasons pressure us to download the archive and check that it
> builds and check that any included tests pass and check some relevant smoke
> tests.
>
Also agreed, and I believe this is where the 72 hours (as a SHOULD)
comes into play.
> From my PoV - as a PMC chair [1] - the legal requirements are what matter
> to most to me, as I am responsible for compliance with the legal
> requirements...
>
> The social requirements are something that can and should be easily
> replaced by a CI system.
That depends on the project actually, but I'd agree that it shouldn't be
mandated in foundation-wide policy (outside of the minimum required to
describe best practices that learn from the past history of community
building).
>
> The final question is then how thorough do we have to be in
>
> [1]: http://www.apache.org/dev/release-publishing.html says
> The PMC in general, and the PMC chair in particular (as an officer of
> the Foundation) is responsible for compliance with requirements.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Chip Childers <ch...@apache.org>.
On Fri, May 30, 2014 at 03:22:04PM +0100, Stephen Connolly wrote:
> Hey I'm not saying that we can cut out the social bits at all. I am just
> saying that we need to consider them separately.
>
> There is the legal stuff which covers our ass and - while annoying - is
> acceptable to remain as some minimal manual steps.
>
> There is the social stuff which prevents our blushes. For complex projects
> this type of thing may need more than 72 hours worth of testing. For
> example it can be hard to get the full confidence in a Maven release in
> just 72 hours of testing... despite having a good suite of integration
> tests... For more complex projects, e.g. Cassandra, the testing
> requirements are much more.
>
> I don't think we can remove the social stuff... but we can make it a lot
> less mundane. Having a CI system do a large chunk of the work is a good way
> to do this... Then again I always argue that you need to retain at least
> one manual test to try and stop the "well the selenium tests still found
> the bits of the UI they were looking for because they were on the page...
> just down at the bottom underneath the big ugly stack trace" kinds of bugs
> from slipping into the released product.
+1 to these thoughts Stephen. CloudStack, as an example, uses CI quite
a bit... but as *ALSO* have a very active push for everyone to test the
release candidate in their local environments. For some, this is just a
local VM where the software simulates managed hardware. For others, this
is a full lab environment with 500+ servers and other hardware devices.
The social part is key here... the call for votes is something that
should be loudly promoted as a chance for the community to rally around
the testing process... and the engagement that ensues is one of the
most powerful tools we have to get new people engaged (especially in
transitioning a user to a tester, if they aren't a coder).
-chip
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Stephen Connolly <st...@gmail.com>.
Hey I'm not saying that we can cut out the social bits at all. I am just
saying that we need to consider them separately.
There is the legal stuff which covers our ass and - while annoying - is
acceptable to remain as some minimal manual steps.
There is the social stuff which prevents our blushes. For complex projects
this type of thing may need more than 72 hours worth of testing. For
example it can be hard to get the full confidence in a Maven release in
just 72 hours of testing... despite having a good suite of integration
tests... For more complex projects, e.g. Cassandra, the testing
requirements are much more.
I don't think we can remove the social stuff... but we can make it a lot
less mundane. Having a CI system do a large chunk of the work is a good way
to do this... Then again I always argue that you need to retain at least
one manual test to try and stop the "well the selenium tests still found
the bits of the UI they were looking for because they were on the page...
just down at the bottom underneath the big ugly stack trace" kinds of bugs
from slipping into the released product.
On 30 May 2014 15:05, Jim Jagielski <ji...@jagunet.com> wrote:
>
> On May 30, 2014, at 9:52 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> >
> > The social requirements are something that can and should be easily
> replaced by a CI system.
> >
>
> I disagree... the social requirements, because they are *social*
> must remain, well.... social. I'm not sure how to
> make that any clearer, but moving towards a process
> which *removes* or *diminishes* the act of people
> personally taking initiative and verifying, for themselves,
> that the release is valid according to their criteria,
> doesn't emphasize the social requirements at all; it
> instead reinforces the mindset that people aren't required
> or necessary to the process at all.
>
> And that ain't the ASF.
>
>
Re: Continuous release review
Posted by Jim Jagielski <ji...@jaguNET.com>.
On May 30, 2014, at 9:52 AM, Stephen Connolly <st...@gmail.com> wrote:
>
> The social requirements are something that can and should be easily replaced by a CI system.
>
I disagree... the social requirements, because they are *social*
must remain, well.... social. I'm not sure how to
make that any clearer, but moving towards a process
which *removes* or *diminishes* the act of people
personally taking initiative and verifying, for themselves,
that the release is valid according to their criteria,
doesn't emphasize the social requirements at all; it
instead reinforces the mindset that people aren't required
or necessary to the process at all.
And that ain't the ASF.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Jim Jagielski <ji...@jaguNET.com>.
On May 30, 2014, at 9:52 AM, Stephen Connolly <st...@gmail.com> wrote:
>
> The social reasons pressure us to download the archive and check that it builds and check that any included tests pass and check some relevant smoke tests.
>
> From my PoV - as a PMC chair [1] - the legal requirements are what matter to most to me, as I am responsible for compliance with the legal requirements...
>
> The social requirements are something that can and should be easily replaced by a CI system.
>
Although I agree w/ the statement regarding the legal aspects,
the PMC itself must be responsible for the social aspects
(dare I say "requirements") of how the project is being run.
And if the PMC chair sees the PMC operating in an
way, socially, which is against the patterns which encompass
how Apache projects should be run, it is his/her responsibility
to steer the PMC back to the "right way".
And if the PMC chair is unable to do so, then he/she are
encouraged to contact the board and let them take care of
it.
Recall: The legal requirements are so we don't get sued, or, if
we do, we don't lose. The social requirements are so the
project and community grows, thrives and survives. Both
are important. And agreeing to be a PMC members means that
one understands these responsibilities and agrees to abide
by them. It's not just a badge that one can put on their CV.
If that's all PMC membership (or even ASF membership) means
to someone, I suggest they reconsider accepting such
membership.
And no, I'm not suggesting that this applies to anyone
active on this thread: I'm just making the statement for
clarity and completeness.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Stephen Connolly <st...@gmail.com>.
On Sunday, 1 June 2014, Emmanuel Lécharny <el...@gmail.com> wrote:
> Le 31/05/2014 14:33, James Carman a écrit :
> > On Fri, May 30, 2014 at 8:33 PM, Emmanuel Lécharny <elecharny@gmail.com
> <javascript:;>> wrote:
> >> " And since the officer is acting on behalf of the corporation, there is
> >> no personal liability".
> >>
> > Liability != responsibility
>
> Hopefully !
>
> In the context of Stephen's mail, I just wanted to stress out that being
> a chairman does not bring any legal pressure on your shoulder.
>
> You are just resposible for a few more things, which are clearly
> explicited on http://www.apache.org/dev/pmc.html#chair. Nothing to be
> afraid of, IMHO.
Sadly that page omits to mention this bit from
http://www.apache.org/dev/release-publishing.html says
The PMC in general, and the PMC chair in particular (as an officer of
the Foundation) is responsible for compliance with requirements.
>
I agree that it shouldn't be too scary, but we chairs are particularly
responsible for compliance with requirements... So the chair has to be
*that* person... You know, the one who reminds people of the rules and that
they must be followed and shit!
It also means that when we chairs are casting our votes we should be
providing an example of sticking to the rules... Rather than just following
the chorus and voting along with half the PMC just because everyone else
+1'd the release.
I read that as saying: if you are PMC chair, you should only vote +1 if you
are happy with the release from a follows the rules PoV
Where I get worried is our wooly requirements on code provenance... Can I
say "oh well all these files were in ASF SCM so they can only have got
there if committed by a committer... All committers have an ICLA... Thus my
provenance checking is done once I do a diff against the SCM tag"? Is that
the extent of the checks on code provenance that are required *for a
release*?
Should I be spot checking some files at random?
Should I be reviewing the entire history?
This is the crux. As a chair I am "particularly" responsible... If I cannot
resolve how responsible I should be wrt code provenance, can I in good
faith cast +1 vote for any release at all?
Now if being "particularly responsible" just means I have to remind people
of the rules and pull people up if they are not following them... Well
that's ok.
But the text is unclear... It could mean that the chair is the last bastion
of hope for a valid release... If that is the case then I have been lax
because I have only mostly been keeping track of commits to Maven (when I
have more than a few 100's of unread emails they can end up in the bin) and
I have not verified our code provenance all the way to the initial
commit... Instead I have assumed that our PMC has done the required checks
before I was invited... I suspect I am in the majority of PMC chairs in
this regard...
I know that - hyperbole as a techinque to spur debate aside - it would
makes more comfortable if we had clearer guidance in this regard... Absence
such clearer guidance I look forward to rotating the PMC chair on! (Though
that doesn't mean I won't seek the position when the next chair rotates it
on next time)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> <javascript:;>
> For additional commands, e-mail: legal-discuss-help@apache.org
> <javascript:;>
>
>
--
Sent from my phone
Re: Continuous release review
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 31/05/2014 14:33, James Carman a écrit :
> On Fri, May 30, 2014 at 8:33 PM, Emmanuel Lécharny <el...@gmail.com> wrote:
>> " And since the officer is acting on behalf of the corporation, there is
>> no personal liability".
>>
> Liability != responsibility
Hopefully !
In the context of Stephen's mail, I just wanted to stress out that being
a chairman does not bring any legal pressure on your shoulder.
You are just resposible for a few more things, which are clearly
explicited on http://www.apache.org/dev/pmc.html#chair. Nothing to be
afraid of, IMHO.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by James Carman <ja...@carmanconsulting.com>.
On Fri, May 30, 2014 at 8:33 PM, Emmanuel Lécharny <el...@gmail.com> wrote:
>
> " And since the officer is acting on behalf of the corporation, there is
> no personal liability".
>
Liability != responsibility
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 31/05/2014 00:51, Stephen Connolly a écrit :
> On Friday, 30 May 2014, Emmanuel Lécharny <el...@gmail.com> wrote:
>
>> Le 31/05/2014 00:19, Stephen Connolly a écrit :
>>
>>> When I ponder what the PMC chair's extra responsibilities are w.r.t.
>>> ensuring that releases comply with legal requirements this problem is the
>>> one that has me look forward to rotating the Maven chair in a couple of
>>> months ;-)
>> Except that it's not the PMC's chair responsability. It's every single
>> PMC member's responsability. Unless you decide to quit a PMC, you have
>> the responsability to ensure that releases compy with the legal
>> requirements...
>>
>>
> Read it up... The PMC chair - as an officer of the foundation - is
> especially charged with this responsibility...
I disagree.
http://www.apache.org/foundation/faq.html#why-are-PMC-chairs-officers
" And since the officer is acting on behalf of the corporation, there is
no personal liability".
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Stephen Connolly <st...@gmail.com>.
On Friday, 30 May 2014, Emmanuel Lécharny <el...@gmail.com> wrote:
> Le 31/05/2014 00:19, Stephen Connolly a écrit :
>
> > When I ponder what the PMC chair's extra responsibilities are w.r.t.
> > ensuring that releases comply with legal requirements this problem is the
> > one that has me look forward to rotating the Maven chair in a couple of
> > months ;-)
>
> Except that it's not the PMC's chair responsability. It's every single
> PMC member's responsability. Unless you decide to quit a PMC, you have
> the responsability to ensure that releases compy with the legal
> requirements...
>
>
Read it up... The PMC chair - as an officer of the foundation - is
especially charged with this responsibility... At least that's what it says
on the apache website (in a locked filing cabinet, in the basement, down
the broken flight of stairs, with the lights not working, behind the door
bearing the sign "beware if tiger")
I know the PMC is responsible as a whole... The chair is even more
responsible
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> <javascript:;>
> For additional commands, e-mail: legal-discuss-help@apache.org
> <javascript:;>
>
>
--
Sent from my phone
Re: Continuous release review
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 31/05/2014 00:19, Stephen Connolly a écrit :
> When I ponder what the PMC chair's extra responsibilities are w.r.t.
> ensuring that releases comply with legal requirements this problem is the
> one that has me look forward to rotating the Maven chair in a couple of
> months ;-)
Except that it's not the PMC's chair responsability. It's every single
PMC member's responsability. Unless you decide to quit a PMC, you have
the responsability to ensure that releases compy with the legal
requirements...
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Stephen Connolly <st...@gmail.com>.
We (maven) are slowly turning the RAT screws after identifying some legacy
issues (which we report tracking metrics on to the board for anyone who's
not aware)
On maven core we have RAT well automated. For core releases I know I check
that the RAT config has not changed since previous release or check the
delta. Since we turned it on, we have found it quite useful... But then we
use CI to ensure that everything is awesome (everything is cool when you're
part of the team) after each commit and core is mostly a smaller number if
committers.
I was not suggesting that using RAT removes the necessity to keep on top of
the commits going into the code base... I am suggesting that if the PMC as
a whole is on top of the commits, then when release time comes around RAT
is sufficient to act as a check of those requirements.
The tricky part - for me - is the provenance of code stuff... Not that
others get that right either...
Case in point is Eclipse which does a whole rigmarole dance over having
legal people review the changes... When every commiters CLA is an
unverified signature and could thus be forged... Quite possible for
somebody to commit to Eclipse code that they do not have the IP rights to
grant to Eclipse *and* the whole song and dance simply gives the illusion
of protection against that eventuality.
We have a similar problem, but no official song and dance... Nor do we have
(or, to my mind, want) a team of legal people to spend buckets of time
holding up a release for legal review.
It all boils down to the commits and whether the people making those
commits have the required IP rights for the code they are committing.
We trust our committers to do the right thing... Committers that we only
know via an email address... We may not even know their real name or
identity... But short of demanding a physical chain of trusted identity -
which would make it even harder to grow our communities - there is not much
we can do... We just have to trust they are doing things right...
Our committers also commit patches submitted by non ASF people. We don't
give a clear guideline to committers w.r.t. how big a patch must be before
there must be a ICLA on file... Never mind things like easy impersonation
on GitHub... How are our committers supposed to know that the person
claiming to have submitted the patch is actually the same Joe Bloggs who
signed the ICLA... Let alone whether that person has the permission of the
IP owner to license the code to the ASF?
When I ponder what the PMC chair's extra responsibilities are w.r.t.
ensuring that releases comply with legal requirements this problem is the
one that has me look forward to rotating the Maven chair in a couple of
months ;-)
On Friday, 30 May 2014, Jacques Le Roux <ja...@les7arts.com>
wrote:
> We (OFBiz team) are using RAT, I mean it's not enough, it's not completely
> automated
>
> Jacques
>
> Le 30/05/2014 17:42, Emmanuel Lécharny a écrit :
>
>> Le 30/05/2014 16:23, Jacques Le Roux a écrit :
>>
>>> Le 30/05/2014 16:01, Stephen Connolly a écrit :
>>>
>>>> * All the source code of the project must be covered by the Apache
>>>> License, version 2.0.
>>>>
>>>> We can't rely safely only on RAT (as least as it is now) for that, for
>>> instance too much false positive in my experience
>>>
>> What tool are you proposing for that check ?
>>
>> I mean, you are not seriously expecting to do that by hand ?
>>
>> (FTR, Apache Directory has 59 618 files...)
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
>>
> --
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
--
Sent from my phone
Re: Continuous release review
Posted by Jacques Le Roux <ja...@les7arts.com>.
We (OFBiz team) are using RAT, I mean it's not enough, it's not completely automated
Jacques
Le 30/05/2014 17:42, Emmanuel Lécharny a écrit :
> Le 30/05/2014 16:23, Jacques Le Roux a écrit :
>> Le 30/05/2014 16:01, Stephen Connolly a écrit :
>>> * All the source code of the project must be covered by the Apache
>>> License, version 2.0.
>>>
>> We can't rely safely only on RAT (as least as it is now) for that, for
>> instance too much false positive in my experience
> What tool are you proposing for that check ?
>
> I mean, you are not seriously expecting to do that by hand ?
>
> (FTR, Apache Directory has 59 618 files...)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
--
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 30/05/2014 16:23, Jacques Le Roux a écrit :
> Le 30/05/2014 16:01, Stephen Connolly a écrit :
>>
>> * All the source code of the project must be covered by the Apache
>> License, version 2.0.
>>
>
> We can't rely safely only on RAT (as least as it is now) for that, for
> instance too much false positive in my experience
What tool are you proposing for that check ?
I mean, you are not seriously expecting to do that by hand ?
(FTR, Apache Directory has 59 618 files...)
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 30/05/2014 16:01, Stephen Connolly a écrit :
> hit send too early...
>
>
> On 30 May 2014 14:52, Stephen Connolly <stephen.alan.connolly@gmail.com <ma...@gmail.com>> wrote:
>
> Well I have not seen anyone address my specific point with regard to separating the concerns w.r.t. voting.
>
> We vote on releases for legal and social reasons.
>
> The legal reasons mandate that we need to download the archive and verify that it is something we can legally ship. There are a set of criteria
> with regards to shipping. Some of these criteria are things like:
>
> * Does it include the LICENSE an NOTICE files
> * All the source code of the project must be covered by the Apache License, version 2.0.
> * The license must be included in each source file.
> * Has the code been contributed by an individual covered by an appropriate contributor license agreement, or have otherwise been licensed to the
> Foundation and passed through IP clearance.
> * Are bundled 3rd party dependencies compatible with the Apache License, version 2.0.
>
> The social reasons pressure us to download the archive and check that it builds and check that any included tests pass and check some relevant
> smoke tests.
>
> From my PoV - as a PMC chair [1] - the legal requirements are what matter to most to me, as I am responsible for compliance with the legal
> requirements...
>
> The social requirements are something that can and should be easily replaced by a CI system.
>
> The final question is then how thorough do we have to be in checking the legal stuff.
>
> So let's take the bits that we know
> * Does it include the LICENSE an NOTICE files
>
> RAT will check this... so simple and quick (if there is a RAT configuration in the project)
>
> * All the source code of the project must be covered by the Apache License, version 2.0.
>
We can't rely safely only on RAT (as least as it is now) for that, for instance too much false positive in my experience
> RAT will check this... so simple and quick (if there is a RAT configuration in the project)
>
> * The license must be included in each source file.
>
> RAT will check this... so simple and quick (if there is a RAT configuration in the project)
Idem, not enough (or I don't know enough about RAT configuration and how to maintain it in time)
Jacques
>
> * Has the code been contributed by an individual covered by an appropriate contributor license agreement, or have otherwise been licensed to the
> Foundation and passed through IP clearance.
>
> Here things get wooly. If all the files came via source control and the commited-by info is ASF committers then I can safely assume that the code
> has been "contributed by an individual covered by an appropriate contributor license agreement" *but* for big commits I don't know if those
> committers were sticking to the rules or just committing a big pull request / patch submitted without the required IP clearance.
>
> If I have been watching the commits list, I should have a handle on these things... but can everyone honestly say they have never just wiped their
> inbox clean when they got back from a 2 week vacation?
>
> Also if we are being strict in the legal sense, it's not just the commits since the last release... its the code since the start of time.
>
> It is this check that I likened to the QA of a batch of toys...
>
> * Are bundled 3rd party dependencies compatible with the Apache License, version 2.0.
>
> Should be easy to check in those cases where you cannot automate... the 3rd party dependencies should be small in number and not subject to major
> deltas from the last release
>
>
> [1]: http://www.apache.org/dev/release-publishing.html says
> The PMC in general, and the PMC chair in particular (as an officer of the Foundation) is responsible for compliance with requirements.
>
>
> On 30 May 2014 14:25, Jim Jagielski <jim@jagunet.com <ma...@jagunet.com>> wrote:
>
> Who says that we can't... in fact, we should. We should
> use technology as much as we can. But CI does not
> remove the need for reviewing/vetting/verifying
> the release as we do (and should).
>
> It appears to me that many people are arguing that
> the existance of CI obliviates the need to perform
> the release process (eg: 3 +1s, 72 hour wait, etc)...
> That is the issue we are trying to clear up.
>
> On Fri, May 30, 2014 at 03:04:17PM +0200, Jacques Le Roux wrote:
> > I'm curious, why not having both?
> >
> > 1) A CI tool to ease things
> > 2) To continue to review releases as it's done now
> >
> > Jacques
> >
> > Le 30/05/2014 14:22, Jim Jagielski a ?crit :
> > >The Board expects the PMC to do its job, and the
> > >Board expects the PMC Chair to do his/her job.
> > >
> > >If they don't, the board acts; and, as has been said
> > >many times, the board is not a surgical scalpel; it
> > >is a hammer.
> > >
> > >On May 30, 2014, at 8:09 AM, Emmanuel L?charny <elecharny@gmail.com <ma...@gmail.com>> wrote:
> > >
> > >>Le 29/05/2014 17:47, Jim Jagielski a ?crit :
> > >>>On May 29, 2014, at 11:28 AM, Emmanuel L?charny <elecharny@gmail.com <ma...@gmail.com>>
> > >>>wrote:
> > >>>
> > >>>>Le 29/05/2014 15:56, Jim Jagielski a ?crit :
> > >>>>>I disagree. And until the policy is changed, PMCs and
> > >>>>>RMs are expected and *required* to comply.
> > >>>>Yes, but actually, most f the PMCs and RMs *aren't* Like it or not.
> > >>>>
> > >>>>...
> > >>>>And, yes, it's probably a good idea to fix the policy if it can't be
> > >>>>enforced.
> > >>>>
> > >>>To be clear: If it is found out that there are "releases" out
> > >>>there that really aren't releases, the board will tell the
> > >>>PMC to:
> > >>>
> > >>> 1: Remove those releases immediately.
> > >>> 2: Re-release those "releases" as real releases
> > >>> by complying w/ the release policy (basically,
> > >>> taking those "releases" and doing the required
> > >>> vetting and voting).
> > >>>
> > >>>The board can, and will, also remove a PMCs ability
> > >>>to "release" stuff if it refuses to comply with the
> > >>>release policy. So it can be enforced. It is being
> > >>>enforced. It will be enforced.
> > >>This is not an enforcement. This is a punishment. And it's totally vain.
> > >>
> > >>Unless the board is ready to check all the releases for all the 151
> > >>projects, and verify that *every* PMC member is eventually going through
> > >>the whole process, this is just a void statement.
> > >>
> > >>Btw, just tell me how you are going to control that ? I'm curious...
> > >>OTOH, we van make it easier for the PMC members to cast a vote, by
> > >>verifying the output of a documented/replayable process, which will take
> > >>a few minutes instead of hours in some cases. How possibly can someone
> > >>object that it would be a progress ?
> > >>
> > >>
> > >>
> > >>---------------------------------------------------------------------
> > >>To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org <ma...@apache.org>
> > >>For additional commands, e-mail: legal-discuss-help@apache.org <ma...@apache.org>
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org <ma...@apache.org>
> > >For additional commands, e-mail: legal-discuss-help@apache.org <ma...@apache.org>
> > >
> > >
> > >
> >
> > --
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org <ma...@apache.org>
> > For additional commands, e-mail: legal-discuss-help@apache.org <ma...@apache.org>
>
> --
> ===========================================================================
> Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
> "Great is the guilt of an unnecessary war" ~ John Adams
>
>
>
--
Re: Continuous release review
Posted by Stephen Connolly <st...@gmail.com>.
On 30 May 2014 15:19, sebb <se...@gmail.com> wrote:
> On 30 May 2014 15:01, Stephen Connolly <st...@gmail.com>
> wrote:
> > hit send too early...
> >
> >
> > On 30 May 2014 14:52, Stephen Connolly <st...@gmail.com>
> > wrote:
> >>
> >> Well I have not seen anyone address my specific point with regard to
> >> separating the concerns w.r.t. voting.
> >>
> >> We vote on releases for legal and social reasons.
> >>
> >> The legal reasons mandate that we need to download the archive and
> verify
> >> that it is something we can legally ship. There are a set of criteria
> with
> >> regards to shipping. Some of these criteria are things like:
> >>
> >> * Does it include the LICENSE an NOTICE files
> >> * All the source code of the project must be covered by the Apache
> >> License, version 2.0.
> >> * The license must be included in each source file.
> >> * Has the code been contributed by an individual covered by an
> appropriate
> >> contributor license agreement, or have otherwise been licensed to the
> >> Foundation and passed through IP clearance.
> >> * Are bundled 3rd party dependencies compatible with the Apache License,
> >> version 2.0.
> >>
> >> The social reasons pressure us to download the archive and check that it
> >> builds and check that any included tests pass and check some relevant
> smoke
> >> tests.
> >>
> >> From my PoV - as a PMC chair [1] - the legal requirements are what
> matter
> >> to most to me, as I am responsible for compliance with the legal
> >> requirements...
> >>
> >> The social requirements are something that can and should be easily
> >> replaced by a CI system.
> >
> >
> > The final question is then how thorough do we have to be in checking the
> > legal stuff.
> >
> > So let's take the bits that we know
> >
> > * Does it include the LICENSE an NOTICE files
> >
> > RAT will check this... so simple and quick (if there is a RAT
> configuration
> > in the project)
>
> AFAIK RAT does not check this.
> And it does not check that the NOTICE and LICENSE files agree with the
> included dependencies.
> Since it works on the source files, the most it can check is that the
> files exist.
> It cannot check for dependencies bundled with the binary (or source!)
> archive.
> I don't see how it can check the attributions in the NOTICE file
> (apart from the ones require for each project), nor can it check the
> contents of the LICENSE file apart from ensuring that the ALv2 is
> there at the start.
>
Well we always have you to do random spot checks that we reserve the right
to disagree with ;-)
>
> > * All the source code of the project must be covered by the Apache
> License,
> > version 2.0.
> >
> > RAT will check this... so simple and quick (if there is a RAT
> configuration
> > in the project)
>
> There is no way that RAT can check this.
> All RAT can do is check that it has the appropriate header; it cannot
> check if the header actually applies to the file.
>
Well the second question is a separate issue, i.e. my 4th point. If my 4th
point is addressed you can assume that the presence of the header implies
the code is covered.
>
> > * The license must be included in each source file.
> >
> > RAT will check this... so simple and quick (if there is a RAT
> configuration
> > in the project)
>
> RAT does check this, but the config can easily be set to exclude certain
> files.
>
> > * Has the code been contributed by an individual covered by an
> appropriate
> > contributor license agreement, or have otherwise been licensed to the
> > Foundation and passed through IP clearance.
> >
> > Here things get wooly. If all the files came via source control and the
> > commited-by info is ASF committers then I can safely assume that the code
> > has been "contributed by an individual covered by an appropriate
> contributor
> > license agreement" *but* for big commits I don't know if those committers
> > were sticking to the rules or just committing a big pull request / patch
> > submitted without the required IP clearance.
> >
> > If I have been watching the commits list, I should have a handle on these
> > things... but can everyone honestly say they have never just wiped their
> > inbox clean when they got back from a 2 week vacation?
> >
> > Also if we are being strict in the legal sense, it's not just the commits
> > since the last release... its the code since the start of time.
> >
> > It is this check that I likened to the QA of a batch of toys...
> >
> > * Are bundled 3rd party dependencies compatible with the Apache License,
> > version 2.0.
> >
> > Should be easy to check in those cases where you cannot automate... the
> 3rd
> > party dependencies should be small in number and not subject to major
> deltas
> > from the last release
>
> Some projects ship lots of dependencies.
> It can be a big job assessing them first time round.
> It's not always obvious what the 3rd party license is, and then one
> has to determine what the ASF classification for that license is.
> That is not always immediately obvious either.
>
I agree that this is a pain for some the first time around... but once you
have got over that pain it should be deltas only.
>
> The dependencies also need to be manually checked with every update
> because licenses can change between versions.
>
Yep... My point was that you should be able to easily check them. I did not
suggest a manual check for this point. I suggested checking them via a
delta from the last release.
>
> >>
> >>
> >> [1]: http://www.apache.org/dev/release-publishing.html says
> >> The PMC in general, and the PMC chair in particular (as an officer
> of
> >> the Foundation) is responsible for compliance with requirements.
> >>
> >>
> >> On 30 May 2014 14:25, Jim Jagielski <ji...@jagunet.com> wrote:
> >>>
> >>> Who says that we can't... in fact, we should. We should
> >>> use technology as much as we can. But CI does not
> >>> remove the need for reviewing/vetting/verifying
> >>> the release as we do (and should).
> >>>
> >>> It appears to me that many people are arguing that
> >>> the existance of CI obliviates the need to perform
> >>> the release process (eg: 3 +1s, 72 hour wait, etc)...
> >>> That is the issue we are trying to clear up.
> >>>
> >>> On Fri, May 30, 2014 at 03:04:17PM +0200, Jacques Le Roux wrote:
> >>> > I'm curious, why not having both?
> >>> >
> >>> > 1) A CI tool to ease things
> >>> > 2) To continue to review releases as it's done now
> >>> >
> >>> > Jacques
> >>> >
> >>> > Le 30/05/2014 14:22, Jim Jagielski a ?crit :
> >>> > >The Board expects the PMC to do its job, and the
> >>> > >Board expects the PMC Chair to do his/her job.
> >>> > >
> >>> > >If they don't, the board acts; and, as has been said
> >>> > >many times, the board is not a surgical scalpel; it
> >>> > >is a hammer.
> >>> > >
> >>> > >On May 30, 2014, at 8:09 AM, Emmanuel L?charny <elecharny@gmail.com
> >
> >>> > > wrote:
> >>> > >
> >>> > >>Le 29/05/2014 17:47, Jim Jagielski a ?crit :
> >>> > >>>On May 29, 2014, at 11:28 AM, Emmanuel L?charny
> >>> > >>> <el...@gmail.com>
> >>> > >>>wrote:
> >>> > >>>
> >>> > >>>>Le 29/05/2014 15:56, Jim Jagielski a ?crit :
> >>> > >>>>>I disagree. And until the policy is changed, PMCs and
> >>> > >>>>>RMs are expected and *required* to comply.
> >>> > >>>>Yes, but actually, most f the PMCs and RMs *aren't* Like it or
> not.
> >>> > >>>>
> >>> > >>>>...
> >>> > >>>>And, yes, it's probably a good idea to fix the policy if it can't
> >>> > >>>> be
> >>> > >>>>enforced.
> >>> > >>>>
> >>> > >>>To be clear: If it is found out that there are "releases" out
> >>> > >>>there that really aren't releases, the board will tell the
> >>> > >>>PMC to:
> >>> > >>>
> >>> > >>> 1: Remove those releases immediately.
> >>> > >>> 2: Re-release those "releases" as real releases
> >>> > >>> by complying w/ the release policy (basically,
> >>> > >>> taking those "releases" and doing the required
> >>> > >>> vetting and voting).
> >>> > >>>
> >>> > >>>The board can, and will, also remove a PMCs ability
> >>> > >>>to "release" stuff if it refuses to comply with the
> >>> > >>>release policy. So it can be enforced. It is being
> >>> > >>>enforced. It will be enforced.
> >>> > >>This is not an enforcement. This is a punishment. And it's totally
> >>> > >> vain.
> >>> > >>
> >>> > >>Unless the board is ready to check all the releases for all the 151
> >>> > >>projects, and verify that *every* PMC member is eventually going
> >>> > >> through
> >>> > >>the whole process, this is just a void statement.
> >>> > >>
> >>> > >>Btw, just tell me how you are going to control that ? I'm
> curious...
> >>> > >>OTOH, we van make it easier for the PMC members to cast a vote, by
> >>> > >>verifying the output of a documented/replayable process, which will
> >>> > >> take
> >>> > >>a few minutes instead of hours in some cases. How possibly can
> >>> > >> someone
> >>> > >>object that it would be a progress ?
> >>> > >>
> >>> > >>
> >>> > >>
> >>> >
> >>---------------------------------------------------------------------
> >>> > >>To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >>> > >>For additional commands, e-mail: legal-discuss-help@apache.org
> >>> > >
> >>> >
> >---------------------------------------------------------------------
> >>> > >To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >>> > >For additional commands, e-mail: legal-discuss-help@apache.org
> >>> > >
> >>> > >
> >>> > >
> >>> >
> >>> > --
> >>> >
> >>> > ---------------------------------------------------------------------
> >>> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >>> > For additional commands, e-mail: legal-discuss-help@apache.org
> >>>
> >>> --
> >>>
> >>>
> ===========================================================================
> >>> Jim Jagielski [|] jim@jaguNET.com [|]
> http://www.jaguNET.com/
> >>> "Great is the guilt of an unnecessary war" ~ John Adams
> >>
> >>
> >
>
Re: Continuous release review
Posted by sebb <se...@gmail.com>.
On 30 May 2014 15:01, Stephen Connolly <st...@gmail.com> wrote:
> hit send too early...
>
>
> On 30 May 2014 14:52, Stephen Connolly <st...@gmail.com>
> wrote:
>>
>> Well I have not seen anyone address my specific point with regard to
>> separating the concerns w.r.t. voting.
>>
>> We vote on releases for legal and social reasons.
>>
>> The legal reasons mandate that we need to download the archive and verify
>> that it is something we can legally ship. There are a set of criteria with
>> regards to shipping. Some of these criteria are things like:
>>
>> * Does it include the LICENSE an NOTICE files
>> * All the source code of the project must be covered by the Apache
>> License, version 2.0.
>> * The license must be included in each source file.
>> * Has the code been contributed by an individual covered by an appropriate
>> contributor license agreement, or have otherwise been licensed to the
>> Foundation and passed through IP clearance.
>> * Are bundled 3rd party dependencies compatible with the Apache License,
>> version 2.0.
>>
>> The social reasons pressure us to download the archive and check that it
>> builds and check that any included tests pass and check some relevant smoke
>> tests.
>>
>> From my PoV - as a PMC chair [1] - the legal requirements are what matter
>> to most to me, as I am responsible for compliance with the legal
>> requirements...
>>
>> The social requirements are something that can and should be easily
>> replaced by a CI system.
>
>
> The final question is then how thorough do we have to be in checking the
> legal stuff.
>
> So let's take the bits that we know
>
> * Does it include the LICENSE an NOTICE files
>
> RAT will check this... so simple and quick (if there is a RAT configuration
> in the project)
AFAIK RAT does not check this.
And it does not check that the NOTICE and LICENSE files agree with the
included dependencies.
Since it works on the source files, the most it can check is that the
files exist.
It cannot check for dependencies bundled with the binary (or source!) archive.
I don't see how it can check the attributions in the NOTICE file
(apart from the ones require for each project), nor can it check the
contents of the LICENSE file apart from ensuring that the ALv2 is
there at the start.
> * All the source code of the project must be covered by the Apache License,
> version 2.0.
>
> RAT will check this... so simple and quick (if there is a RAT configuration
> in the project)
There is no way that RAT can check this.
All RAT can do is check that it has the appropriate header; it cannot
check if the header actually applies to the file.
> * The license must be included in each source file.
>
> RAT will check this... so simple and quick (if there is a RAT configuration
> in the project)
RAT does check this, but the config can easily be set to exclude certain files.
> * Has the code been contributed by an individual covered by an appropriate
> contributor license agreement, or have otherwise been licensed to the
> Foundation and passed through IP clearance.
>
> Here things get wooly. If all the files came via source control and the
> commited-by info is ASF committers then I can safely assume that the code
> has been "contributed by an individual covered by an appropriate contributor
> license agreement" *but* for big commits I don't know if those committers
> were sticking to the rules or just committing a big pull request / patch
> submitted without the required IP clearance.
>
> If I have been watching the commits list, I should have a handle on these
> things... but can everyone honestly say they have never just wiped their
> inbox clean when they got back from a 2 week vacation?
>
> Also if we are being strict in the legal sense, it's not just the commits
> since the last release... its the code since the start of time.
>
> It is this check that I likened to the QA of a batch of toys...
>
> * Are bundled 3rd party dependencies compatible with the Apache License,
> version 2.0.
>
> Should be easy to check in those cases where you cannot automate... the 3rd
> party dependencies should be small in number and not subject to major deltas
> from the last release
Some projects ship lots of dependencies.
It can be a big job assessing them first time round.
It's not always obvious what the 3rd party license is, and then one
has to determine what the ASF classification for that license is.
That is not always immediately obvious either.
The dependencies also need to be manually checked with every update
because licenses can change between versions.
>>
>>
>> [1]: http://www.apache.org/dev/release-publishing.html says
>> The PMC in general, and the PMC chair in particular (as an officer of
>> the Foundation) is responsible for compliance with requirements.
>>
>>
>> On 30 May 2014 14:25, Jim Jagielski <ji...@jagunet.com> wrote:
>>>
>>> Who says that we can't... in fact, we should. We should
>>> use technology as much as we can. But CI does not
>>> remove the need for reviewing/vetting/verifying
>>> the release as we do (and should).
>>>
>>> It appears to me that many people are arguing that
>>> the existance of CI obliviates the need to perform
>>> the release process (eg: 3 +1s, 72 hour wait, etc)...
>>> That is the issue we are trying to clear up.
>>>
>>> On Fri, May 30, 2014 at 03:04:17PM +0200, Jacques Le Roux wrote:
>>> > I'm curious, why not having both?
>>> >
>>> > 1) A CI tool to ease things
>>> > 2) To continue to review releases as it's done now
>>> >
>>> > Jacques
>>> >
>>> > Le 30/05/2014 14:22, Jim Jagielski a ?crit :
>>> > >The Board expects the PMC to do its job, and the
>>> > >Board expects the PMC Chair to do his/her job.
>>> > >
>>> > >If they don't, the board acts; and, as has been said
>>> > >many times, the board is not a surgical scalpel; it
>>> > >is a hammer.
>>> > >
>>> > >On May 30, 2014, at 8:09 AM, Emmanuel L?charny <el...@gmail.com>
>>> > > wrote:
>>> > >
>>> > >>Le 29/05/2014 17:47, Jim Jagielski a ?crit :
>>> > >>>On May 29, 2014, at 11:28 AM, Emmanuel L?charny
>>> > >>> <el...@gmail.com>
>>> > >>>wrote:
>>> > >>>
>>> > >>>>Le 29/05/2014 15:56, Jim Jagielski a ?crit :
>>> > >>>>>I disagree. And until the policy is changed, PMCs and
>>> > >>>>>RMs are expected and *required* to comply.
>>> > >>>>Yes, but actually, most f the PMCs and RMs *aren't* Like it or not.
>>> > >>>>
>>> > >>>>...
>>> > >>>>And, yes, it's probably a good idea to fix the policy if it can't
>>> > >>>> be
>>> > >>>>enforced.
>>> > >>>>
>>> > >>>To be clear: If it is found out that there are "releases" out
>>> > >>>there that really aren't releases, the board will tell the
>>> > >>>PMC to:
>>> > >>>
>>> > >>> 1: Remove those releases immediately.
>>> > >>> 2: Re-release those "releases" as real releases
>>> > >>> by complying w/ the release policy (basically,
>>> > >>> taking those "releases" and doing the required
>>> > >>> vetting and voting).
>>> > >>>
>>> > >>>The board can, and will, also remove a PMCs ability
>>> > >>>to "release" stuff if it refuses to comply with the
>>> > >>>release policy. So it can be enforced. It is being
>>> > >>>enforced. It will be enforced.
>>> > >>This is not an enforcement. This is a punishment. And it's totally
>>> > >> vain.
>>> > >>
>>> > >>Unless the board is ready to check all the releases for all the 151
>>> > >>projects, and verify that *every* PMC member is eventually going
>>> > >> through
>>> > >>the whole process, this is just a void statement.
>>> > >>
>>> > >>Btw, just tell me how you are going to control that ? I'm curious...
>>> > >>OTOH, we van make it easier for the PMC members to cast a vote, by
>>> > >>verifying the output of a documented/replayable process, which will
>>> > >> take
>>> > >>a few minutes instead of hours in some cases. How possibly can
>>> > >> someone
>>> > >>object that it would be a progress ?
>>> > >>
>>> > >>
>>> > >>
>>> > >>---------------------------------------------------------------------
>>> > >>To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> > >>For additional commands, e-mail: legal-discuss-help@apache.org
>>> > >
>>> > >---------------------------------------------------------------------
>>> > >To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> > >For additional commands, e-mail: legal-discuss-help@apache.org
>>> > >
>>> > >
>>> > >
>>> >
>>> > --
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> > For additional commands, e-mail: legal-discuss-help@apache.org
>>>
>>> --
>>>
>>> ===========================================================================
>>> Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
>>> "Great is the guilt of an unnecessary war" ~ John Adams
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> * Does it include the LICENSE an NOTICE files
>
> RAT will check this... so simple and quick (if there is a RAT configuration in the project)
However rat may not tell if the contents are actually correct. The Rat configuration in the project may also be incorrect.
> * The license must be included in each source file.
>
> RAT will check this... so simple and quick (if there is a RAT configuration in the project)
While rat helps with this it doesn't pick up everything, there's often noise from generated files, some binaries may be ok and others not even of the same format (eg images) and license headers can be changed.
While rat is a useful tool it's output generally needs to be looked at/double checked by a human.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Stephen Connolly <st...@gmail.com>.
hit send too early...
On 30 May 2014 14:52, Stephen Connolly <st...@gmail.com>
wrote:
> Well I have not seen anyone address my specific point with regard to
> separating the concerns w.r.t. voting.
>
> We vote on releases for legal and social reasons.
>
> The legal reasons mandate that we need to download the archive and verify
> that it is something we can legally ship. There are a set of criteria with
> regards to shipping. Some of these criteria are things like:
>
> * Does it include the LICENSE an NOTICE files
> * All the source code of the project must be covered by the Apache
> License, version 2.0.
> * The license must be included in each source file.
> * Has the code been contributed by an individual covered by an appropriate
> contributor license agreement, or have otherwise been licensed to the
> Foundation and passed through IP clearance.
> * Are bundled 3rd party dependencies compatible with the Apache License,
> version 2.0.
>
> The social reasons pressure us to download the archive and check that it
> builds and check that any included tests pass and check some relevant smoke
> tests.
>
> From my PoV - as a PMC chair [1] - the legal requirements are what matter
> to most to me, as I am responsible for compliance with the legal
> requirements...
>
> The social requirements are something that can and should be easily
> replaced by a CI system.
>
The final question is then how thorough do we have to be in checking the
legal stuff.
So let's take the bits that we know
* Does it include the LICENSE an NOTICE files
RAT will check this... so simple and quick (if there is a RAT configuration
in the project)
* All the source code of the project must be covered by the Apache License,
version 2.0.
RAT will check this... so simple and quick (if there is a RAT configuration
in the project)
* The license must be included in each source file.
RAT will check this... so simple and quick (if there is a RAT configuration
in the project)
* Has the code been contributed by an individual covered by an appropriate
contributor license agreement, or have otherwise been licensed to the
Foundation and passed through IP clearance.
Here things get wooly. If all the files came via source control and the
commited-by info is ASF committers then I can safely assume that the code
has been "contributed by an individual covered by an appropriate
contributor license agreement" *but* for big commits I don't know if those
committers were sticking to the rules or just committing a big pull request
/ patch submitted without the required IP clearance.
If I have been watching the commits list, I should have a handle on these
things... but can everyone honestly say they have never just wiped their
inbox clean when they got back from a 2 week vacation?
Also if we are being strict in the legal sense, it's not just the commits
since the last release... its the code since the start of time.
It is this check that I likened to the QA of a batch of toys...
* Are bundled 3rd party dependencies compatible with the Apache License,
version 2.0.
Should be easy to check in those cases where you cannot automate... the 3rd
party dependencies should be small in number and not subject to major
deltas from the last release
>
> [1]: http://www.apache.org/dev/release-publishing.html says
> The PMC in general, and the PMC chair in particular (as an officer of
> the Foundation) is responsible for compliance with requirements.
>
>
> On 30 May 2014 14:25, Jim Jagielski <ji...@jagunet.com> wrote:
>
>> Who says that we can't... in fact, we should. We should
>> use technology as much as we can. But CI does not
>> remove the need for reviewing/vetting/verifying
>> the release as we do (and should).
>>
>> It appears to me that many people are arguing that
>> the existance of CI obliviates the need to perform
>> the release process (eg: 3 +1s, 72 hour wait, etc)...
>> That is the issue we are trying to clear up.
>>
>> On Fri, May 30, 2014 at 03:04:17PM +0200, Jacques Le Roux wrote:
>> > I'm curious, why not having both?
>> >
>> > 1) A CI tool to ease things
>> > 2) To continue to review releases as it's done now
>> >
>> > Jacques
>> >
>> > Le 30/05/2014 14:22, Jim Jagielski a ?crit :
>> > >The Board expects the PMC to do its job, and the
>> > >Board expects the PMC Chair to do his/her job.
>> > >
>> > >If they don't, the board acts; and, as has been said
>> > >many times, the board is not a surgical scalpel; it
>> > >is a hammer.
>> > >
>> > >On May 30, 2014, at 8:09 AM, Emmanuel L?charny <el...@gmail.com>
>> wrote:
>> > >
>> > >>Le 29/05/2014 17:47, Jim Jagielski a ?crit :
>> > >>>On May 29, 2014, at 11:28 AM, Emmanuel L?charny <elecharny@gmail.com
>> >
>> > >>>wrote:
>> > >>>
>> > >>>>Le 29/05/2014 15:56, Jim Jagielski a ?crit :
>> > >>>>>I disagree. And until the policy is changed, PMCs and
>> > >>>>>RMs are expected and *required* to comply.
>> > >>>>Yes, but actually, most f the PMCs and RMs *aren't* Like it or not.
>> > >>>>
>> > >>>>...
>> > >>>>And, yes, it's probably a good idea to fix the policy if it can't be
>> > >>>>enforced.
>> > >>>>
>> > >>>To be clear: If it is found out that there are "releases" out
>> > >>>there that really aren't releases, the board will tell the
>> > >>>PMC to:
>> > >>>
>> > >>> 1: Remove those releases immediately.
>> > >>> 2: Re-release those "releases" as real releases
>> > >>> by complying w/ the release policy (basically,
>> > >>> taking those "releases" and doing the required
>> > >>> vetting and voting).
>> > >>>
>> > >>>The board can, and will, also remove a PMCs ability
>> > >>>to "release" stuff if it refuses to comply with the
>> > >>>release policy. So it can be enforced. It is being
>> > >>>enforced. It will be enforced.
>> > >>This is not an enforcement. This is a punishment. And it's totally
>> vain.
>> > >>
>> > >>Unless the board is ready to check all the releases for all the 151
>> > >>projects, and verify that *every* PMC member is eventually going
>> through
>> > >>the whole process, this is just a void statement.
>> > >>
>> > >>Btw, just tell me how you are going to control that ? I'm curious...
>> > >>OTOH, we van make it easier for the PMC members to cast a vote, by
>> > >>verifying the output of a documented/replayable process, which will
>> take
>> > >>a few minutes instead of hours in some cases. How possibly can someone
>> > >>object that it would be a progress ?
>> > >>
>> > >>
>> > >>
>> > >>---------------------------------------------------------------------
>> > >>To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> > >>For additional commands, e-mail: legal-discuss-help@apache.org
>> > >
>> > >---------------------------------------------------------------------
>> > >To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> > >For additional commands, e-mail: legal-discuss-help@apache.org
>> > >
>> > >
>> > >
>> >
>> > --
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> > For additional commands, e-mail: legal-discuss-help@apache.org
>>
>> --
>>
>> ===========================================================================
>> Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
>> "Great is the guilt of an unnecessary war" ~ John Adams
>>
>
>
Re: Continuous release review
Posted by Stephen Connolly <st...@gmail.com>.
Well I have not seen anyone address my specific point with regard to
separating the concerns w.r.t. voting.
We vote on releases for legal and social reasons.
The legal reasons mandate that we need to download the archive and verify
that it is something we can legally ship. There are a set of criteria with
regards to shipping. Some of these criteria are things like:
* Does it include the LICENSE an NOTICE files
* All the source code of the project must be covered by the Apache License,
version 2.0.
* The license must be included in each source file.
* Has the code been contributed by an individual covered by an appropriate
contributor license agreement, or have otherwise been licensed to the
Foundation and passed through IP clearance.
* Are bundled 3rd party dependencies compatible with the Apache License,
version 2.0.
The social reasons pressure us to download the archive and check that it
builds and check that any included tests pass and check some relevant smoke
tests.
>From my PoV - as a PMC chair [1] - the legal requirements are what matter
to most to me, as I am responsible for compliance with the legal
requirements...
The social requirements are something that can and should be easily
replaced by a CI system.
The final question is then how thorough do we have to be in
[1]: http://www.apache.org/dev/release-publishing.html says
The PMC in general, and the PMC chair in particular (as an officer of
the Foundation) is responsible for compliance with requirements.
On 30 May 2014 14:25, Jim Jagielski <ji...@jagunet.com> wrote:
> Who says that we can't... in fact, we should. We should
> use technology as much as we can. But CI does not
> remove the need for reviewing/vetting/verifying
> the release as we do (and should).
>
> It appears to me that many people are arguing that
> the existance of CI obliviates the need to perform
> the release process (eg: 3 +1s, 72 hour wait, etc)...
> That is the issue we are trying to clear up.
>
> On Fri, May 30, 2014 at 03:04:17PM +0200, Jacques Le Roux wrote:
> > I'm curious, why not having both?
> >
> > 1) A CI tool to ease things
> > 2) To continue to review releases as it's done now
> >
> > Jacques
> >
> > Le 30/05/2014 14:22, Jim Jagielski a ?crit :
> > >The Board expects the PMC to do its job, and the
> > >Board expects the PMC Chair to do his/her job.
> > >
> > >If they don't, the board acts; and, as has been said
> > >many times, the board is not a surgical scalpel; it
> > >is a hammer.
> > >
> > >On May 30, 2014, at 8:09 AM, Emmanuel L?charny <el...@gmail.com>
> wrote:
> > >
> > >>Le 29/05/2014 17:47, Jim Jagielski a ?crit :
> > >>>On May 29, 2014, at 11:28 AM, Emmanuel L?charny <el...@gmail.com>
> > >>>wrote:
> > >>>
> > >>>>Le 29/05/2014 15:56, Jim Jagielski a ?crit :
> > >>>>>I disagree. And until the policy is changed, PMCs and
> > >>>>>RMs are expected and *required* to comply.
> > >>>>Yes, but actually, most f the PMCs and RMs *aren't* Like it or not.
> > >>>>
> > >>>>...
> > >>>>And, yes, it's probably a good idea to fix the policy if it can't be
> > >>>>enforced.
> > >>>>
> > >>>To be clear: If it is found out that there are "releases" out
> > >>>there that really aren't releases, the board will tell the
> > >>>PMC to:
> > >>>
> > >>> 1: Remove those releases immediately.
> > >>> 2: Re-release those "releases" as real releases
> > >>> by complying w/ the release policy (basically,
> > >>> taking those "releases" and doing the required
> > >>> vetting and voting).
> > >>>
> > >>>The board can, and will, also remove a PMCs ability
> > >>>to "release" stuff if it refuses to comply with the
> > >>>release policy. So it can be enforced. It is being
> > >>>enforced. It will be enforced.
> > >>This is not an enforcement. This is a punishment. And it's totally
> vain.
> > >>
> > >>Unless the board is ready to check all the releases for all the 151
> > >>projects, and verify that *every* PMC member is eventually going
> through
> > >>the whole process, this is just a void statement.
> > >>
> > >>Btw, just tell me how you are going to control that ? I'm curious...
> > >>OTOH, we van make it easier for the PMC members to cast a vote, by
> > >>verifying the output of a documented/replayable process, which will
> take
> > >>a few minutes instead of hours in some cases. How possibly can someone
> > >>object that it would be a progress ?
> > >>
> > >>
> > >>
> > >>---------------------------------------------------------------------
> > >>To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > >>For additional commands, e-mail: legal-discuss-help@apache.org
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > >For additional commands, e-mail: legal-discuss-help@apache.org
> > >
> > >
> > >
> >
> > --
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
>
> --
> ===========================================================================
> Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
> "Great is the guilt of an unnecessary war" ~ John Adams
>
Re: Continuous release review
Posted by Jim Jagielski <ji...@jaguNET.com>.
Who says that we can't... in fact, we should. We should
use technology as much as we can. But CI does not
remove the need for reviewing/vetting/verifying
the release as we do (and should).
It appears to me that many people are arguing that
the existance of CI obliviates the need to perform
the release process (eg: 3 +1s, 72 hour wait, etc)...
That is the issue we are trying to clear up.
On Fri, May 30, 2014 at 03:04:17PM +0200, Jacques Le Roux wrote:
> I'm curious, why not having both?
>
> 1) A CI tool to ease things
> 2) To continue to review releases as it's done now
>
> Jacques
>
> Le 30/05/2014 14:22, Jim Jagielski a ?crit :
> >The Board expects the PMC to do its job, and the
> >Board expects the PMC Chair to do his/her job.
> >
> >If they don't, the board acts; and, as has been said
> >many times, the board is not a surgical scalpel; it
> >is a hammer.
> >
> >On May 30, 2014, at 8:09 AM, Emmanuel L?charny <el...@gmail.com> wrote:
> >
> >>Le 29/05/2014 17:47, Jim Jagielski a ?crit :
> >>>On May 29, 2014, at 11:28 AM, Emmanuel L?charny <el...@gmail.com>
> >>>wrote:
> >>>
> >>>>Le 29/05/2014 15:56, Jim Jagielski a ?crit :
> >>>>>I disagree. And until the policy is changed, PMCs and
> >>>>>RMs are expected and *required* to comply.
> >>>>Yes, but actually, most f the PMCs and RMs *aren't* Like it or not.
> >>>>
> >>>>...
> >>>>And, yes, it's probably a good idea to fix the policy if it can't be
> >>>>enforced.
> >>>>
> >>>To be clear: If it is found out that there are "releases" out
> >>>there that really aren't releases, the board will tell the
> >>>PMC to:
> >>>
> >>> 1: Remove those releases immediately.
> >>> 2: Re-release those "releases" as real releases
> >>> by complying w/ the release policy (basically,
> >>> taking those "releases" and doing the required
> >>> vetting and voting).
> >>>
> >>>The board can, and will, also remove a PMCs ability
> >>>to "release" stuff if it refuses to comply with the
> >>>release policy. So it can be enforced. It is being
> >>>enforced. It will be enforced.
> >>This is not an enforcement. This is a punishment. And it's totally vain.
> >>
> >>Unless the board is ready to check all the releases for all the 151
> >>projects, and verify that *every* PMC member is eventually going through
> >>the whole process, this is just a void statement.
> >>
> >>Btw, just tell me how you are going to control that ? I'm curious...
> >>OTOH, we van make it easier for the PMC members to cast a vote, by
> >>verifying the output of a documented/replayable process, which will take
> >>a few minutes instead of hours in some cases. How possibly can someone
> >>object that it would be a progress ?
> >>
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >>For additional commands, e-mail: legal-discuss-help@apache.org
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >For additional commands, e-mail: legal-discuss-help@apache.org
> >
> >
> >
>
> --
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
--
===========================================================================
Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"Great is the guilt of an unnecessary war" ~ John Adams
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 30/05/2014 15:04, Jacques Le Roux a écrit :
> I'm curious, why not having both?
>
> 1) A CI tool to ease things
> 2) To continue to review releases as it's done now
The question is : what will be the release process if we have (1). I
just think that it will just require less error prone manual checks than
if we do it without (1).
It's out of question that PMC members *must* check the output of (1)
before casting a vote.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Jacques Le Roux <ja...@les7arts.com>.
I'm curious, why not having both?
1) A CI tool to ease things
2) To continue to review releases as it's done now
Jacques
Le 30/05/2014 14:22, Jim Jagielski a écrit :
> The Board expects the PMC to do its job, and the
> Board expects the PMC Chair to do his/her job.
>
> If they don't, the board acts; and, as has been said
> many times, the board is not a surgical scalpel; it
> is a hammer.
>
> On May 30, 2014, at 8:09 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
>
>> Le 29/05/2014 17:47, Jim Jagielski a écrit :
>>> On May 29, 2014, at 11:28 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
>>>
>>>> Le 29/05/2014 15:56, Jim Jagielski a écrit :
>>>>> I disagree. And until the policy is changed, PMCs and
>>>>> RMs are expected and *required* to comply.
>>>> Yes, but actually, most f the PMCs and RMs *aren't* Like it or not.
>>>>
>>>> ...
>>>> And, yes, it's probably a good idea to fix the policy if it can't be
>>>> enforced.
>>>>
>>> To be clear: If it is found out that there are "releases" out
>>> there that really aren't releases, the board will tell the
>>> PMC to:
>>>
>>> 1: Remove those releases immediately.
>>> 2: Re-release those "releases" as real releases
>>> by complying w/ the release policy (basically,
>>> taking those "releases" and doing the required
>>> vetting and voting).
>>>
>>> The board can, and will, also remove a PMCs ability
>>> to "release" stuff if it refuses to comply with the
>>> release policy. So it can be enforced. It is being
>>> enforced. It will be enforced.
>> This is not an enforcement. This is a punishment. And it's totally vain.
>>
>> Unless the board is ready to check all the releases for all the 151
>> projects, and verify that *every* PMC member is eventually going through
>> the whole process, this is just a void statement.
>>
>> Btw, just tell me how you are going to control that ? I'm curious...
>> OTOH, we van make it easier for the PMC members to cast a vote, by
>> verifying the output of a documented/replayable process, which will take
>> a few minutes instead of hours in some cases. How possibly can someone
>> object that it would be a progress ?
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
>
--
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 30/05/2014 14:22, Jim Jagielski a écrit :
> The Board expects the PMC to do its job,
Ok, so tell me how a PMC member, using the benefit of a CI job that
checks many things he/she otherwise would have to do by a very error
prone process (ie, by hand) would be detrimental to this mandatory step ?
This is the crux of the discussion, we are not trying to say that PMC
members aren't doing their job, or that they should not do their job.
Nevertheless, I claim that the board has *no way* to know if a release
have been validated by people taking a chance that the RM has done all
the check already...
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Jim Jagielski <ji...@jaguNET.com>.
The Board expects the PMC to do its job, and the
Board expects the PMC Chair to do his/her job.
If they don't, the board acts; and, as has been said
many times, the board is not a surgical scalpel; it
is a hammer.
On May 30, 2014, at 8:09 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
> Le 29/05/2014 17:47, Jim Jagielski a écrit :
>> On May 29, 2014, at 11:28 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
>>
>>> Le 29/05/2014 15:56, Jim Jagielski a écrit :
>>>> I disagree. And until the policy is changed, PMCs and
>>>> RMs are expected and *required* to comply.
>>> Yes, but actually, most f the PMCs and RMs *aren't* Like it or not.
>>>
>>> ...
>>> And, yes, it's probably a good idea to fix the policy if it can't be
>>> enforced.
>>>
>> To be clear: If it is found out that there are "releases" out
>> there that really aren't releases, the board will tell the
>> PMC to:
>>
>> 1: Remove those releases immediately.
>> 2: Re-release those "releases" as real releases
>> by complying w/ the release policy (basically,
>> taking those "releases" and doing the required
>> vetting and voting).
>>
>> The board can, and will, also remove a PMCs ability
>> to "release" stuff if it refuses to comply with the
>> release policy. So it can be enforced. It is being
>> enforced. It will be enforced.
>
> This is not an enforcement. This is a punishment. And it's totally vain.
>
> Unless the board is ready to check all the releases for all the 151
> projects, and verify that *every* PMC member is eventually going through
> the whole process, this is just a void statement.
>
> Btw, just tell me how you are going to control that ? I'm curious...
> OTOH, we van make it easier for the PMC members to cast a vote, by
> verifying the output of a documented/replayable process, which will take
> a few minutes instead of hours in some cases. How possibly can someone
> object that it would be a progress ?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 29/05/2014 17:47, Jim Jagielski a écrit :
> On May 29, 2014, at 11:28 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
>
>> Le 29/05/2014 15:56, Jim Jagielski a écrit :
>>> I disagree. And until the policy is changed, PMCs and
>>> RMs are expected and *required* to comply.
>> Yes, but actually, most f the PMCs and RMs *aren't* Like it or not.
>>
>> ...
>> And, yes, it's probably a good idea to fix the policy if it can't be
>> enforced.
>>
> To be clear: If it is found out that there are "releases" out
> there that really aren't releases, the board will tell the
> PMC to:
>
> 1: Remove those releases immediately.
> 2: Re-release those "releases" as real releases
> by complying w/ the release policy (basically,
> taking those "releases" and doing the required
> vetting and voting).
>
> The board can, and will, also remove a PMCs ability
> to "release" stuff if it refuses to comply with the
> release policy. So it can be enforced. It is being
> enforced. It will be enforced.
This is not an enforcement. This is a punishment. And it's totally vain.
Unless the board is ready to check all the releases for all the 151
projects, and verify that *every* PMC member is eventually going through
the whole process, this is just a void statement.
Btw, just tell me how you are going to control that ? I'm curious...
OTOH, we van make it easier for the PMC members to cast a vote, by
verifying the output of a documented/replayable process, which will take
a few minutes instead of hours in some cases. How possibly can someone
object that it would be a progress ?
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Jim Jagielski <ji...@jaguNET.com>.
On May 29, 2014, at 11:28 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
> Le 29/05/2014 15:56, Jim Jagielski a écrit :
>> I disagree. And until the policy is changed, PMCs and
>> RMs are expected and *required* to comply.
>
> Yes, but actually, most f the PMCs and RMs *aren't* Like it or not.
>
> ...
> And, yes, it's probably a good idea to fix the policy if it can't be
> enforced.
>
To be clear: If it is found out that there are "releases" out
there that really aren't releases, the board will tell the
PMC to:
1: Remove those releases immediately.
2: Re-release those "releases" as real releases
by complying w/ the release policy (basically,
taking those "releases" and doing the required
vetting and voting).
The board can, and will, also remove a PMCs ability
to "release" stuff if it refuses to comply with the
release policy. So it can be enforced. It is being
enforced. It will be enforced.
AND All PMC chairs are expected to take this seriously.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 29/05/2014 15:56, Jim Jagielski a écrit :
> I disagree. And until the policy is changed, PMCs and
> RMs are expected and *required* to comply.
Yes, but actually, most f the PMCs and RMs *aren't* Like it or not.
Many times, shoudl I say most of the time, I saw that *if* I do check
for a new release I didn't cut, then almost nobody has chekced anything.
They are just expecting that everything has already been double checked
either by the RM or by another PMC member.
So, yeah, I agree with you, the check must be done. But facing reality,
I do think that a validated automatic process run by a CI is
asymptotically closer to 100% better than what we do now.
And, yes, it's probably a good idea to fix the policy if it can't be
enforced.
PS/ I'm *not* pleased by the fact that people aren't checking the
release, btw. And in absence of a CI, I do have my own scripts on my
machine to do that on the few projects I'm working on. Strange enough,
those scripts could perfectly well be ran by a CI, on my machine. Now,
how different is it to what Jukka is proposing ?
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Jim Jagielski <ji...@jaguNET.com>.
I disagree. And until the policy is changed, PMCs and
RMs are expected and *required* to comply.
On May 29, 2014, at 9:43 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
> Le 29/05/2014 13:50, Jim Jagielski a écrit :
>> On May 28, 2014, at 2:41 PM, Jukka Zitting <ju...@gmail.com> wrote:
>>
>>> For example, do we really need for everyone to download, compile and
>>> test the code before casting a +1, when a CI server can do this just
>>> as well if not better.
>> Yes. Yes we do.
>
> Jim, you can pound your head in the sand, expecting that every release
> *is* downladed, compiled, tested by every PMC member casting a +1, or
> acccept the idea that, yes, a well designed and validated CI build could
> be a valid substitute for a human error prone/lazzy prone process (ie,
> I'm 100% sure that most of the voters aren't following this process)
> (and I'm quite sure that this is one of the reason we are using
> computers, all in all).
>
> Or you can *think* about what you are saying, and realize that it's
> plain pseudo-legal nonsense.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 29/05/2014 13:50, Jim Jagielski a écrit :
> On May 28, 2014, at 2:41 PM, Jukka Zitting <ju...@gmail.com> wrote:
>
>> For example, do we really need for everyone to download, compile and
>> test the code before casting a +1, when a CI server can do this just
>> as well if not better.
> Yes. Yes we do.
Jim, you can pound your head in the sand, expecting that every release
*is* downladed, compiled, tested by every PMC member casting a +1, or
acccept the idea that, yes, a well designed and validated CI build could
be a valid substitute for a human error prone/lazzy prone process (ie,
I'm 100% sure that most of the voters aren't following this process)
(and I'm quite sure that this is one of the reason we are using
computers, all in all).
Or you can *think* about what you are saying, and realize that it's
plain pseudo-legal nonsense.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Jim Jagielski <ji...@jaguNET.com>.
On May 28, 2014, at 2:41 PM, Jukka Zitting <ju...@gmail.com> wrote:
>
> For example, do we really need for everyone to download, compile and
> test the code before casting a +1, when a CI server can do this just
> as well if not better.
Yes. Yes we do.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, May 28, 2014 at 1:24 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> Sure, and of course I'm sure there are places where
> some stuff can be automated. But it seems to me that
> most people are chaffing against the "3 +1 votes" and
> the "72 hour" rules...
My point here isn't that much about those specific mechanics of the
release vote, but rather the listed requirements for casting the +1
vote.
For example, do we really need for everyone to download, compile and
test the code before casting a +1, when a CI server can do this just
as well if not better. Could those requirements for the +1 be met by
simply checking whether the relevant CI build (run on the specific
release candidate) is green?
And more importantly, instead of separately reviewing the release
candidate for policy compliance, would following a documented process
that ensures the compliance of each committed revision leading to the
release be sufficient to address the needs of the foundation?
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Jim Jagielski <ji...@jaguNET.com>.
On May 28, 2014, at 1:16 PM, Alex Harui <ah...@adobe.com> wrote:
>
> What I think several of us want to explore is whether the current release
> policy/process can be automated in places and still be serious about it.
>
Sure, and of course I'm sure there are places where
some stuff can be automated. But it seems to me that
most people are chaffing against the "3 +1 votes" and
the "72 hour" rules... We need to recall that creating
a release != actually releasing the release, as well :)
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Alex Harui <ah...@adobe.com>.
On 5/28/14 9:56 AM, "Jim Jagielski" <ji...@jaguNET.com> wrote:
>Let's look at it this way... We need to recall that the ASF
>is a legal entity, a Delaware corporation with 501(c)3
>classification. We are also a *significant* player, resource
>and source in the IT eco-system.
>
>People want to play as if we were selling our
>kitchen made cookies at a yard sale; we just bake 'em,
>sell em, put the money in an old cigar box and
>basically just take it all easy and relaxed. Instead,
>we are more like Nabisco selling Nutter Butters
>(ignore any implication of quality, etc in this
>"analogy")... This is serious stuff we are doing,
>stuff that people take seriously, stuff that
>interests the IRS, the gov't, "partners", etc...
I get that there is a difference between potlucks and manufactured food.
What I think several of us want to explore is whether the current release
policy/process can be automated in places and still be serious about it.
For example, I bought some real estate last year, which I consider a
serious process, and was pleasantly surprised to see that some of the
paperwork could be digitally signed via web apps (but the final closing
document required traditional signing). That was quite different that
when I last bought real estate merely 5 years ago. Back then, it was all
paper and faxing and couriers.
And several of us are pushing on this topic because, I'm pretty sure that
any bank that still requires all paper and faxing and couriers is finding
itself at a competitive disadvantage against the banks that allow digital
signing.
So the question I have is: where can we use the differences in technology
over the past five years to save us time in the release process without
sacrificing being "serious". I would offer that at least a couple of
things have changed:
1) smartphones make email available to many people virtually 24/7,
eliminating some of the reason for waiting 72 hours to close votes
2) CI servers and automated testing frameworks and security software has
evolved to the point where you can safely and securely create valid
artifacts without human intervention.
Thoughts?
-Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Jim Jagielski <ji...@jaguNET.com>.
Let's look at it this way... We need to recall that the ASF
is a legal entity, a Delaware corporation with 501(c)3
classification. We are also a *significant* player, resource
and source in the IT eco-system.
People want to play as if we were selling our
kitchen made cookies at a yard sale; we just bake 'em,
sell em, put the money in an old cigar box and
basically just take it all easy and relaxed. Instead,
we are more like Nabisco selling Nutter Butters
(ignore any implication of quality, etc in this
"analogy")... This is serious stuff we are doing,
stuff that people take seriously, stuff that
interests the IRS, the gov't, "partners", etc...
What protects us, the foundation, the PMC, etc is
the fact that we have a defined process of a release,
and a track record of following it.
I like my house. I like my car. I like knowing that
I can continue both my coding and non-coding involvement
w/ Apache because I am awarded some legal protection
by following those "silly" and "ceremonial" rules.
Believe me, when a lawyer or the FBI come knocking
on your door, simply saying "Hey, I'm just hacking
around for fun" or "I think those rules were stupid
so I just ignored them" will hardly get you out of
a jam.
On May 28, 2014, at 11:56 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> On May 28, 2014, at 11:32 AM, Jukka Zitting <ju...@gmail.com> wrote:
>>
>> The reason behind my tweet is a worry about the overall direction of
>> the discussion that seems to end up treating a release as a
>> bureaucratic act guarded by high ceremony.
>
> You are right. It is, in fact, a legal act guarded by
> responsible oversight. I think that many people realize
> that, but agree that many people are throwing FUD around
> for who-knows-why reasons.
>
> Any discussion which ignores that is doomed to failure.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Jim Jagielski <ji...@jaguNET.com>.
On May 28, 2014, at 11:32 AM, Jukka Zitting <ju...@gmail.com> wrote:
>
> The reason behind my tweet is a worry about the overall direction of
> the discussion that seems to end up treating a release as a
> bureaucratic act guarded by high ceremony.
You are right. It is, in fact, a legal act guarded by
responsible oversight. I think that many people realize
that, but agree that many people are throwing FUD around
for who-knows-why reasons.
Any discussion which ignores that is doomed to failure.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Chris Mattmann <ma...@apache.org>.
So, I got about halfway through this thread and I was about to
stop reading and type a reply to the effect of:
"why wait for the release to make sure b) is done?"
And then..you beat me to it.
+1 for being ready, during each and every commit, to release.
That's what we have version control for to go back and look
through and verify this type of thing, and this is one of
the purposes of a PMC. Use automated tooling as much and
wherever possible to take care of everything else and then
amortize the grand cost of b) (and I agree it's grand) over
time by doing it continuously, and with those human beings
around you.
My 2c.
Cheers,
Chris
-----Original Message-----
From: Jukka Zitting <ju...@gmail.com>
Reply-To: "legal-discuss@apache.org" <le...@apache.org>
Date: Wednesday, May 28, 2014 8:32 AM
To: Legal Discuss <le...@apache.org>
Subject: Continuous release review
>Hi,
>
>It looks like my recent tweet [1] is making more waves than I
>expected, so I guess I should expand on it here instead of getting
>caught up on too many private debates. I hope to avoid conflicting too
>much with Marvin and others in the effort to clarify existing release
>policy; as he pointed out, this should be considered a separate
>discussion.
>
>The reason behind my tweet is a worry about the overall direction of
>the discussion that seems to end up treating a release as a
>bureaucratic act guarded by high ceremony. For example, breaking down
>the review requirements from the recent draft [2], we have:
>
> Before casting +1 binding votes, individuals are REQUIRED to
> a) download all signed source code packages onto their own hardware,
> b) verify that they meet all requirements of ASF policy on
> releases as described below,
> c) validate all cryptographic signatures,
> d) compile as provided, and
> e) test the result on their own platform.
>
>Steps a, c, d and e are all things that would arguably be better and
>more reliably done by a CI server. In Jackrabbit we use a release
>checker script for these steps (see [3]), and our CI builds already do
>steps a, d and e for each individual commit.
>
>Step b is a complex task that, if done properly, would take hours or
>days to complete if you don't take previous reviews into account. In
>practice it makes more sense to consider only what changed since the
>last reviewed release and see whether the policy implications (LICENSE
>updates, etc.) of any of the changes have been implemented. Even
>better if such policy implications are addressed directly in the same
>commit that introduces the relevant chance (we try to do this in
>Jackrabbit).
>
>In summary all of the steps (apart from c which in any case is easy to
>automate) can and in many ways should be done already for each commit
>instead of just during the release vote.
>
>Thus I question the focus we're putting on the release as the point
>where all this review is supposed happens. Instead I'd rather see this
>becoming more of an ongoing task to be done at the level of each
>commit or push, with the release review more just a final confirmation
>that such a process has been followed. Something like that would help
>relax the somewhat awkward rules we now have on restricting access to
>unreleased stuff. If everything we had was always ready for release,
>such rules wouldn't be needed and it would be much easier for projects
>to release early and often.
>
>This idea has been raised in different forms by others on a few
>occasions already earlier, but with all the focus on the existing
>release policy and the associated ceremony it seems like many are
>missing the point of the argument. I hope this post helps frame the
>idea a bit better.
>
>[1] https://twitter.com/jukkaz/status/471304315412705280
>[2]
>https://github.com/rectang/asfrelease/blob/6ad23f6909ccbe71080e4b6c36c5552
>f863e829f/release.md
>[3] https://dist.apache.org/repos/dist/dev/jackrabbit/check-release.sh
>
>BR,
>
>Jukka Zitting
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Ross Gardler <rg...@opendirective.com>.
+1
I made this same point in the discussion about what is required. Marvin
made the valid observation that he doesn't want to get bogged down in
policy changes while trying to clarify what the existing policy is. He
Didn't explicitly say it but I believe his intention is to separate the two
discussions - what is current policy and what should the policy be.
As I have stated elsewhere I have always believed the right thing is
to (and always asked podling to) review on an ongoing basis and only vote
+1 if you have conducted the agreed checks with legal review being the most
important.
I agree that checking the NOTICE files etc. is easier if you work with
diffs.
For me, voting +1 on a release is no more than an hour or two review. I
don't work full time on any one project so I know I will have missed some
commits along the way.
If I were working on code daily (and thus reviewing every commit) then that
time would drop to 15 minutes or so (around 1-2 hours for the PMC per
release).
We do not require every volunteer to review every commit. We should require
our volunteers to do proper reviews before voting +1 on a release. A proper
review should not include meaningless steps that can be automated.
Ross
On 28 May 2014 08:32, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> It looks like my recent tweet [1] is making more waves than I
> expected, so I guess I should expand on it here instead of getting
> caught up on too many private debates. I hope to avoid conflicting too
> much with Marvin and others in the effort to clarify existing release
> policy; as he pointed out, this should be considered a separate
> discussion.
>
> The reason behind my tweet is a worry about the overall direction of
> the discussion that seems to end up treating a release as a
> bureaucratic act guarded by high ceremony. For example, breaking down
> the review requirements from the recent draft [2], we have:
>
> Before casting +1 binding votes, individuals are REQUIRED to
> a) download all signed source code packages onto their own hardware,
> b) verify that they meet all requirements of ASF policy on
> releases as described below,
> c) validate all cryptographic signatures,
> d) compile as provided, and
> e) test the result on their own platform.
>
> Steps a, c, d and e are all things that would arguably be better and
> more reliably done by a CI server. In Jackrabbit we use a release
> checker script for these steps (see [3]), and our CI builds already do
> steps a, d and e for each individual commit.
>
> Step b is a complex task that, if done properly, would take hours or
> days to complete if you don't take previous reviews into account. In
> practice it makes more sense to consider only what changed since the
> last reviewed release and see whether the policy implications (LICENSE
> updates, etc.) of any of the changes have been implemented. Even
> better if such policy implications are addressed directly in the same
> commit that introduces the relevant chance (we try to do this in
> Jackrabbit).
>
> In summary all of the steps (apart from c which in any case is easy to
> automate) can and in many ways should be done already for each commit
> instead of just during the release vote.
>
> Thus I question the focus we're putting on the release as the point
> where all this review is supposed happens. Instead I'd rather see this
> becoming more of an ongoing task to be done at the level of each
> commit or push, with the release review more just a final confirmation
> that such a process has been followed. Something like that would help
> relax the somewhat awkward rules we now have on restricting access to
> unreleased stuff. If everything we had was always ready for release,
> such rules wouldn't be needed and it would be much easier for projects
> to release early and often.
>
> This idea has been raised in different forms by others on a few
> occasions already earlier, but with all the focus on the existing
> release policy and the associated ceremony it seems like many are
> missing the point of the argument. I hope this post helps frame the
> idea a bit better.
>
> [1] https://twitter.com/jukkaz/status/471304315412705280
> [2]
> https://github.com/rectang/asfrelease/blob/6ad23f6909ccbe71080e4b6c36c5552f863e829f/release.md
> [3] https://dist.apache.org/repos/dist/dev/jackrabbit/check-release.sh
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: Continuous release review
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 30/05/2014 16:32, Jukka Zitting a écrit :
> Hi,
>
> Let me try to refocus this discussion.
>
> First of all, I'm not trying to argue that projects should be free to
> ignore or replace parts of existing policy, they shouldn't. Instead
> I'm looking for ways to *change* the policy to enable new ways to make
> releases.
+1
>
> Second, I think we all agree that underlying goals (legal, social,
> technical, etc.) of the current policy are sound and shouldn't be
> abandoned. I only question the specific mechanisms we currently use to
> meet those goals. If there are alternative ways of meeting the same
> goals, shouldn't we consider adjusting the policy to allow such
> mechanisms if projects would like to use them?
+1
>
> Finally, I believe there's an opening for us to allow radically new
> ways of cutting releases without abandoning any of those goals. I'll
> explain:
>
> On Wed, May 28, 2014 at 11:32 AM, Jukka Zitting <ju...@gmail.com> wrote:
>> Thus I question the focus we're putting on the release as the point
>> where all this review is supposed happens. Instead I'd rather see this
>> becoming more of an ongoing task to be done at the level of each
>> commit or push, with the release review more just a final confirmation
>> that such a process has been followed.
> For the sake of the argument, assume that a project adopts a strict
> RTC policy where each commit is reviewed and voted on not just for
> it's technical content but also as if a new release was cut from that
> point. An audit trail of the review results and all votes cast are
> stored in each commit message. The project would then, after reaching
> consensus that it's time to release, just tag the release and have a
> build server take care of automatically verifying the audit trail and
> then packaging, signing, building, testing and deploying the release.
> There would be no manual review of the release package itself and no
> need for the "72 hours" or "3 +1s" rules, as all those things would
> already have been taken care of earlier in the process.
>
> Or as a simpler alternative, assume a project that identifies a
> specific revision as a release candidate and runs a normal release
> review and vote against that revision instead of a pre-built release
> candidate. If the vote passes, the revision would be tagged and a
> build server would again take care of verifying the vote results and
> then packaging, signing, building, testing and deploying the release.
> Such a process could even produce "official" binary packages, as there
> would be no need to double-guess what actually went into building
> those packages.
+1
>
> How would such imaginary processes produce releases that are any worse
> than those governed by current policy? Are there any legal, social or
> other aspects that such processes would fail to address as well as we
> now do?
I let other respond to that question. My answer is : it's likely that
another process (like our current one) will (is) produce (ing) worse
release.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Jun 2, 2014 at 1:25 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> ...My point is that automatically rubber stamping anything
> with a +1 is dangerous, and bypasses and "ignores" the
> social aspect (and social health check of doing a release)
> that forms a basis of how the ASF produces (and releases)
> s/w....
I agree with that, and my understanding of Jukka's examples is that a
PMC member's +1 might be the result of them watching the codebase
evolve continuously, which makes them consider the successful CI build
as just the final touch that allows them to cast their +1 vote.
So as you say what's important is that the +1 is the result of an
active validation of the codebase. Exactly how that validation occurs
is irrelevant, at some point we have to trust the PMC member that they
did their homework before voting, but exactly what that means depends
on how the project operates.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Stephen Connolly <st...@gmail.com>.
On Monday, 2 June 2014, Jim Jagielski <ji...@jagunet.com> wrote:
>
> On Jun 2, 2014, at 7:41 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com <javascript:;>> wrote:
>
> >
> >
> > On Monday, 2 June 2014, Jim Jagielski <jim@jagunet.com <javascript:;>>
> wrote:
> >
> > On Jun 2, 2014, at 4:34 AM, Bertrand Delacretaz <bdelacretaz@apache.org
> <javascript:;>> wrote:
> > > 4) The PMC votes to make the release an act of the foundation
> > > 5) All PMC members are given a fair chance to take part in release
> votes
> > >
> >
> > These 2 are the only ones which, it appears, are
> > the current topic of discussion. For #5 is issue seems
> > to be the reasoning behind the 72 hour rule.
> >
> > #4 is the "main" issue, as I see it. And it appears that
> > I must be making myself especially unclear or else
> > my position is being (deliberately) misinterpreted.
> >
> > Well you were the one, IIRC, that said PMC members must/should (not sure
> which but definitely not could) "download, build and test"...
> >
>
> Here are my quotes:
>
> People perform releases. They can use whatever tools
> they want, but at the end, the only validation check
> that really matters are those PMC members who test,
> validate and +1 the release.
>
> You may be referring to:
>
> >
> >
> > For example, do we really need for everyone to download, compile and
> > test the code before casting a +1, when a CI server can do this just
> > as well if not better.
>
> Yes. Yes we do.
>
> Note that this was in response to the concept of "rubber
> stamping" a release, the idea being that anything out
> of a CI is already assumed to be +1 worthy.
>
> So tell me, assuming that you also agree w/ the idea
> that an artifact out of a CI should not be blindly rubber-
> stamped w/ a +1, what process would you go through to
> convince you, for yourself, that it is ready for release?
>
> Again, we vote on a release artifact.
Well let's take https://builds.apache.org/job/maven-3.2-release-status/
as a concrete example.
If the git commit hash that job chain built gets a full compliment of
promotion badges then I am happy to trust that the integration tests pass,
so I would verify that the source bundle corresponds to the hash and vote
+1 on the artifacts in the staging repository on nexus.
I would not feel the need to build or test locally.
I would probably take the binary artifact and test locally on a smoke
project just to prevent egg on face eg if an ugly stack trace is shown or
debug logging was left enabled such things can slip through automated tests
and require an actual person to check.
I do not care *how* the release manager built the binaries: on their own
machine or on a CI server. I do care that the artifacts I vote on meet the
criteria
---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> <javascript:;>
> For additional commands, e-mail: legal-discuss-help@apache.org
> <javascript:;>
>
>
--
Sent from my phone
Re: Continuous release review
Posted by Stephen Connolly <st...@gmail.com>.
On 2 June 2014 16:18, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Mon, Jun 2, 2014 at 10:19 AM, Stephen Connolly
> <st...@gmail.com> wrote:
> > On Monday, 2 June 2014, Jukka Zitting <ju...@gmail.com> wrote:
> >> My argument is that at least in some cases it would be better to
> >> review and vote on the sources that go into the release than the
> >> artifact itself. It would be nice if we could find a way to adapt the
> >> policy to allow also such a release process.
> >
> > We vote on the source bundle and only the source bundle as I understand
> > things. Convenience binaries are something separate unless I am
> mistaken...
>
> My point is *not* about convenience binaries (they might benefit as a
> side-effect, but that's not the main point here).
>
> For example, if you review and vote on releasing a specific revision
> in the SCM, what's the added benefit of repeating the process on the
> source bundle produced from that revision?
>
None to my mind. What we should be doing as PMC members with binding votes
in such a situation is verifying that the source bundle matches the SCM(s)
from which it was built
Note: it could be SCMs... you might have bits split across git and svn...
you may have some bits that are pulled from a .zip file and extracted to
generate the source bundle... that zip file may well be stored in a
write-once artifact store... obviously the more complex you make the SCM(s)
that you release from... the more work the PMC has to do to verify, so that
should generate back pressure... but we should not mandate that everything
is in a single SCM.
>
> > If that context is correct then the benefit of a CI server is just wrt
> > testing across multiple platforms.
>
> In addition to the "download, build, test" verification, a build
> server could remove the manual steps of packaging, signing and
> deploying a release. Besides speeding up the process, such a release
> build would significantly reduce the risk of mistakes inherent in
> doing these steps manually. I've seen (and made) mistakes in all of
> these steps.
>
Yes but nothing in the current "state of play" prevents you - as RM - from
setting up your own CI server and automating all that stuff so that it is
easer for *you* to cut those releases. To date I believe the real issue is
that we cannot cut releases from ASF hardware because that would mean
either trusting your GPG key to the ASF hardware or giving the ASF hardware
its own key (which has risks associated with it too)
When I get time to write some fancier Jenkins plugins (my backlog is up the
9's ATM) one of those will be a plugin that allows users to provide their
GPG credentials *one-time* to Jenkins for a specific build job only... I
suspect this would be via GPG agent. That will enable the release manager
to sign a release cut from the CI server on ASF hardware without leaving
their GPG key on the ASF hardware...
I'll probably also see about writing a nexus plugin that allows people to
add their signatures to a staging repo so that the Maven repo can
accumulate the signatures of all of the PMC that voted for the artifacts
However these are all asides.
You are correct that removing the pain points of actually cutting the
release is a benefit of a CI server... my point, however, is that you can
realise those benefits right now... just not on ASF hardware... and the
reasons for that are different from the release process... at least as I
understand things.
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: Continuous release review
Posted by Stephen Connolly <st...@gmail.com>.
On 3 June 2014 11:52, Emmanuel Lécharny <el...@gmail.com> wrote:
> Le 03/06/2014 11:56, Stephen Connolly a écrit :
> > On 3 June 2014 08:55, Emmanuel Lécharny <el...@gmail.com> wrote:
> >
> >>
> >>> This is why I believe that RC votes need to include the SCM tags (and
> >>> hashes/revisions) to clearly associate them with the release artifacts
> >>> and the votes. That way the history of the review is preserved in the
> >>> archives.
> >> +1
> >>
> > Well how does that work if there is an SCM migration?
> >
> > Suppose the ASF decided to move *all* projects from SVN to GIT?
>
> Hopefully, we don't destroy the previous repos when we do the migration.
>
> For instance, MINA has migrated to GIT 16 months ago, but you can still
> pull an old tag from SVN :
>
> http://svn.apache.org/viewvc/mina/
>
>
And that works because there are some projects who are quite happy with SVN
and we use one big subversion repo... but if there was a foundation
mandated migration then the SVN server could well cease to exist and your
tags would be very much like the dodo... (similarly *if* we had used the
one subversion repo per project model then your old repo could very well
have ceased to exist a couple of months after your migration completed.)
Do I think this scenario is likely?
Not really.
Do I think the scenario being unlikely means we can ignore it when drafting
a release *policy* for the ASF?
I think we cannot ignore it when drafting an ASF wide *policy*. Our policy
should be principle based. Mandating a specific way of meeting those
principles will force us to modify the policy as technology changes.
The simple fact that it is easier to verify provenance of files if they all
come from a precisely defined single revision in source control is
sufficient pressure to get projects verifying their source bundles against
source control. We should not mandate a specific technical means to an end.
Policy should reflect the desired end state and not enforce any specific
path to that end state
So to my mind:
* Policy should not dictate 72h minimum for votes. The board can issue
guidance to the effect that 72h minimum votes are presumed to have taken
into account the need for community inclusion. If a project wants to run
shorter votes they would then need to demonstrate how their shorter vote
period preserves the values we wish to retain such as community
inclusiveness
* Policy should not dictate how PMC members decide to vote on a release. It
can state minimum criteria for a +1 vote. The board could issue guidance on
some pre-vetted processes. If a project wants to deviate from one of those
pre-vetted processes they would need to demonstrate how their alternative
process meets the policy requirements.
* etc
At least the above fits with how I see the core principles of the ASF,
namely let projects find their own solutions so that we can innovate.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: Continuous release review
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 03/06/2014 11:56, Stephen Connolly a écrit :
> On 3 June 2014 08:55, Emmanuel Lécharny <el...@gmail.com> wrote:
>
>>
>>> This is why I believe that RC votes need to include the SCM tags (and
>>> hashes/revisions) to clearly associate them with the release artifacts
>>> and the votes. That way the history of the review is preserved in the
>>> archives.
>> +1
>>
> Well how does that work if there is an SCM migration?
>
> Suppose the ASF decided to move *all* projects from SVN to GIT?
Hopefully, we don't destroy the previous repos when we do the migration.
For instance, MINA has migrated to GIT 16 months ago, but you can still
pull an old tag from SVN :
http://svn.apache.org/viewvc/mina/
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Stephen Connolly <st...@gmail.com>.
On 3 June 2014 08:55, Emmanuel Lécharny <el...@gmail.com> wrote:
> Le 03/06/2014 01:58, sebb a écrit :
> > On 2 June 2014 21:51, Emmanuel Lécharny <el...@gmail.com> wrote:
> >> Le 02/06/2014 22:37, Jukka Zitting a écrit :
> >>> Hi,
> >>>
> >>> On Mon, Jun 2, 2014 at 12:43 PM, Emmanuel Lécharny <
> elecharny@gmail.com> wrote:
> >>>> Le 02/06/2014 17:18, Jukka Zitting a écrit :
> >>>>> For example, if you review and vote on releasing a specific revision
> >>>>> in the SCM, what's the added benefit of repeating the process on the
> >>>>> source bundle produced from that revision?
> >>>> AFAIU, there are two different things. As the bundle is produced by a
> >>>> automated tool (can be the maven packaging phase), the result can be
> >>>> *very* different from what we get when pulling the revision from the
> >>>> repository.
> >>> I personally don't see any compelling reasons why a source release
> >>> should be anything more than a packaged export of a tag, and some very
> >>> good reasons reasons (like the ability to verify that the sources
> >>> actually came from the scm) for why it should be just that. But I
> >>> recognize that others disagree.
> >> I don't disagree. The thing is that most of the Java projects are
> >> depending on Maven to generate the jar, which should be the same than
> >> what you get when doing a svn co/git clone followed by a tar cvf. Except
> >> that if you have made a mistake when configuring maven, you may and with
> >> a difference. Been there...
> > It's not only Maven config errors that can cause issues.
> > Maven creates the source archive from a local copy of the SCM, not
> > directly from the SCM tag.
> > This copy can be altered by the process of building the release -
> > additional files can be added, or files can be deleted.
> >
> > Note that Maven is not alone in this; any packaging procedure that
> > uses a local workspace can be subject to the same issues, especially
> > if the same workspace is used to build and test the release candidate.
> Absolutely.
> >
> >> Checking both should mitigate this risk.
> >>> Anyway, this doesn't affect my main premise. As long as there is a
> >>> deterministic process that produces the source bundle from a given scm
> >>> revision (or revisions) and the steps of verifying the correctness and
> >>> quality of that bundle can be automated (given the assumption that the
> >>> correctness and quality of original source has already been reviewed),
> >>> from the "policy invariant" perspective there should be little
> >>> difference in whether the manual review is done on the input or the
> >>> output of the process.
> >> +1
> >>
> > There needs to be a check that the source release contents is entirely
> > derived from the SCM input.
> > If these are the same, then I agree it does not matter which is
> > manually reviewed.
> Yes. We would need a tool to do that...
> >
> > There is another aspect of the using SCM tags or equivalent: I believe
> > that it should be possible to recreate the source release at any later
> > stage. One way to do this is to ensure that the source release is only
> > created from an immutable SCM 'tag'.
> Yes.
> > This is why I believe that RC votes need to include the SCM tags (and
> > hashes/revisions) to clearly associate them with the release artifacts
> > and the votes. That way the history of the review is preserved in the
> > archives.
> +1
>
Well how does that work if there is an SCM migration?
Suppose the ASF decided to move *all* projects from SVN to GIT?
All those peg revision tags in the email record are now useless...
Suppose then a while later the ASF decides to move all projects from GIT to
FooMachuWhizbang as it has a better data model for N-way merges or some
such thing...
Now not only are the SVN peg revisions useless, so are the git tag hashes.
We vote on the source bundles, so I agree that the source bundle hashes
should be required to be in the vote email record (I don't see the need to
mandate it in the VOTE, it could be that a PMC wants each PMC member to
specify the hash of what they are voting on, in which case the RE: VOTE
emails would have "+1 Hash")
But peg revisions or commit hashes are not guaranteed to have permanence...
so if you are arguing that they should be present FTR then we would need to
put some sort of persistence mechanism in place so that in the event of us
migrating to a different SCM then that information remains usable (this is
the same reason why we have s.apache.org as an URL shortener to my mind)
Just to clarify my point: It should not be ASF policy to *require* commit
hashes or tag peg revisions in vote emails... they are very useful to have,
but they should not be required by policy
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: Continuous release review
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 03/06/2014 01:58, sebb a écrit :
> On 2 June 2014 21:51, Emmanuel Lécharny <el...@gmail.com> wrote:
>> Le 02/06/2014 22:37, Jukka Zitting a écrit :
>>> Hi,
>>>
>>> On Mon, Jun 2, 2014 at 12:43 PM, Emmanuel Lécharny <el...@gmail.com> wrote:
>>>> Le 02/06/2014 17:18, Jukka Zitting a écrit :
>>>>> For example, if you review and vote on releasing a specific revision
>>>>> in the SCM, what's the added benefit of repeating the process on the
>>>>> source bundle produced from that revision?
>>>> AFAIU, there are two different things. As the bundle is produced by a
>>>> automated tool (can be the maven packaging phase), the result can be
>>>> *very* different from what we get when pulling the revision from the
>>>> repository.
>>> I personally don't see any compelling reasons why a source release
>>> should be anything more than a packaged export of a tag, and some very
>>> good reasons reasons (like the ability to verify that the sources
>>> actually came from the scm) for why it should be just that. But I
>>> recognize that others disagree.
>> I don't disagree. The thing is that most of the Java projects are
>> depending on Maven to generate the jar, which should be the same than
>> what you get when doing a svn co/git clone followed by a tar cvf. Except
>> that if you have made a mistake when configuring maven, you may and with
>> a difference. Been there...
> It's not only Maven config errors that can cause issues.
> Maven creates the source archive from a local copy of the SCM, not
> directly from the SCM tag.
> This copy can be altered by the process of building the release -
> additional files can be added, or files can be deleted.
>
> Note that Maven is not alone in this; any packaging procedure that
> uses a local workspace can be subject to the same issues, especially
> if the same workspace is used to build and test the release candidate.
Absolutely.
>
>> Checking both should mitigate this risk.
>>> Anyway, this doesn't affect my main premise. As long as there is a
>>> deterministic process that produces the source bundle from a given scm
>>> revision (or revisions) and the steps of verifying the correctness and
>>> quality of that bundle can be automated (given the assumption that the
>>> correctness and quality of original source has already been reviewed),
>>> from the "policy invariant" perspective there should be little
>>> difference in whether the manual review is done on the input or the
>>> output of the process.
>> +1
>>
> There needs to be a check that the source release contents is entirely
> derived from the SCM input.
> If these are the same, then I agree it does not matter which is
> manually reviewed.
Yes. We would need a tool to do that...
>
> There is another aspect of the using SCM tags or equivalent: I believe
> that it should be possible to recreate the source release at any later
> stage. One way to do this is to ensure that the source release is only
> created from an immutable SCM 'tag'.
Yes.
> This is why I believe that RC votes need to include the SCM tags (and
> hashes/revisions) to clearly associate them with the release artifacts
> and the votes. That way the history of the review is preserved in the
> archives.
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by sebb <se...@gmail.com>.
On 2 June 2014 21:51, Emmanuel Lécharny <el...@gmail.com> wrote:
> Le 02/06/2014 22:37, Jukka Zitting a écrit :
>> Hi,
>>
>> On Mon, Jun 2, 2014 at 12:43 PM, Emmanuel Lécharny <el...@gmail.com> wrote:
>>> Le 02/06/2014 17:18, Jukka Zitting a écrit :
>>>> For example, if you review and vote on releasing a specific revision
>>>> in the SCM, what's the added benefit of repeating the process on the
>>>> source bundle produced from that revision?
>>> AFAIU, there are two different things. As the bundle is produced by a
>>> automated tool (can be the maven packaging phase), the result can be
>>> *very* different from what we get when pulling the revision from the
>>> repository.
>> I personally don't see any compelling reasons why a source release
>> should be anything more than a packaged export of a tag, and some very
>> good reasons reasons (like the ability to verify that the sources
>> actually came from the scm) for why it should be just that. But I
>> recognize that others disagree.
> I don't disagree. The thing is that most of the Java projects are
> depending on Maven to generate the jar, which should be the same than
> what you get when doing a svn co/git clone followed by a tar cvf. Except
> that if you have made a mistake when configuring maven, you may and with
> a difference. Been there...
It's not only Maven config errors that can cause issues.
Maven creates the source archive from a local copy of the SCM, not
directly from the SCM tag.
This copy can be altered by the process of building the release -
additional files can be added, or files can be deleted.
Note that Maven is not alone in this; any packaging procedure that
uses a local workspace can be subject to the same issues, especially
if the same workspace is used to build and test the release candidate.
> Checking both should mitigate this risk.
>>
>> Anyway, this doesn't affect my main premise. As long as there is a
>> deterministic process that produces the source bundle from a given scm
>> revision (or revisions) and the steps of verifying the correctness and
>> quality of that bundle can be automated (given the assumption that the
>> correctness and quality of original source has already been reviewed),
>> from the "policy invariant" perspective there should be little
>> difference in whether the manual review is done on the input or the
>> output of the process.
> +1
>
There needs to be a check that the source release contents is entirely
derived from the SCM input.
If these are the same, then I agree it does not matter which is
manually reviewed.
There is another aspect of the using SCM tags or equivalent: I believe
that it should be possible to recreate the source release at any later
stage. One way to do this is to ensure that the source release is only
created from an immutable SCM 'tag'.
This is why I believe that RC votes need to include the SCM tags (and
hashes/revisions) to clearly associate them with the release artifacts
and the votes. That way the history of the review is preserved in the
archives.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 02/06/2014 22:37, Jukka Zitting a écrit :
> Hi,
>
> On Mon, Jun 2, 2014 at 12:43 PM, Emmanuel Lécharny <el...@gmail.com> wrote:
>> Le 02/06/2014 17:18, Jukka Zitting a écrit :
>>> For example, if you review and vote on releasing a specific revision
>>> in the SCM, what's the added benefit of repeating the process on the
>>> source bundle produced from that revision?
>> AFAIU, there are two different things. As the bundle is produced by a
>> automated tool (can be the maven packaging phase), the result can be
>> *very* different from what we get when pulling the revision from the
>> repository.
> I personally don't see any compelling reasons why a source release
> should be anything more than a packaged export of a tag, and some very
> good reasons reasons (like the ability to verify that the sources
> actually came from the scm) for why it should be just that. But I
> recognize that others disagree.
I don't disagree. The thing is that most of the Java projects are
depending on Maven to generate the jar, which should be the same than
what you get when doing a svn co/git clone followed by a tar cvf. Except
that if you have made a mistake when configuring maven, you may and with
a difference. Been there...
Checking both should mitigate this risk.
>
> Anyway, this doesn't affect my main premise. As long as there is a
> deterministic process that produces the source bundle from a given scm
> revision (or revisions) and the steps of verifying the correctness and
> quality of that bundle can be automated (given the assumption that the
> correctness and quality of original source has already been reviewed),
> from the "policy invariant" perspective there should be little
> difference in whether the manual review is done on the input or the
> output of the process.
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Mon, Jun 2, 2014 at 12:43 PM, Emmanuel Lécharny <el...@gmail.com> wrote:
> Le 02/06/2014 17:18, Jukka Zitting a écrit :
>> For example, if you review and vote on releasing a specific revision
>> in the SCM, what's the added benefit of repeating the process on the
>> source bundle produced from that revision?
> AFAIU, there are two different things. As the bundle is produced by a
> automated tool (can be the maven packaging phase), the result can be
> *very* different from what we get when pulling the revision from the
> repository.
I personally don't see any compelling reasons why a source release
should be anything more than a packaged export of a tag, and some very
good reasons reasons (like the ability to verify that the sources
actually came from the scm) for why it should be just that. But I
recognize that others disagree.
Anyway, this doesn't affect my main premise. As long as there is a
deterministic process that produces the source bundle from a given scm
revision (or revisions) and the steps of verifying the correctness and
quality of that bundle can be automated (given the assumption that the
correctness and quality of original source has already been reviewed),
from the "policy invariant" perspective there should be little
difference in whether the manual review is done on the input or the
output of the process.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 02/06/2014 17:18, Jukka Zitting a écrit :
> Hi,
>
> On Mon, Jun 2, 2014 at 10:19 AM, Stephen Connolly
> <st...@gmail.com> wrote:
>> On Monday, 2 June 2014, Jukka Zitting <ju...@gmail.com> wrote:
>>> My argument is that at least in some cases it would be better to
>>> review and vote on the sources that go into the release than the
>>> artifact itself. It would be nice if we could find a way to adapt the
>>> policy to allow also such a release process.
>> We vote on the source bundle and only the source bundle as I understand
>> things. Convenience binaries are something separate unless I am mistaken...
> My point is *not* about convenience binaries (they might benefit as a
> side-effect, but that's not the main point here).
>
> For example, if you review and vote on releasing a specific revision
> in the SCM, what's the added benefit of repeating the process on the
> source bundle produced from that revision?
AFAIU, there are two different things. As the bundle is produced by a
automated tool (can be the maven packaging phase), the result can be
*very* different from what we get when pulling the revision from the
repository.
I usually do :
- pull the source from repo, build, test
- fetch the package, untar, build, test
I already experienced some differences, until we get a stabilized
packaging phase.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Mon, Jun 2, 2014 at 10:19 AM, Stephen Connolly
<st...@gmail.com> wrote:
> On Monday, 2 June 2014, Jukka Zitting <ju...@gmail.com> wrote:
>> My argument is that at least in some cases it would be better to
>> review and vote on the sources that go into the release than the
>> artifact itself. It would be nice if we could find a way to adapt the
>> policy to allow also such a release process.
>
> We vote on the source bundle and only the source bundle as I understand
> things. Convenience binaries are something separate unless I am mistaken...
My point is *not* about convenience binaries (they might benefit as a
side-effect, but that's not the main point here).
For example, if you review and vote on releasing a specific revision
in the SCM, what's the added benefit of repeating the process on the
source bundle produced from that revision?
> If that context is correct then the benefit of a CI server is just wrt
> testing across multiple platforms.
In addition to the "download, build, test" verification, a build
server could remove the manual steps of packaging, signing and
deploying a release. Besides speeding up the process, such a release
build would significantly reduce the risk of mistakes inherent in
doing these steps manually. I've seen (and made) mistakes in all of
these steps.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Stephen Connolly <st...@gmail.com>.
On Monday, 2 June 2014, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Mon, Jun 2, 2014 at 8:17 AM, Jim Jagielski <jim@jagunet.com
> <javascript:;>> wrote:
> > You may be referring to:
> >>
> >> For example, do we really need for everyone to download, compile and
> >> test the code before casting a +1, when a CI server can do this just
> >> as well if not better.
> >
> > Yes. Yes we do.
> >
> > Note that this was in response to the concept of "rubber
> > stamping" a release, the idea being that anything out
> > of a CI is already assumed to be +1 worthy.
>
> At least I read your response more literally, thanks for clarifying.
>
> > So tell me, assuming that you also agree w/ the idea
> > that an artifact out of a CI should not be blindly rubber-
> > stamped w/ a +1, what process would you go through to
> > convince you, for yourself, that it is ready for release?
>
> The point that I'm trying to make here is that if we can guarantee
> that what goes into a build is ready for release (reviewed, voted on,
> etc.), then the output of the build (assuming the build server is
> properly built and maintained for this purpose) should equally be OK
> to release. At least I don't see any of Bertrand's invariants being
> violated. Am I mistaken?
>
> > Again, we vote on a release artifact.
>
> My argument is that at least in some cases it would be better to
> review and vote on the sources that go into the release than the
> artifact itself. It would be nice if we could find a way to adapt the
> policy to allow also such a release process.
We vote on the source bundle and only the source bundle as I understand
things. Convenience binaries are something separate unless I am mistaken...
If that context is correct then the benefit of a CI server is just wrt
testing across multiple platforms.
(Now many projects vote and release binaries, and perhaps we should elivate
the status of binaries from their current low levels, but Apache is about
the source first)
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> <javascript:;>
> For additional commands, e-mail: legal-discuss-help@apache.org
> <javascript:;>
>
>
--
Sent from my phone
Re: Continuous release review
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jun 2, 2014, at 8:38 AM, Jukka Zitting <ju...@gmail.com> wrote:
>
> My argument is that at least in some cases it would be better to
> review and vote on the sources that go into the release than the
> artifact itself. It would be nice if we could find a way to adapt the
> policy to allow also such a release process.
>
We need to do both, imo.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Mon, Jun 2, 2014 at 8:17 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> You may be referring to:
>>
>> For example, do we really need for everyone to download, compile and
>> test the code before casting a +1, when a CI server can do this just
>> as well if not better.
>
> Yes. Yes we do.
>
> Note that this was in response to the concept of "rubber
> stamping" a release, the idea being that anything out
> of a CI is already assumed to be +1 worthy.
At least I read your response more literally, thanks for clarifying.
> So tell me, assuming that you also agree w/ the idea
> that an artifact out of a CI should not be blindly rubber-
> stamped w/ a +1, what process would you go through to
> convince you, for yourself, that it is ready for release?
The point that I'm trying to make here is that if we can guarantee
that what goes into a build is ready for release (reviewed, voted on,
etc.), then the output of the build (assuming the build server is
properly built and maintained for this purpose) should equally be OK
to release. At least I don't see any of Bertrand's invariants being
violated. Am I mistaken?
> Again, we vote on a release artifact.
My argument is that at least in some cases it would be better to
review and vote on the sources that go into the release than the
artifact itself. It would be nice if we could find a way to adapt the
policy to allow also such a release process.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 02/06/2014 15:07, Jim Jagielski a écrit :
> On Jun 2, 2014, at 8:33 AM, Marvin Humphrey <ma...@rectangular.com> wrote:
>
>> You and I seem to have interpreted that specific passage from Jukka in
>> different ways.
>>
>> Here's the full context:
>>
>> For example, do we really need for everyone to download, compile and
>> test the code before casting a +1, when a CI server can do this just
>> as well if not better. Could those requirements for the +1 be met by
>> simply checking whether the relevant CI build (run on the specific
>> release candidate) is green?
>>
>> With that in mind, I took your answer as "Yes. Yes, we must compile build and
>> test locally and inspecting CI is not acceptable substitute for that."
>>
> Simply checking that it's green seems like rubber-stamping
> to me. At least, that's how it looks to be in the above
> case.
But how different will it be if I use a script on my machine, and I
distribute this script to my fellow PMC members, which will run this
script on there machien and cast a vote based on the result of this script ?
I do understand the social aspect et all, but still, at some point, this
is what is going to happen, no ?
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jun 2, 2014, at 8:33 AM, Marvin Humphrey <ma...@rectangular.com> wrote:
>
> You and I seem to have interpreted that specific passage from Jukka in
> different ways.
>
> Here's the full context:
>
> For example, do we really need for everyone to download, compile and
> test the code before casting a +1, when a CI server can do this just
> as well if not better. Could those requirements for the +1 be met by
> simply checking whether the relevant CI build (run on the specific
> release candidate) is green?
>
> With that in mind, I took your answer as "Yes. Yes, we must compile build and
> test locally and inspecting CI is not acceptable substitute for that."
>
Simply checking that it's green seems like rubber-stamping
to me. At least, that's how it looks to be in the above
case.
Cheers!
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Mon, Jun 2, 2014 at 5:17 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> On Jun 2, 2014, at 7:41 AM, Stephen Connolly <st...@gmail.com> wrote:
>> Well you were the one, IIRC, that said PMC members must/should (not sure
>> which but definitely not could) "download, build and test"...
>
> Here are my quotes:
>
> People perform releases. They can use whatever tools
> they want, but at the end, the only validation check
> that really matters are those PMC members who test,
> validate and +1 the release.
Our policy page currently says that we have to download, build and test
locally.
http://www.apache.org/dev/release.html#approving-a-release
What are the ASF requirements on approving a release?
[...] Before voting +1 PMC members are required to download the signed
source code package, compile it as provided, and test the resulting
executable on their own platform, [...]
> You may be referring to:
>
>>
>>
>> For example, do we really need for everyone to download, compile and
>> test the code before casting a +1, when a CI server can do this just
>> as well if not better.
>
> Yes. Yes we do.
>
> Note that this was in response to the concept of "rubber
> stamping" a release, the idea being that anything out
> of a CI is already assumed to be +1 worthy.
You and I seem to have interpreted that specific passage from Jukka in
different ways.
Here's the full context:
For example, do we really need for everyone to download, compile and
test the code before casting a +1, when a CI server can do this just
as well if not better. Could those requirements for the +1 be met by
simply checking whether the relevant CI build (run on the specific
release candidate) is green?
With that in mind, I took your answer as "Yes. Yes, we must compile build and
test locally and inspecting CI is not acceptable substitute for that."
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jun 2, 2014, at 7:41 AM, Stephen Connolly <st...@gmail.com> wrote:
>
>
> On Monday, 2 June 2014, Jim Jagielski <ji...@jagunet.com> wrote:
>
> On Jun 2, 2014, at 4:34 AM, Bertrand Delacretaz <bd...@apache.org> wrote:
> > 4) The PMC votes to make the release an act of the foundation
> > 5) All PMC members are given a fair chance to take part in release votes
> >
>
> These 2 are the only ones which, it appears, are
> the current topic of discussion. For #5 is issue seems
> to be the reasoning behind the 72 hour rule.
>
> #4 is the "main" issue, as I see it. And it appears that
> I must be making myself especially unclear or else
> my position is being (deliberately) misinterpreted.
>
> Well you were the one, IIRC, that said PMC members must/should (not sure which but definitely not could) "download, build and test"...
>
Here are my quotes:
People perform releases. They can use whatever tools
they want, but at the end, the only validation check
that really matters are those PMC members who test,
validate and +1 the release.
You may be referring to:
>
>
> For example, do we really need for everyone to download, compile and
> test the code before casting a +1, when a CI server can do this just
> as well if not better.
Yes. Yes we do.
Note that this was in response to the concept of "rubber
stamping" a release, the idea being that anything out
of a CI is already assumed to be +1 worthy.
So tell me, assuming that you also agree w/ the idea
that an artifact out of a CI should not be blindly rubber-
stamped w/ a +1, what process would you go through to
convince you, for yourself, that it is ready for release?
Again, we vote on a release artifact.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Stephen Connolly <st...@gmail.com>.
On Monday, 2 June 2014, Jim Jagielski <ji...@jagunet.com> wrote:
>
> On Jun 2, 2014, at 4:34 AM, Bertrand Delacretaz <bdelacretaz@apache.org
> <javascript:;>> wrote:
> > 4) The PMC votes to make the release an act of the foundation
> > 5) All PMC members are given a fair chance to take part in release votes
> >
>
> These 2 are the only ones which, it appears, are
> the current topic of discussion. For #5 is issue seems
> to be the reasoning behind the 72 hour rule.
>
> #4 is the "main" issue, as I see it. And it appears that
> I must be making myself especially unclear or else
> my position is being (deliberately) misinterpreted.
Well you were the one, IIRC, that said PMC members must/should (not sure
which but definitely not could) "download, build and test"...
If you are advocating that individual PMC members do what they see fit as
long as:
1. Their voting +1 is not a foregone conclusion before they start doing
what they do.
2. If they do vote +1 they are happy and comfortable so doing
Then that sounds like a radically different position from: must download,
build and test.
>
> First of all, there is/was an argument that a successful
> artifact out of a CI was a de-facto "approved release" by
> a PMC (basically, that there is/was no need for people
> to vote on it, since the CI system could do a better
> job than anyone)... I *hope* that this is now no longer
> believed nor something that anyone considers valid.
> I think we all (now) know that we (the ASF) require
> the 3 +1 votes on a release.
I know I never had any doubts on that one.
There is a second point: you cannot veto a release... So effectively once
you have 3 +1's the release manager *can* release anyway... Yes that
alienates the community... Yes it's not the apache way... Yes I would slap
any release manager in the maven project if they were repeatedly doing that
without good reason (a good reason I can think of I a zero-day security
issue)
>
> Now I think where we might be having some trouble
> understanding each other is "what does a vote entail."
> For me, a vote is not simply a "rubber stamping" of
> an artifact/release ("Hey, it passed the CI, good
> enough for me. +1"). After all, if it's just a
> rubber stamp then it could be argued "why vote at
> all? It's just unnecessary process"...
>
> Recall again that one way in which a PMC knows it's
> in trouble related to its health is when it finds
> itself un-able to find 3 PMC members to vote +1
> on a release. Now this concern *only* makes sense,
> and has validity, when it is assumed that the +1
> votes are not rubber stamps as well.
>
> So the lynchpin in all this is that the vote are
> personal actions by PMC members; they are conscious
> and direct actions. One way that this is done in
> by the voter doing their own "QA test" on the release
> artifact. Now my QA testing will not be the same
> as yours, and I am not specifying any "requirements"
> of that testing other than "it should not be a
> rubber stamp.". Whatever it takes for someone to
> feel comfortable voting +1 is sufficient.
>
> My point is that automatically rubber stamping anything
> with a +1 is dangerous, and bypasses and "ignores" the
> social aspect (and social health check of doing a release)
> that forms a basis of how the ASF produces (and releases)
> s/w.
>
> I hope this clears some things up.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> <javascript:;>
> For additional commands, e-mail: legal-discuss-help@apache.org
> <javascript:;>
>
>
--
Sent from my phone
Re: Continuous release review
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jun 2, 2014, at 4:34 AM, Bertrand Delacretaz <bd...@apache.org> wrote:
> 4) The PMC votes to make the release an act of the foundation
> 5) All PMC members are given a fair chance to take part in release votes
>
These 2 are the only ones which, it appears, are
the current topic of discussion. For #5 is issue seems
to be the reasoning behind the 72 hour rule.
#4 is the "main" issue, as I see it. And it appears that
I must be making myself especially unclear or else
my position is being (deliberately) misinterpreted.
First of all, there is/was an argument that a successful
artifact out of a CI was a de-facto "approved release" by
a PMC (basically, that there is/was no need for people
to vote on it, since the CI system could do a better
job than anyone)... I *hope* that this is now no longer
believed nor something that anyone considers valid.
I think we all (now) know that we (the ASF) require
the 3 +1 votes on a release.
Now I think where we might be having some trouble
understanding each other is "what does a vote entail."
For me, a vote is not simply a "rubber stamping" of
an artifact/release ("Hey, it passed the CI, good
enough for me. +1"). After all, if it's just a
rubber stamp then it could be argued "why vote at
all? It's just unnecessary process"...
Recall again that one way in which a PMC knows it's
in trouble related to its health is when it finds
itself un-able to find 3 PMC members to vote +1
on a release. Now this concern *only* makes sense,
and has validity, when it is assumed that the +1
votes are not rubber stamps as well.
So the lynchpin in all this is that the vote are
personal actions by PMC members; they are conscious
and direct actions. One way that this is done in
by the voter doing their own "QA test" on the release
artifact. Now my QA testing will not be the same
as yours, and I am not specifying any "requirements"
of that testing other than "it should not be a
rubber stamp.". Whatever it takes for someone to
feel comfortable voting +1 is sufficient.
My point is that automatically rubber stamping anything
with a +1 is dangerous, and bypasses and "ignores" the
social aspect (and social health check of doing a release)
that forms a basis of how the ASF produces (and releases)
s/w.
I hope this clears some things up.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 02/06/2014 15:22, Jukka Zitting a écrit :
> Hi,
>
> On Mon, Jun 2, 2014 at 5:17 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
>> IMO, r-t-c and c-t-r process are different. I'm not sure that Jukka is
>> accurate when he writes that r-t-c type project will be validated
>> because each commit has been validated, unless each review is following
>> the same process that a release itself (ie, voting a commit would be
>> like voting a release. Not sure it's the case).
> Just to avoid misunderstandings, here's what I said about that
> example: "a strict RTC policy where each commit is reviewed and voted
> on not just for its technical content but also as if a new release was
> cut from that point"
I stand corrected.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Mon, Jun 2, 2014 at 5:17 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
> IMO, r-t-c and c-t-r process are different. I'm not sure that Jukka is
> accurate when he writes that r-t-c type project will be validated
> because each commit has been validated, unless each review is following
> the same process that a release itself (ie, voting a commit would be
> like voting a release. Not sure it's the case).
Just to avoid misunderstandings, here's what I said about that
example: "a strict RTC policy where each commit is reviewed and voted
on not just for its technical content but also as if a new release was
cut from that point"
That might seem pretty draconian, but would actually be not that much
effort for projects that already have strict RTC rules for maintenance
branches. Such a project could fairly easily adopt the outlined
"continuous release review" process for patch releases cut from
maintenance branches, and stick with the traditional release process
for bigger releases.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 02/06/2014 10:34, Bertrand Delacretaz a écrit :
> Hi,
>
> Jukka's two examples of how projects can manage releases, quoted
> below, are excellent examples of why it doesn't make sense to force
> the same *process* on all projects.
IMO, r-t-c and c-t-r process are different. I'm not sure that Jukka is
accurate when he writes that r-t-c type project will be validated
because each commit has been validated, unless each review is following
the same process that a release itself (ie, voting a commit would be
like voting a release. Not sure it's the case).
That being said,
>
> What's needed is to agree on the *invariants* for releasing software
> at the ASF, something like:
>
> 0) The ASF releases source code
> 1) Each line of code is traceable, we know who committed it when
> 2) All code (and additional files like NOTICE etc.) is reviewed to
> comply with the ASF's legal requirements
> 3) Release packages are signed in a way that allows users to check
> their integrity
4) the source package must be compiled locally, produces the same
output, and has to be tested.
5) I do think it's important to verify that we can pull the source from
the repo and produce the same result too.
> 4) The PMC votes to make the release an act of the foundation
> 5) All PMC members are given a fair chance to take part in release votes
>
> I might be missing a few things but those are the main points -
> agreeing on such a list and making it a hard requirement is what we
> need, the details of how each PMC implements it are not a foundation's
> concern.
I wish it is the case. That also means that if the ASF provides the
tooling - and the machines - to run this process, instead of expecting
people to set it up on their own machine, granted they *will* check the
output of the process, then a vote can be casted safely.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Stephen Connolly <st...@gmail.com>.
+1000
On Monday, 2 June 2014, Bertrand Delacretaz <bd...@apache.org> wrote:
> Hi,
>
> Jukka's two examples of how projects can manage releases, quoted
> below, are excellent examples of why it doesn't make sense to force
> the same *process* on all projects.
>
> What's needed is to agree on the *invariants* for releasing software
> at the ASF, something like:
>
> 0) The ASF releases source code
> 1) Each line of code is traceable, we know who committed it when
> 2) All code (and additional files like NOTICE etc.) is reviewed to
> comply with the ASF's legal requirements
> 3) Release packages are signed in a way that allows users to check
> their integrity
> 4) The PMC votes to make the release an act of the foundation
> 5) All PMC members are given a fair chance to take part in release votes
>
> I might be missing a few things but those are the main points -
> agreeing on such a list and making it a hard requirement is what we
> need, the details of how each PMC implements it are not a foundation's
> concern.
>
> -Bertrand
>
>
> On Fri, May 30, 2014 at 4:32 PM, Jukka Zitting <jukka.zitting@gmail.com
> <javascript:;>> wrote:
> > ...For the sake of the argument, assume that a project adopts a strict
> > RTC policy where each commit is reviewed and voted on not just for
> > it's technical content but also as if a new release was cut from that
> > point. An audit trail of the review results and all votes cast are
> > stored in each commit message. The project would then, after reaching
> > consensus that it's time to release, just tag the release and have a
> > build server take care of automatically verifying the audit trail and
> > then packaging, signing, building, testing and deploying the release.
> > There would be no manual review of the release package itself and no
> > need for the "72 hours" or "3 +1s" rules, as all those things would
> > already have been taken care of earlier in the process.
> >
> > Or as a simpler alternative, assume a project that identifies a
> > specific revision as a release candidate and runs a normal release
> > review and vote against that revision instead of a pre-built release
> > candidate. If the vote passes, the revision would be tagged and a
> > build server would again take care of verifying the vote results and
> > then packaging, signing, building, testing and deploying the release.
> > Such a process could even produce "official" binary packages, as there
> > would be no need to double-guess what actually went into building
> > those packages.
> ...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> <javascript:;>
> For additional commands, e-mail: legal-discuss-help@apache.org
> <javascript:;>
>
>
--
Sent from my phone
Re: Continuous release review
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
Jukka's two examples of how projects can manage releases, quoted
below, are excellent examples of why it doesn't make sense to force
the same *process* on all projects.
What's needed is to agree on the *invariants* for releasing software
at the ASF, something like:
0) The ASF releases source code
1) Each line of code is traceable, we know who committed it when
2) All code (and additional files like NOTICE etc.) is reviewed to
comply with the ASF's legal requirements
3) Release packages are signed in a way that allows users to check
their integrity
4) The PMC votes to make the release an act of the foundation
5) All PMC members are given a fair chance to take part in release votes
I might be missing a few things but those are the main points -
agreeing on such a list and making it a hard requirement is what we
need, the details of how each PMC implements it are not a foundation's
concern.
-Bertrand
On Fri, May 30, 2014 at 4:32 PM, Jukka Zitting <ju...@gmail.com> wrote:
> ...For the sake of the argument, assume that a project adopts a strict
> RTC policy where each commit is reviewed and voted on not just for
> it's technical content but also as if a new release was cut from that
> point. An audit trail of the review results and all votes cast are
> stored in each commit message. The project would then, after reaching
> consensus that it's time to release, just tag the release and have a
> build server take care of automatically verifying the audit trail and
> then packaging, signing, building, testing and deploying the release.
> There would be no manual review of the release package itself and no
> need for the "72 hours" or "3 +1s" rules, as all those things would
> already have been taken care of earlier in the process.
>
> Or as a simpler alternative, assume a project that identifies a
> specific revision as a release candidate and runs a normal release
> review and vote against that revision instead of a pre-built release
> candidate. If the vote passes, the revision would be tagged and a
> build server would again take care of verifying the vote results and
> then packaging, signing, building, testing and deploying the release.
> Such a process could even produce "official" binary packages, as there
> would be no need to double-guess what actually went into building
> those packages.
...
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Continuous release review
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
Let me try to refocus this discussion.
First of all, I'm not trying to argue that projects should be free to
ignore or replace parts of existing policy, they shouldn't. Instead
I'm looking for ways to *change* the policy to enable new ways to make
releases.
Second, I think we all agree that underlying goals (legal, social,
technical, etc.) of the current policy are sound and shouldn't be
abandoned. I only question the specific mechanisms we currently use to
meet those goals. If there are alternative ways of meeting the same
goals, shouldn't we consider adjusting the policy to allow such
mechanisms if projects would like to use them?
Finally, I believe there's an opening for us to allow radically new
ways of cutting releases without abandoning any of those goals. I'll
explain:
On Wed, May 28, 2014 at 11:32 AM, Jukka Zitting <ju...@gmail.com> wrote:
> Thus I question the focus we're putting on the release as the point
> where all this review is supposed happens. Instead I'd rather see this
> becoming more of an ongoing task to be done at the level of each
> commit or push, with the release review more just a final confirmation
> that such a process has been followed.
For the sake of the argument, assume that a project adopts a strict
RTC policy where each commit is reviewed and voted on not just for
it's technical content but also as if a new release was cut from that
point. An audit trail of the review results and all votes cast are
stored in each commit message. The project would then, after reaching
consensus that it's time to release, just tag the release and have a
build server take care of automatically verifying the audit trail and
then packaging, signing, building, testing and deploying the release.
There would be no manual review of the release package itself and no
need for the "72 hours" or "3 +1s" rules, as all those things would
already have been taken care of earlier in the process.
Or as a simpler alternative, assume a project that identifies a
specific revision as a release candidate and runs a normal release
review and vote against that revision instead of a pre-built release
candidate. If the vote passes, the revision would be tagged and a
build server would again take care of verifying the vote results and
then packaging, signing, building, testing and deploying the release.
Such a process could even produce "official" binary packages, as there
would be no need to double-guess what actually went into building
those packages.
How would such imaginary processes produce releases that are any worse
than those governed by current policy? Are there any legal, social or
other aspects that such processes would fail to address as well as we
now do?
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org