Re: [VOTE] Apache Tuweni 0.8.0

[Justin Mclean]

Hi,

> I see a lot of "oh no. a bad file". What is the takeaway from that? "The
> IPMC thinks we should not release.”

Has anyone voted -1? Nope. And even if they did a -1 vote is not a veto.

> How about "make the release, and fix that next time” ?

The podlings previous release put up for IPMC vote had the same issue.

> Look at the framing, and at how any normal reader is going to see it. It is
> (ahem) insanity to believe that it doesn't look like harshing on Tuweni for
> a file in their release. And then escalating with "oh geez. we need Infra
> to weigh in on this problem" (without really doing so, until yesterday,
> thus stalling the process)

We’ve needed infra to make their position clear on this for a while, we just 
didn’t have a release that we could show them, and asking hypothetical 
questions in the past has been answered with “we don’t answer those”. We now 
have an answer which makes it much clearer. That is a big improvement. Re 
“stalling” I asked the podling to check with infra, when they didn’t, I asked 
for them that spending up the process not stalled it.

> As long as the IPMC discusses podling releases, they are going to be
> *interfering*.

Currently only IPMC votes are binding on releases, so by design the incubator 
has to “interfere".

> And that is what I'm seeing with Tuweni, for a minor issue
> which has no material effect on people trying their product. Just ungate
> the release, and fix it next time.

They were asked to fix it last time, and we were told it was fixed, except it 
wasn’t. People make mistakes, hopefully it will be fixed in the next release. 
The release as it is, may have a material effect on people due to its licensing.

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

Re: Podlings, the Incubator, relationships and Apache

[Justin Mclean]

Hi,

> Which would be a reasonable assumption give:
> a) That only IPMC votes are binding on releases.
> b) It listed as a TLP in Whimsy
> c) The resolution that formed it uses the same language as a TLP and talks 
> abut forming a PMC and assigning a VP [1]
> 
> Does anyone know the history behind this, in particular a)? Has it been that 
> way from day one or way it something that was introduced due to some an issue 
> of some sort?

Anyone?

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

Re: [VOTE] (Re)Release Apache Flagon UserALE.js (Incubating) 1.0.0

[Joshua Poore]

Hi Folks,

Another friendly reminder: please VOTE on the ReRelease of Apache Flagon 
UserAle.js (Incubating) 1.0.0.

Our ReRelease was mandated by IPMC due to build artifacts that lacked 
“incubating” markings.

At this point we have +6 votes from our community and +2 Binding. We need one 
more VOTE from general@ to release and 2 of our mentors are AWOL. We’re 
entering the 10th consecutive day of this VOTE on general@ and that’s a very, 
very long time to wait on a ReRelease. 

Thanks to Justin for voting.

Tomorrow, we’ll be pushing v2.0.0 for a VOTE on general, as its wrapping up a 
VOTE in community. Again we’re down two mentors. Am hoping that we’re able to 
get feedback from IPMC a little more quickly. We have users waiting on an NPM 
packaged version of this release.

Thanks,

Joshua Poore


> On Jun 25, 2019, at 11:49 PM, Joshua Poore  wrote:
> 
> Ah, I understand. Copyright attribution is misplaced in License file 
> altogether—appendix gives instruction for how to add a copyright to 
> derivative works. *palm-to-face*. Thanks and sorry for being thick!
> 
> Josh  
> 
>> On Jun 25, 2019, at 9:10 PM, Joshua Poore  wrote:
>> 
>> Hi Justin, 
>> 
>> Dave Meikle and I worked to make the copyrights correct prior to this 
>> ReRelease. 
>> 
>> Our License File reads:
>> 
>>  © Copyright 2018 The Apache Software Foundation.
>> 
>> Our Notice Fille reads:
>> 
>> Copyright 2019 The Apache Software Foundation
>> 
>> We thought that was consistent with 
>> https://www.apache.org/legal/src-headers.html 
>> , however, both should be 
>> dated ‘2019’ (oversight).
>> 
>> If not, or you see something I missed, please don’t hesitate to point it out 
>> and I’ll make sure we get it right.
>> 
>> Thanks!
>> 
 From: Justin Mclean >>> >
 Date: June 25, 2019 at 8:11:25 PM EDT
 To: general@incubator.apache.org 
 Subject: Re: [VOTE] (Re)Release Apache Flagon UserALE.js (Incubating) 1.0.0
 Reply-To: general@incubator.apache.org 
 
 
 HI,
 
