Re: Planning to remove rosters from active podlings

[Niclas Hedhman]

Does that maintain history? Or will that then become a snapshot in "now"
time, and by time of graduation completely dropping mentors? IMHO, there
should be a record of community history over time, not only for podlings.

Niclas

On Tue, Sep 26, 2017 at 4:33 AM, John D. Ament <johndam...@apache.org>
wrote:

> All,
>
> This coming weekend (9/29) I plan to remove the roster sections from all
> podling status pages.
>
> Podling rosters are meant to be managed in Whimsy.  The roster in the
> status page is redundant and end up out of sync.  In place of the roster, I
> will be adding a link automatically to all podling rosters.
>
> John
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: [IP CLEARANCE] Apache Ignite - Persistent Store

[Niclas Hedhman]

Originally, the IP Clearance was intended for "block contributions" larger
than suitable for a Jira patch file, and from people outside the community.
For example, it could be code that was made at SourceForge and IP Clearance
was to make sure that the the OK/interest of the authors was recorded (via
ICLAs, IIRC).

In this case, it seems that the author is on the PM, have an ICLA on file,
the work is part of the same commit tree, so I see no reason for the ASF to
doubt that he had the permission from the company to commit/push.


Cheers
Niclas

On Mon, May 22, 2017 at 5:47 AM, Craig Russell <apache@gmail.com> wrote:

> Let's all read the documentation on IP Clearance so we have a common basis
> for discussion.
>
> Craig
>
> > On May 21, 2017, at 2:46 PM, Craig Russell <apache@gmail.com> wrote:
> >
> >>
> >> On May 21, 2017, at 2:02 PM, John D. Ament <johndam...@apache.org>
> wrote:
> >>
> >> On Sun, May 21, 2017 at 4:54 PM Craig Russell <apache@gmail.com>
> wrote:
> >>
> >>> Hi John,
> >>>
> >>> I don't know all of the details of the code, but this is in regard to
> >>> GridGain's grant via SGA of a persistent store system which is a
> >>> substantial body of code not developed at Apache. So IMHO it is
> appropriate
> >>> for the code grant to be reviewed.
> >>>
> >>>
> >> Errr... wait a tick.  We've been told a few times that IP Clearance and
> SGA
> >> are binary.  You do one or the other, not both.
> >
> > Reference, please. I recall that IP Clearance is for TLPs to vet large
> donations.
> >
> > Craig
> >
> >> Specifically SGA is to
> >> allow the modification of license (from X to Apache-V2.0) whereas IP
> >> Clearance is verifying that all existing Apache-v2.0 donation is in fact
> >> properly licensed (e.g. no hidden LGPL or other inappropriate licenses).
> >> There's even a line in the SGA that puts the ownness on this to the
> donator.
> >>
> >> If GridGain has submitted an SGA then that SGA is what is used.  Have
> they
> >> actually submitted an SGA as well?
> >>
> >>
> >>
> >>> I don't see any issues except it's difficult (for me, a git novice) to
> >>> figure out the exact donation. The reference is to a git repository
> that is
> >>> "194 commits ahead, 240 commits behind apache:master". Most of the
> donated
> >>> code is in “modules/pds”.
> >>>
> >>> Craig
> >>>
> >>>> On May 20, 2017, at 8:53 PM, John D. Ament <johndam...@apache.org>
> >>> wrote:
> >>>>
> >>>> The commit referenced in the IP clearance reflects some changes in a
> pom
> >>>> file.  Is that the only change?
> >>>>
> >>>> In addition, the commit seems to be from Alexey Goncharuk, who is
> >>> already a
> >>>> committer from the foundation (has an ICLA) and is on the PMC for
> >>> ignite...
> >>>> so its not clear why an IP Clearance is needed.
> >>>>
> >>>> John
> >>>>
> >>>> On Sat, May 20, 2017 at 11:42 PM Denis Magda <dma...@apache.org>
> wrote:
> >>>>
> >>>>> Apache Ignite is receiving code for distributed Persistent Store.
> >>>>>
> >>>>> See:
> >>>>>
> >>> http://incubator.apache.org/ip-clearance/persistent-
> distributed-store-ignite.html
> >>>>>
> >>>>> Please vote to approve the donation.
> >>>>>
> >>>>> This is a lazy consensus majority vote, open for at least 72 hours.
> >>>>>
> >>>>> Regards,
> >>>>> Denis
> >>>>>
> >>>>>
> >>>>>
> >>>>> 
> -
> >>>>> 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
> >
> > Craig L Russell
> > Secretary, Apache Software Foundation
> > c...@apache.org http://db.apache.org/jdo
>
> Craig L Russell
> Secretary, Apache Software Foundation
> c...@apache.org http://db.apache.org/jdo
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3

[Niclas Hedhman]

Thanks Anthony,
so that's where the notion "gradlew doesn't work on Windows" comes from.
Makes more sense now. But I don't think that is just as practical for Weex
as it is for BigTop.

On Sat, May 6, 2017 at 3:10 AM, Anthony Baker <aba...@pivotal.io> wrote:

>
> > On May 5, 2017, at 4:27 AM, sospartan <sospar...@gmail.com> wrote:
> >
> > I'll remove whole playground sample app from artifacts innext release. So
> > #7 would be a problem anymore.
> > As the gradle wrapper will be removed too. I'll suggest use installed
> > gradle to create that. These will be put in new "how to build from
> source"
> > doc in root folder.
> > Pierre Smits <pierre.sm...@gmail.com>于2017年5月5日 周五下午6:32写道：
> >
>
> You might want to consider using the Bigtop approach for gradlew [1] to
> avoid shipping a binary in the source release.  The Geode project has been
> using this successfully (thanks to Roman for pointing us in this
> direction!).
>
> Anthony
>
> [1] https://github.com/apache/bigtop/blob/master/gradlew <
> https://github.com/apache/bigtop/blob/master/gradlew>
>
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3

[Niclas Hedhman]

Sorry, but if you don't know the background on that file, then perhaps you
think I am "not civil"... The fact is that NOTICE file doesn't require any
inclusion of what the project depends on, since they are not bundled, but
will be downloaded during build. In a previous round, we were told to take
it out of NOTICE for that reason (not bundled) and I argued that we should
keep it in to make it more reasonable for downstreams to get an idea of
what a binary distro will actually contain. This file was the compromise of
providing such details to downstream.

Now you say, "Uhhh, it is unclear..." when in reality it would be even more
unclear if we left it out, as some people on this very list pushed for on a
previous RC.

So, yes, I get pissed off as well. The incubator over time is getting more
and more intolerant at podling's first release, and I think it is the wrong
way to go. It is disheartening... truly...


Niclas

On Thu, May 4, 2017 at 1:57 PM, Craig Russell <apache@gmail.com> wrote:

> I'm going to call foul on this one.
>
> If you cannot be civil, then leave the discussion to others.
>
> Craig
>
> > On May 3, 2017, at 7:24 PM, Niclas Hedhman <nic...@hedhman.org> wrote:
> >
> >  BUT ALSO figuring out what to start looking for. For fak sake,
> > man Get a grip on reality!
>
> Craig L Russell
> Secretary, Apache Software Foundation
> c...@apache.org http://db.apache.org/jdo
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3

[Niclas Hedhman]

es, we can avoid that
for most users, who normally never touch the NDK. By demanding that these
binaries are taken out, then you just condemned this project to produce a
Binary Release as well, which was not planned for this release.

> 11. There are NOTICE and LICENSE files in ios/sdk that seem to be unix
executable files.
> clr% ls -l ios/sdk
> total 40
> -rwxr-xr-x@  1 clr  staff  11343 Apr 27 20:34 LICENSE
> -rwxr-xr-x@  1 clr  staff575 Apr 27 20:34 NOTICE

An honest mistake, and shouldn't stop a release.

> 12. The README.md doesn't tell me how to build/use org.apache.weex. The
first several lines refer to third-party projects from Alibaba and
cocoapods. How do I use the Apache project?

Well, you just introduced more complexity in "using the project" with your
insistence on no binaries, and more so if your "no execute flag" is also
now not allowed. AFAIK, there is no obligation that the source distribution
must contain all details needed to build the project, only that it can be
built. But for you convenience;

1. Install Gradle and learn how to use it.
2. Install Maven and learn how to use it.
3. Install Android NDK and learn how to use it.
4. Install Android SDK and learn how to use it.
5. Install Xcode and learn how to use it.
6. Install IOS SDK and learn how to use it.
7. Build each part with the tool needed.


Cheers
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3

[Niclas Hedhman]

+1

On Tue, May 2, 2017 at 1:49 PM, sospartan <sospar...@apache.org> wrote:

> Hi all,
> I'll calling a vote for Weex-incubating 0.12.0-RC3 release.
>
> The PPMC vote for this release has passed:
> https://lists.apache.org/thread.html/c5514c86433e3551cae00b21a77a14
> 07ee20846f6565f9701d78c85b@%3Cdev.weex.apache.org%3E
>
> The tag to be voted upon:
> https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git
> ;a=shortlog;h=refs/tags/0.12.0-rc3
>
> The commit hash:
> https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git;a=commit;h=
> 702d04c4922105069f537afdb4688f808530994d
>
> The source tarball can be found at:
> https://dist.apache.org/repos/dist/dev/incubator/weex/0.12.
> 0-incubating/RC3/
>
> The fingerprint of key to sign release artifacts:
> 97B9 6598 A6A3 B63C 53BD  77E9 44C5 2286 22B9 7784
>
> Release artifacts are signed with the following key:
> https://dist.apache.org/repos/dist/dev/incubator/weex/KEYS
>
> Release note about this version:
> https://issues.apache.org/jira/browse/WEEX-26
>
> This vote will remain open for at least 72 hours.
> Please vote on releasing this RC.
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> --
> Best Regards!
> --
>
> sospartan
> https://weex-project.io
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3

[Niclas Hedhman]

As for the Gradle Jar; I gave the go ahead for this release, as I am
pursuing to make Gradle have a single Java file instead of a Jar file, as
this will take some time.

This is known and not of legal concern, and up for interpretation of
policy, which we both agree is not definitive.

Since there is a projected path away from this, I ask you to reconsider.

Cheers
Niclas

On Wed, May 3, 2017 at 8:26 AM, John D. Ament <johndam...@apache.org> wrote:

> Sorry but -1 due to binaries in the source release.  I'm not sure if I
> missed these the last go around or what, but they should not be included
> (gradle-wrapper I know was called out before):
>
> ./apache-weex-incubating-0.12.0-src/android/playground/
> gradle/wrapper/gradle-wrapper.jar
> ./apache-weex-incubating-0.12.0-src/android/sdk/gradle/
> wrapper/gradle-wrapper.jar
> ./apache-weex-incubating-0.12.0-src/android/sdk/license/
> license-gradle-plugin-0.12.1.jar
> ./apache-weex-incubating-0.12.0-src/android/sdk/license/
> maven-license-plugin-1.10.b1.jar
> ./apache-weex-incubating-0.12.0-src/android/sdk/license/
> plexus-utils-3.0.24.jar
> ./apache-weex-incubating-0.12.0-src/android/weex_debug/
> gradle/wrapper/gradle-wrapper.jar
> ./apache-weex-incubating-0.12.0-src/android/weex_debug/libs/classes.jar
> ./apache-weex-incubating-0.12.0-src/scripts/apache-rat-0.12.jar
>
> Other things checked:
> - Has DISCLAIMER
> - File name includes incubating
> - NOTICE and LICENSE look right, especially like the name
> POSSIBLE-NOTICES-FOR-BIN-DIST
>
> I have no idea how to build from source, would be good to include that +
> how to run rat in your instructions.  If it weren't for the binary files I
> would vote a +1.
>
> John
>
> On Tue, May 2, 2017 at 1:49 AM sospartan <sospar...@apache.org> wrote:
>
> > Hi all,
> > I'll calling a vote for Weex-incubating 0.12.0-RC3 release.
> >
> > The PPMC vote for this release has passed:
> >
> > https://lists.apache.org/thread.html/c5514c86433e3551cae00b21a77a14
> 07ee20846f6565f9701d78c85b@%3Cdev.weex.apache.org%3E
> >
> > The tag to be voted upon:
> > https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git
> > ;a=shortlog;h=refs/tags/0.12.0-rc3
> >
> > The commit hash:
> >
> > https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git;a=commit;h=
> 702d04c4922105069f537afdb4688f808530994d
> >
> > The source tarball can be found at:
> >
> > https://dist.apache.org/repos/dist/dev/incubator/weex/0.12.
> 0-incubating/RC3/
> >
> > The fingerprint of key to sign release artifacts:
> > 97B9 6598 A6A3 B63C 53BD  77E9 44C5 2286 22B9 7784
> >
> > Release artifacts are signed with the following key:
> > https://dist.apache.org/repos/dist/dev/incubator/weex/KEYS
> >
> > Release note about this version:
> > https://issues.apache.org/jira/browse/WEEX-26
> >
> > This vote will remain open for at least 72 hours.
> > Please vote on releasing this RC.
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> > --
> > Best Regards!
> > --
> >
> > sospartan
> > https://weex-project.io
> >
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Airflow voting on release artifacts

[Niclas Hedhman]

w.  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.
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Incubator Governance Change

[Niclas Hedhman]

Either you draw the parallels to the TLPs or you don't.

If you do, TLPs don't have Mentors, but they do have a PMC, typically with
engaged members and a 'phone line" to the board in forms of a Chair. If the
"Chair" goes AWOL, then either the PMC members request help from the board
to appoint a new Chair, typically by submission of a resolution, or the
board notices that the phone is no longer ringing, in which case the PMC is
asked if it has died or not.

Translate;
PMC -> Podling committers
PMC Chair -> Mentor
Board -> Incubator PMC

Now, we have the complication that there are 3 mentors, sometimes all
assuming that the "others" will handle it, and podlings are unwise about
what is expected.

I have argued before for a single Mentor, with responsibilities just like
the PMC Chairs and if failing the duties, duly replaced by IPMC. The
counter-argument to single Mentor is that podlings need 3 binding votes,
and I suggest to change the role names here to perhaps "Supporter" and the
Mentor simply emeritus any Supporter that is absent too long, and come to
IPMC to request more help.

Hopefully, we can get to a position where podlings are not asking for IPMC
release votes, just like TLPs are not asking for Board's approval of
releases.

And I think that if the Mentors are then keeping a up-to-date rooster on
Supporters, we have a pretty good overview of podlings' health.


Cheers
Niclas



On Wed, Apr 26, 2017 at 1:37 PM, Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:

> On Wed, Apr 26, 2017 at 5:47 AM, P. Taylor Goetz <ptgo...@gmail.com>
> wrote:
> > ...I mostly agree, but would hesitate with the idea that a podling be
> responsible for raising a red flag
> > when mentors are inactive. If the IPMC isn’t doing it’s job, that’s on
> us, not the projects we incubate
>
> The IPMC will typically not know before it's too late, so it's good
> for the podlings to raise those red flags - and ask the IPMC for help.
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: View archive on podling private@ list

[Niclas Hedhman]

ok, cool...

On Tue, Apr 25, 2017 at 6:41 PM, John D. Ament <johndam...@apache.org>
wrote:

> Niclas,
>
> All of the access rules are based on LDAP now.  I've updated the guides
> recently to reflect that rosters are maintained via whimsy, and not via the
> XML files.  To setup weex's permissions go to
> https://whimsy.apache.org/roster/ppmc/weex and add additional committers
> to
> the PPMC.
>
> I have a request out to Sam to enhance this further to be committer vs
> PPMC, right now it assumes everyone is PPMC.
>
> John
>
> On Tue, Apr 25, 2017 at 12:31 AM Niclas Hedhman <nic...@hedhman.org>
> wrote:
>
> > Dave,
> > I am one of the Weex mentors, and I also don't understand this. I used to
> > be pretty sure that the PPMC was a construct in Incubator without LDAP
> > backing, but perhaps that changed during my absence from the Incubator.
> > Wasn't even committership a matter of the Incubator LDAP group ?
> > And wouldn't this mean that only Incubator PMC members have access to
> > private@PODLING.a.o ?
> >
> > Cheers
> >
> > On Tue, Apr 25, 2017 at 11:10 AM, Dave Fisher <dave2w...@comcast.net>
> > wrote:
> >
> > > You must be on the PPMC(podling), a Mentor, or an Apache Member for
> > > private ML access.
> > >
> > > Mentors should be helping podlings with these tasks.
> > >
> > > Regards,
> > > Dave
> > >
> > > Sent from my iPhone
> > >
> > > > On Apr 24, 2017, at 7:02 PM, sospartan <sospar...@gmail.com> wrote:
> > > >
> > > > Yes, that the RESULT I need. Thank you.
> > > > But It's empty in content when I open this address.
> > > > I want make sure. So, Is there a specific rule that committer can not
> > > view
> > > > these archives of private podling mail list?
> > > >
> > > >> On Tue, Apr 25, 2017 at 2:41 AM, Josh Elser <els...@apache.org>
> > wrote:
> > > >>
> > > >> To avoid disclosing the name included in the subject, here is a
> > > permalink
> > > >> to the RESULT message for a VOTE for a new committer sent by Adam
> Feng
> > > at
> > > >> 2017-04-24 02:51 (-0400).
> > > >>
> > > >> https://lists.apache.org/thread.html/c26b89e59557ae8793bac1e
> > > >> ddeb9d03bfa3e4203da0e50face55193b@%3Cprivate.weex.apache.org%3E
> > > >>
> > > >> Hopefully this is the one you meant... Pinging your mentors in the
> > > future
> > > >> might be better to avoid any chance of accidentally leaking some
> > private
> > > >> context :)
> > > >>
> > > >> - Josh
> > > >>
> > > >> sospartan wrote:
> > > >>
> > > >>> Hi,
> > > >>> May I ask who has karma to view archives of podling private@ list?
> > I'm
> > > >>> weex-incubating committer, but can't view archive of private.
> When I
> > > try
> > > >>> to open
> > > >>>
> > > >>> https://lists.apache.org/list.html?priv...@weex.apache.org , it's
> > > >>> redirect
> > > >>> to commits@ list.
> > > >>>
> > > >>> I need to get permalink of a vote thread.
> > > >>>
> > > >>>
> > > >> 
> -
> > > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > >> For additional commands, e-mail: general-h...@incubator.apache.org
> > > >>
> > > >>
> > > >
> > > >
> > > > --
> > > > sospartan
> > > > Phone:13588488290
> > > > HangZhou
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> > >
> >
> >
> > --
> > Niclas Hedhman, Software Developer
> > http://polygene.apache.org - New Energy for Java
> >
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Airflow voting on release artifacts

[Niclas Hedhman]

It is Java, but we have version references internally in all kinds of
places.
So, what happens is that the build creates the "expected final release",
say "1.2.3" and sets all internal references to that. But the tarball will
be -RCx, which is voted upon. And then, as Bertrand suggested, a rename of
that tarball if the vote passes, is not a problem.

And as John points out, the release build tags "1.2.3" in git and we can
(re)move that later if the vote fails.


On Tue, Apr 25, 2017 at 5:18 PM, Bolke de Bruin <bdbr...@gmail.com> wrote:

> Hi Niclas,
>
> Is this Java or Python? I can only find Java for Polygene.
>
> Furthermore, how do you manage this you repository? Do you have the
> release already set in one of your files, e.g. something like this:
> https://github.com/apache/incubator-airflow/blob/v1-8-
> test/airflow/version.py <https://github.com/apache/
> incubator-airflow/blob/v1-8-test/airflow/version.py>
>
> The build system generates the metadata from there, which is used by the
> package installers (e.g. pip).
>
> Cheers
> Bolke
>
>
> > On 25 Apr 2017, at 10:47, Niclas Hedhman <nic...@hedhman.org> wrote:
> >
> > We have a similar issue in Polygene, but the internal version is simply
> the
> > expected version, say 1.2.3 and the RC has the different file name. No
> > packagers will ever get the -RC named artifact and no confusion is among
> > community members as they are aware of this. IF the RC passes, then the
> > rename can happen. IF the RC doesn't happen, you can rebuild with new
> > content and same internal version.
> >
> > Cheers
> > Niclas
> >
> > On Tue, Apr 25, 2017 at 4:43 PM, Bolke de Bruin <bdbr...@gmail.com>
> wrote:
> >
> >> Hi Bertrand,
> >>
> >>> On 25 Apr 2017, at 09:04, Bertrand Delacretaz <
> >> bdelacre...@codeconsult.ch> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Mon, Apr 24, 2017 at 10:18 PM, Chris Riccomini <
> criccom...@apache.org>
> >> wrote:
> >>>> ...Hitesh recently raised the issue that the artifact that passes the
> >> vote
> >>>> MUST be the one that we actually release...
> >>>
> >>> Yes in terms of having the same binary digests and signatures, but
> >>> renaming the files is fine IMO, especially for removing an -rc suffix
> >>> which makes total sense. I would just add that step to your release
> >>> process documentation to make it clear.
> >>>
> >>>> ...Rename/rebuild after final vote (This is what Airflow is doing, and
> >> Beam
> >>>> does this, I believe)...
> >>>
> >>> I'd say rename yes but rebuild no, in order to keep the same digests
> >>> and signatures.
> >>>
> >>
> >> As mentioned earlier, that seems not to be possible. The metadata
> >> (filename) and version information inside the package need to be in
> sync.
> >> This how the python build tools and python ecosystem works.
> >>
> >> - Bolke.
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >>
> >
> >
> > --
> > Niclas Hedhman, Software Developer
> > http://polygene.apache.org - New Energy for Java
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Airflow voting on release artifacts

[Niclas Hedhman]

We have a similar issue in Polygene, but the internal version is simply the
expected version, say 1.2.3 and the RC has the different file name. No
packagers will ever get the -RC named artifact and no confusion is among
community members as they are aware of this. IF the RC passes, then the
rename can happen. IF the RC doesn't happen, you can rebuild with new
content and same internal version.

Cheers
Niclas

On Tue, Apr 25, 2017 at 4:43 PM, Bolke de Bruin <bdbr...@gmail.com> wrote:

> Hi Bertrand,
>
> > On 25 Apr 2017, at 09:04, Bertrand Delacretaz <
> bdelacre...@codeconsult.ch> wrote:
> >
> > Hi,
> >
> > On Mon, Apr 24, 2017 at 10:18 PM, Chris Riccomini <criccom...@apache.org>
> wrote:
> >> ...Hitesh recently raised the issue that the artifact that passes the
> vote
> >> MUST be the one that we actually release...
> >
> > Yes in terms of having the same binary digests and signatures, but
> > renaming the files is fine IMO, especially for removing an -rc suffix
> > which makes total sense. I would just add that step to your release
> > process documentation to make it clear.
> >
> >> ...Rename/rebuild after final vote (This is what Airflow is doing, and
> Beam
> >> does this, I believe)...
> >
> > I'd say rename yes but rebuild no, in order to keep the same digests
> > and signatures.
> >
>
> As mentioned earlier, that seems not to be possible. The metadata
> (filename) and version information inside the package need to be in sync.
> This how the python build tools and python ecosystem works.
>
> - Bolke.
> ---------
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: View archive on podling private@ list

[Niclas Hedhman]

Dave,
I am one of the Weex mentors, and I also don't understand this. I used to
be pretty sure that the PPMC was a construct in Incubator without LDAP
backing, but perhaps that changed during my absence from the Incubator.
Wasn't even committership a matter of the Incubator LDAP group ?
And wouldn't this mean that only Incubator PMC members have access to
private@PODLING.a.o ?

Cheers

On Tue, Apr 25, 2017 at 11:10 AM, Dave Fisher <dave2w...@comcast.net> wrote:

> You must be on the PPMC(podling), a Mentor, or an Apache Member for
> private ML access.
>
> Mentors should be helping podlings with these tasks.
>
> Regards,
> Dave
>
> Sent from my iPhone
>
> > On Apr 24, 2017, at 7:02 PM, sospartan <sospar...@gmail.com> wrote:
> >
> > Yes, that the RESULT I need. Thank you.
> > But It's empty in content when I open this address.
> > I want make sure. So, Is there a specific rule that committer can not
> view
> > these archives of private podling mail list?
> >
> >> On Tue, Apr 25, 2017 at 2:41 AM, Josh Elser <els...@apache.org> wrote:
> >>
> >> To avoid disclosing the name included in the subject, here is a
> permalink
> >> to the RESULT message for a VOTE for a new committer sent by Adam Feng
> at
> >> 2017-04-24 02:51 (-0400).
> >>
> >> https://lists.apache.org/thread.html/c26b89e59557ae8793bac1e
> >> ddeb9d03bfa3e4203da0e50face55193b@%3Cprivate.weex.apache.org%3E
> >>
> >> Hopefully this is the one you meant... Pinging your mentors in the
> future
> >> might be better to avoid any chance of accidentally leaking some private
> >> context :)
> >>
> >> - Josh
> >>
> >> sospartan wrote:
> >>
> >>> Hi,
> >>> May I ask who has karma to view archives of podling private@ list? I'm
> >>> weex-incubating committer, but can't view archive of private.  When I
> try
> >>> to open
> >>>
> >>> https://lists.apache.org/list.html?priv...@weex.apache.org , it's
> >>> redirect
> >>> to commits@ list.
> >>>
> >>> I need to get permalink of a vote thread.
> >>>
> >>>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >>
> >
> >
> > --
> > sospartan
> > Phone:13588488290
> > HangZhou
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC2

[Niclas Hedhman]

On Sun, Apr 23, 2017 at 7:26 PM, John D. Ament <johndam...@apache.org>
wrote:

> Sure - but there's still issues with it.  And you still need a NOTICE file
> in your source distribution.
>

True. But it would be a single "from Apache..." note, as we are not
bundling anything else.


