[RESULT] [VOTE] Retire Taverna from Apache Incubator

[Stian Soiland-Reyes]

+1 Gale Naylor (binding)
+1 Sagar (binding)
+1 Stian Soiland-Reyes (binding)
+1 Stuart Owen (binding)
-1 Sube Singh
-1 Serban Mardaloescu

With 4 IPMC binding votes, and 2 objections,
the retirement vote for Taverna has passed.

Vote thread:
<https://lists.apache.org/thread.html/r559e0dd047103414fbf48a6ce1bac2e17e67504c546300f2751c067c%40%3Cdev.taverna.apache.org%3E>

Thank you to all that voted. 

I would like to give a large Thank You to Apache Software Foundation,
IPMC, mentors and volunteers for the patience of letting us have a go
at incubating.  I think we have learnt a lot.


For retiring we can request moving the Taverna git repositories to
the GitHub organization <https://github.com/taverna> where the 
license remains Apache License 2.0, so development can continue at any
pace (or none). 

Taverna PPMC folks and other interested; if you have not yet 
received an invite, feel free to reply personally with your GitHub
username I can add you there as a "Caretaker".

After de-branding ("Apache Taverna" -> "Taverna") we can also try to
move the website and documentation to GitHub Pages, hopefully ASF will
afford us a HTTP redirect.


-- 
Stian Soiland-Reyes
https://orcid.org/-0001-9842-9718


On Mon, 3 Feb 2020 14:07:50 +, Stian Soiland-Reyes  wrote:
> Hi,
> 
> I think we have to be honest with ourselves. 
> 
> While we had a good go at Taverna in the Apache Incubator, and lots of
> great effort over the years, we seem to have ground to a standstill.
> 
> It looks now almost impossible that we will graduate from the incubator
> and continue to thrive as a top-level Apache project.
> 
> I am as guilty as everyone - emails missed, builds not updated, releases
> not completed. The tasks were not large, but they still demand continued
> volunteer effort, which sadly we now seem to have not got anymore.
> 
> 
> I think I speak for all of you when I am grateful for all the time
> and effort everyone has committed since we moved to Apache Software
> Foundation in 2014. 
> 
> 
> It is therefore with sadness that I call this vote on retiring
> Taverna from the Apache Incubator.
> 
> 
> I don't think there is any shame if we come to this conclusion, 
> this project started 2003-02-24 and the world of bioinformatics and web
> services has changed significantly since then.
> 
> 
> For more information about what retirement means, see
> https://incubator.apache.org/guides/retirement.html
> 
> In terms of codebase my suggestion is that we move the git repositories
> to http://github.com/taverna/ with a clear README indication that
> they are no longer maintained.  
> 
> I think we should invite anyone on this list to join that GitHub
> organization for a passive curator role, or to delegate if someone 
> later wants to reboot the activity.
> 
> 
> See also previous discussion from 2019-09:
> https://lists.apache.org/thread.html/f9db87bf752c1b3f2f0ac5be9afd34d29a7cff76d66728a0f713%40%3Cdev.taverna.apache.org%3E
> 
> 
> 
> PLEASE INDICATE YOUR VOTE:
> 
> [ ] +1 Retire Taverna
> [ ]  0 Undecided
> [ ] -1 Do not retire Taverna
> 
> The vote is open for at least 72 hours for anyone on this list, with a
> lazy consensus.
> 
> -- 
> Stian Soiland-Reyes
> https://orcid.org/-0001-9842-9718
> 


pgpZf_N4did5f.pgp
Description: PGP signature

Re: Incubator podling reports due today

[Stian Soiland-Reyes]

On Fri, 6 Sep 2019, 08:54 Justin Mclean,  wrote:

>
> Taverna's report is a little confusing are you trying to graduate or
> retire?
>

That is exactly the challenge.. the podling needs a "last push" of releases
so the code base is IP cleared (challenge of many git repositories, but
only some of these have had Incubator releases).

But through this year there has not been much PPMC effort towards that
lift, and lacking that I have had to say we have to look at the alternative
of retiring.

>

Re: [VOTE] Accept MesaTEE into Apache Incubator

[Stian Soiland-Reyes]

+1 (binding)

(I see you now have 4 mentors, do you still need one more?)

On Tue, 13 Aug 2019 23:40:47 -0700, Zhijie Shen  wrote:
> Hi all,
> 
> After gauging the interest of MesaTEE (discussion thread:
> https://lists.apache.org/thread.html/323983a2875dd44ef19a3771ec329d5920d4d04bbdde18aab70dbe08@%3Cgeneral.incubator.apache.org%3E),
> I would like to call a VOTE to accept it into the Apache Incubator.
> 
> Please cast your vote:
> 
>   [ ] +1, bring MesaTEE into Incubator
>   [ ] +0, I don't care either way
>   [ ] -1, do not bring MesaTEE into Incubator, because...
> 
> The vote will open at least for 72 hours and only votes from the Incubator
> PMC are binding.
> 
> Thanks,
> Zhijie
> 
> ==
> MesaTEE Apache Incubation Proposal
> 
> = Abstract =
> 
> MesaTEE is a framework for universal secure computing.
> 
> = Proposal =
> 
> MesaTEE is the next-gen solution to enable general computing service for
> security-critical scenarios. It will allow even the most sensitive data to
> be
> securely processed to enable offshore businesses without leakage.
> 
> The solution combines the advanced Hybrid Memory Safety (HMS) model and the
> power of the Trusted Computing technologies (e.g., TPM) as well as the
> Confidential Computing technologies (e.g., Intel SGX).
> 
>   * Code base:
> * https://github.com/mesalock-linux/mesatee
> * https://github.com/baidu/rust-sgx-sdk
>   * Website: https://mesatee.org
>   * Documentation: https://mesatee.org/doc/mesatee_sdk/
> 
> = Background =
> 
> The emerging technologies of big data analytics, machine learning,
> cloud/edge
> computing, and blockchain are significantly boosting our productivity, but
> at
> the same time they are bringing new confidentiality and integrity concerns.
> On
> public cloud and blockchain, sensitive data like health and financial
> records
> may be consumed at runtime by untrusted computing processes running on
> compromised platforms; during in-house data exchange, confidential
> information
> may cross different clearance boundaries and possibly fall into the wrong
> hands;
> also not to mention the privacy issue arises in offshore data supply chains.
> 
> Although the consequences of data breaching have been extensively
> elaborated, we
> should also note that proprietary computing algorithms themselves, such as
> AI
> models, also need to be well protected. Once leaked, attackers can steal the
> intellectual properties, or launch whitebox attacks and easily exploit the
> weaknesses of the models.
> 
> Facing all these risky scenarios, we are in desperate need of a trusted and
> secure mechanism, enabling us to protect both private data and proprietary
> computing models during a migratable execution in potentially unsafe
> environments, yet preserving functionalities, performance, compatibility,
> and
> flexibility. MesaTEE is targeting to be, as we call it, the full "Universal
> Secure Computing" stack, so it can help users resolve these runtime security
> risks.
> 
> MesaTEE aims to promote the development of universal secure computing
> ecosystem
> through open source and openness, to provide basic support for trust
> protection
> for the productivity revolution brought by big data and AI, to completely
> solve
> the data exchange or multi-party computing between departments/companies, to
> enable privacy-crucial services such as financial and medical care using
> blockchain/cloud services, and to convoy businesses that are closely
> related to
> life and safety such as autonomous driving. MesaTEE has been working closely
> with mainstream cloud computing/blockchain/chip vendors and
> universities/research institutions to promote hardware TEE, software memory
> safety, and versatile computing services to create an internationally
> protected
> and flexible secure computing framework. MesaTEE’s open-source release will
> greatly accelerate the development of the next generation of big data
> business
> applications, and it is also of great importance to promoting AI in all
> business
> areas.
> 
> = Rationale =
> 
> MesaTEE stack redefines future AI and big data analytics by providing a
> trusted
> and secure offshore computing environment. The confidentiality and privacy
> of
> data and models can be well protected with MesaTEE, even if data and model
> originate from different parties with no mutual trust. Moreover, the
> computing
> platform itself is not necessarily trusted either. The Trusted Computing
> Base
> (TCB) can thus be largely reduced to MesaTEE framework alone. A detailed
> description of target use-cases can be found at
> https://github.com/mesalock-linux/mesatee/blob/master/docs/case_study.md.
> 
> We believe that Apache way of open source community empowers MesaTEE to
> attract
> a diverse set of contributors who can bring new ideas into the project.
> 
> = Initial Goals =
> 
>   * Move the existing codebase, website, documentation, and mailing lists
> to an
> Apache-hosted infrastructure.
>   * Integrate wi

Re: [DISCUSS] Incubation Proposal of MesaTEE

[Stian Soiland-Reyes]

On Sat, 10 Aug 2019 10:12:59 -0500, Matt Sicker  wrote:
> I’d most likely be interested in mentoring this project, but I’m not that
> experienced in incubator mentorship. If we have another more experienced
> mentor to work with us, I’d be happy to mentor as well.

I can also join as mentor.

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

Re: overzealous bureaucracy (was: [VOTE] Zipkin leave incubator, return back to OpenZipkin)

[Stian Soiland-Reyes]

On Wed, 19 Jun 2019 11:10:14 -0400, Jim Jagielski  wrote:
> My only comment here is that the Incubator performed a legal action in
> accepting Zipkin; in doing so, Zipkin enjoyed some level of ASF
> services as well as legal protection.

> To dissolve that 'relationship', there should be a clear trail of
> intent and action in doing so, not only by Zipkin but also by the
> Incubator itself.

Agree - we only need to do the VOTE so there is sufficient oversight to
confirm the dissolvement; as the Incubator formally is the custardian.

If a podling is moving OUT of ASF then that indicates that the ASF Way
(or our attempt to implement that) was not right for them. That is a
fair position that would be true for many brilliant open source
projects.

Consequently, this means that additional oversight should be done by
IPMC and mentors to check that the decision to move out/retire was still
done with podling community consensus, and that it is not just a fork,
or done a whim.

Before I casted my vote on Zipkin I checked the relevant archives and
threads and made up my own mind. 

Personalities have certainly played into this case on both sides, as
well as technical and bureaucratic hurdles.  I think we have all learnt
from this.

I found Zipkin community has discussed this at large internally and with
the board, and there was also a consensus from active podling PMC
members - so in that case, yes we morally cannot stop them. 

However IPMC members can't easily come to that conclusion collectively
without having a point of action (e.g. the VOTE).

It might be noisy and seem odd, but it is also our responsibility -
podlings join ASF incubator in good faith and are not autonomous from
day one.

-- 
Stian Soiland-Reyes
https://orcid.org/-0001-9842-9718


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

Re: [VOTE] Zipkin leave incubator, return back to OpenZipkin

[Stian Soiland-Reyes]

On Tue, 18 Jun 2019 09:21:42 +0800, Sheng Wu  wrote:
> This is a call for official vote of Zipkin leave from incubator, and return 
> back to OpenZipkin.

+1 (binding)

-- 
Stian Soiland-Reyes
https://orcid.org/-0001-9842-9718


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

NOTICE attribution for derived work from CC-BY originals?

[Stian Soiland-Reyes]

Dave and others,
remember this old thread (see below)

Taverna is revisiting this old license issue and think we've come round to a
way to avoid distributing CC-BY code, but would instead distribute our
Derived Work by hard-coding what was previosuly auto-generated Java code.

As CC-BY unlike CC-BY-SA (share-alike) then only require attribution we
then only need to keep the attribution - this would most naturally then
go into NOTICE rather than LICENSE as the CC-BY license do not apply to
the derived work (and the attribution also applies to the *.class files
in the JAR)


Obviously the wording in NOTICE then needs to be precise to not imply
that the generated *.java is CC-BY licensed (they would have the regular
Apache file header)

Would you be able to comment on if the approach in 
https://github.com/apache/incubator-taverna-language/pull/43
https://github.com/apache/incubator-taverna-language/blob/no-ontologies/NOTICE#L11
would be a good way forward?



On Thu, 24 May 2018 12:25:47 -0700, Dave Fisher  wrote:
> Hi -
> 
> -1 (binding)
> 
> There are several files in the source release that are licensed as:
> Creative Commons Attribution 3.0 License
> http://creativecommons.org/licenses/by/3.0
> 
> This is a category B license. [1] I’ll note that Stian is listed as a 
> copyright holder for some of these … Either these need to be relicensed to a 
> category A license or some other mechanism will need to be found to make 
> these optional. The LICENSE file should include the other licenses and not 
> references to them.
> 
> Checksums and signature check out. Build and rat-check pass.
> 
> Regards,
> Dave
> 
> [1] http://www.apache.org/legal/resolved.html#category-b
> 
> > On May 24, 2018, at 8:12 AM, Stian Soiland-Reyes  wrote:
> > 
> > any more IPMC votes..? Last chance before GDPR! ;)
> > 
> > On Mon, 21 May 2018 10:57:40 +0100, Stian Soiland-Reyes  
> > wrote:
> >> The Taverna PPMC has voted to release:
> >> 
> >>  Apache Taverna Language 0.16.0-incubating
> >> 
> >> with +4 PPMC-binding votes. This email is the IPMC vote.
> >> 
> >> 
> >> Vote thread:
> >> https://lists.apache.org/thread.html/29405e13efcd3282e978982c2c4c02b1d1bf683460ce618c7248617a@%3Cdev.taverna.apache.org%3E
> >> 
> >> Result:
> >> https://lists.apache.org/thread.html/6c30d76520c2e933c4b93db7dc87cef42f2d34871f0b6f334020d451@%3Cdev.taverna.apache.org%3E
> >> 
> >> 
> >> This carries forward one +1 IPMC binding vote from myself.
> >> 
> >> 
> >> Apache Taverna Language is a set of APIs for workflow definitions (SCUFL2),
> >> Research Object Bundles and workflow inputs/outputs/run (DataBundle), as
> >> consumed and produced by the Apache Taverna workflow system.
> >> 
> >> The API includes support for the legacy formats from Taverna 2 and Taverna 
> >> 1,
> >> and can be also used independently of Apache Taverna 3.  The command line 
> >> tool
> >> tavlang can be used for conversion and inspection of research objects and
> >> workflow bundles.
> >> 
> >> 
> >> 
> >> 
> >> The release candidate to be voted over is available at:
> >> 
> >> https://dist.apache.org/repos/dist/dev/incubator/taverna/source/taverna-language-0.16.0-incubating-RC1/
> >> 
> >> 
> >> Checksums:
> >> 
> >> $ sha1sum *zip
> >> 1f6050994b4bd2661f343119cdcb18b83dc362cf  
> >> apache-taverna-language-0.16.0-incubating-source-release.zip
> >> 
> >> $ sha256sum *zip
> >> bcdba80fbea54b1532cb81b6846e5711f1efe98ad289ecd4a2c6dd2833767115  
> >> apache-taverna-language-0.16.0-incubating-source-release.zip
> >> 
> >> $ sha512sum *zip
> >> 008672c7f7cb1e6e461a2d5113aa111208970cfe9e0b3507fb3a34bc95957db094f0d8e8829beca9496cfa6a6d023943409335839bacd0bdedc82db87d14b9aa
> >>   apache-taverna-language-0.16.0-incubating-source-release.zip
> >> s
> >> 
> >> 
> >> 
> >> 
> >> Build the release candidate using:
> >> 
> >>mvn clean install
> >> 
> >> 
> >> 
> >> 
> >> The release candidates correspond to the following git commit:
> >> 
> >> https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-language.git;a=commit;h=c48ef9d339d7d68791691617ef2ddc56d195131e
> >> 
> >> 
> >> The release candidate is signed with an (updated) GPG key:
> >> https://www.apache.org/dist/incubator/taverna/KEYS
> >> 
> >> 
> >> A staged Maven repository is available 

Re: [DISCUSS] Retirement Policies related to GitHub/GitBox

[Stian Soiland-Reyes]

On Tue, 10 Jul 2018 23:19:01 -0500, Greg Stein  wrote:
> On Fri, Jun 29, 2018 at 9:35 PM Greg Stein  wrote:
> 
> > On Fri, Jun 29, 2018 at 1:10 PM Dave Fisher  wrote:
> > >...
> >
> >> For podlings that have an active GitHub through GitBox the implication of
> >> this step is that the IPMC will now have control of the GitHub auth.
> >>
> >> (1) What needs to be done to the archive to make it clear that the
> >> podling is retired? Shouldn’t the README.md be modified in a prior step?
> >>
> >> (2) Also, in some cases the retirement could mean the transfer of the
> >> GitHub project elsewhere. Do we want to force a fork, or allow the
> >> project’s GitHub to move elsewhere>
> >>
> >
> > This is important *today* ... please see:
> > https://issues.apache.org/jira/browse/INFRA-16698
> I transferred the mirrors of our two Taverna git-wip repositories. But a
> good question is: what to do with the old git-wip repos? Keep or toss? They
> aren't "part of" the ASF any more.

I think we agreed earlier on this particular case to permit a move
elsewhere GitHub-wise - but I am not sure if that should be a general
policy. A project should also be allowed to move to a different host
like GitLab.

I suggested in the issue for the git-wip repos, if we really want to
keep them around, then to do a "git rm *" and then add README.md that
says where they are moved to or why they are archived.

Then the code is still there in the git log at "use at own risk", since
it didn't graduate from the incubator, although the code was still
supposedly covered by the software grant to ASF and as ASF contributions
while in the incubator. And so that code "wants to stay open"

But "use at own risk" because it didn't graduate - in our case because
there were some unresolved IP issues. This should not be any different
than pre-incubator code being in the git log which may include code of a
different license.

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

Re: [VOTE] Retire AriaTosca podling

[Stian Soiland-Reyes]

On Thu, 28 Jun 2018 15:07:50 -0400, Suneel Marthi  wrote:
> The AriaTosca podling has decided to retire the project - see [1] [2]
> +1 - Yes, Retire the podling
> -1  - What ya thinking? Don't do it because ..


Sad to see AriaTosca go.. 

+1 (IPMC binding)

-- 
Stian Soiland-Reyes
https://orcid.org/-0001-9842-9718


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

Retiring legacy git repositories from podling?

[Stian Soiland-Reyes]

Hi,

The Taverna podling has its code in multiple git repositories
https://taverna.incubator.apache.org/code/
Most of these were imported from the initial Software Grant


The Taverna PPMC has voted to retire two legacy git repositories that
will stay behind when/if we graduate.

> https://github.com/apache/incubator-taverna-plugin-component
> https://github.com/apache/incubator-taverna-plugin-bioinformatics

VOTE Result:

https://lists.apache.org/thread.html/547b87fa93601d42ef77a778f80bf59fe9a300fffd7d3a6bcb7a7d81@%3Cdev.taverna.apache.org%3E


These code bases have NOT fully completed the IP clearance/license
checks (there would be a couple of files that have unknown authorship
or the odd GPL dependency), but have already got the Apache License
headers for the rest (majority) of the codebase, that was covered by
the Software Grant.  Would we need to remove/change those headers?

Do the IPMC need to vote on such 'retiring' of a code case?


Our plan is to do a GitHub owner transfer to our affiliated
https://github.com/taverna-extras/ --  but do let me know if you think
Apache Attic would be better (we could delete the files that miss the
headers).

Do IPMC think that it's OK that we do such a GitHub transfer
(effectively giving a HTTP redirect) rather than just
forking+deleting?

-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: graphviz as a potential apache project

[Stian Soiland-Reyes]

On Sun, 3 Jun 2018 13:44:42 -0700, Dave Fisher  wrote:
> It is certainly intriguing. I’ve done work in the past on PICT, PS, and PDF 
> generation.
> I can see great utility here with all of the DAG based workflows that are all 
> the rage right now.
> Sign me up to Mentor if the project comes to the Incubator.

I would also be willing to be a Mentor for graphviz.

We've used Graphviz in Taverna since 2005 or so (and still do), and it's
a great product in many ways that I am very grateful for. 

I see from their GitLab what seems like quite stable maintenance
activity across many contributors.

https://gitlab.com/graphviz/graphviz/

(Note: the code license is actually EPL1, not CDL)


The biggest challenge will indeed be the license/IP clearance - do they
have contact with AT&T that can help get a software grant? Then probably
they would need approval from all contributors since to do relicensing
to Apache License 2.0. This could be quite a task.


Some of the optional dependencies under
https://graphviz.gitlab.io/_pages/Download/Download_source.html are as
far as I understand LGPL or GPL - but this seems odd given that EPL
(except EPL2 with secondary license) is incompatible with GPL. Only a
problem for those distributing such binaries though.


-- 
Stian Soiland-Reyes
https://orcid.org/-0001-9842-9718


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

[CANCELLED] [VOTE] Release Apache Taverna Language 0.16.0-incubating RC1

[Stian Soiland-Reyes]

Thanks to all who voted.

This release-candidate is Cancelled, the Taverna podling will work to
address the licensing issues pointed out by Dave Fisher. 

Although our use of Creative Commons should be allowed by Legal's
resolved FAQ, we recognize that IPMC feelings are otherwise, so we'll
have to recode to avoid including these schema files.


Tally:

+1 Stian Soiland-Reyes (binding)
+1 Andy Seaborne (binding)
-1 David Fisher (binding)

On Mon, 28 May 2018 22:43:22 +0100, Stian Soiland-Reyes  
wrote:
> On Thu, 24 May 2018 12:25:47 -0700, Dave Fisher  wrote:
> > -1 (binding)
> 
> Thanks for checking!
> 
> > There are several files in the source release that are licensed as:
> > Creative Commons Attribution 3.0 License
> > http://creativecommons.org/licenses/by/3.0
> > 
> > This is a category B license. [1] 
> 
> We included the CC-BY-licensed ontologies for
> compatibility, as we saw the category-b license FAQ says:
> 
> > For small amounts of source that is directly consumed by the ASF
> > product at runtime in source form, and for which that source is
> > unmodified and unlikely to be changed anyway (say, by virtue of being
> > specified by a standard), inclusion of appropriately labeled source is
> > also permitted.  An example of this is the web-facesconfig_1_0.dtd,
> > whose inclusion is mandated by the JSR 127: JavaServer Faces
> > specification.
> 
> These OWL ontologies *are* directly consumed at runtime in source form,
> unmodified and unlikely to be changed (that would defy their purpose of
> compliance against their declared namespace).
> 
> We have discussed in Taverna that we could move these to be packaged
> outside ASF on GitHub (and somehow deployed to Maven Central by us
> wearing non-ASF hats, so that we can use them as "binaries". Do you
> think that workaround is necessary, or can we keep them given the "small
> amount" consideration?  
> 
> (They are not executable source code, but more like namespace
> declarations)
> 
> 
> See also https://issues.apache.org/jira/browse/TAVERNA-927
> 
> 
> > I’ll note that Stian is listed as a
> > copyright holder for some of these … Either these need to be
> > relicensed to a category A license or some other mechanism will need
> > to be found to make these optional. 
> 
> Yes, we did relicense to Apache License on several ontologies where Univ
> of Manchester were the sole copyright holder and so were covered by the
> Software Grant. 
> 
> Unfortunately some of the others have multiple institutions as copyright
> holders; we can try to work with their community to change these to a 
> CatA license - however Apache License might not be ideal either here as
> it is not compatible with GPL 2 (just 2+).
> 
> 
> > The LICENSE file should include the other licenses and not references
> > to them.
> 
> I agree, this seems to have been missed. 
> 
>  
> -- 
> Stian Soiland-Reyes
> https://orcid.org/-0001-9842-9718
> 
> 
> -
> 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: [VOTE] Release Apache Taverna Language 0.16.0-incubating RC1

[Stian Soiland-Reyes]

On Thu, 24 May 2018 12:25:47 -0700, Dave Fisher  wrote:
> -1 (binding)

Thanks for checking!

> There are several files in the source release that are licensed as:
> Creative Commons Attribution 3.0 License
> http://creativecommons.org/licenses/by/3.0
> 
> This is a category B license. [1] 

We included the CC-BY-licensed ontologies for
compatibility, as we saw the category-b license FAQ says:

> For small amounts of source that is directly consumed by the ASF
> product at runtime in source form, and for which that source is
> unmodified and unlikely to be changed anyway (say, by virtue of being
> specified by a standard), inclusion of appropriately labeled source is
> also permitted.  An example of this is the web-facesconfig_1_0.dtd,
> whose inclusion is mandated by the JSR 127: JavaServer Faces
> specification.

These OWL ontologies *are* directly consumed at runtime in source form,
unmodified and unlikely to be changed (that would defy their purpose of
compliance against their declared namespace).

We have discussed in Taverna that we could move these to be packaged
outside ASF on GitHub (and somehow deployed to Maven Central by us
wearing non-ASF hats, so that we can use them as "binaries". Do you
think that workaround is necessary, or can we keep them given the "small
amount" consideration?  

(They are not executable source code, but more like namespace
declarations)


See also https://issues.apache.org/jira/browse/TAVERNA-927


> I’ll note that Stian is listed as a
> copyright holder for some of these … Either these need to be
> relicensed to a category A license or some other mechanism will need
> to be found to make these optional. 

Yes, we did relicense to Apache License on several ontologies where Univ
of Manchester were the sole copyright holder and so were covered by the
Software Grant. 

Unfortunately some of the others have multiple institutions as copyright
holders; we can try to work with their community to change these to a 
CatA license - however Apache License might not be ideal either here as
it is not compatible with GPL 2 (just 2+).


> The LICENSE file should include the other licenses and not references
> to them.

I agree, this seems to have been missed. 

 
-- 
Stian Soiland-Reyes
https://orcid.org/-0001-9842-9718


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

Re: [VOTE] Release Apache Taverna Language 0.16.0-incubating RC1

[Stian Soiland-Reyes]

any more IPMC votes..? Last chance before GDPR! ;)

On Mon, 21 May 2018 10:57:40 +0100, Stian Soiland-Reyes  
wrote:
> The Taverna PPMC has voted to release:
> 
>   Apache Taverna Language 0.16.0-incubating
> 
> with +4 PPMC-binding votes. This email is the IPMC vote.
> 
>   
> Vote thread:
> https://lists.apache.org/thread.html/29405e13efcd3282e978982c2c4c02b1d1bf683460ce618c7248617a@%3Cdev.taverna.apache.org%3E
> 
> Result:
> https://lists.apache.org/thread.html/6c30d76520c2e933c4b93db7dc87cef42f2d34871f0b6f334020d451@%3Cdev.taverna.apache.org%3E
> 
> 
> This carries forward one +1 IPMC binding vote from myself.
> 
> 
> Apache Taverna Language is a set of APIs for workflow definitions (SCUFL2),
> Research Object Bundles and workflow inputs/outputs/run (DataBundle), as
> consumed and produced by the Apache Taverna workflow system.
> 
> The API includes support for the legacy formats from Taverna 2 and Taverna 1,
> and can be also used independently of Apache Taverna 3.  The command line tool
> tavlang can be used for conversion and inspection of research objects and
> workflow bundles.
> 
> 
> 
> 
> The release candidate to be voted over is available at:
> 
> https://dist.apache.org/repos/dist/dev/incubator/taverna/source/taverna-language-0.16.0-incubating-RC1/
> 
> 
> Checksums:
> 
> $ sha1sum *zip
> 1f6050994b4bd2661f343119cdcb18b83dc362cf  
> apache-taverna-language-0.16.0-incubating-source-release.zip
> 
> $ sha256sum *zip
> bcdba80fbea54b1532cb81b6846e5711f1efe98ad289ecd4a2c6dd2833767115  
> apache-taverna-language-0.16.0-incubating-source-release.zip
> 
> $ sha512sum *zip
> 008672c7f7cb1e6e461a2d5113aa111208970cfe9e0b3507fb3a34bc95957db094f0d8e8829beca9496cfa6a6d023943409335839bacd0bdedc82db87d14b9aa
>   apache-taverna-language-0.16.0-incubating-source-release.zip
> s
> 
> 
> 
> 
> Build the release candidate using:
> 
> mvn clean install
> 
> 
> 
> 
> The release candidates correspond to the following git commit:
> 
> https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-language.git;a=commit;h=c48ef9d339d7d68791691617ef2ddc56d195131e
> 
> 
> The release candidate is signed with an (updated) GPG key:
> https://www.apache.org/dist/incubator/taverna/KEYS
> 
> 
> A staged Maven repository is available for review at:
> https://repository.apache.org/content/repositories/orgapachetaverna-1019
> 
> 
> The changelog for this release is available from JIRA:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12334881&projectId=12318322
> 
> 
> 
> Please vote on releasing these packages as:
> 
>   Apache Taverna Language 0.16.0-incubating
> 
> 
> The vote is open for at least 72 hours and passes if a majority of at least
> three +1 Apache Incubator PMC votes are cast.
> 
> [ ] +1 Release this package
> [ ]  0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because...
> 
> 
> Anyone can participate in testing and voting, not just IPMC members,
> please feel free to try out the release candidate and provide your
> votes!
> 
> How to review a release? https://s.apache.org/review-release
> 
> 
> -- 
> Stian Soiland-Reyes
> https://orcid.org/-0001-9842-9718
> 
> 
> -
> 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: [VOTE] Release Apache SkyWalking (incubating) version 5.0.0-beta

[Stian Soiland-Reyes]

On Tue, 22 May 2018 22:33:21 +1000, mck  wrote:
>  - Peng Yongsheng, please remember to keep your english (ascii) name in the 
> email from field along with your real name: 彭勇升 
> When you sent the mail to IPMC there was no english name accompanying your 
> chinese name. Sheng is consistent in this practice, so is a good example. 
> I know it's unfortunate, but those of us that can't speak chinese simply find 
> it too difficult to distinguish and remember the chinese characters and names.
> This will also hinder you from getting responses and votes.

Alternatively I think if committers use mail-relay.apache.org
https://reference.apache.org/committer/email with an @apache.org From
address then the 'real name' can be in any language or form, as
demonstrated here by "mck" :)

