Re: May I please have permission to edit the wiki

[Adrian Cole]

Thanks! Is adriancole also authorized now?

On Tuesday, April 16, 2013, Marvin Humphrey wrote:

> On Tue, Apr 16, 2013 at 12:13 PM, Matt Stephenson 
> >
> wrote:
> > I'm helping out with the jclouds incubation.  My username is
> MattStephenson
>
> Done.
>
> Marvin Humphrey
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: 
> general-h...@incubator.apache.org
>
>

Re: May I please have permission to edit the wiki

[Adrian Cole]

Thanks!

On Tuesday, April 16, 2013, Christian Grobmeier wrote:

> On Tue, Apr 16, 2013 at 9:26 PM, Adrian Cole 
> >
> wrote:
> > Thanks! Is adriancole also authorized now?
>
> I just added you
>
> Cheers
>
>
>
> > On Tuesday, April 16, 2013, Marvin Humphrey wrote:
> >
> >> On Tue, Apr 16, 2013 at 12:13 PM, Matt Stephenson <
> matts...@mattstep.net >
> >> wrote:
> >> > I'm helping out with the jclouds incubation.  My username is
> >> MattStephenson
> >>
> >> Done.
> >>
> >> Marvin Humphrey
> >>
> >> -
> >> To unsubscribe, e-mail: 
> >> general-unsubscr...@incubator.apache.org
> 
> >> For additional commands, e-mail: 
> >> general-h...@incubator.apache.org
> 
> >>
> >>
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: 
> general-h...@incubator.apache.org
>
>

Re: [PROPOSAL] jclouds Proposal for Incubator

[Adrian Cole]

Thanks for the offers to mentor, folks.  I've noticed there's a new
"Volunteer" section below, so feel free to add in there :)

http://wiki.apache.org/incubator/jcloudsProposal

Thanks for the support and hope we get accepted!
-A


On Tue, Apr 16, 2013 at 12:27 PM, Mohammad Nour El-Din <
nour.moham...@gmail.com> wrote:

> Hi
>
> Sent from my Samsung Galaxy S3
> Apologies for any typos
> On Apr 16, 2013 9:20 PM, "David Nalley"  wrote:
> >
> > On Tue, Apr 16, 2013 at 2:34 PM, Rebecca Wood 
> wrote:
> > > Dear ASF members,
> > > We would like to propose the jclouds project to the Incubator.  The
> jclouds Proposal is available at:
> > >
> > > http://wiki.apache.org/incubator/jcloudsProposal
> > >
> > > We welcome your feedback and suggestions.
> >
> > Excited to see jclouds proposal.
> > If you are looking for additional mentors, I'd be happy to step up.
> >
>
> Indeed, jclouds is a perfect fit to Apache Cloud ecosystem
>
> I add my enthusiasm to David's about additional mentors
>
> > --David
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>

Re: [PROPOSAL] jclouds Proposal for Incubator

[Adrian Cole]

Thanks for the offers for help, folks.  I've added JB and Mohammad as
mentors, which pretty much fills the bench in the process area.
http://wiki.apache.org/incubator/jcloudsProposal

David, I'm sure we could use extra hands in other aspects of incubation.
 Hope to see you around as work together on the Apache Cloud ecosystem.

-A


On Tue, Apr 16, 2013 at 2:51 PM, Adrian Cole  wrote:

> Thanks for the offers to mentor, folks.  I've noticed there's a new
> "Volunteer" section below, so feel free to add in there :)
>
> http://wiki.apache.org/incubator/jcloudsProposal
>
> Thanks for the support and hope we get accepted!
> -A
>
>
> On Tue, Apr 16, 2013 at 12:27 PM, Mohammad Nour El-Din <
> nour.moham...@gmail.com> wrote:
>
>> Hi
>>
>> Sent from my Samsung Galaxy S3
>> Apologies for any typos
>> On Apr 16, 2013 9:20 PM, "David Nalley"  wrote:
>> >
>> > On Tue, Apr 16, 2013 at 2:34 PM, Rebecca Wood 
>> wrote:
>> > > Dear ASF members,
>> > > We would like to propose the jclouds project to the Incubator.  The
>> jclouds Proposal is available at:
>> > >
>> > > http://wiki.apache.org/incubator/jcloudsProposal
>> > >
>> > > We welcome your feedback and suggestions.
>> >
>> > Excited to see jclouds proposal.
>> > If you are looking for additional mentors, I'd be happy to step up.
>> >
>>
>> Indeed, jclouds is a perfect fit to Apache Cloud ecosystem
>>
>> I add my enthusiasm to David's about additional mentors
>>
>> > --David
>> >
>> > -
>> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> > For additional commands, e-mail: general-h...@incubator.apache.org
>> >
>>
>
>

Re: [PROPOSAL] jclouds Proposal for Incubator

[Adrian Cole]

Tomaz and Olivier (and David)

You guys are awesome to offer help.  I thought maybe 5 was the number of
mentors we needed, but I heard a sentiment of "the more the merrier"  So,
I'm adding any apache member with experience with incubation that offers to
help us.  Seems a better problem to have more advice than less, and now a
fleet of apache members can take holiday and we can still get enough votes
to release something :)

Cheers, thanks for the kind words, and lets do this!
-A


On Tue, Apr 16, 2013 at 4:45 PM, Tomaz Muraus  wrote:

> Agreed and best of luck from the Apache Libcloud PMC :)
>
> If you are looking for additional mentors I'm also more than happy to help.
>
> (I would add myself under "volunteer" section on the wiki, but it looks
> like I don't have the necessary permissions).
>
> On Tue, Apr 16, 2013 at 12:19 PM, David Nalley  wrote:
>
> > On Tue, Apr 16, 2013 at 2:34 PM, Rebecca Wood 
> wrote:
> > > Dear ASF members,
> > > We would like to propose the jclouds project to the Incubator.  The
> > jclouds Proposal is available at:
> > >
> > > http://wiki.apache.org/incubator/jcloudsProposal
> > >
> > > We welcome your feedback and suggestions.
> >
> > Excited to see jclouds proposal.
> > If you are looking for additional mentors, I'd be happy to step up.
> >
> > --David
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: [PROPOSAL] jclouds Proposal for Incubator

[Adrian Cole]

Thanks, Suresh.  Airavata looks like it has context for collaboration with
jclouds for sure.

WRT mentoring, I was going to warn you.. all mentors have implicitly signed
up for 2 hours/week on process guidance and 35 jumping jacks.

-A


On Tue, Apr 16, 2013 at 4:59 PM, Suresh Marru  wrote:

> Nice Proposal, looking forward to see jcloud flourish in Apache. Glad to
> see such a overwhelming mentor support.
>
> I am interested to see this as an abstraction for Apache Airavata, I do
> not think you need more mentors, but I will be happy to help as needed as
> well (either onboard as mentor or on this list).
>
> Cheers,
> Suresh
>
> On Apr 16, 2013, at 7:51 PM, Adrian Cole  wrote:
>
> > Tomaz and Olivier (and David)
> >
> > You guys are awesome to offer help.  I thought maybe 5 was the number of
> > mentors we needed, but I heard a sentiment of "the more the merrier"  So,
> > I'm adding any apache member with experience with incubation that offers
> to
> > help us.  Seems a better problem to have more advice than less, and now a
> > fleet of apache members can take holiday and we can still get enough
> votes
> > to release something :)
> >
> > Cheers, thanks for the kind words, and lets do this!
> > -A
> >
> >
> > On Tue, Apr 16, 2013 at 4:45 PM, Tomaz Muraus  wrote:
> >
> >> Agreed and best of luck from the Apache Libcloud PMC :)
> >>
> >> If you are looking for additional mentors I'm also more than happy to
> help.
> >>
> >> (I would add myself under "volunteer" section on the wiki, but it looks
> >> like I don't have the necessary permissions).
> >>
> >> On Tue, Apr 16, 2013 at 12:19 PM, David Nalley  wrote:
> >>
> >>> On Tue, Apr 16, 2013 at 2:34 PM, Rebecca Wood 
> >> wrote:
> >>>> Dear ASF members,
> >>>> We would like to propose the jclouds project to the Incubator.  The
> >>> jclouds Proposal is available at:
> >>>>
> >>>> http://wiki.apache.org/incubator/jcloudsProposal
> >>>>
> >>>> We welcome your feedback and suggestions.
> >>>
> >>> Excited to see jclouds proposal.
> >>> If you are looking for additional mentors, I'd be happy to step up.
> >>>
> >>> --David
> >>>
> >>> -
> >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >>> For additional commands, e-mail: general-h...@incubator.apache.org
> >>>
> >>>
> >>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [PROPOSAL] jclouds Proposal for Incubator

[Adrian Cole]

Mind you, my previous physical trainers gave up after they saw how buff I
am.


On Tue, Apr 16, 2013 at 6:34 PM, Suresh Marru  wrote:

>
> On Apr 16, 2013, at 9:04 PM, Matt Stephenson 
> wrote:
>
> > Thanks to everyone stepping up to be a mentor!  I personally do 300
> jumping
> > jacks in the name of jclouds on a weekly basis, so we're cutting our
> > mentors a great deal!
>
> + 1 the 2 hours/week mentor time is to make sure podling committers do the
> jumping jacks :).
>
> Adrian, Matt, I am vary of the time commitment and onboard with it.
>
> Cheers,
> Suresh
>
> >
> > I really like our proposal, but I'm biased.  Obviously we wanna be a part
> > of Apache, so this kind of acceptance by the community is amazingly great
> > news!
> >
> >
> > Matt
> >
> >
> > On Tue, Apr 16, 2013 at 5:17 PM, Adrian Cole  wrote:
> >
> >> Thanks, Suresh.  Airavata looks like it has context for collaboration
> with
> >> jclouds for sure.
> >>
> >> WRT mentoring, I was going to warn you.. all mentors have implicitly
> signed
> >> up for 2 hours/week on process guidance and 35 jumping jacks.
> >>
> >> -A
> >>
> >>
> >> On Tue, Apr 16, 2013 at 4:59 PM, Suresh Marru 
> wrote:
> >>
> >>> Nice Proposal, looking forward to see jcloud flourish in Apache. Glad
> to
> >>> see such a overwhelming mentor support.
> >>>
> >>> I am interested to see this as an abstraction for Apache Airavata, I do
> >>> not think you need more mentors, but I will be happy to help as needed
> as
> >>> well (either onboard as mentor or on this list).
> >>>
> >>> Cheers,
> >>> Suresh
> >>>
> >>> On Apr 16, 2013, at 7:51 PM, Adrian Cole  wrote:
> >>>
> >>>> Tomaz and Olivier (and David)
> >>>>
> >>>> You guys are awesome to offer help.  I thought maybe 5 was the number
> >> of
> >>>> mentors we needed, but I heard a sentiment of "the more the merrier"
> >> So,
> >>>> I'm adding any apache member with experience with incubation that
> >> offers
> >>> to
> >>>> help us.  Seems a better problem to have more advice than less, and
> >> now a
> >>>> fleet of apache members can take holiday and we can still get enough
> >>> votes
> >>>> to release something :)
> >>>>
> >>>> Cheers, thanks for the kind words, and lets do this!
> >>>> -A
> >>>>
> >>>>
> >>>> On Tue, Apr 16, 2013 at 4:45 PM, Tomaz Muraus 
> >> wrote:
> >>>>
> >>>>> Agreed and best of luck from the Apache Libcloud PMC :)
> >>>>>
> >>>>> If you are looking for additional mentors I'm also more than happy to
> >>> help.
> >>>>>
> >>>>> (I would add myself under "volunteer" section on the wiki, but it
> >> looks
> >>>>> like I don't have the necessary permissions).
> >>>>>
> >>>>> On Tue, Apr 16, 2013 at 12:19 PM, David Nalley 
> wrote:
> >>>>>
> >>>>>> On Tue, Apr 16, 2013 at 2:34 PM, Rebecca Wood 
> >>>>> wrote:
> >>>>>>> Dear ASF members,
> >>>>>>> We would like to propose the jclouds project to the Incubator.  The
> >>>>>> jclouds Proposal is available at:
> >>>>>>>
> >>>>>>> http://wiki.apache.org/incubator/jcloudsProposal
> >>>>>>>
> >>>>>>> We welcome your feedback and suggestions.
> >>>>>>
> >>>>>> Excited to see jclouds proposal.
> >>>>>> If you are looking for additional mentors, I'd be happy to step up.
> >>>>>>
> >>>>>> --David
> >>>>>>
> >>>>>>
> -
> >>>>>> 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
> >>>
> >>>
> >>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [PROPOSAL] jclouds Proposal for Incubator

[Adrian Cole]

Thanks, Carlos, both for the code bidd as well offering to be our 10th
mentor :)  Now, I promised mattstep that if we got to 10 mentors, we'd
start creating mentor titles.  I was thinking Eternal mentor, Supreme
mentor, but quickly ran out of ideas.  Can you take this on?

:D


On Tue, Apr 16, 2013 at 12:26 PM, Carlos Sanchez  wrote:

> I contributed some code back in the day, so happy to help too.
>
>
> On Tue, Apr 16, 2013 at 9:24 PM, Jean-Baptiste Onofré  >wrote:
>
> > I'm very interested as well.
> >
> > I'm also volunteer to be mentor on the project.
> >
> > Regards
> > JB
> >
> >
> > On 04/16/2013 09:19 PM, David Nalley wrote:
> >
> >> On Tue, Apr 16, 2013 at 2:34 PM, Rebecca Wood 
> wrote:
> >>
> >>> Dear ASF members,
> >>> We would like to propose the jclouds project to the Incubator.  The
> >>> jclouds Proposal is available at:
> >>>
> >>> http://wiki.apache.org/**incubator/jcloudsProposal<
> http://wiki.apache.org/incubator/jcloudsProposal>
> >>>
> >>> We welcome your feedback and suggestions.
> >>>
> >>
> >> Excited to see jclouds proposal.
> >> If you are looking for additional mentors, I'd be happy to step up.
> >>
> >> --David
> >>
> >>
> --**--**-
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.**apache.org<
> general-unsubscr...@incubator.apache.org>
> >> For additional commands, e-mail: general-help@incubator.apache.**org<
> general-h...@incubator.apache.org>
> >>
> >>
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
> >
> > --**--**-
> > To unsubscribe, e-mail: general-unsubscribe@incubator.**apache.org<
> general-unsubscr...@incubator.apache.org>
> > For additional commands, e-mail: general-help@incubator.apache.**org<
> general-h...@incubator.apache.org>
> >
> >
>

Re: [VOTE] Release Apache jclouds 1.6.1-incubating, RC3

[Adrian Cole]

+1

/* using maven, ran denominator live regression tests on route53,
dynect, ultradns-ws, and rackspace-clouddns with no problems. */

On Tue, Jun 18, 2013 at 5:38 AM, Jim Jagielski  wrote:
>
> On Jun 16, 2013, at 10:04 PM, Andrew Bayer  wrote:
>
>>
>> [ ] +1
>> [ ] 0
>> [ ] -1 (explain why)
>>
>
> +1 (binding) /* using mvn */
>

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

Re: [VOTE] Release Whirr version 0.4.0-incubating

[Adrian Cole]

+1

checked out tag and ran the following tests successfully
cassandra, aws-ec2 (verified it used t1.micro type)
zookeeper, cloudservers-us (verified it used the 512m flavor)
hbase, cloudservers-us (verified it used the 1024m flavor)

all tests bootstrapped with the cloud-specific user, but executed configure
with a user identical to my login (expected behavior)

On Thu, Mar 17, 2011 at 3:59 PM, Andrei Savu  wrote:

> This is the first incubator release for Apache Whirr, version
> 0.4.0-incubating.
>
> It fixes the following issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=1230&version=12316065
>
> *** Please download, test and vote by March, 22.
>
> Note that we are voting upon the source (tag), binaries are provided
> for convenience.
>
> Source and binary files:
> http://people.apache.org/~asavu/whirr-0.4.0-incubating-candidate-1
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachewhirr-017
>
> The tag to be voted upon:
>
> http://svn.apache.org/repos/asf/incubator/whirr/tags/release-0.4.0-incubating
>
> Whirr's KEYS file containing PGP keys we use to sign the release:
> http://svn.apache.org/repos/asf/incubator/whirr/dist/KEYS
>
> Note that the Incubator PMC needs to vote upon the release after a
> successful PPMC vote before any release can be made official.
>
> Cheers,
> Andrei
>

Re: [VOTE] Release Whirr version 0.4.0-incubating

[Adrian Cole]

+1  I spot tested cassandra on aws-ec2 and zookeeper on
cloudservers-us from the tag.  a-ok

-Adrian

On Thu, Mar 24, 2011 at 3:26 PM, Patrick Hunt  wrote:
> +1. md5/sha1/gpg all look good. apache-rat:check is clean, and I was
> able to stand up a ZK cluster, use it, then destroy.
>
> Patrick
>
> On Wed, Mar 23, 2011 at 1:29 PM, Andrei Savu  wrote:
>> +1
>>
>> I've been able to run the integration tests on both cloud providers
>> and I have started a ZooKeeper cluster. RC2 contains no code changes
>> from RC1.
>>
>> -- Andrei Savu / andreisavu.ro
>>
>> On Wed, Mar 23, 2011 at 10:26 PM, Andrei Savu  wrote:
>>> This is the first incubator release for Apache Whirr, version 
>>> 0.4.0-incubating.
>>>
>>> It fixes the following issues:
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=1230&version=12316065
>>>
>>> *** Please download, test and vote by March, 28.
>>>
>>> Note that we are voting upon the source (tag), binaries are provided
>>> for convenience.
>>>
>>> Source and binary files:
>>> http://people.apache.org/~asavu/whirr-0.4.0-incubating-candidate-2
>>>
>>> Maven staging repo:
>>> https://repository.apache.org/content/repositories/orgapachewhirr-028
>>>
>>> The tag to be voted upon:
>>> http://svn.apache.org/repos/asf/incubator/whirr/tags/release-0.4.0-incubating
>>>
>>> Whirr's KEYS file containing PGP keys we use to sign the release:
>>> http://svn.apache.org/repos/asf/incubator/whirr/dist/KEYS
>>>
>>> Note that the Incubator PMC needs to vote upon the release after a
>>> successful PPMC vote before any release can be made official.
>>>
>>> Cheers,
>>> Andrei
>>>
>>
>

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

Access to Zipkin incubator thing

[Adrian Cole]

Hi, all.

Mind adding my user AdrianCole with edit rights to
https://wiki.apache.org/incubator/ZipkinProposal? I'd like to help
finalize the proposal.

Best,
-A

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

[PROPOSAL] Zipkin for Apache Incubator

[Adrian Cole]

rate on fixes and changes in the code. They are always happy to
answer users' questions as well.

Zipkin is interested in continuing to expand and strengthen its
network of developers and community members through the ASF.

=== Reliance on Salaried Developers ===
Zipkin has one full time salaried developer, Adrian Cole. Though some
of the developers are paid by their employer to contribute to Zipkin,
many Zipkin developers contribute code and documentation on their own
time and have done so for a lengthy period. Given the current stream
of development requests and the committers' sense of ownership of the
Zipkin code, this arrangement is expected to continue with Zipkin'
induction into the ASF.

=== Relationships with Other Apache Products ===
Zipkin, Apache Incubator Skywalking and Apache Incubator HTrace
address similiar use cases. Most similarities are between Zipkin and
HTrace: Zipkin hopes to help serve the community formerly served by
HTrace, but understands the data services focus of HTrace may require
different tooling. SkyWalking addresses more feature surface than
Zipkin. For example, metrics collection is not a goal of Zipkin, yet
it is a goal of SkyWalking. SkyWalking accepts Zipkin formats and can
be used as a replacement server. SkyWalking PPMC member, Sheng Wu, has
been a routine member of Zipkin design discussions and has offered to
help Zipkin through ASF process.

While Zipkin does not directly rely upon any Apache project, zipkin
supports several Apache projects. Apache CXF, Apache Camel, Apache
Incubator SkyWalking, Apache Incubator Dubbo, Apache Incubator
ServiceComb and Apache Incubator HTrace all utilize Zipkin APIs in
their core repositories. Many more do via community extensions. Apache
Maven is primarily use by Zipkin, and can be used by projects who
build upon Zipkin projects.

