Re: ApacheCon schedule status
On Thu, Feb 13, 2014 at 6:34 PM, Rich Bowen wrote: > I've got a mostly-done tentative schedule, and I need lots of people to look > at it. Looks like my Incubator talk is scheduled to be given on both Day 1 and Day 3. Yes, it will be so awesome that attendees will demand an encore. Marvin Humphrey
ApacheCon schedule status
I've got a mostly-done tentative schedule, and I need lots of people to look at it. http://tm3.org/cfpreview is all of the talks, broken into categories http://tm3.org/actracks is the proposed schedule I'm waiting for feedback from the Hadoop/Bigdata folks, and from the Science folks, so those tracks are marked in grey as full, but I don't have actual content there. I also have the 9th track on day 3 empty, and I don't have any fallback talks picked out. So, what I still need: * Look over the whole schedule and see that it hangs together * Compare the talks listed in the ALL TRACKS tab with everything else, ensuring that there aren't talks that have been omitted from consideration. * Ensure that we don't have folks speaking twice at the same time * Ensure that the *ordering* in the individual tracks makes sense * Ensure that there's not obvious irreconcilable conflict between concurrent talks. (ie, everyone is going to want to go to both.) * Anything else that I've overlooked in this process. Thank you all so much for your assistance so far. Almost every track has had extensive help from *someone* in putting it together. Notes: * All "lightning talks" and "BoF" submissions are marked rejected because they're not scheduled at this point in the process. We'll do that next after we publish this schedule * If you have comments, please reply to this email. If you make comments in the spreadsheet they'll likely get lost in the noise * If you want to edit a track directly in the schedule spreadsheet, just ask, and I'll add you to the access list * The second URL - http://tm3.org/actracks - is redirecting to a different location than it was yesterday, so make sure you're looking at the version that has all three days full of content, not the one that's mostly empty. -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon
Re: How can we support a faster release cadence?
On Thursday, 13 February 2014, Joseph Schaefer wrote: > Change is hard, we aren't a tiny org and we do have an opinion about how > things should be done. That's all I'll say about the git stuff. > > But let's face reality for a moment- Cordova has averaged one release a > month for the past seven months. Why then is a three day window a > dealbreaker? If you are looking to do one release per month, 72h is no problem IMHO If you are looking to do one release every 7 days (assuming there are releasable changes) then 72h + 24h (before announce) is smelling problematic... I am proposing the Maven try weekly releases for our 3.2.x line after we get our first 3.2.x release done and review after 3 months... We'll see what our community feels about that suggestion... It may go nowhere if the community doesn't like it... But I do feel that we are past the point of speculating and that some project needs to try the experiment. > Sent from my iPhone > > > On Feb 13, 2014, at 5:04 PM, Hadrian Zbarcea wrote: > > > > Not sure if it's a mischaracterization. I have the same understanding as > Benson that that many comments on git threads reflected the perception that > git/github are incompatible with ASF. Not the point however. > > > > What I see again is, for the most part, violent agreement that turns > into lengthy threads that have a ddos effect (at least on me). What I get > is that: > > * votes are important, no vote no release (little to debate on that, > given the current bylaws) > > * the community *must* be included, hence the rationale for 72 hours > votes guideline > > * the board is ok with shorter vote windows, provided the release > requirements are met *and* community is included > > * the cordova community is willing to adapt to a process that satisfies > the ASF guidelines, but they would like to preserve their current style of > 'cadence releases' > > > > What I don't get is this: > > * say a community reaches a consensus to provide weekly releases (or > daily, whatever cadence) > > * say that they all know that the voting window is 12 hours (or 1 hour) > starting *always* on Wed as 12 am UTC. > > Then how can one justify a claim that a release was pushed by the > 'people in the room'? Cadence release is not unheard of. There are > communities who release at a cadence of 4 years and the voting window is 24 > hours, the Tue after the first Mon in Nov [1]. > > > > * nobody could claim they are excluded, as the voting window is well > known in advance > > * people (pmc or not) can decide in advance if they have bandwidth to > participate in testing the release and hence voting > > * people can volunteer/announce in advance if they can/will participate > in testing the release, which is what the RM does in any project > > * what goes in the release is dictated by the commits and the community > has plenty of ways to decide how to accomplish that > > * changes are incremental (i.e. whatever changes since last week), so > the volume of work and expectations are known and manageable > > * people can decide what the fate of failed releases is (redo, skip, > etc). > > * a project could even go as far as allowing such 'short' vote cycles > only via a unanimous and time bound (say quarterly) vote in the PMC. This > way a rogue group would only have a limited time to push their interests. A > disenfranchised PMC member could easily -1 short releases for the next > quarter. If the community cares about candence releases, it creates an > incentive for people to play nicely in the community. And there are other > ways, smarter people already suggested. > > > > It is not my place to judge nor my desire to advocate for or against > cadence releases. I saw a bunch of excellent comments and proposals in > these thread(s). Some volunteered to experiment too. What is the problem > with such an elusive solution, really? What is the perceived risk? > > > > My $0.02, > > Hadrian > > > > [1] http://en.wikipedia.org/wiki/Election_Day_%28United_States%29 > > > > > >> On 02/13/2014 08:40 AM, Joseph Schaefer wrote: > >> That is a mischaracterization of the git story which was always about > being able to support multiple version control tools. Yes people were > concerned about the social side but we wouldn't be Apache without that > debate. > >> > >> Same here. All you are seeing is some natural skepticism about the > claims being made. The door is open though to a well considered proposal > that this exercise should help refine. > >> > >> Sent from my iPhone > >> > >>> On Feb 13, 2014, at 7:58 AM, Benson Margulies > wrote: > >>> > >>> This conversation goes in a circle. I see two positions: > >>> > >>> 1: Cadence releases are inevitably incompatible with Apache community > values. > >>> 2: Cadence releases are not inevitably incompatible with Apache > >>> community values. > >>> > >>> People who take the first position see this desire to use cadence as > >>> weakening of values and the brand. People who take the se
Re: How can we support a faster release cadence?
Change is hard, we aren't a tiny org and we do have an opinion about how things should be done. That's all I'll say about the git stuff. But let's face reality for a moment- Cordova has averaged one release a month for the past seven months. Why then is a three day window a dealbreaker? Sent from my iPhone > On Feb 13, 2014, at 5:04 PM, Hadrian Zbarcea wrote: > > Not sure if it's a mischaracterization. I have the same understanding as > Benson that that many comments on git threads reflected the perception that > git/github are incompatible with ASF. Not the point however. > > What I see again is, for the most part, violent agreement that turns into > lengthy threads that have a ddos effect (at least on me). What I get is that: > * votes are important, no vote no release (little to debate on that, given > the current bylaws) > * the community *must* be included, hence the rationale for 72 hours votes > guideline > * the board is ok with shorter vote windows, provided the release > requirements are met *and* community is included > * the cordova community is willing to adapt to a process that satisfies the > ASF guidelines, but they would like to preserve their current style of > 'cadence releases' > > What I don't get is this: > * say a community reaches a consensus to provide weekly releases (or daily, > whatever cadence) > * say that they all know that the voting window is 12 hours (or 1 hour) > starting *always* on Wed as 12 am UTC. > Then how can one justify a claim that a release was pushed by the 'people in > the room'? Cadence release is not unheard of. There are communities who > release at a cadence of 4 years and the voting window is 24 hours, the Tue > after the first Mon in Nov [1]. > > * nobody could claim they are excluded, as the voting window is well known in > advance > * people (pmc or not) can decide in advance if they have bandwidth to > participate in testing the release and hence voting > * people can volunteer/announce in advance if they can/will participate in > testing the release, which is what the RM does in any project > * what goes in the release is dictated by the commits and the community has > plenty of ways to decide how to accomplish that > * changes are incremental (i.e. whatever changes since last week), so the > volume of work and expectations are known and manageable > * people can decide what the fate of failed releases is (redo, skip, etc). > * a project could even go as far as allowing such 'short' vote cycles only > via a unanimous and time bound (say quarterly) vote in the PMC. This way a > rogue group would only have a limited time to push their interests. A > disenfranchised PMC member could easily -1 short releases for the next > quarter. If the community cares about candence releases, it creates an > incentive for people to play nicely in the community. And there are other > ways, smarter people already suggested. > > It is not my place to judge nor my desire to advocate for or against cadence > releases. I saw a bunch of excellent comments and proposals in these > thread(s). Some volunteered to experiment too. What is the problem with such > an elusive solution, really? What is the perceived risk? > > My $0.02, > Hadrian > > [1] http://en.wikipedia.org/wiki/Election_Day_%28United_States%29 > > >> On 02/13/2014 08:40 AM, Joseph Schaefer wrote: >> That is a mischaracterization of the git story which was always about being >> able to support multiple version control tools. Yes people were concerned >> about the social side but we wouldn't be Apache without that debate. >> >> Same here. All you are seeing is some natural skepticism about the claims >> being made. The door is open though to a well considered proposal that this >> exercise should help refine. >> >> Sent from my iPhone >> >>> On Feb 13, 2014, at 7:58 AM, Benson Margulies wrote: >>> >>> This conversation goes in a circle. I see two positions: >>> >>> 1: Cadence releases are inevitably incompatible with Apache community >>> values. >>> 2: Cadence releases are not inevitably incompatible with Apache >>> community values. >>> >>> People who take the first position see this desire to use cadence as >>> weakening of values and the brand. People who take the second position >>> are frustrated. >>> >>> Note the phrase, 'not inevitably'. No one here is claiming, in the >>> absence of an experiment, that this idea will inevitably lead to a >>> perfectly healthy expression of Apache Community values. >>> >>> This conversation reminds me of the early days of the git discussion. >>> At that time, some folks were convinced that 'git === fork culture'. >>> Since 'fork culture' is pretty clearly incompatible with Apache >>> community values, it took a very long time for us to decide to perform >>> an _experiment_ in git usage to see what would happen. OK, here we >>> are, the git experiment has been deemed a success. >>> >>> The following is utterly non
Re: ApacheCon Community track
On Thu, Feb 13, 2014 at 10:26 AM, jan i wrote: > Especially for the community track a panel discussion, with a short > introduction from each panel member could be a lot more lively and thereby > giving for us all. > > The community track is all about our communities, so why not do some of the > talks in that form. > > but thats just my personal opinion. My strong +1 to that -- a panel with a cool moderator is worth a couple of presos in my book ;-) Thanks, Roman.
Re: ApacheCon status and proceeding forward
Hi Rich! On Wed, Feb 12, 2014 at 5:57 PM, Rich Bowen wrote: > 3) http://tm3.org/actracks/ is days and proposed tracks each day. Now that > I'm done with #2, I'm moving on to #3, taking the completed tracks and > populating the actual schedule in #3. From here, we'll have to either add or > remove talks to make the final schedule. > > So, everything is still volatile, and I still need a lot of help. More than willing to help -- just let me know what specifically do you need. One area where I can contribute right away is to reach out to various dev@ MLs and ask for de-duping. Unless, of course, somebody is already doing it. Either way -- please let me know. Thanks, Roman.
Re: How can we support a faster release cadence?
Not sure if it's a mischaracterization. I have the same understanding as Benson that that many comments on git threads reflected the perception that git/github are incompatible with ASF. Not the point however. What I see again is, for the most part, violent agreement that turns into lengthy threads that have a ddos effect (at least on me). What I get is that: * votes are important, no vote no release (little to debate on that, given the current bylaws) * the community *must* be included, hence the rationale for 72 hours votes guideline * the board is ok with shorter vote windows, provided the release requirements are met *and* community is included * the cordova community is willing to adapt to a process that satisfies the ASF guidelines, but they would like to preserve their current style of 'cadence releases' What I don't get is this: * say a community reaches a consensus to provide weekly releases (or daily, whatever cadence) * say that they all know that the voting window is 12 hours (or 1 hour) starting *always* on Wed as 12 am UTC. Then how can one justify a claim that a release was pushed by the 'people in the room'? Cadence release is not unheard of. There are communities who release at a cadence of 4 years and the voting window is 24 hours, the Tue after the first Mon in Nov [1]. * nobody could claim they are excluded, as the voting window is well known in advance * people (pmc or not) can decide in advance if they have bandwidth to participate in testing the release and hence voting * people can volunteer/announce in advance if they can/will participate in testing the release, which is what the RM does in any project * what goes in the release is dictated by the commits and the community has plenty of ways to decide how to accomplish that * changes are incremental (i.e. whatever changes since last week), so the volume of work and expectations are known and manageable * people can decide what the fate of failed releases is (redo, skip, etc). * a project could even go as far as allowing such 'short' vote cycles only via a unanimous and time bound (say quarterly) vote in the PMC. This way a rogue group would only have a limited time to push their interests. A disenfranchised PMC member could easily -1 short releases for the next quarter. If the community cares about candence releases, it creates an incentive for people to play nicely in the community. And there are other ways, smarter people already suggested. It is not my place to judge nor my desire to advocate for or against cadence releases. I saw a bunch of excellent comments and proposals in these thread(s). Some volunteered to experiment too. What is the problem with such an elusive solution, really? What is the perceived risk? My $0.02, Hadrian [1] http://en.wikipedia.org/wiki/Election_Day_%28United_States%29 On 02/13/2014 08:40 AM, Joseph Schaefer wrote: That is a mischaracterization of the git story which was always about being able to support multiple version control tools. Yes people were concerned about the social side but we wouldn't be Apache without that debate. Same here. All you are seeing is some natural skepticism about the claims being made. The door is open though to a well considered proposal that this exercise should help refine. Sent from my iPhone On Feb 13, 2014, at 7:58 AM, Benson Margulies wrote: This conversation goes in a circle. I see two positions: 1: Cadence releases are inevitably incompatible with Apache community values. 2: Cadence releases are not inevitably incompatible with Apache community values. People who take the first position see this desire to use cadence as weakening of values and the brand. People who take the second position are frustrated. Note the phrase, 'not inevitably'. No one here is claiming, in the absence of an experiment, that this idea will inevitably lead to a perfectly healthy expression of Apache Community values. This conversation reminds me of the early days of the git discussion. At that time, some folks were convinced that 'git === fork culture'. Since 'fork culture' is pretty clearly incompatible with Apache community values, it took a very long time for us to decide to perform an _experiment_ in git usage to see what would happen. OK, here we are, the git experiment has been deemed a success. The following is utterly non-rhetorical. Something happened over the course of long discussion to move from 'git is evil, go away' to 'infra is willing to put effort into the infrastructure to support an experiment.' What was it, and is there any hope of following that path? On Thu, Feb 13, 2014 at 12:02 AM, Phil Steitz wrote: On 2/12/14, 7:23 PM, Marvin Humphrey wrote: On Wed, Feb 12, 2014 at 10:46 AM, Phil Steitz wrote: I know this looks old-fashioned, even downright anachronistic to "push-hourly-from-CI" people; but deciding *what* to release *as a community* is an important responsibility of ASF PMCs. Putting things
Re: How can we support a faster release cadence?
On Thu, 13 Feb 2014 01:27:17 -0200, Joseph Schaefer wrote: On Feb 12, 2014, at 10:23 PM, Marvin Humphrey wrote: On Wed, Feb 12, 2014 at 10:46 AM, Phil Steitz wrote: I know this looks old-fashioned, even downright anachronistic to "push-hourly-from-CI" people; but deciding *what* to release *as a community* is an important responsibility of ASF PMCs. Putting things on a rigid schedule basically skips this step, which, IMHO is a core part of our common culture and values. Should projects who wish to release on a regular schedule avoid Apache? I cannot see how the Apache policies prevent a project to release on a regular schedule. As other people mentioned here, nothing prevents a project from having a weekly release as long as the 72h votes are respected and the vote passes. This week's vote got rejected? Improve the release and try again next week. :) Something I can't recall other people mentioned in this thread, so I'll mention myself: the word "Apache" before a project name carries some weight: people expect Apache projects to have high quality and the Foundation gets projects donated to it because of that (but not only that, of course). I think the policies target community participation, but quality as well. Cheers! -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br
Re: ApacheCon CFP: Assistance needed
On 13 February 2014 20:27, Melissa Warnkin wrote: > :) LOL So, we're NOT in an ideal world?!?!...be still my beating heart!!! > LOL > No, googleDocs is not driven by ApacheOpenOffice, yet :-) have a nice day. jan I. > > Thanks for all of your help, Kay!!! > > > > > > > From: Kay Schenk > To: dev@community.apache.org; Melissa Warnkin > Sent: Thursday, February 13, 2014 2:03 PM > Subject: Re: ApacheCon CFP: Assistance needed > > > On Thu, Feb 13, 2014 at 10:40 AM, Melissa Warnkin >wrote: > > > It's a google doc, so the changes should have been saved immediately, no? > > > > > > > Well in an ideal world, yes...I > > > > > > > > > > From: Kay Schenk > > To: dev@community.apache.org > > Sent: Thursday, February 13, 2014 1:27 PM > > Subject: Re: ApacheCon CFP: Assistance needed > > > > > > On Wed, Feb 12, 2014 at 5:58 PM, Rich Bowen wrote: > > > > > > > > On 02/12/2014 08:08 PM, Kay Schenk wrote: > > > > > >> On Wed, Feb 12, 2014 at 4:51 PM, Rich Bowen > wrote: > > >> > > >> I'm going through the reviewed talks and marking things as "yes" and > > "no" > > >>> in http://tm3.org/cfpreview/ based on their average score. I would > > >>> appreciate if someone would go through the CFP site and mark a line > in > > >>> some > > >>> way if that speaker indicated that they need funding. > > >>> > > >>> I'm sure I'll need more assistance as I get through this step, but > that > > >>> would save me a lot of time if someone could take on that task. > Thanks. > > >>> > > >>> -- > > >>> Rich Bowen - rbo...@rcbowen.com - @rbowen > > >>> http://apachecon.com/ - @apachecon > > >>> > > >>> > > >>> I added a new column "Needs Funding?". This should make things > > clearer. > > >> With the assumption that any talk, etc. not marked as "yes" here > means > > >> "no". > > >> > > >> > > > I'm not seeing it. You added it where? > > > > > > well on this... > > > > http://tm3.org/cfpreview/ > > > > I don't see it now either. I didn't see a way to explicitly save, but > > > > > > > > > > > > > > > > -- > > > Rich Bowen - rbo...@rcbowen.com - @rbowen > > > http://apachecon.com/ - @apachecon > > > > > > > > > > > > -- > > > > > - > > MzK > > > > "Cats do not have to be shown how to have a good time, > > for they are unfailing ingenious in that respect." > >-- James Mason > > > > > > > -- > > - > MzK > > "Cats do not have to be shown how to have a good time, > for they are unfailing ingenious in that respect." >-- James Mason
Re: ApacheCon CFP: Assistance needed
:) LOL So, we're NOT in an ideal world?!?!...be still my beating heart!!! LOL Thanks for all of your help, Kay!!! From: Kay Schenk To: dev@community.apache.org; Melissa Warnkin Sent: Thursday, February 13, 2014 2:03 PM Subject: Re: ApacheCon CFP: Assistance needed On Thu, Feb 13, 2014 at 10:40 AM, Melissa Warnkin wrote: > It's a google doc, so the changes should have been saved immediately, no? > > > Well in an ideal world, yes...I > > > > From: Kay Schenk > To: dev@community.apache.org > Sent: Thursday, February 13, 2014 1:27 PM > Subject: Re: ApacheCon CFP: Assistance needed > > > On Wed, Feb 12, 2014 at 5:58 PM, Rich Bowen wrote: > > > > > On 02/12/2014 08:08 PM, Kay Schenk wrote: > > > >> On Wed, Feb 12, 2014 at 4:51 PM, Rich Bowen wrote: > >> > >> I'm going through the reviewed talks and marking things as "yes" and > "no" > >>> in http://tm3.org/cfpreview/ based on their average score. I would > >>> appreciate if someone would go through the CFP site and mark a line in > >>> some > >>> way if that speaker indicated that they need funding. > >>> > >>> I'm sure I'll need more assistance as I get through this step, but that > >>> would save me a lot of time if someone could take on that task. Thanks. > >>> > >>> -- > >>> Rich Bowen - rbo...@rcbowen.com - @rbowen > >>> http://apachecon.com/ - @apachecon > >>> > >>> > >>> I added a new column "Needs Funding?". This should make things > clearer. > >> With the assumption that any talk, etc. not marked as "yes" here means > >> "no". > >> > >> > > I'm not seeing it. You added it where? > > > well on this... > > http://tm3.org/cfpreview/ > > I don't see it now either. I didn't see a way to explicitly save, but > > > > > > > > > -- > > Rich Bowen - rbo...@rcbowen.com - @rbowen > > http://apachecon.com/ - @apachecon > > > > > > > -- > > - > MzK > > "Cats do not have to be shown how to have a good time, > for they are unfailing ingenious in that respect." > -- James Mason > -- - MzK "Cats do not have to be shown how to have a good time, for they are unfailing ingenious in that respect." -- James Mason
Re: ApacheCon status and proceeding forward
On Wed, Feb 12, 2014 at 5:57 PM, Rich Bowen wrote: > > On 02/12/2014 11:57 AM, Jan Willem Janssen wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Hi, >> >> I'm a bit confused as to what the current status is on the track >> selection for ApacheCon NA. I've seen the proposed track list, but >> what do we do with the content of those tracks? And what about the >> proposals that still are not categorized, is that already definitive >> or still in a volatile state? >> > > Right now there are several sources of data: > > 1) The CFP system itself is where folks are rating talks. > > 2) http://tm3.org/cfpreview/ is list of all talks broken into topics > which will hopefully become the tracks. Next to each one is Yes/No/Maybe > based on the rating given in the CFP system, #1, above. I have now gone > through everything in the CFP system and noted their accept status in this > spreadsheet. Note that a lot are still "Maybe" indicating that they either > have no ratings at all, or came out as "average" on the accept scale. > > 3) http://tm3.org/actracks/ is days and proposed tracks each day. Now > that I'm done with #2, I'm moving on to #3, taking the completed tracks and > populating the actual schedule in #3. From here, we'll have to either add > or remove talks to make the final schedule. > > So, everything is still volatile, and I still need a lot of help. > > > -- > Rich Bowen - rbo...@rcbowen.com - @rbowen > http://apachecon.com/ - @apachecon > > Tell us what we can do to help. -- - MzK "Cats do not have to be shown how to have a good time, for they are unfailing ingenious in that respect." -- James Mason
Re: ApacheCon CFP: Assistance needed
On Thu, Feb 13, 2014 at 10:40 AM, Melissa Warnkin wrote: > It's a google doc, so the changes should have been saved immediately, no? > > > Well in an ideal world, yes...I > > > > From: Kay Schenk > To: dev@community.apache.org > Sent: Thursday, February 13, 2014 1:27 PM > Subject: Re: ApacheCon CFP: Assistance needed > > > On Wed, Feb 12, 2014 at 5:58 PM, Rich Bowen wrote: > > > > > On 02/12/2014 08:08 PM, Kay Schenk wrote: > > > >> On Wed, Feb 12, 2014 at 4:51 PM, Rich Bowen wrote: > >> > >> I'm going through the reviewed talks and marking things as "yes" and > "no" > >>> in http://tm3.org/cfpreview/ based on their average score. I would > >>> appreciate if someone would go through the CFP site and mark a line in > >>> some > >>> way if that speaker indicated that they need funding. > >>> > >>> I'm sure I'll need more assistance as I get through this step, but that > >>> would save me a lot of time if someone could take on that task. Thanks. > >>> > >>> -- > >>> Rich Bowen - rbo...@rcbowen.com - @rbowen > >>> http://apachecon.com/ - @apachecon > >>> > >>> > >>> I added a new column "Needs Funding?". This should make things > clearer. > >> With the assumption that any talk, etc. not marked as "yes" here means > >> "no". > >> > >> > > I'm not seeing it. You added it where? > > > well on this... > > http://tm3.org/cfpreview/ > > I don't see it now either. I didn't see a way to explicitly save, but > > > > > > > > > -- > > Rich Bowen - rbo...@rcbowen.com - @rbowen > > http://apachecon.com/ - @apachecon > > > > > > > -- > > - > MzK > > "Cats do not have to be shown how to have a good time, > for they are unfailing ingenious in that respect." >-- James Mason > -- - MzK "Cats do not have to be shown how to have a good time, for they are unfailing ingenious in that respect." -- James Mason
Re: ApacheCon CFP: Assistance needed
It's a google doc, so the changes should have been saved immediately, no? From: Kay Schenk To: dev@community.apache.org Sent: Thursday, February 13, 2014 1:27 PM Subject: Re: ApacheCon CFP: Assistance needed On Wed, Feb 12, 2014 at 5:58 PM, Rich Bowen wrote: > > On 02/12/2014 08:08 PM, Kay Schenk wrote: > >> On Wed, Feb 12, 2014 at 4:51 PM, Rich Bowen wrote: >> >> I'm going through the reviewed talks and marking things as "yes" and "no" >>> in http://tm3.org/cfpreview/ based on their average score. I would >>> appreciate if someone would go through the CFP site and mark a line in >>> some >>> way if that speaker indicated that they need funding. >>> >>> I'm sure I'll need more assistance as I get through this step, but that >>> would save me a lot of time if someone could take on that task. Thanks. >>> >>> -- >>> Rich Bowen - rbo...@rcbowen.com - @rbowen >>> http://apachecon.com/ - @apachecon >>> >>> >>> I added a new column "Needs Funding?". This should make things clearer. >> With the assumption that any talk, etc. not marked as "yes" here means >> "no". >> >> > I'm not seeing it. You added it where? well on this... http://tm3.org/cfpreview/ I don't see it now either. I didn't see a way to explicitly save, but > > > -- > Rich Bowen - rbo...@rcbowen.com - @rbowen > http://apachecon.com/ - @apachecon > > -- - MzK "Cats do not have to be shown how to have a good time, for they are unfailing ingenious in that respect." -- James Mason
Re: ApacheCon Community track
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/02/14 19:25, David Nalley wrote: > There are 4 incubator related talks marked as accept - we could > surely pare one of those down. I was thinking in the same line. So +1 for rejecting one of those. - -- Met vriendelijke groeten | Kind regards Jan Willem Janssen | Software Architect +31 631 765 814 /My world is revolving around PulseOn and Amdatu/ Luminis Technologies B.V. J.C. Wilslaan 29 7313 HK Apeldoorn +31 88 586 46 30 http://www.luminis-technologies.com http://www.luminis.eu KvK (CoC) 09 16 28 93 BTW (VAT) NL8169.78.566.B.01 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS/Q6MAAoJEKF/mP2eHDc4pqsQAKE8rMkoodjgC1ezQmwemmik FerF616OL6Eyqnzea8ZjY20g//9yOSWSPJuBMFnhWdDRUEuOSYf3kXQqO+XNUa1Q Z5oZYN6UTY4jyZpkAH43A+LHOpu963tenKYtkJIxUWPB5M5k8s/BqfHdUWsdQVwn FGA7b8Olawk/mcVYQdWXTi9Uu5azmi7UKpNnLlNMgm3VD8bXdiwYIHX6cxFNRWUK zDAG4QZd0pxh0TOrAMlRcnjLuFn8pCZejIZCQ0fTiLlGnNxfsWv4NWpv33dHNXsi TTYFyVUtgFEWQ2MUQKENXj9o24f7h8yxC8VL0cFs8+FJ1HEjply9Vhgmf3qyD6zX vEJ3784wMN+yTR6Fgiu2Z5UawCn36sWf5zhy5oU/6oqeqTJmoTfQ3bQbeIED9WhJ COHg8m2kPcExYP7P28hQIHga2K+OZhBx2HplNXOGtrPPi3KyRCaCghZCwvO1aBWk XleYq9ZN6FB4Dqeg1wl5n354/P9j3GsnlSaTAKJ+2evETE6Uz/l0WTRa8tHwuqmz Q12qCt/ccA8G8d3e5RKRRo/1iKhlyGOIAiAdS0L5nq7t3TC+mQ8UothaDa+7NQLc YNnyhQw/W/Hdo5o1E3k6TQB3FJaFrZ1VHr2/hOUjzdpo8WMh0F3T60lZg/AkTAnk XMcN/PAklqlI71aa2wnO =ukUL -END PGP SIGNATURE-
Re: ApacheCon Community track
On 02/13/2014 01:24 PM, Marvin Humphrey wrote: On Thu, Feb 13, 2014 at 10:10 AM, Rich Bowen wrote: Please have a look at http://tm3.org/cfpreview Community tab. We currently have 19 talks that have been marked as 'Accept' in the CFP system, and I would like to fit this content into 18 sessions. My Incubator talk is listed in two tracks: "Community" and "For Committers". Does that help? Marvin Humphrey Indeed it does. -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon
Re: ApacheCon CFP: Assistance needed
On Wed, Feb 12, 2014 at 5:58 PM, Rich Bowen wrote: > > On 02/12/2014 08:08 PM, Kay Schenk wrote: > >> On Wed, Feb 12, 2014 at 4:51 PM, Rich Bowen wrote: >> >> I'm going through the reviewed talks and marking things as "yes" and "no" >>> in http://tm3.org/cfpreview/ based on their average score. I would >>> appreciate if someone would go through the CFP site and mark a line in >>> some >>> way if that speaker indicated that they need funding. >>> >>> I'm sure I'll need more assistance as I get through this step, but that >>> would save me a lot of time if someone could take on that task. Thanks. >>> >>> -- >>> Rich Bowen - rbo...@rcbowen.com - @rbowen >>> http://apachecon.com/ - @apachecon >>> >>> >>> I added a new column "Needs Funding?". This should make things clearer. >> With the assumption that any talk, etc. not marked as "yes" here means >> "no". >> >> > I'm not seeing it. You added it where? well on this... http://tm3.org/cfpreview/ I don't see it now either. I didn't see a way to explicitly save, but > > > -- > Rich Bowen - rbo...@rcbowen.com - @rbowen > http://apachecon.com/ - @apachecon > > -- - MzK "Cats do not have to be shown how to have a good time, for they are unfailing ingenious in that respect." -- James Mason
Re: ApacheCon Community track
On 13 February 2014 19:10, Rich Bowen wrote: > All, > > Please have a look at http://tm3.org/cfpreview Community tab. > > We currently have 19 talks that have been marked as 'Accept' in the CFP > system, and I would like to fit this content into 18 sessions. I'd like > some feedback on what talk we should drop. There's a lot of overlap in many > of the sessions proposed, and I expect that there are a number that could > be considered redundant. We'll also need a fallback talk for this track, so > if a particular speaker has several sessions, perhaps we can move one to > fallback designation. > > Shane, Ross, and Nick each have multiple talks marked accepted, but, in > each case, there are a number of "Strongly Accept" votes, and I need to > hear from a larger group on where we should go with this. > > Perhaps we could put the three of them in a cage and let them fight it > out. Or, worse, on a panel session. > Especially for the community track a panel discussion, with a short introduction from each panel member could be a lot more lively and thereby giving for us all. The community track is all about our communities, so why not do some of the talks in that form. but thats just my personal opinion. rgds jan I. > --Rich > > -- > Rich Bowen - rbo...@rcbowen.com - @rbowen > http://apachecon.com/ - @apachecon > >
Re: ApacheCon Community track
On Thu, Feb 13, 2014 at 1:10 PM, Rich Bowen wrote: > All, > > Please have a look at http://tm3.org/cfpreview Community tab. > > We currently have 19 talks that have been marked as 'Accept' in the CFP > system, and I would like to fit this content into 18 sessions. I'd like some > feedback on what talk we should drop. There's a lot of overlap in many of > the sessions proposed, and I expect that there are a number that could be > considered redundant. We'll also need a fallback talk for this track, so if > a particular speaker has several sessions, perhaps we can move one to > fallback designation. > > Shane, Ross, and Nick each have multiple talks marked accepted, but, in each > case, there are a number of "Strongly Accept" votes, and I need to hear from > a larger group on where we should go with this. > > Perhaps we could put the three of them in a cage and let them fight it out. > Or, worse, on a panel session. > > --Rich > > -- > Rich Bowen - rbo...@rcbowen.com - @rbowen > http://apachecon.com/ - @apachecon > There are 4 incubator related talks marked as accept - we could surely pare one of those down. Also Shane has three talks accepted, and has previously requested (admittedly OOB) that we accept no more than 2 of his talks. --David
Re: ApacheCon Community track
On Thu, Feb 13, 2014 at 10:10 AM, Rich Bowen wrote: > Please have a look at http://tm3.org/cfpreview Community tab. > > We currently have 19 talks that have been marked as 'Accept' in the CFP > system, and I would like to fit this content into 18 sessions. My Incubator talk is listed in two tracks: "Community" and "For Committers". Does that help? Marvin Humphrey
ApacheCon Community track
All, Please have a look at http://tm3.org/cfpreview Community tab. We currently have 19 talks that have been marked as 'Accept' in the CFP system, and I would like to fit this content into 18 sessions. I'd like some feedback on what talk we should drop. There's a lot of overlap in many of the sessions proposed, and I expect that there are a number that could be considered redundant. We'll also need a fallback talk for this track, so if a particular speaker has several sessions, perhaps we can move one to fallback designation. Shane, Ross, and Nick each have multiple talks marked accepted, but, in each case, there are a number of "Strongly Accept" votes, and I need to hear from a larger group on where we should go with this. Perhaps we could put the three of them in a cage and let them fight it out. Or, worse, on a panel session. --Rich -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon
Re: How can we support a faster release cadence?
On Thu, Feb 13, 2014 at 8:40 AM, Joseph Schaefer wrote: > > That is a mischaracterization of the git story which was always about being > able to support multiple version control tools. Yes people were concerned > about the social side but we wouldn't be Apache without that debate. > > Same here. All you are seeing is some natural skepticism about the claims > being made. The door is open though to a well considered proposal that this > exercise should help refine. Thank you. Even before any proposals, the first step is to see if a community can establish and maintain a cadence _within the rules as we know them today_, and stay healthy. Stephen has proposed that experiment to the Maven PMC of which he is the chair, and if it goes well, we'll make a proposal to take further steps. > > Sent from my iPhone > >> On Feb 13, 2014, at 7:58 AM, Benson Margulies wrote: >> >> This conversation goes in a circle. I see two positions: >> >> 1: Cadence releases are inevitably incompatible with Apache community values. >> 2: Cadence releases are not inevitably incompatible with Apache >> community values. >> >> People who take the first position see this desire to use cadence as >> weakening of values and the brand. People who take the second position >> are frustrated. >> >> Note the phrase, 'not inevitably'. No one here is claiming, in the >> absence of an experiment, that this idea will inevitably lead to a >> perfectly healthy expression of Apache Community values. >> >> This conversation reminds me of the early days of the git discussion. >> At that time, some folks were convinced that 'git === fork culture'. >> Since 'fork culture' is pretty clearly incompatible with Apache >> community values, it took a very long time for us to decide to perform >> an _experiment_ in git usage to see what would happen. OK, here we >> are, the git experiment has been deemed a success. >> >> The following is utterly non-rhetorical. Something happened over the >> course of long discussion to move from 'git is evil, go away' to >> 'infra is willing to put effort into the infrastructure to support an >> experiment.' What was it, and is there any hope of following that >> path? >> >> >> >>> On Thu, Feb 13, 2014 at 12:02 AM, Phil Steitz wrote: On 2/12/14, 7:23 PM, Marvin Humphrey wrote: > On Wed, Feb 12, 2014 at 10:46 AM, Phil Steitz > wrote: > > I know this looks old-fashioned, even downright anachronistic to > "push-hourly-from-CI" people; but deciding *what* to release *as a > community* is an important responsibility of ASF PMCs. Putting > things on a rigid schedule basically skips this step, which, IMHO is > a core part of our common culture and values. Should projects who wish to release on a regular schedule avoid Apache? >>> >>> I agree with Joe that that is the wrong question to ask. The right >>> question is what are the basic principles and values that >>> *communities* should buy into when deciding to join Apache. I >>> proposed a couple of them above. How releases happen, how policy >>> compliance is assured are secondary - the main thing communities >>> need to ask themselves when deciding to join the ASF is do they want >>> to do open, community-based development the way it is done here. If >>> cutting releases on a predetermined schedule is somehow a >>> "requirement" for them, the first question to ask is "why" and if >>> there is a good answer to that question then the second question is >>> how do you do that in a way that is consistent our principles. >>> >>> Phil Marvin Humphrey . >>>
Re: How can we support a faster release cadence?
On 13 February 2014 04:25, Brian LeRoux wrote: > I'd like to throw out some thoughts in support of this thinking and help > explore how we can support faster releases at Apache. > > Cordova has bias to shipping. We started shipping on a schedule mid 2011 > and this was a very deliberate choice, after two years of scattered, and > frankly reactionary, releases. > > At that time we called the project PhoneGap and we realized our offering > was playing cat and mouse with the very fast moving dependencies of iOS and > Android. Being reactionary made shipping a fire drill, inevitably drawn out > since we didn't exercise those muscles enough, and ultimately this made our > software a risk for adoption. We didn't want to be a risk for adoption. We > also did not want our volunteer committership killing themselves every time > iOS or Android landed a patch. > > Moving to a schedule acted as a forcing function to exercise those muscles, > find our cadence, and only positives to the code and community > resulted. Shipping brought our core together. It meant if we didn't have a > fix for a feature the branch would land in the next release which is only a > month away. This built huge confidence in our team by our community. Our > code become better tested, and more streamlined. A consistent release > cadence not only helped us find more quality in our code, but that > confidence really helped us build our committer and developer community. > The story is hardly unique: Chrome, Ubuntu, Docker, Firefox, and many > others have adopted this model in recent years. I agree; in the CouchDB community we had a similar experience. Addressing it has been positive both for our brand and for our community. It's also been a triumph of Apache values of community over code, demonstrating that the incubator process, as well as addressing legal concerns via due diligence, is also capable of sustaining communities who can survive the acrimonious departure of the founder. Moving to a time-driven release has helped us enormously. > I feel anything that can be considered a better practice for higher quality > code and driving community confidence, and subsequently adoption, really > embodies Apache ideals. The faster our code is distributed, the faster we get feedback, as Stephen's also said. > The current process could be largely automated and the vote doesn't > necessarily have to be in the form of an email. I've found these past weeks > the act of voting seems near cultural at Apache so I hope that doesn't > sound crazy! I mean well. > > Another issue I am personally unclear on is the wide variety of artifacts > destinations that an Apache project can be shipped today. Maven has some of > these smarts built in but projects like the npm registry do not. Another > area we need to address is the proliferation of various app stores. I'm not > a fan of them, but they happen, and we should have a mechanism for our > projects to deliver to them. > > > On Fri, Feb 7, 2014 at 3:02 AM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: ... >> So what is it that gets in the way with release votes: >> >> * The 72h "soft" requirement for vote duration >> >> * The actions that a PMC member is required to perform before they can >> vote. See http://www.apache.org/dev/release which states: >> >> > 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, along with also verifying that the >> package meets the requirements of the ASF policy on releases. This last piece is important - I'll bring it up later on. >> So how exactly do these things get in the way? >> >> Well as I see it the 72h vote duration isn't necessarily a big deal... we >> need some duration of notice about what is going into the release, there >> will always be people who feel the duration is either too short or two >> long... but with a 7 day cadence and maybe a few hours before the release >> manager closes out the vote and then you wait for the release to finished >> syncing to the mirrors and then the release manager gets a chance to verify >> that the release has synced to at least one mirror... you could easily lose >> half a day's duration in that process... oh look the release is out 3.5 >> days after it was cut... and we're cutting another one in 3.5 days... it is >> likely we will not get much meaningful feedback from users in the remaining >> 3.5 days... so essentially you end up with a ping-pong of break... skip... >> fix since if a bleeding edge user finds an issue in 4.0.56 we will have cut >> 4.0.57 by the time they report it to us and the fix ends up in 4.0.58... >> with a shorter vote duration, say 12h, the bleeding edge user reports the >> issue, we fix and the next release is the one they can use. Surely 27 hours is a *guidance* not a law. If a project's community wants to run fast then presumably they also have the commit rate to
Re: How can we support a faster release cadence?
That is a mischaracterization of the git story which was always about being able to support multiple version control tools. Yes people were concerned about the social side but we wouldn't be Apache without that debate. Same here. All you are seeing is some natural skepticism about the claims being made. The door is open though to a well considered proposal that this exercise should help refine. Sent from my iPhone > On Feb 13, 2014, at 7:58 AM, Benson Margulies wrote: > > This conversation goes in a circle. I see two positions: > > 1: Cadence releases are inevitably incompatible with Apache community values. > 2: Cadence releases are not inevitably incompatible with Apache > community values. > > People who take the first position see this desire to use cadence as > weakening of values and the brand. People who take the second position > are frustrated. > > Note the phrase, 'not inevitably'. No one here is claiming, in the > absence of an experiment, that this idea will inevitably lead to a > perfectly healthy expression of Apache Community values. > > This conversation reminds me of the early days of the git discussion. > At that time, some folks were convinced that 'git === fork culture'. > Since 'fork culture' is pretty clearly incompatible with Apache > community values, it took a very long time for us to decide to perform > an _experiment_ in git usage to see what would happen. OK, here we > are, the git experiment has been deemed a success. > > The following is utterly non-rhetorical. Something happened over the > course of long discussion to move from 'git is evil, go away' to > 'infra is willing to put effort into the infrastructure to support an > experiment.' What was it, and is there any hope of following that > path? > > > >> On Thu, Feb 13, 2014 at 12:02 AM, Phil Steitz wrote: >>> On 2/12/14, 7:23 PM, Marvin Humphrey wrote: On Wed, Feb 12, 2014 at 10:46 AM, Phil Steitz wrote: I know this looks old-fashioned, even downright anachronistic to "push-hourly-from-CI" people; but deciding *what* to release *as a community* is an important responsibility of ASF PMCs. Putting things on a rigid schedule basically skips this step, which, IMHO is a core part of our common culture and values. >>> Should projects who wish to release on a regular schedule avoid Apache? >> >> I agree with Joe that that is the wrong question to ask. The right >> question is what are the basic principles and values that >> *communities* should buy into when deciding to join Apache. I >> proposed a couple of them above. How releases happen, how policy >> compliance is assured are secondary - the main thing communities >> need to ask themselves when deciding to join the ASF is do they want >> to do open, community-based development the way it is done here. If >> cutting releases on a predetermined schedule is somehow a >> "requirement" for them, the first question to ask is "why" and if >> there is a good answer to that question then the second question is >> how do you do that in a way that is consistent our principles. >> >> Phil >>> >>> Marvin Humphrey >>> . >>> >>
Re: How can we support a faster release cadence?
This conversation goes in a circle. I see two positions: 1: Cadence releases are inevitably incompatible with Apache community values. 2: Cadence releases are not inevitably incompatible with Apache community values. People who take the first position see this desire to use cadence as weakening of values and the brand. People who take the second position are frustrated. Note the phrase, 'not inevitably'. No one here is claiming, in the absence of an experiment, that this idea will inevitably lead to a perfectly healthy expression of Apache Community values. This conversation reminds me of the early days of the git discussion. At that time, some folks were convinced that 'git === fork culture'. Since 'fork culture' is pretty clearly incompatible with Apache community values, it took a very long time for us to decide to perform an _experiment_ in git usage to see what would happen. OK, here we are, the git experiment has been deemed a success. The following is utterly non-rhetorical. Something happened over the course of long discussion to move from 'git is evil, go away' to 'infra is willing to put effort into the infrastructure to support an experiment.' What was it, and is there any hope of following that path? On Thu, Feb 13, 2014 at 12:02 AM, Phil Steitz wrote: > On 2/12/14, 7:23 PM, Marvin Humphrey wrote: >> On Wed, Feb 12, 2014 at 10:46 AM, Phil Steitz wrote: >> >>> I know this looks old-fashioned, even downright anachronistic to >>> "push-hourly-from-CI" people; but deciding *what* to release *as a >>> community* is an important responsibility of ASF PMCs. Putting >>> things on a rigid schedule basically skips this step, which, IMHO is >>> a core part of our common culture and values. >> Should projects who wish to release on a regular schedule avoid Apache? > > I agree with Joe that that is the wrong question to ask. The right > question is what are the basic principles and values that > *communities* should buy into when deciding to join Apache. I > proposed a couple of them above. How releases happen, how policy > compliance is assured are secondary - the main thing communities > need to ask themselves when deciding to join the ASF is do they want > to do open, community-based development the way it is done here. If > cutting releases on a predetermined schedule is somehow a > "requirement" for them, the first question to ask is "why" and if > there is a good answer to that question then the second question is > how do you do that in a way that is consistent our principles. > > Phil >> >> Marvin Humphrey >> . >> >