(enabling Unicode-names in @apache.org usernames, that's
another battle for another decade..)

-- 
Stian Soiland-Reyes
The University of Manchester
https://www.esciencelab.org.uk/
https://orcid.org/-0001-9842-9718


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

Re: [VOTE] Release Apache SkyWalking (incubating) version 5.0.0-beta

[Stian Soiland-Reyes]

On Mon, 21 May 2018 15:31:49 +0800, "吴晟 Sheng Wu"  wrote:
> I understand in next time, we should add svn revision number. And do
> you suggest we should add checksum in the mail? 

Yes, checksums in the vote email can be good as they are easy to
cross-check, say if there is an RC2 vote followed by RC1,
a PMC member who accidentally tests the old one again would not get the
right checksum.


Another reason is archival - a checksum sent to the email list, while 
unencrypted it is archived in multiple distributed archives and so
becomes a permanent record about the versioned archive the PMC
(eventually) publish and easy for anyone (say a Debian maintainer) to
check/hardcode independent of the more origin-centric GPG signature.


This would also make it easier to detect a 'rogue committer' (or more
likely a wrong command line) that publish something that was not voted
on.  In the end the checksum files on the https://www.apache.org/dist/
should then match a vote email.  
(AFAIK, nobody has attempted to automate such a check :)


You have done well switching to secure sha512, but unlike say md5 and
sha1 these are unfortunately not so email-friendly due to long lines,
so if you want to try with sha512, sha512224, or fall back to sha1 for
votes.. I don't know what would be easiest for your project.

So I would let that be up to the SkyWalking community to decide, but
IMHO at least one of either either svn revision or checksum should be in
the email so it's clear what is being voted on. :)


-- 
Stian Soiland-Reyes
The University of Manchester
https://www.esciencelab.org.uk/
https://orcid.org/-0001-9842-9718


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

[VOTE] Release Apache Taverna Language 0.16.0-incubating RC1

[Stian Soiland-Reyes]

The Taverna PPMC has voted to release:

  Apache Taverna Language 0.16.0-incubating

with +4 PPMC-binding votes. This email is the IPMC vote.

  
Vote thread:
https://lists.apache.org/thread.html/29405e13efcd3282e978982c2c4c02b1d1bf683460ce618c7248617a@%3Cdev.taverna.apache.org%3E

Result:
https://lists.apache.org/thread.html/6c30d76520c2e933c4b93db7dc87cef42f2d34871f0b6f334020d451@%3Cdev.taverna.apache.org%3E


This carries forward one +1 IPMC binding vote from myself.


Apache Taverna Language is a set of APIs for workflow definitions (SCUFL2),
Research Object Bundles and workflow inputs/outputs/run (DataBundle), as
consumed and produced by the Apache Taverna workflow system.

The API includes support for the legacy formats from Taverna 2 and Taverna 1,
and can be also used independently of Apache Taverna 3.  The command line tool
tavlang can be used for conversion and inspection of research objects and
workflow bundles.




The release candidate to be voted over is available at:

https://dist.apache.org/repos/dist/dev/incubator/taverna/source/taverna-language-0.16.0-incubating-RC1/


Checksums:

$ sha1sum *zip
1f6050994b4bd2661f343119cdcb18b83dc362cf  
apache-taverna-language-0.16.0-incubating-source-release.zip

$ sha256sum *zip
bcdba80fbea54b1532cb81b6846e5711f1efe98ad289ecd4a2c6dd2833767115  
apache-taverna-language-0.16.0-incubating-source-release.zip

$ sha512sum *zip
008672c7f7cb1e6e461a2d5113aa111208970cfe9e0b3507fb3a34bc95957db094f0d8e8829beca9496cfa6a6d023943409335839bacd0bdedc82db87d14b9aa
  apache-taverna-language-0.16.0-incubating-source-release.zip
s




Build the release candidate using:

mvn clean install




The release candidates correspond to the following git commit:

https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-language.git;a=commit;h=c48ef9d339d7d68791691617ef2ddc56d195131e


The release candidate is signed with an (updated) GPG key:
https://www.apache.org/dist/incubator/taverna/KEYS


A staged Maven repository is available for review at:
https://repository.apache.org/content/repositories/orgapachetaverna-1019


The changelog for this release is available from JIRA:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12334881&projectId=12318322



Please vote on releasing these packages as:

  Apache Taverna Language 0.16.0-incubating


The vote is open for at least 72 hours and passes if a majority of at least
three +1 Apache Incubator PMC votes are cast.

[ ] +1 Release this package
[ ]  0 I don't feel strongly about it, but don't object
[ ] -1 Do not release this package because...


Anyone can participate in testing and voting, not just IPMC members,
please feel free to try out the release candidate and provide your
votes!

How to review a release? https://s.apache.org/review-release


-- 
Stian Soiland-Reyes
https://orcid.org/-0001-9842-9718


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

Re: [VOTE] Release Apache SkyWalking (incubating) version 5.0.0-beta

[Stian Soiland-Reyes]

On Sun, 20 May 2018 17:08:31 +0800, "吴晟 Sheng Wu"  wrote:
> Hi, IPMC 
> I am asking the release vote, again. :)  Haven't had one yet. Hope we can 
> have enough vote in 72 hours.

Remember 72 hours is not a time-out, but a minimum period to wait. :)

> Voting will start now (May 18th, 2018) and will remain open for at least 72 
> hours, Request all IPMC members to give their vote.

> [ ] +1 Release this package.
> [ ] +0 No opinion.
> [ ] -1 Do not release this package because….

My vote: +1 (binding)

+1 gpg signatures verified
+1 sha512 checksums correct
+1 git commit matches -src.tgz 
+1 Release archive has -incubating in filename
-1 Maven versions of submodules do NOT have -incubator or
   -incubating 
+1 Maven repo checksum matches binaries in dist
+0 src/bin DISCLAIMER present, but it says  "sponsored by Incubator" instead of
   "sponsored by the Apache Incubator PMC."
+1 src LICENSE/NOTICE
+1 bin zip vs .tar.gz
+1 bin LICENSE - very good! 
+1 bin NOTICE 
+0 mvn clean package mostly builds (see below)


build fails in apm-webapp because

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check (validate) on 
project apm-webapp: Execution validate of goal 
org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check failed: Plugin 
org.apache.maven.plugins:maven-checkstyle-plugin:2.17 or one of its 
dependencies could not be resolved: Could not find artifact 
org.apache.skywalking:apm-checkstyle:jar:5.0.0-beta in central 
(https://repo.maven.apache.org/maven2) -> [Help 1]

This is fixed by using "mvn install" instead within apm-checkstyle




> Release Candidate:
> *https://dist.apache.org/repos/dist/dev/incubator/skywalking/5.0.0-beta/


I strongly recommend using suffixes like -RC1 in the release candidate
URL and tag -- how do voters (and anyone checking the vote later) know if you
happened to make a 'second 5.0.0-beta' release candidate?  

For that reason the VOTE email should also include 
svn revision number from dist.apache.org, and/oor sha checksum of the
files under vote.  

Assuming r26864 (from "svn log") aka sha512 checksums

33b13cc7bc4ddea46d727ed8910c54c2e3b9acd6614a7f937e01e34ae6403942791ec3505d16de674605c665a4c0805271eb90a94775701d941462c530a99d11
  apache-skywalking-apm-incubating-5.0.0-beta-src.tgz
770ad70ad3e23fbd93ea675528a81735848a92557f91036b23652b4c2a0282a7198bf9a09fd4570f8bef180d956e81e4f93a9c2308106de1b3d815feeb0dfd84
  apache-skywalking-apm-incubating-5.0.0-beta.tar.gz
d4ca36ed94a6d3557b747fe3ba3daf1dee5dca6d0f827af404762344c41214b4e5ff2173536e6c2feac383d9d0bdbaa648a5f0b8eee9f1b0913734d2c5adfffa
  apache-skywalking-apm-incubating-5.0.0-beta.zip





> Maven 2 staging repository:
> *https://repository.apache.org/content/repositories/orgapacheskywalking-1011/org/apache/skywalking/
>  

> Release Tag :
> * v5.0.0-beta

Should be v5.0.0-beta-RC1 (or later) while under vote, and then re-tagged once
vote has been accepted.

> Release CommitID :
> * 5ddc4e714f2570421779a11f2589ffc32d2b8b21

(while incubating) please, include the URL of the git repository, particularly
as skywalking is for some reason not in git.apache.org

Assuming 
https://github.com/apache/incubator-skywalking/commit/5ddc4e714f2570421779a11f2589ffc32d2b8b21
and git submodules
 c02c12af12116121e25155d1f3fca0fadee5f2e9 
apm-protocol/apm-network/src/main/proto (v1.1.1)
 43ae106a15a77937a255c790a478c620b549d742 skywalking-ui 
(v5.0.0-alpha-44-g43ae106)

which means that 
https://github.com/apache/incubator-skywalking-ui/commit/43ae106a15a77937a255c790a478c620b549d742
is also covered by this release vote. 
But 43ae106a15a77937a255c790a478c620b549d742 in skywalking-ui does not have a 
corresponding tag there.
Presumably a v5.0.0-beta tag will be added there after successful vote.

> Keys to verify the Release Candidate :
> *  http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2EF5026E70A55777 
> corresponding to pen...@apache.org

+1 matches key from KEYS :)

> Guide to build the release from source :
> * 
> https://github.com/apache/incubator-skywalking/blob/master/docs/en/How-to-build.md

Very good, thank you!




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

Re: Altering PMC for graduation

[Stian Soiland-Reyes]

This is not uncommon, at least for filtering the initial PPMC members at
the point of graduation. Obviously it should be the PPMC who decides this
in a regular consensus.

What would be unusual (and perhaps controversial) is using the graduation
for "removing" PPMC members who had been voted in during incubation,
however it is not uncommon for PMC members to step down on their own
initiative.



On Fri, 23 Mar 2018, 16:06 Dave Neuman,  wrote:

> Hey IPMC,
> I had a question about altering the PMC for graduation.
> We have a few folks who are no longer active participants in our project
> that are still a part of our PMC.  In the process of generating our
> graduation resolution we were wondering if we could take the opportunity to
> have these members just be committers and not PMC members anymore?  If yes,
> what would the process look like, would it be enough to just make the
> roster alterations in Whimsy?  I have already spoken to each of these
> people individually and made sure they were on-board with just being
> committers and not PMC members.
>
> We are really excited to draft our resolution and I think this is the last
> thing standing in our way!
>
>
> Thanks in advance for the help!
>
> Dave
>

Re: [incubator/taverna] bad signatures

[Stian Soiland-Reyes]

Hi Henk,

Thanks to the bot for spotting this, I have updated expiry date for my
PGP subkey 6e50bb68cc1699a6.

As for removing "old" releases under
https://dist.apache.org/repos/dist/release/incubator/taverna/source/
all of these are referenced from
https://taverna.incubator.apache.org/download/ as they are different
modules (from different git repos) - is there a way to flag this for
the checker? I have removed taverna-parent-2 though - as -3 is
released.


On 9 March 2018 at 14:35, Henk P. Penning  wrote:
> Hi Stian,
>
>   please take a quick look at :
>
> https://checker.apache.org/projs/incubator.html
>
>   As you can see, you have 2 bad signatures in
>   www.apache.org/dist/incubator/taverna/ because today (2018-3-9)
>   your key 6e50bb68cc1699a6 expired.
>   Key 6e50bb68cc1699a6 is a subkey of key 411063a3a0ffd119.
>
>   Please fix this problem soon :
>
>   -- remove the parent package,
>   -- or change the expiration date of the subkey,
>   -- or replace the signature file
>
>   Help is here : https://checker.apache.org/doc/README.html#EXPKEYSIG
>
>   Please seriously consider removing releases
>
> taverna-common-activities-2.1.0-incubating/
> taverna-language-0.15.1-incubating/
> taverna-osgi-0.2.1-incubating/
> taverna-parent-2-incubating/
> taverna-parent-3-incubating/
>
>   ... from /dist/incubator/taverna/source ; branches that
>   are not currently "under development" should be
>   removed from /dist/ ; see [1].
>
>   Please mail me (he...@apache.org) if you have any questions, remarks etc.
>
>   [1] https://www.apache.org/legal/release-policy.html
>
>   Regards,
>
>   Henk Penning -- apache.org infrastructure ; dist & mirrors
>
>    _
> Henk P. Penning, ICT-beta R Uithof MG-403_/ \_
> Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \
> Leuvenlaan 4, 3584CE Utrecht, NL  F +31 30 253 4553 \_/ \_/
> http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/
>
> -- Forwarded message --
> Date: Fri, 9 Mar 2018 14:20:28 +0100
>
> sigs [6e50bb68cc1699a6] [expired]
> incubator/taverna/source/taverna-parent-3-incubating/apache-taverna-parent-3-incubating-source-release.zip.asc
> sigs [6e50bb68cc1699a6] [expired]
> incubator/taverna/source/taverna-server-3.1.0-incubating/apache-taverna-server-3.1.0-incubating-source-release.zip.asc
> GPG : /usr/bin/gpg2 --recv-key --keyserver pgp.surfnet.nl --homedir prod/gpg
> 6e50bb68cc1699a6 2> /dev/null
> sha1:
> incubator/taverna/source/taverna-parent-3-incubating/apache-taverna-parent-3-incubating-source-release.zip.asc
> sha1:
> incubator/taverna/source/taverna-server-3.1.0-incubating/apache-taverna-server-3.1.0-incubating-source-release.zip.asc
> sig:
> incubator/taverna/source/taverna-parent-3-incubating/apache-taverna-parent-3-incubating-source-release.zip.asc
>   EXPKEYSIG 6e50bb68cc1699a6 Stian Soiland-Reyes 
> sig:
> incubator/taverna/source/taverna-server-3.1.0-incubating/apache-taverna-server-3.1.0-incubating-source-release.zip.asc
>   EXPKEYSIG 6e50bb68cc1699a6 Stian Soiland-Reyes 
> * sums_delete 2



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [VOTE] Pulsar 1.22.0-incubating Release Candidate 3

[Stian Soiland-Reyes]

?On 25 February 2018 at 23:36, Jai Asher  wrote:
> This is the fourth release candidate for Apache Pulsar, version
> 1.22.0-incubating.
>
> It fixes the following issues:
> https://github.com/apache/incubator-pulsar/milestone/11?closed=1
>
> *** Please download, test and vote by Friday, Feb 23, 2018, 10:00 GMT.

Oo, I'll better hurry up then! :)
Normally the wording is "The vote is open for at least 72 hours" --
you are OK to keep it open a bit longer if you need sufficient votes
or have not tallied them yet.


> Source and binary files:
> https://dist.apache.org/repos/dist/dev/incubator/pulsar/
> pulsar-1.22.0-incubating-candidate-3/

Is it fourth of third release candidate? Use consistent numbering.
Starting with "RC0" is a bit unusual..

> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachepulsar-1010/

My vote: +1 (binding)


+0 checksums valid (I think)
? asc signatures (sorry, my machine lacks gpg today)
+1 tag vs commit
+0 src.tar.gz vs git tag  (generate_protobuf.sh and
generate_protobuf_docker.sh missing from dist - are they needed?)
+1 mvn install
+1 src LICENSE
+1 bin NOTICE
+0 src NOTICE -- copyright should extend into 2017-2018
+1 src/bin DISCLAIMER
+1 bin LICENSE and licenses (but why extra LICENSE-HdrHistogram0.txt?)
+0 bin NOTICE -- are all of these copyrights really forwarded from their NOTICE?
+1 mvn apache-rat:check - well-documented excludes

As an overall comment I think good work on the licenses!


I did a spot check, and guava.jar does not have a NOTICE, so unless
that was copied from a zip/tar that had such a NOTICE, then there
would be nothing to propagate. On the other side netty.jar has a
humongous NOTICE which somehow just becomes "Copyright 2014 The Netty
Project" in your NOTICE -- this seems to violate their Apache license.
  Has this been discussed on legael?


Your Git repository contains .gitignore.swp from vim which you
probably want to delete.



Your checksum files are in an unusual style:

C1 B8 C8 91 23 92 6A 56  82 F6 E9 F3 25 86 8B 58

CA1B352F 9576C8CB F16258F8 DEABF8F6 E95A926F 665E2FD8 30A38532 8BC639C6 20FD34E6
 6948396A CCD1A123 F072F93D 55D316EB EE34D208 9E0E9174 95AA09EE

Normally the .md5 and .sha512 files contain the checksum only, in
lowercase hex without spacing, e.g.

c1b8c89123926a5682f6e9f325868b58
ca1b352f9576c8cbf16258f8deabf8f6e95a926f665e2fd830a385328bc639c620fd34e66948396accd1a123f072f93d55d316ebee34d2089e0e917495aa09ee

This makes it easier to check against tools like md5sum and shasum.

You didn't include .sha1 checksums, but extra points for .sha512 :)

It is customary to include the checksums (at least md5) or the
dist.apache.org svn revision in the [VOTE] email, to any avoid
accidental last-minute-tampering confusion and to keep it in the
mailing list archives.


Tested with:
Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T20:39:06+01:00)
Maven home: /usr/local/share/maven
Java version: 1.8.0_144, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.11.6", arch: "x86_64", family: "mac"



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: Google Summer of Code 2018 Mentor Registration

[Stian Soiland-Reyes]

Any podlings participating in GSOC this year? 
(strongly recommended!)

See below for mentor registration procedure - mentors need
acknowledgement from someone else on your private@podling.incubator list
(aka the podling PMC). Note that you do NOT normally need ACK from the
Incubator PMC. [1]

-

Terminology: Your GSOC "mentors" are probably different from your
existing Incubator "mentors"!  The GSOC mentor can be any of the
committers of your podling (that the PPMC deem suitable for mentoring a
student fresh to your code base). 

Later your incubator mentors can assist in how to give the students
access, e.g. how to process pull requests or ask for ICLAs. Your PPMC is
free to decide when/if to grant a successful GSOC student committership.

See my separate email [2] on how to register GSOC ideas in JIRA to
attract potential students. 


[1] http://markmail.org/message/kl5akdi2oohp32c6
[2] 
https://lists.apache.org/thread.html/4e2b5b0ef2e565a08470ecbf9b2a6fc27a25ce28d4708334c9073fb9@%3Cgeneral.incubator.apache.org%3E


On Sat, 24 Feb 2018 22:19:34 +0100, Ulrich Stärk  wrote:
> Dear PMCs,
> 
> I'm happy to announce that the ASF has made it onto the list of accepted 
> organizations for
> Google Summer of Code 2018! [1,2]
> 
> It is now time for mentors to sign up, so please pass this email on to your 
> community and
> podlings. If you aren’t already subscribed to ment...@community.apache.org 
> you should do so now else
> you might miss important information.
> 
> Mentor signup requires two steps: mentor signup in Google's system [3] and 
> PMC acknowledgement.
> 
> If you want to mentor a project in this year's SoC you will have to
> 
> 1. Be an Apache committer.
> 2. Request an acknowledgement from the PMC for which you want to mentor 
> projects. Use the below
> template and *do not forget to copy ment...@community.apache.org*. We will 
> use the email adress you
> indicate to send the invite to be a mentor for Apache.
> 
> PMCs, read carefully please.
> 
> We request that each mentor is acknowledged by a PMC member. This is to 
> ensure the mentor is in good
> standing with the community. When you receive a request for acknowledgement, 
> please ACK it and cc
> ment...@community.apache.org
> 
> Lastly, it is not yet too late to record your ideas in Jira (see my previous 
> emails for details).
> Students will now begin to explore ideas so if you haven’t already done so, 
> record your ideas
> immediately!
> 
> Cheers,
> 
> Uli
> 
> mentor request email template:
> 
> to: private@.apache.org
> cc: ment...@community.apache.org
> subject: GSoC 2018 mentor request for 
> 
>  PMC,
> 
> please acknowledge my request to become a mentor for Google Summer of Code 
> 2018 projects for Apache
> .
> 
> I would like to receive the mentor invite to 
> 
> 
> 
> 
> 
> [1] https://summerofcode.withgoogle.com/organizations/
> [2] https://summerofcode.withgoogle.com/organizations/5718432427802624/
> [3] https://summerofcode.withgoogle.com/
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

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

Re: Google Summer of Code 2018 is coming

[Stian Soiland-Reyes]

Reminder to podlings of how to register ideas for Google Summer of Code.
(see below)

It is still not too late!  This is a great way to learn how to engage
with new contributors to your project, hopefully picking up new
committers and fresh code on the way!

Just decide on someone from your podling committers to be a GSOC mentor
for the student (Note that this "mentor" probably is different from your
existing incubator mentors!) - and register some ideas in JIRA using the
"gsoc2018" label.  If your project is not (yet) using JIRA, you can post
the ideas under the COMDEV project including your podling name in the
title.

See separate email on mentor registration.

On Sun, 21 Jan 2018 22:22:33 +0100, Ulrich Stärk  wrote:
> Hello PMCs (incubator Mentors, please forward this email to your podlings),
> 
> Google Summer of Code [1] is a program sponsored by Google allowing students 
> to spend their summer
> working on open source software. Students will receive stipends for 
> developing open source software
> full-time for three months. Projects will provide mentoring and project 
> ideas, and in return have
> the chance to get new code developed and - most importantly - to identify and 
> bring in new committers.
> 
> The ASF will apply as a participating organization meaning individual 
> projects don't have to apply
> separately.
> 
> If you want to participate with your project we ask you to do the following 
> things as soon as
> possible but please no later than 2017-01-30:
> 
> 1. understand what it means to be a mentor [2].
> 
> 2. record your project ideas.
> 
> Just create issues in JIRA, label them with gsoc2018, and they will show up 
> at [3]. Please be as
> specific as possible when describing your idea. Include the programming 
> language, the tools and
> skills required, but try not to scare potential students away. They are 
> supposed to learn what's
> required before the program starts.
> 
> Use labels, e.g. for the programming language (java, c, c++, erlang, python, 
> brainfuck, ...) or
> technology area (cloud, xml, web, foo, bar, ...) and record them at [5].
> 
> Please use the COMDEV JIRA project for recording your ideas if your project 
> doesn't use JIRA (e.g.
> httpd, ooo). Contact d...@community.apache.org if you need assistance.
> 
> [4] contains some additional information (will be updated for 2017 shortly).
> 
> 3. subscribe to ment...@community.apache.org; restricted to potential 
> mentors, meant to be used as a
> private list - general discussions on the public d...@community.apache.org 
> list as much as possible
> please). Use a recognized address when subscribing (@apache.org or one of 
> your alias addresses on
> record).
> 
> Note that the ASF isn't accepted as a participating organization yet, 
> nevertheless you *have to*
> start recording your ideas now or we will not get accepted.
> 
> Over the years we were able to complete hundreds of projects successfully. 
> Some of our prior
> students are active contributors now! Let's make this year a success again!
> 
> Cheers,
> 
> Uli
> 
> P.S.: Except for the private parts (label spreadsheet mostly), this email is 
> free to be shared
> publicly if you want to.
> 
> [1] https://summerofcode.withgoogle.com/
> [2] http://community.apache.org/guide-to-being-a-mentor.html
> [3] http://s.apache.org/gsoc2018ideas
> [4] http://community.apache.org/gsoc.html
> 

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

Re: [VOTE] Retire iota

[Stian Soiland-Reyes]

+1 (binding)

On 4 February 2018 at 22:44, Justin Mclean  wrote:
> Hi,
>
> This is a call to vote for the retirement of the Iota podling.
>
> The podling has discussed retirement [1], has not made a single release and 
> there's been little activity on it’s mailing list [2] and repos [3] in recent 
> time.
>
> [ ] +1 to retire
> [ ] +/- 0 to retire
> [ ] -1 don't retire because...
>
> Thanks,
> Justin
>
> 1. 
> https://lists.apache.org/thread.html/f762acf82cf0bf7609ec036551c6b4969cd0c45a565d28fc5b01a017@%3Cdev.iota.apache.org%3E
> 2. https://lists.apache.org/list.html?d...@iota.apache.org:lte=3M:
> 3. https://github.com/apache/incubator-iota
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: Apache Policy Quiz

[Stian Soiland-Reyes]

Thanks for having a go, Justin! We need more ways to explain license and
distribution challenges.


I also got just 1 of 5, even on multiple tries on the same questions. Also
the fact that the correct answer(s) is not shown graphically is confusing.

i thinks such a quiz should not deliberately cover all the subtleties which
as we see here we are not in 100% agreement on; that just make people
conclude that "It's too complicated".

The quiz should rather cover the obvious bits so that this could be used by
newcomers to the Incubator, rather than try to catch out ASF members.

I would avoid tricky multiple choice, except in obvious multi-things like
"which licenses allowed" (which I thought was a good, more obvious
question).

Other kind of simpler questions could be:


Which of these need to include/show LICENCE and NOTICE files for an ASF
release?


Source code release on www.apache.org/dist
Binary release zip on www.apache.org/dist
Binary JARs in Maven Central
Windows installer at Launchpad.net
OSX disk image in Apple store
Source code release in Debian

Here all of the above is right answer. I left out "Source code repository
in git" because at least in Incubator we allow slight diversions here (and
also repos would include older commits possibly pre-ASF).


Which of the below should be included in NOTICE for contributions to Apache
Foo under Apache License 2.0?

1 Apache Software Foundation
2 Apache Foo
3 Apache Foo PMC members
4 Apache Foo Committers who contributed to release
5 Contributors who submitted patches to Apache Foo
6 NOTICE of Apache-licensed code that was included from outside ASF

Only 1,2,6 are correct.


Here I left out "Other Apache Projects which code was reused" and "Code
contributed in software grant" because those can be more complicated.



On 25 Jan 2018 8:02 am, "Christofer Dutz"  wrote:

> In general I think it's a great Idea.
> I would really like to bring this to my new Apache colleagues in the PLC4X
> project ... this way they could get up to speed with the formal stuff.
>
> But I think the tool does need a little optimization ;-)
>
> I think from 5 questions I got about 1 right ;-)
>
> But I guess it was mainly cause I interpreted the answers as if they are
> aggregated to form a correct answer.
> For example I interpreted the answers "3 +1 votes" and "more +1 than -1"
> as being ANDed to form the correct answer, but Justin told me "more +1 than
> -1" is correct as you could also have "3 +1 and 10 -1 votes". This was
> not obvious to me and I think if the aggregation of all answers form the
> correct one, It would be more intuitive. I would really like a quiz like
> that that lists up different parts and all that are correct have to be
> clicked. It requires to know the same information, but doesn't make you mad
> if you missed some little trick ;-)
>
> Chris
>
> Am 25.01.18, 08:55 schrieb "Justin Mclean" :
>
> Hi,
>
> > I return to my point: "No" was the best answer (tho its qualifiers
> were
> > wrong), and the "Yes" was wrong for that question.
>
> Yes I agree No is the best answer (and is the correct answer is just
> about every single case) and Yes is wrong in that question. Is "Yes but
> only for some common build tools.” correct or not, currently I have it down
> as correct, but if it’s not as your saying then the text (and title) at
> [1] I think would need to change. May be best to bring up on legal discuss?
>
> Thanks,
> Justin
>
> 1. https://www.apache.org/legal/resolved.html#build-tools
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>
>
>