> I thought about your points a bit more last night, and conversely I want to
> explain why its actually more of a burdon.  Suppose that for some reason I
> found the contents of this class to be useful and wanted to use it alone in
> my work:
> https://github.com/apache/incubator-weex/blob/master/
> android/commons/src/main/java/com/alibaba/weex/commons/
> SimpleWeexActivity.java
> .
> By having an extremely verbose NOTICE, as a user of this file alone, I have
> to carry all of that along with me.
>

I think you will get more than one answer if asking 3 lawyers on this,
because if you single out that class file, then the discussion is quickly
whether the "work" is that class file, or all the stuff around it.

Example; say that I use something that was licensed to me under a BSD
license, but is not otherwise published elsewhere, or maybe hard to locate.
I use that work in a larger work which I release under GPL. So, you come
along and find this file and say "hey, exactly what I have been looking
for"... Is that file now GPL, even though the file header may say
otherwise, and no matter whether I intended that? This is analogous of your
case above, but perhaps spelled out a bit more dramatically.

And honestly, hand on heart, how often is picking individual source files
done, compared to the endless number of binary dependencies that are
resolved by the hour? And most business software that I have ended up
working on places those dependencies in the mid-to-high hundreds, even
beyond thousand, where IF built from source, YOU would have to go figure
each one out manually. Can you honestly claim that is less "burden", even
IF all 100 lines of notice needs to percolate downstream ad nauseum, which
in reality is a "cat his/NOTICE her/NOTICE >my/NOITCE"?


I also just noticed that your
> the files are including the full license text of

the apache license in each file.  We typically use the abbreviated version.
>

Yeah, I know that. I thought to tackle that with a package name change that
I would also like to see soon.


Cheers
-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Incubator Governance Change

[Niclas Hedhman]

On Sun, Apr 23, 2017 at 11:43 AM, Roman Shaposhnik <ro...@shaposhnik.org>
wrote:
> I don't
> think releasing something out of ASF that hasn't had at least 3 binding
votes
> would be advisable.

AFAIK, projects "publish" to
https://repository.apache.org/content/groups/snapshots/org/apache as part
of CI build without vetting and votes. There are also other snapshots
(example; https://ci.apache.org/projects/openoffice/install/win/) that are
not Maven artifacts.

IF we allow those, then why not allow podlings to do the same thing?


Cheers
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Incubator Governance Change

[Niclas Hedhman]

On Sun, Apr 23, 2017 at 8:46 AM, Roman Shaposhnik <ro...@shaposhnik.org>
wrote:

>
> I'm starting to wonder whether the real solution here should be along the
> lines
> of what a board would do to a TLP if its active PMC shrinks to less
> than 3 people.


That will inevitable lead to definition of "what is active" and the whole
"pity me/them for not having time" discussion that always arises when
Mentor responsibilities are brought up.

I have been Mentor on 8 podlings;
  * I was inactive on 1 of those (can't recall the reason)
  * On 2 projects one other mentor was active.
  * Remaining 5 projects, none of the other mentors did anything
substantial, most nothing at all.

Am I unlucky, scare others to inactivity, or is this what I think; people
don't take the responsibility particularly seriously. "Oh cool project, I
would like to be associated with that."

Pat's suggestion is understandable, but not really viable.

I would like to make a counter-suggestion, and I am sure IPMC won't like
it, since it is filled with inactive, but sensitive, mentors;

   * If the release is left dangling (not enough votes) for IPMC approval
beyond 72 hours,
 1. The release may be placed in the dist snapshot areas, so active
community members have some stable milestone to work with,
 2. An Incubator page (for instance the /projects page) is updated with
a "Attempted Release - failed not enough votes" with dates and votes
received. This will accumulate the data points for IF there is a real
problem in the Incubator and we can gather the stats if we have
irresponsible mentors or not. It also gives the podling a vent for the
frustration.


Cheers
-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC2

[Niclas Hedhman]

John,
thanks for pointing me to the issue. I argue against Marvin on it, based on
"this is a tool" that is made conveniently available for those who are not
paranoid.

NOTICE; Ok, let's rename the file.
NOTICES-POSSIBLY-NEEDED-FOR-BINARY-DISTRIBUTION

Ok?


On Sun, Apr 23, 2017 at 8:01 AM, John D. Ament <johndam...@apache.org>
wrote:

> On Sat, Apr 22, 2017 at 7:57 AM Niclas Hedhman <nic...@hedhman.org> wrote:
>
> > On Sat, Apr 22, 2017 at 7:25 PM, John D. Ament <johndam...@apache.org>
> > wrote:
> > >
> > > On Sat, Apr 22, 2017 at 6:41 AM Niclas Hedhman <nic...@hedhman.org>
> > wrote:
> > >
> > > > Note on gradle-wrapper.jar,
> >
> > > Agreed, and this is mostly my argument as well.  However, in *nix the
> JAR
> > > will get downloaded automatically if not present.  On windows, you need
> > to
> > > pre-install gradle.
> >
> > Where did you get this idea? The gradlew launches the Java program inside
> > the gradle-wrapper.jar which in turn downloads the full Gradle distro if
> > not present already. I have not heard neither that the gradlew would
> > download the wrapper jar, nor that the gradle-wrapper does not work on
> > Windows.
> >
> >
> I must have seen a custom built version of gradlew then.
>
>
> >
> > > The argument I've seen from present VP Legal is that the JARs may have
> > > viruses in them, or contain other malware.
> >
> > That was the silliest reason I have heard in a long time. With that
> > argument, we only allow source distributions, only allow to use tools
> that
> > are built from source recursively back through time... Yeah! Right...
> now,
> > there are a few projects that needs that, such as the Bitcoin blockchain
> > toolchain, as they distrust everything, and settled on some binary from
> > decades ago with a known hash as the starting point. In any event, ASF
> > would collapse under the "they may contain malware" banner of paranoia.
> >
> > I don't buy it, since I trust my fellow folks at ASF rather than assume
> > malevolence from everyone.
> >
> >
> I don't disagree with you.  And now may be a good time to bring this back
> up.  But for now, its not allowable in the release.  See also
> https://issues.apache.org/jira/browse/LEGAL-288
>
>
>
> > In this particular case, I don't think that gradle-wrapper.jar ever
> > changes, so committing a new version would set off red flags, at least
> with
> > me (used Gradle for about 7 years now). A small script that traverse all
> of
> > Apache GitHub and compares them all??
> >
> > >
> > > > Note on LICENSE;
> > > > IIUIC, the source distribution doesn't ship any dependencies (except
> > Gradle
> > > > above), and there is only Apache License to be considered.
> > > >
> > > > As for NOTICE, the ASF documentation you point to, basically says
> that
> > a)
> > > > don't put in anything that is not bundled (i.e. just about nothing in
> > the
> > > > source release), b) no burden on downstream users. HOWEVER, by
> > excluding
> > > > the list of dependencies that will be in the resulting product, we
> > would
> > > > actually increase the burden of downstream users as they would need
> to
> > > > figure out what licensing requirements will come out of it all, if
> they
> > > > choose to distribute.
> > > > Therefor, I would argue that documentation is in this case arguing
> > against
> > > > itself in a single sentence, and think that the approach taken by
> Weex
> > is
> > > > appropriate.
> > > >
> > >
> > > I disagree.  I think you're thinking of source release vs binary
> release.
> > > Weex has only presented a source release.
> >
> > I am aware of that, but the documentation says "make it easier for the
> > downstream" and by "excluding all non-bundled, but required, dependencies
> > from NOTICE" we actually make it harder for the downstream. And sorry, I
> > place "common sense" and "tribal knowledge" way over someone writing a
> > documentation and perhaps didn't realize the consequences. I never stop
> > thinking, just because I read something somewhere.
> >
> >
> I'm not sure what a valid response to this would be.  I don't believe we
> should be taking into account ease of use for downstream consumers, however
> at the end of the day those downstream consumers of a source release
> eventually get a binary and that binary should include proper data.  What I
> am trying to say is that these contents look more appropriate for the
> binary release, which would be a satisfactory use case for downstream
> consumers.
>
>
>
> >
> > Cheers
> > --
> > Niclas Hedhman, Software Developer
> > http://polygene.apache.org - New Energy for Java
> >
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC2

[Niclas Hedhman]

On Sat, Apr 22, 2017 at 7:25 PM, John D. Ament <johndam...@apache.org>
wrote:
>
> On Sat, Apr 22, 2017 at 6:41 AM Niclas Hedhman <nic...@hedhman.org> wrote:
>
> > Note on gradle-wrapper.jar,

> Agreed, and this is mostly my argument as well.  However, in *nix the JAR
> will get downloaded automatically if not present.  On windows, you need to
> pre-install gradle.

Where did you get this idea? The gradlew launches the Java program inside
the gradle-wrapper.jar which in turn downloads the full Gradle distro if
not present already. I have not heard neither that the gradlew would
download the wrapper jar, nor that the gradle-wrapper does not work on
Windows.


> The argument I've seen from present VP Legal is that the JARs may have
> viruses in them, or contain other malware.

That was the silliest reason I have heard in a long time. With that
argument, we only allow source distributions, only allow to use tools that
are built from source recursively back through time... Yeah! Right... now,
there are a few projects that needs that, such as the Bitcoin blockchain
toolchain, as they distrust everything, and settled on some binary from
decades ago with a known hash as the starting point. In any event, ASF
would collapse under the "they may contain malware" banner of paranoia.

I don't buy it, since I trust my fellow folks at ASF rather than assume
malevolence from everyone.

In this particular case, I don't think that gradle-wrapper.jar ever
changes, so committing a new version would set off red flags, at least with
me (used Gradle for about 7 years now). A small script that traverse all of
Apache GitHub and compares them all??

>
> > Note on LICENSE;
> > IIUIC, the source distribution doesn't ship any dependencies (except
Gradle
> > above), and there is only Apache License to be considered.
> >
> > As for NOTICE, the ASF documentation you point to, basically says that
a)
> > don't put in anything that is not bundled (i.e. just about nothing in
the
> > source release), b) no burden on downstream users. HOWEVER, by excluding
> > the list of dependencies that will be in the resulting product, we would
> > actually increase the burden of downstream users as they would need to
> > figure out what licensing requirements will come out of it all, if they
> > choose to distribute.
> > Therefor, I would argue that documentation is in this case arguing
against
> > itself in a single sentence, and think that the approach taken by Weex
is
> > appropriate.
> >
>
> I disagree.  I think you're thinking of source release vs binary release.
> Weex has only presented a source release.

I am aware of that, but the documentation says "make it easier for the
downstream" and by "excluding all non-bundled, but required, dependencies
from NOTICE" we actually make it harder for the downstream. And sorry, I
place "common sense" and "tribal knowledge" way over someone writing a
documentation and perhaps didn't realize the consequences. I never stop
thinking, just because I read something somewhere.


Cheers
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC2

[Niclas Hedhman]

Note on gradle-wrapper.jar,
For source releases, we expect the project to be buildable by the user. The
Gradle wrapper is the easiest way to make that happen. It (together with
the gradlew and gradlew.bat scripts) ensures that that the build will be
the same, and not suffer from different Gradle versions being used,
potentially incompatible. Now, you could write a document on how to achieve
this in other ways, and deal with the fall-out. But just like the
gradle-wrapper.jar is committed to the source repository, I stand by that
the gradle-wrapper belongs in the source distro, as a defacto standard for
projects using Gradle to build. You will find similar 'bundling' of build
systems in other languages as well, are they also banned? Or it just
because they are in human-readable format that it is considered ok?

Note on LICENSE;
IIUIC, the source distribution doesn't ship any dependencies (except Gradle
above), and there is only Apache License to be considered.

As for NOTICE, the ASF documentation you point to, basically says that a)
don't put in anything that is not bundled (i.e. just about nothing in the
source release), b) no burden on downstream users. HOWEVER, by excluding
the list of dependencies that will be in the resulting product, we would
actually increase the burden of downstream users as they would need to
figure out what licensing requirements will come out of it all, if they
choose to distribute.
Therefor, I would argue that documentation is in this case arguing against
itself in a single sentence, and think that the approach taken by Weex is
appropriate.

(all subject to that my understanding of that there is no third-party in
the source distribution)


Package name; yeah, I completely forgot that, as I saw it in the directory
name.


On Sat, Apr 22, 2017 at 6:10 PM, John D. Ament <johndam...@apache.org>
wrote:

> Sorry but -1 due to misnamed package and binary content.
>
> - No "incubating" / "incubator" in package name
> - JAR files are present in the source release (gradle-wrapper.jar)
> - Ideally the expanded package would include "apache" in the folder, not a
> big deal.
> - DISCLAIMER present
>
> Your NOTICE seems way too big.  Do you actually bundle all of these
> dependencies? I can't find them if you do.  Most of what's being called out
> in NOTICE should actually be in LICENSE.  For instance, only Apache
> licensed code would normally call out NOTICE entries, and those entries are
> meant to be copied verbatim from the source package. In this case, fastjson
> is referenced (though I don't see it anywhere), but it has no NOTICE so
> nothing to declare.
>
> Meanwhile, your LICENSE is too short.  Each project that you do bundle, if
> its not Apache licensed, you must copy its license text or provide a
> pointer to the license.  We have a full guide on how to assemble these -
> http://www.apache.org/dev/licensing-howto.html - please reach out if you
> need help.
>
> The critical piece to fix is your package name.  If you're re-rolling to
> fix that, I would recommend going through your NOTICE/LICENSE and see what
> does and doesn't belong.  The second piece to fix is the JAR files.  You
> must not include them (I've tried fighting the fight, and can't get
> anywhere on it - source releases are for source code only).
>
> John
>
> On Thu, Apr 20, 2017 at 4:11 AM sospartan <sospar...@apache.org> wrote:
>
> > Hi all,
> > I'll calling a vote for Weex-incubating 0.12.0-RC2 release.
> >
> > The PPMC vote for this release has passed:
> >
> > https://lists.apache.org/thread.html/d544a60a4038f9d053f7ea1eca0d16
> 2b9aef392551a02a0401041e8f@%3Cdev.weex.apache.org%3E
> >
> > The tag to be voted upon:
> > https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git
> > ;a=shortlog;h=refs/tags/0.12.0-rc1
> >
> > The commit hash:
> > https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git;a=commit;h=
> > 9ac0c82443e65b1c9d8a2714fea6b9a5b8af9907
> > <https://git-wip-us.apache.org/repos/asf?p=incubator-
> weex.git;a=commit;h=9ac0c82443e65b1c9d8a2714fea6b9a5b8af9907>
> >
> > The source tarball can be found at:
> >
> > https://dist.apache.org/repos/dist/dev/incubator/weex/0.12.
> 0-incubating/RC1/
> >
> > The fingerprint of key to sign release artifacts:
> > 97B9 6598 A6A3 B63C 53BD  77E9 44C5 2286 22B9 7784
> >
> > Release artifacts are signed with the following key:
> > https://dist.apache.org/repos/dist/dev/incubator/weex/KEYS
> >
> > Release note about this version:
> > https://issues.apache.org/jira/browse/WEEX-26
> >
> > This vote will remain open for at least 72 hours.
> > Please vote on releasing this RC.
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> > --
> > Best Regards!
> > --
> >
> > sospartan
> > https://weex-project.io
> >
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Weex release needs votes, vetting, ++

[Niclas Hedhman]

The third RC is placed before the Incubator and hoping to get through the
door.

Any takers?

Cheers
-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC2

[Niclas Hedhman]

+1 binding

On Thu, Apr 20, 2017 at 4:10 PM, sospartan <sospar...@apache.org> wrote:

> Hi all,
> I'll calling a vote for Weex-incubating 0.12.0-RC2 release.
>
> The PPMC vote for this release has passed:
> https://lists.apache.org/thread.html/d544a60a4038f9d053f7ea1eca0d16
> 2b9aef392551a02a0401041e8f@%3Cdev.weex.apache.org%3E
>
> The tag to be voted upon:
> https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git
> ;a=shortlog;h=refs/tags/0.12.0-rc1
>
> The commit hash:
> https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git;a=commit;h=
> 9ac0c82443e65b1c9d8a2714fea6b9a5b8af9907
>
> The source tarball can be found at:
> https://dist.apache.org/repos/dist/dev/incubator/weex/0.12.
> 0-incubating/RC1/
>
> The fingerprint of key to sign release artifacts:
> 97B9 6598 A6A3 B63C 53BD  77E9 44C5 2286 22B9 7784
>
> Release artifacts are signed with the following key:
> https://dist.apache.org/repos/dist/dev/incubator/weex/KEYS
>
> Release note about this version:
> https://issues.apache.org/jira/browse/WEEX-26
>
> This vote will remain open for at least 72 hours.
> Please vote on releasing this RC.
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> --
> Best Regards!
> --
>
> sospartan
> https://weex-project.io
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: The state of Sirona

[Niclas Hedhman]

a community really didn't get the point of the Apache
> >>>> license.
> >>>>> In many cases, the world just changes and by the time it is time to
> >>>>> graduate, the project just isn't the right thing to do any more.
> >>>>>
> >>>>> As such, I think we need to (somewhat) over-admit podlings when there
> >>> is
> >>>>> doubt. That doesn't mean admit projects that just won't ever succeed,
> >>> but
> >>>>> it does mean we should be a little generous in terms of admission. We
> >>>>> should vote to admit in cases of some doubt.
> >>>>>
> >>>>> If that is true, then we have to expect that there will be a variety
> >> of
> >>>>> outcomes and we have to take that as a consequence of our initial
> >>>>> generosity. This is not a cause for tears. Frankly, every project
> >> that
> >>>>> becomes an obvious candidate for retirement means that there is
> >> another
> >>>>> successful project that we admitted even though there was doubt.
> >>>>>
> >>>>> IF it is time to retire Sirona, let's just do it.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Sat, Apr 15, 2017 at 10:09 AM, Pierre Smits <
> >> pierre.sm...@gmail.com
> >>>>
> >>>>> wrote:
> >>>>>
> >>>>>> It is very sad to see a project failing at growing a community.
> >>> Looking
> >>>>> at
> >>>>>> the various public sources, I see:
> >>>>>>
> >>>>>>   - just 2 pull request since its start in incubation
> >>>>>>   - no postings on the user ml since December 2015
> >>>>>>   - only 3 committing contributors since start in incubation
> >>>>>>   - No description (readme) in github
> >>>>>>   - No mission statement/goal description of the project on the
> >>>>> project's
> >>>>>>   home page
> >>>>>>
> >>>>>> I fear this will not turn around due to the lack of interest in the
> >>>> world
> >>>>>> beyond the project. At the moment I am inclined to say: time for
> >>>>>> retirement.
> >>>>>>
> >>>>>> Best regards,
> >>>>>>
> >>>>>>
> >>>>>> Pierre Smits
> >>>>>>
> >>>>>> ORRTIZ.COM <http://www.orrtiz.com>
> >>>>>> OFBiz based solutions & services
> >>>>>>
> >>>>>> OFBiz Extensions Marketplace
> >>>>>> http://oem.ofbizci.net/oci-2/
> >>>>>>
> >>>>>> On Sat, Apr 15, 2017 at 5:07 PM, Jean-Baptiste Onofré <
> >>> j...@nanthrax.net
> >>>>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi John
> >>>>>>>
> >>>>>>> I think you did the right thing by bringing the point on the
> >> table.
> >>>>>>>
> >>>>>>> AFAIR I already stated some months ago that, regarding the
> >> activity
> >>>> and
> >>>>>>> regarding the community around, we should really think about
> >>>> retirement
> >>>>>> of
> >>>>>>> Sirona. Some can argue about the fact that Sirona is a "stable"
> >>>> project
> >>>>>>> that's not really valid: if it's valid we should see questions,
> >>>> feature
> >>>>>>> requests, etc coming from the user community. And obviously it's
> >>> not
> >>>>> the
> >>>>>>> case. So I think that Sirona is just use for specific use cases
> >> in
> >>> a
> >>>>> very
> >>>>>>> limited community.
> >>>>>>>
> >>>>>>> My €0.01 ;)
> >>>>>>>
> >>>>>>> Regards
> >>>>>>> JB
> >>>>>>>
> >>>>>>> On Apr 15, 2017, 15:49, at 15:49, "John D. Ament" <
> >>>>> johndam...@apache.org
> >>>>>>>
> >>>>>>> wrote:
> >>>>>>>> All,
> >>>>>>>>
> >>>>>>>> I hate bringing up these topics.  But I think we as the IPMC we
> >>> have
> >>>>> to
> >>>>>>>> take a close look at how Sirona is running and figure out what
> >> to
> >>> do
> >>>>>>>> next.
> >>>>>>>>
> >>>>>>>> - The podling has not reported in several months (this is their
> >>> 3rd
> >>>>>>>> attempt
> >>>>>>>> at monthly).
> >>>>>>>> - Every time the thought of retirement comes up, a little bit of
> >>>>>>>> activity
> >>>>>>>> on the project happens.  It doesn't sustain.
> >>>>>>>> - There is some limited project history, but no real
> >> contribution
> >>>> in 6
> >>>>>>>> months ( https://github.com/apache/sirona/commits/trunk )
> >>>>>>>>
> >>>>>>>> I personally don't want to see projects go, and I don't want to
> >>>> force
> >>>>> a
> >>>>>>>> project to leave, but at the same time I'm not convinced that
> >>>> there's
> >>>>>>>> enough of a community behind the project to sustain it going
> >>>> forward.
> >>>>>>>> They've put together a limited plan to get a release out the
> >> door,
> >>>> but
> >>>>>>>> other than that I'm not sure they're going to be able to move
> >>>> forward.
> >>>>>>>>
> >>>>>>>> So I want to ask, as the IPMC, do we want to give them time to
> >>>>> regroup?
> >>>>>>>>
> >>>>>>>> John
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: The state of Sirona

[Niclas Hedhman]

t.
> > > >
> > > >- The podling has not reported in several months (this is their 3rd
> > > >attempt
> > > >at monthly).
> > > >- Every time the thought of retirement comes up, a little bit of
> > > >activity
> > > >on the project happens.  It doesn't sustain.
> > > >- There is some limited project history, but no real contribution in 6
> > > >months ( https://github.com/apache/sirona/commits/trunk )
> > > >
> > > >I personally don't want to see projects go, and I don't want to force
> a
> > > >project to leave, but at the same time I'm not convinced that there's
> > > >enough of a community behind the project to sustain it going forward.
> > > >They've put together a limited plan to get a release out the door, but
> > > >other than that I'm not sure they're going to be able to move forward.
> > > >
> > > >So I want to ask, as the IPMC, do we want to give them time to
> regroup?
> > > >
> > > >John
> > >
> >
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Help with Dependency Licensing

[Niclas Hedhman]

On Wed, Apr 12, 2017 at 9:03 AM, John D. Ament <johndam...@apache.org>
wrote:

>
> The info I provided was based on a discussion on legal, originally carried
> over from a discussion on optional dependencies on software licensed under
> the Amazon Software License -
> https://lists.apache.org/thread.html/2630f3d9540f02ef24f5e03cc171c4
> a2975bd8965c80a1965a55c0b4@%3Clegal-discuss.apache.org%3E
>
>
Yet another long thread on the same topic. I was on Legal for ~5 years and
Hibernate came up again and again. Since their is an JPA implementation
in-house, there would be no need to depend on Hibernate for Apache
projects. And perhaps it is unfair to talk about Hibernate if you want to
discuss Amazon licensing terms, but that is where this thread headed (until
I stopped reading about half way down).

People (myself included at times) forget that our own individual 'opinion'
and 'interpretation' are irrelevant. What matters are "legal opinion" from
a lawyer, who is guessing(!) what a court/judge would rule, and to a lesser
degree the "intent of the license author", who in (L)GPL case is FSF Legal
Counsel (Eben Mogel just stepped down, btw), lawyers spending years to
figure this out, and when FSF declare an intent we either follow that or
take it to court.
Then to make matters worse, the software project author sometimes expresses
an intent that differs from the intent of its license author, and the
"exceptions" comes to play (or not).


Cheers
-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Help with Dependency Licensing

[Niclas Hedhman]

On Wed, Apr 12, 2017 at 12:31 AM, Mike Jumper <mike.jum...@guac-dev.org>
wrote:

>
> Even in the case of the GPL, my understanding is that the virality takes
> hold upon linking (at build time), not upon referencing the API via an
> import, include, etc. in the source.
>

Your understanding is, simply put, not aligned with the FSF, and the ASF
has decided to follow FSF's conclusion. In fact, a former Director at ASF
and lawyer, Larry Rosen, was trying to fight this stance, basically making
the claim that GPL is overreaching, and that ended with Larry being kicked
out (not only for this particular question).


http://www.gnu.org/licenses/lgpl-java.html; emphasis="mine">
It has always been the FSF's position that *dynamically linking
applications to libraries creates a single work derived* from both the
library code and the application code.The GPL requires that all derivative
works be licensed as a whole under the terms of the GPL, an effect which
can be described as “hereditary.” So, if an application links to a library
licensed under the GPL, the application too must be licensed under the GPL.
 :
 :
FSF's position has remained constant throughout: the LGPL works as intended
with all known programming languages, including Java. Applications which
link to LGPL libraries need not be released under the LGPL. Applications
need only follow the requirements in section 6 of the LGPL: allow new
versions of the library to be linked with the application; and allow
reverse engineering to debug this.


At first, the "link to LGPL libraries need not be released under LGPL" is
an indicator that Apache licensed projects could depend on LGPL projects,
but it is this "Section 6" that makes LGPL incompatible, since we don't
require this of our downstreams. This was hotly debated back in the days
when this FSF article was written, and it took us a year or two to nail it
down.


More info at http://www.gnu.org/licenses/gpl-faq.html

John, As for the case of Hibernate; If you depend on JPA, you don't depend
on Hibernate. However, if you depend on JPA in a way so that only Hibernate
makes the project work, and that EclipseLink or other implementations can't
be used instead, then you are in gray territory and should ask Legal for
advice. I am uncertain of that position.


Cheers
-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Publishing npm modules

[Niclas Hedhman]

Thanks, that was very helpful.

On Wed, Apr 12, 2017 at 7:03 AM, Marvin Humphrey <mar...@rectangular.com>
wrote:

> On Tue, Apr 11, 2017 at 7:00 AM, Niclas Hedhman <nic...@hedhman.org>
> wrote:
>
> > does anyone have any information on policy/process for uploading npm
> > modules to global registry https://registry.npmjs.org/
>
> With regards to publication of packages, npm is just another downstream
> distribution channel -- like Maven Central, Docker Hub, PyPI, CPAN, Debian,
> crates.io, etc.
>
> The main policy point that comes up is this one:
>
> http://www.apache.org/legal/release-policy#publication
>
> Projects SHALL publish official releases and SHALL NOT publish
> unreleased
> materials outside the development community.
>
> The second policy point that comes up frequently has to do with
> trademarks: we
> expect that anything published as "Apache Foo" will actually be "Apache
> Foo",
> and not, say, a vendor-specific "sneak peek" version incorporating
> controversial new features.
>
> It can also be important that multiple PMC members have upload permissions
> for a given distribution channel.  That's a best practice, not a policy,
> though.
>
> But these points apply across all downstream distribution channels, not
> just npm.
>
> > This is for convenience and should be similar to publishing to Maven
> > Central, but I would like to know if there is anything explicit about it.
>
> Infra provides some extra support for certain kinds of distribution (we run
> repository.apache.org, we used to run a PEAR repo, etc).  I don't know of
> any special technical support related to npm, though.
>
> Marvin Humphrey
>
> ---------
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Help with Dependency Licensing

[Niclas Hedhman]

Please note that Cat X licenses are deemed to be incompatible with Apache
License, insofar that they are viral in nature, and FSF has made a claim
that dynamically linked languages, such as Java, forces the virality to the
dependent project... Meaning, if you have an import statement linking your
code to such dependency, there is legal uncertainty whether the entire
project must be under the copyleft license in question. FSF certainly
thinks so, and VP Legal has in the past concluded that we should have the
same stance.

So when is the optional Cat X dependency acceptable?

For instance, an acceptably licensed API specification is what our project
depend on, and some runtime mechanism (such as Java Service Loader or
Spring Dependency Injection) make that available. Without this indirection,
we ain't allowed to have dependency on Cat X for Java (and other
circumstances).


HTH
Niclas


On Tue, Apr 11, 2017 at 10:26 PM, Nick Couchman <
nick.couch...@yahoo.com.invalid> wrote:

> Hello, everyone,I'm currently working on the Guacamole incubator project,
> and am developing an extension for the project that has dependencies on
> binaries (JARs via Maven) that are licensed under Category-X licenses.
> We've already determined that we cannot distribute a binary version of this
> extension, but, since it is an extension (and not core to the functionality
> of the product), we should be able to distribute the source code with build
> instructions for the users.
> The question I have is how we should deal with license bundling in this
> scenario?  In the rest of this project, including other extensions, we
> bundle a src/licenses directory that has all of the dependency licenses for
> the extension.  When the binary is built, a resulting file has not only the
> binary for the extension, but also all of the dependency licenses.  Since
> we're not distributing a binary, is there any reason/need for us to package
> up dependency licenses?
> Let me know if this needs more clarification - I know this might be a bit
> vague, but I'm in new territory, here, and am happy to provide any further
> information that might help someone help me :-).
> Thanks,Nick




