Re: Incubation Pain Points

[Ted Dunning]

Willem,

There are already tools to help address the most common issues. The common
issues that can't currently be addressed involve human language which is
hard to figure out automatically.

Assuming that these tools can be improved (and they definitely can) who
would you propose do the extending? Remember, nobody is paid to do that.

On Tue, Jun 18, 2019 at 6:27 PM Willem Jiang  wrote:

> ...
> I know it is harder to provide an unify tool which could be useful for
> all kind of project, but it could address most of common issues if
> IPMC can build the tools together by sharing our experiences.
>
>

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

[Romain Manni-Bucau]

+1

Le mer. 19 juin 2019 à 02:42, Dave Fisher  a écrit :

> Hi David and Greg,
>
> > On Jun 18, 2019, at 5:39 PM, Justin Mclean 
> wrote:
> >
> > HI,
> >
> > +1 (binding)
> >
> > I hope the podling has better success outside the ASF.
> >
> > BTW in all previous cases of podlings exiting I could find, a vote was
> taken (see below links and there’s more I’ve not listed). In most cases
> this was to retire rather than returning/going elsewhere, so the situation
> not exactly the same, but that’s a data point all the same.
>
> If anyone thinks a VOTE is not necessary then please discuss why on
> another thread.
>
> Regards,
> Dave
>
> >
> > Thanks
> > Justin
> >
> > 1.
> https://lists.apache.org/thread.html/6afe3024bdbaf6e484ff376be0919ad6e6935b1688b08e7f8710542a@%3Cgeneral.incubator.apache.org%3E
> > 2.
> https://lists.apache.org/thread.html/c386b985379c8b6b54d791c8eaa62e429987ffb651ffc753d6a69e43@%3Cgeneral.incubator.apache.org%3E
> > 3.
> https://lists.apache.org/thread.html/658cba0894ba6d8884ee3900055eeea3053d6ba09d4be59a9603084a@%3Cgeneral.incubator.apache.org%3E
> > 4.
> https://lists.apache.org/thread.html/aca69095d5b76b4acfe64a2dfe5989b82c6ed9d191499a41a005218c@%3Cgeneral.incubator.apache.org%3E
> > 5.
> https://lists.apache.org/thread.html/7cd55f482d8842089ffdc6f13cd950f91ca3773eaf6d64dec7dfb65b@%3Cgeneral.incubator.apache.org%3E
> > 6,
> https://lists.apache.org/thread.html/52c09582d098f414a15b3a13e06bbb461b182a340635fd459ebdbbb9@%3Cgeneral.incubator.apache.org%3E
> > 7.
> https://lists.apache.org/thread.html/728065ab61e74161c6d0851ada4cf254bd1e4535fcb75674fe478530@%3Cgeneral.incubator.apache.org%3E
> > 8.
> https://lists.apache.org/thread.html/148f49f8d531629e8d39907447c1c65c611ac9fa37621a7ba36f1681@%3Cgeneral.incubator.apache.org%3E
> > 9.
> https://lists.apache.org/thread.html/dcc7974c132e9ae231f385f476e9023ccb161a65e902760793c0a076@%3Cgeneral.incubator.apache.org%3E
> > 10.
> https://lists.apache.org/thread.html/dc5b8252f42746475269260ff771a4f99dfa0a36bb4585eb358399ed@%3Cgeneral.incubator.apache.org%3E
> > 11.
> https://lists.apache.org/thread.html/6736822bbaee99dd4415ca79a37f76ccee65d384a6be57fbe1175b42@%3Cgeneral.incubator.apache.org%3E
> > 12.
> https://lists.apache.org/thread.html/5a7a9e021394e73cba153870f68f9b0a2b91f9489a9c7fbf6fc63006@%3Cgeneral.incubator.apache.org%3E
> > 13.
> https://lists.apache.org/thread.html/ff6a3fbac0dbd14d4b44fb701d1974d78755b203c9734eb8e5de588a@%3Cgeneral.incubator.apache.org%3E
> > 14.
> https://lists.apache.org/thread.html/ebb3d1fbce1ed53a74067ce210a90ee6dfd166341210abc7a04a5992@%3Cgeneral.incubator.apache.org%3E
> > 15.
> https://lists.apache.org/thread.html/92c4ce80bb6fb4c4bd3b373acb2ef80b0c5129a6d3725e31de29e700@%3Cgeneral.incubator.apache.org%3E
> >
> >
> > -
> > 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: Incubation Pain Points

[Willem Jiang]

It could be a grown pain for the new podlings if they need to go
through 10+ voting, but it could make the life more easier by
providing some tools to help the podling to find out the issues before
sending out the vote.
I know it is harder to provide an unify tool which could be useful for
all kind of project, but it could address most of common issues if
IPMC can build the tools together by sharing our experiences.