> Copyrights are 2019 in V2.0.0 under vote now in dev@. Moving forward, 
> we’ll be more careful.
 
 Which would still be incorrect that line should say:
 Copyright [] [name of copyright owner]
 
 As it where a 3rd party put their copyright notice in their file headers.
 
 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: LGPL dependency

[申远]

It looks like we have got result[1] from Legal VP, I will bring it here now

   1. It's fine if Weex only could include header files under 2-clause BSD
   license from Webkit at compiling time and has a dynamic link to Webkit.so
   at runtime.
   2. It's recommended that excluding Webkit.so from Weex convenience
   library. Users would include the code snippet below to include both weex
   and webkit.



weex_sdk





webkit




The following is what I need to consult from Incubator:

Google will ban all apps without 64 bit published in Google Play from 1st,
August, 2019 [1]. Though it's a good idea of excluding Webkit.so from
convenience library of Weex, Weex community needs to publish next release
with 64-bit support ASAP to give users enough time to upgrade Weex. I'd
like to remain webkit.so in convenience library of Weex only for next
release.

[1] https://issues.apache.org/jira/browse/LEGAL-464
[2] https://developer.android.com/distribute/best-practices/develop/64-bit

Best Regards,
YorkShen

申远


Roman Shaposhnik  于2019年6月24日周一 上午7:32写道：

> Lets continue this discussion on
> https://issues.apache.org/jira/browse/LEGAL-464 please
>
> On Sat, Jun 22, 2019 at 2:18 PM Matt Sicker  wrote:
> >
> > WebKit dates back to KHTML, an LGPL web engine from KDE. It sounds like
> > it’s some WebKit specific files that are BSD licensed. I haven’t
> inspected
> > the individual files, but I suspect that the header files are BSD
> licensed
> > to make linking less of a legal headache.
> >
> > On Sat, Jun 22, 2019 at 07:11, Craig Russell 
> wrote:
> >
> > > The Webkit license page https://webkit.org/licensing-webkit/ says
> > > portions licensed under LGPL and BSD licenses.
> > >
> > > Usually this means it's the user's choice which license to use.
> > >
> > > We would choose the BSD License for the components that we use.
> > >
> > > Can you find anywhere a statement that the Webkit.so is licensed only
> > > under LGPL?
> > >
> > > Craig
> > >
> > > > On Jun 14, 2019, at 1:40 AM, 申远  wrote:
> > > >
> > > > As mentioned above, Webkit is under dual License(BSD and LPGL) and
> it's
> > > > almost impossible for us to figure out which function is a pure BSD
> > > > function. I don't know
> > > > Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL will happen
> or
> > > > not. Perhaps pure BSD header file will lead to pure BSD
> implementation.
> > > > Perhaps?
> > > >
> > > > As for alternative dependency, it's possible if we make some major
> > > changes
> > > > to Weex. But convenience binary of each Weex release includes
> Webkit.so,
> > > > how to solve that problem? Maybe publish two convenience binary, one
> > > named
> > > > Weex_WebKit.aar and the other named Weex_BSDKit.aar ? Not sounds
> like a
> > > > good idea to me.
> > > >
> > > > Best Regards,
> > > > YorkShen
> > > >
> > > > 申远
> > > >
> > > >
> > > > Sheng Wu  于2019年6月14日周五 下午4:23写道：
> > > >
> > > >> Hi York
> > > >>
> > > >> I am not a C/C++ coder, so I could be wrong.
> > > >>
> > > >> But from I saw, Catalog X dependency required is not right. Like Hen
> > > said,
> > > >> alternative is an option.
> > > >>
> > > >> Such as
> > > >> Today’s another incubating project, ShardingSphere.
> > > >> When user wants to MySQL sharing, then they needs to accept MySQL
> Driver
> > > >> license first(or already accepted).
> > > >> But user could use ShardingSphere with PostgreSQL JDBC Driver.
> > > >>
> > > >>
> > > >> Sheng Wu
> > > >> Apache Skywalking, ShardingSphere, Zipkin
> > > >>
> > > >>
> > > >>
> > > >>> 在 2019年6月14日，下午4:15，Hen  写道：
> > > >>>
> > > >>> Assuming Weex requires Webkit and is unable to work with an
> > > alternative,
> > > >>> the issue here is that users of Weex would seem to have to permit
> > > reverse
> > > >>> engineering in their legal terms. Our position has been that that
> goes
> > > >>> beyond the scope of the Apache 2.0 license and would be an
> unpleasant
> > > >>> surprise for users.
> > > >>>
> > > >>> (seem to have to  =>  this is how we've discussed the license; an
> > > actual
> > > >>> court may decide something completely different)
> > > >>>
> > > >>> Looking at Weex's website's description, it does not seem to be
> that a
> > > >> user
> > > >>> of Weex will already have agreed to the terms of Webkit; thus I
> believe
> > > >>> they would be unpleasantly surprised.
> > > >>>
> > > >>> Hen
> > > >>>
> > > >>> On Fri, Jun 14, 2019 at 12:49 AM 申远  wrote:
> > > >>>
> > >  Hi,
> > > 
> > >  I am a PPMC member of Apache Weex. After serious reviewing of our
> > >  dependencies, I found there some of the source code we copied from
> > > >> Webkit
> > >  is actually under LGPL license(Category X) and our license format
> > > tools
> > >  changed the license header of these files to Apache v2
> incorrectly.
> > > I'd
> > >  like to hear advice from incubator that whether our actions below
> > > would
> > > >> fix
> > >  the Category X issue.
> > > 
> > >  First of all, License 

