Re: Podlings not following ASF release policy

[Daniel Gruno]

On 2/9/19 8:50 AM, Justin Mclean wrote:

HI,


 From what I can see with httpd, the issue is the same(?)


Not quite as I not see any release candidates listed.


ah, well, httpd doesn't do release candidates :p we tag a release, vote 
on it, if it fails, you burn the version number and use a new one. so 
you'll see release "candidates" but just not recognize them unless you 
know which versions failed to get the proper votes.




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: Podlings not following ASF release policy

[Makoto Yui]

Justin,

Could you please tell us  what
issues exist in Hivemall?

Thanks,
Makoto

2019年2月9日(土) 9:51 Justin Mclean :
>
> Hi,
>
> So I just checked the next bunch of podlings to report to see if we have any 
> other issues with ASF releases policy and sadly we do and again it larger 
> than I expected. Some of these are minor issues and easily fixed, some are 
> not. In a couple of cases I may not of looked deeply enough into the issue 
> and it may actually be fine, if so apologies in advance for listing you here. 
> In a couple of cases (e.g. Zipkin) I can see it’s been discussed on the list 
> but there’s more to do.
>
> Podlings having one or more issues with ASF release policy include:
> - Crail
> - Daffodil
> - Dlab
> - Druid
> - Dubbo
> - Hivemall
> - Marvin-ai
> - Memo
> - Omid
> - Openwhisk
> - Pinot
> - Ponymail
> - Singa
> - Skywalking
> - Zipkin
>
> Projects that I will be following up with include Dlab, Druid, Dubbo, 
> Openwhisk, Singa, Skywalking and Zipkin.
>
> If you are the mentors of these projects please take a look and see what you 
> can do to improve the situation and educate your podling on proper release 
> policy. If you can’t find the issue ping me and I’ll send an email with what 
> I think it is to your private list. There is probably things I’ve missed as 
> well, often were there’s one issue there’s others.
>
> Please include something in the next podling report on this.
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>


-- 
Makoto YUI 
Principal Engineer, Arm Treasure Data.
http://myui.github.io/

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

Re: Renaming repos and security concerns

[Myrle Krantz]

Thank you.  I've corrected some typos, and then added a motivation
section.  Questions/comments/suggestions, as always, welcome.

Best Regards,
Myrle

On Fri, Feb 8, 2019 at 11:59 PM Justin Mclean 
wrote:

> Hi,
>
> > We need to make sure that pre-Apache releases whether source or binary
> are treated in a fair way.
>
> As long are they are not in after the date of incubation and clearly
> marked I see no issues.
>
> > An über-comment - let’s be exceedingly careful with time limits for
> “compliance”.
>
> What do you suggest? If a podling is not following ASF release policy how
> long do we give them to fix that? IMO if the podling is dealing with it
> then all is OK, but we can’t wait for months while that is happening.
>
> > I think it would be good to finalize proposed policies from master
> copies on the wiki.
>
> Here you go. Feel free to edit. [1]
>
> Thanks,
> Justin
>
> 1. https://wiki.apache.org/incubator/DistributionGuidelines

Re: Podlings not following ASF release policy

[Daniel Gruno]

On 2/9/19 9:38 AM, Makoto Yui wrote:

Justin,

Could you please tell us  what
issues exist in Hivemall?


I'd also be interested in knowing (you may use dev@ or private@ as you 
see fit) what issues exist with pony mail and release policies :)





Thanks,
Makoto

2019年2月9日(土) 9:51 Justin Mclean :


Hi,

So I just checked the next bunch of podlings to report to see if we have any 
other issues with ASF releases policy and sadly we do and again it larger than 
I expected. Some of these are minor issues and easily fixed, some are not. In a 
couple of cases I may not of looked deeply enough into the issue and it may 
actually be fine, if so apologies in advance for listing you here. In a couple 
of cases (e.g. Zipkin) I can see it’s been discussed on the list but there’s 
more to do.

Podlings having one or more issues with ASF release policy include:
- Crail
- Daffodil
- Dlab
- Druid
- Dubbo
- Hivemall
- Marvin-ai
- Memo
- Omid
- Openwhisk
- Pinot
- Ponymail
- Singa
- Skywalking
- Zipkin