Regards,

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Mon, Jun 17, 2019 at 5:37 PM Justin Mclean  wrote:
>
> Hi,
>
> > The biggest fix I’d suggest for the incubator is parallel voting
>
> Worthy of consideration (please start a thread), but IMO we want to be 
> careful it doesn’t overwhelm the IPMC. I’ve seen some RCs got through 10+ 
> votes, and most go through 2 or 3. That’s potentially 2 or 3 or 5x more calls 
> for votes on the IPMC list, unless we modify it somehow or somehow get more 
> IPMC members to vote on releases it’s going to need some careful 
> consideration.
>
> Some discussion on legal discuss and in the last board report may help reduce 
> the requirement for revotes like that.
>
> > after an IPMC vote failed yet again on some aspect that the
> > community is not interested in at all (but should be, but still isn’t).
>
> Or alternatively how could a podling get the community (or it's mentors) to 
> pick up these things before the IPMC vote? In theory your mentors should pick 
> up any issues that the IPMC finds, in practise that doesn't always happen.
>
> 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: [VOTE] Zipkin leave incubator, return back to OpenZipkin

[Dave Fisher]

Hi David and Greg,

> On Jun 18, 2019, at 5:39 PM, Justin Mclean  wrote:
> 
> HI,
> 
> +1 (binding)
> 
> I hope the podling has better success outside the ASF.
> 
> BTW in all previous cases of podlings exiting I could find, a vote was taken 
> (see below links and there’s more I’ve not listed). In most cases this was to 
> retire rather than returning/going elsewhere, so the situation not exactly 
> the same, but that’s a data point all the same.

If anyone thinks a VOTE is not necessary then please discuss why on another 
thread.

Regards,
Dave

> 
> Thanks
> Justin
> 
> 1. 
> https://lists.apache.org/thread.html/6afe3024bdbaf6e484ff376be0919ad6e6935b1688b08e7f8710542a@%3Cgeneral.incubator.apache.org%3E
> 2. 
> https://lists.apache.org/thread.html/c386b985379c8b6b54d791c8eaa62e429987ffb651ffc753d6a69e43@%3Cgeneral.incubator.apache.org%3E
> 3. 
> https://lists.apache.org/thread.html/658cba0894ba6d8884ee3900055eeea3053d6ba09d4be59a9603084a@%3Cgeneral.incubator.apache.org%3E
> 4. 
> https://lists.apache.org/thread.html/aca69095d5b76b4acfe64a2dfe5989b82c6ed9d191499a41a005218c@%3Cgeneral.incubator.apache.org%3E
> 5. 
> https://lists.apache.org/thread.html/7cd55f482d8842089ffdc6f13cd950f91ca3773eaf6d64dec7dfb65b@%3Cgeneral.incubator.apache.org%3E
> 6, 
> https://lists.apache.org/thread.html/52c09582d098f414a15b3a13e06bbb461b182a340635fd459ebdbbb9@%3Cgeneral.incubator.apache.org%3E
> 7. 
> https://lists.apache.org/thread.html/728065ab61e74161c6d0851ada4cf254bd1e4535fcb75674fe478530@%3Cgeneral.incubator.apache.org%3E
> 8. 
> https://lists.apache.org/thread.html/148f49f8d531629e8d39907447c1c65c611ac9fa37621a7ba36f1681@%3Cgeneral.incubator.apache.org%3E
> 9. 
> https://lists.apache.org/thread.html/dcc7974c132e9ae231f385f476e9023ccb161a65e902760793c0a076@%3Cgeneral.incubator.apache.org%3E
> 10. 
> https://lists.apache.org/thread.html/dc5b8252f42746475269260ff771a4f99dfa0a36bb4585eb358399ed@%3Cgeneral.incubator.apache.org%3E
> 11. 
> https://lists.apache.org/thread.html/6736822bbaee99dd4415ca79a37f76ccee65d384a6be57fbe1175b42@%3Cgeneral.incubator.apache.org%3E
> 12. 
> https://lists.apache.org/thread.html/5a7a9e021394e73cba153870f68f9b0a2b91f9489a9c7fbf6fc63006@%3Cgeneral.incubator.apache.org%3E
> 13. 
> https://lists.apache.org/thread.html/ff6a3fbac0dbd14d4b44fb701d1974d78755b203c9734eb8e5de588a@%3Cgeneral.incubator.apache.org%3E
> 14. 
> https://lists.apache.org/thread.html/ebb3d1fbce1ed53a74067ce210a90ee6dfd166341210abc7a04a5992@%3Cgeneral.incubator.apache.org%3E
> 15. 
> https://lists.apache.org/thread.html/92c4ce80bb6fb4c4bd3b373acb2ef80b0c5129a6d3725e31de29e700@%3Cgeneral.incubator.apache.org%3E
> 
> 
> -
> 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] Zipkin leave incubator, return back to OpenZipkin

[Justin Mclean]

HI,

+1 (binding)

 I hope the podling has better success outside the ASF.

BTW in all previous cases of podlings exiting I could find, a vote was taken 
(see below links and there’s more I’ve not listed). In most cases this was to 
retire rather than returning/going elsewhere, so the situation not exactly the 
same, but that’s a data point all the same.

Thanks
Justin

1. 
https://lists.apache.org/thread.html/6afe3024bdbaf6e484ff376be0919ad6e6935b1688b08e7f8710542a@%3Cgeneral.incubator.apache.org%3E
2. 
https://lists.apache.org/thread.html/c386b985379c8b6b54d791c8eaa62e429987ffb651ffc753d6a69e43@%3Cgeneral.incubator.apache.org%3E
3. 
https://lists.apache.org/thread.html/658cba0894ba6d8884ee3900055eeea3053d6ba09d4be59a9603084a@%3Cgeneral.incubator.apache.org%3E
4. 
https://lists.apache.org/thread.html/aca69095d5b76b4acfe64a2dfe5989b82c6ed9d191499a41a005218c@%3Cgeneral.incubator.apache.org%3E
5. 
https://lists.apache.org/thread.html/7cd55f482d8842089ffdc6f13cd950f91ca3773eaf6d64dec7dfb65b@%3Cgeneral.incubator.apache.org%3E
6, 
https://lists.apache.org/thread.html/52c09582d098f414a15b3a13e06bbb461b182a340635fd459ebdbbb9@%3Cgeneral.incubator.apache.org%3E
7. 
https://lists.apache.org/thread.html/728065ab61e74161c6d0851ada4cf254bd1e4535fcb75674fe478530@%3Cgeneral.incubator.apache.org%3E
8. 
https://lists.apache.org/thread.html/148f49f8d531629e8d39907447c1c65c611ac9fa37621a7ba36f1681@%3Cgeneral.incubator.apache.org%3E
9. 
https://lists.apache.org/thread.html/dcc7974c132e9ae231f385f476e9023ccb161a65e902760793c0a076@%3Cgeneral.incubator.apache.org%3E
10. 
https://lists.apache.org/thread.html/dc5b8252f42746475269260ff771a4f99dfa0a36bb4585eb358399ed@%3Cgeneral.incubator.apache.org%3E
11. 
https://lists.apache.org/thread.html/6736822bbaee99dd4415ca79a37f76ccee65d384a6be57fbe1175b42@%3Cgeneral.incubator.apache.org%3E
12. 
https://lists.apache.org/thread.html/5a7a9e021394e73cba153870f68f9b0a2b91f9489a9c7fbf6fc63006@%3Cgeneral.incubator.apache.org%3E
13. 
https://lists.apache.org/thread.html/ff6a3fbac0dbd14d4b44fb701d1974d78755b203c9734eb8e5de588a@%3Cgeneral.incubator.apache.org%3E
14. 
https://lists.apache.org/thread.html/ebb3d1fbce1ed53a74067ce210a90ee6dfd166341210abc7a04a5992@%3Cgeneral.incubator.apache.org%3E
15. 
https://lists.apache.org/thread.html/92c4ce80bb6fb4c4bd3b373acb2ef80b0c5129a6d3725e31de29e700@%3Cgeneral.incubator.apache.org%3E


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

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