Re: [VOTE] Apache Tuweni 0.8.0

[Greg Stein]

+1 (binding)

On Mon, Jun 24, 2019 at 5:03 AM Antoine Toulme  wrote:

> Hi all,
> The Tuweni community voted on and has approved a proposal to release
> Tuweni 0.8.0. Pursuant to the Releases section of the Incubation
> Policy and we would now like to request the permission of the Incubator
> PMC to publish the
> tarball on the Tuweni Download page.
> Note we have collected 4 +1 votes from IPMC members and have therefore the
> necessary minimum votes.
>
> Please vote by 12 PM Paris time Thursday, 6/27.
>
> Thanks
> Antoine
>
> Proposal:
>
> https://lists.apache.org/thread.html/7ad88c9725d954f0c58968b3ba53da007b8b48079fe24ee908e03a04@%3Cdev.tuweni.apache.org%3E
> <
> https://lists.apache.org/thread.html/7ad88c9725d954f0c58968b3ba53da007b8b48079fe24ee908e03a04@%3Cdev.tuweni.apache.org%3E
> >
>
> Vote result:
>
> https://lists.apache.org/thread.html/2d4ac9cc208218e87d916a9bfc01faec53b30a5e714fe1d632f5fe8c@%3Cdev.tuweni.apache.org%3E
> <
> https://lists.apache.org/thread.html/2d4ac9cc208218e87d916a9bfc01faec53b30a5e714fe1d632f5fe8c@%3Cdev.tuweni.apache.org%3E
> >
>
> Releases section of the Incubation Policy:
> http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
>
>

Re: [VOTE] Apache Tuweni 0.8.0

[Greg Stein]

On Wed, Jun 26, 2019 at 9:35 PM Justin Mclean 
wrote:
>...

> This sort of language is not helpful. Nor do I think it is accurate. Can
> you please take more care with your words.
>

I feel it is accurate. And it is not directed at anybody. Only at this
process. It is descriptive, and my carefully chosen word that I feel
describes what is happening. You disagree. That will occur in any free
discussion. Only groupthink discussion sees no disagreement.

> Just let Tuweni make a release, already. Stuff like this will get fixed
> eventually.
>
> No-one is stopping them from making a release.


Sure looks like it from here.

I see a lot of "oh no. a bad file". What is the takeaway from that? "The
IPMC thinks we should not release."

Let me provide an exact quote: "this is currently not allowed."
Read that line again. Not. Allowed.

How about "make the release, and fix that next time" ?

Look at the framing, and at how any normal reader is going to see it. It is
(ahem) insanity to believe that it doesn't look like harshing on Tuweni for
a file in their release. And then escalating with "oh geez. we need Infra
to weigh in on this problem" (without really doing so, until yesterday,
thus stalling the process)

As long as the IPMC discusses podling releases, they are going to be
*interfering*. And that is what I'm seeing with Tuweni, for a minor issue
which has no material effect on people trying their product. Just ungate
the release, and fix it next time.

Do not attempt to rewrite history. "this is currently not allowed" was the
very first response. That damned well looks like the IPMC saying "no, you
cannot release that" ... **especially** when that comment comes from the VP
Incubator. Fact.

-g

Re: [VOTE] Apache Tuweni 0.8.0

[Justin Mclean]

Hi,

> Insanity.

This sort of language is not helpful. Nor do I think it is accurate. Can you 
please take more care with your words.