=== A Excessive Fascination with the Apache Brand ===
Zipkin recognizes the fortitude of the Apache brand, but the
motivation for becoming an Apache project is to strengthen and expand
the Zipkin community and its user base. While the Zipkin community has
seen steady growth over the past several years, association with the
ASF is expected to expedite this pattern of growth. Development is
expected to continue on Zipkin under the Apache license whether or not
it is supported by the ASF.

== Documentation ==
The Zipkin project documentation is publicly available at the following sites:

  * https://zipkin.io: project overview
  * http://zipkin.io/zipkin-api/#/: swagger specification
  * https://github.com/openzipkin/b3-propagation: header formats
  * https://zipkin.io/zipkin/: Javadocs for the Zipkin server

== Initial Source ==
The initial source is located on GitHub in the following repositories:

  * git://github.com/OpenZipkin/zipkin.git
  * git://github.com/OpenZipkin/zipkin-dependencies.git
  * git://github.com/OpenZipkin/zipkin-api.git
  * git://github.com/OpenZipkin/b3-propagation.git
  * git://github.com/OpenZipkin/docker-zipkin.git
  * git://github.com/OpenZipkin/docker-zipkin-dependencies.git
  * git://github.com/openzipkin/zipkin-reporter-java
  * git://github.com/openzipkin/brave
  * git://github.com/openzipkin/zipkin-aws
  * git://github.com/openzipkin/docker-zipkin-aws
  * git://github.com/openzipkin/zipkin-azure
  * git://github.com/openzipkin/docker-zipkin-azure
  * git://github.com/openzipkin/zipkin-gcp
  * git://github.com/openzipkin/docker-zipkin-gcp
  * git://github.com/openzipkin/brave-cassandra
  * git://github.com/openzipkin/docker-jre-full
  * git://github.com/openzipkin/brave-karaf

Depending on community progress, other repositories may be moved as well

== Source and Intellectual Property Submission Plan ==
Zipkin's initial source is licensed under the Apache License, Version
2.0. https://github.com/openzipkin/zipkin/blob/master/LICENSE

All source code is copyrighted to 'The OpenZipkin Authors', to which
the existing core community(members list in Initial Committers) has
the rights to re-assign to the ASF.

== External Dependencies ==
This is a listing of Maven coordinates for all of the external
dependencies Zipkin uses. All of the dependencies are in Sonatype and
their licenses should be accessible.

== Cryptography ==
Zipkin contains no cryptographic algorithms.

= Required Resources =
== Mailing Lists ==
  * Zipkin-dev: for development discussions
  * Zipkin-user: for community discussions
  * Zipkin-private: for PPMC discussions
  * Zipkin-commits: for code changes

== Git Repositories ==
The Zipkin team is experienced in git and requests to transfer GitHub
repositories(list in Initial Source) to Apache.

== Issue Tracking ==
The community would like to continue using GitHub Issues.

= Initial Committers =
  * Zoltán Nagy
  * Adrian Cole, Pivotal
  * Bas van Beek
  * Brian Devins
  * Eirik Sletteberg
  * Jeanneret Pierre-Hugues
  * Jordi Polo Carres
  * José Carlos Chávez
  * Kristof Adriaenssens
  * Lance Linder
  * Mick Semb Wever,
  * Tommy L

Re: [PROPOSAL] Zipkin for Apache Incubator

[Adrian Cole]

I'm sure I speak for others welcoming your help as a mentor, Willem. Glad
to have had a chance to meet you before this moment as well!

We can probably take most things off this mail thread, but generally yes..
people definitely want to keep github, though we also at the right time
should move our Google group email to apache lists.

best,
-A

On Sun, 19 Aug 2018, 07:36 Willem Jiang,  wrote:

> +1. It's great that Zipkin can be a part of Apache Incubator project.
>
> After going through the discussion here[1], I can see Zipkin leverage
> Github infrastructure  a lot, we may need to figure out if we need to setup
> the user mailing list for this project.
> I agree with what John has said, you may consider twice for migration user
> discussion from github to apache mailing list.
> I think Skywalking may face the same issue, few people register the mailing
> list because lots of discussion happen in the github issues.
>
> I'd be happy to be the mentor of this project if you are interested.I guess
> there is still a room for additional mentor.
> As some part of my daily work[2] is based on the work of zipkin, I can
> devote more time on this project.
>
> [1] https://github.com/openzipkin/openzipkin.github.io/issues/51
> [2] https://github.com/apache/incubator-servicecomb-saga
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Fri, Aug 17, 2018 at 5:29 PM, Adrian Cole 
> wrote:
>
> > I would like to propose Zipkin as an Apache Incubator project.
> >
> > The text of the proposal can be found below as well as on the Incubator
> > wiki:
> >
> > https://wiki.apache.org/incubator/ZipkinProposal
> >
> > I believe we should have 3 mentors.. currently we have 2 (plus Wu
> > Sheng and I who are familiar but not mentor-grade :P). If another
> > person can volunteer to mentor us, would be sweet.
> >
> > -Adrian
> >
> > = Abstract =
> > Zipkin is a distributed tracing system. It helps gather timing data
> > needed to troubleshoot latency problems in microservice architectures.
> > It manages both the collection and lookup of this data. Zipkin’s
> > design is based on the Google Dapper paper.
> >
> > = Proposal =
> > Zipkin provides a defined data model and payload type for distributed
> > trace data collection. It also provides an UI and http api for
> > querying the data. Its server implements this api and includes
> > abstractions for storage and transport of trace payloads. The
> > combination of these parts avoid lock-in to a specific tracing
> > backend. For example, Zipkin includes integration with different open
> > source storage mechanisms like Apache Cassandra and Elasticsearch. It
> > also includes bridges to convert collected data and forward it to
> > service offerings such as Amazon X-Ray and Google Stackdriver.
> > Ecosystem offering extend this portability further.
> >
> > While primarily focused on the system, Zipkin also includes tracing
> > libraries which applications use to report timing information.
> > Zipkin's core organization includes tracer libraries written in Java,
> > Javascript, Go, PHP and Ruby. These libraries use the formats
> > mentioned above to report data, as well "B3" which is a header format
> > needed to send trace identifiers along with production requests. Many
> > Zipkin libraries can also send data directly to other services such as
> > Amazon X-Ray and Google Stackdriver, skipping any Zipkin
> > infrastructure. There are also more Zipkin tracing libraries outside
> > the core organization than inside it. This is due to the "OpenZipkin"
> > culture of promoting ecosystem work.
> >
> > = Background =
> > Zipkin began in 2012 at Twitter during a time they were investigating
> > performance problems underlying the "fail whale" seen by users. The
> > name Zipkin is from the Turkish word for harpoon: the harpoon that
> > will kill the failures! Incidentally, Zipkin was not the first tracing
> > system, it had roots in a former system at Twitter named
> > BigBrotherBird. It is due to BigBrotherBird that the de-facto tracing
> > headers we still use today include the prefix "X-B3".
> >
> > In 2015, a community of users noticed the project was not healthy in
> > so far as it hadn't progressed and often didn't accept pull requests,
> > and the Cassandra backend was stuck on an unmaintained library. For
> > example, the Apache Incubator H-Trace project started in some ways as
> > a reaction to the inability to customize the code. The root cause of
> > this was Twitter moving to inter

Re: [VOTE] Accept Zipkin into the Apache Incubator

[Adrian Cole]

oject is gaining traction with 
> developers. The risks of the code being abandoned are minimal.
>
> === Inexperience with Open Source ===
> Zipkin rebooted its community in July 2015 and grown there for over three 
> years. Additionally, many of the committers have extensive experience with 
> other open source projects. Zipkin fosters a collaborative and 
> community-driven environment.
>
> In the interest of openly sharing technology and attracting more community 
> members, several of our developers also regularly attend conferences in North 
> America and Europe to give talks about Zipkin. Zipkin meetups are also 
> planned every few months for developers and community members to come 
> together in person and discuss ideas.
>
> === Homogenous Developers ===
> At the time of the writing, OpenZipkin's core 12 developers all work at 
> different companies around the globe. Most operate their own tracing sites, 
> but some no longer operate sites at all: staying for the community we've 
> built. Our ASF champion, Mick Semb Wever, is both a committer and an 
> experienced ASF member.
>
> The Zipkin developers thrive upon the diversity of the community. The Zipkin 
> gitter channel is always active, and the developers often collaborate on 
> fixes and changes in the code. They are always happy to answer users' 
> questions as well.
>
> Zipkin is interested in continuing to expand and strengthen its network of 
> developers and community members through the ASF.
>
> === Reliance on Salaried Developers ===
> Zipkin has one full time salaried developer, Adrian Cole. Though some of the 
> developers are paid by their employer to contribute to Zipkin, many Zipkin 
> developers contribute code and documentation on their own time and have done 
> so for a lengthy period. Given the current stream of development requests and 
> the committers' sense of ownership of the Zipkin code, this arrangement is 
> expected to continue with Zipkin' induction into the ASF.
>
> === Relationships with Other Apache Products ===
> Zipkin, Apache Incubator Skywalking and Apache Incubator HTrace address 
> similiar use cases. Most similarities are between Zipkin and HTrace: Zipkin 
> hopes to help serve the community formerly served by HTrace, but understands 
> the data services focus of HTrace may require different tooling. SkyWalking 
> addresses more feature surface than Zipkin. For example, metrics collection 
> is not a goal of Zipkin, yet it is a goal of SkyWalking. SkyWalking accepts 
> Zipkin formats and can be used as a replacement server. SkyWalking PPMC 
> member, Sheng Wu, has been a routine member of Zipkin design discussions and 
> has offered to help Zipkin through ASF process.
>
> While Zipkin does not directly rely upon any Apache project, zipkin supports 
> several Apache projects. Apache CXF, Apache Camel, Apache Incubator 
> SkyWalking, Apache Incubator Dubbo, Apache Incubator ServiceComb and Apache 
> Incubator HTrace all utilize Zipkin APIs in their core repositories. Many 
> more do via community extensions. Apache Maven is primarily use by Zipkin, 
> and can be used by projects who build upon Zipkin projects.
>
> === A Excessive Fascination with the Apache Brand ===
> Zipkin recognizes the fortitude of the Apache brand, but the motivation for 
> becoming an Apache project is to strengthen and expand the Zipkin community 
> and its user base. While the Zipkin community has seen steady growth over the 
> past several years, association with the ASF is expected to expedite this 
> pattern of growth. Development is expected to continue on Zipkin under the 
> Apache license whether or not it is supported by the ASF.
>
> == Documentation ==
> The Zipkin project documentation is publicly available at the following sites:
>
>   * https://zipkin.io: project overview
>   * http://zipkin.io/zipkin-api/#/: swagger specification
>   * https://github.com/openzipkin/b3-propagation: header formats
>   * https://zipkin.io/zipkin/: Javadocs for the Zipkin server
>
> == Initial Source ==
> The initial source is located on GitHub in the following repositories:
>
>   * git://github.com/OpenZipkin/zipkin.git
>   * git://github.com/OpenZipkin/zipkin-dependencies.git
>   * git://github.com/OpenZipkin/zipkin-api.git
>   * git://github.com/OpenZipkin/b3-propagation.git
>   * git://github.com/OpenZipkin/docker-zipkin.git
>   * git://github.com/OpenZipkin/docker-zipkin-dependencies.git
>   * git://github.com/openzipkin/zipkin-reporter-java
>   * git://github.com/openzipkin/brave
>   * git://github.com/openzipkin/zipkin-aws
>   * git://github.com/openzipkin/docker-zipkin-aws
>   * git://github.com/openzipkin/zipkin-azure
>   * git://github.com/openzipkin/docke

Re: Does Zipkin need to sign a SGA ?

[Adrian Cole]

There was a process involved at Twitter when we first moved it to the
openzipkin organization. It was 100% clear that this was an act for
the community to control the code.  Senior management were involved
https://groups.google.com/d/msg/zipkin-user/fbOgEZpuQx4/bWH1-__EmCoJ

After that, all the repositories had contributing files like the below
indicating that all changes we to be redistributable under ASL
https://github.com/openzipkin/zipkin/blob/master/.github/CONTRIBUTING.md#license

There was no collection of contributor agreements beyond this. Most of
the code except save some UI assets have been completely rewritten
since the migration to OpenZipkin a few years back.

Hope these details help,
-A
On Wed, Sep 19, 2018 at 9:09 AM Craig Russell  wrote:
>
> Hi Mick,
>
> tldr; with my Incubator PMC hat on, "all that needs to be done" is to 
> establish that all of the copyright owners sign either a Software Grant or an 
> ICLA.
>
> In order to establish that Apache has the rights to the code base, every line 
> of code needs to have its provenance researched.
>
> Looking at the proposal https://wiki.apache.org/incubator/ZipkinProposal it 
> seems like most of the code is in the github repository 
> https://github.com/openzipkin/zipkin . Is there any code coming from another 
> source? Was the original code from Twitter granted to OpenZipkin? Is there 
> any documentation of that copyright transfer? Does Twitter retain any rights?
>
> The capitalization of the "Initial Source" section is a bit strange. But can 
> we assume that the only committers to the project are listed at 
> https://github.com/openzipkin/zipkin/graphs/contributors ?
>
> The proposal also says that "All source code is copyrighted to 'The 
> OpenZipkin Authors', to which the existing core community(members list in 
> Initial Committers) has the rights to re-assign to the ASF. "
>
> It looks like there were many people who contributed a few lines of code. Did 
> they sign anything like a Contributor Agreement that grants their copyright 
> to The OpenZipkin Authors?
>
> Craig
>
> > On Sep 18, 2018, at 4:58 PM, Mick Semb Wever  wrote:
> >
> >
> > It's come up that the migration of the github Zipkin repositories to ASF 
> > requires either a signed SGA or a sign-off from the Secretary. Chris raised 
> > this on `INFRA-16989 – Zipkin incubator project request for the GitHub 
> > repositories moving service`.
> >
> > I was under the impression that if the Copyright was already held by the 
> > community, it is held by 'The OpenZipkin Authors', that the ICLA from all 
> > those authors would suffice and a SGA not be required. And it's news to me 
> > that this would also require a sign-off from the ASF Secretary.
> >
> > What's the correct process here? who can help? should I forward the 
> > question to the Secretary?
> >
> > regards,
> > Mick
> >
> > -
> > 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 
> 

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

Re: Does Zipkin need to sign a SGA ?

[Adrian Cole]

Hi, John

Thanks for the input. So, I would hazard a guess that Twitter folks
would like to help with this. I'm not sure who would want to hunt
through the management chain to find someone to reverse-own a decision
made 3 years ago, though! Regardless, on my part, I'll see if I can
find a champion inside Twitter to resurrect and SGA.

Best,
-A
On Wed, Sep 19, 2018 at 9:36 AM John D. Ament  wrote:
>
> Thanks Adrian.  Some comments/banter below.
>
> Migrating a repository from one org to another does not require an SGA.  If
> it did, we would not be able to have code living in our repos that had
> headers other than the ASF standard headers (e.g. BSD licenses, or Apache
> License w/ different copyright statements).  The SGA is used to replace the
> headers with the standard ASF headers.  We should not block migrating the
> repositories over while the SGA/ICLA is worked out.
>
> Resolving the SGA/ICLA situation would block graduation - we should ensure
> that the provenance is in place, which is part of the incubation process.
> This doesn't need to be solved on day 1, but by the time the podling is
> ready to graduate.
>
> With that said, from a pure foundation standpoint it would be ideal to
> receive a SGA from Twitter.  Even if the current code doesn't match the
> code at the time of Twitter's conversion, it gives us a better IP history
> for the codebase to answer questions and deal with any potential problems
> that may come up along the way.  However, to be realistic I believe if we
> receive an ICLA from the primary contributors based on [1], that should
> satisfy enough providence of the codebase, in addition to the contribution
> process that Adrian has pointed out below.
>
> Thoughts?
>
> John
>
> [1]: https://github.com/openzipkin/zipkin/graphs/contributors
>
> On Tue, Sep 18, 2018 at 9:25 PM Adrian Cole  wrote:
>
> > There was a process involved at Twitter when we first moved it to the
> > openzipkin organization. It was 100% clear that this was an act for
> > the community to control the code.  Senior management were involved
> > https://groups.google.com/d/msg/zipkin-user/fbOgEZpuQx4/bWH1-__EmCoJ
> >
> > After that, all the repositories had contributing files like the below
> > indicating that all changes we to be redistributable under ASL
> >
> > https://github.com/openzipkine/zipkin/blob/master/.github/CONTRIBUTING.md#license
> > <https://github.com/openzipkin/zipkin/blob/master/.github/CONTRIBUTING.md#license>
> >
> > There was no collection of contributor agreements beyond this. Most of
> > the code except save some UI assets have been completely rewritten
> > since the migration to OpenZipkin a few years back.
> >
> > Hope these details help,
> > -A
> > On Wed, Sep 19, 2018 at 9:09 AM Craig Russell 
> > wrote:
> > >
> > > Hi Mick,
> > >
> > > tldr; with my Incubator PMC hat on, "all that needs to be done" is to
> > establish that all of the copyright owners sign either a Software Grant or
> > an ICLA.
> > >
> > > In order to establish that Apache has the rights to the code base, every
> > line of code needs to have its provenance researched.
> > >
> > > Looking at the proposal https://wiki.apache.org/incubator/ZipkinProposal
> > it seems like most of the code is in the github repository
> > https://github.com/openzipkin/zipkin . Is there any code coming from
> > another source? Was the original code from Twitter granted to OpenZipkin?
> > Is there any documentation of that copyright transfer? Does Twitter retain
> > any rights?
> > >
> > > The capitalization of the "Initial Source" section is a bit strange. But
> > can we assume that the only committers to the project are listed at
> > https://github.com/openzipkin/zipkin/graphs/contributors ?
> > >
> > > The proposal also says that "All source code is copyrighted to 'The
> > OpenZipkin Authors', to which the existing core community(members list in
> > Initial Committers) has the rights to re-assign to the ASF. "
> > >
> > > It looks like there were many people who contributed a few lines of
> > code. Did they sign anything like a Contributor Agreement that grants their
> > copyright to The OpenZipkin Authors?
> > >
> > > Craig
> > >
> > > > On Sep 18, 2018, at 4:58 PM, Mick Semb Wever  wrote:
> > > >
> > > >
> > > > It's come up that the migration of the github Zipkin repositories to
> > ASF requires either a signed SGA or a sign-off from the Secretary. Chris
> 

Re: Does Zipkin need to sign a SGA ?

[Adrian Cole]