[David Nalley]

+1 (binding)

I agree with Greg, this feels superfluous. Let’s get out of the way of
people doing the work.

—David

On Tue, Jun 18, 2019 at 01:37 Greg Stein  wrote:

> +1 (binding)
>
> (and IMO this vote should never have been needed/called; let's help them,
> rather than hinder)
>
> On Mon, Jun 17, 2019 at 8:22 PM Sheng Wu 
> wrote:
>
> > Hi
> >
> > This is a call for official vote of Zipkin leave from incubator, and
> > return back to OpenZipkin.
> >
> > PPMC have voted.[1], carried two IPMC +1 vote from Sheng Wu and Willem
> > Jiang
> >
> > There is no trademark, logo transfer, so, Zipkin community is OK to still
> > use the name(io.zipkin or zipkin + xxx) and logo.
> > `org.apache.zipkin` is not allowed or going to be used.
> > All 9 repositories(GitHub repo) will be transferred back to OpenZipkin
> > org(GitHub).
> > incubator-zipkin --> https://github.com/openzipkin/zipkin
> > ncubator-zipkin-dependencies -->
> > https://github.com/openzipkin/zipkin-dependencies
> > incubator-zipkin-api --> https://github.com/openzipkin/zipkin-api
> > incubator-zipkin-b3-propagation -->
> > https://github.com/openzipkin/b3-propagation
> > incubator-zipkin-reporter-java -->
> > https://github.com/openzipkin/zipkin-reporter-java
> > incubator-zipkin-brave --> https://github.com/openzipkin/brave
> > incubator-zipkin-brave-cassandra -->
> > https://github.com/openzipkin/brave-cassandra
> > incubator-zipkin-brave-karaf -->
> https://github.com/openzipkin/brave-karaf
> > incubator-zipkin-layout-factory -->
> > https://github.com/openzipkin/zipkin-layout-factory
> >
> > Voting will start now (2019-6-18 9:20 UTC+8) and will remain open 72
> hours
> > only for consensus, Request all IPMC members to give their vote.
> > [ ] +1 Agree
> > [ ] +0 No opinion.
> > [ ] -1 Do not agree because
> >
> > [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
> > >
> >
> >
> >
> > Sheng Wu
> > Apache Skywalking, ShardingSphere, Zipkin
> >
> >
> >
> >
>

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

[P. Taylor Goetz]

+1 (binding)

-Taylor

> On Jun 17, 2019, at 9:21 PM, Sheng Wu  wrote:
> 
> Hi
> 
> This is a call for official vote of Zipkin leave from incubator, and return 
> back to OpenZipkin.
> 
> PPMC have voted.[1], carried two IPMC +1 vote from Sheng Wu and Willem Jiang
> 
> There is no trademark, logo transfer, so, Zipkin community is OK to still use 
> the name(io.zipkin or zipkin + xxx) and logo. 
> `org.apache.zipkin` is not allowed or going to be used.
> All 9 repositories(GitHub repo) will be transferred back to OpenZipkin 
> org(GitHub).
> incubator-zipkin --> https://github.com/openzipkin/zipkin 
> ncubator-zipkin-dependencies --> 
> https://github.com/openzipkin/zipkin-dependencies 
> incubator-zipkin-api --> https://github.com/openzipkin/zipkin-api 
> incubator-zipkin-b3-propagation --> 
> https://github.com/openzipkin/b3-propagation 
> incubator-zipkin-reporter-java --> 
> https://github.com/openzipkin/zipkin-reporter-java 
> incubator-zipkin-brave --> https://github.com/openzipkin/brave 
> incubator-zipkin-brave-cassandra --> 
> https://github.com/openzipkin/brave-cassandra 
> incubator-zipkin-brave-karaf --> https://github.com/openzipkin/brave-karaf 
> incubator-zipkin-layout-factory --> 
> https://github.com/openzipkin/zipkin-layout-factory 
> 
> Voting will start now (2019-6-18 9:20 UTC+8) and will remain open 72 hours 
> only for consensus, Request all IPMC members to give their vote.
> [ ] +1 Agree
> [ ] +0 No opinion.
> [ ] -1 Do not agree because
> 
> [1] 
> https://lists.apache.org/thread.html/fbeb254f569d9852e9740d55532ee338580287ec384e26c7d9107964@%3Cdev.zipkin.apache.org%3E
>  
> 
> 
> 
> 
> 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

Re: Incubation Pain Points

[Dave Fisher]

Hi -

Very interesting talk. It reminds me of Oracle’s donation of OpenOffice.

Would you share your 10 points in text via email?

Best Regards,
Dave

> On Jun 14, 2019, at 3:57 AM, Geertjan Wielenga  wrote:
> 
> Just as a quick follow up, I watched this YouTube recording of a session I
> did last year on the NetBeans move to Apache again today and, it's been a
> while since I watched it last, but I think it still really nails it in
> terms of the pain/gain continuum of transitioning a project to Apache, in
> all its bleakness. :-)
> 
> https://www.youtube.com/watch?v=Bnznard9Nls
> 
> Gj
> 
> 
> On Thu, Jun 13, 2019 at 10:29 PM Geertjan Wielenga 
> wrote:
> 
>> Speaking on behalf of myself only, though note I am PMC chair of NetBeans,
>> which went through a protracted (nice way of saying ‘complex’) incubation
>> because of its size (‘very large’) and history (20+ years) — the key to any
>> new culture is to adopt its traditions and to fight them as little as
>> possible. And one can’t really understand the culture until one is in it.
>> It’s hard to really prepare — other than to admire projects like Maven or
>> TomEE and to want and aim to be like them, regardless of the contortions
>> required to get there.
>> 
>> Gj
>> 
>> 
>> On Thu, 13 Jun 2019 at 21:10, Dave Fisher  wrote:
>> 
>>> Hi -
>>> 
>>> Here are some thoughts I have to improving Incubation. These are not
>>> really new, but I think we should discuss where and how best to apply these.
>>> 
>>> (1) Champions need to very clear that the ASF expects Community decisions
>>> not BDFLs. Burnout is one factor to highlight why community is important.
>>> Vendor independence is important and part of why BDFLs don’t fly. In the
>>> last few years we have deemphasized the role of Champion and I think we
>>> need to list out some of the duties a Champion has to both the prospective
>>> podling community and the Incubator.
>>> 
>>> (2) We should help existing communities plan their entry into Incubation
>>> with their proposals. Currently TVM is moving their community over before
>>> repositories. That might be a better approach for many communities as it
>>> will assure that (a) the existing community keeps its current velocity and
>>> (b) they are making community decisions on list before actual development
>>> is moved over.
>>> 
>>> (3) Having a lower impedance to release and code changes would really
>>> help. We are already having this discussion. A very radical idea might be
>>> to move a lot of the License, Notice and Dependency work away from the
>>> Release Vote and instead do periodic and potentially automated audits of
>>> repositories. This would follow the REVIEW suggestion, but make it more
>>> automated and based on tooling.
>>> 
>>> (4) Relinquishing control of admin rights on GitHub repos is an
>>> impedance. I understand why this is done from an Apache Infrastructure
>>> perspective, but it is a surprise to podling communities. Making sure that
>>> a new podling knows fully what to expect before transferring repos would
>>> really help manage expectations.
>>> 
>>> (5) Failure to incubate is not failure. Currently 63 podlings have
>>> retired and there are two or three additional retirements soon. 4 or 5
>>> podlings moved on or back to where they were. The why of retirement could
>>> be analyzed, but it would need to look into mailing list archives because
>>> the information in podlings.xml is not always clear and is sometimes more
>>> diplomatic than the reality.
>>> 
>>> See https://projects.apache.org for an intriguing chart.
>>> 
>>> Regards,
>>> Dave
>>> 
>>> 
>>> 
>>> -
>>> 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: Incubation Pain Points