[ANNOUNCE] Apache Taverna Server 3.1.0-incubating released

[Stian Soiland-Reyes]

The Apache Taverna (incubating) team is pleased to announce the release of
apache-taverna-server 3.1.0-incubating

This announcement is also available at:
https://s.apache.org/taverna-server-3.1.0


Apache Taverna is a domain-independent suite of tools used to design
and execute data-driven workflows.

# Taverna Server

Apache Taverna Server enables you to set up a dedicated server for
remotely executing Taverna workflows, exposed as REST Web APIs and
WSDL Web Services. This enables integration of Taverna workflows into
web portals, mobile applications, as well as allowing desktop users to
execute remotely on local server or cloud infrastructure. Taverna
Server can be configured for POSIX user isolation (e.g. sudo) and can
restrict which workflows to execute.

Taverna Server runs workflows defined with Apache Taverna Language in
SCUFL2 format (.wfbundle). It can also execute many Taverna 2
workflows (.t2flow) , depending on which activities they require.

Download apache-taverna-server 3.1.0-incubating:
https://taverna.incubator.apache.org/download/server/


# Changes

Major changes since Taverna Server 2.5.4 are described below:

## Taverna 3 execution

Workflows are now executed with Apache Taverna Command-line Tool
3.1.0-incubating, which adds support for executing SCUFL2 workflows
using the Apache Taverna Engine.

## Source Code Name Changes

Package names have changed to org.apache.taverna.server.* and source
code modules have been reorganized. See the Javadoc for details.

## Taverna Server Client

This release adds the  taverna-server-client library, which can be
used by Java clients to connect to the Taverna Service REST API.


# Installation

See the included taverna-server README for details on how to build the
source code.

For full documentation of installing, configuring and using Taverna
Server, see https://taverna.incubator.apache.org/documentation/server/


# Stay Informed

Please subscribe to and contact the dev@taverna mailing list for any
questions, suggestions, and discussions about Apache Taverna.

http://taverna.incubator.apache.org/contact



# Checksums (sha1/sha256/sha512)

6d779941bec29d327e22d2a76ec1069d82c4c28d
apache-taverna-parent-3-incubating-source-release.zip
4aebfdeecb78645365cab868878dc85c34f04ecc
apache-taverna-server-3.1.0-incubating-source-release.zip

6dcca32163870e33d99454388d43c818bc003e29a911f8fe6d48e63373d2aca5
apache-taverna-parent-3-incubating-source-release.zip
0025c85cc115fc5b8c6c969f2a1ae995ca3269a193f63d2508bc8740c095af1c
apache-taverna-server-3.1.0-incubating-source-release.zip

767aaf8cbe43eb62549e8c73619ce2170197cd625d23eeadb8d3df284d74c15a503c86c92741aac6c931208338c00b8409392c36fc965cc237b963143b7a7817
 apache-taverna-parent-3-incubating-source-release.zip
b08e568e4470b2db2b3e5754ae0eaba72990ab2f1f951dcd96f65a04fb768665391d8c50af2270045f659e1ab81dc881a217d4f0d64e3c2ef691e802cad11835
 apache-taverna-server-3.1.0-incubating-source-release.zip



# Disclaimer

Apache Taverna is an effort undergoing incubation at The Apache
Software Foundation (ASF) sponsored by the Apache Incubator PMC.
Incubation is required of all newly accepted projects until a further
review indicates that the infrastructure, communications, and decision
making process have stabilized in a manner consistent with other
successful ASF projects. While incubation status is not necessarily a
reflection of the completeness or stability of the code, it does
indicate that the project has yet to be fully endorsed by the ASF.



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

[RESULT] [VOTE] Release Apache Taverna Server 3.1.0-incubating RC3

[Stian Soiland-Reyes]

Thanks to all who voted!

The release has PASSED with the following IPMC votes:

+1 Stian Soiland-Reyes (binding)
+1 Justin Mclean (binding)
+1 Sergio Fernández (binding)

I will proceed to publish the release and send ANNOUNCE.

I will also merge
https://github.com/apache/incubator-taverna-server/pull/5
following clarification on LICENSE/NOTICE on legal-discuss.

On behalf of the Apache Taverna podling, thank you!


On 14 January 2018 at 00:23, Stian Soiland-Reyes  wrote:
> The Apache Taverna IPMC has voted +3 to release
> Apache Taverna Server 3.1.0-incubating.
>
> This vote carries over +1 binding vote from IPMC members.
>
> Vote thread:
> https://lists.apache.org/thread.html/5cde355f427de0ff7be68002c578387ef7116573d197a6cafc1ad94b@%3Cdev.taverna.apache.org%3E
>
> Taverna Server allows remote execution of Apache Taverna workflows, exposed as
> REST Web APIs and WSDL Web Services. This release is based on Apache Taverna
> Command-line 3.1.0.
>
>
> Release candidates to be voted over are available at:
>
> https://dist.apache.org/repos/dist/dev/incubator/taverna/source/taverna-parent-3-incubating-RC3/
>
> https://dist.apache.org/repos/dist/dev/incubator/taverna/source/taverna-server-3.1.0-RC3/
>
>
> SHA-1 checksums:
> 6d779941bec29d327e22d2a76ec1069d82c4c28d  
> apache-taverna-parent-3-incubating-source-release.zip
> 4aebfdeecb78645365cab868878dc85c34f04ecc  
> apache-taverna-server-3.1.0-incubating-source-release.zip
>
>
> MD5 checksums:
> 11b15c0065541645976658387e4c5030  
> apache-taverna-parent-3-incubating-source-release.zip
> a1ed882e11b2e5a7af58486800f5e8aa  
> apache-taverna-server-3.1.0-incubating-source-release.zip
>
>
> Build the release candidate *in the above order* using:
>
> mvn clean install
>
>
> The release candidates correspond to the following git commits:
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-maven-parent.git;a=commit;h=adecb277e6179ee3f8cbd099b0bffe7aa3e38223
> https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-server.git;a=commit;h=77884cbcc96a065671d920766931819b60f40b53
>
>
>
> Release candidates are signed with a GPG key available at:
> https://dist.apache.org/repos/dist/release/incubator/taverna/KEYS
>
>
> A staged Maven repository is available for review at:
> https://repository.apache.org/content/repositories/orgapachetaverna-1018
>
>
>
> Please vote on releasing these packages as:
>
> Apache Taverna Maven Parent 3-incubating
> Apache Taverna Server 3.1.0-incubating
>
> The vote is open for at least 72 hours and passes if a majority of at least
> three +1 Apache Incubator IPMC votes are cast.
>
> [ ] +1 Release this package
> [ ]  0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because...
>
>
> --
> Stian Soiland-Reyes
> http://orcid.org/-0001-9842-9718
>
>
> -----
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [VOTE] Retire Wave

[Stian Soiland-Reyes]

+1 (binding)

On 8 January 2018 at 18:56, John D. Ament  wrote:
> All,
>
> This is a call to vote for the retirement of the Wave podling.
>
> The podling has positively voted to retire [1].  I now call upon the IPMC
> to confirm this retirement.
>
> [ ] +1 to retire
> [ ] +/- 0 to retire
> [ ] -1 don't retire because...
>
> The podling is working on a migration plan, it seems they will move the
> code to github somewhere, and will work on it as seen fit there.
>
> John
>
> [1]:
> https://lists.apache.org/thread.html/fe4b7a240facbebeded29d7d9d8c733c0e5e624f07b7a110887c2f16@%3Cwave-dev.incubator.apache.org%3E



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [VOTE] Release Apache Taverna Server 3.1.0-incubating RC3

[Stian Soiland-Reyes]

Thanks for reviewing!

On Sun, 14 Jan 2018 11:52:37 +1100, Justin Mclean  
wrote:

> Has a mistake been made here? I can’t see any source code in the release.

There are two artifacts in the release: 

apache-taverna-parent-3-incubating-source-release.zip
apache-taverna-server-3.1.0-incubating-source-release.zip

The second is the actual source code - but it depends on the newer
apache-taverna-parent so they need to be built in that order.

(We have several git repositories, they all share taverna-parent)


> - NOTICE probably has too much information

Presuming you checked taverna-parent, are you suggesting to remove the text
about the software grant?


> - I'd like to say all source code has headers - except there's no source code
> - No unexpended binaries
> - Can “compile” successfully
> 
> Given there is basically nothing bundled here I can’t see any reason for the 
> extra information in NOTICE.
> 
> You might want to consider using sha512 for your sha hash. [1]

Thanks, I've added .sha256 and .sha512 files.

For the record (these lines will probably be wrongly wrapped)

6dcca32163870e33d99454388d43c818bc003e29a911f8fe6d48e63373d2aca5  
apache-taverna-parent-3-incubating-source-release.zip
0025c85cc115fc5b8c6c969f2a1ae995ca3269a193f63d2508bc8740c095af1c  
apache-taverna-server-3.1.0-incubating-source-release.zip

767aaf8cbe43eb62549e8c73619ce2170197cd625d23eeadb8d3df284d74c15a503c86c92741aac6c931208338c00b8409392c36fc965cc237b963143b7a7817
  apache-taverna-parent-3-incubating-source-release.zip
b08e568e4470b2db2b3e5754ae0eaba72990ab2f1f951dcd96f65a04fb768665391d8c50af2270045f659e1ab81dc881a217d4f0d64e3c2ef691e802cad11835
  apache-taverna-server-3.1.0-incubating-source-release.zip



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

[VOTE] Release Apache Taverna Server 3.1.0-incubating RC3

[Stian Soiland-Reyes]

The Apache Taverna IPMC has voted +3 to release 
Apache Taverna Server 3.1.0-incubating.

This vote carries over +1 binding vote from IPMC members.

Vote thread:
https://lists.apache.org/thread.html/5cde355f427de0ff7be68002c578387ef7116573d197a6cafc1ad94b@%3Cdev.taverna.apache.org%3E

Taverna Server allows remote execution of Apache Taverna workflows, exposed as
REST Web APIs and WSDL Web Services. This release is based on Apache Taverna
Command-line 3.1.0.


Release candidates to be voted over are available at:

https://dist.apache.org/repos/dist/dev/incubator/taverna/source/taverna-parent-3-incubating-RC3/

https://dist.apache.org/repos/dist/dev/incubator/taverna/source/taverna-server-3.1.0-RC3/


SHA-1 checksums:
6d779941bec29d327e22d2a76ec1069d82c4c28d  
apache-taverna-parent-3-incubating-source-release.zip
4aebfdeecb78645365cab868878dc85c34f04ecc  
apache-taverna-server-3.1.0-incubating-source-release.zip


MD5 checksums:
11b15c0065541645976658387e4c5030  
apache-taverna-parent-3-incubating-source-release.zip
a1ed882e11b2e5a7af58486800f5e8aa  
apache-taverna-server-3.1.0-incubating-source-release.zip


Build the release candidate *in the above order* using:

mvn clean install


The release candidates correspond to the following git commits:

https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-maven-parent.git;a=commit;h=adecb277e6179ee3f8cbd099b0bffe7aa3e38223
https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-server.git;a=commit;h=77884cbcc96a065671d920766931819b60f40b53



Release candidates are signed with a GPG key available at:
https://dist.apache.org/repos/dist/release/incubator/taverna/KEYS


A staged Maven repository is available for review at:
https://repository.apache.org/content/repositories/orgapachetaverna-1018



Please vote on releasing these packages as:

Apache Taverna Maven Parent 3-incubating 
Apache Taverna Server 3.1.0-incubating

The vote is open for at least 72 hours and passes if a majority of at least
three +1 Apache Incubator IPMC votes are cast.

[ ] +1 Release this package
[ ]  0 I don't feel strongly about it, but don't object
[ ] -1 Do not release this package because...


-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718


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

Re: [VOTE] Graduate the Apache Juneau podling from Incubator to a TLP

[Stian Soiland-Reyes]

+1 (IPMC binding)

Well done!


On 9 Oct 2017 3:12 pm, "James Bognar"  wrote:

Hi everyone,

The Apache Juneau PPMC held a vote on the readiness for graduation of
Apache Juneau as a Top Level Project and came to a consensus to proceed
with graduation.  The vote was 7 +1s (5 binding) and no 0s or -1s.

The vote thread can be found here:
https://lists.apache.org/thread.html/d8eab3f75ca4c2f18477acbdf33726
113eed505a7457b8db289c41ab@%3Cdev.juneau.apache.org%3E

Our Whimsy page can be found here:
https://whimsy.apache.org/roster/ppmc/juneau

Our status file can be found here:
http://incubator.apache.org/projects/juneau.html

Note that we are still waiting for the results of the Podling Suitable
Names Search, but we do not anticipate any issues.
https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-134

We have been in the incubator since June 24, 2016.  Since then we have
proven our ability to produce Apache releases with the following:
- 2016-10-25 - Juneau 6.0.0
- 2017-01-03 - Juneau 6.0.1
- 2017-02-25 - Juneau 6.1.0
- 2017-04-28 - Juneau 6.2.0
- 2017-06-28 - Juneau 6.3.0
- 2017-08-01 - Juneau 6.3.1
- 2017-10-06 - Juneau 6.4.0

Our community consists of a mixture of corporate (IBM, Salesforce), Apache
(Streams), and external committers.  We have a healthy and successful
ongoing collaboration with the Apache Streams project.  Our community is
healthy, open, and respectful.

Our source code is mature and heavily documented with many examples and
tutorials.

Please vote on whether to graduate Juneau from the Incubator and recommend
the graduation resolution below to the ASF Board.

[  ] +1 Graduate Apache Juneau podling from the Incubator
[  ] +0 Don't care
[  ] -1 Don't graduate Apache Juneau podling from the Incubator because...

This vote will be open for at least 72 hours. Thanks to all the mentors and
PPMC members of the Juneau community for your help in getting this project
off the ground.

The full text of the resolution is below. The resolution will be submitted
to the Board of Directors for their consideration upon approval by the
Apache Incubator PMC members.

--

Establish the Apache Juneau 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 a toolkit for marshalling POJOs to a wide variety of content
types using a common framework, and for creating sophisticated
self-documenting REST interfaces and microservices using VERY little
code.

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

RESOLVED, that the Apache Juneau Project be and hereby is responsible
for the creation and maintenance of software related to a toolkit for
marshalling POJOs to a wide variety of content types using a common
framework, and for creating sophisticated self-documenting REST
interfaces and microservices using VERY little code; and be it further

RESOLVED, that the office of "Vice President, Apache Juneau" 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 Juneau
Project, and to have primary responsibility for management of the
projects within the scope of responsibility of the Apache Juneau
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 Juneau Project:

 * Craig L Russell 
 * David Goddard   
 * James Bognar
 * Jochen Wiedmann 
 * John D. Ament   
 * Peter Haumer
 * Raphi D Lee     
 * Steve Blackmon  
 * Stian Soiland-Reyes 

NOW, THEREFORE, BE IT FURTHER RESOLVED, that James Bognar be appointed
to the office of Vice President, Apache Juneau, 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 Juneau 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 Juneau Project;
and be it further

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

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

Re: [VOTE] Do not accept software grants with conditionals or exclusions

[Stian Soiland-Reyes]

+1


However it should be OK (and perhaps even encouraged) for the archive
to list in NOTICE or similar that some of the files are not legally
owned by the donating entity, for instance other open source files
that have been used – legally they can’t be part of the IP grant
(unless the donating entity have gained shared copyright after further
modifications - but their upstream license would still apply).


This does not mean the donated archive has to be fully IP cleared
before donation.. of course the opposite could be true – the grant
donates some code, which the podling later chooses not to keep – for
instance by discovering an LGPL-licensed file from outside.


What is not OK is as you suggest, to include files which ARE owned by
the donating entity, but which are somehow not included in the grant.


On 7 September 2017 at 09:32, Ted Dunning  wrote:
> +1
>
>
> On Sep 7, 2017 10:11, "Jacques Le Roux" 
> wrote:
>
>> +1 (not binding, not part of IPMC)
>>
>> Jacques
>>
>>
>> Le 07/09/2017 à 10:07, Bertrand Delacretaz a écrit :
>>
>>> Hi Incubator PMC.
>>>
>>> We recently received a software grant pointing to an archive file for
>>> the code donation, but mentioning that some material contained in that
>>> archive might not be donated.
>>>
>>> This was discussed on the PMC private list and it looks like we have
>>> consensus for rejecting such grants in the future: software donations
>>> should only include the files that are donated, without conditionals
>>> or exclusions. Anything else puts an unnecessary burden on our
>>> podlings and mentors, for sorting out what's donated or not.
>>>
>>> This is a vote to formalize the decision to reject such grants in the
>>> future.
>>>
>>> This majority vote is open for at least 72 hours.
>>>
>>> Here's my +1.
>>>
>>> -Bertrand
>>>
>>> -
>>> 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
>>
>>



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: vote to go to a TLP? (was: [VOTE] Graduate Apache DistributedLog as a subproject of Apache BookKeeper)

[Stian Soiland-Reyes]

IPMC formally owns "Apache DistributedLog" until graduation. BookKeeper -
or any project anywhere - would of course legally be allowed to fork the
code under a different name. Graduation is more about the community
practices, not so much the code.

Realistically IPMC won't block any such graduation into an existing ASF
project who is accepting, but it should not be automatic, e.g. IPMC should
oversee to ensure the new (sub)community is working in an Apache Way, that
contributions are recognised and releases are IP clean.


On 1 Jul 2017 9:01 am, "Greg Stein"  wrote:

On Wed, Jun 28, 2017 at 10:25 AM, John D. Ament 
wrote:

> I have no idea why this is copying both public and private lists.
>

And I have no idea why this is a vote for the IPMC to conduct.

Can't Apache BookKeeper just move the code over, add some committers and
PMC members, and carry on?

Like... what? The IPMC will tell BK "you can't do that" ??

Cheers,
-g

Re: Airflow voting on release artifacts

[Stian Soiland-Reyes]

I understand that concern. Why do you think your users install release
candidates under vote? It might be time to think about splitting out a
users@ list?

Perhaps you can expand the instructions in the VOTE email with the exact
commands to install and uninstall, or a special test script that enforces
use of virtualenv for instance. With a larger community the VOTE emails
need to be more guiding for expectation management.

On 1 May 2017 11:01 pm, "Bolke de Bruin"  wrote:

> Yes you can, but how do we verify it actually happened? Maven will, afaik,
> happily upgrade “apache-beam-1.0.0rc2” to “apache-beam-1.0.0” although they
> contain the exact same artefact. Pip won’t do that.
>
> If we use a release candidate named “apache-airflow-1.8.1rc2” while the
> package requires us to contain “apache-airflow-1.8.1” users cannot tell the
> difference if they installed RC2 or if it was the actual release. Worse
> even, we cannot tell the difference anymore. Then we just need to wait for
> the confusion in the bug reports.
>
> B.
>
> > On 1 May 2017, at 23:42, Stian Soiland-Reyes  wrote:
> >
> > Sorry for my ignorance, but is there no easy way with pip to uninstall
> the
> > package or force-install a new RC?
> >
> > If a previous RC failed the vote, then it should be uninstalled by
> everyone
> > anyway. In fact if you test a RC by installing it globally, then you
> should
> > always uninstall it after testing as you don't know the result of the
> vote
> > yet and should revert to the latest official release (or your own build
> > from scm).
> >
> > This is no different from Java/Maven - if you happen to test an RC by
> "mvn
> > install" (instead of "mvn verify") then you need to clean it out
> > afterwards. There is no easy command for it in mvn, although you can
> > usually just rm -rf the corresponding folder in .m2/repository.
> >
> >
> >
> > On 1 May 2017 10:00 pm, "Bolke de Bruin"  wrote:
> >
> >
> >> On 1 May 2017, at 22:39, Alex Harui  wrote:
> >>
> >>
> >>
> >> On 5/1/17, 11:44 AM, "Bolke de Bruin"  > bdbr...@gmail.com>> wrote:
> >>
> >>>
> >>>> On 1 May 2017, at 17:36, Alex Harui  wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 5/1/17, 7:44 AM, "Hitesh Shah"  wrote:
> >>>>
> >>>>> Hi Justin,
> >>>>>
> >>>>> Currently, the podling has been modifying the contents and hence this
> >>>>> discussion.
> >>>>
> >>>> I agree with Justin and others that modification after the vote is
> not a
> >>>> good thing.  So my assumption was that if you add your 2a step and
> >>>> modify
> >>>> the binary before the vote, it will be acceptable.  IMO, all you need
> >>>> is a
> >>>> way to verify that the binary the voters test is essentially the same
> as
> >>>> the binary you want to actually release.
> >>>>
> >>>> -Alex
> >>>>
> >>>>
> >>>
> >>> Hi Alex,
> >>>
> >>> As mentioned earlier this is not possible in a clean way. Version
> >>> information is contained within the source package and it is required
> by
> >>> specification to be. Installation happens from this source package.
> There
> >>> are no “binaries”.
> >>>
> >>> We understand the need to vote on the artefacts, however the way it is
> >>> required to work put us between a rock and a hard place: either our
> users
> >>> can end up with an outdated pre-release while reporting they have the
> >>> release installed or we need to vote 2+2 times (PMC+IPMC).
> >>>
> >>> We are looking to optimize this process either technically or
> >>> procedurally, but until so far haven’t been able to distill anything
> that
> >>> really helps.
> >>
> >> Well, I'm quite confused now.  Hitesh seems to say there are binaries.
> >> And I have proposed a couple of ideas where you create different
> artifacts
> >> for voters vs. customers that I think get around all of these issues.
> >> AFAIK, nobody on this list has objected to those proposals.
> >>
> >> Maybe there is something about Python I don't understand, but if I had
> to
> >> ship a set of Javascript files with an embedded version number in one of
> >> those files, I would use what I

Re: Airflow voting on release artifacts

[Stian Soiland-Reyes]

Sorry for my ignorance, but is there no easy way with pip to uninstall the
package or force-install a new RC?

If a previous RC failed the vote, then it should be uninstalled by everyone
anyway. In fact if you test a RC by installing it globally, then you should
always uninstall it after testing as you don't know the result of the vote
yet and should revert to the latest official release (or your own build
from scm).

This is no different from Java/Maven - if you happen to test an RC by "mvn
install" (instead of "mvn verify") then you need to clean it out
afterwards. There is no easy command for it in mvn, although you can
usually just rm -rf the corresponding folder in .m2/repository.



On 1 May 2017 10:00 pm, "Bolke de Bruin"  wrote:


> On 1 May 2017, at 22:39, Alex Harui  wrote:
>
>
>
> On 5/1/17, 11:44 AM, "Bolke de Bruin" > wrote:
>
>>
>>> On 1 May 2017, at 17:36, Alex Harui  wrote:
>>>
>>>
>>>
>>> On 5/1/17, 7:44 AM, "Hitesh Shah"  wrote:
>>>
 Hi Justin,

 Currently, the podling has been modifying the contents and hence this
 discussion.
>>>
>>> I agree with Justin and others that modification after the vote is not a
>>> good thing.  So my assumption was that if you add your 2a step and
>>> modify
>>> the binary before the vote, it will be acceptable.  IMO, all you need
>>> is a
>>> way to verify that the binary the voters test is essentially the same as
>>> the binary you want to actually release.
>>>
>>> -Alex
>>>
>>>
>>
>> Hi Alex,
>>
>> As mentioned earlier this is not possible in a clean way. Version
>> information is contained within the source package and it is required by
>> specification to be. Installation happens from this source package. There
>> are no “binaries”.
>>
>> We understand the need to vote on the artefacts, however the way it is
>> required to work put us between a rock and a hard place: either our users
>> can end up with an outdated pre-release while reporting they have the
>> release installed or we need to vote 2+2 times (PMC+IPMC).
>>
>> We are looking to optimize this process either technically or
>> procedurally, but until so far haven’t been able to distill anything that
>> really helps.
>
> Well, I'm quite confused now.  Hitesh seems to say there are binaries.
> And I have proposed a couple of ideas where you create different artifacts
> for voters vs. customers that I think get around all of these issues.
> AFAIK, nobody on this list has objected to those proposals.
>
> Maybe there is something about Python I don't understand, but if I had to
> ship a set of Javascript files with an embedded version number in one of
> those files, I would use what I proposed.  AFAICT, there is no obligation
> to make your customers (not your voters) consume the source package, it
> just has to be possible to generate what the customers use from the source
> package.
>

In Python we are used to install through so called source distributions
“sdist”. Package managers (e.g. pip) use the filename to determine whether
to download a new package and if they do they examine the contents of the
package to find out it they need to install the package. They do this by
examining the version contained inside the package. Thus while a different
filename will trigger a new download, it might not install updated parts of
the package. This is different from your example as no installer is
examining both the name of the tar ball and the contents of your javascript
files for a version identifier.

But maybe you have a point. We could just do a "git clone”, update the
version (not push it to git until final release), tar it. We then ask
people to vote on it. Then we could provide the convenience package (that
everyone will use) next to it. Or if we consider the “sdist” a binary
release officially we vote on that one as well after the first vote. Two
downsides to this are: if only option 1) nobody would user the tar, as the
sdist is essentially the same and works with the package managers. Might be
a bit excessive? 2) that would be a 2+2 vote again.

Option 1 could work, it isn’t ideal, but will satisfy the procedure.

Bolke.

Re: GitHub workflows?

[Stian Soiland-Reyes]

On Mon, 06 Mar 2017 10:29:54 +0100, "Raphael Bircher" 
 wrote:
> As long as all goes to the list, it's probably ok, but I would prefer ASF  
> Tools over third party tools. Thy are under the Foundation control. Even  
> GH is really strong at the moment, you don't know the future of the tools  
> there. If you use tired party tools it's every time a chance of data loss.

Agreed on not relying too heavily on the third-party tools - we have
seen many of these may gradually degrade/fail or change business models.


Discussions on GH pull requests is common in several projects, which
should then be set up to mirror these to dev@ through the ASF GitHub bot
you are not forced to use GH to contribute and it goes into the list
archive. Pull Request mMerging happens using normal git
commands and pushed back to apache.org's git - GitHub recognizes the
commit (you can also say "This closes #15" in the commit message in case
you don't do a normal merge) .


Using GitHub issues will in theory work the same email wise (as is done
for the Ponymail podling), but it is a bit more tricky because of lack
of admin control for normal committers, e.g. to assign issues or labels.

(As we don't want to give repository git commit directly at GitHub).  

It is possible to work around this with emails to the bot, but it gets
cumbersome. A second option perhaps would be a secondary empty
git repository?


I think generally GitHub Pull Requests is good - it is a very structured way
to converse about a code change that still works well on email, and a
very welcoming way for third-party developers to get started
contributing.

A pull request is also fairly transient/short-lived - it would not
be too big deal if say a year later github.com disappears, as you would
still find a thread per pull request on list.apache.org and the
commits in the git log  - although perhaps not as 
beautiful as the GH rendering :-)


Using GitHub issues is a bit different - as that is part of the planning
and management of the project, which is a (P)PMC matter.

For one you would force the PMC/committers to use a third-party tool;
which some may be reluctant too for personal reasons, or even have
institutional or national firewall issues with.  Secondly keeping track
of what is done or not should remain accessible for longer-term, e.g. to
see what was part of a release a year ago. That's another reason to be
more sceptical about using a third-party issue tracker (without a
contractual binding).


-- 
Stian Soiland-Reyes
The University of Manchester
http://www.esciencelab.org.uk/
http://orcid.org/-0001-9842-9718


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

Re: [VOTE] Release Apache Juneau 6.1.0-incubating-RC2

[Stian Soiland-Reyes]

On Wed, 22 Feb 2017 12:05:26 -0500, James Bognar  wrote:
> The Apache Juneau Incubator PPMC has voted *+3* to release Apache Juneau
> 6.1.0-incubating RC2.
> The binaries are available at:
> https://dist.apache.org/repos/dist/dev/incubator/juneau/binaries/juneau-6.1.0-incubating-RC2/
> 
> The release candidate to be voted over is available at:
> https://dist.apache.org/repos/dist/dev/incubator/juneau/source/juneau-6.1.0-incubating-RC2/

Hi, apologies for not having a chance to look at this earlier.

My vote: +1 (binding)

Checked:
+ pgp signatures
+ sha1 checksums
+ mvn apache-rat:check
+ LICENSE, NOTICE, DISCLAIMER
- mvn clean install FAILS - conflict with Dropbox
  + works with -DskipTests
+ No unexpected binaries in src (beyond PNG)  
+ maven repo matches binary distro (same sha1 on jars and zips)

NOTICE uses format "Copyright 2016, 2017" -- this will over time get verbose
and I would generally think a time span is sufficient (e.g. next year it can be
2016-2018), but this is just a stylistic choice for the podling. :)

