Fossbytes: The Linux Foundation Announces CHIPS Alliance To Open-source Chip Designs

[Kevin A. McGrail]

I thought this was interesting regarding discussions about ASLv2 and
hardware:

Fossbytes: The Linux Foundation Announces CHIPS Alliance To Open-source
Chip Designs.
https://fossbytes.com/linux-foundation-announces-chips-alliance/

[ANNOUNCE] Release Apache NetBeans (incubating) parent pom 1

[Eric Barboni]

The Apache NetBeans (incubating) team is pleased to announce the release of
Apache NetBeans (incubating) parent pom, version 1

 

Apache NetBeans (incubating) parent pom is intended for use in the Apache
NetBeans (incubating) maven project and to be parent for the Apache NetBeans
(incubating) Maven artefacts

 

You should specify the version in your project as parent like the following:

 



   org.apache.netbeans

   netbeans-parent

   1



 

You can download the appropriate sources etc. from the download page:

http://netbeans.apache.org/download/maven/

 

Release Notes 

 This is an initial release

it contains specific mailing list, issue management of Apache NetBeans
(incubating) project

 

Best Regards

The Apache NetBeans (incubating) team

 

*Disclaimer*

 

Apache NetBeans (incubating) is an effort undergoing incubation at The

Apache Software Foundation (ASF), sponsored by the name of Apache

Incubator PMC. 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.

Re: [VOTE] introduce "[DISCUSS]" threads for podling releases

[Myrle Krantz]

Hey Bertrand,

On Wed, Mar 13, 2019 at 10:54 AM Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:

> Ok, if it's specific about non-ASF releases it should be named like that
> IMO.
>

There have been discussions about keeping ASF release votes inside the
podlings lists.  If one of those proposals gets accepted, I want to include
those releases in this service offering.


> [DISCUSS] threads have existed forever.
>

Yes they have been.  But in practice they are not being used for releases.

Best,
Myrle

Re: [VOTE] introduce "[DISCUSS]" threads for podling releases

[Bertrand Delacretaz]

On Wed, Mar 13, 2019 at 10:18 AM Myrle Krantz  wrote:
> ...What's different than now is that rather than pretending non-ASF releases
> don't exist, we are offering podlings the opportunity to use them to learn
> and prepare for ASF releases

Ok, if it's specific about non-ASF releases it should be named like that IMO.

[DISCUSS] threads have existed forever.

If the new thing is to encourage podlings to discuss non-ASF releases
instead of doing them in their own corner, why not. But it shouldn't
make it appear as we are encouraging such releases - they are useful
in some case, for transitions, but not really useful towards
graduating which is our goal.

Anyway...if there's a majority for going the way you suggest, I won't
stand in the way.

-Bertrand

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

Re: [VOTE] introduce "[DISCUSS]" threads for podling releases

[Myrle Krantz]

On Wed, Mar 13, 2019 at 10:09 AM Lars Francke 
wrote:

> Just one question: Where/how do you plan on documenting this?
>

I don't know yet: I will look for an appropriate place and ask for
feedback.  Do you have a good idea?

Best,
Myrle

Re: [VOTE] introduce "[DISCUSS]" threads for podling releases

[Myrle Krantz]

Hey Betrand! : o)

I totally agree that we don't need more rules.  Here's the original discuss
thread:
https://lists.apache.org/thread.html/3c4c8473f6733ad243b748398b25f3ef614aab32aa264216eeaa0695@


Specifically:
"It's not a rule. It's an offering of an additional service + an
incremental reduction in stringency of the incubator."

What's different than now is that rather than pretending non-ASF releases
don't exist, we are offering podlings the opportunity to use them to learn
and prepare for ASF releases.

Best,
Myrle

On Wed, Mar 13, 2019 at 10:04 AM Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:

> Hi Myrle,
>
> On Tue, Mar 12, 2019 at 6:27 PM Myrle Krantz  wrote:
> > ..."Podlings should be able to request feedback by starting a "[DISCUSS]"
> > thread or a "[VOTE]" thread
>
> Sorry that I didn't catch this at the discussion stage, but what is
> new in this proposal compared to now?
>
> Anyone can start a [DISCUSS] thread around anything including a release.
>
> We might write recommendations or examples of how to use such threads,
> but I don't think we need more rules.
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] introduce "[DISCUSS]" threads for podling releases

[Lars Francke]

+1 (binding)