[Dave Fisher]

Apologies for replying twice in a row to the thread.

> On Jun 18, 2019, at 10:32 AM, Ted Dunning  wrote:
> 
> Alex, Jim, Bertrand,
> 
> This discussion is re-inventing a discussion that has been had before. At
> one time, the incubator tried to present principles to incoming podling
> (albeit not in a very well documented fashion). The reaction was that
> podlings strongly wanted specifics, not general principles. The idea of "no
> category x" worked, but things like "no downstream constraints" were a bit
> too vague. And some mostly kind of sort of accepted Apache ideas like votes
> should mostly be used to record consensus rather than make decisions are
> definitely too vague.
> 
> OK. So we learned that lesson. And the maturity model was created. And
> documentation was done.
> 
> One very clear sub-lesson is the unwritten rules really don't work when
> there are a large number of new people. Peoples' understanding changes or
> varies even when there is apparent consensus. Unwritten rules are also just
> not visible enough and can't be passed from one newbie to another.
> 
> And here we are. Folks are now saying that we need to be a lot looser. That
> there is a lot of leeway in how projects interpret the traditions we have.
> That we should just specify abstract invariants.
> 
> A lot of that involves some good ideas. But we need to not just circle back
> to the exact same place we started.
> 
> We can damp the pendulum a bit by the following going to a middle ground:
> 
> 1) *Add* the abstract principles (aka invariants) to an introduction to our
> documentation.

We can use the cookbook that Bertrand started.

> 
> 2) Use the maturity model. But add a statement that a project could
> negotiate an alternative maturity model during incubation as long as the
> IPMC agrees and it meets the invariants.

I was once a doubter, but I’ve come around. +1

> 
> 3) allow some non-conforming podling releases with special approvals.

See my other email just posted in this thread. I don’t think we need special 
approvals if we have Mentors guiding the podling towards conformance which we 
all agree is the final goal. If the podling has issues that need exceptions to 
the Release Policy then the Mentors should guide them to legal-discuss@ and 
note any decisions.

Regards,
Dave

> 
> 
> 
> On Tue, Jun 18, 2019 at 9:32 AM Alex Harui  wrote:
> 
>> 
>> 
>> On 6/18/19, 5:03 AM, "Jim Jagielski"  wrote:
>> 
>> 
>> 
>>> On Jun 18, 2019, at 7:42 AM, Bertrand Delacretaz <
>> bdelacre...@codeconsult.ch> wrote:
>>> 
>>> On Tue, Jun 18, 2019 at 1:18 PM Jim Jagielski 
>> wrote:
 ...prepping the existing community regarding what "moving to the
>> ASF means" is the job of the Champion, no?...
>>> 
>>> I agree but it has to be based on written docs, not oral tradition as
>>> that does not scale.
>>> 
>> 
>>Of course... but lack of it being on written docs does not make it
>> invalid nor not policy.
>> 
>> Just trying to follow these threads, it isn't clear there is agreement,
>> even among the "old-timers", as to what the invariants really are whether
>> written or oral.
>> 
>> For example, I'm a bit surprised that none of the old-timers disagreed
>> that there is an Apache Culture and that incubation is about assimilating
>> into that culture.  I thought I read many times on various ASF lists that
>> the ASF is comprised of many projects each with their own culture.  And
>> that the only common ground is a "Way" not a "Culture".  But then various
>> folks try to define the "Apache Way" and other folks disagree with their
>> definition.
>> 
>> At least in the US, there are many places where the residents have formed
>> or retained their own culture.  Folks immigrating to the US are not
>> required to assimilate into any particular aspect of US culture.  They are
>> only asked to obey certain laws.  And even then, the strictness of law
>> enforcement is somewhat influenced by the local culture and context.
>> 
>> What really are the invariants at the ASF that require strict inflexible
>> immediate enforcement?  I think there are really only a relatively small
>> number of them:
>> 
>> 1) No closed source in a release
>> 2) No CatX in a release
>> 3) No corporation owns decision making
>> 4) Majority vote on releases
>> 5) No advertising the general availability of non-releases.
>> 6) A protocol for handling security issues.
>> 7) ASF does not pay developers
>> 8) Don't violate US Non-Profit rules
>> 
>> A podling could be granted more flexibility around #2 and #5 with the
>> additional requirement of DISCLAIMER and -incubating labels.
>> 
>> Could everything else really be seen as goals for a community?  Then it
>> would be "Community over Code and Policy except these 8 things".
>> 
>> My 2 cents,
>> -Alex
>> 
>>-
>>To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>For additional commands, e-mail: 