Projects that I will be following up with include Dlab, Druid, Dubbo, 
Openwhisk, Singa, Skywalking and Zipkin.

If you are the mentors of these projects please take a look and see what you 
can do to improve the situation and educate your podling on proper release 
policy. If you can’t find the issue ping me and I’ll send an email with what I 
think it is to your private list. There is probably things I’ve missed as well, 
often were there’s one issue there’s others.

Please include something in the next podling report on this.

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: Renaming repos and security concerns

[Justin Mclean]

Hi,

> Thank you.  I've corrected some typos, and then added a motivation
> section.  Questions/comments/suggestions, as always, welcome.

Thanks for edits but I think you missed the main reason, it's mostly about the 
legal umbrella and protection we give our (P)PMC’s. If they do something 
outside of what is prescribed then there are  possible consequences. See [1] 
"Deviations from this policy may have an adverse effect on the legal shield's 
effectiveness, or the insurance premiums Apache pays to protect officers and 
directors, so are strongly discouraged without prior, explicit board approval” 
While there is still a risk of someone taking legal action that’s less likely.

Thanks,
Justin

1. http://www.apache.org/legal/release-policy.html#why
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Renaming repos and security concerns

[Myrle Krantz]

I have no objections to you editing that into it.  I do however think it's
important to explain the reasons for the rules together with the rules.

Please note that I've mentioned legal jeopardy, so if you're going to
"strengthen" the language you may need to delete existing text to avoid
redundancy.  But again I have no objections to you doing that.

Best Regards,
Myrle

On Sat, Feb 9, 2019 at 2:10 PM Justin Mclean  wrote:

> Hi,
>
> > Thank you.  I've corrected some typos, and then added a motivation
> > section.  Questions/comments/suggestions, as always, welcome.
>
> Thanks for edits but I think you missed the main reason, it's mostly about
> the legal umbrella and protection we give our (P)PMC’s. If they do
> something outside of what is prescribed then there are  possible
> consequences. See [1] "Deviations from this policy may have an adverse
> effect on the legal shield's effectiveness, or the insurance premiums
> Apache pays to protect officers and directors, so are strongly discouraged
> without prior, explicit board approval” While there is still a risk of
> someone taking legal action that’s less likely.
>
> Thanks,
> Justin
>
> 1. http://www.apache.org/legal/release-policy.html#why
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Unapproved Sharding Sphere releases

[Craig Russell]

If we agree that new incubating projects have their repositories moved and not 
copied, I think it is only fair that the projects also can choose when the 
transition from "outside project" to "incubating project" occur with regard to 
releases.

I do not think it is fair to require a community coming into incubation to have 
finished all "outside project" work prior to having the vote to join the 
incubator, and to remove all releases made outside.

What I recommended to the ShardingSphere community was to delay moving the 
repository until after their final "outside project" release. Then there would 
be a definite transition point from "outside project" to "incubating project".

As the first step after the repository is moved to Apache infrastructure, the 
previous releases can be labeled "Not Apache Release" but I do not feel that it 
is fair to remove them.

Craig
Mentor, ShardingSphere