Just one question: Where/how do you plan on documenting this?

On Wed, Mar 13, 2019 at 9:53 AM Furkan KAMACI 
wrote:

> Hi,
>
> +1 from me too!
>
> Kind Regards,
> Furkan KAMACI
>
> On Wed, Mar 13, 2019 at 11:50 AM 吴晟 Sheng Wu  wrote:
>
> > > Amendment:
> > > "A non-ASF release
> > > * May or may not be staged on ASF infrastructure for the purposes of a
> > > vote, but it is distributed via non-ASF infrastructure, AND
> > > * Is either not linked from a podling's website, or is linked but
> clearly
> > > marked as a non-ASF release.”
> >
> >
> > +1 (binding) from me. Make sense.
> >
> >
> > --
> > Sheng Wu
> > Apache SkyWalking, ShardingSphere, Zipkin
> > Twitter, wusheng1108
> >
> >
> >
> >
> >
> >
> >
> > -- Original --
> > From:  "justin";
> > Date:  Wed, Mar 13, 2019 04:41 PM
> > To:  "general";
> >
> > Subject:  Re: [VOTE] introduce "[DISCUSS]" threads for podling releases
> >
> >
> >
> > Hi,
> >
> > +1 (binding)
> >
> > > Amendment:
> > > "A non-ASF release
> > > * May or may not be staged on ASF infrastructure for the purposes of a
> > > vote, but it is distributed via non-ASF infrastructure, AND
> > > * Is either not linked from a podling's website, or is linked but
> clearly
> > > marked as a non-ASF release.”
> >
> > Sounds reasonable to me, thanks for updating it.
> >
> > Thanks,
> > Justin
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
>

Re: [VOTE] introduce "[DISCUSS]" threads for podling releases

[Bertrand Delacretaz]

Hi Myrle,

On Tue, Mar 12, 2019 at 6:27 PM Myrle Krantz  wrote:
> ..."Podlings should be able to request feedback by starting a "[DISCUSS]"
> thread or a "[VOTE]" thread

Sorry that I didn't catch this at the discussion stage, but what is
new in this proposal compared to now?

Anyone can start a [DISCUSS] thread around anything including a release.

We might write recommendations or examples of how to use such threads,
but I don't think we need more rules.

-Bertrand

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

Re: [VOTE] introduce "[DISCUSS]" threads for podling releases

[Furkan KAMACI]

Hi,

+1 from me too!

Kind Regards,
Furkan KAMACI

On Wed, Mar 13, 2019 at 11:50 AM 吴晟 Sheng Wu  wrote:

> > Amendment:
> > "A non-ASF release
> > * May or may not be staged on ASF infrastructure for the purposes of a
> > vote, but it is distributed via non-ASF infrastructure, AND
> > * Is either not linked from a podling's website, or is linked but clearly
> > marked as a non-ASF release.”
>
>
> +1 (binding) from me. Make sense.
>
>
> --
> Sheng Wu
> Apache SkyWalking, ShardingSphere, Zipkin
> Twitter, wusheng1108
>
>
>
>
>
>
>
> -- Original --
> From:  "justin";
> Date:  Wed, Mar 13, 2019 04:41 PM
> To:  "general";
>
> Subject:  Re: [VOTE] introduce "[DISCUSS]" threads for podling releases
>
>
>
> Hi,
>
> +1 (binding)
>
> > Amendment:
> > "A non-ASF release
> > * May or may not be staged on ASF infrastructure for the purposes of a
> > vote, but it is distributed via non-ASF infrastructure, AND
> > * Is either not linked from a podling's website, or is linked but clearly
> > marked as a non-ASF release.”
>
> Sounds reasonable to me, thanks for updating it.
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] introduce "[DISCUSS]" threads for podling releases

[???? Sheng Wu]

> Amendment:
> "A non-ASF release
> * May or may not be staged on ASF infrastructure for the purposes of a
> vote, but it is distributed via non-ASF infrastructure, AND
> * Is either not linked from a podling's website, or is linked but clearly
> marked as a non-ASF release.??


+1 (binding) from me. Make sense.


--
Sheng Wu
Apache SkyWalking, ShardingSphere, Zipkin
Twitter, wusheng1108


 




-- Original --
From:  "justin";
Date:  Wed, Mar 13, 2019 04:41 PM
To:  "general";

Subject:  Re: [VOTE] introduce "[DISCUSS]" threads for podling releases