Re: Incubation Pain Points

[Dave Fisher]

> On Jun 18, 2019, at 4:42 AM, Bertrand Delacretaz  
> wrote:
> 
> On Tue, Jun 18, 2019 at 1:18 PM Jim Jagielski  wrote:
>> ...prepping the existing community regarding what "moving to the ASF means" 
>> is the job of the Champion, no?...
> 
> I agree but it has to be based on written docs, not oral tradition as
> that does not scale.
> 
> http://incubator.apache.org/cookbook/#does_our_project_fit_the_apache_incubator
> does address this at least partly, IMO.

There has not been much traction on the cookbook changes that you started.

(1) I think a refocus on the cookbook would be helpful.

As part of the Cookbook update we should make sure of the main points of the 
Apache Way / Culture / minimums are documented. Alex’s list else thread is as 
good a start as any.

(2) Thanks for linking to the Board thread from February. There is some support 
there for allowing Podling Releases to entirely PPMC based assuming there is 
enough Mentor engagement.

Advantages included:
- Keeps Releases in the Community. Provided they meet minimums.
- Avoids the need for “heroics” from those who review 100s of releases.

Disadvantages might include:
- Initial Podling Releases cannot be wholly under the "legal shield" depending 
on how that is interpreted.
- Some think that Release issues won’t be handled until just before graduation.

I propose that the IPMC comfirms an updated policy that we expect that 
Podling’s Apache Releases initially conform to a minimum that includes a 
DISCLAIMER that is invariant aside from the podling name, and fits Apache 
Distribution Policy plus including “-incubator” or “-incubating” in the 
filenames of all artifacts except the KEYS.

Before graduation each of the podling’s released products must be confirmed by 
their Mentors to conform to Apache Release Policy. If there are not enough 
active Mentors then the podling should (a) request additional mentors and/or 
(b) request a review on general@. Such a review should not be during the 
release of a version of the product. If the Mentors have any concerns or 
questions then they can request the review from general@ themselves.

(3) Does anyone have a sense about how many retired podlings where failure to 
incubate was due to release problems? And, if so can that be differentiated 
from other community issues?

(4) Convenience Binary releases need careful discussion in another thread since 
these are ever evolving as new packaging and container technology is under 
continual development. I think that this is another thread that should be 
pursued after we settle on Podling Release Policy.

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: [VOTE] Zipkin leave incubator, return back to OpenZipkin

[Tomaz Muraus]

[+1] Agree

And best of luck in the future.

On Tue, Jun 18, 2019 at 3:22 AM Sheng Wu  wrote:

> Hi
>
> This is a call for official vote of Zipkin leave from incubator, and
> return back to OpenZipkin.
>
> PPMC have voted.[1], carried two IPMC +1 vote from Sheng Wu and Willem
> Jiang
>
> There is no trademark, logo transfer, so, Zipkin community is OK to still
> use the name(io.zipkin or zipkin + xxx) and logo.
> `org.apache.zipkin` is not allowed or going to be used.
> All 9 repositories(GitHub repo) will be transferred back to OpenZipkin
> org(GitHub).
> incubator-zipkin --> https://github.com/openzipkin/zipkin
> ncubator-zipkin-dependencies -->
> https://github.com/openzipkin/zipkin-dependencies
> incubator-zipkin-api --> https://github.com/openzipkin/zipkin-api
> incubator-zipkin-b3-propagation -->
> https://github.com/openzipkin/b3-propagation
> incubator-zipkin-reporter-java -->
> https://github.com/openzipkin/zipkin-reporter-java
> incubator-zipkin-brave --> https://github.com/openzipkin/brave
> incubator-zipkin-brave-cassandra -->
> https://github.com/openzipkin/brave-cassandra
> incubator-zipkin-brave-karaf --> https://github.com/openzipkin/brave-karaf
> incubator-zipkin-layout-factory -->
> https://github.com/openzipkin/zipkin-layout-factory
>
> Voting will start now (2019-6-18 9:20 UTC+8) and will remain open 72 hours
> only for consensus, Request all IPMC members to give their vote.
> [ ] +1 Agree
> [ ] +0 No opinion.
> [ ] -1 Do not agree because
>
> [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
> >
>
>
>
> Sheng Wu
> Apache Skywalking, ShardingSphere, Zipkin
>
>
>
>

Re: Incubation Pain Points

[Ted Dunning]

Alex, Jim, Bertrand,

This discussion is re-inventing a discussion that has been had before. At
one time, the incubator tried to present principles to incoming podling
(albeit not in a very well documented fashion). The reaction was that
podlings strongly wanted specifics, not general principles. The idea of "no
category x" worked, but things like "no downstream constraints" were a bit
too vague. And some mostly kind of sort of accepted Apache ideas like votes
should mostly be used to record consensus rather than make decisions are
definitely too vague.

OK. So we learned that lesson. And the maturity model was created. And
documentation was done.

One very clear sub-lesson is the unwritten rules really don't work when
there are a large number of new people. Peoples' understanding changes or
varies even when there is apparent consensus. Unwritten rules are also just
not visible enough and can't be passed from one newbie to another.

And here we are. Folks are now saying that we need to be a lot looser. That
there is a lot of leeway in how projects interpret the traditions we have.
That we should just specify abstract invariants.

A lot of that involves some good ideas. But we need to not just circle back
to the exact same place we started.

We can damp the pendulum a bit by the following going to a middle ground:

1) *Add* the abstract principles (aka invariants) to an introduction to our
documentation.