NOTICE says "Apache Juneau" instead of "Apache Juneau (incubating)"
(However there is also a DISCLAIMER)


Building on Windows fails with:

java.net.BindException: Address already in use: bind

Failed tests:
  DefaultContentTypesTest.testRestMethodParsersSerializers:119 Response status 
code was not correct.  Expected: '415'.  Actual: '0'
  ErrorConditionsTest.test404and405:184 Response status code was not correct.  
Expected: '404'.  Actual: '0'
  ErrorConditionsTest.test412:215 Response status code was not correct.  
Expected: '412'.  Actual: '0'
  ErrorConditionsTest.testNonExistentBeanProperties:51 Response status code was 
not correct.  Expected: '400'.  Actual: '0'
(..)
Tests in error:
  AcceptCharsetTest.testCharsetOnResponse:72 » RestCall localhost:10001 failed 
t...
  AcceptCharsetTest.testQValues:36->check1:57 » RestCall localhost:10001 failed 
...
  BeanContextPropertiesTest.testClassTransforms:32 » RestCall localhost:10001 
fa...
(..)
[INFO] Apache Juneau REST Tests ... FAILURE [04:35 min] 
  

It turns out port 10001 is used by Dropbox: 

λ netstat -b

Active Connections

  Proto  Local Address  Foreign AddressState
  TCP127.0.0.1:10001biggie:56458   TIME_WAIT
  TCP127.0.0.1:10001biggie:56459   TIME_WAIT
  TCP127.0.0.1:50228biggie:50229   ESTABLISHED
 [Dropbox.exe]

If I stop Dropbox, then tcsd_win32.exe (related to Trusted Platform Module)
binds the port 10001 insted. This seems like a popular internal port!

Ideally the Juneau tests should try to bind the port dynamically rather than be
hardcoded to 10001.  As this is a technical issue it does not affect my IPMC
vote.


Stopping both daemons, the rest tests now fail with a single error:

 BeanContextPropertiesTest.testClassTransforms:33 
expected:
 
 but 
was:

Timezone issue?  (btw, I'm in time zone London, which is Z/GMT during winter
time, but 4th July would be during daylight saving +01)




Tested with:

D:\1\juneau-6.1.0-incubating
λ mvn -version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
2015-11-10T16:41:47+00:00)
Maven home: C:\Program Files\apache-maven-3.3.9\bin\..
Java version: 1.8.0_121, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_121\jre
Default locale: en_GB, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos"

-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [VOTE] MXNet to enter the Incubator

[Stian Soiland-Reyes]

+1 (binding)

On 17 Jan 2017 4:20 am, "Henri Yandell"  wrote:

> Hi Incubator folk,
>
>I would like to call a vote for accepting "MXNet" for incubation in the
> Apache Incubator.
>
> The full proposal is available at this wiki link:
>
> https://wiki.apache.org/incubator/MXNetProposal?action=recall&rev=19
>
> I will reply to this email with a copy of the proposal.
>
> MXNet already has a broad community, which I think is clear from the
> interest from many contributors in being a part of the project at Apache.
> There are four mentors signed up, along with 2 or 3 other Apache committers
> looking to be involved in the project.
>
> Please cast your vote:
>
>   [ ] +1, bring MXNet into the Incubator
>   [ ] -1, MXNet should not enter the Incubator, because...
>
>  The vote will be open for at least 72 hours, and only votes from the
> Incubator PMC are binding.
>
> As the proposer, I consider my vote already cast in favour (and binding as
> I'm a PMC member).
>
> Thanks all,
>
> Hen
>

Re: LDAP changes to support podlings

[Stian Soiland-Reyes]

Not sure what was the decision to be made here, but +1 to all suggestions.
All of PPMC as podling owners makes sense to me as long as private@podling
is notified.

Great work!



On 16 Jan 2017 6:05 pm, "Sam Ruby"  wrote:

> TL;DR: We need to decide, for each PPMC, who gets to update the PPMC list
> and where notifications to be sent on changes.
>
> ---
>
> Background: we have a variety of tools that need access to PPMC member
> lists, including but not limited to: gitbox, phonebook, ponymail, roller,
> sonar, subversion, and whimsy.
>
> The plan is to consolidate all of this to LDAP.  Previously, a number of
> 'auth groups' were migrated from the subversion puppet definition to LDAP.
> The plan is to do podlings next, and ultimately change the way PMCs are
> stored in LDAP.
>
> Currently the 'best' (as in machine readable) list of ppmc member
> information is in the subversion puppet definition - even for podlings that
> don't make use of subversion as this currently is the most expeditious way
> to get ppmc member lists to show up in the the phonebook application.
>
> The cleanest list of mentors can be found in podlings.xml.
>
> More complete, but less machine readable, and not always consistently
> maintained information can be found on the individual
> https://incubator.apache.org/projects/ pages.
>
> ---
> gitbox, phonebook, ponymail, roller, sonar, subversion
> Current status: for ppmcs that have lists in the subversion puppet
> definitions, those lists have been loaded into LDAP, and augmented with
> mentor information from podlings.xml.  A list of all current podlings can
> be found here, and those that have been loaded contain links to individual
> pages:
>
> https://whimsy.apache.org/roster/ppmc/
>
> These pages are currently read-only, and contain links to the project
> page, mailing lists, and prior published reports.
>
> ---
>
> Near future: what we need to resolve is who should be the 'owners' and who
> should be the 'members' for each PPMC.  These are LDAP terms, and they can
> be disjoint, overlapping, or even identical.
>
> The key point is that owners can change membership of the lists, and
> members are what gitbox, ponymail, roller, sonar, and subversion will use
> for access control.
>
> No matter what is decided, owners will be limited to adding and removing
> people who are already committers; adding new ids entirely will still
> require using the new account request web page.  Furthermore, all change
> will trigger notification to, at a minimum, root@.  Additionally
> notifying the individual affected, the private list for the podling, and or
> the private list for the incubator are possibilities.
>
> Given that these controls will be in place, allowing all members to also
> be owners should be safe.  Limiting owners to only mentors would also be a
> valid choice.  This need not be the same choice for all PPMCs, but it
> probably would make life (and tooling) easier if it were.
>
> Once this decision is made, the whimsy roster tool will be updated to
> allow owners to update lists, and those owners will be asked to do so. At
> that point, the subversion access lists in puppet will be converted over to
> LDAP, and the infra team will stop accepting JIRA requests to maintain
> these lists.
>
> ---
>
> Not so distant future: the tools mentioned above will all be updated to
> use the common LDAP definition for podling membership.  As an example, the
> phonebook application will include all podlings, with data automatically
> updated within hours of a change.
>
> The whimsy roster tool currently contains links to mailing lists and
> posted board reports.  It could be updated to include links to other tools
> ranging from subscribing and unsubscribing to mailing lists to static sonar
> analysis.
>
> New tools could be built using this data: for example, all of the data
> needed to draft board resolutions related to graduation could be gathered
> from LDAP and podlings.xml.
>
> ---
>
> Further in the future: PMC definitions will be changed to match the way
> PPMC definitions are done.  At the present time, only PMC chairs can update
> PMC member and committer lists -- even for PMCs to which they don't
> belong.  Other PMC members who aren't PMC chairs can't update their own
> lists.
>
> - Sam Ruby
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Drop incubating requirement of Maven artifacts

[Stian Soiland-Reyes]

+0 from me.

I have also experienced that developers not very familiar with ASF may
interpret -incubator to describe build/code immaturity rather than
community/policy immaturity, and thus wait for graduation before
considering the code from a software engineering perspective rather than
(as intended) legal perspective.

This probably stems from a misunderstanding that Apache is focused on high
quality software and a belief that code (rather than a community) is in the
incubator to harden it's quality.

I am not sure how we can improve on this; particularly as you hint these
developers don't look further than the version number and might not even
have visited the podlings Apache homepage before dismissing the -incubating
releases.

We could change our descriptions of the incubator.apache.org site to better
reflect that we generally tend to adapt existing project rather than being
a starting ground for new initiatives (although that still happens) - yet
this would probably not be sufficient to change those misunderstandings.


I do however see the legal reasoning for -incubating, in particular as IPMC
might allow releases that include sources or dependencies in a grey zone
license/IP-wise, which would otherwise not be permitted or expected from an
ASF release.

Therefore, downstream consumers who care sufficiently about this should be
able to see a clear distinction between pre- and post-graduation artifacts,
in particular for binaries.


For Maven it made sense to put this as "-incubating" in  rather
than change groupId, which can cause conflicts post graduation.  What is
best practice for other systems must be figured out separately; not just
ignored.

The workaround of publishing binaries without any -incubator/-incubating
markers by using a non-apache group/name is probably a somewhat workable
solution for larger established projects like Groovy, but may also work
against community as it de-emphasises ASF, and outsiders might so easily
realise that the community is changing before graduation.

That the current policy is Maven-centric is not perfect, I think we should
require a similar "incubator" marker also for other distribution mechanisms
like Ruby Gems, at least if they include "apache" in their names/grouping.

On 3 Jan 2017 9:20 pm, "Josh Elser"  wrote:

(late to the party)

-1 (binding) as an ask to table the VOTE and try to reach some better
consensus.

I have to agree with Julian that some more discussion may be prudent here.
There are definitely two divided camps, both of which bring good points to
the table.

* Differing policies for the languages/tools of products that podlings
create (maven projects vs. python/ruby projects). Julian states this very
well.

* A clear definition of what the IPMC thinks "x.y.z-incubating" should mean
and some better public-facing docs on what "incubating releases" actually
mean.
  - Groovy is a great, recent example. They were a very "mature" software
project, but still were "immature" in the terms of an ASF community (purely
speaking of them as being a podling, not a TLP). Personally, if I see the
-incubating suffix on a version, I can recognize that the *community* is
the thing at risk. However, I can also see how those less affiliated with
the incubator could interpret it as "software quality". John states this
very well in the VOTE text itself -- it leaves me wondering if we couldn't
just be more clear out of the gates.

I also need to re-read the original thread from freemarker (no [DISCUSS] in
the subject and the holidays kept me from reading it closely) to think
about the original stated problem some more.

- Josh


Julian Hyde wrote:

> John,
>
> I see your points, and hopefully you see mine. I think we can agree on one
> thing: we have not reached consensus. :)
>
> The inconsistency among build tools is a red herring. If we want
> consistency across build tools (and more importantly across package
> formats, regardless of the tool used to build them), let’s first figure out
> what we want, and apply this to all build tools.
>
> Julian
>
>
> On Jan 3, 2017, at 3:34 AM, John D. Ament  wrote:
>>
>> Carsten, Julian,
>>
>> I want to reiterate my notes from a prior message [1] in case there is any
>> confusion over the ask.  There is a "best practice" around maven specific
>> releases that has been treated as policy,  [2].  This best practice for
>> some reason is only applied if you are using the maven build tool.  E.g.
>> published python packages, ruby gems do not have this requirement.  The
>> purpose of this thread is to realign maven specific releases with the
>> other
>> convenience binaries published by podlings.
>>
>> This is not intended to drop the -incubator/-incubating tag applied to
>> source releases.  It was however established in 2008 [3] that releases
>> published by the incubator were endorsed, the -incubator/incubating tag
>> was
>> to imply that the project itself was not considered stable and could go
>> away.
>>
>> John
>>
>> [1]:
>> 

Re: [VOTE] Release Apache Juneau 6.0.1-incubating-RC3

[Stian Soiland-Reyes]

PGP is silly in that the order of the identifies is fixed; and the first
one is shown in debug outputs.

 I managed to rearrange mine to put st...@apache.org in top by using tools
to split my key into its constituent parts and then cat it together in a
modified order.

Not recommended!

Much easier is to bite the bullet and make a brand new private key with @
apache.org first..

On 31 Dec 2016 3:55 am, "James Bognar"  wrote:

Yea...that's exactly what I thought I did.

On Fri, Dec 30, 2016 at 10:37 PM Craig Russell 
wrote:

>
>
> > On Dec 29, 2016, at 6:30 PM, James Bognar 
> wrote:
>
> >
>
> > Yea...that's my cat.
>
> >
>
> > I thought I did sign it with an Apache email address.  I'll recheck
that.
>
>
>
> It should be possible for you to add your apache email address to your
> key. And then re-up-load the key with the additional email address. IIRC
;-)
>
>
>
> Craig
>
> >
>
> > On Thu, Dec 29, 2016 at 8:27 PM Justin Mclean 
>
> > wrote:
>
> >
>
> >> Hi,
>
> >>
>
> >>
>
> >>
>
> >> +1 (binding)
>
> >>
>
> >> I checked:
>
> >>
>
> >> - name includes incubating
>
> >>
>
> >> - disclaimer exists
>
> >>
>
> >> - LICENSE and NOTICE are good
>
> >>
>
> >> - no unexpected binary files in release
>
> >>
>
> >> - all source files have ASF headers
>
> >>
>
> >> - can compile from source
>
> >>
>
> >>
>
> >>
>
> >> It would be a good idea (IMO) to sign with an apache email address
> rather
>
> >> than a sales force one.
>
> >>
>
> >>
>
> >>
>
> >> I assume you have permission from the author to distribute this? [1]
>
> >>
>
> >>
>
> >>
>
> >> Thanks,
>
> >>
>
> >> Justin
>
> >>
>
> >>
>
> >>
>
> >> 1.
>
> >>
> juneau-6.0.1-incubating/juneau-samples/src/main/
resources/org/apache/juneau/server/samples/averycutecat.jpg
>
> >>
>
> >> -
>
> >>
>
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>
> >>
>
> >> For additional commands, e-mail: general-h...@incubator.apache.org
>
> >>
>
> >>
>
> >>
>
> >>
>
>
>
> Craig L Russell
>
> c...@apache.org
>
>
>
>
>
>
>
> -
>
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>
>
>

Re: [DISCUSS] Drop the 2013 Alternate Voting Policy

[Stian Soiland-Reyes]

On 27 December 2016 at 20:44, Roman Shaposhnik  wrote:
> I'd rather not sanctify exceptions with a precise list, but rather stop at:
>
> "During incubation, a podling's release package may not be perfect. It

