Re: [DISCUSSION] Move PAX projects to Apache Karaf ?

[Achim Nierbeck]

Hi,

I'm sorry to be a PITA :)
What I've read so far has been feelings, one concern of perception by "big"
customers.
I would really like to know, which problem we are trying to solve by moving
the pax projects under the umbrella of Karaf.
Or what I personally would favor under their own tlp of the ASF.

Just to clarify, I'm trying the 5 W's here ...
Why do you think it's a good idea to move the Pax Projects under the karaf
umbrella?
Why do you think customers have a wrong perception of the Pax Projects ...
and so on ...


What is the core issue we are trying to solve here?
As long as I don't get down to the core thing that needs to be solved I'm
not in favor of moving the pax projects anywhere.

Again sorry if I'm PITA.

regards, Achim



Am Do., 24. Feb. 2022 um 22:44 Uhr schrieb Eric Lilja :

> Personally, I would love to see this change and the other people in my
> organization liked the proposal as well.
>
> - Eric L
>
> On Thu, Feb 24, 2022 at 3:04 PM Jean-Baptiste Onofré 
> wrote:
>
> > Hi guys,
> >
> > Some of you already pinged me to share concerns about PAX projects
> > governance. I think it's my duty to share these concerns and discuss
> > possible actions.
> >
> > Apache Karaf is one of the biggest consumers of PAX projects.
> >
> > However, PAX projects use a "self own" designed governance:
> > - for contribution/IP
> > - for release
> > - for CVE/Security
> > - ...
> >
> > And it could be seen as a major concern for Apache Karaf users, as PAX
> > projects are not necessarily "aligned" with Apache Foundation rules.
> >
> > I would like to start a discussion on both Karaf and OPS4J communities
> > to "move" PAX projects as Karaf subproject (like karaf-pax).
> > Concretely, it would mean that:
> > 1. Karaf PAX projects would use org.apache.karaf.pax namespace
> > 2. Karaf PAX releases will have to follow the Apache release process
> > (binding votes, 3 days vote period, ...)
> > 3. Any active contributor on PAX projects would be invited as Karaf
> > committer
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
>


-- 

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

Re: [DISCUSSION] Move PAX projects to Apache Karaf ?

[Eric Lilja]

Personally, I would love to see this change and the other people in my
organization liked the proposal as well.

- Eric L

On Thu, Feb 24, 2022 at 3:04 PM Jean-Baptiste Onofré 
wrote:

> Hi guys,
>
> Some of you already pinged me to share concerns about PAX projects
> governance. I think it's my duty to share these concerns and discuss
> possible actions.
>
> Apache Karaf is one of the biggest consumers of PAX projects.
>
> However, PAX projects use a "self own" designed governance:
> - for contribution/IP
> - for release
> - for CVE/Security
> - ...
>
> And it could be seen as a major concern for Apache Karaf users, as PAX
> projects are not necessarily "aligned" with Apache Foundation rules.
>
> I would like to start a discussion on both Karaf and OPS4J communities
> to "move" PAX projects as Karaf subproject (like karaf-pax).
> Concretely, it would mean that:
> 1. Karaf PAX projects would use org.apache.karaf.pax namespace
> 2. Karaf PAX releases will have to follow the Apache release process
> (binding votes, 3 days vote period, ...)
> 3. Any active contributor on PAX projects would be invited as Karaf
> committer
>
> Thoughts ?
>
> Regards
> JB
>

Re: [DISCUSSION] Move PAX projects to Apache Karaf ?

[Robert Varga]

On 24/02/2022 16:48, Jean-Baptiste Onofré wrote:

Hi Achim

Just wanted to share concerns I received. Basically, PAX projects are
"free fields", without strong guarantee in the release (not formal
staging/vote/review).

It doesn't mean we don't do that, it's just not strongly enforced;)


Hello,

I think this is a matter of perception and communication.

As a downstream of a number of ASF projects as well being a committer of 
a number under-staffed FOSS project myself, I can see only one benefit 
here -- which is migration of issues to ASF JIRA.