2) Use the maturity model. But add a statement that a project could
negotiate an alternative maturity model during incubation as long as the
IPMC agrees and it meets the invariants.

3) allow some non-conforming podling releases with special approvals.



On Tue, Jun 18, 2019 at 9:32 AM Alex Harui  wrote:

>
>
> On 6/18/19, 5:03 AM, "Jim Jagielski"  wrote:
>
>
>
> > On Jun 18, 2019, at 7:42 AM, Bertrand Delacretaz <
> bdelacre...@codeconsult.ch> wrote:
> >
> > On Tue, Jun 18, 2019 at 1:18 PM Jim Jagielski 
> wrote:
> >> ...prepping the existing community regarding what "moving to the
> ASF means" is the job of the Champion, no?...
> >
> > I agree but it has to be based on written docs, not oral tradition as
> > that does not scale.
> >
>
> Of course... but lack of it being on written docs does not make it
> invalid nor not policy.
>
> Just trying to follow these threads, it isn't clear there is agreement,
> even among the "old-timers", as to what the invariants really are whether
> written or oral.
>
> For example, I'm a bit surprised that none of the old-timers disagreed
> that there is an Apache Culture and that incubation is about assimilating
> into that culture.  I thought I read many times on various ASF lists that
> the ASF is comprised of many projects each with their own culture.  And
> that the only common ground is a "Way" not a "Culture".  But then various
> folks try to define the "Apache Way" and other folks disagree with their
> definition.
>
> At least in the US, there are many places where the residents have formed
> or retained their own culture.  Folks immigrating to the US are not
> required to assimilate into any particular aspect of US culture.  They are
> only asked to obey certain laws.  And even then, the strictness of law
> enforcement is somewhat influenced by the local culture and context.
>
> What really are the invariants at the ASF that require strict inflexible
> immediate enforcement?  I think there are really only a relatively small
> number of them:
>
> 1) No closed source in a release
> 2) No CatX in a release
> 3) No corporation owns decision making
> 4) Majority vote on releases
> 5) No advertising the general availability of non-releases.
> 6) A protocol for handling security issues.
> 7) ASF does not pay developers
> 8) Don't violate US Non-Profit rules
>
> A podling could be granted more flexibility around #2 and #5 with the
> additional requirement of DISCLAIMER and -incubating labels.
>
> Could everything else really be seen as goals for a community?  Then it
> would be "Community over Code and Policy except these 8 things".
>
> My 2 cents,
> -Alex
>
> -
> 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: Incubation Pain Points

[Alex Harui]

On 6/18/19, 5:03 AM, "Jim Jagielski"  wrote:



> On Jun 18, 2019, at 7:42 AM, Bertrand Delacretaz 
 wrote:
> 
> On Tue, Jun 18, 2019 at 1:18 PM Jim Jagielski  wrote:
>> ...prepping the existing community regarding what "moving to the ASF 
means" is the job of the Champion, no?...
> 
> I agree but it has to be based on written docs, not oral tradition as
> that does not scale.
> 

Of course... but lack of it being on written docs does not make it invalid 
nor not policy.

Just trying to follow these threads, it isn't clear there is agreement, even 
among the "old-timers", as to what the invariants really are whether written or 
oral.

For example, I'm a bit surprised that none of the old-timers disagreed that 
there is an Apache Culture and that incubation is about assimilating into that 
culture.  I thought I read many times on various ASF lists that the ASF is 
comprised of many projects each with their own culture.  And that the only 
common ground is a "Way" not a "Culture".  But then various folks try to define 
the "Apache Way" and other folks disagree with their definition.

At least in the US, there are many places where the residents have formed or 
retained their own culture.  Folks immigrating to the US are not required to 
assimilate into any particular aspect of US culture.  They are only asked to 
obey certain laws.  And even then, the strictness of law enforcement is 
somewhat influenced by the local culture and context.

What really are the invariants at the ASF that require strict inflexible 
immediate enforcement?  I think there are really only a relatively small number 
of them:

1) No closed source in a release
2) No CatX in a release
3) No corporation owns decision making
4) Majority vote on releases
5) No advertising the general availability of non-releases.
6) A protocol for handling security issues.
7) ASF does not pay developers
8) Don't violate US Non-Profit rules

A podling could be granted more flexibility around #2 and #5 with the 
additional requirement of DISCLAIMER and -incubating labels.

Could everything else really be seen as goals for a community?  Then it would 
be "Community over Code and Policy except these 8 things".

My 2 cents,
-Alex

-
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] Zipkin leave incubator, return back to OpenZipkin

[Stian Soiland-Reyes]

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

+1 (binding)

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


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

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

[Myrle Krantz]

+1, and I wish OpenZipkin all the best in your future endeavors.

Best,
Myrle

On Tue, Jun 18, 2019 at 12:21 PM Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:

> > On Mon, Jun 17, 2019 at 8:22 PM Sheng Wu 
> wrote:
>
> > > This is a call for official vote of Zipkin leave from incubator, and
> > > return back to OpenZipkin.
>
> +1
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: LGPL dependency

[申远]

Thanks for help.

I will bring this to legal-jira this weeks later.

Best Regards,
YorkShen

申远


Myrle Krantz  于2019年6月17日周一 下午8:07写道：