...  package may not be fully in compliance with [ASF release
policy](https://www.apache.org/dev/release.html).

> will be up to mentors and IPMC members
> to define the appropriate leeway".

... as long as it is [legal](https://www.apache.org/legal/resolved.html).


+1 to a more abstract text - as long as the podling release is legally
sound (e.g. does not include material we can't distribute under ASF
license) we can still permit it, even if it's not according to policy.

However it would be a judgement per podling - if a podling has been
told for two releases for instance to fix their NOTICE, then a third
release might be downvoted (not blocked) for that reason. It could
also happen that an issue is not identified until later - so it's not
easy to write it down as strict rules - and I think we've the current
practice is about right. Some "just enough" formalizing of that
practice, as Roman proposes, will help keep it along those lines also
for the future.

-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [DISCUSS] Graduating Apache Eagle

[Stian Soiland-Reyes]

This download page does not fully comply with the ASF distribution policy,
which says there should also be a link to the signature and description of
how to check it:

http://eagle.incubator.apache.org/docs/download-0.4.0.html

http://www.apache.org/dev/release-publishing.html#distribution_dist


Is a direct link from front page to an ( implicitly "endorsed"?)
third-party site GitHub (and no link to ASF downloads) OK according to
policy? I would have included a traditional Download link - it's OK for
that page to include both the source code and Maven coordinates, but I
don't think we should encourage downstream to "download from GitHub" at
this stage as it conflates what is a PMC-voted ASF release or not.

On 6 Dec 2016 11:22 pm, "Roman Shaposhnik"  wrote:

> On Tue, Dec 6, 2016 at 3:06 PM, Henry Saputra 
> wrote:
> > HI Roman, John,
> >
> > Most of the mentors have full plate to do and especially need to help
> > existing podling to be successful in incubator.
> >
> > Taylor has been very gracious to stay as  initial member of PMCs, so
> > we have 1 ASF member, which I think good enough and will be seed to
> > invite more Apache Eagle PMCs to be ASF member.
> >
> > Other than that, I don't the the current members should have good
> > level of diversity.
> >
> > If you looked at Apache Geode when it proposed for graduation, it has
> > 22 PMCs from Pivotal only one or two from different orgs.
>
> The majority of podlings that come as projects from a single vendor
> struggle
> with PMC diversity. But this gives them even more of a reason to come up
> with creative ways to mitigate it. This is exactly what Geode had to think
> about
> and I hope Eagle will think about as well.
>
> > ALL mentors in Eagle believe that the community have been operating in
> > the Apache way, create releases, invite new committers, and follow all
> > communications in Apache resources.
>
> Good to know! The mentor's vouching for it helps me a lot.
>
> Quick question to the community: why is there no way to download releases
> of the software that are linked from the http://eagle.incubator.apache.
> org/ ?
> Is GitHub being treated as the way to distribute it?
>
> Thanks,
> Roman.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

New mentor for Taverna podling

[Stian Soiland-Reyes]

Hi,

I've volunteered as a new mentor for Apache Taverna as we're nearing graduation.

I hope it's OK I added myself to the podling report checkoff for this
month even if my podlings.xml update came too late for the bot.

-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [RESTART] [VOTE] Graduate Apache Beam

[Stian Soiland-Reyes]

+1 (binding)

On 5 December 2016 at 23:30, Davor Bonaci  wrote:
> Hi everyone,
> Please vote on the draft resolution proposed by the Apache Beam PPMC below,
> which establishes Apache Beam as a new top-level project at the Apache
> Software Foundation, as follows:
>
> [ ] +1, Graduate Apache Beam from the Incubator.
> [ ] +0, Don't care.
> [ ] -1, Don't graduate Apache Beam from the Incubator because...
>
> Please note that this is a restarted vote, per John's request, to clarify
> the alternatives. The old voting thread is archived [1].
>
> Before voting, please see the full text of the draft resolution below and
> the corresponding discussion thread [2], and vote only after you feel ready
> to do so. The vote will be open for at least 72 hours. This is a procedural
> vote [3]; it is adopted by a simple majority of qualified votes (with no
> minimum).
>
> If approved by the Apache Incubator, the proposed resolution will be
> submitted to the Board of Directors for their consideration.
>
> Thank you!
>
> Davor
>
> [1]
> https://lists.apache.org/thread.html/a8e9cecfe93f0e464cc7c1774d2761ca14326df1101b7670ca8b1dc3@%3Cgeneral.incubator.apache.org%3E
> [2]
> https://lists.apache.org/thread.html/b9c1071b35558846836814575ada3cdca61c72dc1e672ab994a9c936@%3Cgeneral.incubator.apache.org%3E
> [3] http://apache.org/foundation/voting.html
>
> The full-text of the draft resolution proposed by the Apache Beam PPMC:
>
> X. Establish the Apache Beam 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 a unified programming model for both
>batch and streaming data processing, enabling efficient
>execution across diverse distributed execution engines
>and providing extensibility points for connecting to different
>technologies and user communities.
>
>NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>Committee (PMC), to be known as the "Apache Beam Project",
>be and hereby is established pursuant to Bylaws of the
>Foundation; and be it further
>
>RESOLVED, that the Apache Beam Project be and hereby is
>responsible for the creation and maintenance of software
>related to a unified programming model for both batch and
>streaming data processing, enabling efficient execution across
>diverse distributed execution engines and providing extensibility
>points for connecting to different technologies and user
>communities; and be it further
>
>RESOLVED, that the office of "Vice President, Apache Beam" 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 Beam Project, and to have primary responsibility
>for management of the projects within the scope of
>responsibility of the Apache Beam 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 Beam Project:
>
>  * Tyler Akidau 
>  * Davor Bonaci 
>  * Robert Bradshaw 
>  * Ben Chambers 
>  * Luke Cwik 
>  * Stephan Ewen 
>  * Dan Halperin 
>  * Kenneth Knowles 
>  * Aljoscha Krettek 
>  * Maximilian Michels 
>  * Jean-Baptiste Onofré 
>  * Frances Perry 
>  * Amit Sela 
>  * Josh Wills 
>
>NOW, THEREFORE, BE IT FURTHER RESOLVED, that Davor Bonaci
>be appointed to the office of Vice President, Apache Beam, 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 Beam 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 Beam Project; and be it further
>
>RESOLVED, that the Apache Beam Project be and hereby
>is tasked with the migration and rationalization of the Apache
>Incubator Beam podling; and be it further
>
>RE

Re: Write permission for Wiki

[Stian Soiland-Reyes]

I was about to - but realised I was not myself listed on
https://wiki.apache.org/incubator/AdminGroup :-)

Could someone with the right wiki karma add svimal2106 to
ContributorsGroup and StianSoilandReyes to AdminGroup..?




On 5 December 2016 at 08:34, Vimal Sharma  wrote:
> Hi,
> My Apache wiki username is svimal2106.
> Please add this username to Contributors Group so that I can edit the Apache 
> Atlas podling report for December 2016.
>
> Thanks
> Vimal



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [VOTE] Bring Griffin to Apache Incubator

[Stian Soiland-Reyes]

aintained lists:
>
> priv...@griffin.incubator.apache.org
>
> d...@griffin.incubator.apache.org
>
> comm...@griffin.incubator.apache.org
>
> Subversion Directory
>
> Git is the preferred source control system.
>
> Issue Tracking
>
> JIRA
>
> Other Resources
>
> The existing code already has unit tests so we will make use of
> existing Apache continuous testing infrastructure. The resulting load
> should not be very large.
>
> Initial Committers
>
> William Go
> Alex Lv
> Vincent Zhao
> Shawn Sha
> John Liu
> Liang Shao
>
> Affiliations
>
> The initial committers are employees of eBay Inc.
>
> Sponsors
>
> Champion
>
> Henry Saputra (hsapu...@apache.org)
>
> Nominated Mentors
>
> Kasper Sørensen (kasper...@apache.org)
>
> Uma Maheswara Rao Gangumalla (umamah...@apache.org)
>
> Luciano Resende (luckbr1...@gmail.com)
>
> Sponsoring Entity
>
> We are requesting the Incubator to sponsor this project.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: Trademark registration

[Stian Soiland-Reyes]

On 30 November 2016 at 09:51, Ian Dunlop  wrote:
> I saw the following on trademark registrations
> http://www.apache.org/foundation/marks/register#register and wondered if
> this was possible for incubator projects or only for those which have
> graduated. Any ideas?

I think it makes most sense for graduated projects; a podling project
is not guaranteed to graduate from the Incubator and might choose to
say move to a GitHub-only model.  This could then require a project
rename beyond removing "Apache", as ASF would have the trademark
registration and there might not be a new legal entity to move the
trademark to.

But that said, I don't think there's anything stopping such a
registration for podlings - not sure if policy-wise that would need to
include "(incubating)", which perhaps would look odd in a trademark.


-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: Incoming Website Changes

[Stian Soiland-Reyes]

I think sadly both our policies and guidance are a bit outdated, and
for instance very SVN-centric - but I'm all for a split as that means
it's at least easier to update the guidance - updating policy (beyond
typos) is presumably something that needs to be agreed by IPMC before
publishing.

The policy should not be too bound by current technology and
infrastructure, but should focus on the community-side.  The guidance
can be more exemplified.

This distinction could then be noted in the documents similar to W3C
specs who have "This section is non-normative".


Agree with Bertrand's suggestion of starting with a minimal policy
document, but of course that means more potential overlap and
confusion until the old ones are gone. (as well as perhaps longer
email fights? :)

On 30 November 2016 at 07:38, Bertrand Delacretaz
 wrote:
> On Wed, Nov 30, 2016 at 3:49 AM, John D. Ament  wrote:
>> .. should we just drop the
>> current "policy" document and make the guides the policy documents?...
>
> Clearly separating policy from everything else sounds good to me, but
> the policy docs should then be as concise as possible.
>
> Dunno if that can happen by just remixing the existing content, or if
> it's better to start a new minimal policy document or section now.
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

[RESULT] [VOTE] Graduate Commons RDF from incubator

[Stian Soiland-Reyes]

On 23 November 2016 at 13:46, Stian Soiland-Reyes  wrote:
> [Note: this is the IPMC vote on general@incubator - there's a
> concurrent VOTE thread on dev@commons]

> Please VOTE on graduating Commons RDF to Commons:

Thanks to everyone who voted!

The results are:

+1 Andy Seaborne (Incubator PMC binding)
+1 Sergio Fernandez (Incubator PMC binding)
+1 Stian Soiland-Reyes (Incubator PMC binding)
+1 Lewis John McGibbney (Incubator PMC binding)
+1 Jochen Wiedman (Incubator PMC binding)
+1 John D. Ament (Incubator PMC binding)
+1 Ted Dunning (Incubator PMC binding)

+7 positive binding votes, no negative votes.

The vote has PASSED at Incubator PMC (and at Commons PMC). I will
proceed with the relevant community and infrastructure request for
moving mailing list/repository/dist to Commons. (Any hints on this
welcome!)

As Commons RDF is graduating to become a subproject of Commons there
won't be a legal TLP resolution needed by the board.

-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [VOTE] Graduate Commons RDF from incubator

[Stian Soiland-Reyes]

FYI: Apache Commons has voted to accept Commons RDF as a new component with

https://lists.apache.org/thread.html/e5817369e5e713183efcac0ba54d1a7dac6a69e718b32d94b7fbe535@%3Cdev.commons.apache.org%3E

I will let the incubator vote extend till Monday in case someone
waited for that result.

On 23 November 2016 at 13:46, Stian Soiland-Reyes  wrote:
> [Note: this is the IPMC vote on general@incubator - there's a
> concurrent VOTE thread on dev@commons]
>
> Since Commons RDF entered incubation, it has evolved the understanding
> of its purpose, developed and released code base that is now
> stabilizing. Although the Commons RDF developer community is small,
> Apache Commons have shown interest in hosting the code as a new
> component; as intended when this podling was started.
>
>
> The Commons RDF PPMC has voted to graduate from the Incubator
> to join Apache Commons as a new component:
>
> https://lists.apache.org/thread.html/886ed903b3649203c794f7b7409f311b2391ebef1d9157177ba943b6@%3Cdev.commonsrdf.apache.org%3E
>
> This email carries over 4 IPMC binding votes from dev@commonsrdf:
>
> +1 Andy Seaborne (Incubator PMC binding)
> +1 Sergio Fernandez (Incubator PMC binding)
> +1 Stian Soiland-Reyes (Incubator PMC binding)
> +1 Lewis John McGibbney (Incubator PMC binding)
>
>
> Project Maturity report:
> https://github.com/apache/incubator-commonsrdf/blob/master/MATURITY.md
>
>
> This email propose a VOTE to graduate Commons RDF from the incubator,
> and for the code to move to Apache Commons as a new component.
>
> Note that all ASF committers have write-access to Apache Commons, thus
> all existing contributors will keep write access to Commons RDF.
>
>
> The Apache Commons PMC will also need to accept the component, so
> there's a concurrent vote on dev@commons:
>
> https://lists.apache.org/list.html?d...@commons.apache.org
>
>
>
>
>
>
> Please VOTE on graduating Commons RDF to Commons:
>
> [ ] +1 Yes, graduate Commons RDF from incubator
> [ ]  0 Undecided
> [ ] -1 No, because...
>
>
> This vote will be open for at least 72 hours, let's say 2016-11-26 17:00 UTC.
>
>
> --
> Stian Soiland-Reyes
> http://orcid.org/-0001-9842-9718



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: Clarification of Mentors from Proposal Guide

[Stian Soiland-Reyes]

I think practically mentors volunteer and the podling accept, IPMC does not
really need to decide on that. In the rare cases of many mentor volunteers
it may be useful for the Incubator community to guide the podling on which
mentors would be more beneficial, but then for the podling to pick rather
than IPMC (who?) to "appoint". In that sense IPMC just rubber stamp the
mentor list.

The point of the paragraph is that it is the Champion and Incubator
community overall that guides at the proposal stage, not particularly the
nominee mentors (although usually now the champion is also one of the
mentors). So we can shorten the paragraph to just:

> Mentors have no formal role until the proposal is accepted.

And if a mentor comes along after acceptance, then I think it is enough for
the podling to accept that person, as long as they are on IPMC there is no
need to do any formal appointment beyond updating the right files. (an ASF
Member may ask to join IPMC first).

On 25 Nov 2016 2:05 pm, "John D. Ament"  wrote:

> All,
>
> I was wondering if someone could help me clarify this block of text.  This
> is the section I believe is at an issue:
>
> http://incubator.apache.org/guides/proposal.html#template-mentors
>
> *It is common for additional Mentors to volunteer their services during the
> development of the proposal. The number of Mentors for a Podling is limited
> only by the energy and interest of those eligible to Mentor. Three Mentors
> gives a quorum and allows a Podling more autonomy. The current consensus is
> that three or more Mentors makes the incubation process run more smoothly.*
>
> *Note that since Mentors are appointed by the Incubator PMC at the end of
> the acceptance process, they have no formal role until the proposal is
> accepted. But informal enthusiasm from nominee Mentors is taken as a good
> sign.*
>
> In the first paragraph, we're saying that Mentors volunteer.  But the
> second paragraph states that they are appointed by the IPMC.  I'm inclined
> to just remove that first sentence from the proposal guide.  Anyone else's
> thoughts?
>
> John
>

Re: [VOTE] Weex to enter the Apache Incubator

[Stian Soiland-Reyes]

+1 (binding)

On 24 Nov 2016 10:47 pm, "Edward J. Yoon"  wrote:

> Greetings!
>
> I would like to call a vote for accepting "Weex" for incubation in the
> Apache Incubator. The full proposal is available below.  We ask the
> Incubator PMC to sponsor it, with myself (Edward J. Yoon) as Champion, and
> Luke Han, Willem Jiang, Stephan Ewen, and Niclas Hedhman volunteering to be
> Mentors.
>
> Please cast your vote:
>
> [ ] +1, bring Weex into Incubator
> [ ] +0, I don't care either way,
> [ ] -1, do not bring Weex into Incubator, because...
>
> This vote will be open at least for 72 hours and only votes from the
> Incubator PMC are binding.
>
> --
> https://wiki.apache.org/incubator/WeexProposal
>
> = Weex Proposal =
>
> == Abstract ==
> Weex is a framework for building Mobile cross-platform high performance UI.
> Weex enables developers to use Web-like syntax to build iOS, Android and
> Web
> UI with a single codebase.
>
> == Proposal ==
> Weex provide an uniform Web-like syntax for develop native Mobile App UI.
> By
> leverage the Javascript engine that enable dynamic update, the process of
> App interfce and content update can be simple and controllable just like
> Web.Compared with WebView based UI framework which performance are limited,
> Weex use build-in native components instead.
>
> Because of tag based syntax that maintain a consistent style with Web
> standards Weex using. Developers write in this language just like writting
> in HTML. After transforming to JSBundle by Weex tools, these tags will be
> rendered by build-in platform-specific components. The logic part of Weex
> syntax write in Javascript which don't need be compiled control these
> components.
>
> The vision of Weex is to complement gap between platform-specific Native UI
> and Web technical based UI in Mobile age. The team behind Weex believe that
> dynamicly interface update and high performance should be achieved at the
> same time when people develop a Mobile App. Meanwhile duplicate work
> between
> the different platforms should be avoided.
>
> == Background ==
> Prior to Weex, in order to develop high performance mobile application we
> need write at least three different codebase(iOS, Android, Mobile Web) or
> adopt WebView based UI technique(Apache Cordova for example) which can't
> satisfy the demand for performance.
>
> A special task force at Alibaba Inc try to provide a solution for this
> problem has been setup since 2013.  At first the team release a
> cross-platform rendering engine which render a special format JSON to
> native
> components on different platform. To output this JSON file the team had
> build a website which other developer can use to simply design final
> interface.
>
> Although This solution had worked for a while, we found it not able to meet
> our UI developer's habits. Most of our UI developer have Web background
> which make them used to use tag based language to design App interface.
> Meanwhile we found the JSON file lacks of enough flexibility. The following
> discussion inspire we start to develop Weex.
>
> Nowaday, Mobile Taobao App which developed by Alibaba Inc, the largest user
> volume eCommerce App in China has adapted Weex in a lot of UI. In the
> latest
> November 11th promotions(Alibaba's annual Singles' Day online shopping
> event), UI developers from Alibaba Inc have build more then 1,500 pages
> using Weex, 99.6% of all the promotional pages. The ratio of less than one
> second page open time is more than 90%, the frame rate is 53.0~58.5(depend
> on device) due to the high performance of Weex. In addition to user
> experience improvement, the productivity of page development and the
> efficiency of content delivery both have been improved.
>
> After open-source and have got a lot of followers in chinese mobile App
> development community, several of popular Apps listed on chinese top charts
> have adopted or planning for adopt Weex.(UCWeb, Tmall, YouKu, Suning
> etc...)
>
> == Current Status ==
> Weex has become an open source project since June 2016.  It has been used
> at
> a lot of Alibaba producted mobile softwares which running on the mobile
> phone of millions of users.
>
> Weex code repository located at GitHub. All development activities have
> already happened on GitHub as open source manner.
>
> == Community ==
> The community surrounding Weex is a variety of developer which have
> different technique background.iOS, Android, Web developer must collaborate
> closely to implement most Weex feature.
>
> Currently total 61 contributors involved in the GitHub development process.
> Weex repository has received 791 pull requests until Nov 2016.
>
> Beyond committer from Alibaba Inc, Weex community welcome anybody join us.
> Nowaday Evan You from Vue Technology LLC, Wang Run Xiang from Aipai Inc and
> lots of GitHub users have contributed source code or document to Weex.
>
> Weex syntax is inspired a lot from Web framework Vue.js. For better future
> of both Weex&Vue.js, we 

Re: [VOTE] Releasing Apache Metron (incubating) 0.3.0-RC1

[Stian Soiland-Reyes]

-generic", arch: "amd64", family: "unix"

On 17 November 2016 at 19:45, Casey Stella  wrote:
> This is a call to vote on releasing Apache Metron 0.3.0-RC1 incubating
>
>
> Full list of changes in this release:
>
> https://dist.apache.org/repos/dist/dev/incubator/metron/0.3.
> 0-RC1-incubating/CHANGES
>
>
> The tag/commit to be voted upon is apache-metron-0.3.0-rc1-incubating:
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-metron.
> git;a=shortlog;h=refs/tags/apache-metron-0.3.0-rc1-incubating
>
> The source archive being voted upon can be found here:
>
> https://dist.apache.org/repos/dist/dev/incubator/metron/0.3.
> 0-RC1-incubating/apache-metron-0.3.0-rc1-incubating.tar.gz
>
> Other release files, signatures and digests can be found here:
>
> https://dist.apache.org/repos/dist/dev/incubator/metron/0.3.
> 0-RC1-incubating/
>
> The release artifacts are signed with the following key:
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-metron.
> git;a=blob;f=KEYS;h=8381e96d64c249a0c1b489bc0c234d9c260ba55e;hb=refs/tags/
> apache-metron-0.3.0-rc1-incubating
>
>
> Please vote on releasing this package as Apache Metron 0.3.0-RC1 incubating
>
>
> When voting, please list the actions taken to verify the release.
>
> Recommended build validation and verification instructions are posted here:
>
> https://cwiki.apache.org/confluence/display/METRON/Verifying+Builds
>
>
> This vote will be open for at least 72 hours.
>
>
> [ ] +1 Release this package as Apache Metron 0.3.0-RC1 incubating
>
> [ ]  0 No opinion
>
> [ ] -1 Do not release this package because...



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [VOTE] Graduate Commons RDF from incubator

[Stian Soiland-Reyes]

http://incubator.apache.org/guides/graduation.html#subproject says

> To graduate as a subproject, the Mentors should start a VOTE thread on the 
> general list proposing that the IPMC signs off the graduation of the podling 
> as a subproject. This VOTEs should only be started once the project has VOTEd 
> to accept the subproject.

I hope it's OK we do a concurrent vote as we've already got 3 (now 4)
+1 Commons votes, but if anyone would like to await result of Commons
vote first I'm happy to extend this IPMC vote.

On 23 November 2016 at 16:26, John D. Ament  wrote:
> +1 yes please graduate into a subproject (I'm still not sure what the
> process looks like, if there's anything actually required)
>
> John
>
> On Wed, Nov 23, 2016 at 8:49 AM Stian Soiland-Reyes 
> wrote:
>
>> [Note: this is the IPMC vote on general@incubator - there's a
>> concurrent VOTE thread on dev@commons]
>>
>> Since Commons RDF entered incubation, it has evolved the understanding
>> of its purpose, developed and released code base that is now
>> stabilizing. Although the Commons RDF developer community is small,
>> Apache Commons have shown interest in hosting the code as a new
>> component; as intended when this podling was started.
>>
>>
>> The Commons RDF PPMC has voted to graduate from the Incubator
>> to join Apache Commons as a new component:
>>
>>
>> https://lists.apache.org/thread.html/886ed903b3649203c794f7b7409f311b2391ebef1d9157177ba943b6@%3Cdev.commonsrdf.apache.org%3E
>>
>> This email carries over 4 IPMC binding votes from dev@commonsrdf:
>>
>> +1 Andy Seaborne (Incubator PMC binding)
>> +1 Sergio Fernandez (Incubator PMC binding)
>> +1 Stian Soiland-Reyes (Incubator PMC binding)
>> +1 Lewis John McGibbney (Incubator PMC binding)
>>
>>
>> Project Maturity report:
>> https://github.com/apache/incubator-commonsrdf/blob/master/MATURITY.md
>>
>>
>> This email propose a VOTE to graduate Commons RDF from the incubator,
>> and for the code to move to Apache Commons as a new component.
>>
>> Note that all ASF committers have write-access to Apache Commons, thus
>> all existing contributors will keep write access to Commons RDF.
>>
>>
>> The Apache Commons PMC will also need to accept the component, so
>> there's a concurrent vote on dev@commons:
>>
>> https://lists.apache.org/list.html?d...@commons.apache.org
>>
>>
>>
>>
>>
>>
>> Please VOTE on graduating Commons RDF to Commons:
>>
>> [ ] +1 Yes, graduate Commons RDF from incubator
>> [ ]  0 Undecided
>> [ ] -1 No, because...
>>
>>
>> This vote will be open for at least 72 hours, let's say 2016-11-26 17:00
>> UTC.
>>
>>
>> --
>> Stian Soiland-Reyes
>> http://orcid.org/-0001-9842-9718
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [DISCUSS] Concur for Apache Incubator

[Stian Soiland-Reyes]

I think we should in principle aim for also a larger diversity in the
initial committers for a straight-to-TLP,
https://github.com/hortonworks/concur/graphs/contributors does not
show anyone that is not working for Hortonworks - but the proposed
committers (aka proposed PMC?) have broad ASF experience.

Perhaps the stay in the incubator would be short before graduation,
after the project shows non-Hortonworks folks are engaged.

Has this proposal or code base been discussed in any of the Hadoop
lists? I could not find anything in the list archives, but then I'm
not too familiar with Hadoop. Or perhaps it was discussed elsewhere
since development started in April?


On 23 November 2016 at 14:19, Greg Stein  wrote:
> On Wed, Nov 23, 2016 at 5:43 AM, John D. Ament 
> wrote:
>
>> On Wed, Nov 23, 2016 at 6:40 AM Roman Shaposhnik 
>> wrote:
>>
>> > On Wed, Nov 23, 2016 at 11:58 AM, Jean-Baptiste Onofré 
>> > wrote:
>> > > Hi Jitendra,
>> > >
>> > > I gonna take a deeper look.
>> > >
>> > > My first feedback would be about the name: Concur is traveling/expense
>> > > solution (https://www.concursolutions.com/).
>> > >
>> > > To avoid confusion, maybe it would make sense to choose another name.
>> >
>> > FIWI: these were my thoughts exactly. In fact, for a second there I
>> thought
>> > that SAP was donating Concur codebase.
>> >
>>
>> Good to know I wasn't the only one.
>>
>> Jitendra, So considering how strong of a community this is already and the
>> success of recent TLP direct projects, what goals do you have for
>> incubation?  And why incubation over straight to TLP?
>
>
> It is an external codebase, which sets a high bar. The initial committers
> do seem to mostly have ICLAs (haven't looked at all). The Board would
> likely want to see a large majority of them also being ASF Members, before
> considering straight-to-TLP.
>
> Cheers,
> -g



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [DISCUSS] Concur for Apache Incubator

[Stian Soiland-Reyes]

On 23 November 2016 at 11:40, Roman Shaposhnik  wrote:
> FIWI: these were my thoughts exactly. In fact, for a second there I thought
> that SAP was donating Concur codebase.
> In the spirit of bikeshedding I propose Apache Thor (or Heyerdahl) 'cuz
> you know: raft ;-)

As Norwegian I should not really disagree on that name -- but Thor is
already the name of lots of things, including at least two EU projecst
https://project-thor.eu/ (Open Research interoperability)
http://www.eu-thor.eu/ (Oceanography!)


Apache Heyerdahl..?

http://www.ssb.no/en/befolkning/statistikker/navn says:
> There are 410 [Norwegians] with Heyerdahl as their surname

(>200 meaning it is not a protected surname in .no :)

And 111 businesses - just in Norway - several doing IT stuff:
https://w2.brreg.no/enhet/sok/treffliste.jsp?navn=Heyerdahl&orgform=0&fylke=0&kommune=0


But we can discuss the proposal even if it has to change its name -
that's OK to sort in the very beginning (but is very preferably
community-wise to agree before actually moving to the Incubator).


I think it sounds like an interesting proposal but wonders which
consumers (and potential developers) it is targeting - I wonder about
the strong link to Hortonworks and Hadoop -- is Concur relying on
Hadoop, Hadoop might use Concur, or can Concur be used with many
things, including Hadoop?


I see https://github.com/hortonworks/concur is already using
org.apache.raft (and before org.apache.hadoop.raft) as a package name
- I find this approach for proposals a bit concerning trademark-wise;
but then I didn't look closely if this started as a fork/pull request
for Hadoop or similar?

-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

[VOTE] Graduate Commons RDF from incubator

[Stian Soiland-Reyes]

[Note: this is the IPMC vote on general@incubator - there's a
concurrent VOTE thread on dev@commons]

Since Commons RDF entered incubation, it has evolved the understanding
of its purpose, developed and released code base that is now
stabilizing. Although the Commons RDF developer community is small,
Apache Commons have shown interest in hosting the code as a new
component; as intended when this podling was started.


The Commons RDF PPMC has voted to graduate from the Incubator
to join Apache Commons as a new component:

https://lists.apache.org/thread.html/886ed903b3649203c794f7b7409f311b2391ebef1d9157177ba943b6@%3Cdev.commonsrdf.apache.org%3E

This email carries over 4 IPMC binding votes from dev@commonsrdf:

+1 Andy Seaborne (Incubator PMC binding)
+1 Sergio Fernandez (Incubator PMC binding)
+1 Stian Soiland-Reyes (Incubator PMC binding)
+1 Lewis John McGibbney (Incubator PMC binding)


Project Maturity report:
https://github.com/apache/incubator-commonsrdf/blob/master/MATURITY.md


This email propose a VOTE to graduate Commons RDF from the incubator,
and for the code to move to Apache Commons as a new component.

Note that all ASF committers have write-access to Apache Commons, thus
all existing contributors will keep write access to Commons RDF.


The Apache Commons PMC will also need to accept the component, so
there's a concurrent vote on dev@commons:

https://lists.apache.org/list.html?d...@commons.apache.org






Please VOTE on graduating Commons RDF to Commons:

[ ] +1 Yes, graduate Commons RDF from incubator
[ ]  0 Undecided
[ ] -1 No, because...


This vote will be open for at least 72 hours, let's say 2016-11-26 17:00 UTC.


-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: TSU/ECCN notification for Impala podling

[Stian Soiland-Reyes]

As you have noted in
https://github.com/apache/incubator-impala/blob/master/EXPORT_CONTROL.md,
"Designed for use with OpenSSL" sounds right to me for Impala - which
makes Impala an "Encryption item".

See also
https://github.com/apache/incubator-impala/blob/0d0c93ec8c4949940ec113192731f2adb66a0c5e/cmake_modules/FindOpenSSL.cmake


Correct that our policy is that Ted Dunning will have to send it as
the PMC chair - you need to update your "SUBMITTED BY" line (and
probably in the XML).

Personally I would also not send an encryption notice to a foreign
government authority without being somewhat legally protected as an
ASF officer. :-)



On 15 November 2016 at 04:11, John D. Ament  wrote:
> Todd,
>
> Please be cautious about mixing public/private email lists.  I'm removing
> impala's private based on this.
>
> The guide that Sailesh pointed to [1] mentions the "PMC Chair" which would
> be the Incubator PMC, and hence Ted Dunning.  If you don't hear back, may
> be best to ping him directly (I had assumed this was what Sailesh did).
>
> I just want to confirm, when you're talking about using OpenSSL, its more
> than just "you need to run Impala on a (Tomcat|HTTPd) instance with SSL
> enabled (e.g. the user would do that) and you're actually linking to
> OpenSSL in your product?
>
> John
>
>
> [1]: https://www.apache.org/dev/crypto.html
>
>
> On Mon, Nov 14, 2016 at 6:49 PM Todd Lipcon  wrote:
>
>> Hey folks,
>>
>> I'm helping out the Impala podling with their ECCN (crypto export) notice.
>> I added them to the page at http://www.apache.org/licenses/exports/ (well,
>> really I just committed a patch provided by Sailesh Mukil). The next step
>> is to send the TSU NOTIFICATION email to the various US Government email
>> addresses.
>>
>> I see Sailesh emailed general@ 11 days ago asking about who can send this
>> notice but didn't hear back. So now I'm trying again on his behalf :) As an
>> IPMC member and ASF member can I send in the notification, or would we
>> prefer that someone else do it? The generated email attached below lists
>> Roman as the contact, but iirc Ted Dunning is the current IPMC chair.
>>
>> ---EMAIL HEADER---
>> To: cr...@bis.doc.gov, e...@nsa.gov, web_s...@bis.doc.gov
>> Cc: legal-arch...@apache.org, {applicable project list}
>> Subject: TSU NOTIFICATION - Encryption
>> ---EMAIL BODY---
>> SUBMISSION TYPE:  TSU
>>
>> SUBMITTED BY: Roman Shaposhnik
>>
>> SUBMITTED FOR:The Apache Software Foundation
>>
>> POINT OF CONTACT: Secretary, The Apache Software Foundation
>>
>> FAX:  +1-919-573-9199 <(919)%20573-9199>
>>
>> MANUFACTURER(S):  The Apache Software Foundation
>>
>> PRODUCT NAME/MODEL #: Apache Impala
>>
>> ECCN: 5D002
>>
>> NOTIFICATION: http://www.apache.org/licenses/exports/
>>



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

[ANNOUNCE] Apache Commons RDF 0.3.0-incubating

[Stian Soiland-Reyes]

The Apache Commons RDF team is pleased to announce:

* Apache Commons RDF 0.3.0-incubating


Apache Commons RDF aims to provide a common Java API for RDF 1.1
graphs and datasets.

Commons RDF 0.3.0 adds API bindings for Apache Jena, Eclipse RDF4J,
JSON-LD Java as well as a standalone implementation.

This release also adds support for Quads, Datasets and generalized RDF.

Note that Commons RDF 0.3.0 adds an experimental RDFParser API which
is subject to change in the following releases; we welcome any
feedback and suggestions.


Commons RDF 0.3.0 is available from Maven Central and from:

https://commonsrdf.incubator.apache.org/download


For documentation and more, see
https://commonsrdf.incubator.apache.org/



Apache Commons RDF is an effort undergoing incubation at The Apache
Software Foundation (ASF) sponsored by the Apache Incubator PMC.
Incubation is required of all newly accepted projects until a further
review indicates that the infrastructure, communications, and decision
making process have stabilized in a manner consistent with other
successful ASF projects. While incubation status is not necessarily a
reflection of the completeness or stability of the code, it does
indicate that the project has yet to be fully endorsed by the ASF.



sha1 checksums:
965cbbb52946ae9ba710ab19a8fb931fbfe65e7f
apache-commons-rdf-0.3.0-incubating-src.zip
9e08b3edcc633eb07a1c303b1939a0faaebb6c1f
apache-commons-rdf-0.3.0-incubating-src.tar.gz


-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

[RESULT] [VOTE] Release Apache Commons RDF 0.3.0-incubating RC2

[Stian Soiland-Reyes]

Thanks to all who voted. The following IPMC binding votes were cast:

+1 Gary Gregory
+1 Sergio Fernández
+1 John D Ament

The release candidate is therefore ACCEPTED.

I will proceed with publishing the release.

On 11 Nov 2016 11:03 pm, "Stian Soiland-Reyes"  wrote:

> The Apache Commons RDF podling has voted to release
>
> Apache Commons RDF 0.3.0-incubating RC2
>
> Vote thread:
> https://lists.apache.org/thread.html/d7e8d9b2276fed6b688b64d9096f02
> 631a66eb01aaa9dde35d31bdf1@
>
> This forwards two IPMC binding votes from Gary Gregory and Sergio
> Fernández.
>
> We now invite the Incubator PMC to vote on this release candidate.
>
> Apache Commons RDF aims to provide a common Java API for RDF 1.1
> graphs and datasets. API bindings in Commons RDF 0.3.0 include Apache
> Jena, Eclipse RDF4J, JSON-LD Java as well as a standalone
> implementation.
>
> The release candidate to be voted over is available at:
> https://dist.apache.org/repos/dist/dev/incubator/commonsrdf/
> 0.3.0-incubating-RC2/
>
> sha1 checksums:
>
> 965cbbb52946ae9ba710ab19a8fb931fbfe65e7f apache-commons-rdf-0.3.0-
> incubating-src.zip
> 9e08b3edcc633eb07a1c303b1939a0faaebb6c1f apache-commons-rdf-0.3.0-
> incubating-src.tar.gz
>
> md5 checksums:
>
> 86feaef913fbe364872e9d87ea93eaaf apache-commons-rdf-0.3.0-
> incubating-src.zip
> f33f67dce9080eca3c53d23c92e2e56a apache-commons-rdf-0.3.0-
> incubating-src.tar.gz
>
> To build the release candidate (requires JDK 8, Maven 3.3), run:
>
> mvn clean verify
>
> git commit: 0bcb207521acfba04d3fabbe8fbc001ef9c0eb0a
> https://git-wip-us.apache.org/repos/asf?p=incubator-
> commonsrdf.git;a=tag;h=refs/tags/0.3.0-incubating-RC2
>
> KEYS:
> https://dist.apache.org/repos/dist/release/incubator/commonsrdf/KEYS
>
> Maven staging repository:
> https://repository.apache.org/content/repositories/orgapachecommons-1219/
>
> Release notes: https://github.com/apache/incubator-commonsrdf/blob/
> master/RELEASE-NOTES.txt
>
> Site:
> http://stain.github.io/incubator-commonsrdf/0.3.0-RC2/
>
> Please vote on releasing this release candidate as:
>
> Apache Commons RDF 0.3.0-incubating
>
> The vote is open for at least 72 hours, let's say 2016-11-15 12:00 UTC.
>
> [ ] +1 Release this package
> [ ] 0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because...
>

[VOTE] Release Apache Commons RDF 0.3.0-incubating RC2

[Stian Soiland-Reyes]

The Apache Commons RDF podling has voted to release

Apache Commons RDF 0.3.0-incubating RC2

Vote thread:
https://lists.apache.org/thread.html/d7e8d9b2276fed6b688b64d9096f02631a66eb01aaa9dde35d31bdf1@


This forwards two IPMC binding votes from Gary Gregory and Sergio Fernández.

We now invite the Incubator PMC to vote on this release candidate.

Apache Commons RDF aims to provide a common Java API for RDF 1.1
graphs and datasets. API bindings in Commons RDF 0.3.0 include Apache
Jena, Eclipse RDF4J, JSON-LD Java as well as a standalone
implementation.

The release candidate to be voted over is available at:
https://dist.apache.org/repos/dist/dev/incubator/commonsrdf/0.3.0-incubating-RC2/

sha1 checksums:

965cbbb52946ae9ba710ab19a8fb931fbfe65e7f
apache-commons-rdf-0.3.0-incubating-src.zip
9e08b3edcc633eb07a1c303b1939a0faaebb6c1f
apache-commons-rdf-0.3.0-incubating-src.tar.gz

md5 checksums:

86feaef913fbe364872e9d87ea93eaaf apache-commons-rdf-0.3.0-incubating-src.zip
f33f67dce9080eca3c53d23c92e2e56a
apache-commons-rdf-0.3.0-incubating-src.tar.gz

To build the release candidate (requires JDK 8, Maven 3.3), run:

mvn clean verify

git commit: 0bcb207521acfba04d3fabbe8fbc001ef9c0eb0a
https://git-wip-us.apache.org/repos/asf?p=incubator-commonsrdf.git;a=tag;h=refs/tags/0.3.0-incubating-RC2

KEYS:
https://dist.apache.org/repos/dist/release/incubator/commonsrdf/KEYS

Maven staging repository:
https://repository.apache.org/content/repositories/orgapachecommons-1219/

Release notes:
https://github.com/apache/incubator-commonsrdf/blob/master/RELEASE-NOTES.txt

Site:
http://stain.github.io/incubator-commonsrdf/0.3.0-RC2/

Please vote on releasing this release candidate as:

Apache Commons RDF 0.3.0-incubating

The vote is open for at least 72 hours, let's say 2016-11-15 12:00 UTC.

[ ] +1 Release this package
[ ] 0 I don't feel strongly about it, but don't object
[ ] -1 Do not release this package because...

Re: [DISCUSS] Documentation

[Stian Soiland-Reyes]

I guess primarily the answer is that your project should discuss this and
use whatever they are comfortable with; the incubator is not forcing any
technology. I would say that you should avoid proprietary formats (e.g.
.docx) so that anyone can contribute.

I think for developers Markdown (which is similar to AsciiDoc) edited in
git is reasonable simple to get into, as you can generally just write text
and then augment with !ore advanced syntax.

Pull Requests via GitHub is then quite easy as the web editor has previews.
Local editors like Atom also have live previews.

The fact that it is not WYSIWYG makes it much harder to deviate from the
common style, while a WYSIWYG-editor to me has too much freedom, documents
would easily have all kinds of fonts and styles dancing about as different
users edit it, unless you impose strict usage of the Heading levels etc
rather than hitting the Bold and font size buttons.

But it is obviously a barrier for non-developers to contribute, although it
can be used by example.

Like AsciiDoc, Markdown is a textual format so it is very git friendly,
unlike the Zip archives from OO which would just give you a generic binary
merge conflict; you would then solve it using Document Compare which is
possible in OO, but much smoother in Microsoft Word.

Apologies to OO devs, but using OpenOffice for documentation sounds to me
like yesterday's approach, where the end target is a static PDF to print
with blurry screenshots (shrunk to fit on A4), rather than a series of
hyperlinked web-pages that can be continually updated and improved.

So to me a wiki is often a good sweet spot for documentation, allowing
easier editing and encouraged hyperlinked and use of images and associated
example files. At ASF we have a Confluence install at
https://cwiki.apache.org/ which I think has a fairly good WYSIWYG editor
with sufficient freedoms and guidance; and the fact that it allows
structuring pages hierarchically is a massive plus for documentation.

On 11 Nov 2016 7:46 am, "Gunnar Tapper"  wrote:

> Hi,
>
> Related to the muti-lingual issue but also separate since it has to do with
> tools. This might be the wrong list to so please feel free to redirect.
>
> I've created a lot of documentation for Trafodion using Asciidoc, which
> allows the project to include the documentation with the source. It's OK
> but also complicated when wanting to provide PDF versions of the manuals
> due to font issues and other things.
>
> Talking with other contributors, there's a clear preference to use Apache
> OpenOffice for documentation. Beyond usability (and therefore more
> willingness to document), it also makes translation easier.
>
> Has anyone used OpenOffice for documentation before? If so, how is it
> handled with source control etc? (OpenOffice files are really zip archives
> with multiple files in them.)
>
> Thoughts?
>
> --
> Thanks,
>
> Gunnar
>

