Fwd: [VOTE] Graduate Helix from Apache Incubator to TLP

[kishore g]

FYI - Helix community is taking a vote on graduating Helix to TLP

-- Forwarded message --
From: kishore g 
Date: Mon, Nov 11, 2013 at 7:06 PM
Subject: [VOTE] Graduate Helix from Apache Incubator to TLP
To: dev 


Hi,

As the discussion about Graduation have settled down, I am calling for the
vote.

Apache Helix entered Incubator in October 2012. We have made significant
progress in incubation. Some of the highlights being

   - Cut two releases with PPMC being the release managers. Well documented
   release process that makes it easy to cut new releases.
   - Added 3 new committers, 2 from LinkedIn and 1 outside of LinkedIn. We
   already have 2 committers outside of LinkedIn.
   - Added 1 member to PPMC.
   - Kept the status page uptodate with all relevant information.
   - Followed Apache process and almost self governed.

Community

   - We have been responsive to inquiries from user. Also adding additional
   features as needed.
   - We are in development mode and constantly making improvements and
   refactoring. 574 commits over the last 12 months.
   http://www.ohloh.net/p/apachehelix
   - 250+ Jiras
   - 45 in dev mailing list and 57 in user mailing list
   - Gaining adoption outside of LinkedIn.
   http://mvnrepository.com/artifact/org.apache.helix
   - All code reviews done via Apache review board.

Please cast your votes:

[ ] +1 Graduate Apache Helix from Incubator
[ ] +0 Indifferent to graduation status of Apache Helix
[ ] -1 Reject graduation of Apache Helix from Incubator

This vote will remain open for at least 72 hours from now.

Thanks,
Kishore G

Re: the Voting Status monitor is overloaded

[David Crossley]

Lahiru Sandaruwan wrote:
> > 
> > Release Apache Stratos 3.0.0 Incubating RC4
> 
> Will send the result correctly again.
> 
> Thanks.

Cleared now.

> > They added (passed) at the end of Subject.

FIXME: perhaps voter/voter.py needs additional code to handle such

-David

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Cultivating Outstanding IP Stewards

[Alex Harui]

On 11/14/13 9:07 PM, "Marvin Humphrey"  wrote:

>On Wed, Nov 13, 2013 at 10:47 AM, Alex Harui  wrote:
>> I still think that having a "Release Auditor" role provides backup for
>> getting incubator releases out without having folks have to be on the
>>IPMC
>> to approve the legal aspects of a release.  Just like any ASF Member can
>> backup busy PMC Chairs for some actions, any TLP PMC member should be
>>able
>> to backup a busy IPMC member for release auditing.
>
>Speaking as someone who would presumably be suitable for this "Release
>Auditor" role, I'm opposed to the idea -- and not just because I don't
>want to
>get stuck doing all the dirty work.
>
>People who sign up to Mentor a podling should expect to vote on releases
>--
>especially the first.  The Incubator PMC tasks Mentors with overseeing
>the IP
>clearance processes.  A Mentor who votes +1 on the first incubating
>release is
>implicitly affirming that IP clearance was done properly -- because that
>was
>their assignment, and if something had gone awry they would surely not
>vote to
>release.
Well, sure, clearly a highly-engaged mentor can better manage IP
clearance.  But is release voting really an approval of IP clearance?  I
thought it was more about IP "maintenance": making sure that everything in
the package has a header.  Usually there is a significant amount of time
between the incubating IP hitting the repo and it being offered for
release and I thought the clearance had to happen when it hit the repo,
not at release voting time.

>
>A +1 vote from a "Release Auditor" who did not participate in IP
>clearance is
>much less meaningful: all it tells you is that whatever superficial
>inspection
>they performed on the finished product did not reveal any defects.  If
>some
>committer mistakenly attaches an ALv2 header to a file that shouldn't have
>one, a "Release Auditor" won't find that.  To catch such problems, you
>need
>someone monitoring the the dev and commits lists: possibly a Mentor,
>ideally a
>project contributor.

I thought the main point of this thread was to find a way to unblock
podlings looking to release but their mentors dis-engaged, even
temporarily. Are you saying that the IPMC members who step in to help
(like the ones who recently stepped in for VXQuery) must do the forensics
of IP clearance by scanning the commit emails?  Seems like folks doing
"release auditing" can do that as well if that's really required.  We
might even make a tool that searches through repo history for add/remove
of copyrights.