> Thank you all,
>
> YorkShen, I think at this point the best thing to do is to open a "legal"
> ticket at this Jira (https://issues.apache.org/jira/browse/LEGAL).  I
> suspect that if you're only including the BSD-licensed headers, that Weex
> will only be dependent on BSD-licensed code.  It's possible that the
> "runtime" argument will work in this case too.
>
> But this discussion hasn't made me feel confident in either statement, and
> there are other Apache projects for which this question may be relevant.
> I'd like a final answer and the legal committee can provide that.
>
> Let me know if you need help formulating the ticket.
>
> Best Regards,
> Myrle
>
> On Fri, Jun 14, 2019 at 7:13 PM Alex Harui 
> wrote:
>
> > Some  things I don't think have been mentioned in this thread so far:
> >
> > 1) Even if you make Webkit optional by offering V8, I believe the ASF
> > criteria for "optional" includes "less than half of your users will use
> > that option" and so if Webkit offers better performance and most of the
> > users select Webkit over V8, it won't really qualify Webkit as optional.
> > 2) AIUI, the ASF does not care about the licensing of RUNTIMES (my
> > emphasis) your project's code runs on.  Otherwise, no ASF project could
> run
> > on Windows or OSX.  Apache Flex runs on Adobe Flash/AIR runtimes.
> > 3) I could not quickly find a direct quote for this, but I believe the
> ASF
> > does not care about the licensing of BUILD TOOLS (emphasis mine) used to
> > manipulate the source in the source release as long as the license of
> those
> > tools does not constrain usage of that code (like some non-commercial
> > restriction, or even a "no evil" restriction.
> >
> > AIUI, the whole purpose of these restrictions is to not place
> restrictions
> > on modifications to source or use of source when that source is
> eventually
> > executed (whether interpreted or compiled or other).
> >
> > So, if I've made that clear so far, the question I have for Weex is:  How
> > is Webkit used in Weex?  Is it just a runtime and libraries for that
> > runtime?  If so, then I believe it is ok to have a dependency on LGPL
> > Webkit, but I would recommend that you find a way to not bundle Webkit in
> > the release artifacts.  Have it downloaded or make it a "prerequisite"
> just
> > like I think every ASF Java-based project says you must install a Java
> JDK
> > and don't bundle Java JDKs.
> >
> > Other questions to ask relative to whether Webkit is a runtime or build
> > tool:
> >
> > A) Will anybody realistically want to modify the Webkit sources in order
> > to use Weex?  If no, that's great, and another reason to not bundle those
> > header files with your sources.
> > B) Will use of the WebKit header files and other binaries you depend on
> > create a restriction on use?  If no, that's great as well, and I think if
> > the answer to A and B are both "no", the IPMC should consider Webkit to
> be
> > a runtime/build-tool dependency and let it go.
> >
> > HTH,
> > -Alex
> >
> >
> > On 6/14/19, 5:09 AM, "York Shen"  wrote:
> >
> > It depends on the definition of optional dependency. Weex targets
> iOS,
> > Android and Browser environment and Webkit header files and shared
> library
> > are only bundled for Android environment. As for other environments, the
> OS
> > or browser itself has exposed enough API for Weex.
> >
> > PS: I am pretty sure that the iOS system itself uses almost the same
> > code of Webkit as Weex does to build its WKWebView. It’s really strange
> > that’s ok for Weex iOS and not ok for Weex Android.
> >
> > > 在 2019年6月14日，19:17，Justin Mclean  写道：
> > >
> > > Hi,
> > >
> > >> Well, what if Weex copies some BSD header files in Webkit then run
> > on Webkit? IMHO, the Webkit is also an environment for Weex in this case.
> > >
> > > You still didi not answer if this is an optional dependancy? But
> > again either way I suggest you ask on legal discuss.
> > >
> > > 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
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>

Re: Incubation Pain Points

[Jim Jagielski]

> On Jun 18, 2019, at 7:42 AM, Bertrand Delacretaz  
> wrote:
> 
> On Tue, Jun 18, 2019 at 1:18 PM Jim Jagielski  wrote:
>> ...prepping the existing community regarding what "moving to the ASF means" 
>> is the job of the Champion, no?...
> 
> I agree but it has to be based on written docs, not oral tradition as
> that does not scale.
> 

Of course... but lack of it being on written docs does not make it invalid nor 
not policy.


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

Re: Incubation Pain Points

[Bertrand Delacretaz]

On Tue, Jun 18, 2019 at 1:44 PM Justin Mclean  wrote:
> >...at the Incubator level I think there's
> > way to many unclear or badly documented rules.
>
> Nope, sorry that’s at the ASF level

I agree, the mess is on both sides ;-)

-Bertrand

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

Re: Incubation Pain Points

[Justin Mclean]

Hi,

> In principle I would agree, but at the Incubator level I think there's
> way to many unclear or badly documented rules.

Nope, sorry that’s at the ASF level. The IPMC has some documentation that need 
clearing up and reducing but that’s not the core issue.

> Could we adopt the Maturity Model [1] as the only thing to which
> podlings must conform to to graduate? Do we need more than that?

While I like the Maturity Model and think it’s very useful, several IPMC 
members are not in favour of making it standard.

> Focusing on such a clearly defined set of rules and removing anything
> from http://incubator.apache.org/ that's not essential 

Other than incubating in name, DISCLAIMER  and IPMC voting there’s nothing 
under http://incubator.apache.org that specifies anything extra that ’s 
required on top of other ASF policies. Again it’s those policies that podlings 
need to be in line with by the time they graduate.

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

Re: Incubation Pain Points

[Bertrand Delacretaz]

On Tue, Jun 18, 2019 at 1:18 PM Jim Jagielski  wrote:
> ...prepping the existing community regarding what "moving to the ASF means" 
> is the job of the Champion, no?...

I agree but it has to be based on written docs, not oral tradition as
that does not scale.

http://incubator.apache.org/cookbook/#does_our_project_fit_the_apache_incubator
does address this at least partly, IMO.

-Bertrand

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

Re: Incubation Pain Points

[Jim Jagielski]

> On Jun 17, 2019, at 1:25 PM, Dave Fisher  wrote:
> 
> Hi Roman,
> 
> All very true. What the Incubator could do better is to let people know the 
> key values of The Apache Way that will impact any existing community if they 
> come to the ASF through the Incubator. While it will be a community that 
> comes (or doesn’t), it will more likely be a vendor than a community that 
> decides to come to Apache. That will more likely be for the permissive 
> licensing than for community over code.