Re: [DISCUSS] China Contribution. (was: RocketMQ Incubation Proposal)

[Stian Soiland-Reyes]

I think we should separate language barriers for dev@ (a channel for all
its developers to agree on what the project is doing) and users@, which
could be much more diverse, but follow more of a Questions and Answer
format.

It's clear that in the Apache Way, the dev@ list should use a language that
all developers can follow (directly or indirectly via translators);
otherwise you will form sub-communities which may not agree on the
direction on the project.

Sometimes it might make sense to do dual-language posting, e.g. include the
message text in both Chinese and English. Yes, it is more work, but perhaps
some project need a more "UN" approach with many languages, to not be too
exclusive to a large potential dev base.

But I don't see a problem with language-specific *users* lists under ASF,
e.g rocketmq-用户列表@apache.org ("users list" ?), some projects like
OpenOffice use such lists for translation and localisation effort.

Also I think it's good for an ASF project committers to join third-party
user engagements where they happen anyway, like on StackOverflow, Gitter,
BioStars and regional equivalents, as long as they are public and don't
require payment; (but we would need to be careful about how we link to
those).

It it however important that any project development (including bug
reports) are brought back into the official Apache dev list, issue tracker
etc; where it would need to include an English summary/translation, with a
link or quote of the original discussion.

If say QQ don't allow you to catch up with what happened earlier (like on
Gitter) then perhaps some effort is needed to set up a bot with logging,
like we already have for the oldie IRC channels for Apache projects.

On 11 Nov 2016 7:43 am, "Reynold Xin"  wrote:

> Background: I have no tie to RocketMQ. I didn't even know about it until
> today and I don't know any of the people associated with the project. I am
> Chinese but living in the US. I'm purely playing devil's advocate about a
> meta-point here and don't know if it applies to RocketMQ or not.
>
> I definitely agree with Jeff's point that "my thoughts about community
> would be getting as many people and users involved as possible".
>
> That said, for a project started in China, it is unclear switching the
> primary development language from Chinese to English would help with
> accomplishing that goal. While lowering the bar for non-Chinese speakers to
> participate, it will limit the efficacy of its original developers, and
> increases the bar for more Chinese developers, which are the more natural,
> immediate expansion targets for the community.
>
> If we as a community want to enforce the usage of English as the standard,
> we should just explicitly say that.
>
> I'd avoid using the argument that English will bring more users, as it is
> not defensible and risk being interpreted as western arrogance. Afterall,
> three out of the six largest Internet companies (by market cap) are
> currently in mainland China, and they all have enormous daily active users
> even though they are targeting primarily Chinese.
>
>
> On Thu, Nov 10, 2016 at 11:14 PM, Jeff Genender 
> wrote:
>
> > I would think that English is generally used because its the most
> > international language, not because its the most used in the world.  Thus
> > it helps cross borders for communication.  At the end of the day, I think
> > you need to look at your community and ask if you want it to cross
> borders
> > or not.  Do you want worldwide contribution (and adoption)?  I can tell
> you
> > that I glean a lot of information from the mail lists when I run into
> > problems or issues using Apache software.  If the discussions are in
> > Chinese, you may miss a lot of people who can be a part of the discussion
> > from outside of China.  I think you really need to think about who you
> want
> > your users to be and how you want your product adopted.
> >
> > In addition, this is an incubated project.  AFAICT, the champion doesn’t
> > speak Chinese, and I am wild-guessing maybe 2 of the mentors do.  This
> > means the other mentors may have a difficult time steering the project
> when
> > they are needed.  It makes it difficult for the champion to asses any
> > problems without having someone notify him of a translated issue.  In the
> > unlikely event that the project requires input from the incubation PMC
> or,
> > the board for that matter, it would be very difficult to get a proper
> > insight into the issues without have solid knowledge of the language.
> >
> > I personally don’t know of any rule or regulation that locks down a
> > language and perhaps a board member can chime in on that.  But my .02 is
> > that if I were bringing a project to Apache, my thoughts about community
> > would be getting as many people and users involved as possible.  If you
> > don’t use a more cross-border/international language, then I believe that
> > you may ultimately be hindering your project beyond your borders.  I
> think

Re: [DISCUSS] China Contribution. (was: RocketMQ Incubation Proposal)

[Stian Soiland-Reyes]

On 11 Nov 2016 6:18 am, "Luke Han"  wrote:

> It's really not easy for Chinese people, they have to find out a way to
> access
> gmail or others since there's GFW, they are not native English speakers,
> they have limited experiences for open source especially the Apache Way.
> But they are willing to contribute, willing to participate global
> community, and try
> their best to learn and follow The Apache Way. We should have the patience
> for those new comers.

The warnings about firewalls are important as many ASFers (myself included)
are now gradually falling in love with third-party providers like GitHub
for ASF projects; but if those services are blocked (for arbitrary other
reasons), then that could cut off whole countries of potential developers
for the benefit of a slightly shinier button for the rest.

We can hope it helps that ASF is a non-profit and largely political-free
organisation (beyond internal and open source policies!) and that *.
apache.org is not generally blocked, but I guess even that could happen.

I hope people are not under the impression that you need to have access to
Google to contribute to Apache projects, any email system which can contact
and receive from @apache.org should work!  SMTP is still pretty resilient,
even if it takes days for a messagr to get through a "manual firewall" it
could still be compatible with 72h voting rules etc.

Re: [VOTE] Accept RocketMQ into the Apache Incubator

[Stian Soiland-Reyes]

+1 (non-binding)

On 10 Nov 2016 4:41 pm, "Bruce Snyder"  wrote:

> Subsequent to the discussion on RocketMQ, I would like to call a vote on
> accepting RocketMQ into the Apache Incubator.
>
> [ ] +1 Accept RocketMQ into the Apache Incubator
> [ ] +0 Abstain.
> [ ] -1 Do not accept RocketMQ into the Apache Incubator because...
>
> The proposal is pasted below and also available in the wiki here:
> https://wiki.apache.org/incubator/RocketMQProposal
>
> Also, the ASF voting guidelines are available here:
> http://www.apache.org/foundation/voting.html
>
> Thanks,
>
> Bruce
>
>
> = RocketMQ Proposal =
>
> == Abstract ==
>
> RocketMQ is a fast, low latency, reliable, scalable, distributed, easy to
> use message-oriented middleware, especially for processing large amounts of
> streaming data.
>
> == Proposal ==
>
> RocketMQ provides a message model including both pub/sub and P2P and it
> supports both reliable FIFO and strict sequential message queues. It also
> has the ability to accumulate a billion messages in a single queue,
> provides mobile, internet-friendly protocols such as MQTT and HTTP.
> RocketMQ also supports the ability to load data into Apache Hadoop for
> offline storage or to handle stream processing for Apache Storm.
>
> == Background ==
>
> RocketMQ was developed at Alibaba in 2011 and has been used in production
> there since that time. It can process the large amounts of events generated
> by various systems and provides a common repository for many types of
> consumers to access and process those events. RocketMQ also handles dozens
> of types of events including trade order process, search, social network
> activity stream and data pipeline. Every day at Alibaba, RocketMQ clusters
> process more than 500 billion events. The Alibaba Group also uses RocketMQ
> to provide message services for more than 3000 core applications.
>
> RocketMQ was developed to meet Alibaba's particular use cases to provide
> low latency message delivery and high throughput message sending. Alibaba
> has also created its cornerstone product derived from RocketMQ, a Platform
> as a Service (PaaS) product named the Alibaba Cloud Platform (
> https://intl.aliyun.com/).  More than 100 companies use the RocketMQ open
> source version today. We believe RocketMQ can benefit more people so, we
> would like to share it via the ASF and begin developing a community of
> developers and users via The Apache Way.
>
>
> == Rationale ==
>
> As background description, many organizations can benefit from a low
> latency, reliable, high throughput, distributed platform. Its usage is
> varied and we expect many new use cases to emerge. RocketMQ provides many
> features to support many use cases from enterprise application integration,
> to web applications to the flourishing of IoT applications.
>
> == Current Status ==
>
> === Meritocracy ===
>
> The intent of this proposal is to start building a diverse developer and
> user community around RocketMQ following the ASF meritocracy model. Since
> RocketMQ was open sourced, we have solicited contributions via the website
> and presentations given to user groups and technical audiences and have
> received positive feedback and contributions including clients for C++ and
> .NET. We plan to continue this support for new contributors and work with
> those who contribute significantly to the project to encourage them to
> become committers.
>
> === Community ===
>
> RocketMQ is currently being developed by engineers working for Alibaba
> where it is highly used in a production environment. We also have active
> users in or have received contributions from a diverse set of companies
> including CMBC(China Minsheng Bank), Schneider Electric(
> http://www.schneider-electric.com/), the China Railway Ministry official
> ticketing website, China Union, Sina, Umei (http://sh.jumei.com), Chinese
> Academy of Sciences and many more. We hope to grow the base of contributors
> by inviting all those who offer significant contributions and excel through
> the use of The Apache Way. Contributions from outside of Alibaba are now
> being received by the RocketMQ project, including a dashboard, the
> flume-rocketmq module, the storm-rocketmq and more.
>
> To further this goal, the project currently makes use of GitHub project
> features as well as a public mailing list via Google Groups.
>
>
> === Core Developers ===
>
> RocketMQ is currently being developed by engineers from Alibaba and
> Yeahmobi: Xiaorui Wang, Von Gosling, Jiangwei Jiang, Xinyu Zhou, Zhanhui
> Li. Xiaorui Wang, one of Alibaba MOM project owners is also the originator
> of the RocketMQ project. He has rich experience with open source software,
> as well as being active within the RocketMQ community. Von Gosling, another
> MOM project owner at Alibaba and co-creator of the RocketMQ project, is an
> active open source software committer and has been an active contributor to
> several projects in Alibaba, Apache community and Google C

Re: [VOTE] Release Apache Streams 0.4-incubating

[Stian Soiland-Reyes]

d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T16:41:47+00:00)
Maven home: /home/stain/software/maven
Java version: 1.8.0_111, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-45-generic", arch: "amd64", family: "unix"

On 7 November 2016 at 16:51, sblackmon  wrote:
> Hi Incubator PMC,
>
> The Apache Streams community has voted and approved the proposal to
> release Apache Streams 0.4 (incubating).
>
> We now kindly request the Incubator PMC members to review and vote on this
> incubator release.
>
> PPMC and IPMC feedback received during rc1 and rc2 votes (respectively) have 
> been addressed with rc3.
>
> Thread [VOTE] :
> https://lists.apache.org/thread.html/4ad0b6889fb61738209ba464e30dcc67d74ddacf60e820992dee83ab@%3Cdev.streams.apache.org%3E
>
> Thread [VOTE] [RESULT] :
> https://lists.apache.org/thread.html/4ad0b6889fb61738209ba464e30dcc67d74ddacf60e820992dee83ab@%3Cdev.streams.apache.org%3E
>
> The Release candidate to be voted upon is 0.4-incubating release candidate 
> (rc3), with the following artifacts up for a vote:
>
> incubator-streams-master source tag (r0.4-incubating):
> https://git-wip-us.apache.org/repos/asf?p=incubator-streams-master.git;h=b87b23b19649dbd17a26f43aac3e51358d7e2b32
> incubator-streams source tag (r0.4-incubating):
> https://git-wip-us.apache.org/repos/asf?p=incubator-streams.git;h=fc51194bcf44328759961dd1ee95df0b829fe98f
> incubator-streams-examples source tag (r0.4-incubating):
> https://git-wip-us.apache.org/repos/asf?p=incubator-streams-examples.git;h=5cfcc2511a714922cdbc8b15f9cec5a3170f4162
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachestreams-1019
>
> Source releases:
> https://dist.apache.org/repos/dist/dev/incubator/streams/0.4-incubating/streams-master-0.4-incubating-source-release.zip
> https://dist.apache.org/repos/dist/dev/incubator/streams/0.4-incubating/streams-project-0.4-incubating-source-release.zip
> https://dist.apache.org/repos/dist/dev/incubator/streams/0.4-incubating/streams-examples-0.4-incubating-source-release.zip
>
> Checksums of streams-master-0.4-incubating-source-release.zip:
> MD5: 182ed359685f35d950df3ba631d7d5e1
> SHA1: 3cf0110f6a1abd7160ae40088d35ce1d9b581ac0
> Checksums of streams-project-0.4-incubating-source-release.zip:
> MD5: 5321f8c3f470d464a6f354d8b624c726
> SHA1: ea294756549569e1a9392db362f3e3b33adc9dc1
> Checksums of streams-examples-0.3-incubating-source-release.zip:
> MD5: e7af881128418f3a782bf90d669348cb
> SHA1: f53abf0cd23e72f85b9877db7624df8f2e706f6c
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/sblackmon.asc
>
> Note that Maven 3.3.9 and JDK 1.8+ are now required, and that MAVEN_OPTS
> should set the java heap to at least 2G for best results.
>
> These repositories must be built and installed locally in the right
> order: first streams-master, then streams-project, finally streams-examples.
>
> To see the full set of steps used to validate and perform the release 
> candidate, and review the output of each step, visit this public wiki page.
>
> https://cwiki.apache.org/confluence/display/STREAMS/0.4-incubating+rc3+release+logs
>
> Note that to execute the full suite of integration tests, one must first
> prepare a testing environment with docker databases and working credentials
> to all providers.
>
> Vote will be open for 72 hours.
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [DISCUSS] Policy Question: GA for GitHub for Podlings

[Stian Soiland-Reyes]

+1 to both in principle (yay), but with admin access not initially given to
podling committers; as that could encourage "business as usual" for adding
friends&family as committers without a vote.

So I agree that the transition of the existing repositories need to be
handled well.

On 7 Nov 2016 10:23 pm, "Chris Mattmann"  wrote:

> Hi,
>
> As some of you may have seen the OpenWhisk podling being discussed now has
> requested to use GitHub as its primary master. Greg Stein our ASF Infra
> Admin
> has OK’ed this for OpenWhisk iff the IPMC is OK with it.
>
> I ask now:
>
> 1. Is the IPMC OK with this for OpenWhisk?
> 2. Is the IPMC OK with this in general availability for Podlings?
>
> I am +1 on both (IPMC hat on).
>
> Thanks.
>
> Cheers,
> Chris
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Incubator chat on Hipchat?

[Stian Soiland-Reyes]

I think for external chats we should rather recommend Gitter, which has
open rooms (anonymous lurking allowed) and "unlimited" searchable logs (and
unlimited number of users) and don't require workarounds with a sign up bot.

We did the same for Taverna, we tried an IRC chat, but its synchronous
nature and lack of modern web support meant it was not too useful as we
span timezones across the globe. We tried HipChat, but it somehow didn't
kick off.

Now that we tried Gitter (https://gitter.im/apache/taverna) we've seen a
large increase in brainstorming and developer activity (and have to keep
more of a watch to actively push decisions back to list. :-)). I think its
email notifications is a good way to lure people back (or scare away!).

The downside is that participation requires login with Twitter or GitHub,
which some communities might have reasonable objections to.

On 4 Nov 2016 2:33 am, "Wade Chandler"  wrote:

> For the NetBeans community we had been using IRC, but then setup Slack, and
> it has seen an uptick over IRC which per logging and notifications had been
> harder to support and stay connected. We setup a sign up bot at
> https://netbeans.signup.team, and we also have a chat room hooked/bridged
> to our IRC channel, so we service both as a collective; good on mobiles
> too. We have as an item to talk to Slack about OSS and limits/restrictions.
>
> We don't intend it to replace mailing lists, Jira, nor the wiki, but look
> at it as dynamic chats and community building allowing to have hack, help,
> or real time hang time sessions. We didn't know about the Apache HipChat,
> but I must confess I much prefer Slack having used both during my day job.
>
> Wade
>
> On Nov 3, 2016 10:50 AM, "Marvin Humphrey"  wrote:
>
> > On Wed, Nov 2, 2016 at 3:23 PM, John D. Ament 
> > wrote:
> >
> > > Infra recently started leveraging hipchat.  A few PMCs have made use of
> > > it.  I was wondering, would it be beneficial to anyone if we setup an
> > > incubator room in hipchat?
> >
> > How about just promoting the #asf IRC channel on freenode.net?
> >
> >   https://kiwiirc.com/client/irc.freenode.net/#asf
> >
> > Better for podling contributors to make connections to the wider ASF
> > rather than to limit themselves to the current incubator, and the #asf
> > channel is already well established.
> >
> > We could even embed the Kiwi IRC client in an iframe on the Incubator
> > website, at say http://incubator.apache.org/chat alongside guidance
> > documenting how we expect real-time communications to be used.
> >
> > https://kiwiirc.com/client/irc.freenode.net/#asf";
> > style="border:0; width:100%; height:450px;">
> >
> > Marvin Humphrey
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: Incubator chat on Hipchat?

[Stian Soiland-Reyes]

I think it sounds good with a chat for more practical questions, like "How
can I add userX to systemY on our infrastructure..?", but not for policy or
release questions. And if there is no reply on the chat, then send an email
anyway.

A chat can also be welcoming for new potential podlings to ask initial
questions, e.g. if they haven't got a champion yet. HipChat allows
anonymous sign-ins, so "newbies" won't need an ASF account. We would
obviously need to link to the chat from our web site for that :-)

Remember:
"If it didn't happen on the mailing list, it didn't happen"

On 3 Nov 2016 7:32 am, "Evan Hughes"  wrote:

> @mike Official content does need to be on the mailing list but small
> discussions could be made on the hipchat channel.
>
> ~ Evan
>
> On Thu, 3 Nov 2016 at 17:19 Mike Jumper  wrote:
>
> > On Nov 3, 2016 00:02, "Jean-Baptiste Onofré"  wrote:
> > >
> > > Hi John,
> > >
> > > it sounds like a good idea. I would allow "direct" communication
> between
> > the podling guys and the mentors/shepherd (to discuss release or report
> > content).
> > >
> >
> > Wouldn't release/content discussion be best conducted on the mailing
> lists?
> >
> > Thanks,
> >
> > - Mike
> >
>

Re: Release License Audit

[Stian Soiland-Reyes]

Apache RAT helps a lot - at least to find files which hasn't got a
license header - but also manual grep for "Copyright", "License",
"GPL" etc.  Some of these will require you to update your LICENSE or
NOTICE files.

Then you would have to go through binary files and check their origin,
e.g. PNGs for toolbar buttons.


A second item is to check the dependencies your code depends on, here
the Maven dependency plugin and Maven License pluginS (there are two)
will help you somewhat. Usually there are some  which
didn't bother to put a  to their pom.xml, those would have to
be checked manually.

If you do binary releases that include third-party libraries, then
that release would need it's own augmented LICENSE/NOTICE to cover the
libs.


If it's a larger project, then to keep track of this for a podling it
might be good to do a wiki page or two and raise Jira issues to track
those files you are not quite sure of.

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

Re: How to denote unusual copyright circumstances, was Re: [VOTE] Impala 2.7.0 release candidate 3

[Stian Soiland-Reyes]

On 4 October 2016 at 20:21, Henry Robinson  wrote:
>> > After further consideration, I have a patch in flight to fix that. It
>> > is a compiled source file.
>> >
>> > However, my question was intended to be broader. As Henry notes, there
>> > are some files that are Copyright Cloudera that were not part of the
>> > SGA. How shall we annotate those to let future IPMC release voters
>> > understand that the files are intentionally annotated the way they
>> > are?
>> >
>>
>> Is Cloudera willing to donate them?
>>
>
> Perhaps - but these files belong to their own, separate projects, distinct
> from Apache Impala, but are a bit too small to support a community and
> therefore aren't good candidates for incubation.
>
> Isn't the right way to address this to make a note in LICENSE.txt? That's
> what we do for compatibly-licensed files which have a non-ASF copyright
> holder.

They can still be donated to Impala with another Software Grant,
however you would need that both from Cloudera Inc. and Sergey Lyubka
(CTO of Cloudera) given the joint (c) at
https://github.com/apache/incubator-impala/blob/master/be/src/thirdparty/squeasel/squeasel.c

(I guess this code predates Sergey's co-founding of the Cloudera corporation)


Somehow Cloudera's (c) is not noted in
https://github.com/apache/incubator-impala/blob/master/be/src/thirdparty/squeasel/LICENSE
and neither are listed in the top-level LICENSE - so that is what
needs sorting out.


Many ASF projects 'adapt' such free-hanging "bits and bobs code" under
their umbrella - sometimes such code can get a "new life" - that's
after all part of what open source is about.


If they are in a SG it means they would be covered by the ASF license.
But there should not be a big problem with them being mentioned in the
LICENSE file with the compatible MIT license - at least if it's likely
to be "dormant" code that won't evolve much under Apache. The only
effect is that some of the protections of the ASF license then won't
clearly apply - e.g. protection against patent litigation.

I guess the main principle is that the 'main' project code should be
covered by the software grant - having remnants from the same
copyright holder that is not part of the software grant should
understandably be a yellow flag.


I think as a project (with mentors help) Impala will have to review if
the code in question is "important enough" (e.g. contains a patented
algorithm, or is core to how Impala works) to pursue additional
Software Grant (or license change) from upstream or if it's just an
innocent embedded dependency that can be noted it in the top level
LICENSE.


-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [Proposal] Move Wiki Access Requests somewhere

[Stian Soiland-Reyes]

I think it's important that non-Apache folks have an easy way to edit
their proposal as there will typically be changes suggested after they
post it here; having the proposal editing "Apache only" would not be
too good for newcomers although the champion would always be able to
do it.

But +1 for a move to Confluence which has its own registration system.

(If we could have Confluence also for the podling reports.. that would
be awesome!)

On 5 October 2016 at 16:35, Shane Curcuru  wrote:
> Are most requesters already committers, or no?
>
> If so, then *cough* whimsy tool *cough*.  That's a place we can create
> simple AUTH'd request tools that channelize things; even as a front end,
> it would ensure the requests have a specific which-wiki, who is the
> username, etc. that you don't always get from emails.
>
> Just a crazy idea I can't help with yet.  But agree: finding ways to
> reduce non-interesting threads here would help people follow the
> interesting discussions or votes.
>
> - Shane
>
> Benjamin Young wrote on 10/5/16 10:22 AM:
>> The incubator list is pretty popular. ;) Not less so these days with
>> the NetBeans discussions, etc.
>>
>> I’d like to propose (fwiw) that a mailing list be setup to ask for
>> wiki access (perhaps wiki@incubator.a.o) and that it be used
>> primarily for that purpose. If possible, the list could be setup to
>> receive emails from anyone (without prior subscription) to avoid the
>> need to “hang around” on that list if all you needed was to make an
>> edit somewhere.
>>
>> Alternatively, perhaps a web form could be setup to mail the IPMC
>> directly.
>>
>> Or, the much harder alternative, moving to Confluence, which I think
>> avoids this request need / has it’s own more automated way of
>> handling such things (maybe).
>>
>> The hope is just to reduce the signal to noise ratio here—which is
>> already quite high due to so many projects talking in one general
>> space.
>>
>> Thanks for considering this idea! Benjamin
>>
>> -- http://bigbluehat.com/ http://linkedin.com/in/benjaminyoung
>>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

[IPMC] Create incubator-example.git repository?

[Stian Soiland-Reyes]

The feedback on creating the fictional "Apache Extra" repository was positive:

https://lists.apache.org/thread.html/52db935c7ea3798ab358a03932e5ac5240d364606db52e07b840faef@%3Cgeneral.incubator.apache.org%3E


I was unable to request the git repository incubator-example, as INFRA
told me we now have to use:

https://reporeq.apache.org/



It seems only IPMC folks can do that for the incubator (reasonably
enough)  - perhaps some IPMC folks could ask to create at
https://reporeq.apache.org/

 ?

repository name: incubator-example.git
Commits to: comm...@incubator.apache.org
[x] mirror to github
[x] Enable github integration
Github notifications: d...@incubator.apache.org


(I think the otherwise dormant dev@incubator would make sense for
GitHub notifications so we don't spam general@incubator)

-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [EXAMPLE] bootstrapping (was: Apache Example project?)

[Stian Soiland-Reyes]

I've asked for the git repository incubator-example with github integration

https://issues.apache.org/jira/servicedesk/agent/INFRA/issue/INFRA-12713
https://issues.apache.org/jira/servicedesk/agent/INFRA/issue/INFRA-12714

I asked for Travis CI integration so we can show the outside world is
still there.


We can seed it with a dummy multi-module Maven project and see how it
could be "released".



How do we keep track of the various requests to be done? On
http://incubator.apache.org/guides/ ?


Perhaps a good home for many such pages would be
https://cwiki.apache.org/confluence/display/INFRA - but I don't have
write access there.


Should we have a neighbouring incubator-example-site or just a site/
folder for the web?


Luciano - what is the best way to ask INFRA for such a website as in
https://github.com/apache/apache-website-template with git2pub (?) and
buildbot? This has been changing every 3 months so I've lost track of
what is the best approach :-)



On 3 October 2016 at 13:48, Stian Soiland-Reyes  wrote:
> On 3 October 2016 at 06:30, Luciano Resende  wrote:
>> +1,
>>
>> I had started something similar, at least on the website side, with best
>> practices and required branding items.
>>
>> Please consider adding it to the "example" project :
>>
>> https://github.com/apache/apache-website-template
>
> Brilliant - yes, that's exactly the kind of thing I mean!  You've
> already got a great Community page there:
> https://github.com/apache/apache-website-template/blob/master/site/community.md
>
>
> So - how do we proceed? I suggest to use the [EXAMPLE] tag on this
> list as there could be a couple of things we need to agree (not
> discuss!) what best practice actually is.
>
> Do we need an IPMC vote?
>
> We need to request from infra something like:
>
> git repository incubator-example
>   - w/ pull request sync to general@incubator ?
>
> Jira  (or brave: GH issues? Fluo can inform us)
>
> git repository incubator-example-site
>   (alternatives: apache/apache-website-template as-is; site/ folder in
> incubator-example repo)
>
> http://example.incubator.apache.org/
>   - and corresponding git2pub
>
>
> I am not sure about separate mailing list (who would sign up?)
> although we can fake that on its mailing list page.
>
>
>
> --
> Stian Soiland-Reyes
> http://orcid.org/-0001-9842-9718



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [EXAMPLE] bootstrapping (was: Apache Example project?)

[Stian Soiland-Reyes]

Thanks for the feedback from Fluo!

I didn't think about the impediments access-wise. Also there could be
difficulties if the project has more than one git repository.

I guess the double-email problem is also why you moved notifications
to the separate
https://lists.apache.org/list.html?notificati...@fluo.apache.org


I think for Apache Example (tm) (incubating) we should then use
regular Jira (works out of the box) - but I guess we could mention the
GH-issues alternative as well.  I think for many things we will need a
kind of "meta" link. Say for instance let's say
example.incubator.apache.org gets a "contributing" page that says you
can raise GitHub pull requests such and such.  The "meta" page for
this should say how this can be requested from INFRA and what kind of
email notifications would happen.


On 5 October 2016 at 00:51, Keith Turner  wrote:
> On Tue, Oct 4, 2016 at 6:43 PM, Christopher  wrote:
>> On Tue, Oct 4, 2016 at 6:25 PM Josh Elser  wrote:
>>
>>>
>>>
>>> Stian Soiland-Reyes wrote:
>>> > On 3 October 2016 at 06:30, Luciano Resende
>>> wrote:
>>> >> +1,
>>> >>
>>> >> I had started something similar, at least on the website side, with best
>>> >> practices and required branding items.
>>> >>
>>> >> Please consider adding it to the "example" project :
>>> >>
>>> >> https://github.com/apache/apache-website-template
>>> >
>>> > Brilliant - yes, that's exactly the kind of thing I mean!  You've
>>> > already got a great Community page there:
>>> >
>>> https://github.com/apache/apache-website-template/blob/master/site/community.md
>>> >
>>> >
>>> > So - how do we proceed? I suggest to use the [EXAMPLE] tag on this
>>> > list as there could be a couple of things we need to agree (not
>>> > discuss!) what best practice actually is.
>>> >
>>> > Do we need an IPMC vote?
>>> >
>>> > We need to request from infra something like:
>>> >
>>> > git repository incubator-example
>>> >- w/ pull request sync to general@incubator ?
>>> >
>>> > Jira  (or brave: GH issues? Fluo can inform us)
>>>
>>> As far as I know, after we got everything set up (which, admittedly, I
>>> think was more tricky because pre-ASF "fluo" was already on Github, code
>>> and issues), GH issues have been smooth-sailing. As long as you're OK
>>> with closing issues via git commit message, anyways :)
>>>
>>>
>> Closing issues with FF merge or git commit message isn't a big deal, but
>> the biggest issue with using GH issues at ASF is the lack of ability to use
>> labels/milestones for issue-tracking/planning. Some of that can be done
>
> Nothing new to add, just want to reinforce how much of an impediment
> this is. Not being able to utilize GH labels and milestones is really
> suboptimal for coordination and planning purposes.  Can't mark issue
> as bug or feature, can't set its projected fix version, can't easily
> see what issues were fixed in a version, etc.
>
>> manually with Wiki/mailing list, but it's kind of a pain. There can also be
>> a lot of duplicate spam to users if they subscribe to GH issues, and then
>> also subscribe to the mailing lists for activity notifications.
>>
>>
>>> > git repository incubator-example-site
>>> >(alternatives: apache/apache-website-template as-is; site/ folder in
>>> > incubator-example repo)
>>> >
>>> > http://example.incubator.apache.org/
>>> >- and corresponding git2pub
>>> >
>>> >
>>> > I am not sure about separate mailing list (who would sign up?)
>>> > although we can fake that on its mailing list page.
>>> >
>>> >
>>> >
>>>
>>> -
>>> 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
>



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [RESULT][VOTE] Apache Fluo 1.0.0-incubating (rc2)