>
>The most meaningful +1 votes are those cast by enlightened core
>contributors,
>because they speak from deep knowledge of the code base and its history.
>IP
>stewardship is a continuous process, and the Incubator's goal should be to
>graduate communities with the motivation and expertise to attend to it
>over
>the long term -- not to certify code.
Agreed.  The only purpose of having a Release Auditor role is to expand
the pool of folks who can vote on a release without requiring them to
become full-fledged IPMC members.  Now if you're saying that having backup
voters is not going to meet some requirement of IP safety, it seems like
it can just be made a requirement of a backup vote to do whatever that
work is.  If you're saying that will never work because the only folks who
can validate a release are folks who are engaged in the podling, then even
having other IPMC folks backup them isn't going to work either, and
solutions need to be found to somehow get those mentors to find the time
to meet their obligations.

-Alex


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[VOTE] Graduate Ambari from Apache Incubator

[Yusaku Sako]

This is a call for vote to graduate Ambari from Apache Incubator.

The Apache Ambari project has been incubating since August 2011.
We have made significant progress with the project during the two years
of Incubation, adding 27 committers for a total of 36 committers [1], and
producing 8 releases following ASF policies and guidelines.
The Apache Ambari community has voted to graduate Ambari as a TLP [2].
The community vote results can be found at [3].
The discussion thread for the board resolution can be found at [4].

Please cast your votes:

[  ] +1 Graduate Ambari from Incubator
[  ] +0 Indifferent to graduation status of Ambari
[  ] -1 Reject graduation of Ambari from Incubator

This vote will remain open for at least 72 hours from now.
Please find the proposed board resolution below.

[1] http://people.apache.org/committers-by-project.html#ambari
[2] http://markmail.org/thread/cp5ajf2uvfl3oj66
[3] http://markmail.org/message/l6zss4rgfcs3gvpm
[4] http://markmail.org/thread/36dplr3pwzmazwmg

Regards,
Yusaku Sako

###

X. Establish the Apache Ambari Project

  WHEREAS, the Board of Directors deems it to be in the best
  interests of the Foundation and consistent with the
  Foundation's purpose to establish a Project Management
  Committee charged with the creation and maintenance of
  open-source software, for distribution at no charge to
  the public, related to Hadoop cluster management.

  NOW, THEREFORE, BE IT RESOLVED, that a Project Management
  Committee (PMC), to be known as the "Apache Ambari Project",
  be and hereby is established pursuant to Bylaws of the
  Foundation; and be it further

  RESOLVED, that the Apache Ambari Project be and hereby is
  responsible for the creation and maintenance of software
  related to Hadoop cluster management;
  and be it further

  RESOLVED, that the office of "Vice President, Apache Ambari" be
  and hereby is created, the person holding such office to
  serve at the direction of the Board of Directors as the chair
  of the Apache Ambari Project, and to have primary responsibility
  for management of the projects within the scope of
  responsibility of the Apache Ambari Project; and be it further

  RESOLVED, that the persons listed immediately below be and
  hereby are appointed to serve as the initial members of the
  Apache Ambari Project:

* Babiichuk Andriy (ababiichuk)
* Arun Murthy (acmurthy)
* Aleksandr Kovalenko (akovalenko)
* Antonenko Aleksandr Igorevich (alexantonenko)
* Andrii Tkach (atkach)
* Bernd Fondermann (berndf)
* Billie Rinaldi (billie)
* Christopher Douglas (cdouglas)
* Chad Roberts (croberts)
* Devaraj Das (ddas)
* Dmitry Lysnichenko (dmitriusan)
* Dmytro Sen (dsen)
* Eric Yang (eyang)
* Hitesh Shah (hitesh)
* Jagane Sundar (jagane)
* Jaimin Jetly (jaimin)
* Jitendra Pandey (jitendra)
* John Speidel (jspeidel)
* Kan Zhang (kzhang)
* Mahadev Konar (mahadev)
* Papirkovskyy Myroslav (mpapirkovskyy)
* Nate Cole (ncole)
* Oleksandr Diachenko (odiachenko)
* Owen O’Malley (omalley)
* Oleg Nechiporenko (onechiporenko)
* Ramya Sunil (ramya)
* Varun Kapoor (reznor)
* Sumit Mohanty (smohanty)
* Srimanth Gunturi (srimanth)
* Siddharth Wagle (swagle)
* Thomas Beerbower (tbeerbower)
* Suhas (vgogate)
* Vikram Dixit K (vikram)
* Vinod Kumar Vavilapalli (vinodkv)
* Xi Wang (xiwang)
* Yusaku Sako (yusaku)


  NOW, THEREFORE, BE IT FURTHER RESOLVED, that Yusaku Sako
  be appointed to the office of Vice President, Apache Ambari, to
  serve in accordance with and subject to the direction of the
  Board of Directors and the Bylaws of the Foundation until
  death, resignation, retirement, removal or disqualification,
  or until a successor is appointed; and be it further

  RESOLVED, that the initial Apache Ambari PMC be and hereby is
  tasked with the creation of a set of bylaws intended to
  encourage open development and increased participation in the
  Apache Ambari Project; and be it further

  RESOLVED, that the Apache Ambari Project be and hereby
  is tasked with the migration and rationalization of the Apache
  Incubator Ambari podling; and be it further

  RESOLVED, that all responsibilities pertaining to the Apache
  Incubator Ambari podling encumbered upon the Apache Incubator
  Project are hereafter discharged.

-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you

Re: [DISCUSS] Apache Ambari Graduation Resolution Draft

[Yusaku Sako]

Thank you for reviewing, David.
Since there have not been any objection for the resolution draft, we
will start an IPMC recommendation vote thread for graduation.

Yusaku


On Tue, Nov 12, 2013 at 6:38 PM, David Crossley  wrote:
> I compared the text of your resolution to that of the template.
> All appears to be okay.
>
> Good to see a solid number of people on your initial PMC.
>
> -David
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Do we need a disclaimer? (Storm)

[Craig L Russell]

IIRC, JSPWiki had exactly the same issue when it entered the incubator.

There were a non-Apache release or two while it was incubating, using the 
non-Apache package names, hosted on non-Apache servers and announced on 
non-Apache mail lists. 

Since it wasn't an Apache release, it was not announced on announce at 
apache.org but was announced on the Apache incubating user and dev lists. 

I think Storm could do the same. There is specific interest in the incubating 
Storm community but not general interest in the wider Apache community.

Craig

On Nov 15, 2013, at 7:10 AM, P. Taylor Goetz wrote:

> Agreed. It will not be hosted or linked to from any Apache site.
> 
> On another thread on the storm dev list, I have an open question as to 
> whether or not it’s okay to announce it (with a disclaimer that it is not an 
> Apache release) on the Apache mailing lists 
> dev/u...@storm.incubator.apache.org, or if any announcements should only go 
> to the google groups mailing list.
> 
> - Taylor
> 
> On Nov 15, 2013, at 10:02 AM, Luciano Resende  wrote:
> 
>> Also, if it's not an Apache release, it probaly should not be hosted and
>> listed at Apache to avoid confusion.
>> 
>> On Thursday, November 14, 2013, Ted Dunning wrote:
>> 
>>> First few words should read "A disclaimer ..."
>>> 
>>> I blame a combo of jet lag and *really* slow net link.  Not the guy who hit
>>> send without proofing, of course.
>>> 
>>> On Fri, Nov 15, 2013 at 7:41 AM, Ted Dunning 
>>> >
>>> wrote:
>>> 
 
 I disclaimer to clarify that the 0.9.0 release is neither an Apache
 top-level project release nor an Apache incubator release is probably
>>> good.
 A file name like DISCLAIMER might be good.
 
 I would worry about it being clear rather than being totally crafted by a
 true legal mind.
 
 
 On Fri, Nov 15, 2013 at 4:48 AM, P. Taylor Goetz 
 
 wrote:
 