-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Publishing npm modules

[Niclas Hedhman]

Hi,

does anyone have any information on policy/process for uploading npm
modules to global registry https://registry.npmjs.org/

This is for convenience and should be similar to publishing to Maven
Central, but I would like to know if there is anything explicit about it.

Cheers
-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: [DISCUSS] Apache Metron podling Graduation

[Niclas Hedhman]

Sorry, I probably didn't read the subject line, and draw wrong conclusion
when seeing the proposed resolution...

On Fri, Mar 24, 2017 at 12:19 PM, Dave Fisher <dave2w...@comcast.net> wrote:

> This is not a VOTE thread. There is a misstatement to clear up. What part
> of the maturity model is ongoing?
>
> Regards,
> Dave
>
> Sent from my iPhone
>
> > On Mar 23, 2017, at 5:05 PM, Niclas Hedhman <nic...@hedhman.org> wrote:
> >
> > +1 (binding)
> >
> >> On Fri, Mar 24, 2017 at 2:32 AM, Casey Stella <ceste...@gmail.com>
> wrote:
> >>
> >> Hi Everyone,
> >>
> >> The incubating Apache Metron community believes it is time to graduate
> >> to TLP.
> >>
> >> Apache Metron entered incubation in December of 2015. Since then, we've
> >> overcome technical challenges to remove Category X dependencies, and
> >> made 3 releases. Our most recent release contains binary convenience
> >> artifacts. We are a very helpful and engaged community, ready to answer
> >> all questions and feedback directed to us via the user list. Through our
> >> time in incubation we've added a number of committers and promoted some
> >> of them to PPMC membership. We are actively pursuing others. While we do
> >> still have issues to address raised by means of the maturity model, all
> >> projects are ongoing processes, and we believe we no longer need the
> >> incubator to continue addressing these issues.
> >>
> >> To inform the discussion, here is some basic project information:
> >>
> >> Project status:
> >>  http://incubator.apache.org/projects/metron.html
> >>
> >> Project website:
> >>  https://metron.incubator.apache.org/
> >>
> >> Project documentation:
> >>   https://cwiki.apache.org/confluence/display/METRON/Documentation
> >>
> >> Maturity assessment:
> >>
> >> https://cwiki.apache.org/confluence/display/METRON/
> >> Apache+Project+Maturity+Model
> >>
> >> Community Vote to Graduate:
> >>
> >> https://lists.apache.org/thread.html/540378e2773b1b2ce2af498e56a643
> >> 5e547c04948a6b496b9a4ffc71@%3Cdev.metron.apache.org%3E
> >>
> >> DRAFT of the board resolution is at the bottom of this email
> >>
> >> Proposed PMC size: 24 members
> >>
> >> Total number of committers: 6 members
> >>
> >>
> >> 516 commits on develop
> >> 34 contributors across all branches
> >>
> >> dev list averaged ~650 msgs/month for the last 3 months
> >>
> >>
> >> Resolution:
> >>
> >> Establish the Apache Metron 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 security analytics platform for big data use cases.
> >>
> >> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> >> Committee (PMC), to be known as the "Apache Metron Project",
> >> be and hereby is established pursuant to Bylaws of the
> >> Foundation; and be it further
> >>
> >> RESOLVED, that the Apache Metron Project be and hereby is
> >> responsible for the creation and maintenance of software
> >> related to:
> >> (a) A mechanism to capture, store, and normalize any type of security
> >> telemetry at extremely high rates.
> >> (b) Real time processing and application of enrichments
> >> (c) Efficient information storage
> >> (d) An interface that gives a security investigator a centralized view
> >> of data and alerts passed through the system.
> >>
> >> RESOLVED, that the office of "Vice President, Apache Metron" 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 Metron Project, and to have primary responsibility
> >> for management of the projects within the scope of
> >> responsibility of the Apache Metron 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 Metron Project:
> >>
> >>
> >> PPM

Re: [DISCUSS] Apache Metron podling Graduation

[Niclas Hedhman]

+1 (binding)

On Fri, Mar 24, 2017 at 2:32 AM, Casey Stella <ceste...@gmail.com> wrote:

> Hi Everyone,
>
> The incubating Apache Metron community believes it is time to graduate
> to TLP.
>
> Apache Metron entered incubation in December of 2015. Since then, we've
> overcome technical challenges to remove Category X dependencies, and
> made 3 releases. Our most recent release contains binary convenience
> artifacts. We are a very helpful and engaged community, ready to answer
> all questions and feedback directed to us via the user list. Through our
> time in incubation we've added a number of committers and promoted some
> of them to PPMC membership. We are actively pursuing others. While we do
> still have issues to address raised by means of the maturity model, all
> projects are ongoing processes, and we believe we no longer need the
> incubator to continue addressing these issues.
>
> To inform the discussion, here is some basic project information:
>
> Project status:
>   http://incubator.apache.org/projects/metron.html
>
> Project website:
>   https://metron.incubator.apache.org/
>
> Project documentation:
>https://cwiki.apache.org/confluence/display/METRON/Documentation
>
> Maturity assessment:
>
> https://cwiki.apache.org/confluence/display/METRON/
> Apache+Project+Maturity+Model
>
> Community Vote to Graduate:
>
> https://lists.apache.org/thread.html/540378e2773b1b2ce2af498e56a643
> 5e547c04948a6b496b9a4ffc71@%3Cdev.metron.apache.org%3E
>
> DRAFT of the board resolution is at the bottom of this email
>
> Proposed PMC size: 24 members
>
> Total number of committers: 6 members
>
>
> 516 commits on develop
> 34 contributors across all branches
>
> dev list averaged ~650 msgs/month for the last 3 months
>
>
> Resolution:
>
> Establish the Apache Metron 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 security analytics platform for big data use cases.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> Committee (PMC), to be known as the "Apache Metron Project",
> be and hereby is established pursuant to Bylaws of the
> Foundation; and be it further
>
> RESOLVED, that the Apache Metron Project be and hereby is
> responsible for the creation and maintenance of software
> related to:
> (a) A mechanism to capture, store, and normalize any type of security
> telemetry at extremely high rates.
> (b) Real time processing and application of enrichments
> (c) Efficient information storage
> (d) An interface that gives a security investigator a centralized view
> of data and alerts passed through the system.
>
> RESOLVED, that the office of "Vice President, Apache Metron" 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 Metron Project, and to have primary responsibility
> for management of the projects within the scope of
> responsibility of the Apache Metron 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 Metron Project:
>
>
> PPMC:
> Mark Bittmann (mbittmann)
> Sheetal Dolas (sheetal_dolas)
> Debo Dutta (ddutta)
> Discovery Gerdes (discovery)
> Andrew Hartnett (dev_warlord)
> Dave Hirko (dbhirko)
> Paul Kehrer (reaperhulk)
> Brad Kolarov (bjkolly)
> Kiran Komaravolu (kirankom)
> Larry McCay (lmccay)
> P. Taylor Goetz (ptgoetz)
> Ryan Merriman (rmerriman)
> Michael Perez (mperez)
> Charles Porter (cporter)
> Phillip Rhodes (prhodes)
> Sean Schulte (sirsean)
> James Sirota (jsirota)
> Casey Stella (cstella)
> Ray Urciuoli(rurcioli)
> Vinod Kumar Vavilapalli (vinodkv)
> George Vetticaden (gvetticaden)
> Oskar Zabik (smogg)
> David Lyle (lyle)
> Nick Allen (nickallen)
>
>
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Casey Stella
> be appointed to the office of Vice President, Apache Metron, 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 Metron PMC be and hereby is
> tasked with the creation of a set of bylaws intended to
> encourage open development and increased participation in the
> Ap

Re: [VOTE] Apache Fineract podling graduation (restarted with corrected proposal)

[Niclas Hedhman]

+1

On Wed, Mar 22, 2017 at 10:11 PM, Myrle Krantz <my...@apache.org> wrote:

> Greetings Incubator,
>
> I propose that we graduate Apache Fineract from the Incubator.  The
> full text of the proposal is below.
>
> This is a restarted VOTE thread to correct an error in the resolution
> from the original thread. Here's the previous VOTE thread:
>
> [https://lists.apache.org/thread.html/1cbc738bbb4083e50b7772d5226b88
> d3fe321b91451303a69dbc4fa8@%3Cgeneral.incubator.apache.org%3E]
>
> And here's the DISCUSS thread:
>
> [https://lists.apache.org/thread.html/630d3ec22b4f72f827cd817a0a4da5
> c3c52dee4f96f47a1369f5dc50@%3Cgeneral.incubator.apache.org%3E]
>
>
> Thank you,
> Myrle Krantz
>
>
> Resolution:
>
> Establish the Apache Fineract 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 core banking platform that provides a reliable,
> robust, and affordable solution for entrepreneurs, financial
> institutions, and service providers to offer financial
> services to the world's underbanked and unbanked.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> Committee (PMC), to be known as the "Apache Fineract Project",
> be and hereby is established pursuant to Bylaws of the
> Foundation; and be it further
>
> RESOLVED, that the Apache Fineract Project be and hereby is
> responsible for the creation and maintenance of software
> related to a core banking platform that provides a reliable,
> robust, and affordable solution for entrepreneurs, financial
> institutions, and service providers to offer financial
> services to the world's underbanked and unbanked.
>
> RESOLVED, that the office of "Vice President, Apache Fineract" 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 Fineract Project, and to have primary responsibility
> for management of the projects within the scope of
> responsibility of the Apache Fineract 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 Fineract Project:
>
> * Vishwas Babu AJ <vishwasb...@apache.org>
> * Edward Cable <edca...@apache.org>
> * Markus Geiss <mage...@apache.org>
> * Sander van der Heijden <shey...@apache.org>
> * Ishan Khanna <ishan1...@apache.org>
> * Myrle Krantz <myrl...@apache.org>
> * Terence Monteiro <tere...@apache.org>
> * Adi Nayaran Raju <rajua...@apache.org>
> * Gaurav Saini <gsai...@apache.org>
> * Nazeer Hussain Shaik <naz...@apache.org>
> * Jim Jagielski <j...@apache.org>
> * Michael Vorburger <vor...@apache.org>
>
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Myrle Krantz
> be appointed to the office of Vice President, Apache Fineract, 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 Fineract 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 Fineract Project; and be it further
>
> RESOLVED, that the Apache Fineract Project be and hereby
> is tasked with the migration and rationalization of the Apache
> Incubator Fineract podling; and be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache
> Incubator Fineract podling encumbered upon the Apache Incubator
> Project are hereafter discharged.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: [VOTE] Apache Fineract podling graduation

[Niclas Hedhman]

+1 (binding)

On Tue, Mar 21, 2017 at 2:14 AM, Ross Gardler <r...@gardler.org> wrote:

> + 1 (binding)
>
> Great job Fineract team.
>
> Ross
>
> -Original Message-
> From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of
> Roman Shaposhnik
> Sent: Monday, March 20, 2017 8:12 AM
> To: general@incubator.apache.org
> Subject: Re: [VOTE] Apache Fineract podling graduation
>
> +1 (binding)
>
> Best of luck!
>
> Thanks,
> Roman.
>
> On Mon, Mar 20, 2017 at 1:38 AM, Myrle Krantz <my...@apache.org> wrote:
> > The discussion seems to have died down, so I'm calling the vote:  I
> > propose that we graduate Apache Fineract from the Incubator.  The full
> > text of the proposal is below.  The discuss thread can be found here:
> >
> >
> > [
> > https://lists.apache.org/thread.html/630d3ec22b4f72f827cd817a0a4da5c3c
> > 52dee4f96f47a1369f5dc50@%3Cgeneral.incubator.apache.org%3E
> > ]
> >
> > Thank you,
> > Myrle
> >
> >
> >
> > Resolution:
> >
> > Establish the Apache Fineract 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 data management platform that provides
> > real-time, consistent access to data-intensive applications throughout
> > widely distributed cloud architectures.
> >
> > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> > (PMC), to be known as the "Apache Fineract Project", be and hereby is
> > established pursuant to Bylaws of the Foundation; and be it further
> >
> > RESOLVED, that the Apache Fineract Project be and hereby is
> > responsible for the creation and maintenance of software related to a
> > core banking platform that provides a reliable, robust, and affordable
> > solution for entrepreneurs, financial institutions, and service
> > providers to offer financial services to the world's underbanked and
> > unbanked.
> >
> > RESOLVED, that the office of "Vice President, Apache Fineract" 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
> > Fineract Project, and to have primary responsibility for management of
> > the projects within the scope of responsibility of the Apache Fineract
> > 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 Fineract
> > Project:
> >
> > * Vishwas Babu AJ <vishwasb...@apache.org>
> > * Edward Cable <edca...@apache.org>
> > * Markus Geiss <mage...@apache.org>
> > * Sander van der Heijden <shey...@apache.org>
> > * Ishan Khanna <ishan1...@apache.org>
> > * Myrle Krantz <myrl...@apache.org>
> > * Terence Monteiro <tere...@apache.org>
> > * Adi Nayaran Raju <rajua...@apache.org>
> > * Gaurav Saini <gsai...@apache.org>
> > * Nazeer Hussain Shaik <naz...@apache.org>
> > * Jim Jagielski <j...@apache.org>
> > * Michael Vorburger <vor...@apache.org>
> >
> >
> > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Myrle Krantz be appointed
> > to the office of Vice President, Apache Fineract, 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 Fineract 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 Fineract
> > Project; and be it further
> >
> > RESOLVED, that the Apache Fineract Project be and hereby is tasked
> > with the migration and rationalization of the Apache Incubator
> > Fineract podling; and be it further
> >
> > RESOLVED, that all responsibilities pertaining to the Apache Incubator
> > Fineract podling encumbered upon the Apache Incubator Project are
> > hereafter discharged.
>
> -
> 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
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: Creating a podli...@incubator.apache.org mailing list

[Niclas Hedhman]

+1 for a podlings@ alias.

But what could you possibly want with a podlings-private@ ?  We are
expected to keep private to a minimum, typically involving individuals or
security issues, and I fail to see how that can apply to 50 or so very
disperse projects, that changes over time. So I am -1 on that, until I hear
some reasonable justification.

The pmcs@ alias is IMHO a bad alias and should be changed to go to dev@.
Way back in time, we had p...@foo.apache.org and the pmcs@ came out of that
naming. BUT, we later recognized that pmc@ was being overused. The name
invited that overuse and we changed it to private@ to signal its intent,
but pmcs@ was left behind...


Cheers
Niclas


On Tue, Mar 21, 2017 at 4:17 AM, John D. Ament <johndam...@apache.org>
wrote:

> On Mon, Mar 20, 2017 at 12:55 PM Luciano Resende <luckbr1...@gmail.com>
> wrote:
>
> > On Mon, Mar 20, 2017 at 12:00 PM John D. Ament <johndam...@apache.org>
> > wrote:
> >
> > > All,
> > >
> > > Before I go ahead with it, wanted to see if others had any opinions.
> I'm
> > > planning to ask infra to create a podlings@i.a.o mailing list, which
> > would
> > > go to all podlings dev@ list.  There may be some scenarios where we
> need
> > > to
> > > communicate out to all podlings.  For instance, the logo change and how
> > it
> > > impacts the podlings.
> > >
> > > John
> > >
> >
> > This would be more like an alias, similar to @PMCs right ? Also, in the
> > past, some of these communications would go to podling private (e.g. Gsoc
> > info) where there was a request for the podling pmc to discuss this
> > appropriately in their dev lists? That might still be a viable approach.
> >
> >
> Yes, I believe that's how infra would implement it.  It isn't meant to
> replace general@ but instead allow us a convenient way to email blast all
> podlings.
>
> As I was typing the email, I thought about private lists.  I wouldn't mind
> a podlings-private@i.a.o as well.
>
>
> > BTW, podlings, particular podling mentors should (MUST) be following all
> > pertinent general@ discussions.
> > --
> > Sent from my Mobile device
> >
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: [VOTE] Release Apache FreeMarker 2.3.26 (incubating)

[Niclas Hedhman]

+1 (binding)


On Tue, Mar 21, 2017 at 6:51 AM, Daniel Dekany <ddek...@apache.org> wrote:

> Hi all,
>
> Apache FreeMarker (incubating) is a template engine, i.e. a generic
> tool to generate text output based on templates. FreeMarker is
> implemented in Java as a class library for programmers.
>
> The Apache FreeMarker community has voted on and approved a proposal
> to release Apache FreeMarker 2.3.26-incubating.
>
> PPMC Vote Call:
> https://lists.apache.org/thread.html/a33860d7196ccdc5ec19c4ca00d152
> b95784d743995f89ad4e9acedb@%3Cdev.freemarker.apache.org%3E
>
> PPMC Vote Result:
> https://lists.apache.org/thread.html/2bf7dfa720510cf5484e0b345e6b31
> bc8c8a6933b5073d2c87902473@%3Cdev.freemarker.apache.org%3E
>
> PPMC Vote Summary:
> 2 binding (IPMC member) +1 votes
> 2 non-binding PPMC member +1 votes
> 1 non-binding Commiter +1 votes
>
> Release Notes:
> http://freemarker.org/builds/2.3.26-voting/documentation/_
> html/versions_2_3_26.html
>
> Before proceed, you should know that FreeMarker 2.3.x, for a long
> time, always releases a normal and a "gae" variant on the same time,
> which are technically two independent source trees (Git branches). The
> "gae" variant contains a few small modification in the Java source
> code to be Google App Engine compliant, and has freemarker-gae as the
> Maven artifact name. Otherwise the normal and the "gae" branches are
> identical. Hence, they are voted on together.
>
> The commits to be voted upon are:
> - Normal (non-gae) variant:
>   https://git-wip-us.apache.org/repos/asf?p=incubator-
> freemarker.git;a=commit;h=876fffcfaf66bd212b02a931fdd2c69f6e0c297e
>   Commit hash: 876fffcfaf66bd212b02a931fdd2c69f6e0c297e
> - "gae" variant:
>   https://git-wip-us.apache.org/repos/asf?p=incubator-
> freemarker.git;a=commit;h=43564859db4bec23e161c6fa5a32882e8bd9e40a
>   Commit hash: 43564859db4bec23e161c6fa5a32882e8bd9e40a
>
> The artifacts to be voted upon are located here:
> https://dist.apache.org/repos/dist/dev/incubator/freemarker/
> engine/2.3.26-incubating/source/
> where the source release artifacts are:
> - Normal (non-gae) variant:
>   apache-freemarker-2.3.26-incubating-src.tar.gz
> - "gae" variant:
>   apache-freemarker-gae-2.3.26-incubating-src.tar.gz
>
> See the README inside them for build instructions!
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/ddekany.asc
>
> Note that for convenience, we also provide binaries:
> https://dist.apache.org/repos/dist/dev/incubator/freemarker/
> engine/2.3.26-incubating/binaries/
> and Maven artifacts in the ASF staging repository:
> https://repository.apache.org/content/repositories/staging/
> org/freemarker/freemarker/2.3.26-incubating/
>
> We request the permission of the IPMC to publish the above release as
> Apache FreeMarker 2.3.26-incubating. Please try out the package and
> vote.
>
> The vote is open for a minimum of 72 hours or until the necessary number of
> votes (3 binding +1s) is reached.
>
> [ ] +1 Release this package as Apache FreeMarker 2.3.26-incubating
> [ ]  0 I don't feel strongly about it, but I'm okay with the release
> [ ] -1 Do not release this package because...
>
> Please add "(binding)" if your vote is binding.
>
> --
> Thanks,
>  Daniel Dekany
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: New Incubator Logo Selection Results

[Niclas Hedhman]

I don't think the ASF and the incubator logo should be placed side-by-side
like that (2)

http://incubator.staging.apache.org/


On Sat, Mar 18, 2017 at 8:53 AM, John D. Ament <johndam...@apache.org>
wrote:

> Yeah, sorry about that.  Was going to send out more direct links when I had
> the website updates almost ready.  Anyways here they are.
>
> 1. The new logo, in a more web-ready format:
> http://incubator.staging.apache.org/images/incubator_feather
> _egg_logo_sm.png
> 2. An example of the new header - http://incubator.staging.apache.org/
>
> I'm worried that its a bit busy.  thoughts?
>
> John
>
> On Fri, Mar 17, 2017 at 8:31 PM Julian Hyde <jh...@apache.org> wrote:
>
> > I had to click on a few links to actually see the logo. To save y’all
> some
> > clicking, here’s the logo:
> >
> >
> > http://svn.apache.org/viewvc/incubator/public/trunk/content/
> images/apache_incubator_logo.png?view=co=text%2Fplain
> > <
> > http://svn.apache.org/viewvc/incubator/public/trunk/content/
> images/apache_incubator_logo.png?view=co=text/plain
> > >
> >
> >
> > http://svn.apache.org/viewvc/incubator/public/trunk/content/
> images/incbuator_feather_egg_logo.jpg?view=co=text%2Fplain
> > <
> > http://svn.apache.org/viewvc/incubator/public/trunk/content/
> images/incbuator_feather_egg_logo.jpg?view=co=text/plain
> > >
> >
> > Julian
> >
> >
> > > On Mar 17, 2017, at 5:03 PM, John D. Ament <johndam...@apache.org>
> > wrote:
> > >
> > > Dear Apache Incubator PMC,
> > >
> > > On behalf of the Apache Incubator PMC logo selection committee it is
> our
> > > pleasure to announce the new logo.
> > >
> > > This selection was chosen from results collected on the mailing list
> with
> > > minor cosmetic alterations. All submissions for the new logo were of
> > great
> > > quality and it was a tough decision to choose just one. Though we do
> feel
> > > that this design has great symbolic representation with the incubator
> and
> > > builds upon the previous logo.
> > >
> > > The committee also requested an alternate design for specific cases
> where
> > > gradients are not preferred. This design could be used on printed
> > documents
> > > where gradients do not always print well; black and white versions have
> > > also been made. You can expect all versions in a range of formats (svg,
> > > pdf, png) to be available in the coming weeks.
> > >
> > > In order to aid the transition from the old design to the new, a
> > collection
> > > of examples for the “powered by” format will be made available as the
> PMC
> > > will require projects to retire old forms of these logos. We would like
> > to
> > > see all incubating projects updated to use the new logos by the end of
> > June
> > > at the latest. The PMC will use the incubating reports as a method to
> > track
> > > which projects are compliant.
> > >
> > > We hope that the PMC is happy with the choice of the committee and
> would
> > > like to thank the designers for submitting some excellent designs.
> > >
> > > As of when this is being sent, all assets provided by the artist + one
> > > addition from John to update our twitter logo have been committed to
> SVN
> > > and published to our website.  The commit with the information for the
> > > locations of the graphics can be found at
> > >
> > https://lists.apache.org/thread.html/fa8c714d9a7fc45f23cf48a
> 7fdbab3f751dc857835df6ca512197e7b@%3Ccvs.incubator.apache.org%3E
> > >
> > >
> > > Regards,
> > > Apache Incubator Logo Selection Committee
> >
> >
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: [VOTE] Graduate Apache CarbonData Project from the Incubator