None of the technical details will change, nor will responsiveness, nor 
the release cadence/quality, really -- unless Karaf committers actually 
take interest in that codebase. Those aspects are driven by community 
participants and not by the umbrella under which the project operates.


I have two examples for ASF projects:

1. https://issues.apache.org/jira/browse/ARIES-1826 has been sitting 
there for better part of three years without a release


2. SSHD is very responsive, with people rotating, but it is at ~6 months 
release cadence and those releases have caused regressions in the past 
-- i.e. as a downstream we had to hold back and/or apply workarounds 
like 
https://github.com/opendaylight/netconf/commit/f25f45ff27c8a7c7df780df609ec33f6662ea61e#diff-15197c97491b43d179750a5b8ea9ab1f141373544171185da9170a773faee414R21


So, with due respect to whoever has that concerns, my message is clear: 
changing governance and/or the umbrella will not address them. Boots on 
the ground will.


Regards,
Robert


OpenPGP_signature
Description: OpenPGP digital signature

Re: [DISCUSSION] Move PAX projects to Apache Karaf ?

[Łukasz Dywicki]

Hi Jean, hello ops4j participants.

Given recent rush hours with log4j issues I can understand some of the 
concerns. However, looking at practical aspects, these issues were 
handled as good as they would be at the ASF. Time it took Grzegorz to 
release updated pax-logging was pretty short.


If people are concerned about maintenance or governance of ops4j 
projects they can/should share their concerns. So far we have just one 
statement from Matt and literally 0 of the security related comments 
prior this thread. It doesn't make a very solid justification for any 
moves in this area yet, especially that all known security issues seem 
to be covered.


Best,
Łukasz

On 24.02.2022 16:48, Jean-Baptiste Onofré wrote:

Hi Achim

Just wanted to share concerns I received. Basically, PAX projects are
"free fields", without strong guarantee in the release (not formal
staging/vote/review).

It doesn't mean we don't do that, it's just not strongly enforced ;)

I don't mean we *have to* do it, I'm just sharing comments that I got.

Regards
JB

On Thu, Feb 24, 2022 at 4:43 PM 'Achim Nierbeck' via OPS4J
 wrote:


Hi JB,

Before I come to any conclusion, I would really like to understand what kind of 
issue/problem you would like to solve with this, which is easier to solve under 
an apache umbrella.

thanks, Achim

Am Do., 24. Feb. 2022 um 15:04 Uhr schrieb Jean-Baptiste Onofré 
:


Hi guys,

Some of you already pinged me to share concerns about PAX projects
governance. I think it's my duty to share these concerns and discuss
possible actions.

Apache Karaf is one of the biggest consumers of PAX projects.

However, PAX projects use a "self own" designed governance:
- for contribution/IP
- for release
- for CVE/Security
- ...

And it could be seen as a major concern for Apache Karaf users, as PAX
projects are not necessarily "aligned" with Apache Foundation rules.

I would like to start a discussion on both Karaf and OPS4J communities
to "move" PAX projects as Karaf subproject (like karaf-pax).
Concretely, it would mean that:
1. Karaf PAX projects would use org.apache.karaf.pax namespace
2. Karaf PAX releases will have to follow the Apache release process
(binding votes, 3 days vote period, ...)
3. Any active contributor on PAX projects would be invited as Karaf committer

Thoughts ?

Regards
JB




--

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer & 
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

--
--
--
OPS4J - http://www.ops4j.org - op...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ops4j/CAD0r13d2v73ipZrZOD3r9oL9wtSKZj7x2dc4%2By6sWg1rRyvWow%40mail.gmail.com.

Re: [DISCUSSION] Move PAX projects to Apache Karaf ?

[Jean-Baptiste Onofré]

Hi Achim

Just wanted to share concerns I received. Basically, PAX projects are
"free fields", without strong guarantee in the release (not formal
staging/vote/review).

It doesn't mean we don't do that, it's just not strongly enforced ;)

I don't mean we *have to* do it, I'm just sharing comments that I got.

Regards
JB

On Thu, Feb 24, 2022 at 4:43 PM 'Achim Nierbeck' via OPS4J
 wrote:
>
> Hi JB,
>
> Before I come to any conclusion, I would really like to understand what kind 
> of issue/problem you would like to solve with this, which is easier to solve 
> under an apache umbrella.
>
> thanks, Achim
>
> Am Do., 24. Feb. 2022 um 15:04 Uhr schrieb Jean-Baptiste Onofré 
> :
>>
>> Hi guys,
>>
>> Some of you already pinged me to share concerns about PAX projects
>> governance. I think it's my duty to share these concerns and discuss
>> possible actions.
>>
>> Apache Karaf is one of the biggest consumers of PAX projects.
>>
>> However, PAX projects use a "self own" designed governance:
>> - for contribution/IP
>> - for release
>> - for CVE/Security
>> - ...
>>
>> And it could be seen as a major concern for Apache Karaf users, as PAX
>> projects are not necessarily "aligned" with Apache Foundation rules.
>>
>> I would like to start a discussion on both Karaf and OPS4J communities
>> to "move" PAX projects as Karaf subproject (like karaf-pax).
>> Concretely, it would mean that:
>> 1. Karaf PAX projects would use org.apache.karaf.pax namespace
>> 2. Karaf PAX releases will have to follow the Apache release process
>> (binding votes, 3 days vote period, ...)
>> 3. Any active contributor on PAX projects would be invited as Karaf committer
>>
>> Thoughts ?
>>
>> Regards
>> JB
>
>
>
> --
>
> Apache Member
> Apache Karaf  Committer & PMC
> OPS4J Pax Web  Committer & 
> Project Lead
> blog 
> Co-Author of Apache Karaf Cookbook 
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - op...@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups 
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to ops4j+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/ops4j/CAD0r13d2v73ipZrZOD3r9oL9wtSKZj7x2dc4%2By6sWg1rRyvWow%40mail.gmail.com.

Re: [DISCUSSION] Move PAX projects to Apache Karaf ?

[Achim Nierbeck]

Hi JB,

Before I come to any conclusion, I would really like to understand what
kind of issue/problem you would like to solve with this, which is easier to
solve under an apache umbrella.

thanks, Achim

Am Do., 24. Feb. 2022 um 15:04 Uhr schrieb Jean-Baptiste Onofré <
j...@nanthrax.net>:

> Hi guys,
>
> Some of you already pinged me to share concerns about PAX projects
> governance. I think it's my duty to share these concerns and discuss
> possible actions.
>
> Apache Karaf is one of the biggest consumers of PAX projects.
>
> However, PAX projects use a "self own" designed governance:
> - for contribution/IP
> - for release
> - for CVE/Security
> - ...
>
> And it could be seen as a major concern for Apache Karaf users, as PAX
> projects are not necessarily "aligned" with Apache Foundation rules.
>
> I would like to start a discussion on both Karaf and OPS4J communities
> to "move" PAX projects as Karaf subproject (like karaf-pax).
> Concretely, it would mean that:
> 1. Karaf PAX projects would use org.apache.karaf.pax namespace
> 2. Karaf PAX releases will have to follow the Apache release process
> (binding votes, 3 days vote period, ...)
> 3. Any active contributor on PAX projects would be invited as Karaf
> committer
>
> Thoughts ?
>
> Regards
> JB
>


-- 

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

Re: [DISCUSSION] Move PAX projects to Apache Karaf ?

[Łukasz Dywicki]

I am not sure if concerns about PAX projects are fully justified, simply 
because they are being released and still worked on. While team of 
people working on it have shrunk over time, I haven't had any troubles 
with them for long time.
The contribution regulation is not an issue. It does work as for every 
other small project hosted at github, license is ASLv2 so each pull 
request (in theory) is inline with it.


I agree that our dependency chain strongly rely on PAX releases and 
there were parts which had to be first released in PAX in order to get 
next major release of Karaf. I think we need to answer ourselves a basic 
question - does moving PAX into ASF will:

a) ease already easy contribution path for it
b) increase pool of people working on it
c) speed up already fast release cycle of it?
I don't think that any of above points will change since contributing to 
non-apache projects was in the past easier. Not sure for nowadays as we 
got git and can have pull requests accepted directly at github, but 
still - what is an advantage for the community here?