> The Strom project is just entering the incubator. We have promised our
> community that we will issue a stable 0.9.0 release prior to switching
>>> over
> to the Apache release process. We are currently in a release candidate
> process.
> 
> Now that we are an Incubator project, but not yet releasing under the
> Apache process, should we be including a disclaimer with our pre-Apache
> releases stating so?
> 
> It feels like we should have some sort legalese in place.
> 
> - Taylor
> -
> To unsubscribe, e-mail: 
> general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: 
> general-h...@incubator.apache.org
> 
> 
 
>>> 
>> 
>> 
>> -- 
>> Sent from my Mobile device
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:craig.russ...@oracle.com
P.S. A good JDO? O, Gasp!


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Do we need a disclaimer? (Storm)

[P. Taylor Goetz]

Agreed. It will not be hosted or linked to from any Apache site.

On another thread on the storm dev list, I have an open question as to whether 
or not it’s okay to announce it (with a disclaimer that it is not an Apache 
release) on the Apache mailing lists dev/u...@storm.incubator.apache.org, or if 
any announcements should only go to the google groups mailing list.

- Taylor

On Nov 15, 2013, at 10:02 AM, Luciano Resende  wrote:

> Also, if it's not an Apache release, it probaly should not be hosted and
> listed at Apache to avoid confusion.
> 
> On Thursday, November 14, 2013, Ted Dunning wrote:
> 
>> First few words should read "A disclaimer ..."
>> 
>> I blame a combo of jet lag and *really* slow net link.  Not the guy who hit
>> send without proofing, of course.
>> 
>> On Fri, Nov 15, 2013 at 7:41 AM, Ted Dunning 
>> >
>> wrote:
>> 
>>> 
>>> I disclaimer to clarify that the 0.9.0 release is neither an Apache
>>> top-level project release nor an Apache incubator release is probably
>> good.
>>> A file name like DISCLAIMER might be good.
>>> 
>>> I would worry about it being clear rather than being totally crafted by a
>>> true legal mind.
>>> 
>>> 
>>> On Fri, Nov 15, 2013 at 4:48 AM, P. Taylor Goetz 
>>> 
>>> wrote:
>>> 
 The Strom project is just entering the incubator. We have promised our
 community that we will issue a stable 0.9.0 release prior to switching
>> over
 to the Apache release process. We are currently in a release candidate
 process.
 
 Now that we are an Incubator project, but not yet releasing under the
 Apache process, should we be including a disclaimer with our pre-Apache
 releases stating so?
 
 It feels like we should have some sort legalese in place.
 
 - Taylor
 -
 To unsubscribe, e-mail: 
 general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: 
 general-h...@incubator.apache.org
 
 
>>> 
>> 
> 
> 
> -- 
> Sent from my Mobile device


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Majority vs Lazy Majority

[sebb]

On 9 November 2013 12:17, Justin Mclean  wrote:
> Hi,
>
>> Is there such a concept as "Lazy Majority" ?
> Yes many Apache projects define it (eg Ant, Kafka, Hadoop, Pig, Hive and 
> others ) as does Apache HTTP. [1]
> "Lazy majority decides each issue in the release plan."

The phrase is used, but it is not defined anywhere that I could find,
so it is either a typo for something else or it is meaningless.

In both cases the document needs to be tidied up and clarified.

> Different projects however  use different terms, as far as I can see  "Lazy 
> Majority" is used more than " "Majority Approval" but both have the same 
> rules, ie 3 +1s and more +1's than -1's.
>
> My guess is that "Lazy Majority" is used because Majority implies more than 
> 50% of possible voters need to vote.

My guess is that it is a misprint for Lazy Consensus.

> Thanks,
> Justin
>
> 1. http://httpd.apache.org/dev/guidelines.html
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Do we need a disclaimer? (Storm)

[Luciano Resende]

Also, if it's not an Apache release, it probaly should not be hosted and
listed at Apache to avoid confusion.

On Thursday, November 14, 2013, Ted Dunning wrote:

> First few words should read "A disclaimer ..."
>
> I blame a combo of jet lag and *really* slow net link.  Not the guy who hit
> send without proofing, of course.
>
> On Fri, Nov 15, 2013 at 7:41 AM, Ted Dunning 
> >
> wrote:
>
> >
> > I disclaimer to clarify that the 0.9.0 release is neither an Apache
> > top-level project release nor an Apache incubator release is probably
> good.
> >  A file name like DISCLAIMER might be good.
> >
> > I would worry about it being clear rather than being totally crafted by a
> > true legal mind.
> >
> >
> > On Fri, Nov 15, 2013 at 4:48 AM, P. Taylor Goetz 
> > 
> >wrote:
> >
> >> The Strom project is just entering the incubator. We have promised our
> >> community that we will issue a stable 0.9.0 release prior to switching
> over
> >> to the Apache release process. We are currently in a release candidate
> >> process.
> >>
> >> Now that we are an Incubator project, but not yet releasing under the
> >> Apache process, should we be including a disclaimer with our pre-Apache
> >> releases stating so?
> >>
> >> It feels like we should have some sort legalese in place.
> >>
> >> - Taylor
> >> -
> >> To unsubscribe, e-mail: 
> >> general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: 
> >> general-h...@incubator.apache.org
> >>
> >>
> >
>


-- 
Sent from my Mobile device

Re: Cultivating Outstanding IP Stewards

[sebb]

On 10 November 2013 08:00, Alex Harui  wrote:
> IMO, there are two problems:
>
> 1) We're trying to train folks to manage IP for their community but they
> have to seek approval from folks are aren't as vested in their community.
> My analogy is telling a new city council member: "Welcome to the city
> council.  For the next year all of your decisions will require
> ratification by 3 state senators".
>
> 2) Release voting takes a long time.  It would seem like tools should be
> able to reduce the time on several of the steps, except for this one from
> [1] "compile it as provided, and test the resulting executable on their
> own platform".
>
> Sometimes I think about trying to get on the IPMC and helping some podling
> get a release out but:
> A) Really, I just want to help check the legal aspects of a podling's
> release and don't have bandwidth to want to take on the other roles
> implied by being on the IPMC.
> B) I don't want to take the time to figure out how to build and test a
> release that I have no vested interest in.
>
> Now, incubating releases are not official releases, right?

Huh?

AIUI, they *are* official releases, but with certain caveats (the DISCLAIMER).

The source is published from the mirrors in the same way as for TLP releases.

That is why it is vital to get the NOTICE and LICENSE files right.

>  So why have
> such time- consuming requirements to get approval from the IPMC?  Let's
> assume that the podling folks tested the building and operation of the
> source package.  Could we build an ant script that any IPMC member or any
> PMC member from any TLP (to expand the pool of potential helpers to folks
> who supposedly know how) can run just to check:
>
> 1) source package has the name "incubating"
> 2) source package is signed
> 3) unzip source package
> 4) grab a tag from SVN/Git
> 5) Diff
> 6) Run Rat (without any fileset exclusions)
>
> Then some podling writes to general@ and says: "can we get legal approval
> to release? Please run the release checker ant script with the following
> inputs   "
>
> Then it could run while I read through all of the other ASF emails and
> eventually I get a report that contains mainly a list of non-Apache files
> in the RAT report that I review and comment on if needed.  To me, if
> you're reviewing a RAT report, you are a building inspector who has looked
> around inside.
>
> Can we make it that "simple"?
>
> For sure, if any podling member is qualified for IPMC before graduation
> they should be nominated and added, and I suppose we could also approve
> them to cast binding votes as a release checker which may be a lower bar
> and maybe less of a time commitment, but I think if it is possible to have
> a larger group of folks approve incubating releases mainly be reviewing
> RAT reports that might make it easier for a podling to get a release out
> the door and still assist in the training of the podling's future PMC
> members.
>
>
> [1] http://www.apache.org/dev/release.html#approving-a-release
>
> My two cents (probably more),
> -Alex
>
> On 11/9/13 9:38 PM, "Marvin Humphrey"  wrote:
>
>>On Sat, Nov 9, 2013 at 4:11 AM, Dave Brondsema  wrote:
>>> On 11/09/2013 02:23 AM, Jake Farrell wrote:
>>
 If mentors are not performing their duties to vote on a given releases
for
 a podling, then it is up to the IPMC as a whole to help that podling by
 doing the do diligence and casting a vote. We all asked to be apart of
the
 IPMC or where honored by a nomination and accepted the role. It is up
to us
 to show these podlings what the Apache was really means. These projects
 have all come to the ASF and we (the IPMC) have openly voted them into
 incubation, its up to us to help them succeed.