[Stian Soiland-Reyes]

On 4 October 2016 at 20:08, Christopher  wrote:

> (Note, since I'm calling the vote late, I've included Billie's vote, which
> was received after the initial 72 hours, but since there were no -1 or
> +/-0 votes and I didn't get a chance to call it before she voted, this
> seems reasonable. IPMC, please let us know if not.)

That's fine - as a RM you are free to call the vote result whenever
you want after "at least" 72 hours. You are right that you would have
to then include any negative votes, even if they arrived after 72
hours.

Sometimes you may have a situation where a PPMC member asks you to
extend the deadline to get time to review it - it's up to you if you
want to honour that on a reasonable time scale (but remember
"community over code").

In one case the project realized after the RC vote was passed that
there was a big build issue on Windows and decided to drop the RC
anyway. As an RM you can (after coordinating with list) make such
decisions if needed.

A positive [VOTE][RESULT] is not binding on the RM to go through with
publishing - but anyone else in the PPMC could also publish those
artifacts without another vote, say if the RM happen to fall ill.
(This would also be the case if a non-PPMC member is the one calling
the vote).

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

[EXAMPLE] bootstrapping (was: Apache Example project?)

[Stian Soiland-Reyes]

On 3 October 2016 at 06:30, Luciano Resende  wrote:
> +1,
>
> I had started something similar, at least on the website side, with best
> practices and required branding items.
>
> Please consider adding it to the "example" project :
>
> https://github.com/apache/apache-website-template

Brilliant - yes, that's exactly the kind of thing I mean!  You've
already got a great Community page there:
https://github.com/apache/apache-website-template/blob/master/site/community.md


So - how do we proceed? I suggest to use the [EXAMPLE] tag on this
list as there could be a couple of things we need to agree (not
discuss!) what best practice actually is.

Do we need an IPMC vote?

We need to request from infra something like:

git repository incubator-example
  - w/ pull request sync to general@incubator ?

Jira  (or brave: GH issues? Fluo can inform us)

git repository incubator-example-site
  (alternatives: apache/apache-website-template as-is; site/ folder in
incubator-example repo)

http://example.incubator.apache.org/
  - and corresponding git2pub


I am not sure about separate mailing list (who would sign up?)
although we can fake that on its mailing list page.



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Apache Example project?

[Stian Soiland-Reyes]

Hi,

There's been many discussions recently around what is the best practice for
git tagging, release procedures, licencing notes, web site publishing etc.

The landscape is always changing as technologies and INFRA procedures
evolve (yay!). Hunting around the different existing projects for
inspiration can be fun for podlings, but time consuming , as well as being
a bit variable as different mentors have different reference points.

I'm all for diversity and that projects settle this themselves. However I
wonder if it would make sense to gather these things as a kind of Examplar
project?

I'm thinking of extending Justin's excellent LICENSE and NOTICE example
project [1] [2] but make it a real with its own apache.org git repository
and website that anyone in the incubator can help update.

That way new podlings can have a quick look, bootstrap and "mutate"
accordingly (as well as shop around other projects or bring in whatever
they had outside)

We can call it Apache Example, and even do an actual org.apache.example
release of it; natively from the Incubator IPMC!

So for instance I think it would make sense to have a multi-module Maven
project with an assembly-based source releases and artifacts to Central,
Github pull requests enabled, and a Jekyll-based Markdown site managed with
git2pubsubkub. That way we can showcase the "modern" Apache way without
being all bleeding edge.

Thoughts? Do I need to write a proposal...? :-)

1. https://vimeo.com/171210141
2. https://github.com/ 
justinmclean /
ApacheWombat

Re: MySQL FOSS License Exception

[Stian Soiland-Reyes]

As Shane points out, such "Special exceptions" would in theory be good
enough for an open source project, but it restricts commercial
downstream users beyond the ASF license (which gives them the
"freedom" to NOT distribute the source)

https://www.apache.org/legal/resolved#category-x


However you can have an optional dependency and give users
instructions on how to build/add mysql support - given that the
project generally does not require it (most users would not need it).
With JDBC and Maven's true (can SBT do that?)
this should be quite easy to achieve for the mysql client lib; several
ASF projects already do this:

https://github.com/search?q=org%3Aapache+mysql&type=Code


What would NOT be ok is an "Apache mySQL Friend" - e.g. an ASF product
that would be pointless without the (L)GPL component - even if you
managed to sneak away from a compile-dependency. :-)

(Where this gets tricky is if a project has such optional Connector
plugins, but the plugin is released on its own)


Refs:
https://www.apache.org/legal/resolved#optional

On 30 September 2016 at 02:38, Shane Curcuru  wrote:
> Donald Szeto wrote on 9/29/16 6:13 PM:
>> Hi all,
>>
>> I have searched around the Internet and haven't seen this discussed
>> (appreciate pointers if I missed any existing discussion).
>>
>> The exception: https://www.mysql.com/about/legal/licensing/foss-exception/
>>
>> I am curious how Apache view this exception. Is it okay for Apache source
>> code to depends on it? What about binaries? Appreciate any input. Thanks!
>
> My bet is no, because it doesn't meet Apache's license criteria:
>
>   https://www.apache.org/legal/resolved.html#criteria
>
> In particular, the ASF's intent is that third parties may take Apache
> software releases and use or redistribute a variety of works based on
> them without any additional restrictions other than the permissive
> Apache license.  This is intended to apply for further redistributions
> as well, where the third party's licensing would permit it.
>
> That is, our policy explicitly tries to avoid special cases that the
> *ASF* might be able to take advantage of, but that a *redistributor* of
> a larger work including our Apache released software might not be able
> to take advantage of (because they use a different or commercial license
> for some of the work).
>
> - Shane
>
>
> -------------
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: Can you un-open-source a product? Re: [DISCUSS] Olympian Incubation Proposal

[Stian Soiland-Reyes]

I think Apache should not take an active part in any forks, as it could
ruin the long-standing approval with the commercial community.

However I think going the Jenkins fork route is the way for these
communities that want to move forward:

Move to GitHub, change the name & logo, clean up IP, actively grow the
community (e.g. add to the GH organisation after 2 pull requests), make
frequent releases (not too ambitious design changes), have nice and
professional looking web pages, etc.

A bit of noise in the process is necessary so the fork gets attention. It
is a hostile fork, but community-backed. Give it a year or two, and the
fork could be stronger and independent - at which point I think ASF would
have less qualms about accepting the new community - it would kind of be
pre-incubated.

A GitHub fork also makes the fall shorter if the original copyright holders
change their mind and embrace Open Development; they can then (at least in
theory) re-merge the communities by approving the new name as "official
successor" and join the effort; perhaps at that point a move to ASF would
be a very good option to form new neutral ground.

Re: Git release candidate tagging policy? [was: Re: [VOTE] Apache BatchEE 0.4-incubating]

[Stian Soiland-Reyes]

On 28 September 2016 at 16:40, Mark Struberg  wrote:
> But otoh if a project decides to use -RC1..17 it's also fine.
> BUT: they pollute their branches and tags and they actually would need to do 
> a 2nd VOTE afterwards on the .Final release. So it is much more work and thus 
> not recommended. But otoh it's not a blocker neither.

They will not need a second vote to retag from say "0.5.0-RC3" to
"0.5.0" - the whole point of a VOTE is to decide if a RC is to going
out as the version it aspires to. It just means you have to use the
"RCx" string only in the tag name and dist directories, not inside the
candidate's  strings or filenames.