OpenZipkin isn't a formal entity. The primary fork (master copy) was
moved from twitter to a github org named OpenZipkin. We aren't moving
any downstream forks to the exist they still exist for Lookout or any
other person.
On Wed, Sep 19, 2018 at 10:40 AM Dave Fisher  wrote:
>
> Hi,
>
> Is OpenZipkin a formal entity?
>
> What about Lookout who also had a fork (according to the references)?
>
> At Twitter you might try Remy DeCausemaker.
>
> Regards,
> Dave
>
> Sent from my iPhone
>
> > On Sep 18, 2018, at 6:59 PM, Adrian Cole  wrote:
> >
> > Hi, John
> >
> > Thanks for the input. So, I would hazard a guess that Twitter folks
> > would like to help with this. I'm not sure who would want to hunt
> > through the management chain to find someone to reverse-own a decision
> > made 3 years ago, though! Regardless, on my part, I'll see if I can
> > find a champion inside Twitter to resurrect and SGA.
> >
> > Best,
> > -A
> >> On Wed, Sep 19, 2018 at 9:36 AM John D. Ament  
> >> wrote:
> >>
> >> Thanks Adrian.  Some comments/banter below.
> >>
> >> Migrating a repository from one org to another does not require an SGA.  If
> >> it did, we would not be able to have code living in our repos that had
> >> headers other than the ASF standard headers (e.g. BSD licenses, or Apache
> >> License w/ different copyright statements).  The SGA is used to replace the
> >> headers with the standard ASF headers.  We should not block migrating the
> >> repositories over while the SGA/ICLA is worked out.
> >>
> >> Resolving the SGA/ICLA situation would block graduation - we should ensure
> >> that the provenance is in place, which is part of the incubation process.
> >> This doesn't need to be solved on day 1, but by the time the podling is
> >> ready to graduate.
> >>
> >> With that said, from a pure foundation standpoint it would be ideal to
> >> receive a SGA from Twitter.  Even if the current code doesn't match the
> >> code at the time of Twitter's conversion, it gives us a better IP history
> >> for the codebase to answer questions and deal with any potential problems
> >> that may come up along the way.  However, to be realistic I believe if we
> >> receive an ICLA from the primary contributors based on [1], that should
> >> satisfy enough providence of the codebase, in addition to the contribution
> >> process that Adrian has pointed out below.
> >>
> >> Thoughts?
> >>
> >> John
> >>
> >> [1]: https://github.com/openzipkin/zipkin/graphs/contributors
> >>
> >>> On Tue, Sep 18, 2018 at 9:25 PM Adrian Cole  
> >>> wrote:
> >>>
> >>> There was a process involved at Twitter when we first moved it to the
> >>> openzipkin organization. It was 100% clear that this was an act for
> >>> the community to control the code.  Senior management were involved
> >>> https://groups.google.com/d/msg/zipkin-user/fbOgEZpuQx4/bWH1-__EmCoJ
> >>>
> >>> After that, all the repositories had contributing files like the below
> >>> indicating that all changes we to be redistributable under ASL
> >>>
> >>> https://github.com/openzipkine/zipkin/blob/master/.github/CONTRIBUTING.md#license
> >>> <https://github.com/openzipkin/zipkin/blob/master/.github/CONTRIBUTING.md#license>
> >>>
> >>> There was no collection of contributor agreements beyond this. Most of
> >>> the code except save some UI assets have been completely rewritten
> >>> since the migration to OpenZipkin a few years back.
> >>>
> >>> Hope these details help,
> >>> -A
> >>> On Wed, Sep 19, 2018 at 9:09 AM Craig Russell 
> >>> wrote:
> >>>>
> >>>> Hi Mick,
> >>>>
> >>>> tldr; with my Incubator PMC hat on, "all that needs to be done" is to
> >>> establish that all of the copyright owners sign either a Software Grant or
> >>> an ICLA.
> >>>>
> >>>> In order to establish that Apache has the rights to the code base, every
> >>> line of code needs to have its provenance researched.
> >>>>
> >>>> Looking at the proposal https://wiki.apache.org/incubator/ZipkinProposal
> >>> it seems like most of the code is in the github repository
> >>> https://github.com/openzipkin/zipkin . Is there any code coming from
> >&g

Re: Does Zipkin need to sign a SGA ?

[Adrian Cole]

Hi, all.

Assuming the primary provenance concern is Twitter, I'm looping in
Ravi who is happy to help where he can, subject to personal
availability. Just keep in mind that the repository mentioned is in
almost 100% Java and no Java code was written by Twitter employees.

This was done after Twitter donated the project to the OpenZipkin
community. I wrote a great deal of it, but there are quite a lot of
contributors who wrote significant parts of the code, and none of them
are my colleagues nor twitter employees. All code written since
OpenZipkin came with the clause mentioned in the earlier
CONTRIBUTING.md that contributions would be licensed for distribution
in ASL. Changing the headers from "The OpenZipkin Authors" to "The
Apache Authors" or whatever we have to do is unlikely to cause a stir.

So, basically I'm sure many of us would like to know where the
concerns are and how to address concretely what is of issue.

Best,
-A
On Wed, Sep 19, 2018 at 11:09 AM Craig Russell  wrote:
>
> Hi Alex,
>
> Without going into history let's discuss the current guidance: 
> http://www.apache.org/licenses/#provenance
>
> If you want to cite historical references that conflict with this, we can 
> have that discussion.
>
> Establishing provenance is one of the primary tasks of a project in 
> incubation. In order to change the headers on code, the owners of the IP for 
> that code need to agree. SGA or ICLA is documentation of that agreement.
>
> Regards,
>
> Craig
>
> > On Sep 18, 2018, at 11:38 PM, Alex Harui  wrote:
> >
> > I may be mis-remembering, but I thought that an SGA wasn't required for 
> > ALv2 code.  OpenZipkin appears to be ALv2.  The licenses in the SGA are 
> > pretty much the same as in ALv2.
> > I thought that for ALv2 code, we mostly cared that the community documented 
> > that it was willing to make the move from wherever the code is now to the 
> > ASF, and it wasn't super important to get approval from folks with minor 
> > contributions as long as we were confident their contributions were under 
> > ALv2.
> >
> > Once the community has approved the move to the ASF, any copyright holder 
> > or an agent can replace the headers with the ASF header.
> >
> > Of course, I could be wrong...
> > -Alex
> >
> > On 9/18/18, 7:00 PM, "Adrian Cole"  > <mailto:adrian.f.c...@gmail.com>> wrote:
> >
> >Hi, John
> >
> >Thanks for the input. So, I would hazard a guess that Twitter folks
> >would like to help with this. I'm not sure who would want to hunt
> >through the management chain to find someone to reverse-own a decision
> >made 3 years ago, though! Regardless, on my part, I'll see if I can
> >find a champion inside Twitter to resurrect and SGA.
> >
> >Best,
> >-A
> >On Wed, Sep 19, 2018 at 9:36 AM John D. Ament  
> > wrote:
> >>
> >> Thanks Adrian.  Some comments/banter below.
> >>
> >> Migrating a repository from one org to another does not require an SGA.  If
> >> it did, we would not be able to have code living in our repos that had
> >> headers other than the ASF standard headers (e.g. BSD licenses, or Apache
> >> License w/ different copyright statements).  The SGA is used to replace the
> >> headers with the standard ASF headers.  We should not block migrating the
> >> repositories over while the SGA/ICLA is worked out.
> >>
> >> Resolving the SGA/ICLA situation would block graduation - we should ensure
> >> that the provenance is in place, which is part of the incubation process.
> >> This doesn't need to be solved on day 1, but by the time the podling is
> >> ready to graduate.
> >>
> >> With that said, from a pure foundation standpoint it would be ideal to
> >> receive a SGA from Twitter.  Even if the current code doesn't match the
> >> code at the time of Twitter's conversion, it gives us a better IP history
> >> for the codebase to answer questions and deal with any potential problems
> >> that may come up along the way.  However, to be realistic I believe if we
> >> receive an ICLA from the primary contributors based on [1], that should
> >> satisfy enough providence of the codebase, in addition to the contribution
> >> process that Adrian has pointed out below.
> >>
> >> Thoughts?
> >>
> >> John
> >>
> >> [1]: 
> >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenzipkin%2Fzipkin%2Fgraphs%2Fcontributors&data=02%7C01%7Caharui%40

Re: Does Zipkin need to sign a SGA ?

[Adrian Cole]

one note in our efforts to change this to action: the PPMC wrote or
significantly changed the vast majority of the code in the main repo. The
heroes that wrote the rest largely came from Twitter (in Italy work) plus
close and easy to find friends of Zipkin who volunteered effort. A long
tail of smaller works came from quite a few folks all with the noted
CONTRIBUTORS guidance.

Does this framing help at all with next steps?

Best,
-A

On Thu, 27 Sep 2018, 17:28 Adrian Cole,  wrote:

> Hi, all.
>
> Assuming the primary provenance concern is Twitter, I'm looping in
> Ravi who is happy to help where he can, subject to personal
> availability. Just keep in mind that the repository mentioned is in
> almost 100% Java and no Java code was written by Twitter employees.
>
> This was done after Twitter donated the project to the OpenZipkin
> community. I wrote a great deal of it, but there are quite a lot of
> contributors who wrote significant parts of the code, and none of them
> are my colleagues nor twitter employees. All code written since
> OpenZipkin came with the clause mentioned in the earlier
> CONTRIBUTING.md that contributions would be licensed for distribution
> in ASL. Changing the headers from "The OpenZipkin Authors" to "The
> Apache Authors" or whatever we have to do is unlikely to cause a stir.
>
> So, basically I'm sure many of us would like to know where the
> concerns are and how to address concretely what is of issue.
>
> Best,
> -A
> On Wed, Sep 19, 2018 at 11:09 AM Craig Russell 
> wrote:
> >
> > Hi Alex,
> >
> > Without going into history let's discuss the current guidance:
> http://www.apache.org/licenses/#provenance
> >
> > If you want to cite historical references that conflict with this, we
> can have that discussion.
> >
> > Establishing provenance is one of the primary tasks of a project in
> incubation. In order to change the headers on code, the owners of the IP
> for that code need to agree. SGA or ICLA is documentation of that agreement.
> >
> > Regards,
> >
> > Craig
> >
> > > On Sep 18, 2018, at 11:38 PM, Alex Harui 
> wrote:
> > >
> > > I may be mis-remembering, but I thought that an SGA wasn't required
> for ALv2 code.  OpenZipkin appears to be ALv2.  The licenses in the SGA are
> pretty much the same as in ALv2.
> > > I thought that for ALv2 code, we mostly cared that the community
> documented that it was willing to make the move from wherever the code is
> now to the ASF, and it wasn't super important to get approval from folks
> with minor contributions as long as we were confident their contributions
> were under ALv2.
> > >
> > > Once the community has approved the move to the ASF, any copyright
> holder or an agent can replace the headers with the ASF header.
> > >
> > > Of course, I could be wrong...
> > > -Alex
> > >
> > > On 9/18/18, 7:00 PM, "Adrian Cole"  adrian.f.c...@gmail.com>> wrote:
> > >
> > >Hi, John
> > >
> > >Thanks for the input. So, I would hazard a guess that Twitter folks
> > >would like to help with this. I'm not sure who would want to hunt
> > >through the management chain to find someone to reverse-own a
> decision
> > >made 3 years ago, though! Regardless, on my part, I'll see if I can
> > >find a champion inside Twitter to resurrect and SGA.
> > >
> > >Best,
> > >-A
> > >On Wed, Sep 19, 2018 at 9:36 AM John D. Ament <
> johndam...@apache.org> wrote:
> > >>
> > >> Thanks Adrian.  Some comments/banter below.
> > >>
> > >> Migrating a repository from one org to another does not require an
> SGA.  If
> > >> it did, we would not be able to have code living in our repos that had
> > >> headers other than the ASF standard headers (e.g. BSD licenses, or
> Apache
> > >> License w/ different copyright statements).  The SGA is used to
> replace the
> > >> headers with the standard ASF headers.  We should not block migrating
> the
> > >> repositories over while the SGA/ICLA is worked out.
> > >>
> > >> Resolving the SGA/ICLA situation would block graduation - we should
> ensure
> > >> that the provenance is in place, which is part of the incubation
> process.
> > >> This doesn't need to be solved on day 1, but by the time the podling
> is
> > >> ready to graduate.
> > >>
> > >> With that said, from a pure foundation standpoint it would be id

Re: Does Zipkin need to sign a SGA ?

[Adrian Cole]

Thanks tons. I am now watching INFRA-16989 and will follow-up there.
On Thu, Sep 27, 2018 at 5:59 PM Bertrand Delacretaz
 wrote:
>
> Hi,
>
> On Thu, Sep 27, 2018 at 5:29 PM Adrian Cole  wrote:
> > ...basically I'm sure many of us would like to know where the
> > concerns are and how to address concretely what is of issue...
>
> As Craig wrote earlier here
>
> > ..."all that needs to be done" is to establish that all of the copyright 
> > owners
> > sign either a Software Grant or an ICLA...
>
> So ideally all contributors sign a common Software Grant, or in some
> documented way delegate that to someone who is authorized to represent
> "the OpenZipkin community" and sign the software grant.
>
> As mentioned at INFRA-16989, the alternative is for all contributors
> to sign an Apache iCLA, IIUC Craig correctly in this case a Software
> Grant is not needed.
>
> From what you say it looks like there's no code from Twitter left in
> the codebase that is to be imported, if that's the case (and again
> provided we have documented declarations that confirm that) my opinion
> is that you don't need to involve Twitter.
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

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

Re: Does Zipkin need to sign a SGA ?

[Adrian Cole]

just updated that issue as there were some rumors that we are unstuck,
just not yet documented as such.

fingers crossed.
On Tue, Oct 9, 2018 at 1:40 AM Dave Fisher  wrote:
>
> Hi,
>
> I was looking at the October report and see that we need to close the loop on 
> this thread.
>
> > On Sep 27, 2018, at 2:59 PM, Bertrand Delacretaz  
> > wrote:
> >
> > Hi,
> >
> > On Thu, Sep 27, 2018 at 5:29 PM Adrian Cole  wrote:
> >> ...basically I'm sure many of us would like to know where the
> >> concerns are and how to address concretely what is of issue...
> >
> > As Craig wrote earlier here
> >
> >> ..."all that needs to be done" is to establish that all of the copyright 
> >> owners
> >> sign either a Software Grant or an ICLA...
> >
> > So ideally all contributors sign a common Software Grant, or in some
> > documented way delegate that to someone who is authorized to represent
> > "the OpenZipkin community" and sign the software grant.
> >
> > As mentioned at INFRA-16989, the alternative is for all contributors
> > to sign an Apache iCLA, IIUC Craig correctly in this case a Software
> > Grant is not needed.
> >
> > From what you say it looks like there's no code from Twitter left in
> > the codebase that is to be imported, if that's the case (and again
> > provided we have documented declarations that confirm that) my opinion
> > is that you don't need to involve Twitter.
>
> I agree. In fact in looking at the Zipkin repository and the contributing.md 
> referenced:
>
> https://github.com/openzipkin/zipkin/blob/master/.github/CONTRIBUTING.md 
> <https://github.com/openzipkin/zipkin/blob/master/.github/CONTRIBUTING.md>
>
> It looks to me that the code is already covered. As such I think that all 
> that is needed to get the migration unstuck is a comment from 
> secret...@apache.org on INFRA-16989
>
> Regards,
> Dave
>
> >
> > -Bertrand
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>

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

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

[Adrian Cole]

Great to see SkyWalking reach this stage. A good example for others!
Good luck for the graduation and will be watching!

Best,
-Adrian
On Tue, Oct 30, 2018 at 4:21 PM Mick Semb Wever  wrote:
>
> After discussion in the podling's community on the dev ML 
> https://lists.apache.org/thread.html/4ee8894c99275ee0f14fcdb250a66ef9d22a7ba87742fa613897849f@%3Cdev.skywalking.apache.org%3E
>
> and on a github ticket 
> https://github.com/apache/incubator-skywalking/issues/1768
>
> culminating with a positive vote 
> https://lists.apache.org/thread.html/da9768f15c6448d5045409317baacd6a7eb441b99807c6a62478048a@%3Cdev.skywalking.apache.org%3E
>
>
> We'd like to bring this to a discussing at the IPMC.
> Please see the proposed resolution below and let us know what do you think.
>
> A few stats to help with the discussion:
>
> Now we have the developers from
>   Tetrate, Bitmain, Huawei, OneAPM, Tingyun APM, Cloudwise APM,
> Alibaba Cainiao, dangdang.com, jd.com,  VBill Payment,
> yonghui superstore, Tydic, terminus
>
> During the podling's time in the Apache Incubator there has been
>  2200+ commits on development of the project,
>  240+ Issues tagged as question in GitHub created, 236 resolved,
>  700+ Pull request created and resolved, and
>  65 different contributors.
>
> The dev ML has 32 subscribers.
>  https://lists.apache.org/trends.html?d...@skywalking.apache.org:2018-9
>
> Also please check out Apache Maturity Model Assessment for SkyWalking
>   
> https://cwiki.apache.org/confluence/display/SKYWALKING/Apache+Maturity+Model+Assessment+for+SkyWalking
>
>
> regards,
> Mick
>
>
> Establish the Apache SkyWalking 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 application performance monitoring: especially for
> microservice, Cloud Native and container-based architecture systems;
> also known as a distributed tracing system. .
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> (PMC), to be known as the "Apache SkyWalking Project", be and hereby is
> established pursuant to Bylaws of the Foundation; and be it further
>
> RESOLVED, that the Apache SkyWalking Project be and hereby is
> responsible for the creation and maintenance of software related to
> application performance monitoring: especially for microservice, Cloud
> Native and container-based architecture systems; also known as a
> distributed tracing system. ; and be it further
>
> RESOLVED, that the office of "Vice President, Apache SkyWalking" 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
> SkyWalking Project, and to have primary responsibility for management of
> the projects within the scope of responsibility of the Apache SkyWalking
> 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 SkyWalking
> Project:
>
>  * Haoyang Liu  (刘浩杨) 
>  * Hongtao Gao  (高洪涛)
>  * Ignasi Barrera  
>  * Luke Han  (韩卿)
>  * Mick Semb Wever  
>  * Sheng Wu  (吴晟)   
>  * Shinn Zhang  (张鑫)  
>  * Willem Ning Jiang  (姜宁)   
>  * Yongsheng Peng  (彭勇升) 
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Sheng Wu (吴晟) be
> appointed to the office of Vice President, Apache SkyWalking, 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 SkyWalking 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 SkyWalking
> Project; and be it further
>
> RESOLVED, that the Apache SkyWalking Project be and hereby is tasked
> with the migration and rationalization of the Apache Incubator
> SkyWalking podling; and be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache Incubator
> SkyWalking podling encumbered upon the Apache Incubator PMC 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

[VOTE] Release Apache Zipkin Brave Karaf (Incubating) version 0.1.2

[Adrian Cole]

Hello All,

This is a call for vote to release Apache Zipkin Brave Karaf
(Incubating) version 0.1.2

The Apache Zipkin community has voted on and approved a proposal to
release Apache Zipkin Brave Karaf (Incubating) version 0.1.2.

We now kindly request the Incubator PMC members review and vote on
this incubator release.

Apache Zipkin Brave Karaf (Incubating) sets up tracing components such
that tools built Karaf needn't configure these explicitly.

Zipkin community vote and result thread:
https://lists.apache.org/thread.html/e18e8561b6e1ad7bc6f544332d4e97e4f96a020de3e1e4cc721b7625@%3Cdev.zipkin.apache.org%3E

The release candidates:
https://dist.apache.org/repos/dist/dev/incubator/zipkin/brave-karaf/0.1.2/

Git tag for the release:
https://github.com/apache/incubator-zipkin-brave-karaf/tree/v0.1.2

Hash for the release tag:
31545805a55dbe5e495403d84172fc865a4935e0

Release Notes:
https://github.com/apache/incubator-zipkin-brave-karaf/releases/tag/v0.1.2

The artifacts have been signed with Key : BB67A050, which can be found
in the keys file:
https://dist.apache.org/repos/dist/dev/incubator/zipkin/KEYS

Verification Hints:
For your convenience, the below includes detailed how-to on verifying
a source release. Please note that this document is a work-in-progress
https://cwiki.apache.org/confluence/display/ZIPKIN/Verifying+a+Source+Release

The vote will be open for at least 72 hours or until necessary number
of votes are reached.

Please vote accordingly:

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason

Thanks,
The Apache Zipkin (Incubating) Team

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

Re: [VOTE] Release Apache Zipkin Brave Karaf (Incubating) version 0.1.2

[Adrian Cole]

thanks justin. I missed this part about the jar and know there are options
to it.

the license warnings were already resolved for the next release.

On the NOTICE, the headers originally said copyright "The OpenZipkin
Authors" I can put that into a pull request prior to re-cutting.

As recutting, revoting, and reverifying is time consuming for the
volunteers I will wait for someone else to also look at this (besides our
mentors who already have) to save our folks the frustration of 3rd go round
leading to a 4th.