>>>
>>> While this is true in theory it's hard in practice to wrangle those
>>> votes together.
>>
>>That's not the only problem.  While IPMC volunteers who perform
>>"freelance"
>>release reviews keep the Incubator from grinding to a halt, our reliance
>>on
>>them undermines the Incubator's effectiveness as an IP clearinghouse.  I
>>wish
>>that we would redirect those volunteer energies elsewhere.
>>
>>IPMC members who vote +1 on an initial incubating release are endorsing
>>the
>>the code import and IP clearance process[1], as well as any work done
>>in-house
>>since incubation started.  Votes on subsequent incubating releases are
>>less
>>weighty because they chiefly endorse work done in-house since the last
>>release.
>>
>>Non-Mentors who swoop in at the last minute to vote +1 on a codebase
>>they've
>>never looked at produced by a community they've never interacted with are
>>not
>>in a position to make such endorsements, particularly for the first
>>incubating
>>release.
>>
>>They are like building inspectors who never go inside.
>>
 Merit stands above all else, and the contributors that you have
pointed out
 are all exceptional individuals that have advanced their projects and
 continued to do so after grad

[Result][Vote] Release Apache Stratos 3.0.0 Incubating RC4

[Lahiru Sandaruwan]

Hi All,

72 hours and more have passed now and the current vote thread is considered

concluded and passes with the following resolution:

Six +1 binding votes from the following IPMCs:

* Suresh maru

* Ant Elder

* Chip Childers

* Afkam Azeez

* Deepal Jayasingha

* Chris Mattmann

Eight +1 binding votes from the following PPMCs:

* Sajith Kariyawasam

* Reka Thirunavukkarasu

* Isuru Haththotuwa

* Lakmal Warusawithana

* Udara Liyanage

* Nirmal Fernando

* Isuru Perera

* Imesh Gunaratna


Two +1 non-binding votes

* Melan Nimesh

* Dinesh Bandara

Zero -1 votes

Here is the [Vote] thread at stratos dev list,

http://www.mail-archive.com/dev@stratos.incubator.apache.org/msg02047.html

[Vote] thread at general list,

http://www.mail-archive.com/general@incubator.apache.org/msg41954.html

*Thanks*


On Fri, Oct 25, 2013 at 10:53 PM, Lahiru Sandaruwan wrote:

> Hi all,
>
>
> This is the forth release candidate for Apache Stratos  3.0.0-incubating,
> the very first Stratos release at Apache.
>
> This is the IPMC vote. The PPMC vote [1] passed, with 9 binding +1s,
> including 2 from mentors/IPMC (Ant Elder and Chip Childers) and no -1s.
>
>
> This release fixes the following issues(Same as RC1):
>
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314521&version=12324964
>
>
> 
>
> *** Please download, test and vote. The vote runs for 72 hours, until
> Monday, 10.30 am PST, 11.00 am IST.
>
> Note that we are voting upon the source (tag), binaries are provided for
> convenience.
>
>
> This wiki page[1] explains Downloading the Release Candidate, Verifying
> the Candidate, Building Apache Stratos from source, and Carrying out a
> Smoke Test.
>
> We have explained configuring guides[2] and user guides[3] at wiki.
>
> Further, [4], [5], and [6] blogs also explain the testing release
> candidate packs using scripts in EC2 and Openstack IaaSes.
> The reason for not providing sample cartridges is that we test Cartridges
> based on Ubuntu cloud images and therefore we cannot distribute those with
> the release. Hence the blog posts [5] and [6].
>
> Thanks.
>
> Binary files and source files:
>
>
> https://dist.apache.org/repos/dist/dev/incubator/stratos/3.0.0-incubating-rc4/
>
>
> 
>
> Maven staging repos:
>
> 
>
> https://repository.apache.org/content/repositories/orgapachestratos-174/
>
> 
>
> The tag to be voted upon:
>
>
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-stratos.git;a=tag;h=ab166c282897d9db4d3f22863e67fdc8ddcccd61
>
> Tree view of the tag,
>
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-stratos.git;a=tree;h=661b5e19e00497431f552468535052751f115303;hb=c042d6df7becda9f38100aeb7c130b2a8870cb46
>
>
> 
>
> Stratos KEYS file containing PGP keys we use to sign the release:
>
>
> https://dist.apache.org/repos/dist/dev/incubator/stratos/3.0.0-incubating-rc1/KEYS
>
>
> [1] https://cwiki.apache.org/confluence/display/STRATOS/Testing+Procedure
> [2] https://cwiki.apache.org/confluence/display/STRATOS/Getting+Started
> [3] https://cwiki.apache.org/confluence/display/STRATOS/User+Guide
> [4]
> http://imesh.gunaratne.org/a/1/blog/getting-started-with-apache-stratos-incubating-initial-release/
> [5]
> http://dineshmethsiri.blogspot.com/2013/09/create-ec2-apache-stratos-ami.html
> [6]
> http://melannj.blogspot.com/2013/09/quick-start-apache-stratos-from-ec2.html
>
>
> Thanks.
>
>
>
> 
>
> [ ] +1
>
> [ ] 0
> [ ] -1 (explain why)
>
> --
> --
> Lahiru Sandaruwan
> Software Engineer,
> Platform Technologies,
> WSO2 Inc., http://wso2.com
> lean.enterprise.middleware
>
> email: lahi...@wso2.com cell: (+94) 773 325 954
> blog: http://lahiruwrites.blogspot.com/
> twitter: http://twitter.com/lahirus
> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>
>