(Apache projects can also distribute milestone releases - but to avoid
confusion those should not be called "Release Candidates" but rather
'alpha2' etc. and are still formally an "Apache release" with their
own RCs- see https://www.apache.org/dev/release.html#release-types )


Projects are not required to do a vote to make a git tag. They are
required to make a vote to publish a release artifact (by policy the
upload to http://www.apache.org/dist). And as you said, the git commit
is (somewhat) cryptographically sound (sha1 has known collisions)  -
so assigning another tag for the commit that was approved (and
referenced) in VOTE is not another release.


One complicating factor is that GitHub will list any tag as a
"Release": See for instance

https://github.com/apache/incubator-commonsrdf/releases

The tag "apache-import-20150327" was not a release, but is clearly a
good use-case for tagging - in fact I think every SG-imported code
should have such a tag (ideally with --sign).  So a -RC tag will be
listed as a "Release" on GitHub while it's under vote - I can see that
is not good. A workaround would be to use a branch instead - which is
more clearly a moving target.


Perhaps it's possible to enquire with INFRA if there are particular
tags that can be filtered out from the mirroring.


A deleted -RC tag disappears from the main GitHub repository - however
they might appear in forks - not a big deal to me - downstream forks
could also add arbitrary "release" tags in their forks if they so
like. The impact of this varies a bit with the popularity of the
project - something widely known like Groovy is more of risk of having
their Release Candidates sneak into production "out there". (which is
OK as long as they don't call it "Apache Groovy").

I think each project can (and should) decide this - we can list these
pros and cons in the recommendation.


Some projects (incubator and TLP) might have done a VOTE, and then
push out binary and source artifacts to say Maven Central without a
corresponding git tag or source release in dist. This is of course bad
practice - but not what we are talking about here.

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

Re: [DISCUSS] Olympian Incubation Proposal

[Stian Soiland-Reyes]

+1 as a red flag, but not a blocker.  For it to work, larger parts of the
existing contributors need to be convinced to join the Apache effort. There
are not license differences, so cross-pollination is possible.

Another concern is the name "Olympian", the International Olympic Committee
is well known for pursuing any use of their (real or perceived) trademarks.

On 29 Sep 2016 8:17 a.m., "toki"  wrote:

> On 29/09/2016 04:01, Henry Saputra wrote:
> > The project will be forked off the existing Titan code base.
>
> That is a red flag.
>
> jonathon
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Ease of release process and exit criteria

[Stian Soiland-Reyes]

Agreed, it is also a good way to "integration test" the documented release
process to have at least 2 release managers have a go.

If there are no emails on a podling list with questions on how to do a
release, then that hints of potential hidden knowledge, which as we see is
critical for future health of the project.

On 24 Aug 2016 4:19 a.m., "Roman Shaposhnik"  wrote:

> On Tue, Aug 23, 2016 at 2:02 PM, Ted Dunning 
> wrote:
> > I wonder if the requirement might be better phrased along the lines of
> > "must have releases completed by a total of > 2 release managers".
>
> I really like this criteria and use it extensively with my podlings.
>
> Thanks,
> Roman.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Accept NetBeans into the Apache Incubator

[Stian Soiland-Reyes]

+1 (non-binding)

Great committer list! Don't worry if you don't get all the ICLAs signed
right away :-)

On 27 Sep 2016 9:30 p.m., "Ate Douma"  wrote:

> Hi everyone,
>
> Now that the discussion thread on the NetBeans Proposal has ended,
> please vote on accepting NetBeans into the Apache Incubator.
>
> The ASF voting rules are described at:
>http://www.apache.org/foundation/voting.html
>
> A vote for accepting a new Apache Incubator podling is a majority vote
> for which only Incubator PMC member votes are binding.
>
> Votes from other people are also welcome as an indication of peoples
> enthusiasm (or lack thereof).
>
> Please do not use this VOTE thread for discussions.
> If needed, start a new thread instead.
>
> This vote will run for at least 72 hours. Please VOTE as follows
> [] +1 Accept NetBeans into the Apache Incubator
> [] +0 Abstain.
> [] -1 Do not accept NetBeans into the Apache Incubator because ...
>
>
> The proposal is listed below, but you can also access it on the wiki:
>https://wiki.apache.org/incubator/NetBeansProposal
>
>
> Thanks,
> Ate.
>
> == Abstract ==
>
> NetBeans is an open source development environment, tooling platform, and
> application framework, used by 1.5 million individuals each month.
>
> == Proposal ==
> Apache NetBeans will continue to focus on the areas it has focused on while
> sponsored by Sun Microsystems and Oracle. It will continue to primarily
> focus on
> providing tools for the Java ecosystem, while also being focused on tools
> for
> other ecosystems, languages and technologies, such as JavaScript, PHP, and
> C/C++. It will continue to actively support its community by means of
> mailing
> lists, tutorials, and documentation.
>
> == Background ==
> NetBeans started in 1995/96 in Prague, in the Czech Republic, as a student
> project. Sun Microsystems acquired and open sourced it in 2000 and, with
> the
> acquisition of Sun Microsystems by Oracle in 2010, became part of Oracle.
> Throughout its history in Sun Microsystems and Oracle, NetBeans has been
> free
> and open source and has been leveraged by its sponsor as a mechanism for
> driving
> the Java ecosystem forward.
>
> == Rationale ==
> Although NetBeans is already open source, moving it to a neutral place like
> Apache, with its strong governance model, is expected to help get more
> contributions from various organizations. For example, large companies are
> using
> NetBeans as an application framework to build internal or commercial
> applications and are much more likely to contribute to it once it moves to
> neutral Apache ground. At the same time, though Oracle will relinquish its
> control over NetBeans, individual contributors from Oracle are expected to
> continue contributing to NetBeans after it has been contributed to Apache,
> together with individual contributors from other organizations, as well as
> self-employed individual contributors.
>
> == Initial Goals ==
> The initial goals of the NetBeans contribution under the Apache umbrella
> are to
> establish a new home for an already fully functioning project and to open
> up the
> governance model so as to simplify and streamline contributions from the
> community.
>
> == Current Status ==
> Meritocracy: NetBeans has been run by Oracle, with the majority of code
> contributions coming from Oracle. The specific reason for moving to Apache
> is to
> expand the diversity of contributors and to increase the level of
> meritocracy in
> NetBeans. Apache NetBeans will be actively seeking new contributors and
> will
> welcome them warmly and provide a friendly and productive environment for
> purposes of providing a development environment, tooling environment, and
> application framework.
>
> Community: NetBeans has approximately 1.5 million active users around
> the
> world, in extremely diverse structures and organizations. NetBeans is used
> by
> teachers and instructors at schools and universities to teach Java and
> other
> languages. It is used by students as an educational tool. It is used by
> large
> organizations who base their software on the application framework beneath
> NetBeans. It is used by web developers for creating web sites and by
> developers
> using a range of tools, languages, and technologies to be productive and
> efficient software developers.
>
> Core Developers: The core developers will come from a range of
> organizations, including Oracle, which will continue its investment in
> NetBeans.
>
> Alignment: The application framework is the basis of a range of mission
> critical scientific software at large organizations in defense, aerospace,
> logistics, and research, such as at Boeing, Airbus Defense and Space,
> NASA, and
> NATO.
>
> == Known Risks ==
> Orphaned Products: The community proposing NetBeans for incubation is
> strong
> and vibrant. The size and diversity of the community is a guarantee
> against the
> project being orphaned.
>
> Inexperience with Open Source: NetBeans

Re: Radical proposal: no initial list of committers

[Stian Soiland-Reyes]

It's a radical proposal - but I think it would only work well where
the champion/mentors are also from same community - e.g. the kind of
"Already lots of Apache folks" projects that we previously suggested
for the straight-to-PLP mode. There's also the danger of the project
to seem hostile to non-Apache folks - and if the project has not
already have a well-working contributor model; then activity will die
out as it would have almost no committers.

But choreographed well by the mentors - who would then have to be
almost like a "project coach" - it could turn to a very open model as
everyone on the list would feel they have a large say of project
decisions. Some open source projects work well like this on GitHub
today - with a very small set of people using commit rights and all
activity done through pull requests.

Perhaps the radical mini-PMC model could be good for those - working
out who "is" and "isn't"  a committer in ASF sense can be tricky for
such projects - as you would have to go through all the discussions on
all pull requests - code review and "helping" in design decisions is
also part of being a committer!


Just to note - one advantage of the "emeritus committers allowed" for
a long-standing community (e.g. Netbeans - although I think we're
happy with Netbeans proposal now!) is that those people will carry
with them history and opinions - and could still work well with the
PMC hat on even if they don't commit a single line of code - acting
almost like an Advisory Board for the project.

Another is that moving to Apache is not required to be a hard-reset -
so just as Apache projects don't tend to vote out dormant committers
(but they might voluntarily retire) - so if a long-running project
moves to ASF it should not have to 'shed' committers.

On 27 September 2016 at 16:43, Julian Hyde  wrote:
> +0.5 I like this idea a lot (but there are governance problems to be solved).
>
> I have long been frustrated at folks who jump on the bandwagon and become 
> initial committers then play no further part in the project.
>
> Do inactive committers harm the project? No, of course they don’t. But it 
> isn’t fair to those who get in by pulling their weight.
>
> Now, those inactive committers should be removed when the project graduates, 
> right? No, in my experience they get to be PMC members. The project is too 
> polite to throw people out (especially what they perceive as “Apache VIPs”).
>
> And while I’m on that topic: I believe that mentors should not automatically 
> become PMC members when the project graduates.
>
> Julian
>
>
>> On Sep 27, 2016, at 4:25 AM, Greg Stein  wrote:
>>
>> The NetBeans proposal (among many others in the past) has demonstrated a
>> significant "problem" with trying to establish an appropriate list of
>> initial committers. There are many people that want to be on, for various
>> reasons. Because they are committers, recent or historic. Or they want the
>> "prestige" to be there. Some people believe they "deserve" to be on the
>> list. etc etc
>>
>> Establishing the list is particularly difficult for large and old
>> communities.
>>
>> But. What if we just said "no such list" ?
>>
>> This will shift the initial voting of committers upon the Champion/Mentors
>> who will construct the entirety of the PPMC. But hey: aren't they supposed
>> to be involved? Aren't they supposed to demonstrate how to earn merit, and
>> the committership that results?
>>
>> This would also solve the problem of initial committers that have not
>> established any merit whatsoever. We've had many situations where people
>> simply add themselves to the list. Why? Cuz they chose to do so. It is sort
>> of silently allowed for IPMC members to add themselves. "I wanna join!"
>> BAM. It happens.
>>
>> So yeah. Radical thought: NO initial list. The PPMC is just the Champion +
>> Mentors. They will build the committers and PPMC according to merit. (note:
>> this could be *very* fast for a particular few highly-engaged with bringing
>> the project to the ASF)
>>
>> ???
>>
>> Cheers,
>> -g
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [VOTE] Apache BatchEE 0.4-incubating

[Stian Soiland-Reyes]

OpenJDK 1.8.0 from Ubuntu 16.04.
Java version: 1.8.0_91, vendor: Oracle Corporation

It seems it was a threading issue as I was using the optimistic -T1.0C
- which of course is not required to work. My fault!

The build works now (but of course takes a bit longer :).

[INFO] BUILD SUCCESS

My vote changed to +1 (non-binding) -  if you carry over your three
IPMC-binding votes you should be good to go.


On 27 September 2016 at 11:27, Mark Struberg  wrote:
> That's weird. Which Java version do you exactly use?
> I did run the full build with java7 and it passed perfectly fine.
>
>
> LieGrue,
> strub
>
>
> On Tuesday, 27 September 2016, 12:24, Stian Soiland-Reyes  
> wrote:
>>-0 (non-binding)  -- changes my previous -1 vote after dist/ was populated.
>>
>>I'm afraid it's not positive vote from me as the unit tests were
>>failing the build, otherwise I would say +1. But feel free to ignore
>>this vote :)
>>
>>
>>-1 .md5 .sha1 missing from dist
>>+1 valid .asc signature
>>-1 KEYS file missing
>>+1 dist matches mvn (same sha1 of batchee-0.4-incubating-source-release.zip)
>>+1 LICENSE
>>+0 NOTICE:  should say "Apache Batchee" instead of "Batchee".
>>Copyright should be 2013-2016 (or so), not just 2016.
>>-0 DISCLAIMER present - but it says "Apache Sirona" instead of "Apache
>>BatchEE" (already fixed in git)
>>+1 no binaries in source archive
>>+1 mvn apache-rat:check (but jbatch/.../jaxb/* don't have ASF headers)
>>-1 mvn clean install fails
>>+1 source kind of match git commit
>>985047e8cefb46056fcb0bda36af096a0d228fa2 (except LICENSE, NOTICE,
>>.gitignore, DEPENDENCIES)
>>-0 git tag missing LICENSE, NOTICE (already fixed in git master)
>>
>>
>>I would recommend for the JAXB generated files to use the
>>maven-jaxb-plugin from src/main/xsd so that the generated files end up
>>in target/generated-sources instead of being checked in.  If they have
>>to stay (e.g. because they have been modified post generation (uh
>>oh..)) then they should have the ASF header as they are derived from
>>the ASF-licensed xsds.
>>
>>
>>Build failure:
>>
>>[INFO] BatchEE :: GUI :: JAXRS :: Server .. FAILURE [ 19.111 
>>s]
>>
>>Tests run: 9, Failures: 1, Errors: 8, Skipped: 0, Time elapsed: 3.912
>>sec <<< FAILURE! - in org.apache.batchee.jaxrs.server.RestTest
>>getRunningExecutions(org.apache.batchee.jaxrs.server.RestTest)  Time
>>elapsed: 0.772 sec  <<< FAILURE!
>>java.lang.AssertionError: expected:<500> but was:<404>
>>at org.junit.Assert.fail(Assert.java:88)
>>at org.junit.Assert.failNotEquals(Assert.java:834)
>>at org.junit.Assert.assertEquals(Assert.java:645)
>>at org.junit.Assert.assertEquals(Assert.java:631)
>>at 
>>org.apache.batchee.jaxrs.server.RestTest.getRunningExecutions(RestTest.java:82)
>>
>>
>>and then loads of these:
>>
>>getJobExecution(org.apache.batchee.jaxrs.server.RestTest)  Time
>>elapsed: 0.079 sec  <<< ERROR!
>>org.apache.cxf.jaxrs.client.ServerWebApplicationException:
>>Apache Tomcat/7.0.50 - Error
>>report<!--H1
>>{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
>>H2 
>>{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}
>>H3 
>>{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}
>>BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;}
>>B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;}
>>P 
>>{font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A
>>{color : black;}A.name {color : black;}HR {color :
>>#525D76;}--> HTTP Status 404 -
>>/batchee-gui/api/batchee/job-execution/0>noshade="noshade">type Status reportmessage
>>/batchee-gui/api/batchee/job-execution/0description
>>The requested resource is not available.>noshade="noshade">Apache Tomcat/7.0.50
>>at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:791)
>>at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:749)
>>at org.apache.cxf.jaxrs.client.WebClient.invoke(WebClient.java:365)
>>at org.apache.cxf.jaxrs.client.WebClient.get(WebClient.java:501)
>>at org.apache.batchee.jaxrs.server.RestTest.getJobExecution(RestTest.java:117)
>>
>>
>>
>>For reference:
>>
>>stain@biggiebuntu:~/src/batchee/dist/0.4-incubating$ sha1sum
>>batchee-0.4-incubating-source-release.zi

Re: [VOTE] Apache BatchEE 0.4-incubating

[Stian Soiland-Reyes]

se/tomee/KEYS)
>
> Please VOTE
> [+1] yep
> [+0] don’t care
> [-1] no cause [...]
>
> The VOTE is open for 72h or as needed
>
> Thanks,
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [VOTE] Apache BatchEE 0.4-incubating

[Stian Soiland-Reyes]

I think it's sufficient if you push to dist for the 0.4 release under
vote here.

If you want to add the older versions to archive.apache.org then you
can add them to dist and then remove them again after 24h.


On 26 September 2016 at 16:52, Romain Manni-Bucau  wrote:
> Think you lost me a bit :s
>
> so here where we started the fork from:
> http://apache-incubator-general.996316.n3.nabble.com/Re-DISCUSS-jbatch-impl-Apache-td36529.html
>
> About dist: should i push it there now or is that a todo for next release?
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2016-09-26 17:48 GMT+02:00 Stian Soiland-Reyes :
>
>> I didn't want to start a git tag best practices war :)
>>
>> I think we agree that as long as a commit ID is in the email, and/or
>> the hash of the source distribution, then we know what we're voting on
>> and their location is not so important.  If you want to skip those,
>> then my opinion is that the release candidate must be on a
>> *.apache.org server - ideally with some kind of log.
>>
>>
>> I am flagging it mainly as I got a bit concerned when adding up
>> several issues around Batchee releases - it should be easy to fix with
>> a few svn commands on https://dist.apache.org/repos/dist/.
>>
>> The older Batchee releases are already voted over - although without
>> checksums in the email - but this is the incubator so I guess they can
>> just be dug out from
>> https://repository.apache.org/content/repositories/releases/
>> org/apache/batchee/batchee/
>> (ode Archaeologists go check those git tags!)
>>
>>
>>
>>
>> On 26 September 2016 at 16:22, Mark Struberg  wrote:
>> > Stian, this is established practice in the ASF since the very early days
>> of playing with GIT.
>> > It is used e.g. in the following TLPs:
>> > TomEE
>> > DeltaSpike
>> > Johnzon
>> > CouchDB
>> > Maven
>> > and many, many more!
>> >
>> >
>> > It also got discussed on members, infra and even board lists.
>> >
>> > The nice thing about GIT is that it absolutely doesn't matter where I
>> push the commit to as long as the sha1 of the commit later pushed to the
>> ASF repo is the same.
>> >
>> >
>> > Regarding 'pushing something different'. I trust an ASF member that he
>> doesn't do that. Plus we have the sha as explained before.
>> > Regarding 'not getting pushed at all': This would get catched pretty
>> quickly as we would miss the version update ;)
>> >
>> >
>> > Also bear in mind that ASF projects do NOT vote on the tags nor branches
>> - we solely vote on the release source distributable!
>> >
>> >
>> >
>> >> branches are there to be created and removed again
>> > Branches in GIT _cannot_ get removed from any downstream repo!
>> >
>> > That's the whole point. And if you do RCs, then you actually would have
>> to later do a NEW vote again with the 'RC' removed from the version. But
>> who guarantees that the source tarball is the same now? What if someone
>> changed the source in the meantime? You see, it also has flaws.
>> >
>> >> Perhaps "git tag --sign" so you get a PGP-signed tag commit
>> >
>> >> would be a good idea?
>> >
>> > Agree, would be a good idea!
>> > It happens that I wrote the Maven GIT integration somewhen in the
>> 2000s... ;)
>> >
>> > We don't have the tagging feature yet. Could you please file a ticket
>> against Maven SCM?
>> >
>> >
>> > txs and LieGrue,
>> > strub
>> >
>> >
>> >
>> >
>> >> On Monday, 26 September 2016, 16:34, Stian Soiland-Reyes <
>> st...@apache.org> wrote:
>> >> > On 26 September 2016 at 14:34, Mark Struberg
>> 
>> >> wrote:
>> >>>  We *never* push commits for in-progress votes to hte ASF repos when
>> we use
>> >> GIT!
>> >>>  The reason is that we cannot get rid of those afterwards! Of course
>> we can
>> >> delete the branch/tag/commit fro

Re: [VOTE] Apache BatchEE 0.4-incubating

[Stian Soiland-Reyes]

On 26 September 2016 at 16:45, Mark Struberg  wrote:
> Again the question is not about our own repo. The problem are the dozen 
> downstream repos. You cannot delete it from there once it got pulled 
> downstream. Or is there now a way to prevent downstream replication? How does 
> that work?

Just a thought .. you can push to other refs/ than heads/ and tags/


stain@biggiebuntu:~/src/taverna/incubator-taverna-maven-parent$ git
push origin 
f9e049adc3cc079b9efedbbea9cefcaa2ae85c7b:refs/tmp/3-incubating-SNAPSHOT

https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-maven-parent.git;a=shortlog;h=refs/tmp/3-incubating-SNAPSHOT

does not seem to be show on
https://github.com/apache/incubator-taverna-maven-parent as a branch
or tag

but exists as a commit:

https://github.com/apache/incubator-taverna-maven-parent/commit/f9e049adc3cc079b9efedbbea9cefcaa2ae85c7b


bug or feature?

I don't think it's too usable, as you have to do git fetch origin
refs/tmp/3-incubating-SNAPSHOT -- and you would also fight with Maven
release plugin to do so.. But it's not all black and white. :)


-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [VOTE] Apache BatchEE 0.4-incubating

[Stian Soiland-Reyes]

I didn't want to start a git tag best practices war :)

I think we agree that as long as a commit ID is in the email, and/or
the hash of the source distribution, then we know what we're voting on
and their location is not so important.  If you want to skip those,
then my opinion is that the release candidate must be on a
*.apache.org server - ideally with some kind of log.


I am flagging it mainly as I got a bit concerned when adding up
several issues around Batchee releases - it should be easy to fix with
a few svn commands on https://dist.apache.org/repos/dist/.

The older Batchee releases are already voted over - although without
checksums in the email - but this is the incubator so I guess they can
just be dug out from
https://repository.apache.org/content/repositories/releases/org/apache/batchee/batchee/
(ode Archaeologists go check those git tags!)




On 26 September 2016 at 16:22, Mark Struberg  wrote:
> Stian, this is established practice in the ASF since the very early days of 
> playing with GIT.
> It is used e.g. in the following TLPs:
> TomEE
> DeltaSpike
> Johnzon
> CouchDB
> Maven
> and many, many more!
>
>
> It also got discussed on members, infra and even board lists.
>
> The nice thing about GIT is that it absolutely doesn't matter where I push 
> the commit to as long as the sha1 of the commit later pushed to the ASF repo 
> is the same.
>
>
> Regarding 'pushing something different'. I trust an ASF member that he 
> doesn't do that. Plus we have the sha as explained before.
> Regarding 'not getting pushed at all': This would get catched pretty quickly 
> as we would miss the version update ;)
>
>
> Also bear in mind that ASF projects do NOT vote on the tags nor branches - we 
> solely vote on the release source distributable!
>
>
>
>> branches are there to be created and removed again
> Branches in GIT _cannot_ get removed from any downstream repo!
>
> That's the whole point. And if you do RCs, then you actually would have to 
> later do a NEW vote again with the 'RC' removed from the version. But who 
> guarantees that the source tarball is the same now? What if someone changed 
> the source in the meantime? You see, it also has flaws.
>
>> Perhaps "git tag --sign" so you get a PGP-signed tag commit
>
>> would be a good idea?
>
> Agree, would be a good idea!
> It happens that I wrote the Maven GIT integration somewhen in the 2000s... ;)
>
> We don't have the tagging feature yet. Could you please file a ticket against 
> Maven SCM?
>
>
> txs and LieGrue,
> strub
>
>
>
>
>> On Monday, 26 September 2016, 16:34, Stian Soiland-Reyes  
>> wrote:
>> > On 26 September 2016 at 14:34, Mark Struberg 
>> wrote:
>>>  We *never* push commits for in-progress votes to hte ASF repos when we use
>> GIT!
>>>  The reason is that we cannot get rid of those afterwards! Of course we can
>> delete the branch/tag/commit from the ASF repo, but we cannot delete them 
>> from
>> all the hundreds downstream repos which almost immediately pull those 
>> changes...
>>>
>>>  You can think of pushing this to a private (but PMC owned!) github repo as
>> kind of parallel to the Maven 'staging'  process.
>>
>> Of course it is up to each project what particular release/tag
>> practice they want to follow. Many projects do this classically even
>> with git, e.g. using branches or tags like 0.4-RC1 - see for instance:
>>
>> https://lists.apache.org/list.html?d...@jena.apache.org:lte=10M:VOTE
>>
>> Some communities like Apache Commons even keep around all RC tags;
>> then archived emails around failed RCs still have valid links - e.g.
>> https://github.com/apache/commons-lang/releases
>>
>> I wouldn't personally see a problem with a RC branch showing up in
>> forked repositories - branches are there to be created and removed
>> again - if downstream want to keep them for archival purposes that's
>> their choice - just like they can keep the commit emails.
>>
>>
>> But if that's not your project's cup of tea, then I guess just a
>> commit IDs and hashes in the email should work, no matter where the
>> commit 'is' - in git the commit is hashed and it's not forgotten
>> after
>> the vote is passed.
>>
>> Perhaps "git tag --sign" so you get a PGP-signed tag commit would be a
>> good idea?
>>
>>
>> Without the commit ID or hashes in the email - then particularly for
>> mutable release candidates tags hosted in third-party repositories, we
>> don't have a rec

Re: [VOTE] Apache BatchEE 0.4-incubating

[Stian Soiland-Reyes]

I am a bit concerned about BatchEE's release procedure.

Your vote refers to a KEYS file from a different project (tomee)

This would be the fourth BatchEE incubator release - so I'm expecting
to find a batchee 0.1-incubating, 0.2-incubating and 0.3-incubating
somewhere.


Where are the source code downloads?

http://batchee.incubator.apache.org/modules.html only describes Maven
coordinates.

https://dist.apache.org/repos/dist/release/incubator/ does not contain batchee
https://dist.apache.org/repos/dist/dev/incubator/ does not contain batchee
https://dist.apache.org/repos/dist/release/tomee/ does not contain
batchee (had to check! :)


Yet https://dist.apache.org/repos/dist/release/tomee/ contains various
binary artifacts.

http://central.maven.org/maven2/org/apache/batchee/batchee/ seems to
have some source releases.



The ASF Release Policy is quite clear on this:

http://www.apache.org/dev/release.html#where-do-releases-go

On 26 September 2016 at 07:28, Romain Manni-Bucau  wrote:
> Hi guys,
>
> batchee community voted the 0.4-incubating good to release, here is the
> time for general@ to vote on it as well
>
> dev@ result:
> http://mail-archives.apache.org/mod_mbox/batchee-dev/201609.mbox/browser
>
> Here is the release note: https://issues.apache.org/jira/secure/ReleaseNote.
> jspa?projectId=12314924&version=12334147
>
> Staging repo: https://repository.apache.org/content/repositories/
> orgapachebatchee-1004/ (yes numbers are funny sometimes ;))
>
> Source zip: https://repository.apache.org/content/repositories/
> orgapachebatchee-1004/org/apache/batchee/batchee/0.4-incubating/batchee-0.4-
> incubating-source-release.zip
>
> Tag: https://github.com/rmannibucau/incubator-batchee/
> tree/batchee-0.4-incubating
>
> My gpg key is in tomee KEYS file (https://dist.apache.org/
> repos/dist/release/tomee/KEYS)
>
> Please VOTE
> [+1] yep
> [+0] don’t care
> [-1] no cause [...]
>
> The VOTE is open for 72h or as needed
>
> Thanks,
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [VOTE] Apache BatchEE 0.4-incubating

[Stian Soiland-Reyes]

On 26 September 2016 at 14:34, Mark Struberg  wrote:
> We *never* push commits for in-progress votes to hte ASF repos when we use 
> GIT!
> The reason is that we cannot get rid of those afterwards! Of course we can 
> delete the branch/tag/commit from the ASF repo, but we cannot delete them 
> from all the hundreds downstream repos which almost immediately pull those 
> changes...
>
> You can think of pushing this to a private (but PMC owned!) github repo as 
> kind of parallel to the Maven 'staging'  process.

Of course it is up to each project what particular release/tag
practice they want to follow. Many projects do this classically even
with git, e.g. using branches or tags like 0.4-RC1 - see for instance:

https://lists.apache.org/list.html?d...@jena.apache.org:lte=10M:VOTE

Some communities like Apache Commons even keep around all RC tags;
then archived emails around failed RCs still have valid links - e.g.
https://github.com/apache/commons-lang/releases

I wouldn't personally see a problem with a RC branch showing up in
forked repositories - branches are there to be created and removed
again - if downstream want to keep them for archival purposes that's
their choice - just like they can keep the commit emails.


But if that's not your project's cup of tea, then I guess just a
commit IDs and hashes in the email should work, no matter where the
commit 'is' - in git the commit is hashed and it's not forgotten after
the vote is passed.

Perhaps "git tag --sign" so you get a PGP-signed tag commit would be a
good idea?


Without the commit ID or hashes in the email - then particularly for
mutable release candidates tags hosted in third-party repositories, we
don't have a record over exactly what was voted on and the commiter
could easily by mistake push the 'wrong' RC commits or dists without
anyone being able to notice or check later. In fact, this very vote
shows two different commit IDs which this time luckily had the same
content.

Many projects posts RCs on https://dist.apache.org/repos/dist/dev/ -
which is SVN-based - here the revision number and log is sufficient -
we assume the ASF-hosted SVN repository to be 'trusted'. A closed
Nexus repository is similarly tracked and immutable.




-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [VOTE] Apache BatchEE 0.4-incubating

[Stian Soiland-Reyes]

On 26 September 2016 at 07:28, Romain Manni-Bucau  wrote:
> Hi guys,
>
> batchee community voted the 0.4-incubating good to release, here is the
> time for general@ to vote on it as well

-1 (non-binding)

Your vote email didn't include any hashes or commit IDs - please
provide these those next time.


> Tag: https://github.com/rmannibucau/incubator-batchee/
> tree/batchee-0.4-incubating

I would appreciate if the tag under voting was not under a personal
GitHub account.

Your suggested tag is of commit
985047e8cefb46056fcb0bda36af096a0d228fa2, which is not on
git.apache.org

https://git-wip-us.apache.org/repos/asf?p=incubator-batchee.git;a=commit;h=985047e8cefb46056fcb0bda36af096a0d228fa2


However I find an alternative commit:
https://git-wip-us.apache.org/repos/asf?p=incubator-batchee.git;a=commit;h=0dabf849ce59fa26d4dbde301335b74e5715ca2f


I didn't investigate further if the commits are content-wise different or not.


Note that it is not a strict ASF requirement that there is a matching
tag (the vote is on the source archive) - but personally I can't
support a release without commits/tag in the official repository.


-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [VOTE] Release SAMOA 0.4.0 (incubating) RC1

[Stian Soiland-Reyes]

My vote: 0 (non-binding)

+1 tag/commit
+1 git vs source zip
+1 No binaries
0 mvn install fails in test
0 Apache rat is not happy
0 dist includes a  _remote.repositories file - this should be removed
+1 LICENSE DISCLAIMER NOTICE

I'm afraid it's not a positive vote from me because the build fails in
test - and the README told me to do "mvn package" (A workaround here
could be to use -DskipTests=true - but I don't know why the test
fails)


Apache rat complains about:
 !? CONTRIBUTING.md
 !? .travis.yml
 !? bin/samza-kryo

These should be added to pom.xml's apache-rat configuration to be
ignored. None of them are worthy of a license header I think.


Your vote email didn't say the hash of the source distro, it is (sha1)
cab5ace6bfff3b70f883db61578fbda847f0fd66
samoa-0.4.0-incubating-source-release.zip

(which matches *.sha1 on dist)





Tests run: 7, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.411
sec <<< FAILURE! - in
org.apache.samoa.topology.impl.SimpleEntranceProcessingItemTest
testStartSendingEvents(org.apache.samoa.topology.impl.SimpleEntranceProcessingItemTest)
 Time elapsed: 0.313 sec  <<< ERROR!
java.lang.IllegalStateException: Missing invocation to mocked type at
this point; please make sure there is an associated mock field or mock
parameter in scope
at 
org.apache.samoa.topology.impl.SimpleEntranceProcessingItemTest$4.(SimpleEntranceProcessingItemTest.java:159)
at 
org.apache.samoa.topology.impl.SimpleEntranceProcessingItemTest.testStartSendingEvents(SimpleEntranceProcessingItemTest.java:155)

[INFO] Apache SAMOA ... SUCCESS [  4.748 s]
[INFO] samoa-instances  SUCCESS [  3.676 s]
[INFO] samoa-api .. SUCCESS [ 22.050 s]
[INFO] samoa-test . SUCCESS [  2.149 s]
[INFO] samoa-local  FAILURE [ 49.418 s]

using

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T16:41:47+00:00)
Maven home: /home/stain/software/maven
Java version: 1.8.0_91, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-38-generic", arch: "amd64", family: "unix"

On 19 September 2016 at 14:50, Nicolas Kourtellis  wrote:
> Hi all,
>
> Our new release has been voted from the Apache SAMOA team and we are
> opening the vote to the incubator email list for testing.
>
> Please vote on releasing the following release candidate as Apache
> SAMOA (incubating)
> version 0.4.0. This release will be the second release for SAMOA in the
> incubator.
>
> -
> The commit to be voted on is in the branch "releases/0.4.0-incubating"
> (commit fc39238dd7d3674c069a8142312da8c1812bc907):
> https://git1-us-west.apache.org/repos/asf/incubator-samoa/
> repo?p=incubator-samoa.git;a=commit;h=fc39238dd7d3674c069a8142312da8
> c1812bc907
>
> Tag v0.4.0-incubating:
> https://git1-us-west.apache.org/repos/asf/incubator-samoa/
> repo?p=incubator-samoa.git;a=tag;h=aa5bd941ccbed1aabb46b8119049ac1bb293c3a2
>
> Release artifacts are signed with the following key:
> *https://people.apache.org/keys/committer/nkourtellis.asc
> <https://people.apache.org/keys/committer/nkourtellis.asc>*
>
> The staging repository for this release can be found at:
> https://repository.apache.org/content/repositories/staging/
> org/apache/samoa/samoa/0.4.0-incubating/
>
> The developer's version artifacts:
> https://dist.apache.org/repos/dist/dev/incubator/samoa/0.4.0-incubating-rc1/
>
> -
>
> Please vote on releasing this package as Apache SAMOA 0.4.0 (incubating).
>
> The vote is open for the next 72 hours and passes if a majority of at least
> three +1 PPMC votes are cast.
>
> [ ] +1 Release this package as Apache SAMOA 0.4.0 (incubating)
> [ ] -1 Do not release this package because ...
>
> I'm +1 on the release.
>
> Cheers,
>
> Nicolas
>
>
>
> --
> Nicolas Kourtellis



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [discuss] Move podling rosters to LDAP

[Stian Soiland-Reyes]

Does means podlings will also need to define both a $podling and
$podling-pmc group?

Many podlings don't have a clear distinction - at least not in listings.
Perhaps they should..

On 22 Sep 2016 3:17 a.m., "Sam Ruby"  wrote:

> cc += gstein
>
> On Wed, Sep 21, 2016 at 9:55 PM, Stian Soiland-Reyes 
> wrote:
> > Did this conclude..? Just in case it didn't, here's my +1 as well to
> > make podling membership be in proper LDAP groups; with email
> > notifications to private@podling as you mention.
>
> This did not conclude, but you picked an opportune time to resurrect
> this thread with Greg joining the infrastructure team.  In fact, I was
> planning to restart this thread for exactly that reason; thank you for
> doing it.
>
> My assessment previously was that there wasn't enough demand at the
> time to overcome inertia.  This change will undoubtedly break things
> temporarily, but nothing that can't be fixed quickly.
>
> > (I am lucky enough to have faced the asf-authorization-template a
> > couple of times :) )
>
> Join the club. :-)  The current process sucks, doesn't it.  :-)
>
> > Ensuring people.apache.org is updated would also make it easier for
> > podlings to refer to a canonical list of who are their members; which
> > would work somewhat the same way after graduating.
>
> That's part of the discussion I would like to have.  I'm proposing
> that members of the podling can update the group.  Currently only PMC
> chairs can modify PMCs.  And furthermore, PMC chairs can modify *any*
> PMC, not just the one(s) they chair.
>
> I'd like to change this so that PMC members can modify their own
> group.  And I believe that the increased notifications that this tool
> will provide will enable proper oversight.
>
> I also believe this to be fully in line with the President's (Ross's)
> desire to enable self-service.
>
> But a change of this magnitude to the way that we operate is something
> that requires a critical mass of support.  Thanks for lending your
> voice to this discussion.
>
> > Letting podling members modify the group themselves is good (as you
> > said the worst they can do is add another committer), as long as we'll
> > keep the account creation process under the hands of ASF Members (as
> > it is now).
>
> ASF members and officers.
>
> By the way, if you ever want to submit an account request, you might
> want to try https://whimsy.apache.org/officers/acreq/; it loads much
> faster than https://id.apache.org/acreq/; if you like it, spread the
> word.
>
> - Sam Ruby
>
> > On 2 September 2016 at 18:52, Sam Ruby  wrote:
> >> On Fri, Sep 2, 2016 at 12:49 PM, John D. Ament 
> wrote:
> >>> On Fri, Sep 2, 2016 at 12:42 PM Sam Ruby 
> wrote:
> >>>
> >>>> The first stage would be migrating existing lists to LDAP.  This will
> >>>> require some small changes to whimsy and the phone book application.
> >>>> The whole effort will only take a few hours and be spread over a few
> >>>> days elapsed time.
> >>>>
> >>>> To prepare, we will need to decide who gets to modify these lists, and
> >>>> who gets notified.  I propose that members of podlings be able to
> modify
> >>>> the list, and the private list associated with that podling be
> notified
> >>>> on changes.  Alternate choices would include mentors for the podling,
> or
> >>>> the IPMC.  Given that notification facilitates oversight, I encourage
> >>>> this to be pushed down to the podling, but will go with whatever the
> >>>> consensus turns out to be.
> >>>
> >>> My vote would be for mentors to be able to do this.  The podlings don't
> >>> know enough yet to manage this on their own.  I would be concerned of
> >>> missed process steps if the podling themselves could do it.
> >>
> >> See Mark's comment, and my response to it.
> >>
> >>>> The second stage would be to define an interface for adding (and
> perhaps
> >>>> removing) podlings.  This could be limited to the IPMC and the web
> >>>> interface could ensure that it is only possible to create entries that
> >>>> are present in podlings.xml.
> >>>>
> >>>
> >>> Could this lead to the eventual removal of podlings.xml ?
> >>
> >> It could lead to where-ever the IPMC wants to go. :-)
> >>
> >> My preference is that the canonical definition be in SVN, git, LDAP or
> >>

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Stian Soiland-Reyes]

I'm very convinced :-)  I think the Netbeans proposal is ready for a [VOTE]!



On 22 September 2016 at 13:57, Wade Chandler  wrote:
>
>> On Sep 22, 2016, at 08:27, Shane Curcuru  wrote:
>>
>> Jochen Wiedmann wrote on 9/22/16 1:43 AM:
>>> On Thu, Sep 22, 2016 at 7:18 AM, Roman Shaposhnik  
>>> wrote:
>>>
>>>> Still, the question remain -- for somebody like that, what would be a 
>>>> criteria
>>>> to be added as a committer after the project enters incubation?
>>>
>>> Projects decision.
>>
>> Exactly so.  This would be a podling just like every other podling, and
>> the IPMC would expect the PPMC to start operating like an Apache
>> project.  That is, when new people come to the podling and contribute
>> work, and help the work of the podling, that after a time the PPMC will
>> discuss them, then vote them in as new committers.
>>
>> Past merit (i.e. past contributions) is a great help to a new
>> contributor to a project, both because it's easier to get started, and
>> because the community already has a feel for how they act and can help.
>> But it in no way IMO directly leads to current merit.  Old contributors
>> normally would be voted in as committers only once they actually start
>> doing new work on the project.
>
> Perhaps we need to clarify what you mean by “old contributor” … Do you mean 
> those currently contributing to the imported project, those who have 
> contributed at some time in the past, but not in X days/months, or anyone not 
> on the initial committer list? If the latter, then why would this be true for 
> a current OSS project coming to ASF? If this is exactly the case, then more 
> emphasis is put on the initial committer list IMO, and that seems an 
> unnecessary distraction, and an artificial limit, but if it must be that way 
> it must, and if not, then great, but please clarify.
>
> I ask this because I recently contributed some things for Groovy support, and 
> intend to work quite a bit on those features. I have contributed quite a bit 
> to the form (UI editor), J2EE, and Java SE modules in the past. I don’t want 
> to suddenly be hindered just because the project moves to the ASF where I 
> have to “start over”; I have invested quite a number of years into NetBeans 
> and it’s community.
>
>> On Sep 22, 2016, at 07:00, Stian Soiland-Reyes  wrote:
>>
>> Agree - but the initial committer list is also an opportunity to show
>> you really mean open development, and that it's not just business as
>> usual with Friends & Family on the list.
>>
>
> Understood, but the impression still has to be on the community all the rules 
> of merit apply regardless of perception. I have faith Gj and many I know on 
> that initial list will make sure anyone who has made solid code contributions 
> to NB, who also want to contribute in the ASF, will be fast tracked per prior 
> NB community decisions. We are operating off this assumption now; community 
> and Oracle included per my understanding.
>
>> One of the freedoms a project gains from moving to ASF is (somewhat)
>> relief from institutional political considerations.  A new intern at a
>> company would no longer just be given carte blance write access
>> without first engaging with the whole community and earning merit
>> through contributions. Of course each community decides how high or
>> low the bar should be to earn committership - but the bar should be
>> the same for anyone.
>>
> I 100% agree with this. I think it is definitely that the rules have to apply 
> to everyone equally including employees of a company including the donor. I 
> don’t imagine someone who falls outside categories of merit in the current NB 
> process now should suddenly be committers at ASF. Committers should be 
> committers. Those who were well on their way to earn committer status should 
> be considered, and it should be rare they are not promoted. Those not 
> committing code or submitting patches now, should start from the premise they 
> have to earn committer rights, and the project should enforce that as a 
> minimum; merit isn’t about free trophies or we’d all have doctorates or be in 
> the NFL or NBA :-D
>
>>
>> I found for several podlings that people (myself included) who were
>> perhaps dormant "contributors" before the Incubator 'woke up' after
>> being added as an equal peer on the initial list. The beginning of a
>> podling; while sometimes struggling a bit with bootstrapping, is also
>> a chance for a project to review many of its practices and to build
>> common ownership - reduce the "

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Stian Soiland-Reyes]

Agree - but the initial committer list is also an opportunity to show
you really mean open development, and that it's not just business as
usual with Friends & Family on the list.

One of the freedoms a project gains from moving to ASF is (somewhat)
relief from institutional political considerations.  A new intern at a
company would no longer just be given carte blance write access
without first engaging with the whole community and earning merit
through contributions. Of course each community decides how high or
low the bar should be to earn committership - but the bar should be
the same for anyone.


I found for several podlings that people (myself included) who were
perhaps dormant "contributors" before the Incubator 'woke up' after
being added as an equal peer on the initial list. The beginning of a
podling; while sometimes struggling a bit with bootstrapping, is also
a chance for a project to review many of its practices and to build
common ownership - reduce the "us and them" feeling.

I think Netbeans has the balance somewhat right - but I would hope
there would be more engagement on their existing lists to more openly
invite anyone who wants to join; or at least make it clear that the
whole of the community (read: mailing list) gets to influence project
decisions.

On 22 September 2016 at 09:48, Bertrand Delacretaz
 wrote:
> Hi Wade,
>
> On Wed, Sep 21, 2016 at 11:38 PM, Wade Chandler
>  wrote:
>> ..I can say as a long time contributor who is not on the initial list, I
>> understand, think it is fine, and agree that being added once we get into
>> the actual incubation phase makes sense...
>
> Thanks!
>
> As someone who has mentored several projects here in the last ten
> years or so I think although people sometimes see a lot of value in
> being on the initial committers list they should not, IMO.
>
> What very often happens during incubation is some people who were on
> this list almost never contribute to the project, and other expected
> or unexpected people show up, do great things and get elected as a
> result.
>
> Also, as mentor I will recommend reviewing the list of committers and
> PMC members shortly before graduation, to give the opportunity to
> people who didn't actually become active to gracefully retire - if the
> project governance works it's easy to come back later by becoming
> active, and the project benefits from having a roster that reflects
> the reality of active contributors.
>
> So in summary people shouldn't put too much value on the initial list
> of committers, it's just that - an initial list, a kind of draft that
> will evolve during incubation, and probably evolve a lot for a large
> project such as NetBeans.
>
>> ...I am able to contribute as much as I can at this stage anyways...
>
> Indeed, and that stays true once incubation starts. Even though an
> Apache PMC ultimately makes all the project decisions, they are
> expected to listen to their community. The "community" section at
> https://community.apache.org/apache-way/apache-project-maturity-model.html
> expresses that.
>
>> ...getting into building a thorough list before hand will
>> certainly take time away from higher priority items at this stage...
>
> Yes, that's why the NetBeans mentors pushed to avoid adding people to
> the list of initial committers before the incubation vote starts, as
> for a popular project that's a lot of work with no real value as
> mentioned above.
>
> Thanks for your understanding and for your contributions so far!
>
> -Bertrand, with my NetBeans mentor hat on
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [discuss] Move podling rosters to LDAP

[Stian Soiland-Reyes]

Did this conclude..? Just in case it didn't, here's my +1 as well to
make podling membership be in proper LDAP groups; with email
notifications to private@podling as you mention.

(I am lucky enough to have faced the asf-authorization-template a
couple of times :) )

Ensuring people.apache.org is updated would also make it easier for
podlings to refer to a canonical list of who are their members; which
would work somewhat the same way after graduating.


Letting podling members modify the group themselves is good (as you
said the worst they can do is add another committer), as long as we'll
keep the account creation process under the hands of ASF Members (as
it is now).


On 2 September 2016 at 18:52, Sam Ruby  wrote:
> On Fri, Sep 2, 2016 at 12:49 PM, John D. Ament  wrote:
>> On Fri, Sep 2, 2016 at 12:42 PM Sam Ruby  wrote:
>>
>>> The first stage would be migrating existing lists to LDAP.  This will
>>> require some small changes to whimsy and the phone book application.
>>> The whole effort will only take a few hours and be spread over a few
>>> days elapsed time.
>>>
>>> To prepare, we will need to decide who gets to modify these lists, and
>>> who gets notified.  I propose that members of podlings be able to modify
>>> the list, and the private list associated with that podling be notified
>>> on changes.  Alternate choices would include mentors for the podling, or
>>> the IPMC.  Given that notification facilitates oversight, I encourage
>>> this to be pushed down to the podling, but will go with whatever the
>>> consensus turns out to be.
>>
>> My vote would be for mentors to be able to do this.  The podlings don't
>> know enough yet to manage this on their own.  I would be concerned of
>> missed process steps if the podling themselves could do it.
>
> See Mark's comment, and my response to it.
>
>>> The second stage would be to define an interface for adding (and perhaps
>>> removing) podlings.  This could be limited to the IPMC and the web
>>> interface could ensure that it is only possible to create entries that
>>> are present in podlings.xml.
>>>
>>
>> Could this lead to the eventual removal of podlings.xml ?
>
> It could lead to where-ever the IPMC wants to go. :-)
>
> My preference is that the canonical definition be in SVN, git, LDAP or
> some such, and that tools like whimsy remain only a convenient
> mechanism to update these definitions.
>
>> Does any of this have a relationship to projects.apache.org ?
>
> At a minimum, both would derive information from a common source.
>
> My understanding is that the focus of projects.apache.org is to
> provide a public-facing and read-only interface to this data.
>
> The whimsy roster tool would provide an authenticated read-write
> interface to this data.  And a non-exclusive one.  Other tools could
> be written that update that information.
>
> - Sam Ruby
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: Licensing requirement for binary artifacts without transitive deps

[Stian Soiland-Reyes]

t;> > licenses of all transitive deps if the release contains:
>> >
>> > - a single source tarball;
>> > - a few binary JAR artifacts on Nexus that contain no transitive deps in
>> > either binary or source form.
>> >
>> > Would it be sufficient to make sure the licenses of all sources comply
>> > with Apache policy in this case? Do I need to check transitive deps in
>> this
>> > case?
>> >
>> > Thanks!
>> >
>> > Regards,
>> > Donald
>> >
>>



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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