On Thu, Feb 14, 2019, 10:08 AM Justin Mclean  Hi,
>
> Sorry but it’s -1 (binding) as it contains compiled code (a .jar) [1], an
> ASF release must consist of source code only. The other issue are minor IMO
> and can be fixed in a future release.
>
> I checked:
> - incubating in name
> - signature and hashed correct
> - LICENSE is fine
> - NOTICE has some minor issue (see below)
> - All source files have have headers
> - An unexpected binary file in source release [1]
> - Can compile from source
>
> Re NOTICE did you project come to the ASF in 2016? Who did it come from,
> and if the headers were changed to ASF ones then they should be mentioned
> in NOTICE.
>
> Should this file have an ASF header? [2] Where did it originally come
> from? Answer to this question may mean that some changes to LICENSE and
> HEADER are required.
>
> Re the maven wrapper jar several project have run into this issue and have
> managed to resolve it without including the jar. You should be able to find
> them with a search of this list. BTW A warning that rat didn’t pick this up
> and it seem it doesn’t follow directories with a dot in front of them.
>
> While i can compile it looks like the build assumes the code is checked
> out of GitHub and you’re not compiling the source release as I get a lot of
> these:
> failure occured while calling class
> com.mycila.maven.plugin.license.git.CopyrightRangeProvider
> java.lang.RuntimeException: Could not compute the year of the last git
> commit for file x
>
> Thanks,
> Justin
>
> 1. ./.mvn/wrapper/maven-wrapper.jar
> 2. .mvn/wrapper/MavenWrapperDownloader.java
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Release Apache Zipkin Brave Karaf (Incubating) version 0.1.2

[Adrian Cole]

> The product name is a problem.
>
> Please explain how this release relates to Apache Karaf? We can give you 
> branding guidance once you do.
Sure thing. Zipkin is a tracing system and Brave is the original name
of the tracing libary, and the most widely used one. We currently file
"Brave" under the "Zipkin" brand, though users of it think of the
product as a top-level one.

As tracing ends up integrating with other libraries, our artifacts end
up being named brave-XXX where XXX is the library it is supporting.
For example, the brave repo itself has a dozen such things. Karaf was
split out because it is a specialized community with its own notion of
tests and such (PAX exam , etc).

So, this repo includes support libraries for those using Karaf
directly or indirectly (via CXF). Most of the Zipkin community
(including me) are not that familiar with the Karaf ecosystem. We've
mostly been just supporting the library by updating build etc and
trying to keep it passing tests.

Christian Schneider wrote most of this and we've had some advice from
Andriy Redko as well. Folks like these could likely more intelligently
answer Karaf related specifics.

Hope this helps, and thanks for having a look!
-A

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

Re: [VOTE] Release Apache Zipkin Brave Karaf (Incubating) version 0.1.2

[Adrian Cole]

> Re NOTICE did you project come to the ASF in 2016? Who did it come from, and 
> if the headers were changed to ASF ones then they should be mentioned in 
> NOTICE.
I've not seen any example of a project noting prior headers like this,
so I winged a pull request. Feedback welcome!
https://github.com/apache/incubator-zipkin-brave-karaf/pull/30

> Should this file have an ASF header? [2] Where did it originally come from? 
> Answer to this question may mean that some changes to LICENSE and HEADER are 
> required.
> [2] .mvn/wrapper/MavenWrapperDownloader.java
similar to above, I've not found any apache project special-casing the
maven wrapper downloader file. We didn't affect the headers either..
are you looking for a statement inside NOTICE to say we used takari's
script to generate this? Is that required considering the license
header is apache? If so, wouldn't most apache projects need to do
this, as opposed to just us?

> Re the maven wrapper jar several project have run into this issue and have 
> managed to resolve it without including the jar. You should be able to find 
> them with a search of this list. BTW A warning that rat didn’t pick this up 
> and it seem it doesn’t follow directories with a dot in front of them.
done - https://github.com/apache/incubator-zipkin-brave-karaf/pull/30

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

Re: [VOTE] Release Apache Zipkin Brave Karaf (Incubating) version 0.1.2

[Adrian Cole]

> See [1][2] on policy and many many projects do it except those that were 
> developed solely at the ASF.
In practice, you can find many, many that have stock files and were
not developed solely at the ASF.

Considering our statement was "The OpenZipkin Authors", I have not
seen any file at all like this.. noting a non-legal entity.. though I
haven't searched the entire org.
I'm not saying this to be argumentative, rather it feels like cruft
and not commonly applied. I wish others would chime in on topics like
this.

> Where does the code original come from is the question? That ASF header 
> states it was licensed to the ASF under an CLA. Is this actually the case?

Again, this seems a site of unique enforcement with questionable
clarity as a result. You seem to want us to add a statement saying
that this code came from the Takari maven plugin and/or to investigate
their CLA process. You are asking us eventhough many many projects use
this as-is. We can follow this, but the same feedback applies.

The general feedback is that we are being asked to do things of
questionable value even if it is to the letter of the law as you
interpret it. Meanwhile graduated projects do not fall under this more
strict regime and the types of enforcement are certainly more strict.
It seems strict enforcements in general should be a community decide
thing vs one person, even if you are very qualified, Justin.

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

the case of the maven wrapper

[Adrian Cole]

I suspect this has gone around in some incarnations, but I wanted to
bring the topic to the front.

One of the main problems solved in Gradle was environment consistency
through "wrapper scripts". Wrappers lock the version of the tool and
incidental dependencies in order to stabilize the build. This approach
was backported to Maven, and the more popular wrapper seems to be by
Takari.

As binaries are not allowed in source repos, the maven wrapper
introduces a small java source file which bootstraps the tool. This
has Apache license headers on it. Many apache projects use this, but
I'm not going to mention them specifically as I don't want to cause
them work.

As a part of Zipkin's first attempt to vote a release on the general
list, Justin lightly dinged the maven wrapper file, asking for it to
be in the NOTICE box. While this is possibly a reasonably ask, it is
ironic as its presence was to avoid another ding (jar inclusion).
https://github.com/takari/maven-wrapper/blob/master/.mvn/wrapper/MavenWrapperDownloader.java

While we can add some text like "the maven wrapper is also licensed to
apache", I'm concerned about cruft in the NOTICE. It feels we are just
adding things to it and as an end user, I'm not sure how this would
add clarity. Even if it did, I'm concerned that we are jumping to a
enforcement remediation when no-one seems to be doing it at all.

I would like to feel things like this are thought through, that
multiple people agree to enforce something even if it can reasonably
be thought as required. It feels like this has either not been
discussed or not applied.. possibly some just sacrifice users by
excluding the wrapper, maybe only to avoid having to add cruft to
their NOTICE files.. who knows.

TL;DR; is can people please discuss this and chime in? I would feel
better about the incubator process if not just code was a community
process, but also enforcement policies.

If more than one person says.. yeah you totally should blurb this..
and those people themselves use the wrapper and are willing to update
their own NOTICE files.. the incubator would feel like a more fair
place than it feels today.

Best,
-Adrian

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

Re: the case of the maven wrapper

[Adrian Cole]

To help others participate, here is the original thread:
https://lists.apache.org/thread.html/8e9b5ec9b8fcc14427bee4dc64f4db7692b787e6349ed348b983d914@%3Cgeneral.incubator.apache.org%3E

Here is the part about the file in question:
> Should this file have an ASF header? [2] Where did it originally come from? 
> Answer to this question may mean that some changes to LICENSE and HEADER are 
> required.
> 2. .mvn/wrapper/MavenWrapperDownloader.java

My goal is to verify that Justin's attention to detail matches what
experience IPMC, and more importantly what Apache desires when
applying their policy. In that manner, I really want to hear from
projects who are willing to change their own code each time Justin
asks an incubator project to do that. Of course, unrelated feedback is
also good!

-A

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

Re: [VOTE] Release Apache Zipkin Brave Karaf (Incubating) version 0.1.2

[Adrian Cole]

>
> Did the Zipkin project file an SGA? If no, the contribution is all ICLA
> based and you are correct.


> If yes, then AFAIK Justin is correct, but there may be other edge cases.
>
There was no SGA. This particular codebase was also primarily authored by
iCLA signers. In Zipkin, we did an odd thing which was the IP stuff up
front.

Not every TLP may follow policy to the letter. Issues may have been missed
> in the past. A TLP may not have gone through the Incubator. You are free to
> examine the history of every project’s NOTICE file. If you do not accept
> the collective advice here and wish a ruling then you can ask the legal
> affairs committee at legal-disc...@apache.org by filing a LEGAL JIRA. But
> wait a bit to see. People who would answer there are as likely to answer
> here.
>
Most importantly, I am trying to figure out if advice is collective or not.
This is mainly an issue of understanding if all Justin's comments are to be
taken as a collective without others saying anything. We are lucky to have
people speak a lot but it would be nice to have especially detailed points
asked as "yeah you should do this" especially when others are clearly not.
I hope you saw my other thread opened as I doubt discussing also here will
get the same visibility into what could become a crisis if not watched over
well.

Re: the case of the maven wrapper

[Adrian Cole]

> Does it help, that I wrote that file and submitted it in a pull request to
> eliminate the binary jar needed prior to my change? ... Guess that's also
> an additional reason why there's an Apache header on it :-)


imho it helps in so far as the work itself (thanks!) and also a subject
matter expert. I see this file as useful but incidental.

If we set a precedent towards having to re-link this file in our NOTICE..
you might expect this to cause a flurry of low value activity across every
project that uses it, to do the same, or projects like us feeling unfair
burden by accident of the month we joined the incubator.  ex if we did
early last year surely this discussion would haven't happened (as others
graduated before the more recent scrutiny of incubees.

If we all say fine.. let's just throw more paperwork at it, I would ask you
to help draft a line for the NOTICE of what we would do. suppose we would
also have to do this for gradle etc.

So basically if we accept that the new norm is this level of detail on
incidental files, we likely have more volunteer time spent policing and
remediation. We could at least tell them what to say.

would it be "this includes source generated by the takari maven plugin"?
and of course if we say this, the next cruft is explaining gradle etc.

do we want to do this? we can but is it really worthwhile?

you tell me

Re: the case of the maven wrapper

[Adrian Cole]

> But in the end ... if we actually do include code by takari isn't if fair
> to mention it?
>
this is where I am trying to get at actually. is it an intention to change
the NOTICE files

After all it's not just the Java code the wrapper scripts themselves should
> count too.
> And in the end it's a one-time addition that will stick there for the rest
> of time.
> So give it 5 minutes (max) of work and we're on the safe side. Better than
> loosing
> Hours in email discussions ;-)
>
not quite true I think you know the act of changing artifacts and release
can be very expensive in practice. some projects have review on trivial
things as well. Then, new projects get to be dinged for yet another thing.
If they have to re release once it can cost 10hrs easy.

Some might simply not distribute the wrapper anymore. people are weird.
NOTICE file particularly because some feel it is a credit thing. being
listed or not listed is emotional. even if I dont personally care, I dont
particularly want to converse with someone about why their name is not in
there while takari is.

This is why I think when we are changing enforcement, and clearly this is a
change, we should think it through. This is important precedent wise.

Re: the case of the maven wrapper

[Adrian Cole]

FYI I've asked takari to donate the wrapper to the ASF. It is
important but tiny
https://github.com/takari/takari-maven-plugin/issues/18

Meanwhile, we will remove the wrapper from the source distribution as
putting it in the NOTICE file is something off-putting to a few of our
contributors. We can build without the wrapper and it isn't worth
making a commitment to the NOTICE file for what seems not thought
through.

If the enforcement rules loosen back to where we don't need to do
this, or the plugin or a copy of it is donated to the ASF, we'll
likely put it back into the source distribution.

On Thu, Feb 14, 2019 at 3:29 PM Justin Mclean  wrote:
>
> Hi,
>
> > If we all say fine.. let's just throw more paperwork at it, I would ask you
> > to help draft a line for the NOTICE of what we would do. suppose we would
> > also have to do this for gradle etc.
>
> You would need to do this for any 3rd party file bundled with a release and 
> yes sometimes this is complex and takes time. See for example Apache Newt. [1]
>
> > So basically if we accept that the new norm is this level of detail on
> > incidental files,
>
> It’s a 3rd party file not an incidental file and the ASF has policy around 
> what to do when including 3rd party files which a (P)PMC and releases need to 
> comply with. [2][3]
>
> To comply however is a simple change that needs to be made once to clearly 
> inculcate the IP province and license of that file to users of the projects.
>
> > would it be "this includes source generated by the takari maven plugin"?
> > and of course if we say this, the next cruft is explaining gradle etc.
>
> If you don’t know what to do ask you mentors or the IPMC for help. If you 
> disagree with advice given then clarify on legal-discuss.
>
> Thanks,
> Justin
>
> 1. https://github.com/apache/mynewt-newt/blob/master/LICENSE
> 2. http://www.apache.org/dev/release-publishing.html#goal
> 3. http://www.apache.org/dev/release-publishing.html#valid
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

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

Re: [VOTE] Release Apache Zipkin Brave Karaf (Incubating) version 0.1.2

[Adrian Cole]

We would really prefer us to not have to add a non standard and explicit
line in the NOTICE file about "The OpenZipkin Authors" as it doesnt exist
as a legal entity and even if it did, it didn't sign an SGA.

We would like that to not only be a non-blocker for this release, but also
subsequent ones in different repos which are yet to move. In other words,
we would like a clean file and if there is confusion on this topic it be
fully resolved prior to any more work on incubation.

In other words agree that this "The OpenZipkin Authors" addendum to the
NOTICE is neither required nor will be resurrected as a blocker to a future
release or graduation? If this is a disagreement, we would prefer to have
multiple IPMC members say so and why before asking us to escalate to legal.

Finally, there was an unresolved question about branding of the repo. I
dont think we should attempt another release if there is something else
lurking.

Thanks for the help folks.

-Adrian


On Thu, Feb 14, 2019, 7:40 PM John D. Ament  On Thu, Feb 14, 2019 at 6:35 AM Justin Mclean  wrote:
>
> > Hi,
> >
> > > I can follow up with the developer to fix their headers via a github
> > issue (if no one else gets to it before me).
> >
> > I already have raise it as an issue :-)  Add to it it if you want. [1]
> >
> > > Including prior statements about NOTICE is completely optional, but in
> > the
> > > case of no SGA would be ideal.  I don't think that's a blocker for
> > release …
> >
> > No neither do I think it is a blocker, but having a jar in a source
> > release is.
> >
> >
> And I can see in the repo that's already been resolved.  So I think
> Adrian's all set to re-roll the release and put it up for a vote.
>
>
> > Thanks,
> > Justin
> >
> > 1. https://github.com/takari/maven-wrapper/issues/104
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: [VOTE] Release Apache Zipkin Brave Karaf (Incubating) version 0.1.2

[Adrian Cole]

Perfectly fine naming suggestion. thanks, Dave.

"Apache Zipkin Brave (incubating) for Apache Karaf"

I will put that into a pull request and suspect no-one will contest it.

-A

On Fri, Feb 15, 2019, 7:43 AM Dave Fisher  Hi Adrian,
>
> (NOTE - cross posted to private lists. Take care with replies.)
>
> Thanks for your patience regarding the branding issue I mentioned.
>
> > On Feb 14, 2019, at 4:29 AM, Adrian Cole 
> wrote:
>
> 
>
> > Finally, there was an unresolved question about branding of the repo. I
> > dont think we should attempt another release if there is something else
> > lurking.
>
> The name Apache Zipkin Brave Karaf (incubating) represents a confusion of
> two Apache Brands - Zipkin an incubating podling and Apache Karaf.
>
> See http://www.apache.org/foundation/marks/pmcs#other
>
> This suggests that the proper name respecting Karaf’s brand would be
> "Apache Zipkin Brave (incubating) for Apache Karaf"
>
> Regards,
> Dave
>
> >
> > Thanks for the help folks.
> >
> > -Adrian
> >
> >
> > On Thu, Feb 14, 2019, 7:40 PM John D. Ament  wrote:
> >
> >> On Thu, Feb 14, 2019 at 6:35 AM Justin Mclean 
> wrote:
> >>
> >>> Hi,
> >>>
> >>>> I can follow up with the developer to fix their headers via a github
> >>> issue (if no one else gets to it before me).
> >>>
> >>> I already have raise it as an issue :-)  Add to it it if you want. [1]
> >>>
> >>>> Including prior statements about NOTICE is completely optional, but in
> >>> the
> >>>> case of no SGA would be ideal.  I don't think that's a blocker for
> >>> release …
> >>>
> >>> No neither do I think it is a blocker, but having a jar in a source
> >>> release is.
> >>>
> >>>
> >> And I can see in the repo that's already been resolved.  So I think
> >> Adrian's all set to re-roll the release and put it up for a vote.
> >>
> >>
> >>> Thanks,
> >>> Justin
> >>>
> >>> 1. https://github.com/takari/maven-wrapper/issues/104
> >>> -
> >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >>> For additional commands, e-mail: general-h...@incubator.apache.org
> >>>
> >>>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@zipkin.apache.org
> For additional commands, e-mail: dev-h...@zipkin.apache.org
>
>

Re: the case of the maven wrapper

[Adrian Cole]

The request to donate the wrapper was closed won't fix (they did
adjust the license headers)

I've made a comment on a 3+ year old issue on maven itself, which had
excluded the wrapper due to perceived problems in performing change
inside the ASF

https://issues.apache.org/jira/browse/MNG-5937?focusedCommentId=16771456&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16771456

On Thu, Feb 14, 2019 at 4:18 PM Adrian Cole  wrote:
>
> FYI I've asked takari to donate the wrapper to the ASF. It is
> important but tiny
> https://github.com/takari/takari-maven-plugin/issues/18
>
> Meanwhile, we will remove the wrapper from the source distribution as
> putting it in the NOTICE file is something off-putting to a few of our
> contributors. We can build without the wrapper and it isn't worth
> making a commitment to the NOTICE file for what seems not thought
> through.
>
> If the enforcement rules loosen back to where we don't need to do
> this, or the plugin or a copy of it is donated to the ASF, we'll
> likely put it back into the source distribution.
>
> On Thu, Feb 14, 2019 at 3:29 PM Justin Mclean  
> wrote:
> >
> > Hi,
> >
> > > If we all say fine.. let's just throw more paperwork at it, I would ask 
> > > you
> > > to help draft a line for the NOTICE of what we would do. suppose we would
> > > also have to do this for gradle etc.
> >
> > You would need to do this for any 3rd party file bundled with a release and 
> > yes sometimes this is complex and takes time. See for example Apache Newt. 
> > [1]
> >
> > > So basically if we accept that the new norm is this level of detail on
> > > incidental files,
> >
> > It’s a 3rd party file not an incidental file and the ASF has policy around 
> > what to do when including 3rd party files which a (P)PMC and releases need 
> > to comply with. [2][3]
> >
> > To comply however is a simple change that needs to be made once to clearly 
> > inculcate the IP province and license of that file to users of the projects.
> >
> > > would it be "this includes source generated by the takari maven plugin"?
> > > and of course if we say this, the next cruft is explaining gradle etc.
> >
> > If you don’t know what to do ask you mentors or the IPMC for help. If you 
> > disagree with advice given then clarify on legal-discuss.
> >
> > Thanks,
> > Justin
> >
> > 1. https://github.com/apache/mynewt-newt/blob/master/LICENSE
> > 2. http://www.apache.org/dev/release-publishing.html#goal
> > 3. http://www.apache.org/dev/release-publishing.html#valid
> >
> >
> > -
> > 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

[VOTE FAILED] Release Apache Zipkin Brave Karaf (Incubating) version 0.1.2

[Adrian Cole]

This vote failed due to binaries in the distribution. Will send a new
vote shortly.

Thanks for the input, all.
-A