-- 
--
Lahiru Sandaruwan
Software Engineer,
Platform Technologies,
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

email: lahi...@wso2.com cell: (+94) 773 325 954
blog: http://lahiruwrites.blogspot.com/
twitter: http://twitter.com/lahirus
linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146

Re: the Voting Status monitor is overloaded

[Lahiru Sandaruwan]

Hi David,

Sorry for being late to act.


On Fri, Nov 15, 2013 at 7:40 AM, David Crossley  wrote:

> Thanks to those who did follow-up. That clears a bit.
>
> Another plea from me to help you to clear the clutter:
>
> I reviewed the mail archives for the outstanding ones
> to see why the "Vote Monitor" did not detect their vote result.
>
> I do not have time to correct them nor to tweak voter.py
> but hope that others can utilise my work.
>
> Here is a summary:
>
> As expected in my original mail, some tallies added extra words
> to the Subject, so tricked the monitor.
>
> Others did not tally.
>
> Others tallied but did not add RESULT tag.
>
> Others did cancel but did not add CANCEL tag.
>
> There were a few "community graduation" votes which were "Fwd:"
> but did not summarise. Perhaps voter.py could detect these "notices".
>
> There were a few with common mis-spelings, such as the CANCLE one.
>
> Thanks to Branko, the regex is nice. People could help to expand.
>
> Some possible tweaks to voter/voter.py are flagged below.
>
> Some situations could be cleared with a new RESULT or CANCEL email.
>
> Please assist.
>
> Notes:
>
> 
> Release Apache Stratos 3.0.0 Incubating RC4
>

Will send the result correctly again.

Thanks.