[Niclas Hedhman]

+1 (binding)

On Wed, Mar 15, 2017 at 8:39 PM, Jean-Baptiste Onofré <j...@nanthrax.net>
wrote:

> Hi IPMC,
>
> Following the previous discussion, please vote on the draft resolution
> proposed by the Apache CarbonData PPMC below, which establishes Apache
> CarbonData as a new top-level project at the Apache Software Foundation, as
> follows:
>
> [ ] +1, Graduate Apache CarbonData from the Incubator.
> [ ] +0, Don't care.
> [ ] -1, Don't graduate Apache CarbonData from the Incubator (provide
> details)
>
> The full text of the resolution is bellow.
>
> If approved by the Apache Incubator PMC members, the proposed resolution
> will be submitted to the Board of Directors for their consideration.
>
> Thanks !
>
> Regards
> JB
>
> The full-text of the draft resolution proposed by the Apache CarbonData
> PPMC:
>
>  X. Establish the Apache CarbonData 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 an indexed columnar data format
>for fast analytics on big data platform.
>
>NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>Committee (PMC), to be known as the "Apache CarbonData Project",
>be and hereby is established pursuant to Bylaws of the
>Foundation; and be it further
>
>RESOLVED, that the Apache CarbonData 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 CarbonData"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 CarbonData Project, and to have primary responsibility
>for management of the projects within the scope of
>responsibility of the Apache CarbonData 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 CarbonData Project:
>
> * Liang Chen <chenliang...@apache.org>
> * Jean-Baptiste Onofré <jbono...@apache.org>
> * Henry Saputra <hsapu...@apache.org>
> * Uma Maheswara Rao G <umamah...@apache.org>
> * Jenny MA <jihon...@apache.org>
> * Jacky Li <jack...@apache.org>
> * Vimal Das Kammath <vimal...@apache.org>
> * Jarray Qiu <jarray...@apache.org>
>
>NOW, THEREFORE, BE IT FURTHER RESOLVED, that Liang Chen be
>appointed to the office of Vice President, Apache CarbonData, 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 CarbonData 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 CarbonData Project; and be it further
>
>RESOLVED, that the Apache CarbonData Project be and hereby
>is tasked with the migration and rationalization of the Apache
>Incubator CarbonData podling; and be it further
>
>RESOLVED, that all responsibilities pertaining to the Apache
>Incubator CarbonData podling encumbered upon the Apache Incubator
>Project are hereafter discharged.
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: [DISCUSS] Apache CarbonData podling graduation

[Niclas Hedhman]

I think the wording needs tuning, and my own interpretation of the intent
has been,

Project claims itself to comply, and list any exceptions and why that is
the case.

I think that can deal with the invariance that exists.

Cheers
Niclas


On Mar 7, 2017 14:48, "Jim Apple"  wrote:

> > Actually, the Maturity Model can be a very nice framework to organize
> > incubation around.
>
> If you're talking about a platonic MM, then I agree. If you are
> talking about the MM at
> https://community.apache.org/apache-way/apache-project-maturity-model.html
> ,
> I think it needs to be much more carefully written and much more
> accurate to be a "nice framework". In particular, "aims to capture the
> invariants of Apache projects ... A mature Apache project complies
> with all the elements of this model" is wishful thinking or outdated
> or both.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: GitHub workflows?

[Niclas Hedhman]

Thanks Marvin for the pointers.
But my question is not so much whether we can accept pull requests or
handle GH issues. It is whether it is ok to be the *primary* workflow and
dev@ is an archive.

The podling is coming from a GitHub-only culture, and the core team in the
same company. S...

1. I think all development is pull requests, whether it is from committers
or external contributors. I.e. RTC. Hard to tell external from internal
patches, so to speak

2. the dev@ list receives all the Issue comments and pull requests.

3. A somewhat large number (300) of open GH issues are on the old GH
repository, brought over selectively, seemingly along with the work that
goes with them (but I could be wrong here).

3. Some decision-making is _likely_ happening face-to-face.

The overall effect is that if you are used to ASF projects, this podling
feels very different than most other projects here. dev@ is a cold place at
the moment, and I don't like it. A bit like some projects have tried to do
(nearly) "JIRA only" discussions, which I also found somewhat "off-putting".

Anyway, I will continue to nudge them in the "common direction" and shout
again if I feel there is a problem.

Cheers
Niclas



On Tue, Mar 7, 2017 at 2:23 PM, Greg Stein <gst...@gmail.com> wrote:

> On Mon, Mar 6, 2017 at 11:34 PM, Marvin Humphrey <mar...@rectangular.com>
> wrote:
> >...
>
> > So, the questions I would ask are, are all those comments making it to
> the
> > list?  And are the podling participants showing through their actions
> that
> > they understand inclusiveness, by ensuring that dev list readers are able
> > to
> > follow along?
> >
>
> Pull requests and issues, and the comments upon them are all delivered to
> an archived PMC mailing list. These tend to go to dev@, issues@, or
> notifications@ ... as a PMC chooses.
>
> I checked with Legal, and we are required to forward this stuff to a list.
>
>
> > For what it's worth, on one dev list I'm on, pull requests make it to the
> > dev
> > list, but commenting on a commit via the Github interface only triggers a
> > private notification -- the comment never makes it to our dev list.  We
> > mostly
> > avoid Github commit comments for that reason, so inclusiveness is not
> > harmed
> > -- but people new to Apache might not handle things that way.
> >
>
> We can forward those, if you want. Probably should.
>
> Cheers,
> -g
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: Wiki Karma

[Niclas Hedhman]

Yes on both accounts.

Thanks

On Mon, Mar 6, 2017 at 7:29 PM, John D. Ament <johndam...@apache.org> wrote:

> I added Jinjiang Zhao, guessing at a username.  Is that the actua username?
> Also, is your username "niclas"?
>
> On Mon, Mar 6, 2017 at 12:02 AM Niclas Hedhman <nic...@hedhman.org> wrote:
>
> > Gang,
> > can I have karma to add users to the https://wiki.apache.org/incubator ?
> >
> > If I already do, then I lack the knowledge of how to do it...
> >
> > If I can't have it, then please add Jinjiang Zhao (zhaojinji...@me.com)
> to
> > be able to edit Podling reports page.
> >
> >
> > Thanks
> > --
> > Niclas Hedhman, Software Developer
> > http://polygene.apache.org <http://zest.apache.org> - New Energy for
> Java
> >
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Wiki Karma

[Niclas Hedhman]

Gang,
can I have karma to add users to the https://wiki.apache.org/incubator ?

If I already do, then I lack the knowledge of how to do it...

If I can't have it, then please add Jinjiang Zhao (zhaojinji...@me.com) to
be able to edit Podling reports page.


Thanks
-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: GitHub workflows?

[Niclas Hedhman]

Thanks Daniel, I should have thought of that, since that is how I noticed
it.

So, then the question should have been;

Are we ok with podlings using GH "Issues" instead of ASF-hosted issue
tracker?

Are we ok that discussions happen on pull requests and commits?


I am a little bit uneasy about it, but does the Incubator as a whole have
an opinion/resolution on it?


Cheers
Niclas

On Mon, Mar 6, 2017 at 11:58 AM, Daniel Gruno <humbed...@apache.org> wrote:

> On 03/06/2017 04:56 AM, Niclas Hedhman wrote:
> > Everyone,
> > I need to get an understanding of the use of GitHub workflows on Apache
> > projects.
> >
> > In GH, it is possible to comment on commits and pull requests. Are those
> > captured by infra@ and replicated somewhere, or is this "lost data" (I
> > suspect) in case GitHub goes out of business?
>
> Pull requests and issues are relayed back to the projects' mailing
> list(s) automatically. Check, for instance,
> https://lists.apache.org/list.html?iss...@trafficserver.apache.org
>
> >
> > Cheers
> >
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

GitHub workflows?

[Niclas Hedhman]

Everyone,
I need to get an understanding of the use of GitHub workflows on Apache
projects.

In GH, it is possible to comment on commits and pull requests. Are those
captured by infra@ and replicated somewhere, or is this "lost data" (I
suspect) in case GitHub goes out of business?

Cheers
-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: [RESULT] New Incubator Logo - Public Vote

[Niclas Hedhman]

Are all these Apache marks, or are they (like everything on Jira unless
otherwise noted) ALv2 licensed ??

Cheers
Niclas

On Wed, Mar 1, 2017 at 9:04 AM, John D. Ament <johndam...@apache.org> wrote:

> All,
>
> Below are the summed results for the incubator logo vote.  Items that do
> not appear received 0 votes.
>
> https://s.apache.org/INCUBATOR-189 21
> https://s.apache.org/INCUBATOR-149 18
> https://s.apache.org/INCUBATOR-147 16
> https://s.apache.org/INCUBATOR-197 15
> https://s.apache.org/INCUBATOR-163 15
> https://s.apache.org/INCUBATOR-161 12
> https://s.apache.org/INCUBATOR-191 10
> https://s.apache.org/INCUBATOR-176 10
> https://s.apache.org/INCUBATOR-196 9
> https://s.apache.org/INCUBATOR-158 9
> https://s.apache.org/INCUBATOR-186 8
> https://s.apache.org/INCUBATOR-183 8
> https://s.apache.org/INCUBATOR-148 8
> https://s.apache.org/INCUBATOR-177 7
> https://s.apache.org/INCUBATOR-174 7
> https://s.apache.org/INCUBATOR-154 7
> https://s.apache.org/INCUBATOR-187 6
> https://s.apache.org/INCUBATOR-182 6
> https://s.apache.org/INCUBATOR-175 6
> https://s.apache.org/INCUBATOR-188 5
> https://s.apache.org/INCUBATOR-172 5
> https://s.apache.org/INCUBATOR-160 5
> https://s.apache.org/INCUBATOR-159 5
> https://s.apache.org/INCUBATOR-195 4
> https://s.apache.org/INCUBATOR-166 4
> https://s.apache.org/INCUBATOR-157 4
> https://s.apache.org/INCUBATOR-152 4
> https://s.apache.org/INCUBATOR-150 4
> https://s.apache.org/INCUBATOR-193 3
> https://s.apache.org/INCUBATOR-190 3
> https://s.apache.org/INCUBATOR-168 3
> https://s.apache.org/INCUBATOR-164 3
> https://s.apache.org/INCUBATOR-192 2
> https://s.apache.org/INCUBATOR-185 2
> https://s.apache.org/INCUBATOR-181 2
> https://s.apache.org/INCUBATOR-179 2
> https://s.apache.org/INCUBATOR-178 2
> https://s.apache.org/INCUBATOR-173 2
> https://s.apache.org/INCUBATOR-167 2
> https://s.apache.org/INCUBATOR-155 2
> https://s.apache.org/INCUBATOR-194 1
> https://s.apache.org/INCUBATOR-184 1
> https://s.apache.org/INCUBATOR-169 1
> https://s.apache.org/INCUBATOR-165 1
> https://s.apache.org/INCUBATOR-153 1
> https://s.apache.org/INCUBATOR-151 1
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: [IP CLEARANCE] Software grant for Ratis (incubating)

[Niclas Hedhman]

All,
the Board approved Apache Zest (now Polygene) to go straight to TLP about 2
years ago. Part of the decision was the question; "What benefit will
incubation have for the community?", and since we had exclusively Apache
members on the initial project, operated with an ASF mindset before coming
to ASF, we had no good answer for that particular question. Follow up on
that was to have a "provisional TLP" (proposed by Greg Stein, I think), a
self-inflected restriction, and the Board asked "What benefit for the
project does that bring?".

I think more projects have done this since then, but not sure...

So, end of the day; Place a Resolution in front of the Board, accompanied
(a priori) with motivation why incubation is not beneficial to the
community, and you have a good shot at go straight to TLP.

HTH
Niclas

On Sat, Feb 25, 2017 at 1:57 PM, Alex Harui <aha...@adobe.com> wrote:

>
>
> On 2/24/17, 4:40 PM, "Enis Söztutar" <e...@apache.org> wrote:
> >
> >On a separate note, I wish there was a fast-track for these kind of
> >projects which can start internally in Apache without too much of a
> >hassle.
>
> Check the archives for "Straight to TLP" discussions.  I thought it was
> possible these days.
>
> -Alex
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: Podling Graduation Rally

[Niclas Hedhman]

I haven't followed this issue, but if we take BSD licensed source and
modifies it (enough to claim copyright on the modifications) we re-license
to ALv2, but leaves the original BSD headers (if any) in the source.

CatA licenses are CatA because they allow modifications on source and
re-license...

Niclas

On Feb 20, 2017 04:12, "John D. Ament"  wrote:

> On Sun, Feb 19, 2017 at 3:08 PM Roman Shaposhnik 
> wrote:
>
> > On Sun, Feb 19, 2017 at 5:43 AM, John D. Ament 
> > wrote:
> > > I'm personally still concerned about MADLib's licensing status.
> > > Specifically speaking, where I feel more info is needed around
> > > modifications to the BSD licensed code.  None of that was in the legal
> > > resolution.
> >
> > Can you please suggest how can this be resolved? I've stated my opinion,
> > others stated theirs -- but how do we arrive at a either a consensus or
> > a resolution? What's a mechanism here?
> >
>
> Was there a clear statement on the code modifications?  Last I saw, there
> was an agreement for the imported code, but I thought I saw something
> saying the modifications were apache licensed, which is confusing in the
> current state.
>
> Either way, lets move this to legal discuss.
>
>
> >
> > Thanks,
> > Roman.
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: Consult License Compatible Issue

[Niclas Hedhman]

Yukon,
Cat-B means that your project is allowed to have a compile/runtime
dependency on an unmodified version of that, but you are NOT allowed to
include the source code, modified or not, into your project. The reason (at
least in many cases) is that there are reciprocity in these licenses, such
that if you make a change you must release that change under the same
license or that modifications must be contributed back.

HTH
NIclas

On Fri, Feb 10, 2017 at 9:19 PM, yukon <yu...@apache.org> wrote:

> Hi,
>
> I found EPL 1.0 in https://www.apache.org/legal/resolved#category-b, and
> it
> says that `Software under the category-b licenses may be included in binary
> form within an Apache product if the inclusion is appropriately labeled`.
>
> I wonder that could we include the EPL 1.0 software(like logback[1]) in
> Apache product sources?
>
> [1]. https://logback.qos.ch/license.html
>
> I would appreciate your help.
>
> Regards,
> yukon
>
> On Fri, Feb 10, 2017 at 7:43 PM, yukon <yu...@apache.org> wrote:
>
> > Got it, thanks Tom and Ross.
> >
> > Regards,
> > yukon
> >
> > On Fri, Feb 10, 2017 at 6:42 PM, Ross Gardler <r...@gardler.org> wrote:
> >
> >> Less of a compatible/incompatible list, more of an Apache Policy with
> >> respect to allowable licenses in ASF software...
> >> http://www.apache.org/legal/resolved.html
> >>
> >> -Original Message-
> >> From: yukon [mailto:yu...@apache.org]
> >> Sent: Friday, February 10, 2017 2:21 AM
> >> To: general@incubator.apache.org
> >> Subject: Consult License Compatible Issue
> >>
> >> Hi IPMC,
> >>
> >> Is there a uncompatible license list with ASL2?
> >>
> >> Regards,
> >> yukon
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >>
> >
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: [VOTE] Release apache-singa-incubating-1.1.0 (RC1)

[Niclas Hedhman]

https://github.com/google/glog/blob/master/COPYING

On Mon, Feb 6, 2017 at 7:44 PM, John D. Ament <johndam...@apache.org> wrote:

> Niclas,
>
> So I'll point out a couple of things.
>
> 1. -1's on releases aren't vetos, so if someone else (e.g. you) voted a +1
> my -1 would be moot.
>
> 2. I mentioned in my response that the main issue is that I can't find a
> listed license for glog and I was choosing GPL because I found a source
> file with a GPL header.  If the first file I looked at was another license,
> I would have assumed that license.  It has nothing to do with build chain.
> If you have a link that can show that glog is BSD licensed, that would
> settle this.  Note that this issue [1] exists.
>
> John
>
> [1]: https://github.com/google/glog/issues/118
>
>
> On Mon, Feb 6, 2017 at 12:04 AM Niclas Hedhman <nic...@hedhman.org> wrote:
>
> > Sure, but in this case it is;
> >   1. Singa depends on Glog
> >   2. Glog is BSD licensed
> >   3. Glog use a build tool chain that is GPL'd and includes a build
> script
> > to compensate for missing toolchain tools.
> >   4. Singa doesn't use Glog's build toolchain
> >
> > Your (John) argument is that Glog is incorrectly licensed and should have
> > been GPL'd. I think that reasoning is incorrect, and that Glog is
> licensed
> > correctly and hence it is not relevant whether it is optional or not for
> > Singa.
> >
> > Given that we have both belt and suspenders for this, I think the -1 can
> be
> > withdrawn regarding the Glog dependency.
> >
> > Cheers
> > Niclas
> >
> > On Mon, Feb 6, 2017 at 10:49 AM, John D. Ament <johndam...@apache.org>
> > wrote:
> >
> > > We actually just had a discussion recently on legal-discuss on this
> type
> > of
> > > topic.  Specifically, Cat-X and optional vs required dependencies.
> Henri
> > > and I settled on the wording you'll find at [1] as the final result.
> > > Basically, you can rely on Cat-X but only for optional features.
> > >
> > > We can probably follow up with legal on whether this does fall into the
> > GPL
> > > bucket though.
> > >
> > > John
> > >
> > > [1]: https://www.apache.org/legal/resolved.html#optional
> > >
> > > On Sun, Feb 5, 2017 at 9:45 PM Niclas Hedhman <nic...@hedhman.org>
> > wrote:
> > >
> > > > I think that ends up being a build time dependency in GLOG, i.e. the
> > > > equivalent of Systems Requirement, and not in itself viral to the ASF
> > > > software. I assume that Google is much more worried about this and
> may
> > > even
> > > > have checked with their Legal team...
> > > >
> > > > Want to check with legal-discuss@ ? Is my memory failing me, or
> hasn't
> > > FSF
> > > > stated that the build output is not bound by GPL of the build
> > toolchain?
> > > > (otherwise they can't release their own LGPL stuff)
> > > >
> > > > Cheers
> > > > Niclas
> > > >
> > > > On Mon, Feb 6, 2017 at 10:27 AM, John D. Ament <
> johndam...@apache.org>
> > > > wrote:
> > > >
> > > > > -1 at least I think there's an issue.
> > > > >
> > > > > While the source code all looks good, the resulting binary is not
> > > valid.
> > > > > There's no how to build doc, so I looked at your .travis.yml.  It
> > > > confirmed
> > > > > what I suspected for make, but then I started looking at your
> > required
> > > > > packages.
> > > > >
> > > > > You require glog [1], which I can't find a license for.  However,
> > glog
> > > > > includes [2] which is GPL, which makes glog GPL and as a result,
> your
> > > > code.
> > > > >
> > > > > [1]: https://github.com/google/glog
> > > > > [2]: https://github.com/google/glog/blob/master/missing
> > > > >
> > > > > - John
> > > > >
> > > > > On Sun, Jan 29, 2017 at 8:24 PM Wang Wei <wang...@apache.org>
> wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > The SINGA community has voted on and approved a proposal to
> release
> > > > > Apache
> > > > > > SINGA 1.1.0 (incubating).
> > > > > >
> > > > > > The vote thread is at:
> > > > > > http:/

Re: [jira] [Created] (INCUBATOR-171) Submission: Anonymous-21

[Niclas Hedhman]

OTOH, Sally has now managed to post 20-25% of ALL Incubator issues of ALL
time... *Sigh*

On Mon, Feb 6, 2017 at 8:18 PM, Carlos Santana <csantan...@gmail.com> wrote:

> Thank Hedhman for letting me know, I recently join the list sonI was not
> sure.
>
> Sounds good with me then.
>
> - Carlos Santana
> @csantanapr
>
> > On Feb 5, 2017, at 9:33 PM, Niclas Hedhman <nic...@hedhman.org> wrote:
> >
> > I think it was said to be ok, as the total number of issues in Incubator
> > project itself is quite small. The current "flood" related to a new logo
> is
> > not "normal".
> >
> > On Sun, Feb 5, 2017 at 10:22 PM, Carlos Santana <csantan...@gmail.com>
> > wrote:
> >
> >> Is this normal to get all this issues notifications from JIRA to the
> >> general@ list instead of a issues@ mailing list?
> >>
> >> Makes it hard to keep up with the general@ list.
> >>
> >> Just curious to know and providing feedback
> >>
> >> - Carlos Santana
> >> @csantanapr
> >>
> >>> On Feb 5, 2017, at 9:19 AM, Sally Khudairi (JIRA) <j...@apache.org>
> >> wrote:
> >>>
> >>> Sally Khudairi created INCUBATOR-171:
> >>> 
> >>>
> >>>Summary: Submission: Anonymous-21
> >>>Key: INCUBATOR-171
> >>>URL: https://issues.apache.org/
> jira/browse/INCUBATOR-171
> >>>Project: Incubator
> >>> Issue Type: Task
> >>> Components: LogoSubmission
> >>>   Reporter: Sally Khudairi
> >>>Attachments: Anonymous-21.png
> >>>
> >>> Submission for Anonymous-21
> >>>
> >>>
> >>>
> >>> --
> >>> This message was sent by Atlassian JIRA
> >>> (v6.3.15#6346)
> >>>
> >>> -
> >>> 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
> >>
> >>
> >
> >
> > --
> > Niclas Hedhman, Software Developer
> > http://polygene.apache.org <http://zest.apache.org> - New Energy for
> Java
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: [VOTE] Release apache-singa-incubating-1.1.0 (RC1)

[Niclas Hedhman]

Sure, but in this case it is;
  1. Singa depends on Glog
  2. Glog is BSD licensed
  3. Glog use a build tool chain that is GPL'd and includes a build script
to compensate for missing toolchain tools.
  4. Singa doesn't use Glog's build toolchain

Your (John) argument is that Glog is incorrectly licensed and should have
been GPL'd. I think that reasoning is incorrect, and that Glog is licensed
correctly and hence it is not relevant whether it is optional or not for
Singa.

Given that we have both belt and suspenders for this, I think the -1 can be
withdrawn regarding the Glog dependency.

Cheers
Niclas

On Mon, Feb 6, 2017 at 10:49 AM, John D. Ament <johndam...@apache.org>
wrote:

> We actually just had a discussion recently on legal-discuss on this type of
> topic.  Specifically, Cat-X and optional vs required dependencies.  Henri
> and I settled on the wording you'll find at [1] as the final result.
> Basically, you can rely on Cat-X but only for optional features.
>
> We can probably follow up with legal on whether this does fall into the GPL
> bucket though.
>
> John
>
> [1]: https://www.apache.org/legal/resolved.html#optional
>
> On Sun, Feb 5, 2017 at 9:45 PM Niclas Hedhman <nic...@hedhman.org> wrote:
>
> > I think that ends up being a build time dependency in GLOG, i.e. the
> > equivalent of Systems Requirement, and not in itself viral to the ASF
> > software. I assume that Google is much more worried about this and may
> even
> > have checked with their Legal team...
> >
> > Want to check with legal-discuss@ ? Is my memory failing me, or hasn't
> FSF
> > stated that the build output is not bound by GPL of the build toolchain?
> > (otherwise they can't release their own LGPL stuff)
> >
> > Cheers
> > Niclas
> >
> > On Mon, Feb 6, 2017 at 10:27 AM, John D. Ament <johndam...@apache.org>
> > wrote:
> >
> > > -1 at least I think there's an issue.
> > >
> > > While the source code all looks good, the resulting binary is not
> valid.
> > > There's no how to build doc, so I looked at your .travis.yml.  It
> > confirmed
> > > what I suspected for make, but then I started looking at your required
> > > packages.
> > >
> > > You require glog [1], which I can't find a license for.  However, glog
> > > includes [2] which is GPL, which makes glog GPL and as a result, your
> > code.
> > >
> > > [1]: https://github.com/google/glog
> > > [2]: https://github.com/google/glog/blob/master/missing
> > >
> > > - John
> > >
> > > On Sun, Jan 29, 2017 at 8:24 PM Wang Wei <wang...@apache.org> wrote:
> > >
> > > > Hi all,
> > > >
> > > > The SINGA community has voted on and approved a proposal to release
> > > Apache
> > > > SINGA 1.1.0 (incubating).
> > > >
> > > > The vote thread is at:
> > > > http://mail-archives.apache.org/mod_mbox/singa-dev/201701.mbox/%
> > > > 3CCAJz0iLvAaEd5AgCqaWFD1M4-D_3EBh%3DUHbeZu-MRn%3DcKuQiX-Q%4
> > > 0mail.gmail.com
> > > > %3E
> > > >
> > > > and the result is at:
> > > >
> > > > http://mail-archives.apache.org/mod_mbox/singa-dev/201701.mbox/%
> > > 3ccajz0ilspborscstawuraowwetidb4cn14ak5sgdyb8umxoj...@mail.gmail.com
> %3e
> > > >
> > > > We ask the IPMC to vote on this release.
> > > >
> > > > The artifacts to be voted on are located here:
> > > > https://dist.apache.org/repos/dist/dev/incubator/singa/1.1.0/
> > > >
> > > > The hashes of the artifacts are as follows:
> > > > MD5:  08 CA 31 10 4E 79 02 16  A1 D7 3F 20 2D 60 21 BB
> > > >
> > > > Release artifacts are signed with the following key:
> > > > https://people.apache.org/keys/committer/dinhtta.asc
> > > >
> > > > and the signature file is:
> > > > https://dist.apache.org/repos/dist/dev/incubator/singa/1.1.0
> > > > /apache-singa-incubating-1.1.0-RC1.tar.gz.asc
> > > >
> > > > The Github tag is at:
> > > > https://github.com/apache/incubator-singa/releases/tag/v1.1.0-rc1
> > > > commit ID is: 59ca44a7ce38ce4f965511c805cda074d0b8e360
> > > >
> > > > To check the license, you can use the Apache Rat tool as follows:
> > > > 1. download & decompress apache rat from
> > http://creadur.apache.org/rat/
> > > > download_rat.cgi
> > > > 2. run the following command under singa folder:
> > > > java -jar /PATH/TO/RAT/apache-rat-0.11.jar -E rat-excludes -d .
> >
> > > > rat_check
> > > > 3. check the results in file named "rat_check"
> > > >
> > > > Please check and vote on releasing this package. The vote is open for
> > at
> > > > least 72 hours and passes if a majority of at least three +1 votes
> are
> > > > cast.
> > > >
> > > > [ ] +1 Release this package as Apache SINGA 1.0.0-incubating
> > > > [ ]  0 I don't feel strongly about it, but I'm okay with the release
> > > > [ ] -1 Do not release this package because...
> > > >
> > > > Best,
> > > > Wei
> > > >
> > >
> >
> >
> >
> > --
> > Niclas Hedhman, Software Developer
> > http://polygene.apache.org <http://zest.apache.org> - New Energy for
> Java
> >
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: [VOTE] Release apache-singa-incubating-1.1.0 (RC1)

[Niclas Hedhman]

I think that ends up being a build time dependency in GLOG, i.e. the
equivalent of Systems Requirement, and not in itself viral to the ASF
software. I assume that Google is much more worried about this and may even
have checked with their Legal team...

Want to check with legal-discuss@ ? Is my memory failing me, or hasn't FSF
stated that the build output is not bound by GPL of the build toolchain?
(otherwise they can't release their own LGPL stuff)

Cheers
Niclas

On Mon, Feb 6, 2017 at 10:27 AM, John D. Ament <johndam...@apache.org>
wrote:

> -1 at least I think there's an issue.
>
> While the source code all looks good, the resulting binary is not valid.
> There's no how to build doc, so I looked at your .travis.yml.  It confirmed
> what I suspected for make, but then I started looking at your required
> packages.
>
> You require glog [1], which I can't find a license for.  However, glog
> includes [2] which is GPL, which makes glog GPL and as a result, your code.
>
> [1]: https://github.com/google/glog
> [2]: https://github.com/google/glog/blob/master/missing
>
> - John
>
> On Sun, Jan 29, 2017 at 8:24 PM Wang Wei <wang...@apache.org> wrote:
>
> > Hi all,
> >
> > The SINGA community has voted on and approved a proposal to release
> Apache
> > SINGA 1.1.0 (incubating).
> >
> > The vote thread is at:
> > http://mail-archives.apache.org/mod_mbox/singa-dev/201701.mbox/%
> > 3CCAJz0iLvAaEd5AgCqaWFD1M4-D_3EBh%3DUHbeZu-MRn%3DcKuQiX-Q%4
> 0mail.gmail.com
> > %3E
> >
> > and the result is at:
> >
> > http://mail-archives.apache.org/mod_mbox/singa-dev/201701.mbox/%
> 3ccajz0ilspborscstawuraowwetidb4cn14ak5sgdyb8umxoj...@mail.gmail.com%3e
> >
> > We ask the IPMC to vote on this release.
> >
> > The artifacts to be voted on are located here:
> > https://dist.apache.org/repos/dist/dev/incubator/singa/1.1.0/
> >
> > The hashes of the artifacts are as follows:
> > MD5:  08 CA 31 10 4E 79 02 16  A1 D7 3F 20 2D 60 21 BB
> >
> > Release artifacts are signed with the following key:
> > https://people.apache.org/keys/committer/dinhtta.asc
> >
> > and the signature file is:
> > https://dist.apache.org/repos/dist/dev/incubator/singa/1.1.0
> > /apache-singa-incubating-1.1.0-RC1.tar.gz.asc
> >
> > The Github tag is at:
> > https://github.com/apache/incubator-singa/releases/tag/v1.1.0-rc1
> > commit ID is: 59ca44a7ce38ce4f965511c805cda074d0b8e360
> >
> > To check the license, you can use the Apache Rat tool as follows:
> > 1. download & decompress apache rat from http://creadur.apache.org/rat/
> > download_rat.cgi
> > 2. run the following command under singa folder:
> > java -jar /PATH/TO/RAT/apache-rat-0.11.jar -E rat-excludes -d . >
> > rat_check
> > 3. check the results in file named "rat_check"
> >
> > Please check and vote on releasing this package. The vote is open for at
> > least 72 hours and passes if a majority of at least three +1 votes are
> > cast.
> >
> > [ ] +1 Release this package as Apache SINGA 1.0.0-incubating
> > [ ]  0 I don't feel strongly about it, but I'm okay with the release
> > [ ] -1 Do not release this package because...
> >
> > Best,
> > Wei
> >
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: [jira] [Created] (INCUBATOR-171) Submission: Anonymous-21

[Niclas Hedhman]

I think it was said to be ok, as the total number of issues in Incubator
project itself is quite small. The current "flood" related to a new logo is
not "normal".

On Sun, Feb 5, 2017 at 10:22 PM, Carlos Santana <csantan...@gmail.com>
wrote:

> Is this normal to get all this issues notifications from JIRA to the
> general@ list instead of a issues@ mailing list?
>
> Makes it hard to keep up with the general@ list.
>
> Just curious to know and providing feedback
>
> - Carlos Santana
> @csantanapr
>
> > On Feb 5, 2017, at 9:19 AM, Sally Khudairi (JIRA) <j...@apache.org>
> wrote:
> >
> > Sally Khudairi created INCUBATOR-171:
> > 
> >
> > Summary: Submission: Anonymous-21
> > Key: INCUBATOR-171
> > URL: https://issues.apache.org/jira/browse/INCUBATOR-171
> > Project: Incubator
> >  Issue Type: Task
> >  Components: LogoSubmission
> >Reporter: Sally Khudairi
> > Attachments: Anonymous-21.png
> >
> > Submission for Anonymous-21
> >
> >
> >
> > --
> > This message was sent by Atlassian JIRA
> > (v6.3.15#6346)
> >
> > -
> > 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
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: Logos

[Niclas Hedhman]

I think there are several strong candidates in the list. Thanks to whoever
made them all.

On Sun, Feb 5, 2017 at 1:15 AM, Sally Khudairi <s...@apache.org> wrote:

> Thanks, John.
> Actually, I was hoping we'd be able to have an open period for the public
> to voice their opinion prior to the selection committee.
> Per the timeframe:
>  - 20 Feb --call for entries closes - 27 Feb --voting ends (this would be
> the public vote) - 13 Mar --announce winning design (this would be after
> the selection committee reviews and picks the winner) - 3 April --winning
> logo rollout (after we'd work with the winning designer to make any
> adjustments/tweaks as needed)
> Does that make sense? Does this work for you?
> Cheers,Sally = = = = =  vox +1 617 921 8656gvox +1 646 598 4616skype
> sallykhudairi
>
>   From: John D. Ament <johndam...@apache.org>
>  To: general@incubator.apache.org
> Cc: Sally Khudairi <s...@apache.org>
>  Sent: Saturday, February 4, 2017 12:08 PM
>  Subject: Re: Logos
>
> I think the idea we were throwing around was setting up a selection
> committee + a steve vote.
>
> On Sat, Feb 4, 2017 at 11:51 AM Niclas Hedhman <nic...@hedhman.org> wrote:
>
> Are we supposed to vote as a comment on Jira, or?
>
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org <http://zest.apache.org> - New Energy for Java
>
>
>
>
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Logos

[Niclas Hedhman]

Are we supposed to vote as a comment on Jira, or?

-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: [DISCUSS] new incubator project Apache IOT

[Niclas Hedhman]

Edward,
you might not be aware that the Incubator is not a place to "start" new
projects from scratch, but to educate communities in the Apache Way of
operating as sustainable communities. We accept existing communities with
existing projects...

That said; I generally agree with your "ambition" and I agree with Roman
that MyNewt is probably the best home right now for this, so I suggest that
"we, the interested people" head over to d...@mynewt.apache.org and see if
we can carve out a small sandbox and start doing some work. If that turns
out well, and IF mynewt.apache.org is not a natural home, then we could
spin out of MyNewt. I know Justin is also heavily invested in the space, so
should be possible to get a ball rolling.


Cheers
Niclas

On Wed, Feb 1, 2017 at 2:44 AM, Edward Capriolo <edlinuxg...@gmail.com>
wrote:

> On Tue, Jan 31, 2017 at 11:40 AM, <dav...@apache.org> wrote:
>
> > Hi all,
> >
> > Sounds quite interesting :) It might also be an idea to provide a home
> for
> > implementations of other hardware that can drive GPIO pins and can
> control
> > similar sensors and other devices. I'm thinking of an Arduino, or
> something
> > like an ESP8266. These are devices that are much simpler (and cheaper)
> than
> > a Raspberry Pi, but if you are just building a sensor or a simple switch
> > they are often quite useful.
> >
> > Would that fit with a project like this as well?
> >
> > Cheers,
> >
> > David
> >
>
> David,
>
> It is my understanding that what this project would produce would be device
> independent.
>
> In Unix operating systems devices are files. For the I2C bus the device id
> would /dev/i2c-0.(I do not believe this would be different on a PI vs and
> Arduino). My goal is to produce Apache licensed libraries like this here:
>
> https://blogs.oracle.com/acaicedo/resource/RPi-HOL/GPIOTest.java
>
> Namely:
>
> final GpioController gpio = GpioFactory.getInstance();
> final GpioPinDigitalOutput led1 =
> gpio.provisionDigitalOutputPin(RaspiPin.GPIO_00);
>
> // continuously blink the led every 1/2 second for 15 seconds
> led1.blink(500, 15000);
>
> However, if people are open to device driver implementations (I would
> assume these would be BSD drivers) I think that is an interesting
> direction and I know of some FreeBSD user groups that might be
> interested in getting involved.
>
> Thanks,
>
> Edward
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Release Process [was: [VOTE] Drop incubating requirement of Maven artifacts]

[Niclas Hedhman]

Yes, I think we all hear your "frustration" that the process is not as
streamlined as it perhaps could, nor that the documentation is as solid as
one might expect (patches are welcome)

The underlying "issue" between the previous "GitHub/Maven releases" and
"Apache releases" was discussed at length long time ago. Basically, pushing
something to Maven Central is not a release. It is a "convenience service"
by the project, and is not at all required from Apache's point of view.
This fact may have some repercussions in how you approach the release.

Perhaps it is possible to automate a bunch of this, for future podlings to
benefit from. And perhaps with help from someone who has experienced this
recently and have notes, infra could create a self-service portal for
setting it up.

In Apache Polygene, we have gotten very far in terms of release automation,
but the initial steps are of course outside our scope. Probably after our
next release, we will publish reusable Gradle components for the Apache
release process for other Gradle based projects to benefit from. We'll see
exactly how we do this.

Cheers
Niclas


On Mon, Jan 9, 2017 at 1:12 AM, Edward Capriolo <edlinuxg...@gmail.com>
wrote:

> On Sat, Jan 7, 2017 at 9:42 AM, John D. Ament <johndam...@apache.org>
> wrote:
>
> > On Sat, Jan 7, 2017 at 9:23 AM Niclas Hedhman <nic...@hedhman.org>
> wrote:
> >
> > > On Sat, Jan 7, 2017 at 9:36 PM, John D. Ament <johndam...@apache.org>
> > > wrote:
> > >
> > > > > So, instead of tying the "incubating" marker to "incubating", I
> would
> > > favor
> > > > > a system of marker(s) indicating the code maturity (incl legal).
> So,
> > > for a
> > > > > podling release to be 1.2.3 (a la Groovy), the same release
> standard
> > as
> > > > > TLPs are applied, but allow "alpha", "rc" or similar markers for
> > > podlings
> > > > > to "practice" releases. Probably not pushing those to mirrors, but
> > > > > otherwise identical in "process" for podling to get their grips on
> > the
> > > > > release process.
> > > > >
> > >
> > > > I think this is a fair point, and probably close to what podling
> > > > communities do (when its a fairly new codebase).  We often see
> releases
> > > in
> > > > the 0.x line, and in the 1+ lines.  Its up to the podling to
> determine
> > > how
> > > > mature they are from a release numbering standpoint.  I wouldn't want
> > the
> > > > IPMC to enforce a versioning scheme.
> > > > It does however seem like a foundation wide versioning scheme may
> make
> > > > sense, or at least references to common references, e.g. semver, may
> > make
> > > > sense as a recommendation to new podlings.
> > >
> > > Yeah, this is a tricky question. On one hand I don't like to dictate,
> but
> > > as a user I like to have a unified view of the world. Perhaps one or
> two
> > > DOAP entries would be a good way, and more strongly promote the DOAP
> and
> > > over time our common tooling could provide the unified view. A bit of
> > "be a
> > > good citizen for your own sake" attitude.
> > >
> > >
> > I'm not sure what you mean by DOAP entries.  Do you have an example?
> >
> > John
> >
> >
> >
> > >
> > > Cheers
> > > --
> > > Niclas Hedhman, Software Developer
> > > http://polygene.apache.org - New Energy for Java
> > >
> >
>
> But that pendulum has swung in the opposite direction, and podling releases
> are now expected to be at ASF TLP levels.
>
> I agree with this. I have started the gossip podling. Getting the release
> out to ASF levels is a bit tricky. Let me explain my situation:
>
> For projects outside of apache I have my own github and I setup an account
> on sonatype. I publish two or three artifacts to maven central and have a
> good amount of foot traffic for what are niche projects.
>
> github, sonatype, and travis yaml is a lightning fast setup. Sonatype asks
> you to submit a jira one time and after that you can publish unlimited
> artifacts in your group to maven central.  After the initial setup a single
> pom file is all you need to be publishing to maven central.
> mvn release clean; mvn release prepare; mvn release perform
> With some plugins you can even automate the closing and releasing the
> repository if you wish,I still do that by hand in sonat

Re: [VOTE] Drop incubating requirement of Maven artifacts

[Niclas Hedhman]

On Sat, Jan 7, 2017 at 9:36 PM, John D. Ament <johndam...@apache.org> wrote:

> > So, instead of tying the "incubating" marker to "incubating", I would
favor
> > a system of marker(s) indicating the code maturity (incl legal). So,
for a
> > podling release to be 1.2.3 (a la Groovy), the same release standard as
> > TLPs are applied, but allow "alpha", "rc" or similar markers for
podlings
> > to "practice" releases. Probably not pushing those to mirrors, but
> > otherwise identical in "process" for podling to get their grips on the
> > release process.
> >

> I think this is a fair point, and probably close to what podling
> communities do (when its a fairly new codebase).  We often see releases in
> the 0.x line, and in the 1+ lines.  Its up to the podling to determine how
> mature they are from a release numbering standpoint.  I wouldn't want the
> IPMC to enforce a versioning scheme.
> It does however seem like a foundation wide versioning scheme may make
> sense, or at least references to common references, e.g. semver, may make
> sense as a recommendation to new podlings.

Yeah, this is a tricky question. On one hand I don't like to dictate, but
as a user I like to have a unified view of the world. Perhaps one or two
DOAP entries would be a good way, and more strongly promote the DOAP and
over time our common tooling could provide the unified view. A bit of "be a
good citizen for your own sake" attitude.


Cheers
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: [VOTE] Graduate Apache Ranger Project from the Incubator - Resending with additional mail distro

[Niclas Hedhman]

ll branches
> > > > Dev list averaged ~50 msgs/month in 2016
> > > > User list averaged ~40 msgs/month in 2016
> > > > 1208 issues created
> > > > 997 issues resolved
> > > >
> > > > Committer’s affiliation:
> > > > ===
> > > > Active:
> > > > Hortonworks
> > > > Talend
> > > > Freestone infotech
> > > > BlueTalon
> > > > eBay
> > > > Others
> > > >
> > > >
> > > > Apache Ranger Top Level Project Resolution:
> > > > 
> > > >
> > > > Establish the Apache Ranger 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 data management platform That provides real-time, consistent
> > access
> > > > to data-intensive applications throughout widely distributed cloud
> > > > architectures.
> > > >
> > > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> > > > (PMC), to be known as the "Apache Ranger Project", be and hereby is
> > > > established pursuant to Bylaws of the Foundation; and be it further
> > > >
> > > > RESOLVED,that the Apache Ranger Project be and hereby is responsible
> > for
> > > > the creation and maintenance of software related to a data management
> > > > platform that provides real-time, consistent access to data-intensive
> > > > applications throughout widely distributed cloud architectures.
> > > >
> > > > RESOLVED, that the office of "Vice President, Apache Ranger" 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 Ranger
> > > > Project, and to have primary responsibility for management of the
> > > projects
> > > > within the scope of responsibility of the Apache Ranger 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 Ranger
> Project:
> > > >
> > > > Alok La
> > > > la...@apache.org<mailto:a...@apache.org><mailto:a...@apache.org>
> > > > Alan Gates
> > > > ga...@apache.org<mailto:ga...@apache.org><mailto:ga...@apache.org>
> > > > Balaji Ganesan
> > > > bgane...@apache.org<mailto:bgane...@apache.org><mailto:bgane
> > > s...@apache.org
> > > > >
> > > > Colm O hEigeartaigh
> > > > cohei...@apache.org<mailto:cohei...@apache.org><mailto:cohei
> > > g...@apache.org
> > > > >
> > > > Daniel Gruno
> > > > rum...@cord.dk<mailto:rum...@cord.dk><mailto:rum...@cord.dk>
> > > > Devaraj Das
> > > > d...@hortonworks.com<mailto:d...@hortonworks.com><mailto:dda
> > > > s...@hortonworks.com>
> > > > Don Bosco Durai
> > > > bo...@apache.org<mailto:bo...@apache.org><mailto:bo...@apache.org>
> > > > Dilli Arumugam
> > > > dillido...@apache.org<mailto:dillido...@apache.org> > > > illido...@apache.org>
> > > > Gautam Borad
> > > > gau...@apache.org<mailto:gau...@apache.org><mailto:gau...@apache.org
> >
> > > > Kevin Minder
> > > > kmin...@apache.org<mailto:kmin...@apache.org><mailto:kminder
> > @apache.org>
> > > > Larry Mccay
> > > > lmc...@apache.org<mailto:lmc...@apache.org><mailto:lmc...@apache.org
> >
> > > > Madhanmohan Neethiraj
> > > > mad...@apache.org<mailto:mad...@apache.org><mailto:mad...@apache.org
> >
> > > > Ramesh Mani
> > > > rm...@hortonworks.com<mailto:rm...@hortonworks.com> > > > m...@hortonworks.com>
> > > > Owen O’Malley
> > > > omal...@apache.org<mailto:omal...@apache.org><mailto:omalley
> > @apache.org>
> > > > Sanjay Radia
> > > > san...@hortonworks.com<mailto:san...@hortonworks.com> > > > san...@hortonworks.com>
> > > > Selvamohan Neethiraj
> > > > sneet...@apache.org<mailto:sneet...@apache.org><mailto:sneet
> > > h...@apache.org
> > > > >
> > > > Velmurugan Periasamy
> > > > v...@apache.org<mailto:v...@apache.org><mailto:v...@apache.org>
> > > >
> > > > NOW, THEREFORE, BE IT FURTHER RESOLVED, that "Selvamohan Neethiraj"
> be
> > > > appointed to the
> > > > office of Vice President, Apache Ranger, 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 Ranger 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 Ranger Project; and be it
> further
> > > >
> > > > RESOLVED, that the Apache Ranger Project be and hereby is tasked with
> > the
> > > > migration of the Apache Incubator Ranger podling; and be it further
> > > >
> > > > RESOLVED, that all responsibilities pertaining to the Apache
> Incubator
> > > > Ranger polling encumbered upon the Apache Incubator Project are
> > hereafter
> > > > discharged.
> > > >
> > >
> >
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: [VOTE] Drop incubating requirement of Maven artifacts

[Niclas Hedhman]

Pierre,
Where can I download or "consume" a project community? I would like to have
a local copy of it, right here. ;-)

Communities are living things, people, and not an immutable release
artifact. Incubation is not a release process, it is effectively an
education program for inexperienced people by experienced people, passing
the baton of collective knowledge. Sorry, but I simply fail to equate this
with the release process of "open source software for the public good", I
think the analogy is too thin.

Cheers

On Sat, Jan 7, 2017 at 4:42 AM, Pierre Smits <pierre.sm...@gmail.com> wrote:

> Nicolas, all,
>
> Despite your believes, you do release communities. Because the community is
> the incubating project. Only after the community meets the criteria of
> graduation a proposal is submitted, seconded by the IPMC and reviewed by
> the board. The community works the code during incubation until it
> consistently meets just one (small set) of the graduation criteria
> (compliance to ASF rules). But all the other aspects (community size,
> diversity and interaction) are far more important for the success, given
> the principle Community over Code.
>
> Otherwise, your suggestion to use the same standards for releasing as tlp
> (released communities) and the examples brought forward look very sound and
> acceptable.
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Fri, Jan 6, 2017 at 1:37 AM, Niclas Hedhman <nic...@hedhman.org> wrote:
>
> > Coming late to the party...
> >
> > This has been discussed, and contentious, since "forever". A long time
> ago,
> > there was a notion that a podling release was not an ASF release (which
> was
> > the main reason for the "incubating" marker in all release and support
> > artifacts. But that pendulum has swung in the opposite direction, and
> > podling releases are now expected to be at ASF TLP levels.
> >
> > Pierre pointed out that "incubating" refers to community and not code,
> but
> > we don't release a community, we release code. I think this is an
> important
> > fact.
> >
> > So, instead of tying the "incubating" marker to "incubating", I would
> favor
> > a system of marker(s) indicating the code maturity (incl legal). So, for
> a
> > podling release to be 1.2.3 (a la Groovy), the same release standard as
> > TLPs are applied, but allow "alpha", "rc" or similar markers for podlings
> > to "practice" releases. Probably not pushing those to mirrors, but
> > otherwise identical in "process" for podling to get their grips on the
> > release process.
> >
> > So, I am +1 with John's "something is broken" observation, although I
> also
> > agree with the many "-1"s that think there is value to the public here.
> >
> >
> > Cheers
> >
> > On Wed, Jan 4, 2017 at 7:47 PM, John D. Ament <johndam...@apache.org>
> > wrote:
> >
> > > I'll point out that this is a cancel thread..., I'm fine if people want
> > to
> > > continue chatting in here, but I started a new discussion on
> > > https://lists.apache.org/thread.html/15550f5bf622ae3070b558505c8a0f
> > > d0ce3b23df3012d57de8b6d9f3@%3Cgeneral.incubator.apache.org%3E
> > >
> > > I'll try to answer questions I saw pop up
> > >
> > > Mark Struberg: No, ignoring commons/log4j for a minute, other projects
> > > continue to work under legacy maven coordinates.  Includes one i
> already
> > > linked to - groovy, also freemarker, zest/polygene (a project that went
> > > straight to TLP).  There's neither foundation policy nor legal impact
> by
> > > using other very similar marks, especially when the project's name
> hasn't
> > > changed.  Publishing under "com.oracle.someProduct" would probably be
> bad
> > > from a marks standpoint since it shows as property of some other
> company,
> > > whereas former foundations or completely independent projects.  Plus,
> the
> > > way maven central works you own the entire tld, except for cases where
> > its
> > > a known third party publisher.  For instance, I own (personally) the
> > domain
> > > name ament.ws and have access to publish under maven coordinates
> > > ws.ament.*.  Github users have to request io.github.themselves
> > manually.  I
> > > assume that something similar exists betwee

Re: [VOTE] Drop incubating requirement of Maven artifacts

[Niclas Hedhman]

t; >
> > On Mon, Jan 2, 2017 at 6:22 PM, John D. Ament <johndam...@apache.org>
> > wrote:
> > > All,
> > >
> > > I'm calling to vote on a proposed policy change.  Current guide at [1]
> > > indicates that maven artifacts should include incubator (or incubating)
> > in
> > > the version string of maven artifacts.  Its labeled as a best practice,
> > not
> > > a requirement and is not a policy followed on other repository
> management
> > > tools (e.g. PyPi).
> > >
> > > I therefore push forward that the incubator will cease expecting
> > java-based
> > > projects to publish artifacts with "-incubating" in the version string,
> > > with the understanding that:
> > >
> > > - Incubating is a term used to refer to a project's stability, not a
> > > release's stability.  It is generally understood that incubating
> projects
> > > are not necessarily immature, but may have a potential of failing to
> > become
> > > a TLP.
> > > - Podling releases are endorsed, the podling itself is not endorsed.
> We
> > > will not approve releases that are blatantly against ASF policies.
> > >
> > >
> > > [ ] +1 Drop the -incubator/-incubating expectation of maven projects
> > > [ ] +/0
> > > [ ] -1 Don't drop because
> > >
> > >
> > > [1]:
> > > http://incubator.apache.org/guides/release-java.html#best-
> practice-maven
> >
> >
> >
> > --
> > Become a Wicket expert, learn from the best: http://wicketinaction.com
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: Write access to January report page

[Niclas Hedhman]

My login as "niclas"

On Thu, Jan 5, 2017 at 9:13 AM, Marvin Humphrey <mar...@rectangular.com>
wrote:

> On Wed, Jan 4, 2017 at 4:51 PM, Niclas Hedhman <nic...@hedhman.org> wrote:
> > Isn't the https://wiki.apache.org/incubator/January2017 supposed to be
> > editable by Mentors/IPMC members?
>
> It's editable by anyone whose wiki username we add to the
> ContributorsGroup page.  What's your wiki id for
> wiki.apache.org/incubator?  (Which is distinct from your Apache ID and
> from logins for other Moin wikis.) I'll add you.
>
> Marvin Humphrey
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Write access to January report page

[Niclas Hedhman]

Hi,
Isn't the https://wiki.apache.org/incubator/January2017 supposed to be
editable by Mentors/IPMC members?

Cheers
-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Re: SGA vs CCLA

[Niclas Hedhman]

Ok, just wanted to make sure...

Why isn't my memory updated with "svn commit" ?? Yeah, the CCLA was updated
in 2005 with the appendix to make the grant specific.

Never mind...

On Wed, Nov 30, 2016 at 12:13 PM, Craig Russell <craig.russ...@oracle.com>
wrote:

> Hi Niclas,
>
> The CCLA is sufficient as a code grant for new code bases coming into
> Apache. Of course, committers must submit their own ICLA as well.
>
> Why do you consider the CCLA a ‘weak’ agreement?
>
> Craig
>
> > On Nov 29, 2016, at 8:04 PM, Niclas Hedhman <nic...@hedhman.org> wrote:
> >
> > I am seeing on
> > http://incubator.apache.org/guides/mentor.html#initial-import-code-dump
> > that the CCLA is adequate for new codebases coming in via the Incubator.
> Is
> > that really the case? It seems to me to be a rather 'weak' agreement for
> > something that substantial.
> >
> >
> > Cheers
> > --
> > Niclas Hedhman, Software Developer
> > http://zest.apache.org - New Energy for Java
>
> Craig L Russell
> Secretary, Apache Software Foundation
> c...@apache.org http://db.apache.org/jdo
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

SGA vs CCLA

[Niclas Hedhman]

I am seeing on
http://incubator.apache.org/guides/mentor.html#initial-import-code-dump
that the CCLA is adequate for new codebases coming in via the Incubator. Is
that really the case? It seems to me to be a rather 'weak' agreement for
something that substantial.


Cheers
-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: [VOTE] Weex to enter the Apache Incubator

[Niclas Hedhman]

+1

On Fri, Nov 25, 2016 at 6:47 AM, Edward J. Yoon <edward.y...@samsung.com>
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 un

Re: [VOTE] Accept OpenWhisk into the Apache Incubator

[Niclas Hedhman]

gt; == Git Repository ==
>
> As a community we would like to keep the master repository as well as
> issue tracking on GitHub. We will be working closely with ASF Infra.
> team to implement all the required pieces like ensure to send push and
> issue notifications through ASF controlled mailing lists. During
> incubation we will work closely with Infra to support GitHub master
> repositories. We also understand that we have to support a way of
> providing patches, which does not require a GitHub account for
> contributors who are not willing or not able abide by GitHub’s terms
> and conditions. It is our understanding that this approach has been
> signed off by Greg Stein, ASF’s Infrastructure Administrator.
>   gstein sez: the podling can only graduate within an approved
> repository system. The IPMC may have a differing opinion, but from an
> Infra perspective: the OpenWhisk podling can continue with their usage
> of a GitHub repository, but faces a clear obstacle: GitHub "as master
> [as allowed by the Foundation]" must be approved and working before
> the graduation, or they must migrate their primary to the Foundation's
> Git repository (at git-wip) before they graduate.
>
> If we need to adapt our repo. paths to conform to Apache guidelines
> (and perhaps necessitated by a move the the Apache named repo.) It is
> conventional to use all lower case, dash-separated (-) repository
> names. The repository should be prefixed with incubator and later
> renamed assuming the project is promoted to a TLP.
>
> If we need to move the project codebase from its existing GitHub repo.
> as part of incubation, we would like to preserve the directory names
> as they appear today and adopt the “apache” as part of the URI path as
> we have seen other projects adopt.
>
> This would mean all existing repositories which are now of the form:
>
>  *  https://github.com/openwhisk/openwhisk
>  *  https://github.com/openwhisk/openwhisk-catalog
>  *  https://githun.com/openwhisk/openwhisk-package-rss
>  *  etc.
>
> would now take the form:
>
>  *  https://github.com/apache/openwhisk/openwhisk
>  *  https://github.com/apache/openwhisk/openwhisk-catalog
>  *  https://githun.com/apache/openwhisk/openwhisk-package-rss
>  *  and so on ...
>
> == Issue Tracking ==
>
> We would like to explore the possibility of continuing to use GitHub
> issue tracking (as project milestones, epics and features are all
> nicely tracked via ZenHub boards) as we understand that this may now
> be possible. We will provide any linkage or support for JIRA issue
> tracking if that is required in order to track any “pull” requests
> within GitHub.
>
> == Other Resources ==
>
> We would like to preserve our existing automated TravisCI automated
> testing from GitHub. The project uses a continuous CD/CI process
> currently that we would like to continue to support via multiple
> stages that run progressive stress and performance tests that are also
> automated.
>
> == Initial Committers ==
>
> The following is the proposed list of initial committers, email
> address [, GitHub ID)]:
>
>  *  Bertrand Delacretaz, bdelacre...@apache.org, bdelacretaz
>  *  Carlos Santana,  csant...@us.ibm.com, csantanapr
>  *  Carsten Ziegeler, cziege...@apache.org, cziegeler
>  *  Chetan Mehrotra, chet...@adobe.com, chetanmeh
>  *  Christian Bickel, cbic...@de.ibm.com, christianbickel
>  *  Daisy Guo, guoyi...@cn.ibm.com, daisy-ycguo
>  *  David Liu, david@cn.ibm.com, lzbj
>  *  Dragos Dascalita Haut, ddas...@adobe.com, ddragosd
>  *  Jeremias Werner, jerew...@de.ibm.com, jeremiaswerner
>  *  Markus Thommes, markus.thoem...@de.ibm.com, markusthoemmes
>  *  Matt Rutkowski, mrutk...@us.ibm.com, mrutkows
>  *  Nicholas Speeter, nwspe...@us.ibm.com, nwspeete-ibm
>  *  Paul Castro, cast...@us.ibm.com, paulcastro
>  *  Perry Cheng, pe...@us.ibm.com, perryibm
>  *  Philippe Sutor, psu...@us.ibm.com, psutor
>  *  Rodric Rabbah, rab...@us.ibm.com, rabbah
>  * Sergio Fernández, wik...@apache.org, wikier
>  *  Stephen Fink, sjf...@us.ibm.com, sjfink
>  *  Tony Ffrench, tffre...@us.ibm.com, tonyfrench
>  *  Vincent Hou, s...@us.ibm.com, houshengbo
>  * Edward J. Yoon, edward.y...@samsung.com, edwardyoon
>
> Although this list of initial committers appears long, OpenWhisk is a
> complete platform which consists of many services supporting many
> environments, programming languages and integrations. This diversity
> in needs is reflected by the size of the initial committers group.
> OpenWhisk also supports an end user ecosystem including CLI, Tooling,
> Package Catalog, “curated” Packages, samples, etc. along with the
> intention of tying in API gateway (e.g., OpenAPI) and other event
> source integrations.
>
> We hope to add many more committers who provide expertise and the
> various areas OpenWhisk uses to efficiently provide an exceptional
> Serverless platform with compelling content.
>
> == Affiliations ==
>
> Additional TBD during the proposal process
>
> == Sponsors ==
>
> Additional TBD during the proposal process.
>
> == Sponsoring Entity ==
>
> OpenWhisk would ask that the Apache Incubator be the sponsor.
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: [DISCUSS] Weex for Apache Incubator

[Niclas Hedhman]

Additional note to Weex community; Beside everything discussed, there is
nothing impossible about changing name during or even after incubation.
Apache Zest is discussing a name change right now, as Eclipse Zest was
missed in the name search previously and we want to avoid the name clash.

Cheers
Niclas

On Tue, Nov 22, 2016 at 10:07 PM, Bertrand Delacretaz <
bdelacre...@apache.org> wrote:

> On Tue, Nov 22, 2016 at 2:45 PM, Daniel Gruno <humbed...@apache.org>
> wrote:
> > ...Whether it means something funny in $language, who cares... :)
>
> We don't really care at the ASF or Incubator PMC level but it's fair
> to warn people when that happens.
>
> It's like when you're traveling, it's good to know in advance if your
> name means something funny in that country...to be prepared for
> people's reactions when you say your name ;-)
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: [DISCUSS] Weex for Apache Incubator

[Niclas Hedhman]

I volunteer as mentor. I have been a bit inactive of the Weex proposal, but
my recent addition to the Incubator PMC was for this purpose.

Cheers
Niclas

On Mon, Nov 21, 2016 at 2:01 PM, Bertrand Delacretaz <bdelacre...@apache.org
> wrote:

> Hi,
>
> On Sun, Nov 20, 2016 at 11:17 PM, Edward J. Yoon
> <edward.y...@samsung.com> wrote:
> > === Nominated Mentors ===
> ...
> >  * Longda Feng  (Apache Storm)
> 
>
> As per http://people.apache.org/phonebook.html?uid=longda Longda
> doesn't seem to be an Incubator PMC member - that's required for being
> a mentor.
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

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

[Niclas Hedhman]

Reynold,
I can recall the "newer technologies" argument since the inception[1] of
ASF, and not a single one of these "newer technologies" has stood the test
of time, and it is likely that the current "newer technologies" will
eventually fall out of favor too, because of newer "newer technologies".

Now, all of that said, I think that it is important to divide this
discussion into 2 very distinct cases. The Gradle community has realized
that and run the "user lists" as a web forum and the "dev list" as a
traditional mailing list. Such choice is probably within reason at ASF too,
although if you ask around a bit, you will probably find that experience
community members will participate a lot less on web forums than on mailing
lists, because it is more inconvenient (filtering, tagging is not as
powerful). An arrangement like Google Groups, where both the web forum and
the mailing list is merge into one is probably better, and if you feel
strongly about this, then please help out PonyMail project, which drives
http://lists.apache.org which is getting closer and closer to this hybrid.

Cheers
Niclas

[1] Believe it or not, I was involved with Apache group way before Jeff
was, and back then projects didn't even have in-house mailing lists, but
utilized outside companies' "gracious help", but these companies have
ceased to exist and some of the early mails are lost forever, as there were
no archiving and not all lists could be salvaged in their entirety. This
was a painful reminder to not depend on external services, that may
disappear over night, even if they seem bigger and better than Swiss army
knives.


On Mon, Nov 14, 2016 at 5:57 AM, Reynold Xin <r...@apache.org> wrote:

> "a better global way to A) communicate across a medium that everyone uses
> daily B) archive to search and come back to"
>
> How would we even validate or decide that? For discussions like this it is
> very easy to fall into confirmation bias.
>
> I use mailing lists all the time since it is the Apache Way, but I also
> admit there are potentially better ways for other projects. People that are
> used to mailing lists might think mailing lists are the best thing in the
> world, but the reality is that majority of the developers in this world,
> outside a few core open source projects, have never used mailing lists. If
> we talk to the QQ/Wechat/web-based-forum generation in China and force them
> to use mailing lists, they might comply because it is the Apache Way, but
> they will also develop the sentiment that the ASF refuses to change and
> adapt newer technologies.
>
> And to be honest, while I think mailing lists are great for simple voting
> and information dissemination, there are obvious downsides of mailing lists
> too. That's why a lot of projects also augment mailing lists via video
> discussions, google docs for commenting, wiki, etc.
>
> In reality, there are also legal reasons why we use mailing lists, and
> those are not as well known. We should document those and make them more
> visible too.
>
>
>
> On Sun, Nov 13, 2016 at 12:25 PM, Jeff Genender <jgenen...@apache.org>
> wrote:
>
> > > On Nov 13, 2016, at 11:33 AM, Gunnar Tapper <tapper.gun...@gmail.com>
> > wrote:
> > > As mentioned, the Apache Way is that "everything happens on the mailing
> > lists." As a matter of fact, key parts of being an incubator is to learn
> > how to operate per the Apache Way and to build communities. We even
> include
> > statistics about mailing list engagement as an indicator of community
> > building.
> > >
> >
> > Gunnar, I’m going to give you a big -1 to this.
> >
> > Unless you can come up with a better global way to A) communicate across
> a
> > medium that everyone uses daily B) archive to search and come back to, I
> am
> > in full disagreement.  Since I have been with Apache (about 14 years), I
> > have yet to find a better medium than the lists, and its always been a
> > known fact that ultimately, any non-mail list discussions that result in
> > some form of a decision are brought to the mail lists for global
> discussion.
> >
> > Our mail lists are indexed by Google and others.  Its easy to find what
> > one looks for.
> >
> > Jeff
> >
>