> Just let Tuweni make a release, already. Stuff like this will get fixed 
> eventually.

No-one is stopping them from making a release.

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

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

[Greg Stein]

On Wed, Jun 26, 2019 at 1:15 PM Ted Dunning  wrote:

> This comment by Craig is the most important one in the discussion.
>
> When the first words that people pick when disagreeing are essentially
> personal insults, what is going on is better described as mud wrestling
> rather than discussion.
>

Personal insults? Euh. [citation needed]

[RESULT] [VOTE] Release Apache Druid (incubating) 0.15.0 [RC2]

[Jihoon Son]

Hi all,

The vote to release Apache Druid (incubating) 0.15.0 passed with five +1
binding votes:

Julian Hyde
Jun Rao
Justin Mclean
P. Taylor Goetz
Furkan KAMACI

Vote thread:
https://www.mail-archive.com/general@incubator.apache.org/msg68917.html

Thank you to the above IPMC members for taking the time to review and
provide guidance on our release!

We will proceed with publishing the approved artifacts and sending out the
appropriate announcements in the coming days.

On behalf of the Apache Druid PPMC,
Jihoon

Re: [VOTE] Release Apache Druid (incubating) 0.15.0 [RC2]

[Furkan KAMACI]

+1 Binding

26 Haz 2019 Çar, saat 21:24 tarihinde P. Taylor Goetz 
şunu yazdı:

> +1 (binding)
>
> -Taylor
>
> > On Jun 19, 2019, at 10:38 PM, Jihoon Son  wrote:
> >
> > Hi IPMC,
> >
> > The Apache Druid community has voted on and approved a proposal to
> release
> > Apache Druid (incubating) 0.15.0 (rc2).
> >
> > We now kindly request the Incubator PMC members review and vote on this
> > incubator release.
> >
> > Apache Druid (incubating) is a high performance analytics data store for
> > event-driven data.
> >
> > The community voting thread can be found here:
> >
> https://lists.apache.org/thread.html/f4b1b708bcb7e6ec08e6a9cfcb2c0dfcb565fab353ccbb8c5f362218@%3Cdev.druid.apache.org%3E
> >
> > The release notes are available here:
> > https://github.com/apache/incubator-druid/issues/7854
> >
> > The release candidate has been tagged in GitHub as
> > druid-0.15.0-incubating-rc2 (44c9323), available here:
> >
> https://github.com/apache/incubator-druid/releases/tag/druid-0.15.0-incubating-rc2
> >
> > The artifacts to be voted on are located here:
> >
> https://dist.apache.org/repos/dist/dev/incubator/druid/0.15.0-incubating-rc2/
> >
> > A staged Maven repository is available for review at:
> > https://repository.apache.org/content/repositories/orgapachedruid-1007/
> >
> > Release artifacts are signed with the key [95574000]:
> > https://people.apache.org/keys/committer/jihoonson.asc
> >
> > This key and the key of other committers can also be found in the
> project's
> > KEYS file here:
> > https://dist.apache.org/repos/dist/release/incubator/druid/KEYS
> >
> > As part of the validation process, the release artifacts can be generated
> > from source by running:
> > mvn clean install -Papache-release,dist
> >
> > The RAT license check can be run from source by:
> > mvn apache-rat:check -Prat
> >
> > This vote will be open for at least 72 hours. The vote will pass if a
> > majority of at least three +1 IPMC votes are cast.
> >
> > [ ] +1 Release this package as Apache Druid (incubating) 0.15.0
> > [ ]  0 I don't feel strongly about it, but I'm okay with the release
> > [ ] -1 Do not release this package because...
> >
> > Thank you IPMC! We appreciate your efforts in helping the Apache Druid
> > community to validate this release.
> >
> > On behalf of the Apache Druid PPMC,
> > Jihoon
> >
> > Apache Druid (incubating) is an effort undergoing incubation at The
> Apache
> > Software Foundation (ASF), sponsored by the Apache 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.
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Release Apache Druid (incubating) 0.15.0 [RC2]

[P. Taylor Goetz]

+1 (binding)

-Taylor