> They added (passed) at the end of Subject.
>
> 
> Release Apache Tajo-0.2-incubating RC1
>
> Prepended tag CANCLE instead.
> (FIXME: voter/voter.py needs additional code to handle such typo errors.)
>
> (Now a follow-up has done a reply with CANCEL.)
>
> 
> Apache Ambari 1.4.1-incubating RC1
>
> No-one did summarise.
>
> 
> Graduate Apache Marmotta from incubator and become a TLP
>
> This was a community graduation vote.
> Used "Fwd:" but not summarised.
> (FIXME: perhaps voter/voter.py needs additional code to handle such
> "notices".)
>
> 
> Apache Kalumet 0.6-incubating release (3rd try)
>
> No-one did summarise.
>
> 
> Usergrid BaaS Stack for Apache Incubator
>
> No-one did CANCEL.
> (A subsequent new thread was summarised, but this old one remains.)
>
> 
> : Release Apache Sentry 1.2.0 incubating (rc0)
>
> Was tallied but no RESULT tag.
>
> 
> Apache Chukwa graduation
>
> Was tallied and RESULT, but different thread with different Subject.
>
> 
> first milestone release of Apache Drill (incubating)
>
> Was tallied, but broke the thread and removed the VOTE tag.
>
> 
> Graduate Curator from Apache Incubator
>
> This was a community graduation vote.
> Used "Fwd:" but not summarised.
> (FIXME: perhaps voter/voter.py needs additional code to handle such
> "notices".)
>
> 
> Release Apache Provisionr version 0.4.0-incubating, RC0
>
> Was tallied and RESULT, but different thread with different Subject.
>
> 
> Release Curator 2.1.0-incubating
>
> No-one did summarise.
>
> 
> Release Apache Wave 0.4 based on RC3
>
> No-one did summarise.
>
> 
> Accept Stratos proposal as an incubating project
>
> Was tallied, and RESULT tag
> but had "Re: " in between the tags
> 2013-06-20
> (FIXME: voter/voter.py needs additional code to handle this.)
>
> 
> Accept Apache BeanShell in the Incubator
>
> No-one did summarise.
>
> 
> Release Apache Mesos 0.11.0-incubating (RC1)
>
> No-one did tag with CANCEL
>
> 
> helix 0.6.1-incubating
>
> Was tallied and RESULT, but different thread with different Subject.
>
> 
> S4 0.6.0 Release Candidate 4
>
> No-one did summarise.
>
> 
> S4 0.6.0 Incubating Release Candidate 3
>
> No-one did tag with CANCEL.
>
> 
> Recommending DeltaSpike for Graduation to an Apache Top Level Project
>
> This was a community graduation vote.
> Used "Fwd:" but not summarised.
> (FIXME: perhaps voter/voter.py needs additional code to handle such
> "notices".)
>
> 
>
> ---
> David Crossley wrote:
> > If the projects that are listed there cannot make the effort
> > to clean up, then do not be surpised if your subsequent
> > vote threads are overlooked. This is also not fair on the
> > other projects, especially new ones.
> >
> > -David
> >
> > David Crossley wrote:
> > > It seems that the brilliant "Voting Status" monitor
> > > has fallen into disrepair. Partly due to people
> > > not properly following up with a clear RESULT tally
> > > and partly perhaps inadequacies of the monitor script.
> > >
> > > Follow the top-left link from the Incubator home:
> > > http://incubator.apache.org/
> > >
> > > Items coloured any shade of orange need attention.
> > >
> > > We all need to care for these tools to assist us
> > > through incubation efficiently.
> > >
> > > Would people who have an interest in each open entry
> > > please review the email archives to see why your
> > > result summary tally email was not detected.
> > >
> > > Perhaps you forgot to prepend "[RESULT]".
> > > Or maybe changed the email Subject too and so
> > > confused the monitor.
> > >
> > > If so then please send a followup to your VOTE threa

Re: Cultivating Outstanding IP Stewards

[ant elder]

On Fri, Nov 15, 2013 at 5:08 AM, Marvin Humphrey  wrote:
> On Thu, Nov 14, 2013 at 1:08 AM, ant elder  wrote:
>> What i'd like to try is more similar to the pTLP approach previously
>> talked about. So take some existing podling, eg Stratos and/or
>> VXQuery, and give the PPMC binding votes. They have experienced and
>> active mentors so there will be oversight and nothing to worry about.
>> They already have experienced participants so know what they're doing
>> anyway. Anyone on the Incubator PMC can join in or watch what happens
>> and intervene at any point to have the experiment shutdown in the
>> unlikely event that they go wild.
>
> I think there are some issues with that approach.
>
> *   Being listed in the initial committer list of a proposal is not
> sufficient justification for granting a binding vote.  Each individual
> needs to demonstrate merit in the context of incubation and there needs to
> be a VOTE.
> *   When it's already excruciatingly difficult to get IPMC members to
> review releases, making such reviews optional just means hardly anybody
> will get around to them -- even if they have the best of intentions.
> *   Under this model, a first incubating release could be approved with solely
> PPMC votes.  We need more accountability than that.
>

No no, thats not what i'm suggesting, this isn't for some new podling
thats never done a release or anything its for a more experienced
podling thats been here for a while and already done a release but is
still here for some reason. So they mostly know what they're doing,
and they'll have active mentors. Please don't just rule this out as
too scary, its just an experiment and even when successful would be
unlikly ever become the mainstream approach for most podlings.

   ...ant

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org