> On Feb 8, 2019, at 3:52 PM, 吴晟 Sheng Wu  wrote:
> 
> I support move than copy too. 
> Move is better, not just for keeping star, fork and watch. These are also 
> important too.
> The more important is, GitHub provides repo address auto redirect. If the 
> user or article links to the old repo, it will forward to the new one(Apache 
> one) automatically. 
> 
> 
> 
> Sheng Wu
> Apache SkyWalking, ShardingSphere, Zipkin
> 
> From Wu Sheng 's phone.
> 
> 
> -- Original --
> From: Chris Lambertus 
> Date: Sat,Feb 9,2019 4:34 AM
> To: general 
> Cc: dev 
> Subject: Re: Unapproved Sharding Sphere releases
> 
> 
> 
> 
> 
>> On Feb 7, 2019, at 1:52 PM, Dave Fisher  wrote:
>> 
>> 
>> 
>>> On Feb 7, 2019, at 1:44 PM, Craig Russell  wrote:
> 
> [snip]
> 
>>> 
>>> Larger discussion: Is there a reason for projects coming into incubation to 
>>> have the old repository moved (i.e. renamed) instead of being copied? I 
>>> cannot think of a good use case for moving versus copying. Seems like any 
>>> project that had releases and a community outside Apache would want to 
>>> copy, not move.
>> 
>> If the project is moved then all of the thousands of forks and stars are 
>> still associated with the original project. If copied then all of these will 
>> be associated with the now abandoned repository and most of those will never 
>> come along with the moving project.
>> 
>> For the Chinese projects this can mean losing thousands of users and 
>> sometime contributors to the project.
>> 
>> So, I am a MOVE and not COPY.
>> 
>> ShardingSphere has 6,633 stars and 2,363 forks plus 842 watches.
>> 
>>> 
>>> Smaller discussion: Should the JIRA have been written to request 
>>> copying/forking the project? Or is this something that is supposed to be 
>>> self-serve. I could not find a definitive answer to this.
>> 
>> Ask Infra. ASICT they move by default.
> 
> 
> We endeavor to perform move operations wherever technically possible for the 
> exact reason of retaining the stars and other metadata associated with the 
> github project. It adds a few extra steps for us, but the projects always 
> appreciate having that data retained. If we did a “copy” then there would be 
> two extant repos which would cause no end of confusion, especially for people 
> with forks and watches on the original repo.
> 
> -Chris
> ASF Infra

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org  http://db.apache.org/jdo 

Re: Renaming repos and security concerns

[Greg Stein]

Hehe... I think she just said "patches welcome" 😋

On Sat, Feb 9, 2019, 08:19 Myrle Krantz  I have no objections to you editing that into it.  I do however think it's
> important to explain the reasons for the rules together with the rules.
>
> Please note that I've mentioned legal jeopardy, so if you're going to
> "strengthen" the language you may need to delete existing text to avoid
> redundancy.  But again I have no objections to you doing that.
>
> Best Regards,
> Myrle
>
> On Sat, Feb 9, 2019 at 2:10 PM Justin Mclean  wrote:
>
> > Hi,
> >
> > > Thank you.  I've corrected some typos, and then added a motivation
> > > section.  Questions/comments/suggestions, as always, welcome.
> >
> > Thanks for edits but I think you missed the main reason, it's mostly
> about
> > the legal umbrella and protection we give our (P)PMC’s. If they do
> > something outside of what is prescribed then there are  possible
> > consequences. See [1] "Deviations from this policy may have an adverse
> > effect on the legal shield's effectiveness, or the insurance premiums
> > Apache pays to protect officers and directors, so are strongly
> discouraged
> > without prior, explicit board approval” While there is still a risk of
> > someone taking legal action that’s less likely.
> >
> > Thanks,
> > Justin
> >
> > 1. http://www.apache.org/legal/release-policy.html#why
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: Renaming repos and security concerns

[Craig Russell]

> On Feb 8, 2019, at 2:59 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>> We need to make sure that pre-Apache releases whether source or binary are 
>> treated in a fair way.
> 
> As long are they are not in after the date of incubation and clearly marked I 
> see no issues.

As I mentioned else-thread, I think the date should be the date the repository 
is moved to the Incubator, not the date the project is voted into the 
incubator. 

Craig
> 
>> An über-comment - let’s be exceedingly careful with time limits for 
>> “compliance”.
> 
> What do you suggest? If a podling is not following ASF release policy how 
> long do we give them to fix that? IMO if the podling is dealing with it then 
> all is OK, but we can’t wait for months while that is happening.
> 
>> I think it would be good to finalize proposed policies from master copies on 
>> the wiki.
> 
> Here you go. Feel free to edit. [1]
> 
> Thanks,
> Justin 
> 
> 1. https://wiki.apache.org/incubator/DistributionGuidelines

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org  http://db.apache.org/jdo 

Re: Renaming repos and security concerns

[Justin Mclean]

Hi,

> As I mentioned else-thread, I think the date should be the date the 
> repository is moved to the Incubator, not the date the project is voted into 
> the incubator. 

This seams reasonable but that not what has been happening in most cases, the 
repo get transferred and then unapproved release are made.

It may also make it hard for people outside that repo (including possibly some 
on the initial committers list) to get access if it’s under some corporations 
control.

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