On Fri, Feb 15, 2019 at 7:56 AM Adrian Cole  wrote:
>
> Perfectly fine naming suggestion. thanks, Dave.
>
> "Apache Zipkin Brave (incubating) for Apache Karaf"
>
> I will put that into a pull request and suspect no-one will contest it.
>
> -A
>
> On Fri, Feb 15, 2019, 7:43 AM Dave Fisher >
>> Hi Adrian,
>>
>> (NOTE - cross posted to private lists. Take care with replies.)
>>
>> Thanks for your patience regarding the branding issue I mentioned.
>>
>> > On Feb 14, 2019, at 4:29 AM, Adrian Cole  wrote:
>>
>> 
>>
>> > Finally, there was an unresolved question about branding of the repo. I
>> > dont think we should attempt another release if there is something else
>> > lurking.
>>
>> The name Apache Zipkin Brave Karaf (incubating) represents a confusion of 
>> two Apache Brands - Zipkin an incubating podling and Apache Karaf.
>>
>> See http://www.apache.org/foundation/marks/pmcs#other
>>
>> This suggests that the proper name respecting Karaf’s brand would be "Apache 
>> Zipkin Brave (incubating) for Apache Karaf"
>>
>> Regards,
>> Dave
>>
>> >
>> > Thanks for the help folks.
>> >
>> > -Adrian
>> >
>> >
>> > On Thu, Feb 14, 2019, 7:40 PM John D. Ament > >
>> >> On Thu, Feb 14, 2019 at 6:35 AM Justin Mclean  wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>>> I can follow up with the developer to fix their headers via a github
>> >>> issue (if no one else gets to it before me).
>> >>>
>> >>> I already have raise it as an issue :-)  Add to it it if you want. [1]
>> >>>
>> >>>> Including prior statements about NOTICE is completely optional, but in
>> >>> the
>> >>>> case of no SGA would be ideal.  I don't think that's a blocker for
>> >>> release …
>> >>>
>> >>> No neither do I think it is a blocker, but having a jar in a source
>> >>> release is.
>> >>>
>> >>>
>> >> And I can see in the repo that's already been resolved.  So I think
>> >> Adrian's all set to re-roll the release and put it up for a vote.
>> >>
>> >>
>> >>> Thanks,
>> >>> Justin
>> >>>
>> >>> 1. https://github.com/takari/maven-wrapper/issues/104
>> >>> -
>> >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> >>> For additional commands, e-mail: general-h...@incubator.apache.org
>> >>>
>> >>>
>> >>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@zipkin.apache.org
>> For additional commands, e-mail: dev-h...@zipkin.apache.org
>>

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

[VOTE] Release Apache Zipkin Brave (incubating) for Apache Karaf version 0.1.2

[Adrian Cole]

Hello All,

This is a call for vote to release Apache Zipkin Brave (incubating)
for Apache Karaf version 0.1.2

The Apache Zipkin community has voted on and approved a proposal to
release Apache Zipkin Brave (incubating) for Apache Karaf version
0.1.2.

We now kindly request the Incubator PMC members review and vote on
this incubator release.

Apache Zipkin Brave (incubating) for Apache Karaf sets up tracing
components such that tools built Karaf needn't configure these
explicitly.

Zipkin community vote and result thread:
https://lists.apache.org/thread.html/32baf4b4b65644dd1dd8e2bf0cb360c94f8f939d61c5444b8f4ef45b@%3Cdev.zipkin.apache.org%3E

The release candidates:
https://dist.apache.org/repos/dist/dev/incubator/zipkin/brave-karaf/0.1.2/

Git tag for the release:
https://github.com/apache/incubator-zipkin-brave-karaf/tree/v0.1.2

Hash for the release tag:
3cf4ac6577eb0d4775d20f24814e7a0852fa1635

Release Notes:
https://github.com/apache/incubator-zipkin-brave-karaf/releases/tag/v0.1.2

The artifacts have been signed with Key : BB67A050, which can be found
in the keys file:
https://dist.apache.org/repos/dist/dev/incubator/zipkin/KEYS

Verification Hints:
For your convenience, the below includes detailed how-to on verifying
a source release. Please note that this document is a work-in-progress
https://cwiki.apache.org/confluence/display/ZIPKIN/Verifying+a+Source+Release

The vote will be open for at least 72 hours or until necessary number
of votes are reached.

Please vote accordingly:

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason

Thanks,
The Apache Zipkin (Incubating) Team

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

[RESULT][VOTE] Release Apache Zipkin Brave (incubating) for Apache Karaf version 0.1.2

[Adrian Cole]

Thanks to everyone that participated. The vote to release Apache
Zipkin Brave (incubating) for Apache Karaf version 0.1.2 is now
closed. It passed with 6 (+1 binding) votes and no 0 or -1 votes.

Results:
6 (+1 binding) from 姜宁 Willem Jiang, 吴晟 Sheng Wu, Andriy Redko,
Olivier Lamy, John D. Ament, Jean-Baptiste Onofré

0 (-1 binding)

0 (+1 unbinding)

Vote thread:

https://lists.apache.org/thread.html/4ed7c8ea65e7300a008dd9ac3d0485eba4a1caa7585809e453ad25f8@%3Cgeneral.incubator.apache.org%3E

We will work to complete the release process.

Thanks,
The Apache Zipkin (Incubating) Team

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

SOS for infra related glitches

[Adrian Cole]

Hi, all.

Problems getting subscribed to mailing lists can be crippling. For
example, we have someone stuck in workflow steps where they are
supposed to formally reply to a private@ invitation to join the PPMC.
We've had several people with and without moderator access try to
help. It is really disruptive to things like becoming a committer to
be stuck in pergatory for days.. hoping the next is when you can
actually reply.

Consider all the paperwork for tasks in incubator, like a new member
being not only a circulatory conversation, but also 72hr vote, then
72hr notice period, then an invite.. compared to the incubator doc
pile-on where basically anyone can edit the wiki before acceptance! It
feels frustrating to get through the gauntlet then stuck in email
subscription hell.

Is there an SOS we can use, conservatively, like for tasks like this?
Considering a lot of our problems have been getting people on the
private list (we still have PPMC how have tried and failed many
times), granting the ability to manually add people seems a reasonable
"break glass" process to consider as well.

-A

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

Re: SOS for infra related glitches

[Adrian Cole]

> The infra team is on slack and they are very responsive to sos type of
> questions...

Great! didn't realise that. Thanks

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

Re: SOS for infra related glitches

[Adrian Cole]

for closure. here's the slack info
https://www.apache.org/dev/infra-volunteer#slack

On Wed, Mar 6, 2019 at 10:24 PM Adrian Cole  wrote:
>
> > The infra team is on slack and they are very responsive to sos type of
> > questions...
>
> Great! didn't realise that. Thanks

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

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check

[Adrian Cole]

Drive by opinion here, since one of the topics is about expiring "merit"

On one hand, you want to encourage participation and people being one
of NNN where NNN are inactive is demotivating
On one hand, you want to immortalize merit, but is an incubator wiki
pile-on indicative of merit?
On one hand, you want to have fairness, like expiring access after
inactivity, but will people get super mad and hate you for a decade if
they are removed?

It is a loaded topic, almost doomed to fail. Personally, I think
"merit doesn't expire" is weak. There are people who willingly damage
projects and plenty of other reasons to consider decisions that seemed
good at first to not be good long term. Which leads into the bike shed
nature of this topic. Many can take a side as it is easy
participation.. we all have stories with contradicting conclusions.

For that reason alone, I think projects themselves should be able to
decide their culture inclusive of their expiry policy for access. I
don't think this topic will result in any convergence of a one road
out.. and I also feel that way with  "merit doesn't expire". That by
itself is suspiciously attributed to the ASF and I would bet any
amount of money not close to a majority agree with that in private
even if they would out loud.

Can we sideline this or move it somewhere else in other words?
-A

On Thu, Mar 7, 2019 at 5:07 AM Dmitriy Pavlov  wrote:
>
> Hi Daniel,
>
> There are two independent questions here.
>
> 1) Removal question and its allowance in general:  this question asked
> during every talk I gave related to ASF. My fellows ask me if someone can
> remove Committer or PMCs. Some folks think it is possible by the vote of
> PMC. They refer to docs I've shared: mnemonic project & incubator guide.
>
> Here I need some general understanding which I can use for
> answering questions.
>
> 2) Inactive members removal: Lack of active PMCs member makes me thinks
> that at some point some removal will be necessary. We can
> continuously grow the roster for a TLP project, but sometimes I feel there
> are ~30 members and only 5-7 active members. So why don't we narrow the
> roster to 7 and invite new members?
>
> It looks reasonable that if you want a binding vote, approve releases,
> propose new committers you need to join community communication channels
> and be there.  My idea is, first of all, ask PMCs if they want to stay or
> leave and, second of all, to always keep committership, because it is based
> on merit.
>
> And here for option 2, I don't have any severe issues to address. If it a
> bad idea, not a problem. In that case, I also would be happy if I
> understand this topic better.
>
> Sincerely,
> Dmitriy Pavlov
>
>
> ср, 6 мар. 2019 г. в 23:12, Daniel Gruno :
>
> > On 3/6/19 9:08 PM, Dmitriy Pavlov wrote:
> > > Hi Ross,
> > >
> > > Thank you for your reply. Apache Ignite PMCs do not support this idea, so
> > > inactive PMCs will be still there.
> > >
> > > But still, it is not clear for me in general, why following
> > > projects/guidelines contains removal procedure for Committer PMC:
> > > - https://mnemonic.apache.org/develop/bylaws/  after 6 months of
> > inactivity
> > > both PMC and Committer status may be removed.
> > > - Default Incubator guidelines
> > > https://wiki.apache.org/incubator/DefaultProjectGuidelines It contains
> > > procedures of consensus-based removal, - it is ok to remove for
> > Incubator?
> > > is it ok for TLP?
> > >
> > > If both PMC & Committer roles are merit-based, and merit does not expire,
> > > how it even possible to remove TLP committer/PMC (excepting some extreme
> > > cases)?
> > >
> > > This question is not only mine, but it is also often asked and I would
> > like
> > > to know the answer.
> >
> > Turn the question around; *why* are you looking to remove people? What
> > is the problem you are trying to solve here? How will removing someone
> > from the PMC/committer list help address the issues you are facing?
> >
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >

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

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check

[Adrian Cole]

> The standard response to this would be a question in return. Instead of
> "remove inactive members and add new ones" why not just "add new ones".

wires crossed and not IPMC (yet), but I agree with this rationale.
Avoid the loaded topic. focus on the important one.

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

Re: [VOTE] Recommend 'Apache SkyWalking graduation to Top Level Project' resolution to board

[Adrian Cole]

+1 not binding

On Wed, Mar 20, 2019 at 10:38 AM juan pan  wrote:
>
> +1 no binding
>
> Best Regards!
>
> -
> Juan Pan (Trista)
> Apache ShardingSphere
>
> On 2019/03/19 05:21:41, "Mick Semb Wever"  wrote:
> >
> >
> > After the latest discussion amongst this dev community on this dev mailing 
> > list[1],  presenting Sheng Wu as the PMC Chair and the maturity model[2], 
> > and then the discussion again on the incubator list[3],  a vote for Apache 
> > SkyWalking graduating to a top level project was called and has passed[4]. 
> > From the past incubator discussions the PPMC altered the draft graduation 
> > proposal, specifically the proposed PMC list: removing some inactive people 
> > and adding all the podling Committers. >
> >
> >
> > Apache SkyWalking entered the incubator on December of 2017.  SkyWalking 
> > has delivered 8 releases so far in total, and now shows a good cadence of 
> > successful releases.>
> >
> > During the podling's time in the Apache Incubator there has been>
> >  3200+ commits on development of the project,>
> >   378 Issues tagged as question in GitHub created, 373 resolved,>
> >   850+ Pull request created and resolved,>
> >   97 different contributors,>
> > 9 elected new committers, and>
> > 3 elected new PPMC members.>
> >
> > And the dev ML has had 72 participants: 
> > https://lists.apache.org/trends.html?d...@skywalking.apache.org:2019>
> >
> > Attached is the draft Resolution for the PPMC and IPMC to vote upon.>
> >
> > Please take a minute to vote on whether or not Apache SkyWalking should>
> > graduate to a Top Level Project by responding with one of the following:>
> >
> > [ ] +1 Apache SkyWalking should graduate.>
> > [ ] +0 No opinion>
> > [ ] -1 Apache SkyWalking should not graduate (please provide the reason)>
> >
> > The VOTE is open for a minimum of 72 hours. As there has been previous 
> > discussions on past versions of this proposal, I have not preluded the vote 
> > with a DISCUSS email. If feedback arises the vote period will be extended 
> > in good faith.>
> >
> > regards,>
> > Mick>
> >
> >
> > [1] 
> > https://lists.apache.org/thread.html/9aab116a5df46d10a655bbf243f525260bad7763f6f65bce19ec33bd@%3Cdev.skywalking.apache.org%3E>
> > [2] 
> > https://cwiki.apache.org/confluence/display/SKYWALKING/Apache+Maturity+Model+Assessment+for+SkyWalking>
> > [3] 
> > https://lists.apache.org/thread.html/68b06b2efdcd4f519cd9aa3df55d46bf0dade28002065fbad75d4195@%3Cdev.skywalking.apache.org%3E>
> > [4] 
> > https://lists.apache.org/thread.html/9f05862dffb40a967f867ba0fee4ab8549b08736cde27571e303ab30@%3Cdev.skywalking.apache.org%3E>
> >
> > >
> >
> >
> > Establish the Apache SkyWalking 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 application performance management and monitoring (APM).>
> >
> > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee>
> > (PMC), to be known as the "Apache SkyWalking Project", be and hereby is>
> > established pursuant to Bylaws of the Foundation; and be it further>
> >
> > RESOLVED, that the Apache SkyWalking Project be and hereby is>
> > responsible for the creation and maintenance of software related to>
> > application performance management and monitoring (APM); and >
> > be it further>
> >
> > RESOLVED, that the office of "Vice President, Apache SkyWalking" 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>
> > SkyWalking Project, and to have primary responsibility for management of>
> > the projects within the scope of responsibility of the Apache SkyWalking>
> > 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 SkyWalking>
> > Project:>
> >
> >   * Haoyang Liu  (刘浩杨)  >
> >   * Hongtao Gao  (高洪涛)  >
> >   * Ignasi Barrera  >
> >   * Mick Semb Wever >
> >   * Sheng Wu  (吴晟)  >
> >   * Shinn Zhang  (张鑫)   >
> >   * Willem Ning Jiang  (姜宁)>
> >   * Yongsheng Peng  (彭勇升)   >
> >   * DongXue Si (司冬雪)>
> >   * Jian Tan (谭建)   >
> >   * Kai Wang (王凯)   >
> >   * Yang Bai (柏杨)   >
> >   * Yao Wang (王垚)   >
> >   * Zhang Kewei (张科伟)  >
> >  * Can Li (李璨)  >
> >  * Jiaqi Lin (林嘉绮)  >
> >  * Jinlin Fu (付金林)  >
> >  * Lang Li (李浪)   >
> >  * Wenb

[VOTE] Release Apache Zipkin Brave (incubating) for Apache Cassandra version 0.10.2

[Adrian Cole]

The Apache Zipkin community has voted on and approved a proposal to
release Apache Zipkin Brave (incubating) for Apache Cassandra version
0.10.2. The voting thread can be found here:
https://lists.apache.org/thread.html/c2c55a0e347f90bcb07032b4fa79e34a6832742e7284d7f327583b23@%3Cdev.zipkin.apache.org%3E

Three binding +1 vote from mentors Andriy Redko, Willem Ning Jiang and
Mick Semb Wever carry over from the dev list thread.

We now kindly request the Incubator PMC members review and vote on
this incubator release.

Apache Zipkin Brave (incubating) for Apache Cassandra allows you to
trace activities started by Datastax Java Driver for Apache Cassandra
all the way to inside Apache Cassandra itself. It was originally
created by Mick at The Last Pickle and also championed by Lance at
Smart Things.

The release candidates:
https://dist.apache.org/repos/dist/dev/incubator/zipkin/brave-cassandra/0.10.2/

Git tag for the release:
https://github.com/apache/incubator-zipkin-brave-cassandra/tree/v0.10.2

Hash for the release tag:
b8e379f33eb9f52f0742d3187252de330163cbf7

Release Notes:
https://github.com/apache/incubator-zipkin-brave-cassandra/releases/tag/v0.10.2

The artifacts have been signed with Key : BB67A050, which can be found
in the keys file:
https://dist.apache.org/repos/dist/dev/incubator/zipkin/KEYS

Verification Hints:
For your convenience, the below includes detailed how-to on verifying
a source release. Please note that this document is a work-in-progress
https://cwiki.apache.org/confluence/display/ZIPKIN/Verifying+a+Source+Release

The vote will be open for at least 72 hours or until necessary number
of votes are reached.

Please vote accordingly:

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason

Thanks,
The Apache Zipkin (Incubating) Team

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

[RESULT][VOTE] Release Apache Zipkin Brave (incubating) for Apache Cassandra version 0.10.2

[Adrian Cole]

Thanks to everyone that participated. The vote to release Apache
Zipkin Brave (incubating) for Apache Cassandra version 0.10.2 is now
closed. It PASSED with 3 (+1 binding) votes and no 0 or -1 votes:

+1 Andriy Redko (binding)
+1 Willem Jiang (binding)
+1 Mick Semb Wever (binding)

Vote thread:
https://lists.apache.org/thread.html/6e26ccaecba70a5cde1f808d82499701562f370441067b96ca65f09a@%3Cgeneral.incubator.apache.org%3E

We will work to complete the release process.

Thanks,
The Apache Zipkin (Incubating) Team

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

Re: Voting on releases with serious unaddressed issues

[Adrian Cole]

I agree please email the author of the cat photo or find another cat.
This topic is boring and probably there are actual important things we
are defocused from when focusing so massively on this photo.