Hi,

+1 (binding)

> Amendment:
> "A non-ASF release
> * May or may not be staged on ASF infrastructure for the purposes of a
> vote, but it is distributed via non-ASF infrastructure, AND
> * Is either not linked from a podling's website, or is linked but clearly
> marked as a non-ASF release.??

Sounds reasonable to me, thanks for updating it.

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

Re: [VOTE] introduce "[DISCUSS]" threads for podling releases

[Justin Mclean]

Hi,

+1 (binding)

> Amendment:
> "A non-ASF release
> * May or may not be staged on ASF infrastructure for the purposes of a
> vote, but it is distributed via non-ASF infrastructure, AND
> * Is either not linked from a podling's website, or is linked but clearly
> marked as a non-ASF release.”

Sounds reasonable to me, thanks for updating it.

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

Re: [VOTE] introduce "[DISCUSS]" threads for podling releases

[Myrle Krantz]

That seems fixable

I hereby amend the proposal with the following definition of "non-ASF
release".  If this definition is not sufficient, consider accepting the
term as currently undefined and start a discussion to create a definition
without blocking this vote:

Amendment:
"A non-ASF release
* May or may not be staged on ASF infrastructure for the purposes of a
vote, but it is distributed via non-ASF infrastructure, AND
* Is either not linked from a podling's website, or is linked but clearly
marked as a non-ASF release."

As to how I propose dealing with user confusion resulting from the
incomplete status of podlings:  This problem already exists, and it's been
discussed here for years.  I don't think that we need to solve every
problem of the incubator with this one proposal.  Independent of this
proposal, my opinion on the matter is that it shouldn't be up to the
podlings to solve it.  Podlings already have enough on their plates with
learning a new culture, building a community, getting a technology stack
set up, moving their stuff onto our infrastructure, and adjusting to a new
set of policies and procedures.  Explaining the difference between a
podling and a TLP should be the incubator's job.  And we need to accept
that it's not possible to do it perfectly.

My request now:  This proposal has been in discussion since February 26th.
Discussion had petered out.  If y'all think we need more discussion we can
do that, but please a.) *say* we need more discussion and b.) participate
in it.  Otherwise, please vote.

Best Regards,
Myrle

On Wed, Mar 13, 2019 at 12:13 AM Justin Mclean 
wrote:

> Hi,
>
> +1 to the idea in general, but +0 to it in its current form.
>
> > "Podlings should be able to request feedback by starting a "[DISCUSS]"
> > thread or a "[VOTE]" thread.  The podling can decide whether they prefer
> > [DISCUSS] or [VOTE], but only a release which passes a vote by members of
> > the IPMC is an official ASF release.
> >
> > Discussion should give podlings feedback on what they would need to do to
> > bring their release in line with the requirements of an official ASF
> > release and thus for graduation to TLP.  Podlings will be responsible for
> > capturing feedback that they accept in work items for their project.
> >
> > Feedback provided in a discussion thread will not block a non-ASF
> release.
> > Asking for feedback using this mechanism is not obligatory, but rather a
> > service that the incubator offers and podlings can take advantage of."
>
> I think this is an excellent idea but the wording re "will not block a
> non-ASF release” may need some work. (A minus one vote on a release doesn’t
> block anything as it’s not a veto, but that’s not my main concern).
>
> Let's assume for a minute that an podling make a release candidate, votes
> on it and put it up for incubator discussion. The IPMC finds it contains
> GPL licensed software and provides that feedback. What does the podling do?
> They probably can’t make this an ASF release or place in the ASF
> distribution channel or link to on their download page. to do so they would
> problem need permission from legal and infra. If they place it elsewhere
> it’s likely it will cause user confusion to what is an ASF release and what
> is not. How do you see the proposal working in this situatiion?
>
> Part of the big problem here is with distinguishing the non-ASF releases
> from the ASF ones. A lot of podlings fail to follow branding, trademark or
> distribution policy when making non-ASF releases or worse make it easy for
> users to confuse non-ASF releases with actual ASF releases and promote
> these non-ASF releases as ASF ones.
>
> > Notes on proposal:
> > * This proposal does presume that we are allowing non-ASF releases in the
> > early days of a poddling.  My understanding of the discussion of the last
> > few weeks is that this has *actually* always been allowed, but that that
> > knowledge may not have been wide spread.
>
> It’s a little more subtle than that, 3rd parties can make non-ASF
> releases, podlings (or rather the IPMC) can’t. A member of the (P)PMC can
> act as a 3rd party. This has also been used in a couple of cases to get
> around making official ASF release.
>
> Thanks,
> Justin
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Mentors and Voting on Podling Releases