> On Jun 19, 2019, at 10:38 PM, Jihoon Son  wrote:
> 
> Hi IPMC,
> 
> The Apache Druid community has voted on and approved a proposal to release
> Apache Druid (incubating) 0.15.0 (rc2).
> 
> We now kindly request the Incubator PMC members review and vote on this
> incubator release.
> 
> Apache Druid (incubating) is a high performance analytics data store for
> event-driven data.
> 
> The community voting thread can be found here:
> https://lists.apache.org/thread.html/f4b1b708bcb7e6ec08e6a9cfcb2c0dfcb565fab353ccbb8c5f362218@%3Cdev.druid.apache.org%3E
> 
> The release notes are available here:
> https://github.com/apache/incubator-druid/issues/7854
> 
> The release candidate has been tagged in GitHub as
> druid-0.15.0-incubating-rc2 (44c9323), available here:
> https://github.com/apache/incubator-druid/releases/tag/druid-0.15.0-incubating-rc2
> 
> The artifacts to be voted on are located here:
> https://dist.apache.org/repos/dist/dev/incubator/druid/0.15.0-incubating-rc2/
> 
> A staged Maven repository is available for review at:
> https://repository.apache.org/content/repositories/orgapachedruid-1007/
> 
> Release artifacts are signed with the key [95574000]:
> https://people.apache.org/keys/committer/jihoonson.asc
> 
> This key and the key of other committers can also be found in the project's
> KEYS file here:
> https://dist.apache.org/repos/dist/release/incubator/druid/KEYS
> 
> As part of the validation process, the release artifacts can be generated
> from source by running:
> mvn clean install -Papache-release,dist
> 
> The RAT license check can be run from source by:
> mvn apache-rat:check -Prat
> 
> This vote will be open for at least 72 hours. The vote will pass if a
> majority of at least three +1 IPMC votes are cast.
> 
> [ ] +1 Release this package as Apache Druid (incubating) 0.15.0
> [ ]  0 I don't feel strongly about it, but I'm okay with the release
> [ ] -1 Do not release this package because...
> 
> Thank you IPMC! We appreciate your efforts in helping the Apache Druid
> community to validate this release.
> 
> On behalf of the Apache Druid PPMC,
> Jihoon
> 
> Apache Druid (incubating) is an effort undergoing incubation at The Apache
> Software Foundation (ASF), sponsored by the Apache 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.


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

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

[Ted Dunning]

This comment by Craig is the most important one in the discussion.

When the first words that people pick when disagreeing are essentially
personal insults, what is going on is better described as mud wrestling
rather than discussion.

On Thu, Jun 20, 2019 at 5:01 AM Craig Russell  wrote:

> ...
>
> Well, I strongly disagree with the characterization of the process as
> nonsensical.
>
> And I would like to suggest that words like these:
>
> Ridiculous
> Specious
> Bullied
> Foolish
> Nonsensical
>
> Do Not Help with civil discourse. I understand your passion on the subject
> but I'd like you to disagree without using such language.
>
> Craig
>
> > -g
>
> Craig L Russell
> c...@apache.org
>
>

Re: [VOTE] Apache Tuweni 0.8.0

[Greg Stein]

Insanity.

Just let Tuweni make a release, already. Stuff like this will get fixed
eventually.


On Wed, Jun 26, 2019 at 10:46 AM Justin Mclean 
wrote:

> Hi,
>
> > It may not be clear to you, but it was discussed in the earlier vote
> thread. See
> https://lists.apache.org/thread.html/2b5fed22493e954937405cfd2553d06c00e5bee3b76be06b18b74862@%3Cdev.tuweni.apache.org%3E
> for my noticing the jar still being present.
>
> Noting its present and clearly indicating what the podlings future
> responsibility is in regards to this are perhaps seperate things. This is
> not a minor issue. I hope the podling realises this is the first time that
> a IPMC release with compiled code of this magnitude has been approved. A
> recent thread on legal would suggest that this should not be allowed due to
> licensing issues (even if we allow jars in source releases), and the thread
> on infra makes this the IPMC responsibility. I’ll leave it up the the PPMC
> and the mentors to consider the implications of that. In all previous IPMC
> votes that would of resulted in one or more -1 votes being cast and the
> podling asked to make another release candidate, especially considering
> that this was a issue that has occurred in a previous release candidate.
> Apache makes open source software, having a release with compiled code it
> it is not open source software and is against one of the core values of
> what we do.
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Apache Tuweni 0.8.0

[Justin Mclean]

Hi,

> It may not be clear to you, but it was discussed in the earlier vote thread. 
> See 
> https://lists.apache.org/thread.html/2b5fed22493e954937405cfd2553d06c00e5bee3b76be06b18b74862@%3Cdev.tuweni.apache.org%3E
>  for my noticing the jar still being present.