From legal perspective I think moving these components a a whole into 
Karaf will not fly without making some IP clearance first. Even if PAX 
projects are libraries/components they have a whole bunch of code which 
can't be copied just because we like to host it at ASF, isn't it?
Another point is that Karaf itself become pretty fat so I'd rather think 
of chunking Karaf into smaller parts than pushing more stuff into it. 
Looking at Karaf source tree it looks as big as servicemix 4 at its 
early days; difference is - we have less people working on Karaf than on 
servicemix before. At least according to own observations.


Best,
Łukasz

On 24.02.2022 15:03, Jean-Baptiste Onofré wrote:

Hi guys,

Some of you already pinged me to share concerns about PAX projects
governance. I think it's my duty to share these concerns and discuss
possible actions.

Apache Karaf is one of the biggest consumers of PAX projects.

However, PAX projects use a "self own" designed governance:
- for contribution/IP
- for release
- for CVE/Security
- ...

And it could be seen as a major concern for Apache Karaf users, as PAX
projects are not necessarily "aligned" with Apache Foundation rules.

I would like to start a discussion on both Karaf and OPS4J communities
to "move" PAX projects as Karaf subproject (like karaf-pax).
Concretely, it would mean that:
1. Karaf PAX projects would use org.apache.karaf.pax namespace
2. Karaf PAX releases will have to follow the Apache release process
(binding votes, 3 days vote period, ...)
3. Any active contributor on PAX projects would be invited as Karaf committer

Thoughts ?

Regards
JB

[DISCUSSION] Move PAX projects to Apache Karaf ?

[Jean-Baptiste Onofré]

Hi guys,

Some of you already pinged me to share concerns about PAX projects
governance. I think it's my duty to share these concerns and discuss
possible actions.

Apache Karaf is one of the biggest consumers of PAX projects.

However, PAX projects use a "self own" designed governance:
- for contribution/IP
- for release
- for CVE/Security
- ...

And it could be seen as a major concern for Apache Karaf users, as PAX
projects are not necessarily "aligned" with Apache Foundation rules.

I would like to start a discussion on both Karaf and OPS4J communities
to "move" PAX projects as Karaf subproject (like karaf-pax).
Concretely, it would mean that:
1. Karaf PAX projects would use org.apache.karaf.pax namespace
2. Karaf PAX releases will have to follow the Apache release process
(binding votes, 3 days vote period, ...)
3. Any active contributor on PAX projects would be invited as Karaf committer

Thoughts ?

Regards
JB

[ANN] Pax Logging 2.1.1, 2.0.16, 1.12.1 and 1.11.15 released (4 versions)

[Grzegorz Grzybek]

Hello

I'd like to announce the release of 4 Pax Logging versions with two version
updates:

   - SLF4J 1.7.36 (not much affecting Pax Logging - just a version update)
   - Reload4J 1.2.19 (aligning to latest upstream version) in 1.11.15 and
   2.0.16 (the 1.12.x and 2.1.x branches do not contain log4j1 backend)

And two improvements:

   - Allowing Log4j2's JsonTemplateLayout (JSON without Jackson)
   - "org.ops4j.pax.logging.eventAdminEnabled" system/context property that
   allows disabling of EventAdmin integration - even if EventAdmin is
   mandatory in org.osgi.service.log specification (if available), it greatly
   affects performance (even on async logging), so this property should
   increase performance. See the github issue[1]


All the release notes can be found using the following links:

   - 2.1.1:
   https://github.com/ops4j/org.ops4j.pax.logging/milestone/85?closed=1
   - 2.0.16:
   https://github.com/ops4j/org.ops4j.pax.logging/milestone/88?closed=1
   - 1.12.1:
   https://github.com/ops4j/org.ops4j.pax.logging/milestone/90?closed=1
   - 1.11.15:
   https://github.com/ops4j/org.ops4j.pax.logging/milestone/89?closed=1

kind regards
Grzegorz Grzybek
===
[1]: https://github.com/ops4j/org.ops4j.pax.logging/issues/480