[Julian Feinauer]

Hi Dave,

thanks for your feedback.
I totally agree with what you say and from all the discussions I read, I have 
the impression that there is a good direction where many IPMC members think 
this should be going and the "right" points are addressed.

Regarding the release process: We just had a discussion in a podling to do 
regular releases but agreed that to discuss the topic futher AFTER graduation 
to keep the workload for the IPMC low.
So I fully agree that we should find a way to make the release process smooth 
for both sides, especially the IPMC to allow Podlings to keep their (official) 
releases frequent (which is especially important for young projects) without 
too much work for the IPMC members.

I am mostly involved in incubating projects, thus I have a bit of a different 
perspective and will happily share my impressions in the discussion and also 
help to update docs or so to make things smoother.
So please come back to me whenever you need help on these matters.

Best
Julian

Am 12.03.19, 18:04 schrieb "Dave Fisher" :

Hi Julian -

Thanks for bringing this discussion to general@.

I think that there are two calls to action here:

(1) How can Mentors service the Podlings they have volunteered to help by 
VOTING on releases? For me the issues can be any of:
- The Release was not discussed on the dev@ list until the VOTE is called.
- 72 hours may not be enough time to find the cycles.
- I know the podling is going to call the next step on general@ and if I 
don’t have time then I can defer and VOTE later (or not.)
- I sometimes resent feeling like the only active mentor.
These are my human reasons. I am a volunteer and no one is paying me to do 
this.

(2) Documentation and guidance can be improved.
- The incubator site is mostly in Github at 
https://github.com/apache/incubator/tree/master/pages 

- PRs after discussions are welcome.

My current distraction/obsession is INCUBATOR-231 which will improve the 
site. I am looking to make a Podling’s status and issues easier to see and act 
upon.

More inline.

> On Mar 12, 2019, at 2:19 AM, Julian Feinauer 
 wrote:
> 
> Hi all,
> 
> I just wanted to bring back a short summary of a discussion we had with 
Craig Russel on a private list regarding the role of podling mentors in the 
release approval process.
> And as there are currently many thoughts and discussions going on about 
these topics, I thought it would be good to have the essence of the discussion 
public.
> 
> Basically the point was when mentors should vote. In the IPMC Vote only 
or already in the Podlings Vote.
> 
> Currently, the rules state that the approval of a podling release can 
only be given by IPMC Vote, see [1] and [2].
> Both these documents do not mention the “mentor” explicitly but only 
speak of the podling and the IPMC.
> Also, the role of the mentor does say nothing about releases [3] and 
describes the mentor (as I read it) more as a lawyer of the podling with 
regards to the IPMC (and not vice versa).
> On the other hand, with the current dimension of the incubator, there is 
a huge “load” of approvals put on the IPMC.

To me the responsibility of the Mentor is to the Podling to provide 
guidance to the podling community in how to interact with the Apache Software 
Foundation. Mentors should be able to direct the podling to the following 
committees and resources:

- Infrastructure for Resources and Release Distribution Policy
- Legal-Discuss for License interpretation and Release Policy
- Brand/Trademarks for Name Search, Logos, and Website organization. Also, 
large event approval.
- Press for announcements within the rules for podlings.
- ComDev for community information like the maturity model and help with 
events.
- Conference committee.

We should not duplicate documentation, but should point to the Foundation 
docs.

To me the Incubator is about.
- Entry of a project community - proposal
- Bootstrap by Champion and Mentors
- Watching that Podlings are making progress and helping mentors help the 
community.
- Making sure that Release and Release Distribution Policies are followed.

> 
> So I thought if it wouldn’t be possible to discuss and perhaps redefine 
the mentor role a bit with regards to release approval or voting.
> My observation is, that often times the IPMC vote consists mostly of 
votes from mentors (or PPMCs who happen to be also IPMC members) and from very 
few other IPMC members.
> I also think that this makes sense, as mentors follow the projects 
closely and can have an eye on the specifics of the project and have a strong 
relation to the project which makes them decide to vote for the project.

Mentors also need to encourage discussion on the dev@ list,