Certainly prepping the existing community regarding what "moving to the ASF 
means" is the job of the Champion, no?
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubation Pain Points

[Bertrand Delacretaz]

Hi,

On Thu, Jun 13, 2019 at 9:10 PM Dave Fisher  wrote:
> ...Here are some thoughts I have to improving Incubation

FWIW, to give additional context for ASF Members, there was also a
discussion about this started by Incubator PMC members, on the board@
list: http://s.apache.org/zipkin_mentors_feb18

(as mentioned, accessible to ASF Members and PMC Chairs only, but I
think most IPMC members are ASF Members)

-Bertrand

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

Re: Incubation Pain Points

[Bertrand Delacretaz]

Hi,

On Mon, Jun 17, 2019 at 10:24 AM Christofer Dutz
 wrote:
> ...We have to make them understand that the ASF is more than a GIT repo, CI 
> Server and Mailing lists.
> That the ASF has great things to provide (Legal Shield, Marketing, Infra, 
> ...) but that this only works
> If you play along with some rules we have. Also should we explain WHY these 
> rules are there...

In principle I would agree, but at the Incubator level I think there's
way to many unclear or badly documented rules.

Could we adopt the Maturity Model [1] as the only thing to which
podlings must conform to to graduate? Do we need more than that?

Focusing on such a clearly defined set of rules and removing anything
from http://incubator.apache.org/ that's not essential in that view
might make our podlings life much easier.

-Bertrand

[1] https://community.apache.org/apache-way/apache-project-maturity-model.html
[2] http://www.apache.org/legal/release-policy.html

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

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

[Bertrand Delacretaz]

> On Mon, Jun 17, 2019 at 8:22 PM Sheng Wu  wrote:

> > This is a call for official vote of Zipkin leave from incubator, and
> > return back to OpenZipkin.

+1

-Bertrand

-
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
>>
>>

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
>
>

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

[sebb]

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: Incubation Pain Points

[Geertjan Wielenga]

I think a big and simple thing to consider is that the difference between
success/failure in migrating to Apache TLP is one of attitude -- i.e., the
very same things that the Zipkin community considered to be immensely
frustrating were considered to be immensely frustrating to the NetBeans
community too. However, in the case of the NetBeans community we (1) didn't
have the pre-history of going it alone that Zipkin has, i.e., for Zipkin
there was always the possibility of going back to their independent status
before Apache, while for NetBeans the prior state was Oracle and NetBeans
couldn't go back, it simply needed a governance model and so if it wasn't
going to be Apache it would have been something else, which would have been
frustrating to get into as well, so we just simply persevered until we
adopted everything and accepted everything and (2) Zipkin seems to be less
cohesive than NetBeans and less interested in being cohesive, i.e.,
concerned about laying down things for subgroups that might be averse to
that, while NetBeans is a pretty holistic organism working towards very
similar end goals. So, it's as much the nature of the specifics of a
community or project as it is about the specifics of Apache, the Apache
Way, the Incubator, etc.

Gj

On Mon, Jun 17, 2019 at 7:26 PM Dave Fisher  wrote:

> Hi Roman,
>
> All very true. What the Incubator could do better is to let people know
> the key values of The Apache Way that will impact any existing community if
> they come to the ASF through the Incubator. While it will be a community
> that comes (or doesn’t), it will more likely be a vendor than a community
> that decides to come to Apache. That will more likely be for the permissive
> licensing than for community over code.
>
> (1) The careful Apache Licensing and Release process that is not fully
> automated might be a surprise. If a project relies on frequent and quick
> releases then there will be a cultural issue as the project adapts. This
> needs to be fully considered. Projects need to discuss a more careful and
> deliberate transition between existing process and the ASF. Moving over
> repositories immediately might not be best.
>
> Yes, the IPMC can help lower the impedance for a release. I think rather
> than parallel releases we should allow projects whose communities need
> faster releases to be slower about moving repositories to Apache.
>
> (2) Community over code means global asynchronous communications with
> decisions in public based on Consensus. Consensus is often simple (Lazy),
> but is sometimes very difficult. This is the opposite from a “king” or BFDL
> (aka Linux Kernel, etc.) and it is not driven from within a “Vendor” team
> (at least not in the end.) The very foundation of the Apache Group was to
> bring back an abandoned project. An Apache project with a functioning PMC
> replaces committers from the community and supports the community of users.
> In many PMCs the original developers are long gone and some are likely in a
> fourth or fifth generation of committers.
>
> I think that the IPMC should recommend that mailing list communications be
> fully established prior to moving repositories. Rather than having the
> quickest most active developer take charge immediately we get Consensus
> from all the Initial Committers about it being time to move a repository.
> The choice of Transferring vs. Cloning needs to be clearly made.
>
> Surprises with repositories include giving up some admin rights and
> plugins in GitHub due to Apache’s management of 100s of repositories (close
> to 1000?) This will impact a project’s pipelines in unexpected ways.
>
> (3) Coming to Apache does mean there is a unique view on Foundation
> available resources. If a project wishes to Incubate with a number of extra
> resources then careful planning and possible exceptions to policies will
> need to be negotiated.
>
> I could go on, but I think we need to identify for prospective podlings
> what the main cultural points are so that they can know if they will have
> trouble.
>
> I think that the podling proposal template should be updated to be less
> verbose and more about the podling community clearly understanding what its
> going to happen and identifying what support the community will need.
>
> Regards,
> Dave
>
> > On Jun 17, 2019, at 9:02 AM, Roman Shaposhnik 
> wrote:
> >
> > On Mon, Jun 17, 2019 at 8:51 AM Geertjan Wielenga 
> wrote:
> >>
> >> It’s not really totally OK. People leaving back to their old place
> feeling
> >> unhappy and frustrated, how is that totally OK?
> >
> > I'll stick with Christofer's analogy -- if you come to a new country
> > thinking that
> > the roads are paved with gold -- all you're going to get is
> > frustration and unhappiness.
> > Not a single place is a paradise on earth.
> >
> > If, however, you come to the new country with the intent to learn and
> > see if this
> > place can *gradually* become your new home -- now you're talking.
> >
> > Obviously,