Noting its present and clearly indicating what the podlings future 
responsibility is in regards to this are perhaps seperate things. This is not a 
minor issue. I hope the podling realises this is the first time that a IPMC 
release with compiled code of this magnitude has been approved. A recent thread 
on legal would suggest that this should not be allowed due to licensing issues 
(even if we allow jars in source releases), and the thread on infra makes this 
the IPMC responsibility. I’ll leave it up the the PPMC and the mentors to 
consider the implications of that. In all previous IPMC votes that would of 
resulted in one or more -1 votes being cast and the podling asked to make 
another release candidate, especially considering that this was a issue that 
has occurred in a previous release candidate. Apache makes open source 
software, having a release with compiled code it it is not open source software 
and is against one of the core values of what we do.

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

Re: [VOTE] Apache Tuweni 0.8.0

[Dave Fisher]

Sent from my iPhone

> On Jun 26, 2019, at 6:17 AM, Justin Mclean  wrote:
> 
> Hi,
> 
>> Going only by past experiences in the incubator, my understanding is that a
>> graduation blocking issue is not something that necessarily blocks a
>> podling release.
> 
> And I was not stating that, nor has anyone voted -1 on this release. I was 
> just pointing out that this doesn’t seem to have been made clear to this 
> podling.

It may not be clear to you, but it was discussed in the earlier vote thread. 
See 
https://lists.apache.org/thread.html/2b5fed22493e954937405cfd2553d06c00e5bee3b76be06b18b74862@%3Cdev.tuweni.apache.org%3E
 for my noticing the jar still being present.

Regards,
Dave
> 
>> It would be something that should be noted and fixed in follow up releases
>> for sure.
> 
> This is not their first release or the first time this issue has occurred in 
> their releases.
> 
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

Re: [VOTE] Apache Tuweni 0.8.0

[larry mccay]

It wasn't clear to me whether you were waiting for infra before issuing a
-1 - sorry to have read too much into that.

AFAIK - this is indeed still a first Apache release for Tuweni - not the
first attempt but I don't believe that 0.7.0 was successfully voted to
release.
The change of the release number does make that unclear though.

Thanks for the clarification on your intentions with that note, Justin.

On Wed, Jun 26, 2019 at 9:17 AM Justin Mclean 
wrote:

> Hi,
>
> > Going only by past experiences in the incubator, my understanding is
> that a
> > graduation blocking issue is not something that necessarily blocks a
> > podling release.
>
> And I was not stating that, nor has anyone voted -1 on this release. I was
> just pointing out that this doesn’t seem to have been made clear to this
> podling.
>
> > It would be something that should be noted and fixed in follow up
> releases
> > for sure.
>
> This is not their first release or the first time this issue has occurred
> in their releases.
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Apache Tuweni 0.8.0

[Justin Mclean]

Hi,

> Going only by past experiences in the incubator, my understanding is that a
> graduation blocking issue is not something that necessarily blocks a
> podling release.

And I was not stating that, nor has anyone voted -1 on this release. I was just 
pointing out that this doesn’t seem to have been made clear to this podling.

> It would be something that should be noted and fixed in follow up releases
> for sure.

This is not their first release or the first time this issue has occurred in 
their releases.

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

Re: [VOTE] Apache Tuweni 0.8.0

[larry mccay]

Going only by past experiences in the incubator, my understanding is that a
graduation blocking issue is not something that necessarily blocks a
podling release.
It would be something that should be noted and fixed in follow up releases
for sure.
Perhaps the letter of the law change or the level of enforcement has
changed since then.

Now, whether those experiences were to the letter of the law or not, I
believe that (especially the first) release from a podling is intended to
make sure that the mechanics of creating an Apache release are understood.

I do think that the mechanics are in order here and would expect that this
should be able to move forward with a JIRA to fix in a follow up release.



On Wed, Jun 26, 2019 at 12:44 AM Justin Mclean 
wrote:

> Hi,
>
> I also find int a little odd that in the discussion on this release it was
> not clearly pointed out that having compiled code in the source release is
> a graduation blocking issue and that as a TLP this would not be allowed in
> a release, especially given that the exact same issue occurred in the
> previous release. Now it may be at some point policy will change and allow
> this, but currently it doesn’t.
>
> I’ve asked on users@infra if infra will allow this release, and in
> general releases like this. [1]
>
> Thanks,
> Justin
>
> 1.
> https://lists.apache.org/thread.html/a9d158ba394de3ac23204c4b7cd7e377271eb24035a38ee137a54786@%3Cusers.infra.apache.org%3E
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>