-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

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

[Niclas Hedhman]

t; > On Fri, Nov 4, 2016 at 3:26 PM, John D. Ament <
> john.d.am...@gmail.com
> > >
> > >> > wrote:
> > >> >
> > >> > > On Fri, Nov 4, 2016 at 4:43 PM Roman Shaposhnik <
> > ro...@shaposhnik.org
> > >> >
> > >> > > wrote:
> > >> > >
> > >> > > > The proposal looks fine in general, but I'm slightly concerned
> > >> about:
> > >> > > >https://na01.safelinks.protection.outlook.com/?url=
> > >> > https%3A%2F%2Fgithub.com%2Falibaba%2FRocketMQ%2Fgraphs%
> > >> > 2Fcontributors=02%7C01%7CRoss.Gardler%40microsoft.com%
> > >> > 7Cd12890186efe4c6e60c908d40597dcff%7C72f988bf86f141af91ab2d7cd011
> > >> > db47%7C1%7C0%7C636139597197176036=96ixj1Js5%
> > >> > 2BytkM0Pru7nABYfTTYimOP5se5POgOMleo%3D=0
> > >> > > >
> > >> > > > It seems that the model so far has been -- through huge blobs of
> > >> > > > code over the wall. Given that the composition of initial
> > committers
> > >> > > > is all from Alibaba I hope their mentors will spend a lot of
> time
> > >> > > > making sure that "commit early, commit often" mentality
> prevails.
> > >> > > >
> > >> > > > In addition to that, I can't seem to reconcile the statement:
> > >> > > >"The source code was opened up in 2012."
> > >> > > > with what I see on GitHub. What am I missing?
> > >> > > >
> > >> > >
> > >> > > So I think these are the same points I was bringing up as well.  I
> > >> > suspect
> > >> > > its a case where there wasn't a ton of open source development on
> > the
> > >> > > product and it was kept internal.
> > >> > >
> > >> > > I'm still a bit leary about the "relationship with other apache
> > >> products"
> > >> > > section still.  I'm not interested in seeing how a podling
> competes
> > >> with
> > >> > > other projects (and its a bit surprising, since Bruce is the chair
> > of
> > >> one
> > >> > > of the competitors), but instead how the podling has synergies
> with
> > >> the
> > >> > > other components.  I raised that they're using ASF projects today
> in
> > >> > their
> > >> > > code base.
> > >> > >
> > >> > > Some other ways to address this section:
> > >> > >
> > >> > > - How can RocketMQ work with the existing Kafka or ActiveMQ
> > >> communities
> > >> > to
> > >> > > build cross platform clients?
> > >> > > - How can RocketMQ look to leverage Cassandra, Geode, Derby as
> > backend
> > >> > > persistence stores?
> > >> > >
> > >> > > etc..
> > >> > >
> > >> > >
> > >> > > >
> > >> > > > Thanks,
> > >> > > > Roman.
> > >> > > >
> > >> > > > On Fri, Nov 4, 2016 at 11:00 AM, Brian McCallister <
> > >> bri...@skife.org>
> > >> > > > wrote:
> > >> > > > > +1 !
> > >> > > > >
> > >> > > > > On Fri, Nov 4, 2016 at 8:37 AM, Jim Jagielski <
> j...@jagunet.com>
> > >> > wrote:
> > >> > > > >
> > >> > > > >> Cool.
> > >> > > > >>
> > >> > > > >> +1
> > >> > > > >>
> > >> > > > >> > On Nov 3, 2016, at 6:10 PM, Bruce Snyder <
> > >> bruce.sny...@gmail.com>
> > >> > > > wrote:
> > >> > > > >> >
> > >> > > > >> > Please find below a proposal for a new Incubator podling
> > named
> > >> > > Apache
> > >> > > > >> > RocketMQ, a fast, low latency, reliable, scalable,
> > distributed,
> > >> > easy
> > >> > > > to
> > >> > > > >> use
> > >> > > > >> > message-oriented middleware, especially for processing
> large
> > >> > amounts
> > >> > > > of
> > >> > > > >> > streaming data.
> > >> > > > >> >
> > >> > > > >> > The draft proposal can be found in the wiki at the
> following
> > >> URL:
> > >> > > > >> >
> > >> > > > >> > https://na01.safelinks.protection.outlook.com/?url=
> https%3A%
> > >> 2F%
> > >> > 2Fwiki.apache.org%2Fincubator%2FRocketMQProposal=02%
> > >> > 7C01%7CRoss.Gardler%40microsoft.com%7Cd12890186efe4c6e60c908d40597
> > dcff%
> > >> > 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
> > 7C636139597197176036=
> > >> > xjsmhUA5%2Ftnl5HnA4LtQnVGa5ddYybjaKIe3CRgS9S0%3D=0
> > >> > > > >> >
> > >> > > > >> > Below, please find the text for the proposal below.
> > >> > > > >> >
> > >> > > > >> > Thanks,
> > >> > > > >> >
> > >> > > > >> > Bruce
> > >> > > > >>
> > >> > > > >>
> > >> > > > >> 
> > >> > -
> > >> > > > >> To unsubscribe, e-mail: general-unsubscribe@incubator.
> > apache.org
> > >> > > > >> For additional commands, e-mail:
> general-help@incubator.apache.
> > >> org
> > >> > > > >>
> > >> > > > >>
> > >> > > >
> > >> > > > 
> > >> -
> > >> > > > To unsubscribe, e-mail: general-unsubscribe@incubator.
> apache.org
> > >> > > > For additional commands, e-mail: general-help@incubator.apache.
> > org
> > >> > > >
> > >> > > >
> > >> > >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > perl -e 'print
> > >> > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\
> "YC;VT*"
> > >> );'
> > >> >
> > >> > ActiveMQ in Action: https://na01.safelinks.
> > protection.outlook.com/?url=
> > >> > http%3A%2F%2Fbit.ly%2F2je6cQ=02%7C01%7CRoss.Gardler%40m
> > >> icrosoft.com%
> > >> > 7Cd12890186efe4c6e60c908d40597dcff%7C72f988bf86f141af91ab2d7cd011
> > >> > db47%7C1%7C0%7C636139597197176036=WObI4mpJLTWW%2Fg6%
> > >> > 2BNB3ERPQJ6JVFuM0u4fWySbWWpGI%3D=0
> > >> > Blog: https://na01.safelinks.protection.outlook.com/?url=
> > >> > http%3A%2F%2Fbsnyder.org%2F=02%7C01%7CRoss.Gardler%40
> > microsoft.com
> > >> %
> > >> > 7Cd12890186efe4c6e60c908d40597dcff%7C72f988bf86f141af91ab2d7cd011
> > >> > db47%7C1%7C0%7C636139597197176036=9EWI%2FF%2FgDyaU9qybAVHRZ%
> > >> > 2FigY6o%2FjkAuZxilJ8uZMEg%3D=0 <https://na01.safelinks.
> > >> > protection.outlook.com/?url=http%3A%2F%2Fbruceblog.org%2F&
> > >> > data=02%7C01%7CRoss.Gardler%40microsoft.com%7Cd12890186efe4c
> > >> 6e60c908d40597
> > >> > dcff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
> > >> > 7C636139597197176036=
> > >> > Vlc0l%2FVfE997etkGwBIVJ0wSQ6eDz3bPoWzeWLTl6X8%3D=0>
> > >> > Twitter: https://na01.safelinks.protection.outlook.com/?url=
> > >> > http%3A%2F%2Ftwitter.com%2Fbrucesnyder=02%7C01%
> > >> > 7CRoss.Gardler%40microsoft.com%7Cd12890186efe4c6e60c908d40597dcff%
> > >> > 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
> > 7C636139597197176036=
> > >> > iCFOJzNIqieH5fJ%2BL6%2BxaVjgi8q2hiqjlc2VVerPr40%3D=0
> > >> >
> > >>
> > >
> > >
> >
>



-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Request to join Incubator PMC

[Niclas Hedhman]

Hi,
I (apache ID "niclas") would like to rejoin the Incubator PMC.

Thanks
-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: [DISCUSS] Graduate Apache Geode (incubating) as a TLP

[Niclas Hedhman]

D, that the persons listed immediately below be and
> hereby are appointed to serve as the initial members of the
> Apache Geode Project:
>
> * Anilkumar Gingade <aging...@apache.org>
> * Anthony Baker <aba...@apache.org>
> * Ashvin Agrawal <ash...@apache.org>
> * Avinash Dongre <adon...@apache.org>
> * Barry Oglesby < bogle...@apache.org>
> * Bruce Schuchardt <bschucha...@apache.org>
> * Dan Smith <upthewatersp...@apache.org>
> * Darrel Schneider <dschnei...@apache.org>
> * Dave Barnes <dbar...@apache.org>
> * Eric Shu <esh...@apache.org>
> * Greg Chase <gregch...@apache.org>
> * Hitesh Khamesra <hiteshkhame...@apache.org>
> * Jason Huynh <jasonhu...@apache.org>
> * Jens Deppe <jensde...@apache.org>
> * Jianxia Chen <jche...@apache.org>
> * Jinmei Liao <jinmeil...@apache.org>
> * John Blum <jxb...@apache.org>
> * Karen Miller <kmil...@apache.org>
> * Konstantin Boudnik <c...@apache.org>
> * Kirk Lund <kl...@apache.org>
> * Mark Bretl <mbr...@apache.org>
> * Nabarun Nag <n...@apache.org>
> * Niall Pemberton <nia...@apache.org>
> * Nitin Lamba <nla...@apache.org>
> * Roman Shaposhnik <r...@apache.org>
> * Sai Boorlagadda <sai_boorlaga...@apache.org>
> * Swapnil Bawaskar <sbawas...@apache.org>
> * Udo Kohlmeyer <u...@apache.org>
> * William Markito <mark...@apache.org>
> * Xiaojian Zhou <zho...@apache.org>
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Mark Bretl
> be appointed to the office of Vice President, Apache Geode, 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 Geode 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 Geode Project; and be it further
>
> RESOLVED, that the Apache Geode Project be and hereby
> is tasked with the miization of the Apache
> Incubator Geode podling; and be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache
> Incubator Geode podling encumbered upon the Apache Incubator
> Project are hereafter discharged.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: NetBeans next steps

[Niclas Hedhman]

See https://issues.apache.org/jira/browse/ZEST-1 with a list of tasks that
are needed as the initial steps of onboarding, and that is just to get
going.

I hope that provides a concrete view of what is needed from the Mentors in
the first couple of weeks.

Cheers
Niclas

On Sat, Oct 1, 2016 at 11:35 PM, Bertrand Delacretaz <bdelacre...@apache.org
> wrote:

> Hi NetBeans mentors and initial committers,
>
> As per [0] I have updated podlings.xml and requested creation of the
> dev, users, commits and private lists via
> https://infra.apache.org/officers/mlreq/incubator, with Geertjan and
> myself as moderators [4] for now. I just took care of steps 1 to 3
> from [0] so far. I'll be mostly offline until Tuesday morning, if
> other mentors can take care of the remaining steps please go ahead!
>
> We will announce the availability of these lists here once they are
> created, along with subscription information. Everybody can subscribe
> to these lists except for the private one for which we'll send
> instructions to the dev list separately. But please wait for the lists
> to be created before subscribing, obviously ;-)
>
> NetBeans initial committers are welcome to already send in their iCLA
> [1] as well as cCLA [2] if desired. The iCLA is required to get an
> Apache account, while cCLA is between you and your employer but not
> required by the ASF. See [3] for which Apache IDs are already taken.
>
> -Bertrand
>
> [0] https://www.apache.org/dev/infra-contact#requesting-podling
> [1] https://www.apache.org/licenses/icla.txt
> [2] https://www.apache.org/licenses/cla-corporate.txt
> [3] http://people.apache.org/committer-index.html
> [4] https://reference.apache.org/pmc/ml
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: [DISCUSS] Olympian Incubation Proposal

[Niclas Hedhman]

Agree with you on all points, Taylor.

And I am even quite surprised to see the number of people backing the
project, yet Apache is adamant to get involved. It feels a little bit like
the "Community over Code" and "Independent of any Corporate Influences"
have both received a big fat slap in their faces, and I think this hurts
the ASF more than any fallout with named corporation.

Disappointing to me...

Niclas

On Sat, Oct 1, 2016 at 7:32 AM, P. Taylor Goetz <ptgo...@gmail.com> wrote:

> I think the community behind this proposal is ready to accept defeat at
> this point. With DataStax' objection, the project simply can't be brought
> under the auspices of the ASF unless DataStax reverses its stance.
>
> Personally, I'm somewhat discouraged to see a company I once held in high
> regard in  terms of supporting OSS and the ASF take this action. This
> represents a further erosion of that respect. It is what it is. I can't
> fault DataStax for trying to protect their bottom line. They are well
> within their rights here. It could be considered a stain on their
> relationship with the ASF, or not.
>
> The community seems committed to moving forward with a fork, whether it is
> considered hostile or friendly. From discussions I've been privy to, if
> DataStax were to reverse their stance, this community would come back to
> the ASF in a heartbeat. There's a community behind this code, and they
> deserve the right to move forward.
>
> I think they will, unfortunately not at the ASF. At least for now. Nothing
> would please me more than to see this community be able to come to Apache.
>
> -Taylor
>
> > On Sep 30, 2016, at 4:15 AM, Tom Barber <tom.bar...@meteorite.bi> wrote:
> >
> > I like the re-licensing threat get it forked on github and prove to
> > them there is a willing community out there!
> >
> > Tom
> >
> >> On Fri, Sep 30, 2016 at 4:17 AM, P. Taylor Goetz <ptgo...@gmail.com>
> wrote:
> >>
> >> I'd leave it open for now. I imagine/hope there are enough people aware
> of
> >> this thread that the sentiments expressed here might affect a change.
> >>
> >> -Taylor
> >>
> >>>> On Sep 29, 2016, at 10:57 PM, Henry Saputra <henry.sapu...@gmail.com>
> >>> wrote:
> >>>
> >>> With obvious block due to Datastax response, shall I CLOSE this DISCUSS
> >>> thread until further updates, if any?
> >>>
> >>>> On Thursday, September 29, 2016, P. Taylor Goetz <ptgo...@gmail.com>
> >> wrote:
> >>>>
> >>>> For the record I'd be -1 as well unless DataStax chose to support it.
> >>>>
> >>>> I would like to give them time to change their mind though.
> >>>>
> >>>> -Taylor
> >>>>
> >>>>>> On Sep 29, 2016, at 10:37 PM, Greg Stein <gst...@gmail.com
> >>>>> <javascript:;>> wrote:
> >>>>>
> >>>>>> On Sep 29, 2016 19:22, "P. Taylor Goetz" <ptgo...@gmail.com
> >>>> <javascript:;>> wrote:
> >>>>>> ...
> >>>>>> They can block a move to the ASF, but they can’t block a fork of the
> >>>>> project moving elsewhere. Strong communities will regroup and live
> on.
> >>>>> DataStax' reluctance to allow it could very easily be interpreted as
> a
> >>>>> rejection of the ASF governance model or the Foundation itself.
> >>>>>
> >>>>> Yes, the community could certainly launch their fork at GitHub or
> some
> >>>>> such. DataStax provided them with that ability via the ALv2 license.
> >> The
> >>>>> ASF is not a necessary step for that community.
> >>>>>
> >>>>>> ...
> >>>>>> Can we wait and see if DataStax is willing to do the right thing
> >> before
> >>>>> shooting down the proposal as a hostile fork?
> >>>>>
> >>>>> My vote remains -1. That can change, based on their choices.
> >>>>>
> >>>>> Cheers,
> >>>>> -g
> >>>>
> >>>> -
> >>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >>>> <javascript:;>
> >>>> For additional commands, e-mail: general-h...@incubator.apache.org
> >>>> <javascript:;>
> >>
> >> -
> >> 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
>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: Radical proposal: no initial list of committers

[Niclas Hedhman]

I like the idea, but isn't the initial list primarily a question for the
Secretary.
Is the Secretary ok with 1000 additional ICLAs arriving en masse from an
even larger project?

If so, then I think the solution is much simpler; *Let the podling decide*
if it is only Mentors, every user who has showed up at the project, or
anything in between. If the Secretary has workload issues with ICLAs, then
add a "max X" to the "let the podling decide". My guess is that the
Secretary would say Ok to up to 100, possibly much higher (it spreads out
over a few weeks). The less Incubator interferes the better, I think.

Niclas

On Wed, Sep 28, 2016 at 1:27 PM, Greg Stein <gst...@gmail.com> wrote:

> On Tue, Sep 27, 2016 at 4:39 PM, Bertrand Delacretaz <
> bdelacre...@apache.org
> > wrote:
>
> > On Tue, Sep 27, 2016 at 11:01 PM, Roman Shaposhnik <ro...@shaposhnik.org
> >
> > wrote:
> > >... Greg's proposal, as far as I can see, is predicated on mentors being
> > fully
> > > aware of an increased load...
> >
> > And as such might be an interesting filter to make sure mentors are
> > actually going to engage.
> >
>
> RIght. That was a bit of my thought: if the mentors aren't engaged enough
> to vote people in, then what are they doing there.(*)
>
> The basic concept can certainly be fiddled with. I see a couple ways:
> increased mentor count for the bootstrap work, and/or maybe set the initial
> list at (5) rather than (0).
>
> But back to (*), the mentors may only be there for *community*
> development/education. As stated elsethread, such mentors may not be
> properly equipped to evaluate merit for committership. That's a fair point
> which I had not considered. ... So you could maybe imagine (1) Champion,
> (3) Mentors, and (5) PPMC/committers to start any podling.
>
> Cheers,
> -g
>



-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: [VOTE] Accept NetBeans into the Apache Incubator

[Niclas Hedhman]

BV)
> >   11. Francesco Perez Duran (Corizon BV)
> >   11. Christian Stolz (Janitza)
> >   13. Ernest Lotter (Institute of Mine Seismology)
> >   14. Neil C. Smith (Praxis LIVE)
> >   15. Valentin Buergel (Simtec Buergel AG)
> >   16. Stephen Cumminger (Sonideft)
> >   17. Steven Yi (blue)
> >   18. Henry Arousell (Björn Lundén Information AB)
> >   19. Thomas Boqvist (Björn Lundén Information AB)
> >   20. Zoran Sevarac (University of Belgrade)
> >
> >   * Individual contributors from ex-Sun and ex-Oracle employees.
> >1. James Gosling (Liquid Robotics)
> >2. Mike Duigou (Liquid Robotics)
> >3. *Jesse Glick*
> >4. *Milos Kleint* (Atlassian)
> >5. *Radim Kubacki* (currently NBAndroid.org)
> >6. *Ralph Benjamin Ruijs* (ex refactoring guru from NetBeans team,
> now at
> > Rockstars IT)
> >7. *Tim Boudreau* (ex window system guru from NetBeans team)
> >8. *Viktor Lapitsky* (dev/deployment/debug)
> >
> >   * Individual contributors from NetBeans Dream Team.
> >1. Aljoscha Rittner (ETable/Outline component features)
> >2. Andreas Stefik (accessibility features)
> >3. *Anton Epple* (DukeScript plugin from Dukehoff)
> >4. Aristides Villareal (documentation, testing)
> >5. *Benno Markiewicz* (various independent plugins)
> >6. Bruno Souza (SouJava)
> >7. Christian Lenz (website redesigner and more)
> >8. Constantin Drabo (testing, quality control)
> >9. David Heffelfinger (documentation in Java EE area)
> >   10. *Emilian Bold* (various plugins from Joseki Bold SRL)
> >   11. Hermien Pellissier (documentation, testing)
> >   12. Ivar Grimstad (JPA Modeler and MVC tooling)
> >   13. Josh Juneau (documentation, testing, MVC tooling)
> >   14. Kirk Pepperdine (jClarity)
> >   15. Johan Vos (Gluon plugin from Gluon)
> >   16. Jose Pereda (Gluon plugin from Gluon)
> >   17. John Kostaras (documentation, testing)
> >   18. Liang Ding (Chinese translator)
> >   19. Mark Stephens (JavaFX PDF viewer plugin from IDR Solutions)
> >   20. Martijn Verburg (jClarity)
> >   21. Michael Nascimento Santos (Improving CEO, working on refactoring
> > tools) 22. Michael Mueller
> >   23. Michel Graciano (tests, documentation)
> >   24. Tushar Joshi (various plugins, documentation, testing)
> >   25. *Wade Chandler* (Independent, working on Groovy support)
> >   26. Zoran Sevarac (plugins for teaching/education)
> >
> >   * Individual contributors from NetBeans plugin developers.
> >1. Georgia Ingham (JavaFX PDF viewer plugin from IDR Solutions)
> >2. *Emmanuel Hugonnet* (WildFly plugin from Red Hat)
> >3. Shai Almog (Codename One plugin from Codename One)
> >4. Steve Hannah (Codename One plugin from Codename One)
> >5. Attila Kelemen (independent Gradle plugin)
> >6. Denis Anisimov (Vaadin plugin from Vaadin)
> >7. Gaurav Gupta (independent JPA Modeler plugin)
> >8. Junichi Yamamoto (PHP-related plugins)
> >9. Bruno Flavio (Groovy/Grails-related code)
> >   10. Leonardo Loch Zanivan (JSHint)
> >   11. Mattias Blaesing (various plugins)
> >
> >   * Miscellaneous
> >1. Anuradha Gunasekara (Maven tools)
> >2. Steve Millidge (Payara Services)
> >3. Andrew Pielage (Payara Services)
> >4. Gui Chulin (translation)
> >5. Yi Zhao (translation)
> >6. Liyuan Li (translation)
> >7. CunHui Lin (translation)
> >8. Lei Cao (translation)
> >
> > == Sponsors ==
> >
> > === Champion ===
> >
> >   * Bertrand Delacretaz
> >
> > === Mentors ===
> >
> >   * Bertrand Delacretaz
> >   * Emmanuel Lécharny
> >   * Ate Douma
> >   * Mark Struberg
> >   * Jim Jagielski
> >   * Daniel Gruno
> >
> > === Sponsoring Entity ===
> >   * The Apache Incubator
> >
> >
> > -
> > 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
>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Niclas Hedhman]

On Sun, Sep 25, 2016 at 3:07 AM, Emmanuel Lécharny <elecha...@gmail.com>
wrote:

> Le 24/09/16 à 01:25, Roman Shaposhnik a écrit :
> > On Thu, Sep 22, 2016 at 1:48 AM, Bertrand Delacretaz
> > <bdelacre...@apache.org> wrote:
> >> Hi Wade,
> >>
> >> On Wed, Sep 21, 2016 at 11:38 PM, Wade Chandler
> >> 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.
> > Well, but they do. In fact, when I was a VP of Incubator a few years
> > ago I had to deal with a formal escalation brought to the ASF level
> > by somebody who felt unduly left out of that initial list of committers.
>
> Shit happens. But because it happens does not mean we should appy very
> bureaucratic rules for all the other projects.
>
> It's enough to *warn* the new podling that they have to be careful. Up
> to them to decide which level of check they want to apply.


The initial committer list is IMHO completely irrelevant. Put down those
people who are expected to make a contribution within the next 6 months. It
is also a more honest position to the ASF, rather than listing hundreds of
people who will never use it. If that intent is stated clearly, then I
can't see why anyone who is not active would find that objectionable, even
if it is someone contributing as much as Tulach. Ohhh, yeah, don't forget
that each and every one of those initial committers need to execute a
Individual Contributor License Agreement (ICLA) with the ASF, and that our
dear Secretary need to process those. So, although the Secretary seems to
be super-human and can handle hundreds, it seems unnecessary to ask people
to do something that has no effect on them.

What I think IS important is that there is a "Contributor List" on the web
site, listing everyone and perhaps even to what extent (number of commits
for instance, time period, or similar). That is more prudent and much
easier to point to for the individual who is seeking this credit. And
better yet, it doesn't need to exist right now...

Cheers
-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Niclas Hedhman]

Greg,
many people on this list are probably unaware that your role changed a
couple of days ago...

On Sat, Sep 24, 2016 at 10:59 AM, Greg Stein <gst...@gmail.com> wrote:

> On Thu, Sep 22, 2016 at 7:20 AM, Bertrand Delacretaz <
> bdelacre...@apache.org
> > wrote:
>
> > On Thu, Sep 22, 2016 at 1:40 PM, Geertjan Wielenga
> > <geertjan.wiele...@googlemail.com> wrote:
> > >...there hasn't even been a vote on the proposal at this stage. :-)
> >
> > Correct ;-)
> >
> > FWIW I've seen an internal draft of Daniel Gruno's infrastructure cost
> > analysis so that's progressing nicely, we should have public results
> > soon and can then move forward.
> >
>
> One thing that is coming out of this discussion, and the costing is
> plugins.nb.o. That seems to be a critical part of the NetBeans ecosystem
> and cannot just be "left behind for a few months, and we'll hope to figure
> it out before Oracle shuts it down".
>
> I think it would be a tremendous hardship to the community to enter
> incubation, not solve plugins.nb.o, and get their podling retired. Where
> would NB go then? Would not be fun. (and by "solve", I mean: some basic
> technical approach here at the ASF, and a +1 that the ASF can absorb the
> related cost).
>
> As an IPMC member, I'd be hard-pressed to accept NB without some of idea of
> how the community will handle plugins. As Infra, I can help Daniel Gruno
> with the costing and getting that +1 from on high.
>
> (Note: I am sure that NB could be changed over time to use (say) Maven
> Central, as mentioned else-thread, but that change is a multi-year rollout;
> plugins.nb.o would likely need to exist even past that)
>
> Cheers,
> -g
>



-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Niclas Hedhman]

AGES ago (~2002), I was running a project that used the openapi.org which
is the RCP part of NetBeans. At that time, we had a job that downloaded the
nightly builds to be tested and incorporated into our continuous build. The
nightly, compared to source tree, had the advantage of being tested before
published. If test failed, there were no build (IIRC).

So, "developers" could be broader, but that is potentially always the case
"pull from source tree"...

Niclas

On Sun, Sep 18, 2016 at 1:57 PM, Alex Harui <aha...@adobe.com> wrote:

>
>
> On 9/17/16, 8:54 AM, "Jochen Theodorou" <blackd...@gmx.org> wrote:
>
> >On 17.09.2016 10:23, Geertjan Wielenga wrote:
> >> Nightly builds is all that's needed, indeed, no one needs to announce
> >>them,
> >> they should simply be available. Agreed it's important to distinguish
> >> between nightly builds and official releases, that's exactly how
> >>NetBeans
> >> works currently. The #1 requirement here is that there should be nightly
> >> builds and that is supported, from your response here.
> >
> >may I ask for whom and what the nightly builds are in your case? If it
> >is for developers only there should be no problem.
>
> Where "developers" is the folks contributing to the code in Apache, not
> users of the code.
> IIRC, there are also restrictions on how folks find out about the
> "nightly" builds.  It can't be listed in the release info on the web site,
> for example.
>
> -Alex
>
>
> ---------
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: Dual-licensed logo PNG (CC-BY 3.0, LGPL 3.0)?

[Niclas Hedhman]

Hi,

I would recommend that we only license that under CC-SA, but you might want
to point out that the media files are also available under LGPL3. The
downstream user can re-apply (or swap with) the LGPL3 if they want to, as
those media files are unmodified and we lay no additional claims.


Cheers
Niclas

On Fri, Aug 26, 2016 at 9:41 PM, Stian Soiland-Reyes <st...@apache.org>
wrote:

> Hi,
>
> Our GSOC student wants to include a PNG for a CWL logo (for
> representing CWL services within Apache Taverna), but the original
> logo is dual-licensed:
>
> From https://github.com/common-workflow-language/logo/blob/
> master/LICENSE.md
>
> > The Common Workflow Language Logos are (C) Copyright 2016 the Common
> Workflow Language Project and are released under the terms of the GNU
> Lesser General Public License, version 3 or any later version, or, at your
> option, of the Creative Commons Attribution-ShareAlike 3.0 Unported License.
>
>
> https://www.apache.org/legal/resolved#cc-sa says:
>
> > Unmodified media under the Creative Commons Attribution-Share Alike 2.5
> and Creative Commons Attribution-Share Alike 3.0 licenses may be included
> in Apache products, subject to the licenses attribution clauses which may
> require LICENSE/NOTICE/README changes. For any other type of CC-SA licensed
> work, please contact the Legal PMC.
>
>
> So I guess our best option is to use it under CC-SA 3.0 - but as LGPL
> 3.0 in this case is not effectively incompatible with ASF license
> either direction (it's easy to replace a PNG file in a JAR) - I don't
> see a reason why we have to remove that dual-license choice for
> downstream users?
>
> That is - my question is - are we fine in NOT specifying which of the
> two licenses we choose to distribute the PNG under?
>
> (This would allow for instance a GPL 3.0 downstream project to embed
> our code AND the logo without re-sourcing it from upstream)
>
>
>
> Here's our student's proposed modifications to append to our project's
> LICENSE:
>
> https://github.com/apache/incubator-taverna-common-
> activities/pull/21/files
>
>
> I assume we don't need to also modify our NOTICE file?  Am I correct
> in this understanding? Or should we do something more, e.g.
> cwl-logo-header.txt file next to the PNG or adding to the README?
>
>
>
> BTW - I have raised an issue upstream about the attribution as "Common
> Workflow Language Project" does not seem to be a legal copyright
> holder:
>
> https://github.com/common-workflow-language/logo/issues/2
>
> ..I guess for now we should respect their current (C) statement.
>
>
> Any feedback?
>
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating), Apache Commons
> 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
>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Number of Podlings

[Niclas Hedhman]

For the podlings that have concerns over the current "incubation branding"
push, I would like to offer an alternative; Push hard to graduate!

I haven't studied the numbers in great detail, but the upward trend is
somewhat bothering. We had a similar rise of concurrent podlings in 2011,
and I recall a strong push to get podlings to graduate, and the data shows
that there was a positive outcome of that, primarily in 2012.

Call to Arms for all Mentors, put in an extra gear and try to nudge the
podlings out of the comfy incubator, and into "scary" TLP (and perhaps a
few rare cases of retirements) territory. ;-)


Cheers
-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

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

Re: [DISCUSS] Incubator Logo & Branding

[Niclas Hedhman]

Suggestion; If such new Incubator logo is to be incorporated on podling
sites, could it also be standardized to have a "hover popup" containing the
standard text and possibly links to further information (both
Incubator-specific as well as podling-specific)?

Cheers
Niclas

On Sat, Jul 2, 2016 at 10:58 AM, Roman Shaposhnik <ro...@shaposhnik.org>
wrote:

> On Fri, Jul 1, 2016 at 7:42 PM, John D. Ament <johndam...@apache.org>
> wrote:
> > On Fri, Jul 1, 2016 at 10:23 PM Roman Shaposhnik <ro...@shaposhnik.org>
> > wrote:
> >
> >> On Fri, Jul 1, 2016 at 7:06 PM, John D. Ament <johndam...@apache.org>
> >> wrote:
> >> > All,
> >> >
> >> > As a follow up to the current discussions happening, I wanted to get
> >> > opinions from the IPMC on whether or not the Incubator logo should be
> >> > included in podling websites.
> >> >
> >> > Take https://wiki.apache.org/incubator/BrandingAuditJune2016 as a
> >> summary
> >> > of podling status.
> >> >
> >> > 29 podlings presently show the Incubator Logo.  1 podling uses a
> custom
> >> > version of the logo.  This means we're just above 50% matching.  The
> >> > branding guide indicates that this is a should, which essentially
> means
> >> > that unless there's some strong reason to not include, it is to be
> >> included
> >> > on the website.
> >> >
> >> > I believe the usage of the Incubator logo comes from including parent
> >> > project logos on sub-project websites, where podlings are essentially
> >> > sub-projects, but I can't find anything confirming this.
> >> >
> >> > If we are to require the logo to be present, we must spell out the
> URL to
> >> > the logo to use.  This may be a variety of logos, include transparency
> >> > effects, with and without borders, but we should guide projects on
> where
> >> to
> >> > find them.
> >>
> >> In general, this is a good idea, but before we all just +1 the heck
> >> out of it, lets
> >> make sure that the intent doesn't penalize the podlings by creating an
> ugly
> >> visual layout for their websites.
> >>
> >
> > Agreed, the discussion will be worthless if its just a series of +1's.
> We
> > can vote when something's been figured out as working.  I suspect that
> will
> > be a rewrite of http://incubator.apache.org/guides/branding.html#logos
>
> Correct.
>
> >> In my view, the best way to think about overall visual layout is along
> the
> >> lines
> >> suggested by Niall in a very much related discussion on Geode:
> >>http://markmail.org/message/e4p5owz5swmcyb7d
> >>
> >> To quote:
> >> ==
> >> Going back to the incubator branding issue, I think Geode should
> >> incorporate the
> >> Incubator logo in its banner at the top of the page, with the aim of
> >> replacing it with
> >> one of the Apache feather logos when it graduates to a TLP.
> >> ==
> >>
> >> I think this is a brilliant way to solve it, but it will require us to
> >> do a bit of graphic design
> >> to dovetail the Incubator artwork into the ASF style. The current logo
> >> clearly doesn't
> >> cut it, but something along the lines of:
> >> http://incubator.apache.org/images/apache-incubator.png
> >> actually might.
> >>
> >
> > Well, i'm not sure that we're the ones to do the graphic design.  We may
> > want to say that one of the incubator logos needs to be incorporated into
> > your design.  You may want to consider that this logo will be replaced by
> > the ASF feather logo once you graduate to a TLP.
> >
> > I also recall pinging Sally a long while ago about a new incubator logo
> > based on the new feather design.
>
> At this point, I honestly think that we may want to go back and make
> it a priority.
>
> Given the number of podlings in the incubator it is clear to me that
> the incubator
> visual identity should be treated on-par with ASF's visual identity.
> Yes, we're that
> important. We didn't scribble the new ASF's visual identity on a
> napkin -- we actually
> hired professionals. I think we have a pretty strong case for the IPMC
> of the same.
>
> Thanks,
> Roman.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: [ALL] Volunteers for a Math IPMC?

[Niclas Hedhman]

If you have a functioning community around Commons Math already, why do you
feel you need Incubation?

People on a Math TLP would come out of the Commons PMC and simply submit a
Board Resolution, and I doubt that there would be any objects. There are no
legal concerns, no community training, no need for release management
training, and so on...

Or are you looking at a situation where the Commons community has no
interest in Math subproject, and need new blood?


Cheers
Niclas

On Sat, Jun 11, 2016 at 6:25 PM, James Carman <ja...@carmanconsulting.com>
wrote:

> We (the Commons PMC) have not decided yet what to do, but I just wanted to
> gauge the interest in joining the math IPMC if we choose to go TLP by way
> of the incubator. The idea would be that math (whatever its name may be),
> would go through the incubator in order to enrich its community prior to
> becoming a TLP. Do we have any folks willing to throw their hat in the
> ring?
>
> p.s. I've cross-posted to the incubator list as there are folks there who
> are very good at this stuff and could perhaps lend us some advice.
>



-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: [DICSUSS] Graduation of Apache Twill as Top Level Project

[Niclas Hedhman]

org>
> >
> > * Henry Saputra <hsapu...@apache.org>
> >
> >
> >   NOW, THEREFORE, BE IT FURTHER RESOLVED, that Terence Yim
> >
> >   be appointed to the office of Vice President, Apache Twill, 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 Twill 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 Twill Project; and be it further
> >
> >
> >   RESOLVED, that the Apache Twill Project be and hereby
> >
> >   is tasked with the migration and rationalization of the Apache
> >
> >   Incubator Twill podling; and be it further
> >
> >
> >   RESOLVED, that all responsibilities pertaining to the Apache
> >
> >   Incubator Twill podling encumbered upon the Apache Incubator
> >
> >   Project are hereafter discharged.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: Number of projects in Incubation [was: [VOTE] Release Apache Mynewt 0.9.0-incubating-rc1]

[Niclas Hedhman]

And where is the sources for that?

On Sat, May 28, 2016 at 11:27 AM, Daniel Gruno <humbed...@apache.org> wrote:

> On 05/28/2016 05:25 AM, Niclas Hedhman wrote:
> > Thanks Justin,
> > as always, snapshots in time is not as useful as trending data over
> time. I
> > guess it is time to take a look at whimsy.. :-)
>
> Or projects.apache.org :) Since there's already an incubator chart there
> - should be easy to add another one.
>
> >
> > Cheers
> >
> > On Sat, May 28, 2016 at 9:38 AM, Justin Mclean <jus...@classsoftware.com
> >
> > wrote:
> >
> >> Hi,
> >>
> >>> An additional graph that would be super-interesting to get is "Months
> in
> >>> Incubation" for the current podlings, plotted over time.
> >>
> >> Some of the data can be found here [1] (column B)
> >>
> >> Thanks,
> >> Justin
> >>
> >> 1. http://incubator.apache.org/clutch.html
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >>
> >
> >
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: Number of projects in Incubation [was: [VOTE] Release Apache Mynewt 0.9.0-incubating-rc1]

[Niclas Hedhman]

Thanks Justin,
as always, snapshots in time is not as useful as trending data over time. I
guess it is time to take a look at whimsy.. :-)

Cheers

On Sat, May 28, 2016 at 9:38 AM, Justin Mclean <jus...@classsoftware.com>
wrote:

> Hi,
>
> > An additional graph that would be super-interesting to get is "Months in
> > Incubation" for the current podlings, plotted over time.
>
> Some of the data can be found here [1] (column B)
>
> Thanks,
> Justin
>
> 1. http://incubator.apache.org/clutch.html
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Number of projects in Incubation [was: [VOTE] Release Apache Mynewt 0.9.0-incubating-rc1]

[Niclas Hedhman]

I respectfully disagree... One of the main reasons we went from 1 to 3
recommended mentors, way back in the days, was that those 3 would be the
primary people to ping for binding votes, without limiting the rest of the
IPMC to do so.

If that is no longer the consensus, then we need to look at the bigger
picture.
At the moment, the number of incubating projects are staggering (>50), and
take a look at https://projects.apache.org/ . I think it looks like both
the RATE-Incomng is increasing and the RATE-graduating is slowing down
recently, OR that there was a particularly strong effort to get projects to
graduate in 2011-2012 to bring the incubation set down.
Either way, I think we need to manage to drive down the number of projects
in incubation.

An additional graph that would be super-interesting to get is "Months in
Incubation" for the current podlings, plotted over time.

Cheers
Niclas

On Sat, May 28, 2016 at 8:32 AM, Justin Mclean <jus...@classsoftware.com>
wrote:

> Hi,
>
> > I think you need to ping your mentors, and if they are not able, then I
> > think you need to raise this as an issue with the Incubator PMC, either
> in
> > separate thread or put it in the report for next month.
>
> AFAIK it's not the responsibility of the mentors to vote, it's the
> responsibility of the IPMC. Mentors should vote if they can, but there’s
> going to be times when they are busy and unable to do so.
>
> > I am not on the PMC, and can't help at this point.
>
> Anyone can vote on a release you don’t have to be on the IPMC to do so.
> IPMC votes are the only binding votes however. But voting on releases may
> be a way to join the IPMC if you are not an ASF member.
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: [VOTE] Release Apache Mynewt 0.9.0-incubating-rc1

[Niclas Hedhman]

t;>  repos:
>>>> https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt
>>>>  commit: 0afe655414bbefc922d2adfddf238479bedac5c0
>>>>
>>>> In addition, the following newt convenience binaries are available:
>>>>  linux:
>>>> https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-0.9.0-incubating/rc1/apache-newt-bin-linux-0.9.0-incubating.tgz
>>>>  osx:
>>>> https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-0.9.0-incubating/rc1/apache-newt-bin-osx-0.9.0-incubating.tgz
>>>>
>>>> The release candidate is signed with a GPG key available at:
>>>> https://dist.apache.org/repos/dist/dev/incubator/mynewt/KEYS
>>>>
>>>> The vote is open for at least 72 hours.
>>>>
>>>> [ ] +1 Release this package
>>>> [ ]  0 I don't feel strongly about it, but don't object
>>>> [ ] -1 Do not release this package because…
>>>>
>>>> Thanks,
>>>> Chris
>>>>
>>>
>>> -
>>> 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
>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: [DISCUSS] PredictionIO incubation proposal

[Niclas Hedhman]

Funny quote of the day at a conference in Beijing; "The best way to predict
the future is to create it."  ;-)

Cheers
Niclas

On Sat, May 21, 2016 at 1:51 AM, Andrew Purtell <apurt...@apache.org> wrote:

> ​​The proposal excludes the Template Gallery from inclusion in the initial
> software grant and sets it up as an issue for the podling to tackle during
> incubation.
>
> "The PredictionIO community also maintains a​ ​Template Gallery, a place to
> publish and download (free or proprietary) engine templates for different
> types of machine learning applications, and is a complemental part of the
> project. At this point we exclude the Template Gallery from the proposal,
> as it has a separate set of contributors and we’re not familiar with an
> Apache approved mechanism to maintain such a gallery.​"
>
> I agree with the proposers that tracking down a large set of contributors
> to get their ok for a consolidated grant would be onerous.
>
>
>
> On Fri, May 20, 2016 at 9:14 AM, Pat Ferrel <p...@occamsmachete.com> wrote:
>
> > +1 for the current committer list, but please, anyone interested get
> > familiar, we will need more help soon!
> >
> > Also I’d like to bring up the template gallery again. Plugins may be
> > problematic in other projects but pio does nothing of interest *without*
> a
> > template. There are some examples in the core repo but...
> >
> > Questions:
> > 1) can the gallery be transferred? This is just a listing of templates
> > that may be maintained by external people and is the source from which
> they
> > are downloaded by default.
> > 2) which templates are proposed for the transfer? Didn’t see that spelled
> > out beyond the included examples.
> >
> > On May 20, 2016, at 8:53 AM, Suneel Marthi <smar...@apache.org> wrote:
> >
> > The current list is good to go and includes all (both present and former)
> > PIO folks.
> > I am fine with going for Voting with the present list.
> >
> > +1
> >
> > On Fri, May 20, 2016 at 11:47 AM, Andrew Purtell <apurt...@apache.org>
> > wrote:
> >
> > > The current list of initial committers was that provided me by the
> > > PredictionIO folks so I have every reason to believe they all have a
> > stake
> > > at entering incubation.
> > >
> > > It's totally fine with me if we stick to that list. I am just trying to
> > > facilitate the fairest process possible.
> > >
> > >
> > > On Friday, May 20, 2016, Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
> > >
> > >> On Thu, May 19, 2016 at 9:16 PM, Suneel Marthi <smar...@apache.org
> > >> <javascript:;>> wrote:
> > >>> I definitely have concerns about too many folks becoming initial
> > >> committers
> > >>> and bringing their own corporate agendas to this project.
> > >>>
> > >>> I suggest that first we vote PIO into incubator then bring in those
> > > less
> > >>> experienced with the project. We have a good start with people who
> have
> > >>> worked on the project from several orgs. Let us get organized first
> and
> > >>> then bring in new people.
> > >>
> > >> I think this is a reasonable concern. Andrew, any chance you can look
> > > over
> > >> the names of initial committers and let us know who has had a stake in
> > > the
> > >> project before entering the incubation vs. those who are trying to
> join
> > > in
> > >> as
> > >> part of the ASF Incubation.
> > >>
> > >> I'm not saying we need to pass judgement one way or the other yet, but
> > it
> > >> will be a very useful data point to know before voting.
> > >>
> > >> Thanks,
> > >> Roman.
> > >>
> > >> -
> > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > >> <javascript:;>
> > >> For additional commands, e-mail: general-h...@incubator.apache.org
> > >> <javascript:;>
> > >>
> > >>
> > >
> > > --
> > > Best regards,
> > >
> > >   - Andy
> > >
> > > Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> > > (via Tom White)
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>
>
> --
> Best regards,
>
>- Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>



-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: RTC vs CTR (was: Concerning Sentry...)

[Niclas Hedhman]

I have now, days later, Reviewed this Thread and Commit to a veto of the
whole debate, Can't agree That it is Rewarding for anyone... ;-)

On Sat, Nov 21, 2015 at 2:50 AM, Todd Lipcon <t...@apache.org> wrote:

> On Thu, Nov 19, 2015 at 6:49 PM, Greg Stein <gst...@gmail.com> wrote:
>
> > Todd: as Ross notes, your three points about code reviews in a CTR
> project
> > are quite valid, and match accepted engineering practices.
> >
> > What I haven't seen is an explanation why a committer must be treated the
> > same as a drive-by. Both are subject to requiring "permission"[1] to make
> > even the simplest of changes under RTC. Even worse, from else-thread, it
> > sounds like under your control scheme, you don't even allow the committer
> > to apply their own change [after review].
>
>
> They can apply their own change once someone else has +1ed it. On Hadoop,
> for example, the usual workflow when I review another committer's patch is
> that I give them a +1 and they commit it themselves. On gerrit or github,
> because the actual "commit" process is just clicking a button on a web UI,
> it's more normal for the reviewer to be the one to commit it after giving
> the +1 review, but both happen and either one's fine.
>
>
> > A committer can give a binding +1
> > to somebody else's work. But they aren't trusted to give that to their
> own
> > work. Just like a drive-by contributor can't be trusted.
> >
>
> Right, they can't give it to their own work because it defeats the purpose
> of the code review (discussed earlier).
>
> Of course it's not hard and fast -- eg fixing a broken build due to a
> missing 'import' statement or something would be totally fine to commit
> without review, or fixing a grammar mistake in a comment, or anything else
> that's obviously trivial. But once actual code is changing, it's expected
> to get two pairs of eyes.
>
> -Todd
>



-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: apache binary distributions

[Niclas Hedhman]

Cool.
I can't find info on how much it costs ASF, any pointers before embarking
on 100+ artifact signing spree... ;-)

On Fri, Aug 21, 2015 at 12:35 AM, William A Rowe Jr wr...@rowe-clan.net
wrote:

 On Thu, Aug 20, 2015 at 8:09 AM, Niclas Hedhman nic...@hedhman.org
 wrote:

  On Thu, Aug 20, 2015 at 1:06 AM, William A Rowe Jr wr...@rowe-clan.net
  wrote:
 
   There are some special things here we do have absolute control over.
 If a
   project wants to provide the 'official' build, why not start signing
  the .jar?
 
  Good idea, but to be practical to users, the certificate for the signing
  needs to be part of the certificate chain of the JVM (otherwise those
 would
  be needed to be installed on every host). I don't know how willing infra
  would be to support PKI at ASF for this, otherwise many projects will be
  limited due to cost (I could be wrong by now and that there are totally
  free CAs)
 

 That infrastructure now exists through code signing service by Symantec.
 One PMC member (or more) gets their own unique log in, pushes the artifact
 (.jar, in this example) to the service and is returned a signed artifact
 reflecting the ASF providence.

 The interesting thing is the actual cert is unique to the object, so if it
 is discovered that it was compromised, the signature can be revoked (good
 luck having sig revocations active at boot time, but otherwise this is
 quite useful.) And because there is a history, we know who precisely
 requested each object signing.




-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: What is the legal basis for enforcing release policies at ASF?

[Niclas Hedhman]

I think it is somewhat amusing, that this is actually discussed ~20years
after Apache group is formed. A newcomer must be flabbergasted that this
isn't clear cut by now... ;-)

// Niclas

On Fri, Aug 21, 2015 at 10:37 AM, Ross Gardler ross.gard...@microsoft.com
wrote:

 I do not agree with this interpretation when viewed from a legal angle
 (though I do agree from a trademark angle). I have a feeling that the root
 of my disagreement is the same as the root of Jim's earlier statement
 (though I may be mistaken).

 There are two points of IP due diligence in an Apache project: At the
 point of contribution where the IP is validated by the committer and zero
 or more people who review the patch. The second phase of IP validation is
 at the point of release, where 3 our more PMC members validate that the
 foundation can legally release the code.

 This means that taking a snapshot and building a release is *not*
 trademark-acceptable since the foundation, through the project PMC has not
 approved the release, therefore it is not an Apache release.

 Only the ASF gets to say what is an ASF release and to do so requires a
 vote of the PMC. It has nothing to do with the number of changes made to
 what is in our repositories. It has everything to do with whether it's a
 release of the foundation.

 So, in the strictest sense, distributions that make minor changes for
 their distribution should call it Bar powered by Apache Foo in order to
 differentiate it from an official release of the foundation. In the real
 world the question is, from a legal point of view, do we care?

 (lets ignore the fact that some people vote on releases without doing
 proper validation, that's why we require 3 +1 votes, the assumption is that
 at least one of them did the job properly)

 Sent from my Windows Phone
 
 From: William A Rowe Jrmailto:wr...@rowe-clan.net
 Sent: ‎8/‎20/‎2015 7:17 PM
 To: general@incubator.apache.orgmailto:general@incubator.apache.org
 Subject: Re: What is the legal basis for enforcing release policies at ASF?

 On Thu, Aug 20, 2015 at 9:03 PM, Benson Margulies bimargul...@gmail.com
 wrote:

  This thread started as a discussion of Linux distros and trademarks.
  Perhaps I could try to return it there?
 
  If a distro takes a release of Apache X, compiles it with minimal changes
  that adapt it to the environment, and distributes it, I believe that
 it's a
  fine thing for them to call it simple Apache X, and acknowledge our
 marks.
 
  If a distro takes a release of Apache X, and make significant changes to
  it, and then distributes it, I believe that it's not OK with us for them
 to
  simply call it Apache X. I've seen some evidence that Gentoo Linux makes
 a
  regular habit of this, because their policies drive them to make some
  pretty scary changes in some cases. Others may not share my view.
 
  Further, if someone takes a snapshot (small 's') from source control and
  starts from that, with minimal changes, I think that this would also be
  trademark-acceptable, so long as they accurately describe what they did.
 
  The operative concept here, as Shane has taught it, is 'confusion in the
  marketplace.' If some third party behaves so as to cause confusion as to
  the identity of Apache X, there's a trademark issue. If not, not.
 

 You summed this up to the best of my understanding ... +1.  If our legal VP
 agrees (and retracts earlier FUD) it appears we are entirely in agreement.




-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: apache binary distributions

[Niclas Hedhman]

On Thu, Aug 20, 2015 at 1:06 AM, William A Rowe Jr wr...@rowe-clan.net
wrote:


 There are some special things here we do have absolute control over. If a
 project wants to provide the 'official' build, why not start signing the
 .jar?


Good idea, but to be practical to users, the certificate for the signing
needs to be part of the certificate chain of the JVM (otherwise those would
be needed to be installed on every host). I don't know how willing infra
would be to support PKI at ASF for this, otherwise many projects will be
limited due to cost (I could be wrong by now and that there are totally
free CAs)

Cheers
-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: apache binary distributions

[Niclas Hedhman]

I was indeed talking of publishing the original material, released properly
from Apache but with some minor changes to fit into the SteveNick
Platform (whatever that might be). I think that is analogous...

So, if we agree that is all the same... minor alterations of official
releases

That said, I think/suspect that if Cloudera Hadoop or Hortonworks
Hadopo is published in this manner (official releases with minor changes
to fit their bigger picture), there might be quite a lot of noise... Just
asking... I have no strong opinion in either way, other than I would like
to see consistency.

Cheers
Niclas


On Wed, Aug 19, 2015 at 1:15 PM, Marvin Humphrey mar...@rectangular.com
wrote:

 On Tue, Aug 18, 2015 at 6:46 PM, Niclas Hedhman nic...@hedhman.org
 wrote:

  Well, if  Debian can publish their built Apache Maven as maven and
  SteveNick can't publish their built Apache Maven as maven, then the
  inescapable question is; On what non-arbitrary grounds is one acceptable
  and the other is not? It can't be we like Debian, but not SteveNick,
  that is morally weak.

 We need to distinguish between two situations:

 *   Redistributor starts from official Apache release.
 *   Redistributor starts from unreleased code.

 Debian consumes official Apache releases, and they make changes that are
 often very small.  Whether we should be aggressive in enforcing our
 trademarks
 under those circumstances is a judgment call.  Should SteveNick also
 start
 from an official release and make changes of similar scope to those made by
 Debian, I would agree that the case for enforcing our trademarks would be
 roughly analogous.

 However, if SteveNick are Apache project contributors publishing
 unreleased
 code and making an end run around Apache release policy, there's greater
 cause
 for concern.

 *   Are other PMC members being denied their right to participate in
 release
 decision making?
 *   To what extent does the privileged position afforded SteveNick
 undermine project independence?
 *   While our communities strive to maintain codebases in compliance with
 Apache legal and release policies, we accept that raw repository code
 may
 be imperfect between releases.  Just how far out of compliance is the
 unreleased code SteveNick are publishing under our trademark?
 *   To what extent is the 501(c)(3) status of the Foundation put at
 increased risk by the actions of this project?  What if the practices
 spread to other projects?

 If Debian were to systematically consume unreleased code from us (aside
 from
 patches they've contributed themselves), I imagine we would have similar
 concerns.  But that seems like a weird theoretical.

 Marvin Humphrey

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




-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: Podlings and the ASF maturity model (was: Reform of Incubator...)

[Niclas Hedhman]

Bertrans,
yes, something like that. I think a simple page in the regular
documentation is good enough, which states the model items, whether fully
complies with it, and if not why that is the case. Start out to make it a
recommendation to all podlings to take a look and incorporate, thumbs up
for those who do it, and over time increase the pressure a little bit.

On Thu, Aug 6, 2015 at 3:28 PM, Bertrand Delacretaz bdelacre...@apache.org
wrote:

 On Thu, Aug 6, 2015 at 8:46 AM, Niclas Hedhman nic...@hedhman.org wrote:
  ...the maturity model shouldn't be a set of gating criteria, but that the
  podling should self-assess its position and to what degree, as well as
 how,
  each point is handled. Yes, many of the points are non-negotiable, but
  don't claim that all are...

 So you would see the maturity model as one element of the Incubation
 graduating checklist, with self-assessment from the podling and its
 mentors? I like the idea.

 -Bertrand

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




-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: What is the legal basis for enforcing release policies at ASF?

[Niclas Hedhman]

Bill,
So I can release Niclas Hadoop platform, based on Apache Hadoop ?? I
thought the discussion a few years ago was that this was misleading...



On Fri, Aug 7, 2015 at 12:30 PM, William A Rowe Jr wr...@rowe-clan.net
wrote:

 On Thu, Aug 6, 2015 at 7:50 PM, Roman Shaposhnik ro...@shaposhnik.org
 wrote:

  Hi!
 
  while answering a question on release policies and ALv2
  I've suddenly realized that I really don't know what is the
  legal basis for enforcing release policies we've got
  documented over here:
 http://www.apache.org/dev/release.html
 
  For example, what would be the legal basis for stopping
  a 3d party from releasing a snapshot of ASF's project
  source tree and claim it to be a release X.Y.Z of said
  project?
 

 Nothing other than the Trademarks.

 If someone wants to call httpd trunk 3.0.1-GA, they cannot do this as
 Apache httpd 3.0.1-GA or Apache HTTP Server 3.0.1-GA.

 They can certainly release trunk under the AL license and call it Kindred
 Http Server 3.0.1-GA, based on Apache HTTP Server. That is a statement of
 fact and not an abuse of the mark, IMHO. (If it was not actually based on
 Apache HTTP Server, then that would similarly be a Trademark infringement
 as it is a false use of the mark.)

 There are no less than two marks, one is the name of the foundation itself
 in conjunction with Open Source Software, and the other is the specific
 project name.




-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: apache package naming convention

[Niclas Hedhman]

By that notion, practically all incoming projects would be in non
org.apache namespaces, and that would be a different kind of detrimental
situation.

So, my(!) general recommendation has been; for any releases that maintain
100% compatibility, keep the namespace as before. But as soon as a major
(1.x - 2.0) release is made, that the namespace is changing with it.

Doing a search/replace for s/import datafu/import org.apache.datafu
across N files (and you can provide the script) is not a big deal compared
to whatever other compatibility-breaking changes that are introduced in the
major upgrade.

But as Luciano says; The sooner, the better, as fewer people are impacted.

Niclas

On Sat, Aug 8, 2015 at 6:55 AM, Russell Jurney russell.jur...@gmail.com
wrote:

 Leave it datafu. The normal way of doing Java namespaces is terrible bloat,
 and the change would be breaking.

 On Friday, August 7, 2015, Luciano Resende luckbr1...@gmail.com wrote:

  On Fri, Aug 7, 2015 at 3:16 PM, Matthew Hayes 
  matthew.terence.ha...@gmail.com javascript:; wrote:
 
   Hi all,
  
   Roman Shaposhnik suggested I open a discussion on the following topic:
  
   For Apache DataFu, all of the Java classes are declared in a datafu.*
   namespace.  This has been the naming convention since the DataFu
 project
   started in 2010.  Since DataFu became part of the Apache incubation
   process, the topic has come up of moving all of the classes into a
   org.apache.datafu.* namespace.  This was first discussed in January
 2014
   (see DATAFU-7) and most recently again in the past couple weeks.  The
   consensus at the time last year was that it would be a huge pain for
  users
   and not worth the cost.  It would break any script out there currently
   using DataFu.  Also Jakob Homan and Russell Journey pointed out that
 this
   is just a convention and not all Apache projects follow it.  Since we
  would
   like DataFu to graduate sometime soon it would be good to clarify what
  the
   requirements are on package naming conventions before we do a release.
  
   Thoughts?
  
   Thanks,
   Matt
  
 
  Current statement on Incubator website
 
  http://incubator.apache.org/guides/mentor.html#repackaging
 
  But, if DataFu will do the repackaging, better sooner (before graduation)
  then later.
 
 
  --
  Luciano Resende
  http://people.apache.org/~lresende
  http://twitter.com/lresende1975
  http://lresende.blogspot.com/
 


 --
 Russell Jurney twitter.com/rjurney russell.jur...@gmail.com
 datasyndrome.com




-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: apache binary distributions

[Niclas Hedhman]

On Thu, Aug 6, 2015 at 8:43 AM, Roman Shaposhnik ro...@shaposhnik.org
wrote:

 I honestly see no problem with that, again provided that the artifact can
NOT
 be confused with the one coming from Apache project.

I think the problem lies in Trademarks. Debian's Tomcat7 is labeled
Servlet and JSP engine and its Tomcat8 is labeled Apache Tomcat 8 -
Servlet and JSP engine, yet I don't see Apache Tomcat project
creating/maintaining a Debian dist.

Now, is Debian allowed to call it Tomcat? Is it allowed to call Tomcat8
to BE Apache Tomcat8, when in fact(!) there are changes to the source,
such as the start script in Debian Tomcat is not original of Apache Tomcat,
but instead follows a Debian template for how those scripts should be
written. I am not sure what all the changes are, feel free to check;
http://anonscm.debian.org/cgit/pkg-java/tomcat8.git/tree/debian/patches

IF (like Mozilla) Apache decides to strike down on Debian and not allowing
it to use the same names, _I_ think it is a disservice to the users
(IceWeasel browser), but as it stands, Apache trademark licensing seems to
not really be followed (Perhaps Debian has some permission that was granted
long in the past... I may have missed that).


Cheers
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: apache binary distributions

[Niclas Hedhman]

 *could*
 be considered an official binary convenience artifact for the release
 (see my point above on 3d part vs. PMCs actually producing these
 binaries).

 IOW, what makes a binary convenience artifact an official ASF
 artifact is not whether it got designated as such, but whether it
 corresponds to an official source release produced by the PMC.

  Same for links for example to docker image distribution servers...
  or let's say a link to an ubuntu package. On the other hand you
  can put disclaimers on the pages stating they are not official...

 But they are. If they correspond to an official release.

  Then again nightly builds should be ok, if they will have the
  same disclaimer?

 No. Nightly builds are special precisely because they don't
 correspond to an official source release.

  Or is it ok if the nightly build comes from
  non-apache?

 It is ok, but at that point it becomes 3d party artifact and as
 such can't be promoted as part of ASF project.

  If that is ok, then why does the release document
  not say this and is instead very strict about not promoting anything
  even beyond the dev-list? It does not make sense for me and I
  am going in circles here.

 Perhaps the source of confusion is that ironically PMCs are *more*
 constrained in what they can do compared to 3dparty. They do get
 the Apache Branding rights in return for those constraints, though.

  Of course a third person would be someone unrelated to the project.

 Or related. Could even be one of the PMC members. The point
 is: it is NOT PMC.

  So what they do is of lesser concern, unless they misuse things.
  But what if the person is ASF member, or contributor to that project,
  maybe even in the PMC? For example... assuming I would provide
  snapshot of Groovy on an external server and the web page
  mentions how to get this with a disclaimer, would that be ok?
  Even if it is a nightly build?

 As I said -- that person(*) (even a PMC member of the project) as
 a person has even more rights than a PMC does, except in one
 crucial area -- that person can NOT speak on behalf of the project
 (and that includes linking to that person's artifacts from the PMC
 managed assets: website, wiki, etc.).

 Other than that, that person is absolutely free to:
#1 produce maven binaries based on, really anything,
 including but not limited to snapshot of source tree
#2 distribute those binaries however he/she sees fit
 provided they can't be confused with project's binaries.
 Modifying versionID while leaving everything else
 as-is is considered acceptable.

 #2 of course may be subject to constraints of distribution
 channel. An example is a recently  cited Maven Central
 policy where they are NOT allowing to publish SNAPSHOTs
 AND they only allow owners of the groupID to publish.
 Those constraints, of course, have nothing to do with
 ASF or the project -- those are Maven Central constraints.

 Thanks,
 Roman.

 (*) as all of us living in US know: corporations are people too.

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




-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: Podlings and the ASF maturity model (was: Reform of Incubator...)

[Niclas Hedhman]

Of course there are...

CD40 - podlings may not have this prior to coming ASF, hence the full
history might not be available.

RE40 - interesting clause in itself, both the can be and the caveat in it
no guarantee. IMHO, shouldn't be there at all.

QU20 - Highly subjective as noted in footnote 7, and every project would
need to examine a reasonable level of security awareness and response
strategy, and often there will be varying opinions on what is appropriate.

QU40 - That is mostly a function of how popular a project is, and how the
project's code is intended to be used.

QU50 - How do you check list-ticking the strive to qualifier?

CO70 - another strive to...

CS50 - a funny one, actually two... Mailing lists are not spelled out, and
in theory YouTube videos and response videos could serve as asynchronous
channel. Also, it doesn't mention that such channel needs to be provided
by ASF infrastructure.

IN10/IN20 - I claim that many projects would fail if all companies decided
to pull their man-power support away. I happen to think it is relatively
good, as that provides use-cases and requirements, but the agendas are
there under the surface, and it should be recognized as a fact, rather than
pretending it isn't.



So, the maturity model shouldn't be a set of gating criteria, but that the
podling should self-assess its position and to what degree, as well as how,
each point is handled. Yes, many of the points are non-negotiable, but
don't claim that all are...
And if it is gating criteria for becoming a TLP, then likewise it should be
a reversed gating criteria for going to Attic.

Cheers
Niclas

On Thu, Aug 6, 2015 at 8:01 AM, Roman Shaposhnik ro...@shaposhnik.org
wrote:

 On Wed, Aug 5, 2015 at 12:43 AM, Bertrand Delacretaz
 bdelacre...@apache.org wrote:
  Hi,
 
  On Wed, Aug 5, 2015 at 12:24 AM, Dennis E. Hamilton
  dennis.hamil...@acm.org wrote:
  ...I understand the maturity model to be something to aspire to and
 that Apache Projects
  will always be working toward it.  I mean TLPs, not podlings, although
 podlings should be
  aware of it and also aspire to it...
 
  I don't see why podlings should be different here, once they are about
  to graduate.
 
  Why can't we define our incubation process as a way for podlings to
  learn to operate according to that maturity model [1]?
 
  This would allow us to use the maturity model [1] as a checklist for
  graduating podlings - do you see anything in there that shouldn't be
  required from a podling that's about to graduate?

 I see it as a useful checklist that may uncover interesting issues within
 the graduating podling. I don't see anything in there that would qualify
 as an unambiguous gating criteria.

 Thanks,
 Roman.

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




-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

List of all Current Incubator Projects

[Niclas Hedhman]

On this page; http://incubator.apache.org/ there is a list of current
projects.

I saw SAMOA listing Apache S4 (which I hadn't heard of) and it doesn't
show up on that list.

Is it manually maintained, or is it auto-generated somehow?

Cheers
-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java