On Sun, Mar 31, 2019 at 10:51 AM Davor Bonaci  wrote:
>
> The issue at hand is simply called theft, and everyone (both inside and
> outside the community) is most welcome to point it out and ask for it to be
> fixed. We thank those individuals who point it out, whether in IPMC or
> otherwise, and look for ways to address it as soon as possible.
>
> Fixing this issue is in the best interest of the foundation, the project,
> the community, the release manager, the copyright owner... everyone. We
> don't push back on this. We don't look for reasons why the individual has
> no standing in pointing it out. We don't find excuses. (If we do and/or
> continue as nothing happened, we'd just make a case that the theft was
> willful and action negligent -- we do not do that.)
>
> So... to be direct -- just fix the damn problem, thank Justin for pointing
> it out, and stop arguing.
>
> You may find that fixing the problem requires no code changes. If you'd
> just politely email the copyright owner, explain the situation, that ASF is
> a charity, offer to promote the photographer in legal notices, you may find
> that a reasonable person will just grant you the permission you need and
> thank you for helping promote his work. This is particularly true if you
> ask for a few photos, out of the photographer's huge collection. It is
> often as simple as that. (Try that instead of arguing here, but make sure
> to phrase things properly so that everyone understands all implications of
> licensing downstream and upstream.)
>
> On Sat, Mar 30, 2019 at 2:31 PM Craig Russell  wrote:
>
> > Hi Ted,
> >
> > > On Mar 30, 2019, at 2:22 PM, Ted Dunning  wrote:
> > >
> > > On Sat, Mar 30, 2019 at 1:57 PM Craig Russell 
> > wrote:
> > >
> > >> 
> > >>> copyright issues on the cute cat and rabbit photos [1] probably mean
> > >> that they cannot put that release in the ASF distribution area even if
> > they
> > >> do get 3 +1s without legal and infra approval.
> > >>
> > >> We have to look at risk here. Is there a risk that the owner of the
> > images
> > >> is going to make trouble?
> > >>
> > >
> > > I am kind of stunned to hear this.
> >
> > >
> > > The web site where the images came from says:
> > >
> > > We have an extensive commercial picture library of professional Nature
> > and
> > >> Pet photographs. Our images are sold on a rights managed basis and can
> > be
> > >> bought for specific and exclusive uses. All the images on this website
> > are
> > >> ©Warren Photographic and watermarked with our logo.
> > >
> > > (see https://www.warrenphotographic.co.uk/about.php)
> > >
> > > This sounds a lot like serious photographers trying to make a living.
> > > Anybody who goes to the trouble of watermarking their images is pretty
> > > serious about their work and about people stealing that work.
> > >
> > > But aside from that, quite frankly, Apache is not in the business of
> > > judging whether somebody is powerful enough or aware enough or rich
> > enough
> > > or even just cantankerous enough to make trouble for us about copyright
> > > infringement.
> >
> > This is way over the top. Please don't go there.
> >
> > > We don't even do adversarial forks of open source material
> > > where the license says that it is perfectly fine to do.
> > >
> > > So how can anybody imagine that it is OK to steal some images from people
> > > who do not grant the rights to use just because they aren't likely to
> > "make
> > > trouble"?
> > >
> >
> > I am not arguing that the image issue does not need to be resolved. Just
> > the opposite.
> >
> > Perhaps I should have elaborated: Is there a risk that during the next few
> > weeks that it will take us to either get permission or remove the image
> > that the owner is going to make trouble?
> >
> > Craig
> > >
> > >
> > >>>
> > >>> What do other IPMC members think?
> > >>
> > >> I think that if others want to dig into the details, I would encourage
> > >> them to do so. But at this point, I do not believe that the issues you
> > >> raised warrant a -1 on the release.
> > >
> > >
> > > The issue of the photos has been previously raised. The suggested
> > solution
> > > was to delete the photos.
> > >
> > > It should be done.
> >
> > Craig L Russell
> > Secretary, Apache Software Foundation
> > c...@apache.org  http://db.apache.org/jdo <
> > http://db.apache.org/jdo>
> >

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

Re: Voting on releases with serious unaddressed issues

[Adrian Cole]

It appears a jira issue was updated about the cat photo IP and what to
do about it. My 2p is park the cat thing there, give it a chance to
proceed, and let's move on.

https://issues.apache.org/jira/browse/NETBEANS-1820?focusedCommentId=16805839&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16805839

I'm excited about netbeans becoming an apache TLP, and also interested
in learning if there are things in that process (beyond the photo
snatching) other podlings like the one I am should be careful of.

Cheers,
-A

On Sun, Mar 31, 2019 at 12:35 PM Adrian Cole  wrote:
>
> I agree please email the author of the cat photo or find another cat.
> This topic is boring and probably there are actual important things we
> are defocused from when focusing so massively on this photo.
>
> On Sun, Mar 31, 2019 at 10:51 AM Davor Bonaci  wrote:
> >
> > The issue at hand is simply called theft, and everyone (both inside and
> > outside the community) is most welcome to point it out and ask for it to be
> > fixed. We thank those individuals who point it out, whether in IPMC or
> > otherwise, and look for ways to address it as soon as possible.
> >
> > Fixing this issue is in the best interest of the foundation, the project,
> > the community, the release manager, the copyright owner... everyone. We
> > don't push back on this. We don't look for reasons why the individual has
> > no standing in pointing it out. We don't find excuses. (If we do and/or
> > continue as nothing happened, we'd just make a case that the theft was
> > willful and action negligent -- we do not do that.)
> >
> > So... to be direct -- just fix the damn problem, thank Justin for pointing
> > it out, and stop arguing.
> >
> > You may find that fixing the problem requires no code changes. If you'd
> > just politely email the copyright owner, explain the situation, that ASF is
> > a charity, offer to promote the photographer in legal notices, you may find
> > that a reasonable person will just grant you the permission you need and
> > thank you for helping promote his work. This is particularly true if you
> > ask for a few photos, out of the photographer's huge collection. It is
> > often as simple as that. (Try that instead of arguing here, but make sure
> > to phrase things properly so that everyone understands all implications of
> > licensing downstream and upstream.)
> >
> > On Sat, Mar 30, 2019 at 2:31 PM Craig Russell  wrote:
> >
> > > Hi Ted,
> > >
> > > > On Mar 30, 2019, at 2:22 PM, Ted Dunning  wrote:
> > > >
> > > > On Sat, Mar 30, 2019 at 1:57 PM Craig Russell 
> > > wrote:
> > > >
> > > >> 
> > > >>> copyright issues on the cute cat and rabbit photos [1] probably mean
> > > >> that they cannot put that release in the ASF distribution area even if
> > > they
> > > >> do get 3 +1s without legal and infra approval.
> > > >>
> > > >> We have to look at risk here. Is there a risk that the owner of the
> > > images
> > > >> is going to make trouble?
> > > >>
> > > >
> > > > I am kind of stunned to hear this.
> > >
> > > >
> > > > The web site where the images came from says:
> > > >
> > > > We have an extensive commercial picture library of professional Nature
> > > and
> > > >> Pet photographs. Our images are sold on a rights managed basis and can
> > > be
> > > >> bought for specific and exclusive uses. All the images on this website
> > > are
> > > >> ©Warren Photographic and watermarked with our logo.
> > > >
> > > > (see https://www.warrenphotographic.co.uk/about.php)
> > > >
> > > > This sounds a lot like serious photographers trying to make a living.
> > > > Anybody who goes to the trouble of watermarking their images is pretty
> > > > serious about their work and about people stealing that work.
> > > >
> > > > But aside from that, quite frankly, Apache is not in the business of
> > > > judging whether somebody is powerful enough or aware enough or rich
> > > enough
> > > > or even just cantankerous enough to make trouble for us about copyright
> > > > infringement.
> > >
> > > This is way over the top. Please don't go there.
> > >
> > > > We don't even do adversarial forks of open source material
> > > > where the l

Re: [DISCUSS] Mentors SHOULD vote on podling releases prior to asking IPMC to vote

[Adrian Cole]

I have a related question. In Zipkin (incubating) last release of one of
our projects, we had 3 IPMC +1 votes prior to the formal verification vote.
Then we basically just waited 72hrs anyway with no additional votes but it
didn't matter as we had what we needed (another came later but still) [1]

If a project already has 3 IPMC members active verifying and voting.. it
might feel a bit tedious to delay a release an additional 3+ days
especially if there is no additional feedback.


Not sure the answer here, but I hope the situation is relevant to the
thread. For example, should same rules apply when there are no additional
IPMC votes needed from what is carried over from the podling vote?

-A

[1]
https://lists.apache.org/thread.html/6e26ccaecba70a5cde1f808d82499701562f370441067b96ca65f09a@%3Cgeneral.incubator.apache.org%3E

On Mon, Apr 1, 2019, 11:15 AM Ross Gardler  wrote:

> Just like so many things, this is how it used to be. In fact, back in the
> day the only time the IPMC was asked to vote was when there were not enough
> mentor votes.
>
> If you look at all the podlinga I've mentored I have only ever asked for
> an IPMC vote on two occasions (that I recall). One because I had absent
> mentors (the project never graduated due to lack of success as a community)
> and one because it was a very large and complex code base and we asked for
> extra eyes on the first release.
>
> Every other time the community worked with mentors. Once we had the votes
> we notified the IPMC that the vote had passed and moved on.
>
> Requiring an IPMC vote is akin to the board voting on all TLP releases. It
> should be stopped. The IPMC are facilitators not gate keepers.
>
> Individual IPMC members can join the podling communities if they wish to
> participate. Why are podlings and mentors answering to the IPMC by default?
>
> I know the standard answer is because mentors sometimes get too busy.
> Sure. If it happens every release is a problem and having to ask for an
> IPMC vote highlights the problem.
>
> I realize this proposal does not go this far, I'm +0 for the proposal as a
> step in the right direction, but it doesn't go far enough in my opinion.
>
> Ross
>
> Get Outlook for Android
>
> 
> From: Craig Russell 
> Sent: Sunday, March 31, 2019 8:30:35 PM
> To: Incubator
> Subject: [DISCUSS] Mentors SHOULD vote on podling releases prior to asking
> IPMC to vote
>
> This is a proposal to recommend that all Mentors SHOULD vote on podling
> releases prior to sending the release for a vote to the IPMC.
>
> This is not a MUST, since there are many good reasons why a mentor might
> be unable to perform the checks needed to vote. We are volunteers after all.
>
> But if this proposal is adopted, it will minimize the occurrences of a
> podling desperately asking for someone, anyone, on the IPMC to please vote.
>
> It should also minimize the number of podling releases that are shot down
> in the full IPMC vote because of something that a Mentor is likely to catch.
>
> Thanks for your consideration,
>
> Craig
>
> Craig L Russell
> c...@apache.org
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Mentors SHOULD vote on podling releases prior to asking IPMC to vote

[Adrian Cole]

Directly on this proposal, I agree. In Zipkin (incubating) we are lucky
that mentors are already active.

However, we should not take this for granted and certainly it would be
harder and more fragile if our mentors were not looking carefully and
voting.

-A

On Mon, Apr 1, 2019, 10:30 AM Craig Russell  wrote:

> This is a proposal to recommend that all Mentors SHOULD vote on podling
> releases prior to sending the release for a vote to the IPMC.
>
> This is not a MUST, since there are many good reasons why a mentor might
> be unable to perform the checks needed to vote. We are volunteers after all.
>
> But if this proposal is adopted, it will minimize the occurrences of a
> podling desperately asking for someone, anyone, on the IPMC to please vote.
>
> It should also minimize the number of podling releases that are shot down
> in the full IPMC vote because of something that a Mentor is likely to catch.
>
> Thanks for your consideration,
>
> Craig
>
> Craig L Russell
> c...@apache.org
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Mentors SHOULD vote on podling releases prior to asking IPMC to vote

[Adrian Cole]

one part that may not be obvious is the bookkeeping overhead on projects
with many repositories and also the load on the IPMC.

For example in zipkin, we are migrating several repositories. You can
imagine a surge of release verification votes which if people here want to
take the burden of responding to, surely can. Noting that there are already
several IPMC involved it might for some members feel less priority and they
may choose to not vote at all (such as our last release).

Probably secondary to folks here is the burden on the podling to track the
incomplete releases. It is less about rush more about excess tracking. It
is possible that a project can achieve a "good driver status" to reduce the
burden of having to create a wait condition especially if it is not the
case people do anything during it.

my 2p

On Tue, Apr 2, 2019, 5:59 AM Dave Fisher  wrote:

>
>
> > On Apr 1, 2019, at 3:42 PM, Justin Mclean 
> wrote:
> >
> > Hi,
> >
> > When Ross wrote “72hrs or 3 +1” I think he was using shorthand, not
> >> intending to rewrite foundation policy.
> >>
> >
> > Sure I thought so as well, but other newer people here might not of been
> > aware of it.
>
> The only exception to the 72 hour rule that I’ve heard about is a critical
> security fix needs to be made in which case I would hope the reason for the
> hurry would be explained on private lists.
>
> I would not put words into Ross’s mouth. He may in fact mean that he would
> go quickly when there are three +1 votes and reasons other than security.
>
> Regards,
> Dave
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Mentors SHOULD vote on podling releases prior to asking IPMC to vote

[Adrian Cole]

TL;DR; I suppose is that in the case of 3 mentor/IPMC already +1 a release
we can switch to a "review after commit" style notification so that folks
eager to double check can, but not to burden the project or IPMC with a
secondary step.

This not only reduces bookkeeping but encourages each podling to engage
mentors, helping with the original intent of this thread.

Anything noted as blocker review after commit would be addressed.

In the rare case that IPMC members acting in a podling are doing a bad job,
that could be addressed as a learning exercise as presumably they would
also be doing a bad job at the later vote too.

On Tue, Apr 2, 2019, 9:42 AM Adrian Cole  wrote:

> one part that may not be obvious is the bookkeeping overhead on projects
> with many repositories and also the load on the IPMC.
>
> For example in zipkin, we are migrating several repositories. You can
> imagine a surge of release verification votes which if people here want to
> take the burden of responding to, surely can. Noting that there are already
> several IPMC involved it might for some members feel less priority and they
> may choose to not vote at all (such as our last release).
>
> Probably secondary to folks here is the burden on the podling to track the
> incomplete releases. It is less about rush more about excess tracking. It
> is possible that a project can achieve a "good driver status" to reduce the
> burden of having to create a wait condition especially if it is not the
> case people do anything during it.
>
> my 2p
>
> On Tue, Apr 2, 2019, 5:59 AM Dave Fisher  wrote:
>
>>
>>
>> > On Apr 1, 2019, at 3:42 PM, Justin Mclean 
>> wrote:
>> >
>> > Hi,
>> >
>> > When Ross wrote “72hrs or 3 +1” I think he was using shorthand, not
>> >> intending to rewrite foundation policy.
>> >>
>> >
>> > Sure I thought so as well, but other newer people here might not of been
>> > aware of it.
>>
>> The only exception to the 72 hour rule that I’ve heard about is a
>> critical security fix needs to be made in which case I would hope the
>> reason for the hurry would be explained on private lists.
>>
>> I would not put words into Ross’s mouth. He may in fact mean that he
>> would go quickly when there are three +1 votes and reasons other than
>> security.
>>
>> Regards,
>> Dave
>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>

Re: [DISCUSS] Mentors SHOULD vote on podling releases prior to asking IPMC to vote

[Adrian Cole]

Parallel would solve our problem of delayed bookkeeping as well. good idea.

It is not so much about about the initial 72 hours, rather the pause
then another 72hrs that someone having to remember. Podlings have a
stateful experience during a release.. they have to know which are in
what stage. voting is more stateless. My goal is to have podlings and
folks who have stateful tasks to be able to complete them with no more
stages than necessary.

People will drive up quality to have less burdensome process. You'll
notice zipkin already automating things people have been emburdened by
for years [1] . If higher gates are needed for a faster process, I'm
sure we'd find a way to do that vs the alternative. No ones goal is to
do more red tape than necessary or take longer doing it I'm sure.

-A

[1] https://github.com/openzipkin-contrib/apache-release-verification

On Tue, Apr 2, 2019 at 4:30 PM Geertjan Wielenga
 wrote:
>
> Maybe the PPMC and IPMC vote could run in parallel -- a key reason why we
> in Apache NetBeans are looking forward to graduation is that we'll not need
> to go through the loop of (1) PPMC approves, (2) IPMC rejects, (3) PPMC
> needs to put together a new release and vote on it again, (4) IPMC rejects
> again (finding something else they hadn't found before), etc. That's slowed
> the releases we have done in the incubator down significantly, typically by
> at least 2 weeks -- of course, as will be pointed out, Apache NetBeans is
> very large -- but, assuming Apache wants to be a welcome place for large
> projects too, something needs to be done here (though it won't be a problem
> for Apache NetBeans anymore since we plan to graduate before our next
> release). So, if the votes were to at least run in parallel, that would
> save time, and maybe as soon as there are 3 +1s from PPMC/IPMC members,
> that should be good to go, rather than waiting another 72 hours after that,
> in situations where those votes come in quickly.
>
> Gj
>
> On Tue, Apr 2, 2019 at 11:09 AM Julian Feinauer <
> j.feina...@pragmaticminds.de> wrote:
>
> > Hi,
> >
> > I like Craigs suggestion and I'm aware of the problem with the ASF Policy
> > if we would skip the formal IPMC Vote.
> > On the other hand in PLC4X we had a discussion about a regular release
> > cycle to bring new features to the users as fast as possible and decided to
> > skip that for now, to keep the burden on the IPMC low (and we usually have
> > 3 IPMC / Mentor Votes as we have very active Mentors).
> > I agree with this decision of the PPMC but I see a problem with that, as
> > the IPMC Vote should be something to help podlings (aside from the
> > necessity by Policy) but not "negatively" impact them.
> >
> > Perhaps it helps to see the IPMC Votes more as a "take notice" in case
> > that there are already 3 +1 Votes. This means that the vote is open for
> > 72hrs formally, but IPMC members do not feel to have to go to action
> > (usually as PMC member one "should" participate in votes... although this
> > is practiced differently in the IPMC for good reasons) but CAN if they feel
> > like.
> > This would especially mean that podlings should be encouraged to formulate
> > their votes more explicit about whether there are already enough IPMC Votes
> > or not.
> >
> > Julian
> >
> >
> > Am 01.04.19, 23:51 schrieb "Justin Mclean" :
> >
> > Hi,
> >
> > I'd also like to see those mentors / IPMC members vote with more than
> > just a +1 and provide a list of what they checked. If they could use
> > something like this all the better [1].
> >
> > I wouldn’t be for removing the second step of letting the IPMC look at
> > it, reasonably often serious issues are found in that step. By skilling
> > that we risk some podlings going all the way to propose graduation while
> > having releases that don’t follow ASF policy. This is a situation I’d like
> > to avoid.
> >
> > Thanks,
> > Justin
> >
> > 1. https://wiki.apache.org/incubator/IncubatorReleaseChecklist
> > -
> > 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
> >

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

Re: Podling use of StackOverflow

[Adrian Cole]

not saying it is practical but what I was getting at with the "also
licensing to ASF" thing would be a feature request to SO similar to github
contributing file integration.

ASF members could choose to license to ASF by default and have a badge put
on their content accordingly.

This doesn't preclude SO like solutions in our own space, just thinking
aloud.

On Sat, Apr 6, 2019, 7:22 AM Adrian Cole  wrote:

> I think we should get legal clarity if folks disagree, but providing
> content under CC license does not stop you from also licensing it under ASL.
>
> IOTW, I can give an answer, license that answer simultaneously to two
> parties.
>
> Agree that we cant lift other people's content from SO based on its
> license for inclusion in ASF works.
>
> -A
>
> On Sat, Apr 6, 2019, 6:09 AM Ted Dunning  wrote:
>
>> Justin,
>>
>> THis is a huge and important point.
>>
>> I had completely forgotten that SO had these abusive terms.
>>
>> To summarize, just so everybody is clear, according to their terms of
>> service *anything* you put on SO is the property of SO. That is sooo
>> completely anti-Apache, that I have a hard time recommending their use at
>> all.
>>
>>
>> On Fri, Apr 5, 2019 at 2:17 PM Justin Mclean 
>> wrote:
>>
>> > HI,
>> >
>> > You also might want to note that anything contributed to stack overflow
>> is
>> > licensed under the CC-SA-3.0 [1] which may causes issues. [2] For
>> instance
>> > code from a stack overflow post can’t be included in a Apache project's
>> > code base. In edition also note "noncommercial use is expressly
>> prohibited
>> > without prior written permission from Stack Overflow or from the
>> copyright
>> > holder identified in the copyright notice per the Creative Commons
>> License."
>> >
>> > Thanks,
>> > Justin
>> >
>> > 1.https://stackoverflow.com/legal/terms-of-service#licensing
>> > 2. http://www.tavfrna.incubator.apache.org/legal/resolved.html#cc-sa
>> > -
>> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> > For additional commands, e-mail: general-h...@incubator.apache.org
>> >
>> >
>>
>

Re: Podling use of StackOverflow

[Adrian Cole]

I think we should get legal clarity if folks disagree, but providing
content under CC license does not stop you from also licensing it under ASL.

IOTW, I can give an answer, license that answer simultaneously to two
parties.

Agree that we cant lift other people's content from SO based on its license
for inclusion in ASF works.

-A

On Sat, Apr 6, 2019, 6:09 AM Ted Dunning  wrote:

> Justin,
>
> THis is a huge and important point.
>
> I had completely forgotten that SO had these abusive terms.
>
> To summarize, just so everybody is clear, according to their terms of
> service *anything* you put on SO is the property of SO. That is sooo
> completely anti-Apache, that I have a hard time recommending their use at
> all.
>
>
> On Fri, Apr 5, 2019 at 2:17 PM Justin Mclean 
> wrote:
>
> > HI,
> >
> > You also might want to note that anything contributed to stack overflow
> is
> > licensed under the CC-SA-3.0 [1] which may causes issues. [2] For
> instance
> > code from a stack overflow post can’t be included in a Apache project's
> > code base. In edition also note "noncommercial use is expressly
> prohibited
> > without prior written permission from Stack Overflow or from the
> copyright
> > holder identified in the copyright notice per the Creative Commons
> License."
> >
> > Thanks,
> > Justin
> >
> > 1.https://stackoverflow.com/legal/terms-of-service#licensing
> > 2. http://www.tavfrna.incubator.apache.org/legal/resolved.html#cc-sa
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: [VOTE] Release Apache Zipkin Layout Factory (incubating) version 0.0.5

[Adrian Cole]

This one had 1 vote cast on the dev list: a +1 from Mick Semb Wever.

Cheers,
-Adrian

On Mon, Apr 29, 2019, 7:23 PM Justin Mclean 
wrote:

> Hi,
>
> Out of interest how many mentor / IPMC votes do get on the dev list?
>
> Thanks,
> Justin
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Release Apache Zipkin Layout Factory (incubating) version 0.0.5

[Adrian Cole]

Thanks for the tips, Sebastian. I made some notes below which are more
for our folks than you.

Best,
-A

> It would be better to link to the KEYS file at
>
> https://www.apache.org/dist/incubator/zipkin/KEYS
>
> as that is where downloaders will be directed once the release is published.
Good idea.. I will nudge RMs to add KEYS there and also use this in
the next release announcement.

> Also ideally there should be a comment before each key to say whose key it is.
> See for example:
>
> https://www.apache.org/dist/httpd/KEYS

Thanks, we were following dubbo's thing about keys, but it looks like
their website is out-of-date.
https://dubbo.incubator.apache.org/en-us/blog/prepare-an-apache-release.html

https://github.com/apache/incubator-dubbo-website/blob/fcf17e7543e7092ea5f23af9f4e2319b95dc/docs/en-us/developers/committer-guide/release-guide_dev.md
has the right commands, pasted for convenience to others

(gpg --list-sigs 'Adrian Cole' &&  gpg --armor --export 'Adrian Cole') >> KEYS

I corrected mine and will help others correct.

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

Re: [VOTE] Release Apache Zipkin (incubating) version 2.13.0

[Adrian Cole]

Also, to clarify Zipkin 2.13 is a bridge release. The code that is
readying for next week (2.14) changes functionality. We need this 2.13
code released regardless of what is in flight for next week to ensure
people move off our pre-ASF group IDs ASAP.

Best,
-A

On Wed, May 8, 2019 at 8:02 AM Adrian Cole  wrote:
>
> Thanks, Justin. there was a problem in our license header
> configuration that updated that vendored subdirectory. I will revert
> that part (and move the text in the wrong spot) in the next release
> which will be next week.
> https://github.com/apache/incubator-zipkin/issues/2567
>
> Please let us know if this release can take place as-is. It is a lot
> easier for us if we can as there has been a lot of movement on master
> since.
>
> Best,
> -A
>
> On Wed, May 8, 2019 at 6:03 AM Justin Mclean  wrote:
> >
> > Hi,
> >
> > I’ve not done a full check but noticed a couple of minor things:
> > - NOTICE file contains LICENSE information that should be in LICENSE
> > - LICENSE is missing licenses for [1][2]
> > - The files [1][2] and [3] also incorrectly have had ASF headers added, 
> > there might be others.
> >
> > Thanks,
> > Justin
> >
> > 1. ./zipkin-ui/libs/dagre-d3/js/dagre-d3.js
> > 2. ./zipkin-ui/libs/chosen/chosen.css
> > 3. ./zipkin-ui/libs/dagre-d3/js/dagre-d3.min.js
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >

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

Re: [VOTE] Release Apache Zipkin (incubating) version 2.13.0

[Adrian Cole]

Thanks, Justin. there was a problem in our license header
configuration that updated that vendored subdirectory. I will revert
that part (and move the text in the wrong spot) in the next release
which will be next week.
https://github.com/apache/incubator-zipkin/issues/2567

Please let us know if this release can take place as-is. It is a lot
easier for us if we can as there has been a lot of movement on master
since.

Best,
-A

On Wed, May 8, 2019 at 6:03 AM Justin Mclean  wrote:
>
> Hi,
>
> I’ve not done a full check but noticed a couple of minor things:
> - NOTICE file contains LICENSE information that should be in LICENSE
> - LICENSE is missing licenses for [1][2]
> - The files [1][2] and [3] also incorrectly have had ASF headers added, there 
> might be others.
>
> Thanks,
> Justin
>
> 1. ./zipkin-ui/libs/dagre-d3/js/dagre-d3.js
> 2. ./zipkin-ui/libs/chosen/chosen.css
> 3. ./zipkin-ui/libs/dagre-d3/js/dagre-d3.min.js
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

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

Re: [VOTE] Release Apache Zipkin (incubating) version 2.13.0

[Adrian Cole]

FYI there was another binding +1 vote on the other thread from Ignasi Barrera

https://lists.apache.org/thread.html/fcc730ad01eb55293f7a174a3b5301f4a277b6222c7bb821d33faf2e@%3Cdev.zipkin.apache.org%3E

On 2019/05/07 14:25:42, Raja Sundaram Ganesan  wrote: 
> Hello IPMC
> The Apache Zipkin community has voted on and approved a proposal to release
> Apache Zipkin API (incubating) version 0.2.1. The voting thread can be
> found here:
> 
> https://lists.apache.org/thread.html/9d4bbf52bd93a3907737b6cf445b5465607b7dd260a4bdc2a519e6ab@%3Cdev.zipkin.apache.org%3E
> 
> Two binding +1 vote from mentors Willem Ning Jiang and Andriy Redko carry
> over from the dev list thread.
> 
> We now kindly request the Incubator PMC members review and vote on this
> incubator release.
> 
> Apache Zipkin (incubating) is the main repository Zipkin Server which
> includes Collectors, UI, Storage implementation.
> 
> The release candidates:
> https://dist.apache.org/repos/dist/dev/incubator/zipkin/zipkin/2.13.0/
> 
> Git tag for the release:
> https://github.com/apache/incubator-zipkin/tree/v2.13.0
> 
> Hash for the release tag:
> 
> 7c08091d3f8b0428d1d78839d3bef0f6887746f2
> 
> Release Notes:
> https://github.com/apache/incubator-zipkin/releases/tag/v2.13.0
> 
> The artifacts have been signed with Key: DA805D02, which can be found
> in the keys file:
> https://dist.apache.org/repos/dist/release/incubator/zipkin/KEYS
> 
> Verification Hints:
> For your convenience, the below includes a detailed how-to on verifying
> a source release. Please note that this document is a work-in-progress
> 
> https://cwiki.apache.org/confluence/display/ZIPKIN/Verifying+a+Source+
> Release
> 
> The vote will be open for at least 72 hours or until the necessary number
> of votes are reached.
> 
> Please vote accordingly:
> 
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
> 
> Thanks,
> The Apache Zipkin (Incubating) Team
> 
> -
> 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

request: please keep feedback categorized to what's being voted on

[Adrian Cole]

Hi, all.

During a release vote, it can be tempting to tack on feedback about
things not being voted on, but pertain to the eventual graduation of a
project. For example, some glitch about content on a website. In
projects with only one or few codebases, it can maybe make sense to
conflate things related to a vote of one thing with anything about the
project. However, I would expect that projects with a dozen
repositories, that it would be easier to respond in votes only about
things that pertain to what is being voted on.

If there are other things to mention, for example, rosters, web sites
etc, or any other random feedback, please give that. However, I would
ask to please start a new thread sent to the dev@ list if the change
request would not affect the source being voted on.

I would go so far as saying this is just how issues typically work.
For example, ideally an issue is created on the project it relates to,
and comments on an issue should relate to the issue under discussion.
If you think of a release vote as an issue to close, it is possibly
easier to grok why it can make sense and be easier to classify content
like this.

 Yes, it is inconvenient for the IPMC member to start a new email
thread vs tack onto the vote response, but I don't think that is much
to ask. The result is less stress for the project team. In a project
like Zipkin, we have a huge amount of things to do as we have like ten
repos to work on. This leads to a higher level of load and stress,
something we desperately desire.

My 2p.
-A

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

[VOTE] Release Apache Zipkin (incubating) version 2.14.0

[Adrian Cole]

Hello IPMC

The Apache Zipkin community has voted on and approved a proposal to release
Apache Zipkin (incubating) version 2.14.0. The voting thread can be found here:

https://lists.apache.org/thread.html/03b215cc4a6e10a7092fe39b6ce87d3a964f35b6e181e12da4d45432@%3Cdev.zipkin.apache.org%3E

This vote is running concurrent with the above, carrying over 3
binding +1 votes from mentors Willem Ning Jiang, Sheng Wu and Andriy
Redko.

We now kindly request the Incubator PMC members review and vote on this
incubator release.

Apache Zipkin (incubating) is a distributed tracing system. It helps
gather timing data needed to troubleshoot latency problems in
microservice architectures. It manages both the collection and lookup
of this data. Zipkin’s design is based on the Google Dapper paper.

This source includes a dependency-free library and a spring-boot
server. Storage options include in-memory, JDBC (mysql), Cassandra,
and Elasticsearch.

The release candidates:
https://dist.apache.org/repos/dist/dev/incubator/zipkin/zipkin/2.14.0/

Git tag for the release:
https://github.com/apache/incubator-zipkin/tree/v2.14.0

Hash for the release tag: 9c2fa2697cdbbd6a3eeb9f87ae6a6ccba2f3c881

Release Notes:
https://github.com/apache/incubator-zipkin/releases/tag/v2.14.0

The artifacts have been signed with Key: BB67A050, which can be found in
the keys file:
https://www.apache.org/dist/incubator/zipkin/KEYS

Verification Hints:
For your convenience, the below includes a detailed how-to on verifying
a source release. Please note that this document is a work-in-progress

https://cwiki.apache.org/confluence/display/ZIPKIN/Verifying+a+Source+
Release

The vote will be open for at least 72 hours or until the necessary number
of votes are reached.

Please vote accordingly:

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason

Note:

   1. Zipkin-UI contains vendored libraries which will be removed during the
   incubation
   2. A more complete list of issues requiring attention before
graduation is here
https://github.com/apache/incubator-zipkin/issues/2544

Thanks,
The Apache Zipkin (Incubating) Team

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

Re: [VOTE] Release Apache Zipkin (incubating) version 2.14.0

[Adrian Cole]

Thanks justin. Opened an issue to polish this eventhough these files
won't survive graduation.
https://github.com/apache/incubator-zipkin/issues/2602

On Fri, May 17, 2019 at 10:04 AM Justin Mclean  wrote:
>
> Hi,
>
> +1 (binding) but there some improvements that can be made.
>
> I checked:
> - incubating in name
> - signatures and hashes good
> - LICENSE needs a little more work and is missing LICENSE for [2].
> - NOTICE is incorrect as it missing information from this NOTICE [4]
> - no unexpected binary files
> - source file have ASF header. In fact a couple too many [1] has an ASF 
> header and two others and this file as well [2]
> - can compile from source
>
> To ensure you are abiding by 3rd party license terms the full license text 
> generally needs be included (e.g. MIT, BSD). Usually this is done by pointing 
> a pointer to a file in the distribution in the LICENSE file (not a URL). Some 
> projects put all of these licenses into a license directory. You might want 
> to consider doing that.
>
> Thanks,
> Justin
>
> 1. ./zipkin-2.13.0/zipkin-ui/libs/dagre-d3/js/dagre-d3.js
> 2. 
> ./zipkin-2.14.0/zipkin-server/src/main/java/zipkin2/server/internal/AbstractUnsafeUnaryGrpcService.java
> 3. ./zipkin-ui/libs/chosen/chosen.css
> 4. https://github.com/line/armeria/blob/master/NOTICE.txt
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

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

Re: [DISCUSS] Mentors SHOULD vote on podling releases prior to asking IPMC to vote

[Adrian Cole]

FWIW I tried this just recently and was requested to not do it again. Worth 
knowing 
https://lists.apache.org/thread.html/0571e9dd1b7711c588a38d8a664378ce7df31c72592edcbe8ab8a72b@%3Cgeneral.incubator.apache.org%3E

On 2019/04/02 09:30:10, Geertjan Wielenga 
 wrote: 
> Maybe the PPMC and IPMC vote could run in parallel -- a key reason why we
> in Apache NetBeans are looking forward to graduation is that we'll not need
> to go through the loop of (1) PPMC approves, (2) IPMC rejects, (3) PPMC
> needs to put together a new release and vote on it again, (4) IPMC rejects
> again (finding something else they hadn't found before), etc. That's slowed
> the releases we have done in the incubator down significantly, typically by
> at least 2 weeks -- of course, as will be pointed out, Apache NetBeans is
> very large -- but, assuming Apache wants to be a welcome place for large
> projects too, something needs to be done here (though it won't be a problem
> for Apache NetBeans anymore since we plan to graduate before our next
> release). So, if the votes were to at least run in parallel, that would
> save time, and maybe as soon as there are 3 +1s from PPMC/IPMC members,
> that should be good to go, rather than waiting another 72 hours after that,
> in situations where those votes come in quickly.
> 
> Gj
> 
> On Tue, Apr 2, 2019 at 11:09 AM Julian Feinauer <
> j.feina...@pragmaticminds.de> wrote:
> 
> > Hi,
> >
> > I like Craigs suggestion and I'm aware of the problem with the ASF Policy
> > if we would skip the formal IPMC Vote.
> > On the other hand in PLC4X we had a discussion about a regular release
> > cycle to bring new features to the users as fast as possible and decided to
> > skip that for now, to keep the burden on the IPMC low (and we usually have
> > 3 IPMC / Mentor Votes as we have very active Mentors).
> > I agree with this decision of the PPMC but I see a problem with that, as
> > the IPMC Vote should be something to help podlings (aside from the
> > necessity by Policy) but not "negatively" impact them.
> >
> > Perhaps it helps to see the IPMC Votes more as a "take notice" in case
> > that there are already 3 +1 Votes. This means that the vote is open for
> > 72hrs formally, but IPMC members do not feel to have to go to action
> > (usually as PMC member one "should" participate in votes... although this
> > is practiced differently in the IPMC for good reasons) but CAN if they feel
> > like.
> > This would especially mean that podlings should be encouraged to formulate
> > their votes more explicit about whether there are already enough IPMC Votes
> > or not.
> >
> > Julian
> >
> >
> > Am 01.04.19, 23:51 schrieb "Justin Mclean" :
> >
> > Hi,
> >
> > I'd also like to see those mentors / IPMC members vote with more than
> > just a +1 and provide a list of what they checked. If they could use
> > something like this all the better [1].
> >
> > I wouldn’t be for removing the second step of letting the IPMC look at
> > it, reasonably often serious issues are found in that step. By skilling
> > that we risk some podlings going all the way to propose graduation while
> > having releases that don’t follow ASF policy. This is a situation I’d like
> > to avoid.
> >
> > Thanks,
> > Justin
> >
> > 1. https://wiki.apache.org/incubator/IncubatorReleaseChecklist
> > -
> > 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
> >
> 

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

Re: [DISCUSS] Mentors SHOULD vote on podling releases prior to asking IPMC to vote

[Adrian Cole]

I informed our mentors.

On Sat, May 18, 2019, 2:03 AM Justin Mclean 
wrote:

> HI,
>
> Or better still if you want to try something new / not in line with policy
> at least discuss it with the IPMC first and give them a heads up that you
> are doing so.
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Mentors SHOULD vote on podling releases prior to asking IPMC to vote

[Adrian Cole]

and I also said in the announcement that this was a concurrent vote.

On Sat, May 18, 2019, 7:55 AM Adrian Cole  wrote:

> I informed our mentors.
>
> On Sat, May 18, 2019, 2:03 AM Justin Mclean 
> wrote:
>
>> HI,
>>
>> Or better still if you want to try something new / not in line with
>> policy at least discuss it with the IPMC first and give them a heads up
>> that you are doing so.
>>
>> Thanks,
>> Justin
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>

Re: [DISCUSS] Mentors SHOULD vote on podling releases prior to asking IPMC to vote

[Adrian Cole]

> Can you point me to where the PPMC has a discussion about this?

I nagged our mentors privately to vote and mentioned that I would be
trying a concurrent vote.

Everyone in our PPMC is aware of the vote delay problem and this
thread. We have had numerous discussions about this topic since
incubation.

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

Re: [VOTE] Release Apache Zipkin (incubating) version 2.14.0

[Adrian Cole]

maybe you can open source the tools you use justin.

you seem uncanny ability to find glitches, yet also have an ability to
ignore note in the vote request mentioning known issues.

start helping instead of finding faults. you are the reason incubator is
not something anyone wants to go through

On Sat, May 18, 2019, 3:20 PM Justin Mclean 
wrote:

> Hi,
>
> > But for Zipkin,  there are lots of community releases which are built
> > on top of auto tools,  so I think it's much safer for us to start a
> > parallel vote both PPMC and IPMC.
>
> Given all release I’ve looked at had license (or other) issues why do you
> think that the “auto tools” are doing what is required and that there is a
> requirement for doing this? Or why do you feel you need to get releases out
> before they comply with ASF policy? You'll allow note that issues pointed
> out with previous releases still occur in later releases and that’s
> probably an issue you need to look into.
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Release Apache Zipkin (incubating) version 2.14.0

[Adrian Cole]

the fact people allow tools like apache RAT to rot, yet somehow can
find glitches in dozens of repos tells me priorities are whacked.

For example, the last release justin found a second header on a file
that said it was temporary (now deleted)

did he manually look at hundreds of files to see that? If not, why are
the tools we are supposed to use hamstrung? A correct optimization is
empowering projects to succeed on their own. RAT is a part of that.
Why are there better tools not available? Why is a second license a
"ISSUE" that needs to be discussed in consideration of whether a vote
is 3+1 days or 3+3 days. The bias is towards making things problems,
not putting them in perspective or addressing long held issues that
make this whole thing eggshell (ex RAT)

On Sat, May 18, 2019 at 5:33 PM Geertjan Wielenga  wrote:
>
> In defence of Justin :-) I'm very sure NetBeans would not be as solid and
> well placed in Apache right now, outside the Incubator, without Justin's
> uncanny ability to find glitches. :-)
>
> Gj
>
> On Sat, May 18, 2019 at 4:59 PM Adrian Cole  wrote:
>
> > maybe you can open source the tools you use justin.
> >
> > you seem uncanny ability to find glitches, yet also have an ability to
> > ignore note in the vote request mentioning known issues.
> >
> > start helping instead of finding faults. you are the reason incubator is
> > not something anyone wants to go through
> >
> > On Sat, May 18, 2019, 3:20 PM Justin Mclean 
> > wrote:
> >
> > > Hi,
> > >
> > > > But for Zipkin,  there are lots of community releases which are built
> > > > on top of auto tools,  so I think it's much safer for us to start a
> > > > parallel vote both PPMC and IPMC.
> > >
> > > Given all release I’ve looked at had license (or other) issues why do you
> > > think that the “auto tools” are doing what is required and that there is
> > a
> > > requirement for doing this? Or why do you feel you need to get releases
> > out
> > > before they comply with ASF policy? You'll allow note that issues pointed
> > > out with previous releases still occur in later releases and that’s
> > > probably an issue you need to look into.
> > >
> > > Thanks,
> > > Justin
> > > -
> > > 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

[RESULT][VOTE] Release Apache Zipkin (incubating) version 2.14.0

[Adrian Cole]

Thanks to everyone that participated. The vote to release Release
Apache Zipkin (incubating) version 2.14.0 is now closed. It PASSED
with 5 (+1 binding) votes and no 0 or -1 votes:

+1 Willem Ning Jiang (binding)
+1 Sheng Wu (binding)
+1 Andriy Redko (binding)
+1 Michael Semb Wever (binding)
+1 Justin Mclean (binding)

Vote thread: 
https://lists.apache.org/thread.html/0b52a3437370937c98724f5478002fe65b68717f30387595be4cd18e@%3Cgeneral.incubator.apache.org%3E

We will work to complete the release process.

Thanks,

The Apache Zipkin (Incubating) Team

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

[ANNOUNCE] Apache Zipkin (Incubating) version 2.14.0 Released

[Adrian Cole]

Hello Community,

The Apache Zipkin (incubating) team is pleased to announce that Zipkin
2.14.0 has just been released.

Apache Zipkin (incubating) is a distributed tracing system. It helps
gather timing data needed to troubleshoot latency problems in
microservice architectures. It manages both the collection and lookup
of this data.

The official source release[1] and convenience binaries for the server
[2] and core libraries [3] are available now. You can also find the
detailed release notes in here[4].

If you have any usage questions, or have problems when upgrading or
find any problems about enhancements included in this release, please
don’t hesitate to let us know by sending feedback to this mailing
list.

=
*Disclaimer*

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


[1] https://www.apache.org/dyn/closer.lua/incubator/zipkin/zipkin/2.14.0
[2] https://search.maven.org/search?q=g:org.apache.zipkin%20AND%20v:2.14.0
[3] 
https://search.maven.org/search?q=g:org.apache.zipkin.zipkin2%20AND%20v:2.14.0
[4] https://github.com/apache/incubator-zipkin/releases/tag/v2.14.0

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

Is the DEPENDENCIES file a requirement or a nice-to-have?

[Adrian Cole]

Hi, all.

We tripped on some bugs related to maven projects generating the file
DEPENDENCIES which includes information about runtime dependencies. We
marked this as a graduation blocker assuming that is required.

Later, we noticed a certain lack of clarity on how to handle this for
javascript.. Then, looking further, it seems the file DEPENDENCIES is
actually not a requirement of ASF or to graduate from the incubator..
If it were, it seems it would be here
http://www.apache.org/dev/licensing-howto.html right?

Can someone clarify if packaging a file named DEPENDENCIES is required
or a nice-to-have? If we are required to, is the format defined
anywhere? or are we to copy the formatting generated from maven during
the apache-release profile?

Thanks,
-Adrian (on behalf of the Zipkin podling)

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

Re: Is the DEPENDENCIES file a requirement or a nice-to-have?

[Adrian Cole]

Thanks, Justin. Crystal clear!

On Sun, Jun 2, 2019 at 3:58 PM Justin Mclean  wrote:
>
> Hi,
>
> > Can someone clarify if packaging a file named DEPENDENCIES is required
> > or a nice-to-have?
>
> It’s a nice to have. You’re releases do need to have no Category X licence 
> (e.g. GPL) dependancies.
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

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

Re: Podling releases and release policy

[Adrian Cole]

wouldnt it be fair to keep the incubator benefit adjectives away from words
like reliable and production ready?

If I am not mistaken, almost all of the efforts are around ceremony around
the code, not whether it works. In fact the slowing of the community hurts
production ness as it is far slower to fix actual bugs in a way people can
consume those fixes.

It is fair to say incubator helps with process, community, provenance and
many other things. however, I dont think it is relevant or even correct to
say it helps make the code more reliable in an operations way.

On Tue, Jun 4, 2019, 8:54 AM Craig Russell  wrote:

>
>
> > On Jun 3, 2019, at 5:40 PM, Greg Stein  wrote:
> >
> > On Mon, Jun 3, 2019 at 7:24 PM Craig Russell 
> wrote:
> >
> >>> On Jun 3, 2019, at 2:33 PM, Justin Mclean 
> >> wrote:
> >>
> >> ...
> >
> >>> I agree, but if you read the disclaimer is says nothing about releases,
> >> perhaps that needs to change?
> >>
> >> Yes, I'd like to change the disclaimer to state that releases cannot be
> >> considered completely reliable, should not be depended on for
> production,
> >
> >
> > I believe the above two phrases would be unfair to mature projects. In
> > fact, to 95% of all the projects that arrive in the Incubator. The
> projects
> > *are* reliable and *are* used in production.
>
> Mature projects arrive here and go into incubation. I'd like to see
> production cases use the existing mature project distributions and use the
> incubator releases as test subjects. YMMV.
> >
> > The only difference is they are learning how to become an Apache-style
> > community. The software doesn't magically "degrade".
>
> Once the community makes changes to the "mature" software they have in
> production, it not-magically does "degrade".
>
> Maybe you and I have different standards for production. Take a mature
> project, add a few hundred lines of code, and it's no longer the mature
> project you are using in production.
>
> Regards,
> Craig
> >
> >
> >> might not have passed all normal Apache reviews, etc.
> >>
> >
> > Concur.
> >
> >
> >> I am of the opinion that the board should not need to be involved in
> >> telling the incubator what particular release deficiencies can stop
> >> releases. The incubator can certainly ask the board for advice on
> proposed
> >> change to policy.
> >>
> >
> > Concur.
> >
> > Cheers,
> > -g
>
> Craig L Russell
> c...@apache.org
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Podling releases and release policy

[Adrian Cole]

> > As others have mentioned, such release bugs would be labelled as blocking
> > for graduation. Ideally the bug ticket numbers would be listed in a
> > disclaimer file within the release.
>
> Interesting idea, that list would need to be kept up to date in there. It 
> might be easier to just tag the issues with a “blocking-graduation” tag? Of 
> course each PPMC could come up with their own may of doing thi as long as it 
> easy for reviewers to check.

FWIW as we have 10 repos, but no central issue repository specific to
ASF graduation tracking, Zipkin decided to make one issue with tick
boxes. We've added this issue to the bottom of vote requests in
attempts to reduce effort mutually around known and/or in progress
things

https://github.com/apache/incubator-zipkin/issues/2544

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

late learnings, which could be helpful for all mentors to know

[Adrian Cole]

Hi, all.

Through Zipkin's incubation, I noticed that knowledge of state of the
art is not equally distributed. Some voting approaches already in use
aren't known. Also what you can use to automate isn't known. As
podlings don't always know the right questions to ask, it might be
beneficial for future podlings if some advice about state of the art
was taught instead. This is especially important as many projects will
likely want to import multiple repos. I will inventory some.

* "parallel votes" is a technique to reduce the lag between dev@ and
general@ by starting the IPMC vote slightly after, but before
conclusion of the PPMC one. This may have only been tried once (in
Zipkin) and met resistance.
* "bundled votes" is a technique where multiple repos are sent in a
single vote. This is much more efficient for coupled repos than
pipelining. OpenWhisk uses this and don't appear to have met
resistance.
* not all repos need to actually release prior to graduation. Both
Dubbo and OpenWhisk had unreleased repos when they called for
graduation (OpenWhisk has dozens). It isn't intuitive for projects to
know they don't have to release every repo, so they should be told
this.
* Jenkins is most ASF, but Travis is ok, but CircleCI is not, and
maybe Appveyor is ok.  All we know now, is that CircleCI is not ok,
which is personally fine, but basically people should be able to know
what CI tools are allowed to be used.
* You are allowed to automate release process, even with Travis. It
can be confusing to know what you are allowed to automate, and whether
it must be done with ASF infra etc. The most elaborate example is
https://github.com/apache/incubator-openwhisk-release
* ASF tools like RAT and the release plugin are barely maintained in
comparison with Incubator policy. It is unintuitive that tools
projects use to audit themselves don't evolve lock-step with general
software, policy and discussion. This feels bad whenever told, but
earlier is better.

Anyway, figured I would send off these notes so that folks entering
the incubator don't end up with a lot of unnecessary grief, irritation
due to ignorance about state of the art, or the disparity between
project-specific ASF tools and general ASF tools.

-A

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

Re: late learnings, which could be helpful for all mentors to know

[Adrian Cole]

> If the mentors on the project list have voted +1, then the vote can be 
> continued in parallel? Shouldn't this help reduce both the time votes take 
> but not waste the limited IPMC bandwidth?

That's exactly what we tried and were given grief about. We waited
until 3 binding +1 votes, which is for practical purposes all of our
active mentors

https://lists.apache.org/thread.html/0b52a3437370937c98724f5478002fe65b68717f30387595be4cd18e@%3Cgeneral.incubator.apache.org%3E

I think the 100% perfect release standard is debated on other topics,
and seems to be a split where many say you have to fix things by
graduation, and others think you have to fix all things by next
release. The 100% goal is really counterproductive and causes a lot of
unnecessary stress, and frankly anger. This toxic situation of not
being able to succeed because rules aren't knowable, yet expected as
100% makes it hard to be friendly and nice.

> Instead of having to actually DO releases, at least Release Candidates should 
> be created ... this would prove the general ability to do a release, but not 
> actually DO it. Of course if these RCs contain bad things, they should not 
> pass.

I suspect in some cases there are repos that maybe never have a
release. In zipkin we felt like we had to do all work and it was a bad
taste to see all this high friction efforts then projects go for
graduation with dozens of repos.. probably some not even looked at.
Whatever it is, I think it should become fair at some point.

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

There's a missing state in the state diagram for the incubator

[Adrian Cole]

Hi, all

I just noticed that all states in the diagram are under the assumption
that the only way a project stops is by the IPMC making a decision for
the project, saying they have no community etc.

https://incubator.apache.org/policy/process.html#termination_or_retirement

A route not listed is the PPMC choosing to stop on their own. It would
be helpful to know that a podling can voluntarily return to their
prior state, and know up front what impact that would imply.

I expect not everything needs to be on the website, but hypothetically
speaking, what would be the impact to the people who decided to stop
incubating.. if for example the community is entirely the same as they
started?

Best,
-Adrian

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

Re: Move the Zipkin repos back, as the community has voted to leave.

[Adrian Cole]

as there was little progress inside incubator, the far easiest on
everyone is to resume our old "io.zipkin" group ids. We have no plans
to use any apache namespaces as it represents one release of several
out of many projects. Least surprising and distracting is a
straightforward revert.

-A

On Mon, Jun 17, 2019 at 5:57 PM Christofer Dutz
 wrote:
>
> But if you are releasing Maven artifacts, I would assume that you change the 
> group-ids to not start with "org.apache"
> and the packages should probably be changed too. But not 100% sure if this is 
> just a nice-to-have or a hard requirement.
> And also I didn't check the coordinates or package structure of the repo ... 
> so just ignore me, if this all doesn't apply ;-)
>
> Chris
>
>
>
> Am 17.06.19, 11:52 schrieb "Sheng Wu" :
>
> Hi Incubator.
>
> As a Zipkin incubator mentor, I am asking to make Zipkin all repositories 
> back to original OpenZipkin org as soon as possible.
>
> They have done a public ml vote, result is here[1].
> Also, with no transfer happened about Zipkin trademark, logo, domain, so, 
> there is no such thing about return the trademark or permission of using 
> Zipkin name.
>
> Zipkin is a big community and a lots of dependency out there are waiting 
> for release.
>
> I think there is nothing hold this transfer, right?
> If so, please give a clear reply. The INFRA team is waiting at this JIRA 
> ticket[2].
>
>
> [1] 
> https://lists.apache.org/thread.html/fbeb254f569d9852e9740d55532ee338580287ec384e26c7d9107964@%3Cdev.zipkin.apache.org%3E
>  
> 
> [2] https://issues.apache.org/jira/browse/INFRA-18604 
> 
>
>
> Sheng Wu
> Apache Skywalking, ShardingSphere, Zipkin
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org

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

Re: Move the Zipkin repos back, as the community has voted to leave.

[Adrian Cole]

on the maven topic:

for almost all cases there will be no classpath problem. the most common
entry point into maven was the package for "brave" which was never released
under an apache group id. the underlying libraries had very few call sites
in comparison. the "bom" most commonly used was also never released.

the server itself was explicitly marked as not supported as a library, so
there is not much impact to group ids there. many didn't upgrade to the ASF
build according to support chatter. like most projects, getting folks to
upgrade is a task in itself.

main thing, we will take this liability of group ids on as a community in
other words, and it is less a problem than being unable to control our
repositories which is the current dilemma. you dont need to worry about
this.

On Tue, Jun 18, 2019, 4:13 AM sebb  wrote:

> I agree it's not a block, but there is scope for some classpath confusion.
>
> If someone has an app that includes both the ASF and non-ASF Zipkin
> jars, both will end up on the Maven classpath.
> There is no way to tell which version of a particular class will end
> up being loaded.
>
> A Maven relocation pom might help to ensure that only one version of
> the jars ends up on the Maven classpath, but I've not tried that.
>
> The recommended procedure is to always ensure that there is a 1:1
> relationship between Maven coords and Java package name.
> There can then be no chance of incompatible jars on the classpath.
>
> On Mon, 17 Jun 2019 at 14:17, Sheng Wu  wrote:
> >
> > Hi
> > Zipkin doesn’t change the java package name, and had no plan to do that.
> > We just changed the groupid, and are reverting it back to `io.zipkin`.
> >
> > So, I don’t see this as a block.
> >
> > Sheng Wu
> > Apache Skywalking, ShardingSphere, Zipkin
> >
> >
> >
> > > 在 2019年6月17日，下午5:57，Christofer Dutz  写道：
> > >
> > > But if you are releasing Maven artifacts, I would assume that you
> change the group-ids to not start with "org.apache"
> > > and the packages should probably be changed too. But not 100% sure if
> this is just a nice-to-have or a hard requirement.
> > > And also I didn't check the coordinates or package structure of the
> repo ... so just ignore me, if this all doesn't apply ;-)
> > >
> > > Chris
> > >
> > >
> > >
> > > Am 17.06.19, 11:52 schrieb "Sheng Wu" :
> > >
> > >Hi Incubator.
> > >
> > >As a Zipkin incubator mentor, I am asking to make Zipkin all
> repositories back to original OpenZipkin org as soon as possible.
> > >
> > >They have done a public ml vote, result is here[1].
> > >Also, with no transfer happened about Zipkin trademark, logo,
> domain, so, there is no such thing about return the trademark or permission
> of using Zipkin name.
> > >
> > >Zipkin is a big community and a lots of dependency out there are
> waiting for release.
> > >
> > >I think there is nothing hold this transfer, right?
> > >If so, please give a clear reply. The INFRA team is waiting at this
> JIRA ticket[2].
> > >
> > >
> > >[1]
> https://lists.apache.org/thread.html/fbeb254f569d9852e9740d55532ee338580287ec384e26c7d9107964@%3Cdev.zipkin.apache.org%3E
> <
> https://lists.apache.org/thread.html/fbeb254f569d9852e9740d55532ee338580287ec384e26c7d9107964@%3Cdev.zipkin.apache.org%3E
> >
> > >[2] https://issues.apache.org/jira/browse/INFRA-18604 <
> https://issues.apache.org/jira/browse/INFRA-18604>
> > >
> > >
> > >Sheng Wu
> > >Apache Skywalking, ShardingSphere, Zipkin
> > >
> > >
> > >
> > >
> > >
> > >
> > > -
> > > 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
> >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Maven coordinates (was: Move the Zipkin repos back, as the community has voted to leave.)

[Adrian Cole]

if you would like to do, this feel free. this type of concern seems more
like a github issue vs an incubator discussion. we have changed group ids
in the past prior to Apache without complaints.

again the most important project from a dependency pinning pov, brave, was
never released. knowing the community as I do I would rate the other
packages released as a super high priority concern these are low level or
niche libraries. it would have been a problem if we released brave but we
didn't luckily.

On Tue, Jun 18, 2019, 5:33 PM sebb  wrote:

> On Tue, 18 Jun 2019 at 00:40, Adrian Cole  wrote:
> >
> > on the maven topic:
> >
> > for almost all cases there will be no classpath problem. the most common
> > entry point into maven was the package for "brave" which was never
> released
> > under an apache group id. the underlying libraries had very few call
> sites
> > in comparison. the "bom" most commonly used was also never released.
>
> There appear to be at least 7 Maven packages under org.apache.zipkin.
> These have been released, and cannot be changed.
>
> I don't know if any of them have been used by 3rd parties, but if they
> have:
>
> If any of them use the same Java package name as io.zipkin Maven
> packages, then there is a chance that two jars with the same class
> names but different API and behaviour will end up on the classpath.
> This can cause failures that can be hard to debug.
>
> > the server itself was explicitly marked as not supported as a library, so
> > there is not much impact to group ids there. many didn't upgrade to the
> ASF
> > build according to support chatter. like most projects, getting folks to
> > upgrade is a task in itself.
> >
> > main thing, we will take this liability of group ids on as a community in
> > other words, and it is less a problem than being unable to control our
> > repositories which is the current dilemma. you dont need to worry about
> > this.
>
> This is not about who controls the entries in Maven Central.
> It is about ensuring that Maven knows which jars can safely co-exist
> on the classpath.
>
> It may help the project to set up a relocation POM.
> AIUI this may help Maven to know that org.apache.zipkin is now
> io.zipkin, and thus hopefully prevent both appearing on the same
> classpath.
>
> > On Tue, Jun 18, 2019, 4:13 AM sebb  wrote:
> >
> > > I agree it's not a block, but there is scope for some classpath
> confusion.
> > >
> > > If someone has an app that includes both the ASF and non-ASF Zipkin
> > > jars, both will end up on the Maven classpath.
> > > There is no way to tell which version of a particular class will end
> > > up being loaded.
> > >
> > > A Maven relocation pom might help to ensure that only one version of
> > > the jars ends up on the Maven classpath, but I've not tried that.
> > >
> > > The recommended procedure is to always ensure that there is a 1:1
> > > relationship between Maven coords and Java package name.
> > > There can then be no chance of incompatible jars on the classpath.
> > >
> > > On Mon, 17 Jun 2019 at 14:17, Sheng Wu 
> wrote:
> > > >
> > > > Hi
> > > > Zipkin doesn’t change the java package name, and had no plan to do
> that.
> > > > We just changed the groupid, and are reverting it back to
> `io.zipkin`.
> > > >
> > > > So, I don’t see this as a block.
> > > >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Maven coordinates (was: Move the Zipkin repos back, as the community has voted to leave.)

[Adrian Cole]

of course I meant "packages released as a *not* super high priority concern"

On Tue, Jun 18, 2019, 5:37 PM Adrian Cole  wrote:

> if you would like to do, this feel free. this type of concern seems more
> like a github issue vs an incubator discussion. we have changed group ids
> in the past prior to Apache without complaints.
>
> again the most important project from a dependency pinning pov, brave, was
> never released. knowing the community as I do I would rate the other
> packages released as a super high priority concern these are low level or
> niche libraries. it would have been a problem if we released brave but we
> didn't luckily.
>
> On Tue, Jun 18, 2019, 5:33 PM sebb  wrote:
>
>> On Tue, 18 Jun 2019 at 00:40, Adrian Cole 
>> wrote:
>> >
>> > on the maven topic:
>> >
>> > for almost all cases there will be no classpath problem. the most common
>> > entry point into maven was the package for "brave" which was never
>> released
>> > under an apache group id. the underlying libraries had very few call
>> sites
>> > in comparison. the "bom" most commonly used was also never released.
>>
>> There appear to be at least 7 Maven packages under org.apache.zipkin.
>> These have been released, and cannot be changed.
>>
>> I don't know if any of them have been used by 3rd parties, but if they
>> have:
>>
>> If any of them use the same Java package name as io.zipkin Maven
>> packages, then there is a chance that two jars with the same class
>> names but different API and behaviour will end up on the classpath.
>> This can cause failures that can be hard to debug.
>>
>> > the server itself was explicitly marked as not supported as a library,
>> so
>> > there is not much impact to group ids there. many didn't upgrade to the
>> ASF
>> > build according to support chatter. like most projects, getting folks to
>> > upgrade is a task in itself.
>> >
>> > main thing, we will take this liability of group ids on as a community
>> in
>> > other words, and it is less a problem than being unable to control our
>> > repositories which is the current dilemma. you dont need to worry about
>> > this.
>>
>> This is not about who controls the entries in Maven Central.
>> It is about ensuring that Maven knows which jars can safely co-exist
>> on the classpath.
>>
>> It may help the project to set up a relocation POM.
>> AIUI this may help Maven to know that org.apache.zipkin is now
>> io.zipkin, and thus hopefully prevent both appearing on the same
>> classpath.
>>
>> > On Tue, Jun 18, 2019, 4:13 AM sebb  wrote:
>> >
>> > > I agree it's not a block, but there is scope for some classpath
>> confusion.
>> > >
>> > > If someone has an app that includes both the ASF and non-ASF Zipkin
>> > > jars, both will end up on the Maven classpath.
>> > > There is no way to tell which version of a particular class will end
>> > > up being loaded.
>> > >
>> > > A Maven relocation pom might help to ensure that only one version of
>> > > the jars ends up on the Maven classpath, but I've not tried that.
>> > >
>> > > The recommended procedure is to always ensure that there is a 1:1
>> > > relationship between Maven coords and Java package name.
>> > > There can then be no chance of incompatible jars on the classpath.
>> > >
>> > > On Mon, 17 Jun 2019 at 14:17, Sheng Wu 
>> wrote:
>> > > >
>> > > > Hi
>> > > > Zipkin doesn’t change the java package name, and had no plan to do
>> that.
>> > > > We just changed the groupid, and are reverting it back to
>> `io.zipkin`.
>> > > >
>> > > > So, I don’t see this as a block.
>> > > >
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>