Re: [QUESTION] How do Java-based projects handle Hibernate?

[Romain Manni-Bucau]

Hi Jason,

AFAIK it is ok to use it in tests while you don't reference it explicitly
in your code (which means delivering it or implementing its SPI/classes and
you don't let it be transitive in any assembly somehow) so would mean ok to
use in test while you stay under JPA API.
So it would be more JPA for the code, OpenJPA/Hibernate in tests and
OpenJPA for the runtime until you download it at runtime (like Karaf
features can do for ex).

Regards,
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 30 janv. 2023 à 20:01, Jason Porter  a
écrit :

> Question for the group, since I have seen things that seem contradictory.
> How do projects handle Hibernate since it's LGPL and as such, a Category X
> dependency?
>
> It seems like simply using the library is fine. However, then you see
> things about "linking" to the library, does simply using the classes and
> the imports mean it's included in the source?
>
> Is that allowed if we're using JPA and OpenJPA for the classes and
> Hibernate for the implementation?
>
> Along the same lines, what about test libraries?
>
> Jason Porter
> Software Engineer
> He/Him/His
>
> IBM
>
>

Re: Looking for a champion: resurrect log4j 1.x

[Romain Manni-Bucau]

I know Vladimir but let's do things in order, if we move in all ways it
will fail.
Incubating log4j1 will fail as I epxlained - not even sure incubator would
let it be incubated since project is official dead for everybody and can
only get security fixes (incubator is to ensure you can build a community
and comply to ASF, for log4j1 it is out of topic).
If current logging PMC does not want to release they will have the choice
to donate the group for an external project or let the release be done. For
that last point you need at least 3 PMC voting and if current one does not
want to do it they can always add new PMC member willing to release -
plenty are easily found, even just in this thread.

So please stick to the normal plan:

1. do the work
2. share it properly (one feature per patch/ticket, not all at once is what
I mean here ;))
3. solve the "how to release"

To be honest speaking of 3 without having 1 and 2 is pointless.

Just to push what I just said: we had the same in maven (surefire) and the
release had been done finally so back to keyboard if anyone wants it to
happen IMHO, no need to look for future issues before they are actually
actual.

Romain

Le mer. 22 déc. 2021 à 08:42, Vladimir Sitnikov 
a écrit :

> Romain,
>
> Romain>for now the thread is looking for options which are not needed from
> my window
>
> It was the Logging PMC team who suggested I should re-incubate log4j 1.x.
>
> Romain>1. where is the patch needed to fix the desired CVE? - must be
> compatible
> with current SVN trunk
>
> The current SVN trunk is NOT buildable.
> It uses outdated build tools, so build system healing
> is needed before ANY other patches.
>
> Romain>2. please attach it to a ticket
>
> I have just created https://issues.apache.org/jira/browse/LOG4J2-3272
> "Enable Git and GitHub for log4j 1.2 repository"
>
> Every patch to 1.x must be well-tested, so attaching patch files to JIRA
> is a recipe for disaster.
>
> I already asked Logging PMC to enable Git and GitHub for 1.x, and they
> rejected it:
> https://lists.apache.org/thread/ssbdg44gy7txzl16xxd097t7orco52g2
>
> I do not see why filing the same thing as JIRA would work any better than
> sending mail to dev@logging list.
>
> Vladimir
>

Re: Looking for a champion: resurrect log4j 1.x

[Romain Manni-Bucau]

ok, so let's try to not create an endless thread:

1. where is the patch needed to fix the desired CVE? - must be compatible
with current svn trunk
2. please attach it to a ticket (or multiple if there are multiple fixes)
like LOG4J2-3219
3. if it does not get applied and PMC is opposed to get it applied let's
create a thread about it as being an issue and look for options but for now
the thread is looking for options which are not needed from my window

Hope it helps ot move the ball forward

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 22 déc. 2021 à 06:24, Vladimir Sitnikov 
a écrit :

> Matt>Nobody in the Logging PMC is blocking a release here.
>
> Matt, thanks for the reply, however, it is false :(
> I see you are positive, however, many more replies were quite negative.
>
> Ralph Goers says: "We’ve stated several times that we don’t think
> resurrecting Log4j 1.x permanently is a good idea."
> https://lists.apache.org/thread/vz80p3v78xgposon3pcxbnb9729snnxt
>
> Gary Gregory says: "As I've stated before, IF there is a 1.2.18, it should
> ONLY be for CVEs,"
> https://lists.apache.org/thread/53h130p0kdkspn4kj2hq39vkgpyzgvp7
>
> They both are on Logging PMC, and they both have negative opinions on
> making progress with v1.
> I do not really understand what "ONLY be for CVEs" means (e.g. does it
> allow upgrading from Maven2 to Maven3?),
> but I do not want to get accidentally blocked by "oh, this change is not
> allowed because it is not a CVE fix".
>
> Matt>What we don’t want is to falsely advertise that v1 is still under
> development
>
> For instance, I do want to support new versions of v1.
> If Logging PMC does not want advertise v1, that is fine. Would you donate
> log4j 1.x code
> to Incubator or to another PMC?
>
> Matt>if we resurrect v1, then it’ll quickly become impossible to keep up
> with all the activity given the size of the PMC
>
> log4j v1 and log4j v2 are completely different products sharing the same
> name.
> So it won't be that surprising to have different people working on them.
>
> Adding PMC members is one of the solutions. Donating the code to another
> PMC is another solution.
>
> I agree you have an unusual traffic spike now, however, multiple members of
> Logging PMC do respond regarding v1,
> and the overall intention is "Logging PMC is not interested in v1".
>
> That is not something I want spending time on.
> If I want to get v1 CVE fixed, I want to get it done and released. I do not
> want to spend my time on "evangelizing v2, v3, or whatever".
>
> Matt>we’d prefer to see more than one person working on that,
> Matt>especially if we want to add more PMC members to oversee v1 in the
> first place
>
> Matt, this case is really unusual. Do you really want *multiple*
> individuals to *actively* contribute to log4j v1
> in order to add them to v1 PMC?
> That is impossible. There's not much work to do in v1. There's no way I can
> improve v1 code in a consistent and non-trivial way.
>
> You should not be sitting and waiting for new v1 contributions to come.
>
> So I would say it is not fair to say "there's not enough Logging PMC".
> What needs to be done to add PMC members for v1?
>
> Matt>users who haven’t bothered to upgrade in 10 years will have to end up
> paying astronomical costs
>
> There **is** possibility to maintain COBOL.
> Currently, external contributions, including CVE fixes, are literally
> blocked.
>
> Matt>Or were people still using a mix of make or Ant?
>
> People use Ant a lot, and there are new Ant releases:
> https://ant.apache.org/antnews.html
>
> Vladimir
>

Re: Looking for a champion: resurrect log4j 1.x

[Romain Manni-Bucau]

Le mar. 21 déc. 2021 à 12:33, Enrico Olivelli  a
écrit :

> Vladimir,
> I totally support this proposal.
>
> Which are actually the steps we need to cut a release of log4j 1.x ?
> - establish an Apache project ?
>

1. Send a patch to apply on
http://svn.apache.org/repos/asf/logging/log4j/trunk


> - do the fix
>

2. Get it applied


> - cut a release
>
> Can this be done inside another Apache Project who "adopts" the log4j
> sources if the Logging Project doesn't want to do it ?
>

The PMC of log4j2 is logging project so it should be done there, if not the
project can be forked inside Apache but should change of package until we
get the perms to reuse the same one which means likely as much work as just
getting it done at logging project so hope it is not needed ;).


>
> Enrico
>
>
> Il giorno mar 21 dic 2021 alle ore 08:36 Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> ha scritto:
>
> > >Just wondering, is it even fulfilling the criteria of incubation?
> >
> > I believe, the world does not need "active development in log4j 1.x"
> > nowadays.
> > What everybody needs from log4j 1.x is to fix security issues, fix
> > outstanding issues (if any),
> > keep the project buildable (e.g. avoid using outdated build systems),
> etc.
> >
> > >it doesn't seem that sustainability is proven.
> >
> > The problem is log4j 1.x is like COBOL of logging. There are apps that
> are
> > just stuck with log4j 1.x.
> > The proof of sustainability is that lots of existing apps will never
> > upgrade to 2.x because 2.x is incompatible.
> > If the compatibility layer of 2.x would be improved to handle 99.999% of
> > apps,
> > then we could indeed move 1.x to the attic.
> >
> > The Incubator Cookbook says:
> > >The ASF provides software for the public good,
> >
> > As I described, log4j 2.x is not a direct replacement for log4j 1.x, and
> > there are **lots** of applications
> > that can't easily be upgraded to 2.x due to testing, configuration, and
> > implementation issues.
> >
> > The current Logging PMC is focused on log4j 2.x only, and they have no
> > desire to release 1.x
> >
> > >active development but focus only on CVE fixes
> >
> > I would say, the primary goal of resurrecting 1.x is to focus on CVEs,
> and
> > keep the project buildable and testable.
> > However, it might be the case, that certain fixes or features would
> appear.
> >
> > The sad story is that the industry is using 1.x A LOT, and what Logging
> PMC
> > did was
> > they ignored the community, and they just stopped maintaining 1.x and
> > focused on an incompatible 2.x
> >
> > Not only do they stop maintaining 1.x, but they also deny others to pick
> up
> > the maintenance task.
> >
> > What I am trying to do now is to pick up that maintenance activity.
> >
> > Vladimir
> >
>

Re: Looking for a champion: resurrect log4j 1.x

[Romain Manni-Bucau]

Guess there are 4 options:

1. resurrect log4j1 and let it die again
2. do a log4j1 release for the CVE under logging umbrella (as a subproject)
- after all log4j1 belongs to logging as a subproject already (
https://logging.apache.org/dormant.html)
3. the log4j1-log4j2 bridge (but agree this is not a solution and requires
to do 2 to be useful technically since none of log4j1 users will want to
import log4j2, at least cause it is not compatible with java version or due
to the injected bytecode like module-info)
4. do a CVE fix release fork on github or any other hosting

Personally I don't think 1 or 3 are real options, 4 is but not that nice
indeed (due to the fact it would be yet another forks but also cause it
requires some GAV change or build hack to be done properly) so from my
window I would be tempted to push for 2 which sounds like a quick win for
everyone.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 20 déc. 2021 à 14:32, John D. Ament  a
écrit :

> Hi Vladimir,
>
> I think based on what you're describing and the Logging PMC's response,
> re-incubating the project makes sense.  I would be curious if the Logging
> PMC would be interested in restarting the sub-project after a successful
> incubation period.  This seems to match what Ralph is suggesting as well.
>
> Typically this would mean that the VP Logging PMC would serve as the
> champion, and as the sponsor the Logging PMC would still be the one to vote
> to add the project to the incubator.  If the VP Logging isn't interested in
> doing this, I would recommend starting out the project as a standalone
> podling and keeping the Incubator as sponsor rather than Logging.  See [1]
> for some details on those notes.  The incubator would be responsible for
> voting on releases, receiving notices for new PPMC members, etc regardless
> of who is the sponsor.  Given enough contributors and a diverse contributor
> base then the Incubator PMC and the Logging PMC (if they're the sponsor)
> would vote whether everyone feels the new project can be brought back to
> the Logging project.  We can also decide as it gets closer to graduation to
> move the podling into a sub-project if that's what everyone agrees.
>
> I would be up for helping you get through the incubator.  If VP Logging
> doesn't want to own the sponsorship part, I can be your Champion.
>
> John
>
>
> [1]: https://incubator.apache.org/guides/proposal.html#background
>
> On Mon, Dec 20, 2021 at 8:20 AM Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> wrote:
>
> > >Do you have "facts" (like message on mailing list) ?
> >
> > I am not sure what you mean.
> >
> > For example:
> >
> > 1) Ralph Goers says the existing committers did not touch 1.x code a lot:
> > https://lists.apache.org/thread/j6zrdp1d148qpkg0g7x3cc41o070oq6n
> > Ralph>Virtually all of the contributors to the Log4j 1.x project left a
> few
> > years before it was declared
> > Ralph>EOL. That is the primary reason it was retired. Although the
> current
> > set of committers have
> > Ralph>access to the code, none of us have ever built it
> >
> > 2) Ralph Goers (a member of Logging PMC) suggested that one of the ways
> to
> > move forward is to re-incubate log4j 1.x:
> > https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5
> >
> > This in conjunction with #1 sounds like the current logging PMC is not
> > interested in moving log4j 1.x forward.
> >
> > 3) I suggest moving log4j 1.x to Git, and nobody from PMC approves the
> > change;
> > Gary Gregory (a member of Logging PMC) votes with -1 (binding):
> > https://lists.apache.org/thread/y89v84okzs76g2yl760vx5yc0w1y4yd8
> >
> > 4) Both Gary and Mike push for "improving log4j 1->2 compatibility
> layer":
> > https://lists.apache.org/thread/hq2m11f1w9yp031r5f65b9h4ym2zy1kc
> > https://lists.apache.org/thread/tw172svxt1q6wds7lt9szyjw2sxjf34n
> >
> > I understand that log4j2 team might want everybody to upgrade to 2.x,
> > however, that is not possible since the apps would need significant
> > regression testing,
> > the compatibility layer is far from perfect, and so on.
> > Many apps are fine with 1.x, and they do not need 2.x features.
> > There's no reason to upgrade, so I am not interested in investing time in
> > improving
> > the compatibility layer.
> >
> > Is it what you ask?
> >
> > Vladimir
> >
>

Re: JPMS Projects?

[Romain Manni-Bucau]

Hi,

If it helps, JPMS has still a lot of blockers IMHO, as soon as you quit
unamed module land you break most frameworks out there.
If your lib is a standalone functional set of utilities it can not be
bothering but if you use any reflection or meta programming I would
recommend to stick to unamed module by default until you are required to go
with jpms.
Only feature JPMS has, as of today, is being able to build jvm images and
graalvm kind of killed this features by making it irrelevant (I skip the
licensing issues it can create ;)).

My 2 cts,
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 18 mars 2021 à 15:25, Serge Huber  a écrit :

> I was also going to mention OSGi. It enforces better lifecycle management
> than JPMS. If you can do it with OSGi you can certainly use it with JPMS
>
> Regards,
>   Serge...
>
> On Thu, Mar 18, 2021 at 3:19 PM Matt Sicker  wrote:
>
> > Perhaps the various OSGi-related projects here might be similar to what
> > you’re looking for since those have enforced modularity for a long time.
> > That module system is more advanced than JPMS, but the concepts are
> fairly
> > similar.
> >
> > We’ve also been looking into this for log4j 3.0, but that’s not out yet.
> >
> > On Thu, Mar 18, 2021 at 01:06 Daniel Widdis  wrote:
> >
> > > After considering this email I wrote, I regret sending it and want to
> > > apologize if I have overstepped any bounds.
> > >
> > > I am not a member of the IPMC or associated in any formal way with
> Apache
> > > and am certainly not in any position to make any judgments regarding
> code
> > > quality or your wise choice to begin your search with such projects.
> > >
> > > I'll back out of this conversation now and let others answer or
> redirect
> > > you to other resources.
> > >
> > > Dan
> > >
> > >
> > > On 3/17/21, 10:21 PM, "Daniel Widdis"  wrote:
> > >
> > > Thanks for your clarifications.
> > >
> > > Regarding "Apache" = "Quality", I'd be careful.  Apache asserts
> [1] a
> > > maxim of "Community over code".  While certainly a broad community
> > > inevitably leads to better code, and Apache is a good starting point,
> > given
> > > the specificity of your request I might start there but not exclude
> other
> > > established projects (not random code) which follow many of the same
> > > principles.
> > >
> > > I do hope those on this list are aware of some projects they can
> > > recommend to you!
> > >
> > > As for the technical specifications, I'd also recommend you'd
> > separate
> > > those out as well.  Some of your concerns seem to deal with native code
> > > access which seems a separate issue than modular design of code.  I
> have
> > > also been looking around for good Panama/FMA examples and haven't seen
> > > anything non-trivial yet.  But even those can be done with/without the
> > Java
> > > Module System (JPMS).
> > >
> > > Looking forward to any other replies with interest.
> > >
> > > Dan
> > >
> > > [1] - https://www.apache.org/theapacheway/
> > >
> > > On 3/17/21, 10:08 PM, "leerho"  wrote:
> > >
> > > Daniel,
> > > Thank you for your reply.
> > >
> > >
> > > > Can you clarify what you mean by an "Apache Java project"?
> > >
> > >
> > > I would prefer to examine a project that has a formal release
> > > process and
> > > an active community. So a TLP or incubating project would be
> > > great.  In
> > > this case I was equating "Apache" = "Quality"  :)
> > >
> > > I'm not so interested in random code on the Internet that just
> > > happens to
> > > be Apache licensed :)
> > >
> > > Is there a particular use case you are interested in?
> > >
> > >
> > > I am seriously looking at *redesigning* our JDK8 Library using
> > > Java Modules
> > > leveraging JDK16+/Panama/FMA and completely replacing the need
> &

Re: Alita-validator Proposal

[Romain Manni-Bucau]

Hi

At Apache we have bval which is a bean validation implementation.
Contrarly to what was written, bean validation does not work by exception
but validator returns violations as alita if I got it right.
So overall I am not sure the difference between both except some API
choices.
Also note that originally bval was the same kind of validator and we merged
the custom api with the jsr one because the proprietary api was not used.
Anyway to converge and make alita a module of bval maybe?

Le dim. 1 nov. 2020 à 10:53, Sheng Wu  a écrit :

> Hi Ran Ke
>
> I did a quick review of the project you proposed, due to it is in Chinese
> basically, very few IPMC members could understand the project from the read
> doc.
> I need to point out
> 1. The project has a very small community, you are the only one committed
> codes. The other two, you listed on the proposal have no commit to the
> repo.
> 2. No issue exists, which makes me feel, the project is in the very early
> stage, still leaks of users.
>
> I would suggest you build the community first, at least you have active
> contributors(not just you, at least have a small group of people).
> Try to connect with qualified mentors(Apache members or Incubator PMC
> members) to get started. You need to prepare the proposal(more about the
> project and community themselves) for a longer time and need some guidance.
> Such as try to ask at d...@community.apache.org for ALC(Apache Local
> Community) Beijing, to see whether there is a volunteer(s) to help.
>
> Sheng Wu 吴晟
> Twitter, wusheng1108
>
>
> ranke <213...@qq.com> 于2020年11月1日周日 下午5:35写道：
>
> > Alita-validator Proposal
> >
> >
> > Abstract
> > Alita-validator is a simple and easy-to-use API verifier. It provides
> > custom business code and business message and returns it to API
> consumers.
> > Users can customize error return packaging.
> > Users can extend some non generic business related verifiers themselves.
> >
> >
> > Unlike JSR 380 bean validation standard, alita-validator does not throw
> an
> > exception when the validation fails. Instead, it returns the code and
> > message set by the user to the API caller.
> > At present, the functions are implemented based on spring AOP, and future
> > plans are made:
> > * Provide different implementations for non spring projects
> > * Add more universal validator
> > * Provide the way to handle the failure of selection verification: return
> > the message to the API caller / throw an exception
> >
> >
> > The goal of alita-validator is to enable users to focus more on business
> > logic. The validation of API parameters is handed over to alita-validator
> > to save the code of validation parameters.
> > Proposal
> > Alita-validator is still young and not strong enough. I hope that more
> > people can know it, develop and strengthen it by donating it to Apache.
> >
> >
> > Background
> > In the past, when I was doing API development, there was always a lot of
> > code to do parameter verification. Many of these codes were repetitive
> and
> > boring.
> > Although there is JSR 380 bean validation standard and there are many
> > implementations, these implementations throw the failed message as an
> > exception, and there is no corresponding code for the message.
> > As an API, I want to tell the caller of the API the reason why the
> > verification failed so that the corresponding processing can be done.
> > For example, for the API based on HTTP, the parameters often come from
> the
> > user's input. The UI can handle these error messages and let the user
> know
> > in some way.
> >
> >
> > Rationale
> > Alita-validator is developed in Java, which provides API parameter
> > validation capability through annotations. Annotations can be used on
> > method parameters or in attributes of Java beans.
> > Through the combination of various verifier annotations, the verification
> > of API parameters can be realized. For example, verify whether a string
> is
> > email, and verify that a password meets the complexity requirements, etc.
> > We expect more interesting features and use cases to emerge from the
> > community ranging.
> >
> >
> > Current Status
> > Meritocracy
> > The intent of this proposal is to start building a diverse developer and
> > user community around alita-validator following the ASF meritocracy
> > model.
> > We plan to invite more people as committers if they are interested and
> > contribute to this project.
> >
> >
> > Community
> > At present, alita-validator is mainly developed by me and my friends. We
> > hope to expand the contributor base by donating to Apache.
> >
> >
> > Core Developers
> > At present, alita-validator is mainly developed by me and my friends.
> >
> >
> > Aligment
> > The ASF is the natural choice to host the alita-validator project as its
> > goal of encouraging community-driven open source projects fits with our
> > vision for alita-validator.
> >
> >
> > Known Risks
> > Orphaned products
> > Alita-validator comes from the 

[RESULT] [VOTE] Apache BatchEE leaving the incubator

[Romain Manni-Bucau]

Hi all,

makes 12 +1 (10 bindings) and no other vote so this vote passes.

Thank you all.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 9 déc. 2019 à 13:57, Furkan KAMACI  a
écrit :

> Hi,
>
> +1 (binding)
>
> Kind Regards,
> Furkan KAMACI
>
> On Sat, Dec 7, 2019 at 12:17 PM Sheng Wu 
> wrote:
>
> > +1 binding
> >
> > Sheng Wu 吴晟
> > Twitter, wusheng1108
> >
> >
> > Mark Struberg  于2019年12月7日周六 下午5:13写道：
> >
> > > +1 (binding) to join Geronimo
> > >
> > > txs and LieGrue,
> > > strub
> > >
> > > > Am 06.12.2019 um 10:50 schrieb Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >:
> > > >
> > > > Hi everyone,
> > > >
> > > > BatchEE community voted to leave the incubator to join Apache
> Geronimo
> > > as a
> > > > subproject.
> > > >
> > > > Here is the vote thread:
> > > >
> > http://mail-archives.apache.org/mod_mbox/batchee-dev/201912.mbox/browser
> > > >
> > > > Please vote:
> > > >
> > > > [ ] +1 to retire Sirona
> > > > [ ] -1 to retire Sirona ${cause}
> > > >
> > > > Vote will be opened for 3 days or until 3 +1 bindings are reached as
> > > usual
> > > >
> > > > Here is my +1
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> > >
> >
>

[VOTE] Apache BatchEE leaving the incubator

[Romain Manni-Bucau]

Hi everyone,

BatchEE community voted to leave the incubator to join Apache Geronimo as a
subproject.

Here is the vote thread:
http://mail-archives.apache.org/mod_mbox/batchee-dev/201912.mbox/browser

Please vote:

 [ ] +1 to retire Sirona
 [ ] -1 to retire Sirona ${cause}

Vote will be opened for 3 days or until 3 +1 bindings are reached as usual

Here is my +1

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

Re: What is the best tool to scan the code?

[Romain Manni-Bucau]

Hi,

1. ossindex from sonatype covers a lot
2. not sure what you means, findbugs or more checkstyle/pmd?
3. rat plugin for example (see apache creadur tools too, there are license
tools). Also note that with the initial dep review + review of the license
each time a new dep is added in standard asf review flow you rarely need to
scan them actually.
4. you can also check binary only contains your code + deps so no need to
rescan in such a case.

Blackduck is good but does not scale well for huge projects (> 60 modules)
and is not free, sourceclear is also a not that bad alternative but is not
free too I think.

My 2cts being that the previous setup works well for asf projects, stays
free and integrated to the build (compared to blackduck or sourceclear
which are using two steps/async process as solutions).

Hope it helps

Le mer. 4 sept. 2019 à 23:13, Xun Hu  a écrit :

> We would like to scan our code to:
> 1) dependency analysis
> 2) snippet matching
> 3) license analysis
> 4) binary analysis  - optional
>
> We found one paid solution - black duck, not sure there is any open source
> solution on the market.
>
> Thanks,
> -xun
>
> -Original Message-
> From: Justin Mclean 
> Sent: Wednesday, September 4, 2019 1:59 PM
> To: general@incubator.apache.org
> Subject: Re: What is the best tool to scan the code?
>
> HI,
>
> > We have one open source project, and I would like to find a tool to scan
> the code before we open it.
>
> Sorry but it unclear to me, what you what to scan the code for.
>
> 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

[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: [VOTE] Accept Zipkin into the Apache Incubator

[Romain Manni-Bucau]

+1 Accept Zipkin

Le lun. 27 août 2018 05:52, James Taylor  a écrit :

> +1 (binding)
>
> On Sun, Aug 26, 2018 at 8:41 PM Greg Trasuk 
> wrote:
>
> > +1 Accept Zipkin (binding).
> >
> > Greg Trasuk.
> >
> > > On Aug 26, 2018, at 11:14 PM, Mick Semb Wever  wrote:
> > >
> > > After a brief discussion¹ I would like to call a VOTE to accept Zipkin
> > into the Apache Incubator.
> > > The full proposal is available on the wiki² and is pasted below in text
> > form as well.
> > >
> > > This vote will run at least 72 hours. Please VOTE as follows:
> > >
> > > [ ] +1 Accept Zipkin into the Apache Incubator
> > > [ ] +0 No opinion
> > > [ ] -1 Do not accept Zipkin into the Apache Incubator because…
> > >
> > > regards,
> > > Mick
> > >
> > > [1]
> >
> https://lists.apache.org/thread.html/54798a5059db1d5716ed9910a15c92945509a25ec3b7ccb6b1215c53@%3Cgeneral.incubator.apache.org%3E
> > > [2] https://wiki.apache.org/incubator/ZipkinProposal
> > >
> > >
> > >
> > > = Abstract =
> > > Zipkin is a distributed tracing system. It helps gather timing data
> > needed to troubleshoot latency problems in microservice architectures. It
> > manages both the collection and lookup of this data. Zipkin’s design is
> > based on the Google Dapper paper.
> > >
> > > = Proposal =
> > > Zipkin provides a defined data model and payload type for distributed
> > trace data collection. It also provides an UI and http api for querying
> the
> > data. Its server implements this api and includes abstractions for
> storage
> > and transport of trace payloads. The combination of these parts avoid
> > lock-in to a specific tracing backend. For example, Zipkin includes
> > integration with different open source storage mechanisms like Apache
> > Cassandra and Elasticsearch. It also includes bridges to convert
> collected
> > data and forward it to service offerings such as Amazon X-Ray and Google
> > Stackdriver. Ecosystem offering extend this portability further.
> > >
> > > While primarily focused on the system, Zipkin also includes tracing
> > libraries which applications use to report timing information. Zipkin's
> > core organization includes tracer libraries written in Java, Javascript,
> > Go, PHP and Ruby. These libraries use the formats mentioned above to
> report
> > data, as well "B3" which is a header format needed to send trace
> > identifiers along with production requests. Many Zipkin libraries can
> also
> > send data directly to other services such as Amazon X-Ray and Google
> > Stackdriver, skipping any Zipkin infrastructure. There are also more
> Zipkin
> > tracing libraries outside the core organization than inside it. This is
> due
> > to the "OpenZipkin" culture of promoting ecosystem work.
> > >
> > > = Background =
> > > Zipkin began in 2012 at Twitter during a time they were investigating
> > performance problems underlying the "fail whale" seen by users. The name
> > Zipkin is from the Turkish word for harpoon: the harpoon that will kill
> the
> > failures! Incidentally, Zipkin was not the first tracing system, it had
> > roots in a former system at Twitter named BigBrotherBird. It is due to
> > BigBrotherBird that the de-facto tracing headers we still use today
> include
> > the prefix "X-B3".
> > >
> > > In 2015, a community of users noticed the project was not healthy in so
> > far as it hadn't progressed and often didn't accept pull requests, and
> the
> > Cassandra backend was stuck on an unmaintained library. For example, the
> > Apache Incubator H-Trace project started in some ways as a reaction to
> the
> > inability to customize the code. The root cause of this was Twitter
> moving
> > to internal storage (Manhattan) and also the project not being managed
> as a
> > product. By mid 2015, the community regrouped as OpenZipkin and the
> > codebase moved from Twitter to an org also named OpenZipkin. This led to
> > fast progress on concerns including initially a server rewrite and Docker
> > based deployment.
> > >
> > > In 2018, the second version of the data model completed, and along the
> > way, many new libraries became standard, including javascript, golang and
> > PHP. The community is dramatically larger than 2015, and Zipkin remains
> the
> > most popular tracing system despite heavy competition.
> > >
> > > = Rationale =
> > > Zipkin is a de-facto distributed tracing system, which is more
> important
> > as architectures become more fine grained due to popularity of
> microservice
> > or even serverless architectures. Applications transition to use more
> > complex communication including asynchronous code and service mesh,
> > increasing the need for tools that visualize the behavior of requests as
> > they map across an architecture.
> > >
> > > Zipkin's server is focused only on distributed tracing. It is meant to
> > be used alongside existing logging and metrics systems. Generally, the
> > community optimizes brown field concerns such as interop over breaking
> > changes such as experimental features. 

Re: [PROPOSAL] Zipkin for Apache Incubator

[Romain Manni-Bucau]

+1 and exited since it sounds like the promise of a lot of communities
interactions (skywalking, cxf, geronimo opentracing, ).

Le sam. 18 août 2018 14:27, kristof.adriaenss...@gmail.com <
kristof.adriaenss...@gmail.com> a écrit :

> +1 Looks like a good move for the community based on the initial goals and
> motivations as also mentioned here:
> https://github.com/openzipkin/zipkin/issues/2152
>
> On 2018/08/17 09:29:47, Adrian Cole  wrote:
> > I would like to propose Zipkin as an Apache Incubator project.
> >
> > The text of the proposal can be found below as well as on the Incubator
> wiki:
> >
> > https://wiki.apache.org/incubator/ZipkinProposal
> >
> > I believe we should have 3 mentors.. currently we have 2 (plus Wu
> > Sheng and I who are familiar but not mentor-grade :P). If another
> > person can volunteer to mentor us, would be sweet.
> >
> > -Adrian
> >
> > = Abstract =
> > Zipkin is a distributed tracing system. It helps gather timing data
> > needed to troubleshoot latency problems in microservice architectures.
> > It manages both the collection and lookup of this data. Zipkin’s
> > design is based on the Google Dapper paper.
> >
> > = Proposal =
> > Zipkin provides a defined data model and payload type for distributed
> > trace data collection. It also provides an UI and http api for
> > querying the data. Its server implements this api and includes
> > abstractions for storage and transport of trace payloads. The
> > combination of these parts avoid lock-in to a specific tracing
> > backend. For example, Zipkin includes integration with different open
> > source storage mechanisms like Apache Cassandra and Elasticsearch. It
> > also includes bridges to convert collected data and forward it to
> > service offerings such as Amazon X-Ray and Google Stackdriver.
> > Ecosystem offering extend this portability further.
> >
> > While primarily focused on the system, Zipkin also includes tracing
> > libraries which applications use to report timing information.
> > Zipkin's core organization includes tracer libraries written in Java,
> > Javascript, Go, PHP and Ruby. These libraries use the formats
> > mentioned above to report data, as well "B3" which is a header format
> > needed to send trace identifiers along with production requests. Many
> > Zipkin libraries can also send data directly to other services such as
> > Amazon X-Ray and Google Stackdriver, skipping any Zipkin
> > infrastructure. There are also more Zipkin tracing libraries outside
> > the core organization than inside it. This is due to the "OpenZipkin"
> > culture of promoting ecosystem work.
> >
> > = Background =
> > Zipkin began in 2012 at Twitter during a time they were investigating
> > performance problems underlying the "fail whale" seen by users. The
> > name Zipkin is from the Turkish word for harpoon: the harpoon that
> > will kill the failures! Incidentally, Zipkin was not the first tracing
> > system, it had roots in a former system at Twitter named
> > BigBrotherBird. It is due to BigBrotherBird that the de-facto tracing
> > headers we still use today include the prefix "X-B3".
> >
> > In 2015, a community of users noticed the project was not healthy in
> > so far as it hadn't progressed and often didn't accept pull requests,
> > and the Cassandra backend was stuck on an unmaintained library. For
> > example, the Apache Incubator H-Trace project started in some ways as
> > a reaction to the inability to customize the code. The root cause of
> > this was Twitter moving to internal storage (Manhattan) and also the
> > project not being managed as a product. By mid 2015, the community
> > regrouped as OpenZipkin and the codebase moved from Twitter to an org
> > also named OpenZipkin. This led to fast progress on concerns including
> > initially a server rewrite and Docker based deployment.
> >
> > In 2018, the second version of the data model completed, and along the
> > way, many new libraries became standard, including javascript, golang
> > and PHP. The community is dramatically larger than 2015, and Zipkin
> > remains the most popular tracing system despite heavy competition.
> >
> > = Rationale =
> > Zipkin is a de-facto distributed tracing system, which is more
> > important as architectures become more fine grained due to popularity
> > of microservice or even serverless architectures. Applications
> > transition to use more complex communication including asynchronous
> > code and service mesh, increasing the need for tools that visualize
> > the behavior of requests as they map across an architecture.
> >
> > Zipkin's server is focused only on distributed tracing. It is meant to
> > be used alongside existing logging and metrics systems. Generally, the
> > community optimizes brown field concerns such as interop over breaking
> > changes such as experimental features. The combination of code and
> > community make Zipkin a safe and easier choice for various sites to
> > introduce or grow their 

Re: graphviz as a potential apache project

[Romain Manni-Bucau]

Wow, sounds very exciting to have graphviz here.

Incubator being mainly about validating there is a community@asf I think it
makes sense to go through incubator first. Also it will let Graphviz time
to handle the license switch. That said the promotion to a TLP can be quite
fast since most of the community is already here and I don't see it being
that far from ASF requirements so I think going through incubator is a good
path.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le dim. 3 juin 2018 à 17:29,  a écrit :

> Hi All
>
> I received this request from Stephen so am forwarding to the general
> incubator mailing list for discussion and any suggestions for options.
>
> Thanks
> Sharan
>
>
>  Forwarded Message 
> Subject:graphviz as a potential apache project
> Date:   Thu, 31 May 2018 17:51:04 -0400
> From:   Stephen North 
> Reply-To:   Stephen North 
> To: sha...@apache.org
>
>
>
> Hi, Sharan.   I hope you’re the right person for this.  (Your org. just
> sent an invitation
> to an Apache roadshow event under your name.)
>
> I’m one of the founders of Graphviz, 20+ years ago, and it’s useful
> infrastructure
> software with new and old applications in bioinformatics, machine
> learning, software
> engineering and other fields, including plugins for R, python, Haskell,
> transpiled
> into javascript, who knows what else.  I think for example clang, llvm,
> maybe Go
> use it for debug output.  See www.graphviz.org
>
> We started this in AT Labs but AT discontinued all support for the
> work,
> eliminated some of our jobs or encouraged us to leave, has disclaimed the
> project,
> so we’re on our own.  We maintain the software and the website, that we
> moved to gitlab.
>
> We are looking for a more stable institutional home for Graphviz.  Apache
> seems like
> a great match. Is this possible?  How is a decision like that made?  I’m
> not sure a mature
> project like this fits the incubator model. Are there other ways?
>
> Sorry if this has gone long (I could say a lot more, too, for example how
> we could put
> focus effort on new features, or providing better resources to people that
> need
> network visualization as a service). I’m hoping you’re the right person to
> start the conversation.
>
> Thank you for your time, and for your consideration.
>
> Stephen North
>
>
>

Re: scala/play community?

[Romain Manni-Bucau]

Seems there is no big enthusiasm - which is what i kind of expected ;),  so
I guess I'll keep it on github for now (https://github.com/rmannibucau/playx).
If anyone becomes interested and feels we can create a community, dont
hesitate to ping me.

Thanks guys.

Le jeu. 17 mai 2018 02:55, Willem Jiang <willem.ji...@gmail.com> a écrit :

> As there are bunch of big data projects which use Scala @asf,
> I guess here are some of Scala developer could be interested to expose the
> big data service in an easy way.
>
>
>
>
>
> Willem Jiang
>
> Blog: http://willemjiang.blogspot.com (English)
>   http://jnn.iteye.com  (Chinese)
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Wed, May 16, 2018 at 11:27 PM, Matt Sicker <boa...@gmail.com> wrote:
>
> > I've been involved in Scala and Akka projects before, but not Play,
> though.
> >
> > On 16 May 2018 at 07:43, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
> >
> > > Hi Romain,
> > >
> > > AFAIK, we don't have any project for now related to scala@play.
> > >
> > > Even if it sounds very interesting, I'm not sure a servlet/jaxrs bridge
> > > would be enough for a incubator project (especially in term of
> > community).
> > >
> > > Let's see feedback from the others.
> > >
> > > Regards
> > > JB
> > >
> > >
> > > On 16/05/2018 14:40, Romain Manni-Bucau wrote:
> > >
> > >> Hi guys,
> > >>
> > >> I wonder if we have some scala@play community or not @asf.
> > >>
> > >> I will likely try to bring a servlet/jaxrs bridge soon and wonder if
> > >> proposing it @asf can be interesting (otherwise I just put it on
> > github).
> > >>
> > >> Any inputs welcomed.
> > >>
> > >> Romain Manni-Bucau
> > >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > >> <https://rmannibucau.metawerx.net/> | Old Blog
> > >> <http://rmannibucau.wordpress.com> | Github <
> > >> https://github.com/rmannibucau> |
> > >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > >> <https://www.packtpub.com/application-development/java-ee-8-
> > >> high-performance>
> > >>
> > >>
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> > >
> >
> >
> > --
> > Matt Sicker <boa...@gmail.com>
> >
>

scala/play community?

[Romain Manni-Bucau]

Hi guys,

I wonder if we have some scala@play community or not @asf.

I will likely try to bring a servlet/jaxrs bridge soon and wonder if
proposing it @asf can be interesting (otherwise I just put it on github).

Any inputs welcomed.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

Re: The role of a mentor

[Romain Manni-Bucau]

Hi John,

for me it is close to what JB described:

1. be there when needed (how do I create a git repo? how do I ask a
JIRA?Why do I need X?). Even documented, having somebody you can ask
more directly is often valuable.
2. ensure the releases are legal (+ respect mandatory ASF rules + point out
not mandatory but recommanded rules)
3. be there to remind community is important and not only code to prepare a
good graduation



Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-04-03 7:31 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>:

> Hi John,
>
> IMHO, a mentor is not necessary involved in the project technics/codebase
> (it's
> actually a bonus).
>
> As a mentor, I'm focusing:
> 1. Insure of the legal aspect of the project (ICLA/CCLA, SGA, ...)
> 2. Help around infra and release preparation according to Apache rules
> 3. Help to promote the project and build communities around
> 4. See if there's potential interaction with other podlings and existing
> TLPs
> 5. Help to go to graduation (following the graduation checklist)
> 6. (optional) Help on the contribution (codebase, website, ...)
>
> My $0.01
>
> Regards
> JB
>
> On 04/03/2018 12:54 AM, John D. Ament wrote:
> > I've been following along the absent mentors discussion.  But I'm
> curious,
> > from both an IPMC member's perspective as well as a member of a podling,
> > what roles do you see for a mentor?  What are their responsibilities to
> the
> > podling?
> >
> > We have a few things written down, and I'm not too interested in
> rehashing
> > the written version.  But what do podlings need from their mentors?
> Point
> > you in a direction to run with?  Do the apache work for the podling?  Do
> we
> > (the ASF) need mentors to ensure that podlings are operating within
> certain
> > bounds?  Do we rely on mentors to be a read of the pulse of a podling?
> >
> > John
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Apache Gobblin 0.12.0 release RC2

[Romain Manni-Bucau]

+1, not a blocker since it is more on nice to have helpers than needed
tools IMHO and legally it looks ok and it builds properly

Le 1 avr. 2018 10:42, "Olivier Lamy"  a écrit :

> Well not a big drama, we can fix that with the next release.
> ATM  2 mentors have voted +1: Jean-Baptiste and myself.
> 1 * IPMC with Matt.
>
>
> On Sun, 1 Apr 2018 at 18:36, Justin Mclean 
> wrote:
>
> > Hi,
> >
> > PS by my count you only need one more +1 vote and only one of your
> project
> > mentors have voted.
> >
> > Thanks,
> > Justin
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>

Re: [VOTE] Release Apache SkyWalking (incubating) version 5.0.0-alpha (3rd round)

[Romain Manni-Bucau]

+1 looks good

Le 31 mars 2018 18:05, "Matt Sicker"  a écrit :

> +1 (binding)
>
> * Signatures ok
> * Rat check ok
> * Disclaimer, license, notice files all present
> * Build and test ok
>
>
> On 30 March 2018 at 23:07, 吴晟 Sheng Wu  wrote:
>
> > Hi All,
> > This is a call for vote to release Apache SkyWalking (Incubating) version
> > 5.0.0-alpha.
> >
> >
> > The Apache SkyWalking community has tested, voted and approved the
> proposed
> > release of Apache SkyWalking (Incubating) 5.0.0-alpha
> >
> >
> > From last vote:
> > 1. Separated the NOTICE and LICENSE in source package and distribution
> > 2. Removed the libraries in source package.
> > 3. Removed some unnecessary excludes from rat setting.
> > 4. Added a missing DISCLAIMER file.
> >
> >
> > We now kindly request the Incubator PMC members review and vote on this
> > incubator release.
> >
> >
> > Skywalking is an APM (application performance monitor), especially for
> > microservice, Cloud Native and container-based architecture systems.
> > Also known as a distributed tracing system.
> > It provides an automatic way to instrument applications:
> > no need to change any of the source code of the target application;
> > and an collector with an very high efficiency streaming module.
> >
> >
> > Vote Thread:
> >
> >
> >  * https://lists.apache.org/thread.html/4459517d990e2d0fa879ced5b65c44
> > e047191e8b9301e8b6d67f7927@%3Cdev.skywalking.apache.org%3E
> >
> >
> > Result Thread:
> >
> >
> >  * https://lists.apache.org/thread.html/c55adf4fa19d6c9ffa76a8d0cf2465
> > 90d95d8dd7dead11331346e10b@%3Cdev.skywalking.apache.org%3E
> >
> >
> > Release notes:
> >
> >
> > * https://github.com/apache/incubator-skywalking/blob/v5.
> > 0.0-alpha/CHANGES.md
> >
> >
> > Release Candidate:
> >
> >
> > * https://dist.apache.org/repos/dist/dev/incubator/skywalking/
> 5.0.0-alpha/
> >
> >
> > Maven 2 staging repository:
> >
> >
> > * https://repository.apache.org/content/repositories/
> > orgapacheskywalking-1010/org/apache/skywalking/
> >
> >
> > Release Tag :
> >
> >
> > * 5.0.0-alpha
> >
> >
> > Release CommitID :
> >
> >
> > * 476ae378bed24690628cc0d16108185b7b5580b6
> >
> >
> > Keys to verify the Release Candidate :
> >
> >
> > * http://pgp.mit.edu:11371/pks/lookup?op=get=0x2EF5026E70A55777
> > * https://dist.apache.org/repos/dist/dev/incubator/skywalking/
> > 5.0.0-alpha/KEYS
> >
> >
> > corresponding to pen...@apache.org
> >
> >
> > Guide to build the release from source :
> >
> >
> > * https://github.com/apache/incubator-skywalking/blob/v5.
> > 0.0-alpha/docs/en/How-to-build.md#build-from-apache-source-codes
> >
> >
> > Voting will start now (March 31th) and will remain open for at least 72
> > hours, Request IPMC to give their vote.
> > [ ] +1 Release this package.
> > [ ] +0 No opinion.
> > [ ] -1 Do not release this package because
> >
> >
> >
> > --
> > Sheng Wu
> > Apache SkyWalking original creator and PPMC member
>
>
>
>
> --
> Matt Sicker 
>

Re: [VOTE] Accept Coral into the Apache Incubator

[Romain Manni-Bucau]

+1


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-02-02 7:54 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>:

> +1 (binding)
>
> Regards
> JB
>
> On 02/01/2018 03:07 PM, Byung-Gon Chun wrote:
> > Hi all,
> >
> > I would like to start a VOTE to propose the Coral project as a podling
> into
> > the Apache Incubator.
> >
> > The ASF voting rules are described at https://www.apache.org/foundation/
> > voting.html
> >
> > A vote for accepting a new Apache Incubator podling is a majority vote
> for
> > which only Incubator PMC member votes are binding.
> >
> > This vote will run for at least 72 hours. Please VOTE as follows.
> > [] +1 Accept Coral into the Apache Incubator
> > [] +0 Abstain
> > [] -1 Do not accept Coral into the Apache Incubator because ...
> >
> > The proposal is listed below, but you can also access it on the wiki:
> > https://wiki.apache.org/incubator/CoralProposal
> >
> > = CoralProposal =
> >
> > == Abstract ==
> > Coral is a data processing system for flexible employment with
> > different execution scenarios for various deployment characteristics
> > on clusters.
> >
> > == Proposal ==
> > Today, there is a wide variety of data processing systems with
> > different designs for better performance and datacenter efficiency.
> > They include processing data on specific resource environments and
> > running jobs with specific attributes. Although each system
> > successfully solves the problems it targets, most systems are designed
> > in the way that runtime behaviors are built tightly inside the system
> > core to hide the complexity of distributed computing. This makes it
> > hard for a single system to support different deployment
> > characteristics with different runtime behaviors without substantial
> > effort.
> >
> > Coral is a data processing system that aims to flexibly control the
> > runtime behaviors of a job to adapt to varying deployment
> > characteristics. Moreover, it provides a means of extending the
> > system’s capabilities and incorporating the extensions to the flexible
> > job execution.
> >
> > In order to be able to easily modify runtime behaviors to adapt to
> > varying deployment characteristics, Coral exposes runtime behaviors to
> > be flexibly configured and modified at both compile-time and runtime
> > through a set of high-level graph pass interfaces.
> >
> > We hope to contribute to the big data processing community by enabling
> > more flexibility and extensibility in job executions. Furthermore, we
> > can benefit more together as a community when we work together as a
> > community to mature the system with more use cases and understanding
> > of diverse deployment characteristics. The Apache Software Foundation
> > is the perfect place to achieve these aspirations.
> >
> > == Background ==
> > Many data processing systems have distinctive runtime behaviors
> > optimized and configured for specific deployment characteristics like
> > different resource environments and for handling special job
> > attributes.
> >
> > For example, much research have been conducted to overcome the
> > challenge of running data processing jobs on cheap, unreliable
> > transient resources. Likewise, techniques for disaggregating different
> > types of resources, like memory, CPU and GPU, are being actively
> > developed to use datacenter resources more efficiently. Many
> > researchers are also working to run data processing jobs in even more
> > diverse environments, such as across distant datacenters. Similarly,
> > for special job attributes, many works take different approaches, such
> > as runtime optimization, to solve problems like data skew, and to
> > optimize systems for data processing jobs with small-scale input data.
> >
> > Although each of the systems performs well with the jobs and in the
> > environments they target, they perform poorly with unconsidered cases,
> > and do not consider supporting multiple deployment characteristics on
> > a single system in their designs.
> >
> > For an application writer to optimize an application to perform well
> > on a certain system engraved with its underlying behaviors, it
> > requ

Re: [PROPOSAL] Onyx - proposal for Apache Incubation

[Romain Manni-Bucau]

Le 26 janv. 2018 21:53, "Byung-Gon Chun" <bgc...@gmail.com> a écrit :

On Sat, Jan 27, 2018 at 5:41 AM, Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> Why not doing a beam subproject? Any blocker?
>
>
Thanks for the question, Romain.

We have a flexible, efficient runtime that supports various user programs
(e.g., Beam and Spark programs).
We are taking advantage of Beam as a programming layer, but our focus is
more on optimizing execution on various deployment scenarios.
We also plan to support other programming layers.



I tend to think it can converge since beam is about portability and
complementary IMHO. Can be worth PoCing.



> Otherwise +1 to have it @asf, makes a lot of sense.
>
>
Thanks for the support!

-Gon


> Le 26 janv. 2018 20:58, "Byung-Gon Chun" <bgc...@gmail.com> a écrit :
>
> > On Sat, Jan 27, 2018 at 4:09 AM, Davor Bonaci <da...@apache.org> wrote:
> >
> > > Great work -- I think this technology has a lot of promise, and I'd
> love
> > to
> > > see its evolution inside the Foundation.
> > >
> > >
> > Thanks, Davor!
> >
> >
> > > Parts of it, like the Onyx Intermediate Representation [1], overlap
> with
> > > the work-in-progress inside the Apache Beam project ("portability").
> We'd
> > > love to work together on this -- would you be open to such
> collaboration?
> > > If so, it may not be necessary to start from scratch, and leverage the
> > work
> > > already done.
> > >
> > >
> > Sure. We're open to collaboration.
> >
> >
> > > Regarding the name, Onyx would likely have to be renamed, due to a
> > conflict
> > > with a related technology [2].
> > >
> > >
> > Thanks for pointing it out. It's difficult to come up with a good short
> > name. :)
> > Do you have any suggestion?
> >
> > Thanks!
> > -Gon
> >
> > ---
> > Byung-Gon Chun
> >
> >
> >
> > > Davor
> > >
> > > [1] https://snuspl.github.io/onyx/docs/ir/
> > > [2] http://www.onyxplatform.org/
> > >
> > > On Thu, Jan 25, 2018 at 3:28 PM, Byung-Gon Chun <bgc...@gmail.com>
> > wrote:
> > >
> > > > Dear Apache Incubator Community,
> > > >
> > > > Please accept the following proposal for presentation and
discussion:
> > > > https://wiki.apache.org/incubator/OnyxProposal
> > > >
> > > > Onyx is a data processing system that aims to flexibly control the
> > > runtime
> > > > behaviors of a job to adapt to varying deployment characteristics
> > (e.g.,
> > > > harnessing transient resources in datacenters, cross-datacenter
> > > deployment,
> > > > changing runtime based on job characteristics, etc.). Onyx provides
> > ways
> > > to
> > > > extend the system’s capabilities and incorporate the extensions to
> the
> > > > flexible job execution.
> > > > Onyx translates a user program (e.g., Apache Beam, Apache Spark)
into
> > an
> > > > Intermediate Representation (IR) DAG, which Onyx optimizes and
> deploys
> > > > based on a deployment policy.
> > > >
> > > > I've attached the proposal below.
> > > >
> > > > Best regards,
> > > > Byung-Gon Chun
> > > >
> > > > = OnyxProposal =
> > > >
> > > > == Abstract ==
> > > > Onyx is a data processing system for flexible employment with
> > > > different execution scenarios for various deployment characteristics
> > > > on clusters.
> > > >
> > > > == Proposal ==
> > > > Today, there is a wide variety of data processing systems with
> > > > different designs for better performance and datacenter efficiency.
> > > > They include processing data on specific resource environments and
> > > > running jobs with specific attributes. Although each system
> > > > successfully solves the problems it targets, most systems are
> designed
> > > > in the way that runtime behaviors are built tightly inside the
system
> > > > core to hide the complexity of distributed computing. This makes it
> > > > hard for a single system to support different deployment
> > > > characteristics with different runtime behaviors without substantial
> > > > effort.
> > > >
> > > > Onyx is a data processing system that aims to flexibly control the
> > > > ru

Re: [PROPOSAL] Onyx - proposal for Apache Incubation

[Romain Manni-Bucau]

Why not doing a beam subproject? Any blocker?

Otherwise +1 to have it @asf, makes a lot of sense.

Le 26 janv. 2018 20:58, "Byung-Gon Chun"  a écrit :

> On Sat, Jan 27, 2018 at 4:09 AM, Davor Bonaci  wrote:
>
> > Great work -- I think this technology has a lot of promise, and I'd love
> to
> > see its evolution inside the Foundation.
> >
> >
> Thanks, Davor!
>
>
> > Parts of it, like the Onyx Intermediate Representation [1], overlap with
> > the work-in-progress inside the Apache Beam project ("portability"). We'd
> > love to work together on this -- would you be open to such collaboration?
> > If so, it may not be necessary to start from scratch, and leverage the
> work
> > already done.
> >
> >
> Sure. We're open to collaboration.
>
>
> > Regarding the name, Onyx would likely have to be renamed, due to a
> conflict
> > with a related technology [2].
> >
> >
> Thanks for pointing it out. It's difficult to come up with a good short
> name. :)
> Do you have any suggestion?
>
> Thanks!
> -Gon
>
> ---
> Byung-Gon Chun
>
>
>
> > Davor
> >
> > [1] https://snuspl.github.io/onyx/docs/ir/
> > [2] http://www.onyxplatform.org/
> >
> > On Thu, Jan 25, 2018 at 3:28 PM, Byung-Gon Chun 
> wrote:
> >
> > > Dear Apache Incubator Community,
> > >
> > > Please accept the following proposal for presentation and discussion:
> > > https://wiki.apache.org/incubator/OnyxProposal
> > >
> > > Onyx is a data processing system that aims to flexibly control the
> > runtime
> > > behaviors of a job to adapt to varying deployment characteristics
> (e.g.,
> > > harnessing transient resources in datacenters, cross-datacenter
> > deployment,
> > > changing runtime based on job characteristics, etc.). Onyx provides
> ways
> > to
> > > extend the system’s capabilities and incorporate the extensions to the
> > > flexible job execution.
> > > Onyx translates a user program (e.g., Apache Beam, Apache Spark) into
> an
> > > Intermediate Representation (IR) DAG, which Onyx optimizes and deploys
> > > based on a deployment policy.
> > >
> > > I've attached the proposal below.
> > >
> > > Best regards,
> > > Byung-Gon Chun
> > >
> > > = OnyxProposal =
> > >
> > > == Abstract ==
> > > Onyx is a data processing system for flexible employment with
> > > different execution scenarios for various deployment characteristics
> > > on clusters.
> > >
> > > == Proposal ==
> > > Today, there is a wide variety of data processing systems with
> > > different designs for better performance and datacenter efficiency.
> > > They include processing data on specific resource environments and
> > > running jobs with specific attributes. Although each system
> > > successfully solves the problems it targets, most systems are designed
> > > in the way that runtime behaviors are built tightly inside the system
> > > core to hide the complexity of distributed computing. This makes it
> > > hard for a single system to support different deployment
> > > characteristics with different runtime behaviors without substantial
> > > effort.
> > >
> > > Onyx is a data processing system that aims to flexibly control the
> > > runtime behaviors of a job to adapt to varying deployment
> > > characteristics. Moreover, it provides a means of extending the
> > > system’s capabilities and incorporating the extensions to the flexible
> > > job execution.
> > >
> > > In order to be able to easily modify runtime behaviors to adapt to
> > > varying deployment characteristics, Onyx exposes runtime behaviors to
> > > be flexibly configured and modified at both compile-time and runtime
> > > through a set of high-level graph pass interfaces.
> > >
> > > We hope to contribute to the big data processing community by enabling
> > > more flexibility and extensibility in job executions. Furthermore, we
> > > can benefit more together as a community when we work together as a
> > > community to mature the system with more use cases and understanding
> > > of diverse deployment characteristics. The Apache Software Foundation
> > > is the perfect place to achieve these aspirations.
> > >
> > > == Background ==
> > > Many data processing systems have distinctive runtime behaviors
> > > optimized and configured for specific deployment characteristics like
> > > different resource environments and for handling special job
> > > attributes.
> > >
> > > For example, much research have been conducted to overcome the
> > > challenge of running data processing jobs on cheap, unreliable
> > > transient resources. Likewise, techniques for disaggregating different
> > > types of resources, like memory, CPU and GPU, are being actively
> > > developed to use datacenter resources more efficiently. Many
> > > researchers are also working to run data processing jobs in even more
> > > diverse environments, such as across distant datacenters. Similarly,
> > > for special job attributes, many works take different approaches, such
> > > as runtime optimization, 

Re: [VOTE] Accept ECharts for Apache Incubation

[Romain Manni-Bucau]

+1

Le 13 janv. 2018 09:17, "Pierre Smits"  a écrit :

> +1
>
>
> Best regards,
>
> Pierre Smits
>
> V.P. Apache Trafodion
>
> On Sat, Jan 13, 2018 at 9:12 AM, Sergio Fernández 
> wrote:
>
> > +1 (binding)
> >
> > On Jan 12, 2018 14:13, "Kevin A. McGrail"  wrote:
> >
> > > Hi All,
> > >
> > > I would like to start a VOTE & I vote +1 to bring the ECharts project
> in
> > > as an Apache incubator podling.
> > >
> > > The ASF voting rules are described:
> > >
> > > https://www.apache.org/foundation/voting.html
> > >
> > > A vote for accepting a new Apache Incubator podling is a majority vote
> > for
> > > which only Incubator PMC member votes are binding.
> > >
> > > This vote will run for at least 72 hours. Please VOTE as follows
> > > [ ] +1 Accept ECharts into the Apache Incubator
> > > [ ] +0 Abstain.
> > > [ ] -1 Do not accept ECharts into the Apache Incubator because ...
> > >
> > > The proposal is listed below, but you can also access it on the wiki:
> > > https://wiki.apache.org/incubator/EChartsProposal
> > >
> > > Regards,
> > > KAM
> > >
> > >
> > > ECharts Proposal
> > >
> > > Abstract
> > >
> > > ECharts is a charting and data visualization library written in
> > JavaScript.
> > >
> > > Proposal
> > >
> > > ECharts provides a powerful, interactive charting and data
> visualization
> > > library and framework for web browser, mobile App and backend usage.
> > >
> > > Background
> > >
> > > A primary goal of data visualization is to communicate information
> > clearly
> > > and efficiently via statistical graphics, plots and other graphics.
> > >
> > > Numerical data may be presented in dots, lines, or bars, to visually
> > > communicate a quantitative message. Effective visualization helps users
> > to
> > > analyze data .It makes complex data more readable, understandable.[1]
> > >
> > > Now data visualization concerns mainly about presentation and
> propagation
> > > in web, ECharts uses JavaScript as its basic programing language. It
> > brings
> > > great compatibility across multiple platforms, not only in web
> browsers,
> > > but also in mobile Apps via embedded web engine or in backend
> environment
> > > via the techniques of headless browser.
> > >
> > > Rationale
> > >
> > > ECharts encapsulates the underlying data transformation, control flow,
> > > visual encoding and rendering, receiving the visualization requirements
> > > with declarative language, and produces interactive charts and
> > components.
> > > We will highlight the features below to illustrate the power that
> ECharts
> > > already has, and our concerns and our visions:
> > >
> > > User Diversity:
> > >
> > > ECharts expects that its users are not only web developers, but also
> > > people with lesser programing skills. So ECharts enables users to
> > describe
> > > data and settings with declarative language, which lowers the barrier
> but
> > > without losing the power, and benefit to transfer and store.
> > >
> > > Configurable Interactions:
> > >
> > > ECharts has provided plenty of interactions and aims at providing more.
> > > Both human interactions and the interactions with upper program are
> > > supported and can be configurable.
> > >
> > > Large Data:
> > >
> > > Although the browser environment and JavaScript bring some performance
> > > limits in visualizing large data or performing animations, ECharts have
> > > been adopting various optimization techniques to rise the upper limit
> of
> > > the amount of data that it can process, and keep improving the fluency
> of
> > > interactions and animations.
> > >
> > > Cross-Platform:
> > >
> > > The underlying render engine of ECharts can be switched between
> > > HTMLCanvas, SVG, or VML, which provides good compatibility and brings
> > > opportunities to optimize performance according to different platform
> and
> > > usage scenarios. Besides, ECharts can also works in backend environment
> > via
> > > headless techniques.
> > >
> > > ECharts can be created using headless browsers to pregenerate reports
> on
> > > more powerful machines for better performance on resource-limited
> devices
> > >
> > > Extension and Customization:
> > >
> > > ECharts provides extension mechanisms to make new types of chart and
> > > components, adopt other layout algorithms, or even adopt other render
> > > techniques. Various developers have contributed different types of
> > > extensions based on ECharts.[2]
> > >
> > > Current Status
> > >
> > > ECharts has been an open source project on GitHub[3] since 2013.
> > Currently
> > > it has more than 20k stars, more than 50k monthly downloads[4] in NPM,
> > and
> > > is one of the most popular repositories in topic of data visualization
> > > category in GitHub.[5] And it has been used in many products of Baidu
> and
> > > other companies such as Alibaba, Tencent, Netease, XinHua News
> > > Agency,National Bureau of Statistics of China, Sina, 

Re: [VOTE] Release of Apache BatchEE 0.5-incubating

[Romain Manni-Bucau]

We didnt change the headers (see
https://github.com/WASdev/standards.jsr352.jbatch/blob/master/com.ibm.jbatch.container/src/main/java/com/ibm/jbatch/container/impl/RetryHandler.java).
What would be a better mention in NOTICE?

Le 11 déc. 2017 07:26, "Justin Mclean"  a écrit :

> Hi,
>
> > The root NOTICE references the donation but files are under apache v2
> > license anyway, even referencing IBM so should be good.
>
> OKish, perhaps,  but given we’re taking about 120 or so files rather than
> just a couple so I think it would be better if it was fixed.
>
> The NOTICE statement is there because the copyright line have been
> relocated. [1] The Apache header used for ASF project is also different to
> that used in external projects i.e. mentions contributor license
> agreements.  If some of the headers haven't changed then it’s unclear if
> they were part of the donation or come from somewhere else. If they come
> from somewhere else then that bit of Apache licensed software may have a
> NOTICE file that would need to be looked at and parts possibly copied to
> your NOTICE file. So have 120 or so  files with IBM headers makes it a
> little hard to review.
>
> Thanks,
> Justin
>
> 1. https://www.apache.org/legal/src-headers.html#headers
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Release of Apache BatchEE 0.5-incubating

[Romain Manni-Bucau]

Hi Justin

The root NOTICE references the donation but files are under apache v2
license anyway, even referencing IBM so should be good.

Romain

Le 11 déc. 2017 07:02, "Justin Mclean"  a écrit :

Hi,

I’m not 100% sure I would vote +1 on this release due to possible header
issues (copyright IBM) and missing license information, but it’s probably
in the “please fix for next release” category. Where these files with IBM
headers a part of the donation or do they come from other 3rd party code?
If so does that other 3rd party code have NOTICE files?

What do other IPMC members think?

I checked:
- incubating in name
- hashes and signatures correct
- disclaimer exists
- LICENSE is missing a couple of things (see below)
- NOTICE looks good
- A number of files (120 or so ) are still "Copyright 2012 International
Business Machines Corp.”  and don’t have ASF headers. I assume these files
were part of the donation from IBM and just been missed? Two examples [3][4]
- no binary files in release
- can compile from source

LICENSE is missing a couple of permissive licenses.
- bootstrap [1][2] . While this is the older Apache license of bootstrap
(so it's not required to be added to LICENSE), more recent versions are MIT
licensed so might be good to call that out in the LICENSE. Bootstrap also
contains MIT licensed normalize.css.
- MIT licensed JQuery [5] which also contains MIT licensed Sizzle.js

And a very minor thing I notice some dependancies files refer to ALv2 as
the “Apache Public License 2.0” - not GPL thankfully :-) e.g. [6] but I
assume this is auto generated.

Thanks,
Justin

1. batchee-0.5-incubating/gui/servlet/embedded/src/main/
resources/META-INF/resources/internal/batchee/css/bootstrap.min.3.0.0.css
2. batchee-0.5-incubating/gui/servlet/embedded/src/main/
resources/META-INF/resources/internal/batchee/js/bootstrap.min.3.0.0.js
3. batchee-0.5-incubating/jbatch/src/main/xsd/jobXML_1_0.xsd
4. batchee-0.5-incubating/jbatch/src/main/java/org/apache/
batchee/container/impl/controller/chunk/RetryHandler.java
5. batchee-0.5-incubating/gui/servlet/embedded/src/main/
resources/META-INF/resources/internal/batchee/js/jquery-2.0.3.min.js
6. ./tools/maven-plugin/target/classes/META-INF/DEPENDENCIES


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

Re: [VOTE] Release of Apache BatchEE 0.5-incubating

[Romain Manni-Bucau]

Le 10 déc. 2017 11:35, "Mark Struberg"  a écrit :


> If you put them under /dev/ for the vote, that makes it easier for the
> reviewer to see what is actually intended for the release area.

Yes and no. Where do we get this zip from?
The answer is: from repository.apache.org. Because all this is set up in
the ASF own apache-parent pom.xml!

You are indeed right in pointing out that the original vote mail should
have added the sha1 of the source zip to vote on.
Let's fix that:
b51aebefc01e94f96df3d1a6664835524b855cf7

But you are wrong by assuming that with dist/dev all would be perfect.
Indeed, a SVN location is not worth much either if you don't know the
_exact_ SVN revision!
And this is missing in almost all votes as well.

By forcing dist/dev you basically render the staging area of
repository.apache.org useless. You agree?
And one more drawback is that ditching a failed release from SVN will _not_
free the occupied storage.
That might or might not be an issue. But it still would be a change to what
we do in many TLPs since many years.

In my personal opinion the dist/dev is a fine solution if the project does
not leverage a fully automated release build.
But for projects which use the maven-release-plugin doing a release is as
easy as mvn release:prepare + mvn release:perform.
All the rest is done automatically, including the deployment to a staging
area at repository.apache.org.

Forcing dist/dev for those projects would imo be more or less a step back
to deploying release candidates to people.a.o as we did a decade ago.
There was a good reason why we did get rid of that, you probably remember...

Don't get me wrong: it's always good to review and discuss our release
process.
What Reinhard did with the BatchEE release is really identical to what we
do in many TLPs.
What we really need to fix is the part with the sha1 (even better would be
sha256 though) as this is the only 100% way to ensure the VOTE is really on
the right source zip.



Exactly. Since the source is in the mvn closed staging repo with its hashes
it should also be fine OOTB.



Is this documented in the incubator release howto already?


Adding git.properties/svn.properties in the source at build time could even
remove any ambiguity.

Anyway this vote is regular so please proceed and open a new thread on the
process if there is really annissue please.



LieGrue,
strub

> Am 07.12.2017 um 15:01 schrieb sebb :
>
> On 7 December 2017 at 10:22, Mark Struberg 
wrote:
>> Hi Sebb!
>>
>> commits got pushed to the ASF repo
>> https://github.com/apache/incubator-batchee/commits/master
>>
>> And we clarified the dist question with Infra.
>> All is fine as repository.apache.org is ASF owned and operated territory.
>> The only thing which we must make sure is that the source zip get's
copied over to dist.a.o once the VOTE did succeed.
>
> If you put them under /dev/ for the vote, that makes it easier for the
> reviewer to see what is actually intended for the release area.
>
>> And we have to ofc make sure that it is really the same as voted upon.
We ensure this via the sha1.
>
> I don't understand how that can work, given the content of the VOTE mail.
> Note that the Nexus repo URLs are transient and not version controlled
AFAICT.
> Nor are they unique as the numbers will eventually wrap.
>
> Try to use the SHA1 of any of the files in the previous release to
> prove that the file is the one that was voted on.
>
> For example, under
> www.apache.org/dist/incubator/batchee/0.4-incubating/
> we have
> batchee-0.4-incubating-source-release.zip.sha1
> which contains
> 05535de5554b598356f27bdb475853675b80b8b4
>
> The release vote is here:
> https://lists.apache.org/thread.html/fc112978fe7682a95189f9d14567dd
ef23bd2fc860bbce89903bf5c9@%3Cgeneral.incubator.apache.org%3E
>
> How do you prove that the source zip is the one that was voted on?
>
>> txs and LieGrue,
>> strub
>>
>>
>>
>>> Am 06.12.2017 um 23:16 schrieb sebb :
>>>
>>> On 6 December 2017 at 17:06, Mark Struberg 
wrote:
 No sebb, the tag does NOT need to be owned by the PPMC.
 We just have to make sure that the tag gets moved over to ASF _AFTER_
the vote is closed.
 That's how GIT works and that's how we work with GIT since many years
at the ASF.

> The source must be released through the ASF mirror system,
> The source must be released through the ASF mirror system,
> The staging area for that is here:

 That's also ONLY valid for AFTER the vote!
>>>
>>> No, the /dev/ area is the normal location for RCs
>>>
 So once the VOTE passes we will copy it over.
>>>
>>> Once the vote passes you SVN copy/move /dev/ to /release/
>>>
 Again: we handle it that way in TLPs and many podlings since MANY
years.
>>>
>>> There have been changes over the years, including the introduction of
>>> dist.apache.org.
>>>
>>> The point is to provide a staged 

Re: [VOTE] Release of Apache BatchEE 0.5-incubating

[Romain Manni-Bucau]

Le 6 déc. 2017 18:22, "Daniel Gruno" <humbed...@apache.org> a écrit :

On 12/06/2017 06:18 PM, Romain Manni-Bucau wrote:
> 2017-12-06 18:14 GMT+01:00 Daniel Gruno <humbed...@apache.org>:
>> On 12/06/2017 06:10 PM, Mark Struberg wrote:
>>> As explained in the original GIT at ASF threads many years ago: you
cannot easily get rid of a branch at ASF.
>>> Even if we force-push a delete it will _not_ get propagated downstream
and would cause clashes if a release needs to be re-rolled.
>>
>> Move to gitbox, problem solved?
>
> Doesn't change anything AFAIK since it is the exact same archi no?

No it's not the same architecture - that wouldn't make much sense :)
gitbox is github r/w access with pruning of deleted branches enabled.


Not sure I get whay it changes here and you can still not push a tag on the
mainstream repo until it is vote*d*.


>
>> It strikes me as highly irregular that you are voting on something with
>> no guaranteed provenance in place. Perhaps this is based on
>> misinformation? I'd be inclined to vote -1 here, but I just can't be
>> bothered.
>
> No guarantee is quite rude since it is still mainly about trust
> between asf people. Or is the issue to use github only?

It's not all about trust, it's trust BUT verify. We can verify on the
ASF side, we can't verify someone's private repository. I'd also point
to the incubator policy (as john linked to) that states that the source
must be at ASF for a release vote to be held. Arguably, this is not the
case here. I'd suggest you simply move the repos to gitbox, give us
sufficient provenance to vote on the release, and you get to delete
branches.


We vote on the zip sources so this works.

Side note: im not against gitbox but topic should move to batchee dev@ ;)



>
>>
>>> That's the reason why we do NOT push the staging branch to the ASF
cannonical repo. Never did for most ASF projects.
>>> You can also read this up in the original GIT documentation I worked
out with Infra and CouchDB.
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>> Am 06.12.2017 um 17:36 schrieb John D. Ament <johndam...@apache.org>:
>>>>
>>>> Right, but the IPMC has general oversight and responsibilities for
>>>> podlings.  Our requirements for what goes into a release are at
>>>> https://incubator.apache.org/policy/incubation.html#releases
>>>>
>>>> John
>>>>
>>>> On Wed, Dec 6, 2017 at 11:16 AM Romain Manni-Bucau <
rmannibu...@gmail.com>
>>>> wrote:
>>>>
>>>>> @John: depends the project. DeltaSpike, BatchEE and several others
>>>>> don't and it is fine IMHO.
>>>>>
>>>>> Romain Manni-Bucau
>>>>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
>>>>>
>>>>>
>>>>> 2017-12-06 17:04 GMT+01:00 John D. Ament <johndam...@apache.org>:
>>>>>> On Wed, Dec 6, 2017 at 11:00 AM Romain Manni-Bucau <
>>>>> rmannibu...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> 2017-12-06 16:41 GMT+01:00 sebb <seb...@gmail.com>:
>>>>>>>> On 6 December 2017 at 08:08, Reinhard Sandtner <
rsandt...@apache.org>
>>>>>>> wrote:
>>>>>>>>> Hey incubator PMCs,
>>>>>>>>>
>>>>>>>>> The Apache BatchEE community has voted and approved the proposal
to
>>>>>>> release Apache BatchEE 0.5-incubating.
>>>>>>>>> Apache BatchEE is a JBatch implementation (JSR-352) which provides
>>>>> many
>>>>>>> enhancements and extensions.
>>>>>>>>>
>>>>>>>>> You may find the VOTE thread here:
>>>>>>>>>
>>>>>>>
>>>>> https://lists.apache.org/thread.html/50c023e02cebcb61bc61aa2ea6112d
366b1dba0db04c045b7c1b415b@%3Cdev.batchee.apache.org%3E
>>>>>>> <
>>>>>>>
>>>>> http://mail-archives.apache.org/mod_mbox/batchee-dev/
201712.mbox/%3c501767c2-1220-41f1-a8f9-73330969d...@apache.org%3E
>>>>>>>>
>>>>>>>>>
>>>>>>>>> the RESULT VOTE thread can be found here:
>>>>>>>>>
>>>>>>>
>>>>> https://lists.apache.org/thread.html/6d05ea8439167e15d720d318c9c284
5fbd134ae2967321e3b7540386@%3Cdev.batchee.apache.org%3E
>>>>>>> <
>>>>>>>
>>>>> http

Re: [VOTE] Release of Apache BatchEE 0.5-incubating

[Romain Manni-Bucau]

2017-12-06 18:14 GMT+01:00 Daniel Gruno <humbed...@apache.org>:
> On 12/06/2017 06:10 PM, Mark Struberg wrote:
>> As explained in the original GIT at ASF threads many years ago: you cannot 
>> easily get rid of a branch at ASF.
>> Even if we force-push a delete it will _not_ get propagated downstream and 
>> would cause clashes if a release needs to be re-rolled.
>
> Move to gitbox, problem solved?

Doesn't change anything AFAIK since it is the exact same archi no?

> It strikes me as highly irregular that you are voting on something with
> no guaranteed provenance in place. Perhaps this is based on
> misinformation? I'd be inclined to vote -1 here, but I just can't be
> bothered.

No guarantee is quite rude since it is still mainly about trust
between asf people. Or is the issue to use github only?

>
>> That's the reason why we do NOT push the staging branch to the ASF 
>> cannonical repo. Never did for most ASF projects.
>> You can also read this up in the original GIT documentation I worked out 
>> with Infra and CouchDB.
>>
>> LieGrue,
>> strub
>>
>>
>>> Am 06.12.2017 um 17:36 schrieb John D. Ament <johndam...@apache.org>:
>>>
>>> Right, but the IPMC has general oversight and responsibilities for
>>> podlings.  Our requirements for what goes into a release are at
>>> https://incubator.apache.org/policy/incubation.html#releases
>>>
>>> John
>>>
>>> On Wed, Dec 6, 2017 at 11:16 AM Romain Manni-Bucau <rmannibu...@gmail.com>
>>> wrote:
>>>
>>>> @John: depends the project. DeltaSpike, BatchEE and several others
>>>> don't and it is fine IMHO.
>>>>
>>>> Romain Manni-Bucau
>>>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
>>>>
>>>>
>>>> 2017-12-06 17:04 GMT+01:00 John D. Ament <johndam...@apache.org>:
>>>>> On Wed, Dec 6, 2017 at 11:00 AM Romain Manni-Bucau <
>>>> rmannibu...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> 2017-12-06 16:41 GMT+01:00 sebb <seb...@gmail.com>:
>>>>>>> On 6 December 2017 at 08:08, Reinhard Sandtner <rsandt...@apache.org>
>>>>>> wrote:
>>>>>>>> Hey incubator PMCs,
>>>>>>>>
>>>>>>>> The Apache BatchEE community has voted and approved the proposal to
>>>>>> release Apache BatchEE 0.5-incubating.
>>>>>>>> Apache BatchEE is a JBatch implementation (JSR-352) which provides
>>>> many
>>>>>> enhancements and extensions.
>>>>>>>>
>>>>>>>> You may find the VOTE thread here:
>>>>>>>>
>>>>>>
>>>> https://lists.apache.org/thread.html/50c023e02cebcb61bc61aa2ea6112d366b1dba0db04c045b7c1b415b@%3Cdev.batchee.apache.org%3E
>>>>>> <
>>>>>>
>>>> http://mail-archives.apache.org/mod_mbox/batchee-dev/201712.mbox/%3c501767c2-1220-41f1-a8f9-73330969d...@apache.org%3E
>>>>>>>
>>>>>>>>
>>>>>>>> the RESULT VOTE thread can be found here:
>>>>>>>>
>>>>>>
>>>> https://lists.apache.org/thread.html/6d05ea8439167e15d720d318c9c2845fbd134ae2967321e3b7540386@%3Cdev.batchee.apache.org%3E
>>>>>> <
>>>>>>
>>>> https://lists.apache.org/thread.html/6d05ea8439167e15d720d318c9c2845fbd134ae2967321e3b7540386@%3Cdev.batchee.apache.org%3E
>>>>>>>
>>>>>>>>
>>>>>>>> For information about the contents of this release, see:
>>>>>>>>
>>>>>>
>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314924=12334679
>>>>>> <
>>>>>>
>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314924=12334679
>>>>>>>
>>>>>>>>
>>>>>>>> The tag is available on my github fork
>>>>>>>>
>>>>>>
>>>> https://github.com/rsandtner/incubator-batchee/tree/batchee-0.5-incubating
>>>>>> <
>>>>>>
>>>> https://github.com/rsandtner/incubator-batchee/tree/batchee-0.5-incubating
>>>>>>>
>>>>>>>
>>>>>>> That does not seem right.
>>>>>>> Tags need to be permanent and 'owned' by the (P)PMC
>>>>

Re: [VOTE] Release of Apache BatchEE 0.5-incubating

[Romain Manni-Bucau]

@John: depends the project. DeltaSpike, BatchEE and several others
don't and it is fine IMHO.

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn


2017-12-06 17:04 GMT+01:00 John D. Ament <johndam...@apache.org>:
> On Wed, Dec 6, 2017 at 11:00 AM Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>
>> 2017-12-06 16:41 GMT+01:00 sebb <seb...@gmail.com>:
>> > On 6 December 2017 at 08:08, Reinhard Sandtner <rsandt...@apache.org>
>> wrote:
>> >> Hey incubator PMCs,
>> >>
>> >> The Apache BatchEE community has voted and approved the proposal to
>> release Apache BatchEE 0.5-incubating.
>> >> Apache BatchEE is a JBatch implementation (JSR-352) which provides many
>> enhancements and extensions.
>> >>
>> >> You may find the VOTE thread here:
>> >>
>> https://lists.apache.org/thread.html/50c023e02cebcb61bc61aa2ea6112d366b1dba0db04c045b7c1b415b@%3Cdev.batchee.apache.org%3E
>> <
>> http://mail-archives.apache.org/mod_mbox/batchee-dev/201712.mbox/%3c501767c2-1220-41f1-a8f9-73330969d...@apache.org%3E
>> >
>> >>
>> >> the RESULT VOTE thread can be found here:
>> >>
>> https://lists.apache.org/thread.html/6d05ea8439167e15d720d318c9c2845fbd134ae2967321e3b7540386@%3Cdev.batchee.apache.org%3E
>> <
>> https://lists.apache.org/thread.html/6d05ea8439167e15d720d318c9c2845fbd134ae2967321e3b7540386@%3Cdev.batchee.apache.org%3E
>> >
>> >>
>> >> For information about the contents of this release, see:
>> >>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314924=12334679
>> <
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314924=12334679
>> >
>> >>
>> >> The tag is available on my github fork
>> >>
>> https://github.com/rsandtner/incubator-batchee/tree/batchee-0.5-incubating
>> <
>> https://github.com/rsandtner/incubator-batchee/tree/batchee-0.5-incubating
>> >
>> >
>> > That does not seem right.
>> > Tags need to be permanent and 'owned' by the (P)PMC
>>
>> During the vote - and for git - the tags shouldnt hit git@asf to
>> ensure that they are permanent (naming convention hacks don't work so
>> using forks is the choice which has been done by several projects,
>> including BatchEE).
>>
>> If it helps I can push the tag on my fork (which would make it owned
>> by the PMC) but since Reihard is a committer I don't see any issue
>> here.
>>
>
> I think what we've been doing is pushing to the ASF repos and pointing to
> the specific commit hash.
>
>
>>
>> >
>> >> Staging Repo is here:
>> >>
>> https://repository.apache.org/content/repositories/orgapachebatchee-1005 <
>> https://repository.apache.org/content/repositories/orgapachebatchee-1005>
>> >
>> > That is only the Maven staging area.
>> >
>> > The source must be released through the ASF mirror system,
>> >
>> > The staging area for that is here:
>> >
>> > https://dist.apache.org/repos/dist/dev/incubator/batchee/
>> >
>> > [If the vote succeeds, the files can be moved here:
>> > https://dist.apache.org/repos/dist/release/incubator/batchee/]
>> >
>> >> Sources can be found here:
>> >>
>> https://repository.apache.org/content/repositories/orgapachebatchee-1005/org/apache/batchee/batchee/0.5-incubating/batchee-0.5-incubating-source-release.zip
>> <
>> https://repository.apache.org/content/repositories/orgapachebatchee-1005/org/apache/batchee/batchee/0.5-incubating/batchee-0.5-incubating-source-release.zip
>> >
>> >>
>> >> Release artifacts are singed with the KEY:
>> >> https://github.com/apache/incubator-batchee/blob/master/KEYS <
>> https://github.com/apache/incubator-batchee/blob/master/KEYS>
>> >
>> > The KEYS file must be under
>> > https://www.apache.org/dist/incubator/batchee/ as must the sigs and
>> > hashes.
>> >
>> >
>> >> The vote is open for 72 hours
>> >
>> > At least 72 hours.
>> >
>> >> [ ] +1 batchEE -> coolShipIt()
>> >> [ ] +0 don’t care
>> >> [ ] -1 do not release because…
>> >>
>> >> thanks, lg
>> >> reini
>> >
>> > -
>> > 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: [VOTE] Release of Apache BatchEE 0.5-incubating

[Romain Manni-Bucau]

2017-12-06 16:41 GMT+01:00 sebb :
> On 6 December 2017 at 08:08, Reinhard Sandtner  wrote:
>> Hey incubator PMCs,
>>
>> The Apache BatchEE community has voted and approved the proposal to release 
>> Apache BatchEE 0.5-incubating.
>> Apache BatchEE is a JBatch implementation (JSR-352) which provides many 
>> enhancements and extensions.
>>
>> You may find the VOTE thread here:
>> https://lists.apache.org/thread.html/50c023e02cebcb61bc61aa2ea6112d366b1dba0db04c045b7c1b415b@%3Cdev.batchee.apache.org%3E
>>  
>> 
>>
>> the RESULT VOTE thread can be found here:
>> https://lists.apache.org/thread.html/6d05ea8439167e15d720d318c9c2845fbd134ae2967321e3b7540386@%3Cdev.batchee.apache.org%3E
>>  
>> 
>>
>> For information about the contents of this release, see:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314924=12334679
>>  
>> 
>>
>> The tag is available on my github fork
>> https://github.com/rsandtner/incubator-batchee/tree/batchee-0.5-incubating 
>> 
>
> That does not seem right.
> Tags need to be permanent and 'owned' by the (P)PMC

During the vote - and for git - the tags shouldnt hit git@asf to
ensure that they are permanent (naming convention hacks don't work so
using forks is the choice which has been done by several projects,
including BatchEE).

If it helps I can push the tag on my fork (which would make it owned
by the PMC) but since Reihard is a committer I don't see any issue
here.

>
>> Staging Repo is here:
>> https://repository.apache.org/content/repositories/orgapachebatchee-1005 
>> 
>
> That is only the Maven staging area.
>
> The source must be released through the ASF mirror system,
>
> The staging area for that is here:
>
> https://dist.apache.org/repos/dist/dev/incubator/batchee/
>
> [If the vote succeeds, the files can be moved here:
> https://dist.apache.org/repos/dist/release/incubator/batchee/]
>
>> Sources can be found here:
>> https://repository.apache.org/content/repositories/orgapachebatchee-1005/org/apache/batchee/batchee/0.5-incubating/batchee-0.5-incubating-source-release.zip
>>  
>> 
>>
>> Release artifacts are singed with the KEY:
>> https://github.com/apache/incubator-batchee/blob/master/KEYS 
>> 
>
> The KEYS file must be under
> https://www.apache.org/dist/incubator/batchee/ as must the sigs and
> hashes.
>
>
>> The vote is open for 72 hours
>
> At least 72 hours.
>
>> [ ] +1 batchEE -> coolShipIt()
>> [ ] +0 don’t care
>> [ ] -1 do not release because…
>>
>> thanks, lg
>> reini
>
> -
> 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] Accept SkyWalking into the Apache Incubator

[Romain Manni-Bucau]

+1

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn


2017-12-04 13:36 GMT+01:00 Ted Dunning <ted.dunn...@gmail.com>:
> +1
>
>
>
> On Mon, Dec 4, 2017 at 3:17 AM, mck <m...@apache.org> wrote:
>
>>
>> After some discussion on the SkyWalking proposal, I'd like to raise the
>> vote on accepting SkyWalking into into the Apache Incubator.
>>
>> https://lists.apache.org/thread.html/b4e7205e77fe382b4cd096fb6da28b
>> 70053e0722b3dd7ae8ac389f8a@%3Cgeneral.incubator.apache.org%3E
>>
>>
>> A vote for accepting a new Apache Incubator podling is a majority vote
>> for which only Incubator PMC member votes are binding.
>> Votes from other people are also welcome as an indication of peoples
>> enthusiasm (or lack thereof).
>>
>> Please do not use this VOTE thread for discussions. If needed, start a
>> new thread instead.
>>
>> This vote will run for at least 72 hours.
>> Please VOTE as follows:
>>[] +1 Accept SkyWalking
>>[] +0 Abstain
>>[] -1 Do not accept Skywalking, because ...
>>
>>
>> The proposal below is also on the wiki:
>> https://wiki.apache.org/incubator/SkyWalkingProposal
>>
>>
>> = Abstract =
>> Skywalking is an APM (application performance monitor), especially for
>> microservice, Cloud Native and container-based architecture systems.
>> Also known as a distributed tracing system. It provides an automatic way
>> to instrument applications: no need to change any of the source code of
>> the target application; and an collector with an very high efficiency
>> streaming module.
>>
>> = Proposal =
>> The goal of this proposal is to bring the existing
>> [[https://github.com/OpenSkywalking/skywalking|Skywalking]] codebase and
>> existing developers and community into the Apache Software Foundation
>> (ASF) in order to build a global, diverse and self-governed open source
>> community in APM field.
>>
>> This project started in Open Source on GitHub about more than 2 years
>> ago. Beginning with a small SDK and collector. So far the
>> [[https://github.com/OpenSkywalking/Organization|OpenSkywalking]]
>> governs the project through the PMC and Committer Team.
>>
>> OpenSkywalking is submitting this proposal to donate the Skywalking
>> sources code and  associated artifacts (documentation, web site content,
>> wiki, etc.) to the Apache Software Foundation Incubator under the Apache
>> License, Version 2.0. These artifacts are currently available on GitHub
>> at https://github.com/OpenSkywalking and include:
>>  * Skywalking: The java sniffer(agent) for collecting data, and
>>  collector for analysing and persistence.
>>  * Skywalking-UI: The web UI for skywalking APM
>>
>> ''Voted on submitting the proposal to the Incubator.
>> [[https://github.com/OpenSkywalking/Organization/issues/11|Check
>> here]]''
>>
>> = Background =
>> Mircro-service, Cloud Native and container-based architecture system are
>> becoming more and more popular, so the traditional monitoring, like
>> application loggings, can provide less information because of the
>> distributed isolates the relations. Based on the
>> [[https://research.google.com/pubs/pub36356.html|Google Dapper paper]],
>> many tracing systems born. The OpenSkywalking organisation was created
>> with  Skywalking made based on tracing, but not just tracing, it adds
>> additional value by reducing the sniffer (agent) cost, analysis and
>> visualization.
>>
>> In 2015, Skywalking project started, when service-oriented architecture
>> became popular. At first, skywalking provided a very simple SDK, and
>> collected data into a HBASE cluster. After we opened on the GitHub, the
>> community gives the feedbacks about how difficult to maintain a HBase
>> cluster, even harder than the applications under monitored. So, in 2.x
>> 2016, skywalking provided a self-designed storage, and update the SDK to
>> a javaagent with supporting auto-instrumentation. Then since 2017, more
>> and more contributors joined, we set up the PMC team and committer team.
>> Skywalking evolved to an APM, and more and more features provided since
>> then.
>>
>> = Rationale =
>> Skywalking includes these primary parts:
>>  1. Provide an anto-instrument sniffer, which is based on Javaagent and
>>  collects events and traces happened inside JVM, with little CPU/Memory
>>  cost.
>>  1. An extendable `tracing data protocol suit` with gRPC and HTTP
>>  implementations, is compatible for other language agent or 

Re: [PROPOSAL] SkyWalking - proposal for Apache Incubation

[Romain Manni-Bucau]

Hi Mick

I'm generally +1 and would be very happy to help but before voting can
you clarify the position with other donations like
https://github.com/cncf/toc/issues/50 please?

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn


2017-11-29 7:58 GMT+01:00 mck <m...@apache.org>:
> Dear Apache Incubator Community,
>
> Please accept the following proposal for presentation and discussion:
>   https://wiki.apache.org/incubator/SkyWalkingProposal
>
> SkyWalking is a distributed tracing solution that provides automatic
> instrumentation, coming from a community of Chinese contributors. This
> community has been involved with and part of the Distributed Tracing
> workshops held by Adrian Cole (who maintains and develops Zipkin) and
> the OpenTracing initiative.
>
> Sheng Wu reached out to me recently asking me to Champion the proposal
> because of my involvement with OpenTracing, Zipkin, and these
> Distributed Tracing workshops. The whole SkyWalking community has
> demonstrated a keenness to join Apache, as is seen on their GitHub
> issues discussing the matter. I'm excited to have been asked and have
> gladly accepted. Furthermore at last year's ApacheCon in Vancouver I met
> Luke Han during the ASF media workshop and watched his presentation
> about the challenges of opening up ASF to chinese communities and
> developers. Because of this we have reached out to Luke Han as an
> additional mentor. The result of this was that Sheng met Luke in person
> last weekend in Shanghai. Sheng also met Nicolas Hedhman in Shanghai.
> And Willem Ning Jiang has also been added as a mentor, who is also from
> Huawei and is currently involved in the ServiceComb proposal. Otherwise
> I'm aware that I'm new to the Incubator and its processes, so any
> additional mentors familiar with the finer details and precedence will
> be most welcomed.
>
> regards,
> Mick
>
> 
>
> = Abstract =
> Skywalking is an APM (application performance monitor), especially for
> microservice, Cloud Native and container-based architecture systems.
> Also known as a distributed tracing system. It provides an automatic way
> to instrument applications: no need to change any of the source code of
> the target application; and an collector with an very high efficiency
> streaming module.
>
> = Proposal =
> The goal of this proposal is to bring the existing Skywalking
> https://github.com/OpenSkywalking/skywalking codebase and existing
> developers and community into the Apache Software Foundation (ASF) in
> order to build a global, diverse and self-governed open source community
> in APM field.
>
> This project started in Open Source on GitHub about more than 2 years
> ago. Beginning with a small SDK and collector. So far the OpenSkywalking
> https://github.com/OpenSkywalking/Organization governs the project
> through the PMC and Committer Team. The major contributors are from
> Huawei DevCloud Team, Tydic, Oneapm (APM vendor),  Alibaba Group,
> dangdang.com and cloudwise (APM vendor).
>
> OpenSkywalking is submitting this proposal to donate the Skywalking
> sources code and  associated artifacts (documentation, web site content,
> wiki, etc.) to the Apache Software Foundation Incubator under the Apache
> License, Version 2.0. These artifacts are currently available on GitHub
> at https://github.com/OpenSkywalking and include:
>  * Skywalking: The java sniffer(agent) for collecting data, and
>  collector for analysing and persistence.
>  * Skywalking-UI: The web UI for skywalking APM
>
> Voted on submitting the proposal to the Incubator.
> https://github.com/OpenSkywalking/Organization/issues/11
>
> = Background =
> Mircro-service, Cloud Native and container-based architecture system are
> becoming more and more popular, so the traditional monitoring, like
> application loggings, can provide less information because of the
> distributed isolates the relations. Based on the Google Dapper paper
> https://research.google.com/pubs/pub36356.html, many tracing systems
> born. The OpenSkywalking organisation was created with  Skywalking made
> based on tracing, but not just tracing, it adds additional value by
> reducing the sniffer (agent) cost, analysis and visualization.
>
> In 2015, Skywalking project started, when service-oriented architecture
> became popular. At first, skywalking provided a very simple SDK, and
> collected data into a HBASE cluster. After we opened on the GitHub, the
> community gives the feedbacks about how difficult to maintain a HBase
> cluster, even harder than the applications under monitored. So, in 2.x
> 2016, skywalking provided a self-designed storage, and update the SDK to
> a javaagent with supporting auto-instrumentation. Then since 2017, more
> an

Re: Project informal discussion

[Romain Manni-Bucau]

Hi

For sources any template engine is great so velocity, freemarker, ..., even
strings (like cxf client plugin does) so need for a more formal lib is less
true than for bytecode generation. Eugene (from codelutin not asf) is also
a great one for sources.

What would add yours? Kind of fear it ends up as a token based api to stay
powerful which wouldnt be that user friendly at the end (compared to
templates).

Le 18 juil. 2017 08:22, "Wade Chandler"  a écrit :

> You should also checkout something like Graal and Truffle
> https://github.com/graalvm/graal/blob/master/truffle/README.md
>
> Wade
>
>
> On Jul 18, 2017 02:01, "Jochen Theodorou"  wrote:
>
> > On 18.07.2017 02:53, Harrison & Wells wrote:
> >
> >> # I'm just a beginner here, please ignore any stupidities
> >> So guys, you told me to discuss my project here first.
> >> Well, I have an idea of making a source code generator.
> >> There really isn't a source code generation library.And it can be done.
> >> It is really useful,just like BCEL, I think there should be one for
> >> source.
> >>
> >> For example, when one is making a compiler compiler,it will be quite
> >> handy.
> >> I haven't written any source at the moment, but when I do,can I start my
> >> packages with org.apache.
> >> Because,it's gonna be real cool.
> >>
> >>
> > I think you will have to give this a lot more flesh. Right now I can
> > imagine everything from a simple templating engine up to a compiler
> > generator like antlr
> >
> > bye Jochen
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: The state of Sirona

[Romain Manni-Bucau]

Le 16 avr. 2017 06:58, "Niclas Hedhman"  a écrit :

One could also ask the question; Considering how hyped "devops" culture is
right now, the central role that monitoring and visualization of that is
for devops, How come this project can't attract hordes of people? Is there
something inherent in Apache Incubator that interested parties have some
aversion of "incubating" or is it ASF as a whole isn't the right place for
these kinds of efforts?

The answer of "Too many out there", didn't seemed to have played a role in
the days of XML and WebApp frameworks, so I doubt that is the cause.



Adopters mainly were 100% java in term of philosophy or starting from
nothing so my (personal) explanation is devops is trendy but game was
already played in term of tool adoption. Not bringing anything really new
made our proposal having this characteristic. Just my interpretation but
dont think it is far to the reality.

Also think we were really bad in term of comm and, not sure why, comm
channels were always elsewhere than sirona@ (irc, direct ping, tomee
channels, ).




Cheers
Niclas

On Sun, Apr 16, 2017 at 2:55 AM, Ted Dunning  wrote:

> I think that we need to get over thinking of this state of affairs is a
> "failure".
>
> It is just one of the many different possible outcomes for incubation. To
> my mind, having multiple possible outcomes is a *feature*, not a bug.
>
> Obviously, we should not admit podlings that we aren't committed to
helping
> become TLP's and we should help those podlings become TLP's. But there are
> lots of different possible outcomes and only the podling can really
> determine which outcome it will have.
>
> It is a fact of nature that we cannot always know whether a new podling
> really has the right intent and contributor mix to become a good TLP.
> Sometimes it is apparent that the project will be a great fit and
sometimes
> it is apparent that it won't be, but many times we won't exactly know.
> There will be cases where a community will melt away and there will be
> cases where a community really didn't get the point of the Apache license.
> In many cases, the world just changes and by the time it is time to
> graduate, the project just isn't the right thing to do any more.
>
> As such, I think we need to (somewhat) over-admit podlings when there is
> doubt. That doesn't mean admit projects that just won't ever succeed, but
> it does mean we should be a little generous in terms of admission. We
> should vote to admit in cases of some doubt.
>
> If that is true, then we have to expect that there will be a variety of
> outcomes and we have to take that as a consequence of our initial
> generosity. This is not a cause for tears. Frankly, every project that
> becomes an obvious candidate for retirement means that there is another
> successful project that we admitted even though there was doubt.
>
> IF it is time to retire Sirona, let's just do it.
>
>
>
> On Sat, Apr 15, 2017 at 10:09 AM, Pierre Smits 
> wrote:
>
> > It is very sad to see a project failing at growing a community. Looking
> at
> > the various public sources, I see:
> >
> >- just 2 pull request since its start in incubation
> >- no postings on the user ml since December 2015
> >- only 3 committing contributors since start in incubation
> >- No description (readme) in github
> >- No mission statement/goal description of the project on the
> project's
> >home page
> >
> > I fear this will not turn around due to the lack of interest in the
world
> > beyond the project. At the moment I am inclined to say: time for
> > retirement.
> >
> > Best regards,
> >
> >
> > Pierre Smits
> >
> > ORRTIZ.COM 
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
> > On Sat, Apr 15, 2017 at 5:07 PM, Jean-Baptiste Onofré 
> > wrote:
> >
> > > Hi John
> > >
> > > I think you did the right thing by bringing the point on the table.
> > >
> > > AFAIR I already stated some months ago that, regarding the activity
and
> > > regarding the community around, we should really think about
retirement
> > of
> > > Sirona. Some can argue about the fact that Sirona is a "stable"
project
> > > that's not really valid: if it's valid we should see questions,
feature
> > > requests, etc coming from the user community. And obviously it's not
> the
> > > case. So I think that Sirona is just use for specific use cases in a
> very
> > > limited community.
> > >
> > > My €0.01 ;)
> > >
> > > Regards
> > > JB
> > >
> > > On Apr 15, 2017, 15:49, at 15:49, "John D. Ament" <
> johndam...@apache.org
> > >
> > > wrote:
> > > >All,
> > > >
> > > >I hate bringing up these topics.  But I think we as the IPMC we have
> to
> > > >take a close look at how Sirona is running and figure out what to do
> > > >next.
> > > >
> > > >- The podling has not reported in several months (this is 

Re: [VOTE] Drop incubating requirement of Maven artifacts

[Romain Manni-Bucau]

2017-01-03 13:45 GMT+01:00 Cédric Champeau <cedric.champ...@gmail.com>:

> 2017-01-03 13:41 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>
> > 2017-01-03 13:38 GMT+01:00 Cédric Champeau <cedric.champ...@gmail.com>:
> >
> > > +1
> > >
> > > Note that for Groovy, the source artifact, which is what legal is all
> > > about, contained the -incubating appendix. The Maven artifacts did not,
> > and
> > > I think it's a reasonable thing: people were used to stable versions of
> > > Groovy for years, there was no reason why a new one wouldn't be.
> > >
> > >
> > @Cédric: incubator is not about code maturity so still think it makes
> sense
> > (but agree for very big projects - by users - like groovy which are
> widely
> > used already it is weird so can be the exception confirming the rule?)
> >
> >
> Yes but the problem is that "incubating" carries the concept of maturity.
> So I was ok to have it in the source zip file name, because that is the
> reference that the ASF cares about, legally speaking. But Maven
> coordinates, including the version string, should not be affected by this
> policy. In other words, the requirement should not leak into technical
> aspects of consuming an artifact.
>
>
Think most of maven users will never grab the source zip and don't even
care so it is important to still reflect this maturity issue in what they
use (+ it is consistent since we release a single version and not 2: one
for legal and one for user)


>
> >
> > > 2017-01-03 13:25 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> > >
> > > > 2017-01-03 13:06 GMT+01:00 Guillaume Laforge <glafo...@gmail.com>:
> > > >
> > > > > When you say "it denotes a lack of maturity which is exactly the
> > > purpose
> > > > > AFAIK", what do you mean my maturity?
> > > > > Maturity in terms of how well it follows Apache processes and
> > > principles?
> > > > > Or in terms of "the project is not ready for prime time"?
> > > > >
> > > > > For example, for Apache Groovy, the project was very mature, and
> was
> > > > > already 11 years old when it joined the ASF.
> > > > > It was very stable, very mature, very solid.
> > > > > And it was a bit weird to append "-incubating", as people thought
> it
> > > > meant
> > > > > "not ready for prime time" rather that "going through ASF
> > incubation".
> > > > > Furthermore it forced users to also change the appId although they
> > > > usually
> > > > > change only the version number, which might be in some property
> file
> > > > > externally. It's not such a big big deal, but it's still something
> > they
> > > > had
> > > > > to do, which is a bit unconvenient.
> > > > >
> > > > >
> > > > And that is exactly this. Don't get me wrong, I'm part of several
> > > > incubating projects and I don't like to have -incubating cause it
> looks
> > > not
> > > > mature where sometimes code is very robust...but the project is
> > immature
> > > -
> > > > otherwise it wouldn't be in incubator. Even for groovy, there were
> few
> > > > chances but still some, it doesn't match ASF and it could have moved
> > > > somewhere else which is a stability issue which is important to show
> in
> > > the
> > > > published artifacts.
> > > >
> > > > Not sure I get the appId since most incubator projects don't reflect
> > the
> > > > state in the groupId but only the version for this exact reason (make
> > > user
> > > > upgrade from incubator to TLP just a version to change and not all
> > > > coordinates - which makes the classifier as bad as the groupId and
> > > version
> > > > a good compromise).
> > > >
> > > >
> > > > > I also second the idea that such a rule should apply to all kind of
> > > > > artifacts or none, but not be an exception of Maven artifacts.
> > > > > It doesn't make sense to enforce a rule for just one... and hence
> the
> > > > idea
> > > > > of lifting that rule altogether for everybody.
> > > > >
> > > > > On Tue, Jan 3, 2017 at 12:55 PM, Romain Manni-Bucau <
> > > > rmannibu...@gmail.com
> > > > > >
>

Re: [VOTE] Drop incubating requirement of Maven artifacts

[Romain Manni-Bucau]

2017-01-03 13:38 GMT+01:00 Cédric Champeau <cedric.champ...@gmail.com>:

> +1
>
> Note that for Groovy, the source artifact, which is what legal is all
> about, contained the -incubating appendix. The Maven artifacts did not, and
> I think it's a reasonable thing: people were used to stable versions of
> Groovy for years, there was no reason why a new one wouldn't be.
>
>
@Cédric: incubator is not about code maturity so still think it makes sense
(but agree for very big projects - by users - like groovy which are widely
used already it is weird so can be the exception confirming the rule?)


> 2017-01-03 13:25 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>
> > 2017-01-03 13:06 GMT+01:00 Guillaume Laforge <glafo...@gmail.com>:
> >
> > > When you say "it denotes a lack of maturity which is exactly the
> purpose
> > > AFAIK", what do you mean my maturity?
> > > Maturity in terms of how well it follows Apache processes and
> principles?
> > > Or in terms of "the project is not ready for prime time"?
> > >
> > > For example, for Apache Groovy, the project was very mature, and was
> > > already 11 years old when it joined the ASF.
> > > It was very stable, very mature, very solid.
> > > And it was a bit weird to append "-incubating", as people thought it
> > meant
> > > "not ready for prime time" rather that "going through ASF incubation".
> > > Furthermore it forced users to also change the appId although they
> > usually
> > > change only the version number, which might be in some property file
> > > externally. It's not such a big big deal, but it's still something they
> > had
> > > to do, which is a bit unconvenient.
> > >
> > >
> > And that is exactly this. Don't get me wrong, I'm part of several
> > incubating projects and I don't like to have -incubating cause it looks
> not
> > mature where sometimes code is very robust...but the project is immature
> -
> > otherwise it wouldn't be in incubator. Even for groovy, there were few
> > chances but still some, it doesn't match ASF and it could have moved
> > somewhere else which is a stability issue which is important to show in
> the
> > published artifacts.
> >
> > Not sure I get the appId since most incubator projects don't reflect the
> > state in the groupId but only the version for this exact reason (make
> user
> > upgrade from incubator to TLP just a version to change and not all
> > coordinates - which makes the classifier as bad as the groupId and
> version
> > a good compromise).
> >
> >
> > > I also second the idea that such a rule should apply to all kind of
> > > artifacts or none, but not be an exception of Maven artifacts.
> > > It doesn't make sense to enforce a rule for just one... and hence the
> > idea
> > > of lifting that rule altogether for everybody.
> > >
> > > On Tue, Jan 3, 2017 at 12:55 PM, Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >
> > > wrote:
> > >
> > > > -1, I think it is important to show that the artifact dependency is
> not
> > > > stable and should be used as such (if the project never graduates,
> even
> > > if
> > > > code is very mature then you still get all the troubles you can think
> > > > about).
> > > >
> > > > Question is IMHO the opposite: why others don't follow the
> -incubating
> > > rule
> > > > as well?
> > > >
> > > > PS: of course an alternative to follow maven common practise would be
> > to
> > > > put incubating in the groupId instead of version but in practise we
> > have
> > > > more easily a placeholder for the version than the groupId so I still
> > > think
> > > > version is the easiest place for users. Also note no user complained
> > > about
> > > > that excepted about the fact it denotes a lack of maturity which is
> > > exactly
> > > > the purpose AFAIK.
> > > >
> > > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > > rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > > > <https://jav

Re: [VOTE] Drop incubating requirement of Maven artifacts

[Romain Manni-Bucau]

2017-01-03 13:06 GMT+01:00 Guillaume Laforge <glafo...@gmail.com>:

> When you say "it denotes a lack of maturity which is exactly the purpose
> AFAIK", what do you mean my maturity?
> Maturity in terms of how well it follows Apache processes and principles?
> Or in terms of "the project is not ready for prime time"?
>
> For example, for Apache Groovy, the project was very mature, and was
> already 11 years old when it joined the ASF.
> It was very stable, very mature, very solid.
> And it was a bit weird to append "-incubating", as people thought it meant
> "not ready for prime time" rather that "going through ASF incubation".
> Furthermore it forced users to also change the appId although they usually
> change only the version number, which might be in some property file
> externally. It's not such a big big deal, but it's still something they had
> to do, which is a bit unconvenient.
>
>
And that is exactly this. Don't get me wrong, I'm part of several
incubating projects and I don't like to have -incubating cause it looks not
mature where sometimes code is very robust...but the project is immature -
otherwise it wouldn't be in incubator. Even for groovy, there were few
chances but still some, it doesn't match ASF and it could have moved
somewhere else which is a stability issue which is important to show in the
published artifacts.

Not sure I get the appId since most incubator projects don't reflect the
state in the groupId but only the version for this exact reason (make user
upgrade from incubator to TLP just a version to change and not all
coordinates - which makes the classifier as bad as the groupId and version
a good compromise).


> I also second the idea that such a rule should apply to all kind of
> artifacts or none, but not be an exception of Maven artifacts.
> It doesn't make sense to enforce a rule for just one... and hence the idea
> of lifting that rule altogether for everybody.
>
> On Tue, Jan 3, 2017 at 12:55 PM, Romain Manni-Bucau <rmannibu...@gmail.com
> >
> wrote:
>
> > -1, I think it is important to show that the artifact dependency is not
> > stable and should be used as such (if the project never graduates, even
> if
> > code is very mature then you still get all the troubles you can think
> > about).
> >
> > Question is IMHO the opposite: why others don't follow the -incubating
> rule
> > as well?
> >
> > PS: of course an alternative to follow maven common practise would be to
> > put incubating in the groupId instead of version but in practise we have
> > more easily a placeholder for the version than the groupId so I still
> think
> > version is the easiest place for users. Also note no user complained
> about
> > that excepted about the fact it denotes a lack of maturity which is
> exactly
> > the purpose AFAIK.
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-01-03 12:50 GMT+01:00 Myrle Krantz <mkra...@mifos.org>:
> >
> > > +1 non-binding
> > >
> > > If a best practice targets only maven and not the others, wouldn't that
> > be
> > > a reason for a podling to consider avoiding using maven to distribute
> > > binaries at all?  Is it fair for Apache to disadvantage maven that way?
> > >
> > > Can Apache enforce policies about binaries not released under the
> Apache
> > > name? Wouldn't that sort of policy be in contradiction to the Apache
> > > license?
> > >
> > > Keeping a best practice which is not only unenforceable and
> inconsistent,
> > > but also disadvantageous to any project which tries to follow it,
> > > discredits other best practices as well. (Broken windows theory)
> > >
> > > Greets from Germany
> > > Myrle
> > >
> > >
> > > On Tue, Jan 3, 2017 at 12:34 PM, John D. Ament <johndam...@apache.org>
> > > wrote:
> > >
> > > > Carsten, Julian,
> > > >
> > > > I want to reiterate my notes from a prior message [1] in case there
> is
> > > any
> > > > confusion over the ask.  There is a "best practice" around maven
> > specific
> > > > releases that has been treated as policy,  [2].  This best practice
> 

Re: [VOTE] Drop incubating requirement of Maven artifacts

[Romain Manni-Bucau]

-1, I think it is important to show that the artifact dependency is not
stable and should be used as such (if the project never graduates, even if
code is very mature then you still get all the troubles you can think
about).

Question is IMHO the opposite: why others don't follow the -incubating rule
as well?

PS: of course an alternative to follow maven common practise would be to
put incubating in the groupId instead of version but in practise we have
more easily a placeholder for the version than the groupId so I still think
version is the easiest place for users. Also note no user complained about
that excepted about the fact it denotes a lack of maturity which is exactly
the purpose AFAIK.



Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-01-03 12:50 GMT+01:00 Myrle Krantz <mkra...@mifos.org>:

> +1 non-binding
>
> If a best practice targets only maven and not the others, wouldn't that be
> a reason for a podling to consider avoiding using maven to distribute
> binaries at all?  Is it fair for Apache to disadvantage maven that way?
>
> Can Apache enforce policies about binaries not released under the Apache
> name? Wouldn't that sort of policy be in contradiction to the Apache
> license?
>
> Keeping a best practice which is not only unenforceable and inconsistent,
> but also disadvantageous to any project which tries to follow it,
> discredits other best practices as well. (Broken windows theory)
>
> Greets from Germany
> Myrle
>
>
> On Tue, Jan 3, 2017 at 12:34 PM, John D. Ament <johndam...@apache.org>
> wrote:
>
> > Carsten, Julian,
> >
> > I want to reiterate my notes from a prior message [1] in case there is
> any
> > confusion over the ask.  There is a "best practice" around maven specific
> > releases that has been treated as policy,  [2].  This best practice for
> > some reason is only applied if you are using the maven build tool.  E.g.
> > published python packages, ruby gems do not have this requirement.  The
> > purpose of this thread is to realign maven specific releases with the
> other
> > convenience binaries published by podlings.
> >
> > This is not intended to drop the -incubator/-incubating tag applied to
> > source releases.  It was however established in 2008 [3] that releases
> > published by the incubator were endorsed, the -incubator/incubating tag
> was
> > to imply that the project itself was not considered stable and could go
> > away.
> >
> > John
> >
> > [1]:
> > https://lists.apache.org/thread.html/c6daddf2d564685acdcd14a876bebf
> > 392b25c268905b353e36b3cac5@%3Cgeneral.incubator.apache.org%3E
> > [2]:
> > http://incubator.apache.org/guides/release-java.html#best-practice-maven
> > [3]:
> > https://lists.apache.org/thread.html/0b6c065a908c5f9ec39fa78c31b39c
> > 83a6fea29eb34fada0ee070413@1222432864@%3Cgeneral.incubator.apache.org%3E
> >
> >
> > On Tue, Jan 3, 2017 at 1:47 AM Carsten Ziegeler <cziege...@apache.org>
> > wrote:
> >
> > > -1
> > >
> > > I followed the "other thread" but it's still unclear to me what real
> > > problem this tries to solve.
> > > As others noted, there should be an indicator whether this is already
> an
> > > official Apache project or in the incubator and adding it to the
> version
> > > information is the solution with causes the least amount of pain for
> > > users. It's a simple marker, clearly visible for any user.
> > > And once the project is out of the incubator, users simply need to
> > > update to a new version - something which they would do anyway.
> > >
> > > Carsten
> > >
> > > John D. Ament wrote
> > > > All,
> > > >
> > > > I'm calling to vote on a proposed policy change.  Current guide at
> [1]
> > > > indicates that maven artifacts should include incubator (or
> incubating)
> > > in
> > > > the version string of maven artifacts.  Its labeled as a best
> practice,
> > > not
> > > > a requirement and is not a policy followed on other repository
> > management
> > > > tools (e.g. PyPi).
> > > >
> > > > I therefore push forward that the incubator will cease expecting
> > > java-based
> > > > projects to publish artifacts with "-incubat

[ANNOUNCE] Apache BatchEE 0.4-incubating Release

[Romain Manni-Bucau]

The Apache BatchEE and Incubator teams are pleased to announce the release
of Apache BatchEE 0.4-incubating.

The release passes the JBatch 1.0 TCK test 1.1-b03.

Sources are available on Apache download area (
https://www.apache.org/dyn/closer.cgi/incubator/batchee) accessible through
BatchEE site menu and binaries are on central.


Release Notes - BatchEE - Version 0.4-incubating

** Bug
* [BATCHEE-38] - readOnly mode is broken on a few containers
* [BATCHEE-54] - After retry-with-rollback, 1-at-a-time processing
continues for the rest of the step.   Numerous areas where
ChunkStepController's sequence of calls is out-of-synch with spec.
* [BATCHEE-68] - update plugins and dependencies to latest versions
* [BATCHEE-73] - stochastic tck test-failure in
JobOperatorTests.testJobOperatorAbandonJobDuringARestart
* [BATCHEE-88] - rollback fails if the connection already got closed by
the container
* [BATCHEE-89] - replace geronimo-tx-components with just the tx api
* [BATCHEE-95] - stop partitioned batches throws exception for already
completed executions
* [BATCHEE-96] - StepExecutionEntity and JobExecutionEntity violate the
JPA2.0 Spec
* [BATCHEE-97] - JPQL Error in JobInstanceEntity
* [BATCHEE-106] - batchee cli script not working on cygwin
* [BATCHEE-107] - JobOperator#getJobNames() is slow if many Batches
exist

** Improvement
* [BATCHEE-98] - try to find batches not executed in embedded mode for
BatchEE servlet
* [BATCHEE-99] - add batch Metrics to simplerest
* [BATCHEE-100] - Add README.md from info available on offical site
* [BATCHEE-109] - Remove SecurityService
* [BATCHEE-111] - upgrade batchee to tomee 7

** New Feature
* [BATCHEE-94] - provide EE JPA provider implementations


Regards,
Romain

[RESULT][VOTE] Apache BatchEE 0.4-incubating

[Romain Manni-Bucau]

And here is my +1

So we have 3 +1 bindings (Justin, JB, me) and 1 +1 non binding (Stian) and
no other votes so the release passes.

Thanks to all who had a look.

Will continue with the release steps.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-09-27 12:50 GMT+02:00 Stian Soiland-Reyes <st...@apache.org>:

> OpenJDK 1.8.0 from Ubuntu 16.04.
> Java version: 1.8.0_91, vendor: Oracle Corporation
>
> It seems it was a threading issue as I was using the optimistic -T1.0C
> - which of course is not required to work. My fault!
>
> The build works now (but of course takes a bit longer :).
>
> [INFO] BUILD SUCCESS
>
> My vote changed to +1 (non-binding) -  if you carry over your three
> IPMC-binding votes you should be good to go.
>
>
> On 27 September 2016 at 11:27, Mark Struberg <strub...@yahoo.de.invalid>
> wrote:
> > That's weird. Which Java version do you exactly use?
> > I did run the full build with java7 and it passed perfectly fine.
> >
> >
> > LieGrue,
> > strub
> >
> >
> > On Tuesday, 27 September 2016, 12:24, Stian Soiland-Reyes <
> st...@apache.org> wrote:
> >>-0 (non-binding)  -- changes my previous -1 vote after dist/ was
> populated.
> >>
> >>I'm afraid it's not positive vote from me as the unit tests were
> >>failing the build, otherwise I would say +1. But feel free to ignore
> >>this vote :)
> >>
> >>
> >>-1 .md5 .sha1 missing from dist
> >>+1 valid .asc signature
> >>-1 KEYS file missing
> >>+1 dist matches mvn (same sha1 of batchee-0.4-incubating-source-
> release.zip)
> >>+1 LICENSE
> >>+0 NOTICE:  should say "Apache Batchee" instead of "Batchee".
> >>Copyright should be 2013-2016 (or so), not just 2016.
> >>-0 DISCLAIMER present - but it says "Apache Sirona" instead of "Apache
> >>BatchEE" (already fixed in git)
> >>+1 no binaries in source archive
> >>+1 mvn apache-rat:check (but jbatch/.../jaxb/* don't have ASF headers)
> >>-1 mvn clean install fails
> >>+1 source kind of match git commit
> >>985047e8cefb46056fcb0bda36af096a0d228fa2 (except LICENSE, NOTICE,
> >>.gitignore, DEPENDENCIES)
> >>-0 git tag missing LICENSE, NOTICE (already fixed in git master)
> >>
> >>
> >>I would recommend for the JAXB generated files to use the
> >>maven-jaxb-plugin from src/main/xsd so that the generated files end up
> >>in target/generated-sources instead of being checked in.  If they have
> >>to stay (e.g. because they have been modified post generation (uh
> >>oh..)) then they should have the ASF header as they are derived from
> >>the ASF-licensed xsds.
> >>
> >>
> >>Build failure:
> >>
> >>[INFO] BatchEE :: GUI :: JAXRS :: Server .. FAILURE [
> 19.111 s]
> >>
> >>Tests run: 9, Failures: 1, Errors: 8, Skipped: 0, Time elapsed: 3.912
> >>sec <<< FAILURE! - in org.apache.batchee.jaxrs.server.RestTest
> >>getRunningExecutions(org.apache.batchee.jaxrs.server.RestTest)  Time
> >>elapsed: 0.772 sec  <<< FAILURE!
> >>java.lang.AssertionError: expected:<500> but was:<404>
> >>at org.junit.Assert.fail(Assert.java:88)
> >>at org.junit.Assert.failNotEquals(Assert.java:834)
> >>at org.junit.Assert.assertEquals(Assert.java:645)
> >>at org.junit.Assert.assertEquals(Assert.java:631)
> >>at org.apache.batchee.jaxrs.server.RestTest.
> getRunningExecutions(RestTest.java:82)
> >>
> >>
> >>and then loads of these:
> >>
> >>getJobExecution(org.apache.batchee.jaxrs.server.RestTest)  Time
> >>elapsed: 0.079 sec  <<< ERROR!
> >>org.apache.cxf.jaxrs.client.ServerWebApplicationException:
> >>Apache Tomcat/7.0.50 - Error
> >>report<!--H1
> >>{font-family:Tahoma,Arial,sans-serif;color:white;
> background-color:#525D76;font-size:22px;}
> >>H2 {font-family:Tahoma,Arial,sans-serif;color:white;
> background-color:#525D76;font-size:16px;}
> >>H3 {font-family:Tahoma,Arial,sans-serif;color:white;
> background-color:#525D76;font-size:14px;}
> >>BODY {font-family:Tahoma,Arial,sans-serif;color:black;
>

Re: [VOTE] Apache BatchEE 0.4-incubating

[Romain Manni-Bucau]

added asc (thanks to have caught that!)


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-09-26 18:54 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>:

> + md5 and sha1
>
>
> LieGrue,
> strub
>
> PS: thanks for the review again!
>
>
>
>
> > On Monday, 26 September 2016, 18:43, John D. Ament <
> johndam...@apache.org> wrote:
> > > Can you include the .asc file?
> >
> > John
> >
> > On Mon, Sep 26, 2016 at 12:32 PM Romain Manni-Bucau
> > <rmannibu...@gmail.com>
> > wrote:
> >
> >>  added batchee source zip there
> >>  https://dist.apache.org/repos/dist/dev/incubator/batchee/0.
> 4-incubating/
> >>
> >>
> >>  Romain Manni-Bucau
> >>  @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >>  <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> >>  <http://rmannibucau.wordpress.com> | Github <
> >>  https://github.com/rmannibucau> |
> >>  LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> >>  <http://www.tomitribe.com> | JavaEE Factory
> >>  <https://javaeefactory-rmannibucau.rhcloud.com>
> >>
> >>  2016-09-26 18:03 GMT+02:00 Romain Manni-Bucau
> > <rmannibu...@gmail.com>:
> >>
> >>  > creating dist/dev, please be patient a moment
> >>  >
> >>  >
> >>  > Romain Manni-Bucau
> >>  > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >>  > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> >>  > <http://rmannibucau.wordpress.com> | Github
> >>  > <https://github.com/rmannibucau> | LinkedIn
> >>  > <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> >>  > <http://www.tomitribe.com> | JavaEE Factory
> >>  > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> >>  >
> >>  > 2016-09-26 17:59 GMT+02:00 Romain Manni-Bucau
> > <rmannibu...@gmail.com>:
> >>  >
> >>  >>
> >>  >>
> >>  >> 2016-09-26 17:56 GMT+02:00 Stian Soiland-Reyes
> > <st...@apache.org>:
> >>  >>
> >>  >>> On 26 September 2016 at 16:45, Mark Struberg
> > <strub...@yahoo.de.invalid
> >>  >
> >>  >>> wrote:
> >>  >>> > Again the question is not about our own repo. The problem
> > are the
> >>  >>> dozen downstream repos. You cannot delete it from there once
> > it got
> >>  pulled
> >>  >>> downstream. Or is there now a way to prevent downstream
> > replication?
> >>  How
> >>  >>> does that work?
> >>  >>>
> >>  >>> Just a thought .. you can push to other refs/ than heads/ and
> > tags/
> >>  >>>
> >>  >>>
> >>  >>>
> > stain@biggiebuntu:~/src/taverna/incubator-taverna-maven-parent$ git
> >>  >>> push origin
> >>  f9e049adc3cc079b9efedbbea9cefcaa2ae85c7b:refs/tmp/3-incubati
> >>  >>> ng-SNAPSHOT
> >>  >>>
> >>  >>> https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-
> >>  >>> maven-parent.git;a=shortlog;h=refs/tmp/3-incubating-SNAPSHOT
> >>  >>>
> >>  >>> does not seem to be show on
> >>  >>> https://github.com/apache/incubator-taverna-maven-parent as a
> > branch
> >>  >>> or tag
> >>  >>>
> >>  >>> but exists as a commit:
> >>  >>>
> >>  >>> https://github.com/apache/incubator-taverna-maven-parent/com
> >>  >>> mit/f9e049adc3cc079b9efedbbea9cefcaa2ae85c7b
> >>  >>>
> >>  >>>
> >>  >>> bug or feature?
> >>  >>>
> >>  >>> I don't think it's too usable, as you have to do git
> > fetch origin
> >>  >>> refs/tmp/3-incubating-SNAPSHOT -- and you would also fight
> > with Maven
> >>  >>> release plugin to do so.. But it's not all black and
> > white. :)
> >>  >>>
> >>  >>>
> >>  >> Think I'll leave that topic for this thread since it has been
> > discussed
> >>  >> several times and we can change it later but not the moment IMHO.
> >>  >>
> >>  >>
> >>  >>>
> >>  >>> --
> >>  >>> Stian Soiland-Reyes
> >>  >>> http://orcid.org/-0001-9842-9718
> >>  >>>
> >>  >>>
> > -
> >>  >>> 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] Apache BatchEE 0.4-incubating

[Romain Manni-Bucau]

added batchee source zip there
https://dist.apache.org/repos/dist/dev/incubator/batchee/0.4-incubating/


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-09-26 18:03 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:

> creating dist/dev, please be patient a moment
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2016-09-26 17:59 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>
>>
>>
>> 2016-09-26 17:56 GMT+02:00 Stian Soiland-Reyes <st...@apache.org>:
>>
>>> On 26 September 2016 at 16:45, Mark Struberg <strub...@yahoo.de.invalid>
>>> wrote:
>>> > Again the question is not about our own repo. The problem are the
>>> dozen downstream repos. You cannot delete it from there once it got pulled
>>> downstream. Or is there now a way to prevent downstream replication? How
>>> does that work?
>>>
>>> Just a thought .. you can push to other refs/ than heads/ and tags/
>>>
>>>
>>> stain@biggiebuntu:~/src/taverna/incubator-taverna-maven-parent$ git
>>> push origin f9e049adc3cc079b9efedbbea9cefcaa2ae85c7b:refs/tmp/3-incubati
>>> ng-SNAPSHOT
>>>
>>> https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-
>>> maven-parent.git;a=shortlog;h=refs/tmp/3-incubating-SNAPSHOT
>>>
>>> does not seem to be show on
>>> https://github.com/apache/incubator-taverna-maven-parent as a branch
>>> or tag
>>>
>>> but exists as a commit:
>>>
>>> https://github.com/apache/incubator-taverna-maven-parent/com
>>> mit/f9e049adc3cc079b9efedbbea9cefcaa2ae85c7b
>>>
>>>
>>> bug or feature?
>>>
>>> I don't think it's too usable, as you have to do git fetch origin
>>> refs/tmp/3-incubating-SNAPSHOT -- and you would also fight with Maven
>>> release plugin to do so.. But it's not all black and white. :)
>>>
>>>
>> Think I'll leave that topic for this thread since it has been discussed
>> several times and we can change it later but not the moment IMHO.
>>
>>
>>>
>>> --
>>> Stian Soiland-Reyes
>>> http://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] Apache BatchEE 0.4-incubating

[Romain Manni-Bucau]

creating dist/dev, please be patient a moment


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-09-26 17:59 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:

>
>
> 2016-09-26 17:56 GMT+02:00 Stian Soiland-Reyes <st...@apache.org>:
>
>> On 26 September 2016 at 16:45, Mark Struberg <strub...@yahoo.de.invalid>
>> wrote:
>> > Again the question is not about our own repo. The problem are the dozen
>> downstream repos. You cannot delete it from there once it got pulled
>> downstream. Or is there now a way to prevent downstream replication? How
>> does that work?
>>
>> Just a thought .. you can push to other refs/ than heads/ and tags/
>>
>>
>> stain@biggiebuntu:~/src/taverna/incubator-taverna-maven-parent$ git
>> push origin f9e049adc3cc079b9efedbbea9cefcaa2ae85c7b:refs/tmp/3-incubati
>> ng-SNAPSHOT
>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-
>> maven-parent.git;a=shortlog;h=refs/tmp/3-incubating-SNAPSHOT
>>
>> does not seem to be show on
>> https://github.com/apache/incubator-taverna-maven-parent as a branch
>> or tag
>>
>> but exists as a commit:
>>
>> https://github.com/apache/incubator-taverna-maven-parent/
>> commit/f9e049adc3cc079b9efedbbea9cefcaa2ae85c7b
>>
>>
>> bug or feature?
>>
>> I don't think it's too usable, as you have to do git fetch origin
>> refs/tmp/3-incubating-SNAPSHOT -- and you would also fight with Maven
>> release plugin to do so.. But it's not all black and white. :)
>>
>>
> Think I'll leave that topic for this thread since it has been discussed
> several times and we can change it later but not the moment IMHO.
>
>
>>
>> --
>> Stian Soiland-Reyes
>> http://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] Apache BatchEE 0.4-incubating

[Romain Manni-Bucau]

2016-09-26 17:56 GMT+02:00 Stian Soiland-Reyes :

> On 26 September 2016 at 16:45, Mark Struberg 
> wrote:
> > Again the question is not about our own repo. The problem are the dozen
> downstream repos. You cannot delete it from there once it got pulled
> downstream. Or is there now a way to prevent downstream replication? How
> does that work?
>
> Just a thought .. you can push to other refs/ than heads/ and tags/
>
>
> stain@biggiebuntu:~/src/taverna/incubator-taverna-maven-parent$ git
> push origin f9e049adc3cc079b9efedbbea9cefcaa2ae85c7b:refs/tmp/3-
> incubating-SNAPSHOT
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-
> maven-parent.git;a=shortlog;h=refs/tmp/3-incubating-SNAPSHOT
>
> does not seem to be show on
> https://github.com/apache/incubator-taverna-maven-parent as a branch
> or tag
>
> but exists as a commit:
>
> https://github.com/apache/incubator-taverna-maven-parent/commit/
> f9e049adc3cc079b9efedbbea9cefcaa2ae85c7b
>
>
> bug or feature?
>
> I don't think it's too usable, as you have to do git fetch origin
> refs/tmp/3-incubating-SNAPSHOT -- and you would also fight with Maven
> release plugin to do so.. But it's not all black and white. :)
>
>
Think I'll leave that topic for this thread since it has been discussed
several times and we can change it later but not the moment IMHO.


>
> --
> Stian Soiland-Reyes
> http://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] Apache BatchEE 0.4-incubating

[Romain Manni-Bucau]

Think you lost me a bit :s

so here where we started the fork from:
http://apache-incubator-general.996316.n3.nabble.com/Re-DISCUSS-jbatch-impl-Apache-td36529.html

About dist: should i push it there now or is that a todo for next release?


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-09-26 17:48 GMT+02:00 Stian Soiland-Reyes <st...@apache.org>:

> I didn't want to start a git tag best practices war :)
>
> I think we agree that as long as a commit ID is in the email, and/or
> the hash of the source distribution, then we know what we're voting on
> and their location is not so important.  If you want to skip those,
> then my opinion is that the release candidate must be on a
> *.apache.org server - ideally with some kind of log.
>
>
> I am flagging it mainly as I got a bit concerned when adding up
> several issues around Batchee releases - it should be easy to fix with
> a few svn commands on https://dist.apache.org/repos/dist/.
>
> The older Batchee releases are already voted over - although without
> checksums in the email - but this is the incubator so I guess they can
> just be dug out from
> https://repository.apache.org/content/repositories/releases/
> org/apache/batchee/batchee/
> (ode Archaeologists go check those git tags!)
>
>
>
>
> On 26 September 2016 at 16:22, Mark Struberg <strub...@yahoo.de> wrote:
> > Stian, this is established practice in the ASF since the very early days
> of playing with GIT.
> > It is used e.g. in the following TLPs:
> > TomEE
> > DeltaSpike
> > Johnzon
> > CouchDB
> > Maven
> > and many, many more!
> >
> >
> > It also got discussed on members, infra and even board lists.
> >
> > The nice thing about GIT is that it absolutely doesn't matter where I
> push the commit to as long as the sha1 of the commit later pushed to the
> ASF repo is the same.
> >
> >
> > Regarding 'pushing something different'. I trust an ASF member that he
> doesn't do that. Plus we have the sha as explained before.
> > Regarding 'not getting pushed at all': This would get catched pretty
> quickly as we would miss the version update ;)
> >
> >
> > Also bear in mind that ASF projects do NOT vote on the tags nor branches
> - we solely vote on the release source distributable!
> >
> >
> >
> >> branches are there to be created and removed again
> > Branches in GIT _cannot_ get removed from any downstream repo!
> >
> > That's the whole point. And if you do RCs, then you actually would have
> to later do a NEW vote again with the 'RC' removed from the version. But
> who guarantees that the source tarball is the same now? What if someone
> changed the source in the meantime? You see, it also has flaws.
> >
> >> Perhaps "git tag --sign" so you get a PGP-signed tag commit
> >
> >> would be a good idea?
> >
> > Agree, would be a good idea!
> > It happens that I wrote the Maven GIT integration somewhen in the
> 2000s... ;)
> >
> > We don't have the tagging feature yet. Could you please file a ticket
> against Maven SCM?
> >
> >
> > txs and LieGrue,
> > strub
> >
> >
> >
> >
> >> On Monday, 26 September 2016, 16:34, Stian Soiland-Reyes <
> st...@apache.org> wrote:
> >> > On 26 September 2016 at 14:34, Mark Struberg
> <strub...@yahoo.de.invalid>
> >> wrote:
> >>>  We *never* push commits for in-progress votes to hte ASF repos when
> we use
> >> GIT!
> >>>  The reason is that we cannot get rid of those afterwards! Of course
> we can
> >> delete the branch/tag/commit from the ASF repo, but we cannot delete
> them from
> >> all the hundreds downstream repos which almost immediately pull those
> changes...
> >>>
> >>>  You can think of pushing this to a private (but PMC owned!) github
> repo as
> >> kind of parallel to the Maven 'staging'  process.
> >>
> >> Of course it is up to each project what particular release/tag
> >> practice they want to follow. Many projects do this classically even
> >> with git, e.g. using branches or tags like 0.4-RC1 - see for instance:
> >>
> >> https://lists.apache.org/list.html?d...@jena.apache.org:lte=10M:VOTE
> >&g

Re: [VOTE] Apache BatchEE 0.4-incubating

[Romain Manni-Bucau]

2016-09-26 15:20 GMT+02:00 Stian Soiland-Reyes <st...@apache.org>:

> On 26 September 2016 at 07:28, Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
> > Hi guys,
> >
> > batchee community voted the 0.4-incubating good to release, here is the
> > time for general@ to vote on it as well
>
> -1 (non-binding)
>
> Your vote email didn't include any hashes or commit IDs - please
> provide these those next time.
>
>
This is this one
https://github.com/rmannibucau/incubator-batchee/commit/985047e8cefb46056fcb0bda36af096a0d228fa2
corresponding to
https://git-wip-us.apache.org/repos/asf?p=incubator-batchee.git;a=commit;h=0dabf849ce59fa26d4dbde301335b74e5715ca2f
on asf (tag intentionnally not pushed yet, see next comment)


>
> > Tag: https://github.com/rmannibucau/incubator-batchee/
> > tree/batchee-0.4-incubating
>
> I would appreciate if the tag under voting was not under a personal
> GitHub account.
>
> Your suggested tag is of commit
> 985047e8cefb46056fcb0bda36af096a0d228fa2, which is not on
> git.apache.org
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-batchee.
> git;a=commit;h=985047e8cefb46056fcb0bda36af096a0d228fa2
>
>
This was intended and will likely stay that way for future releases (like
on several asf projects using git) to avoid to push cancelled tag on asf
repos (cause you can't delete a tag from a git repo without advanced infra
work).

Side note: don't read it as a personal opinion please but as the followed
rule.

Difference in hashes comes from the fact Reinhard committed after the tag
has been created and I pushed the release hashes with the notice/license
commits - yes I should maybe have removed them. However no big deal there
since the tag itself is not yet on ASF and will be sync-ed only when this
vote will pass.


> However I find an alternative commit:
> https://git-wip-us.apache.org/repos/asf?p=incubator-batchee.
> git;a=commit;h=0dabf849ce59fa26d4dbde301335b74e5715ca2f
>
>
> I didn't investigate further if the commits are content-wise different or
> not.
>
>
> Note that it is not a strict ASF requirement that there is a matching
> tag (the vote is on the source archive) - but personally I can't
> support a release without commits/tag in the official repository.
>
>
> --
> Stian Soiland-Reyes
> http://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] Apache BatchEE 0.4-incubating

[Romain Manni-Bucau]

2016-09-26 11:31 GMT+02:00 Justin Mclean :

> Hi,
>
> > Comes from OpenEJB for cli - thought it was ok to rely on transitive
> > dependencies there - and for the maven plugin it is JUNG (BSD) so think
> it
> > is ok, did I miss one?
>
> I think so but it not clear to me when those LICENSES end up.
>
> MPL and CDDL (known at category B) are not OK in source releases [1] so as
> long at that followed it’s all OK.
>
>
Not in source AFAIK but binaries transitively.


> Thanks,
> Justin
>
> [1] http://www.apache.org/legal/resolved.html#category-b
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Apache BatchEE 0.4-incubating

[Romain Manni-Bucau]

2016-09-26 11:27 GMT+02:00 Justin Mclean :

> Hi,
>
> > No, we didn't get an official grant, but the RI is ALv2 and we actively
> asked the IBM devs/managers and they are perfectly fine with it. They even
> give feedback on JIRA and contributed patches later on.
> >
> > We are actively working together so to say.
> > But by not having a grant we cannot change the copyright for those files.
>
> Thanks for that that sounds fine to me. ASF policy to to not add copyright
> lines to ASF headers, but if they are a 3rd parties then I guess that needs
> to be respected.
>
> One last question - does the IBM project have a NOTICE file?
>
>
yes there https://github.com/WASdev/standards.jsr352.jbatch . I think we
are good - at least we were when imported the code.


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

Re: [VOTE] Apache BatchEE 0.4-incubating

[Romain Manni-Bucau]

2016-09-26 10:21 GMT+02:00 Justin Mclean :

> Hi,
>
> +0 until IBM copyright question sorted. Happy to change to +1 if there’s a
> good reason for it.
>
> I’d guess that the code come from them in a software grant and the
> copyright has just been forgotten to be removed and IBM added to the NOTICE
> file?
>
>
Mark answered that one I think


> I checked:
> - inculcating in name
> - signature and hashes correct
> - DISCLAIMER exists
> - LICENSE is missing normalise.css found inside this file [4] and for
> jQuery [5] Please fix in next release.
>

added
https://git-wip-us.apache.org/repos/asf?p=incubator-batchee.git;a=commitdiff;h=6caf91cc17547b47f4c803d5212c7d88f7488cad


> - NOTICE correct
> - No binary files in release
> - All source files have ASF header but there’s an issue with IBM copyright
> - Can compile from source
>
> It would be use to place the artefacts here [1] for voting on that was
> they can be released with an svn move.
>
> I’m a little confused by these [2][3] They contain BSD. MIT, MPL, CDDL
> licenses but it’s not mentioned in LICENSE.
>
>
Comes from OpenEJB for cli - thought it was ok to rely on transitive
dependencies there - and for the maven plugin it is JUNG (BSD) so think it
is ok, did I miss one?


> There are several files e.g. with ASF header with copyright 2012 or 2013
> International Business Machines Corp. Is this correct? If so what ASv2
> licensed software did they come from or were they part of a software grant?
>
> Thanks,
> Justin
>
> 1. https://dist.apache.org/repos/dist/dev/incubator/batchee
> 2. ./tools/maven-plugin/src/main/resources/META-INF/LICENSE
> 3 ./tools/cli/src/main/resources/META-INF/LICENSE
> 4. ./gui/servlet/embedded/src/main/resources/META-INF/
> resources/internal/batchee/css/bootstrap.min.3.0.0.css
> 5. ./gui/servlet/embedded/src/main/resources/META-INF/
> resources/internal/batchee/js/jquery-2.0.3.min.js
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

[VOTE] Apache BatchEE 0.4-incubating

[Romain Manni-Bucau]

Hi guys,

batchee community voted the 0.4-incubating good to release, here is the
time for general@ to vote on it as well

dev@ result:
http://mail-archives.apache.org/mod_mbox/batchee-dev/201609.mbox/browser

Here is the release note: https://issues.apache.org/jira/secure/ReleaseNote.
jspa?projectId=12314924=12334147

Staging repo: https://repository.apache.org/content/repositories/
orgapachebatchee-1004/ (yes numbers are funny sometimes ;))

Source zip: https://repository.apache.org/content/repositories/
orgapachebatchee-1004/org/apache/batchee/batchee/0.4-incubating/batchee-0.4-
incubating-source-release.zip

Tag: https://github.com/rmannibucau/incubator-batchee/
tree/batchee-0.4-incubating

My gpg key is in tomee KEYS file (https://dist.apache.org/
repos/dist/release/tomee/KEYS)

Please VOTE
[+1] yep
[+0] don’t care
[-1] no cause [...]

The VOTE is open for 72h or as needed

Thanks,
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

Fwd: [VOTE] Apache BatchEE 0.4-incubating

[Romain Manni-Bucau]

Hi general@!

FYI the BatchEE incubation project is votiing on batchee 0.4-incubating

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

-- Forwarded message --
From: Romain Manni-Bucau <rmannibu...@gmail.com>
Date: 2016-09-22 18:16 GMT+02:00
Subject: [VOTE] Apache BatchEE 0.4-incubating
To: "d...@batchee.incubator.apache.org" <d...@batchee.incubator.apache.org>


Hi guys,

we discussed it several time so here it is: the vote for batchee N+1

Here is the release note: https://issues.apache.org/jira/secure/ReleaseNote.
jspa?projectId=12314924=12334147

Staging repo: https://repository.apache.org/content/repositories/
orgapachebatchee-1004/ (yes numbers are funny sometimes ;))

Source zip: https://repository.apache.org/content/repositories/
orgapachebatchee-1004/org/apache/batchee/batchee/0.4-incubating/batchee-0.4-
incubating-source-release.zip

Tag: https://github.com/rmannibucau/incubator-batchee/
tree/batchee-0.4-incubating

My gpg key is in tomee KEYS file (https://dist.apache.org/
repos/dist/release/tomee/KEYS) - didn't find the batchee one ATM

Please VOTE
[+1] yep
[+0] don’t care
[-1] no cause [...]

The VOTE is open for 72h

Thanks,
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

Re: [DRAFT] Incubator PMC Board Report - August 2016

[Romain Manni-Bucau]

An internal/asf EE umbrella rather.

BatchEE got more exposure than most G shared projects so not super
motivating from my point of view.

What is the real issue staying self contained? Why should a project get 500
commits and 500 mails a month once stable - or what is the evaluation there?

Le 8 août 2016 22:48, "Mark Struberg" <strub...@yahoo.de.invalid> a écrit :

> Given that Geronimo is nowadays more a kind of „EE commons“, it might fit
> in there.
>
> LieGrue,
> strub
>
>
> > Am 08.08.2016 um 22:32 schrieb Romain Manni-Bucau <rmannibu...@gmail.com
> >:
> >
> > Le 8 août 2016 21:04, "Jean-Baptiste Onofré" <j...@nanthrax.net> a écrit :
> >>
> >> Hi John,
> >>
> >> I've probably missed your ping. That's right that last month I didn't
> > sign for two reasons:
> >> 1. the report was empty
> >> 2. I don't see lot of activity on the BatchEE project:
> >> 2.1. There are some commits (
> > https://github.com/apache/incubator-batchee/commits/master) but not
> super
> > active
> >> 2.2. Same for the mailing lists:
> >>  http://mail-archives.apache.org/mod_mbox/incubator-batchee-user/
> >>  http://mail-archives.apache.org/mod_mbox/incubator-batchee-dev/
> >>
> >> I'm not sure that BatchEE can be a project by its own as I'm not sure we
> > have a community around (especially an user community).
> >
> > To be honest got very various feesback from tomcat, standalone and tomee
> > users. Putting batchee behind tomee or geronimo would kill the remaining
> > 66% of users IMO and the community would be quite weird or not
> > heterogeneous at least (so not a real one). That to say i have a very
> mixes
> > feeling about umbrella projects.
> >
> >> I agree with Romain that BatchEE could be part of a kind of umbrella
> > project.
> >> If we have good sign that we have an user community around, then it
> makes
> > sense to discuss about graduation.
> >>
> >> Regards
> >> JB
> >>
> >>
> >> On 08/08/2016 05:57 PM, John D. Ament wrote:
> >>>
> >>> Romain,
> >>>
> >>> I've actually been pushing to get BatchEE to graduate for some time.
> > IMHO
> >>> there's no more benefit in the incubator for you guys.
> >>>
> >>> I'm pointing out the issue, as last month a mentor refused sign off due
> > to
> >>> lack of content in your report.  The current report doesn't seem to be
> > much
> >>> better.  I pinged JB off list, so far no answer there either.
> >>>
> >>> - John
> >>>
> >>> On Mon, Aug 8, 2016 at 11:49 AM Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>
> >>> wrote:
> >>>
> >>>> Hi John,
> >>>>
> >>>> Think we can be blamed to not have answered you but we took actions in
> >>>> general. That said Mark was more pointing out that if there are issues
> > with
> >>>> the content it should probably be sent to batchee too explaining why
> and
> >>>> what is expected/how we can enhance it. Typically this time you
> pointed
> > out
> >>>> it was "too empty" for you but I'm not sure there is a list I'm not
> > aware
> >>>> of but it would have been completely silently ignored cause batchee@
> >>>> wouldn't have been notified of that.
> >>>>
> >>>> More generally it is quite hard to fill this report for stable
> projects
> >>>> (which doesn't mean they are not alive but just they are stable enough
> > to
> >>>> not get as much activity as BigData projects ;)). I'm not sure we
> should
> >>>> group them either in a new umbrella project or an existing one -
> > typically
> >>>> we could create an inconsistent bucket in term of user communities but
> >>>> consistent in term of maintainers/asf guys - or just keep it like that
> > but
> >>>> this "issue" will come back regularly I think and it would be great to
> >>>> "skip" these round trips if possible and have a clear statement about
> >>>> projects having by design an irregular activity - thinking to EE
> > projects
> >>>> which have a big activity after spec releases then mainly just
> > maintenance
> >>>> until next round.
> >>>>
> >>>> You probably guessed that I would love to avoid to let small proje

Re: [DRAFT] Incubator PMC Board Report - August 2016

[Romain Manni-Bucau]

Le 8 août 2016 21:04, "Jean-Baptiste Onofré" <j...@nanthrax.net> a écrit :
>
> Hi John,
>
> I've probably missed your ping. That's right that last month I didn't
sign for two reasons:
> 1. the report was empty
> 2. I don't see lot of activity on the BatchEE project:
> 2.1. There are some commits (
https://github.com/apache/incubator-batchee/commits/master) but not super
active
> 2.2. Same for the mailing lists:
>   http://mail-archives.apache.org/mod_mbox/incubator-batchee-user/
>   http://mail-archives.apache.org/mod_mbox/incubator-batchee-dev/
>
> I'm not sure that BatchEE can be a project by its own as I'm not sure we
have a community around (especially an user community).

To be honest got very various feesback from tomcat, standalone and tomee
users. Putting batchee behind tomee or geronimo would kill the remaining
66% of users IMO and the community would be quite weird or not
heterogeneous at least (so not a real one). That to say i have a very mixes
feeling about umbrella projects.

> I agree with Romain that BatchEE could be part of a kind of umbrella
project.
> If we have good sign that we have an user community around, then it makes
sense to discuss about graduation.
>
> Regards
> JB
>
>
> On 08/08/2016 05:57 PM, John D. Ament wrote:
>>
>> Romain,
>>
>> I've actually been pushing to get BatchEE to graduate for some time.
IMHO
>> there's no more benefit in the incubator for you guys.
>>
>> I'm pointing out the issue, as last month a mentor refused sign off due
to
>> lack of content in your report.  The current report doesn't seem to be
much
>> better.  I pinged JB off list, so far no answer there either.
>>
>> - John
>>
>> On Mon, Aug 8, 2016 at 11:49 AM Romain Manni-Bucau <rmannibu...@gmail.com
>
>> wrote:
>>
>>> Hi John,
>>>
>>> Think we can be blamed to not have answered you but we took actions in
>>> general. That said Mark was more pointing out that if there are issues
with
>>> the content it should probably be sent to batchee too explaining why and
>>> what is expected/how we can enhance it. Typically this time you pointed
out
>>> it was "too empty" for you but I'm not sure there is a list I'm not
aware
>>> of but it would have been completely silently ignored cause batchee@
>>> wouldn't have been notified of that.
>>>
>>> More generally it is quite hard to fill this report for stable projects
>>> (which doesn't mean they are not alive but just they are stable enough
to
>>> not get as much activity as BigData projects ;)). I'm not sure we should
>>> group them either in a new umbrella project or an existing one -
typically
>>> we could create an inconsistent bucket in term of user communities but
>>> consistent in term of maintainers/asf guys - or just keep it like that
but
>>> this "issue" will come back regularly I think and it would be great to
>>> "skip" these round trips if possible and have a clear statement about
>>> projects having by design an irregular activity - thinking to EE
projects
>>> which have a big activity after spec releases then mainly just
maintenance
>>> until next round.
>>>
>>> You probably guessed that I would love to avoid to let small projects be
>>> swallowed by bigger projects to skip this kind of lifecycle/activity
issue
>>> and avoid to create inconsistent (user) communities but I have to admit
I
>>> don't have a good view of the incubator freedom we can have on that
area.
>>>
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
>>> <http://rmannibucau.wordpress.com> | Github <
>>> https://github.com/rmannibucau> |
>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>>> <http://www.tomitribe.com> | JavaEE Factory
>>> <https://javaeefactory-rmannibucau.rhcloud.com>
>>>
>>> 2016-08-08 17:22 GMT+02:00 John D. Ament <johndam...@apache.org>:
>>>
>>>> On Mon, Aug 8, 2016 at 3:47 AM Mark Struberg <strub...@yahoo.de.invalid
>
>>>> wrote:
>>>>
>>>>> John, others. Would you please also add in the BatchEE amendments I
did
>>>>> today.
>>>>>
>>>>>
>>>> Next time a draft is sent, it will be picked up (its just copy and
>>>
>>> paste).
>>>>
>>>>
>>>>
>>>>> The feedback mecha

Re: [DRAFT] Incubator PMC Board Report - August 2016

[Romain Manni-Bucau]

2016-08-08 17:57 GMT+02:00 John D. Ament <johndam...@apache.org>:

> Romain,
>
> I've actually been pushing to get BatchEE to graduate for some time.  IMHO
> there's no more benefit in the incubator for you guys.
>
>
Ok so this shouldn't be understood as a blocker to graduate.


> I'm pointing out the issue, as last month a mentor refused sign off due to
> lack of content in your report.  The current report doesn't seem to be much
> better.  I pinged JB off list, so far no answer there either.
>
>
Will check as well.

Thanks John!


> - John
>
> On Mon, Aug 8, 2016 at 11:49 AM Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>
> > Hi John,
> >
> > Think we can be blamed to not have answered you but we took actions in
> > general. That said Mark was more pointing out that if there are issues
> with
> > the content it should probably be sent to batchee too explaining why and
> > what is expected/how we can enhance it. Typically this time you pointed
> out
> > it was "too empty" for you but I'm not sure there is a list I'm not aware
> > of but it would have been completely silently ignored cause batchee@
> > wouldn't have been notified of that.
> >
> > More generally it is quite hard to fill this report for stable projects
> > (which doesn't mean they are not alive but just they are stable enough to
> > not get as much activity as BigData projects ;)). I'm not sure we should
> > group them either in a new umbrella project or an existing one -
> typically
> > we could create an inconsistent bucket in term of user communities but
> > consistent in term of maintainers/asf guys - or just keep it like that
> but
> > this "issue" will come back regularly I think and it would be great to
> > "skip" these round trips if possible and have a clear statement about
> > projects having by design an irregular activity - thinking to EE projects
> > which have a big activity after spec releases then mainly just
> maintenance
> > until next round.
> >
> > You probably guessed that I would love to avoid to let small projects be
> > swallowed by bigger projects to skip this kind of lifecycle/activity
> issue
> > and avoid to create inconsistent (user) communities but I have to admit I
> > don't have a good view of the incubator freedom we can have on that area.
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2016-08-08 17:22 GMT+02:00 John D. Ament <johndam...@apache.org>:
> >
> > > On Mon, Aug 8, 2016 at 3:47 AM Mark Struberg <strub...@yahoo.de.invalid
> >
> > > wrote:
> > >
> > > > John, others. Would you please also add in the BatchEE amendments I
> did
> > > > today.
> > > >
> > > >
> > > Next time a draft is sent, it will be picked up (its just copy and
> > paste).
> > >
> > >
> > > > The feedback mechanism is great but we could improve this by also
> > sending
> > > > a mail to the respective podling if you have feedback.
> > > >
> > >
> > > I know that I've personally sent feedback/questions to BatchEE before,
> > > without any response from the podling.
> > >
> > > https://lists.apache.org/thread.html/262e43b2bb49d1ef5058a74f43b4f7
> > > c1e4ec6b9fb4f5896d28e95918@%3Cdev.batchee.apache.org%3E
> > > https://lists.apache.org/thread.html/044be9dc4b10136a7025ca5e031b33
> > > 12e2dee8b93680483a754b594e@%3Cdev.batchee.apache.org%3E
> > >
> > > - John
> > >
> > >
> > > >
> > > > That way we could fix left-overs and missed paragraphs much easier.
> > > >
> > > > txs and LieGrue,
> > > > strub
> > > >
> > > > 
> -
> > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > > For additional commands, e-mail: general-h...@incubator.apache.org
> > > >
> > > >
> > >
> >
>

Re: [DRAFT] Incubator PMC Board Report - August 2016

[Romain Manni-Bucau]

Hi John,

Think we can be blamed to not have answered you but we took actions in
general. That said Mark was more pointing out that if there are issues with
the content it should probably be sent to batchee too explaining why and
what is expected/how we can enhance it. Typically this time you pointed out
it was "too empty" for you but I'm not sure there is a list I'm not aware
of but it would have been completely silently ignored cause batchee@
wouldn't have been notified of that.

More generally it is quite hard to fill this report for stable projects
(which doesn't mean they are not alive but just they are stable enough to
not get as much activity as BigData projects ;)). I'm not sure we should
group them either in a new umbrella project or an existing one - typically
we could create an inconsistent bucket in term of user communities but
consistent in term of maintainers/asf guys - or just keep it like that but
this "issue" will come back regularly I think and it would be great to
"skip" these round trips if possible and have a clear statement about
projects having by design an irregular activity - thinking to EE projects
which have a big activity after spec releases then mainly just maintenance
until next round.

You probably guessed that I would love to avoid to let small projects be
swallowed by bigger projects to skip this kind of lifecycle/activity issue
and avoid to create inconsistent (user) communities but I have to admit I
don't have a good view of the incubator freedom we can have on that area.



Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-08-08 17:22 GMT+02:00 John D. Ament <johndam...@apache.org>:

> On Mon, Aug 8, 2016 at 3:47 AM Mark Struberg <strub...@yahoo.de.invalid>
> wrote:
>
> > John, others. Would you please also add in the BatchEE amendments I did
> > today.
> >
> >
> Next time a draft is sent, it will be picked up (its just copy and paste).
>
>
> > The feedback mechanism is great but we could improve this by also sending
> > a mail to the respective podling if you have feedback.
> >
>
> I know that I've personally sent feedback/questions to BatchEE before,
> without any response from the podling.
>
> https://lists.apache.org/thread.html/262e43b2bb49d1ef5058a74f43b4f7
> c1e4ec6b9fb4f5896d28e95918@%3Cdev.batchee.apache.org%3E
> https://lists.apache.org/thread.html/044be9dc4b10136a7025ca5e031b33
> 12e2dee8b93680483a754b594e@%3Cdev.batchee.apache.org%3E
>
> - John
>
>
> >
> > That way we could fix left-overs and missed paragraphs much easier.
> >
> > txs and LieGrue,
> > strub
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: [VOTE] Apache Sirona 0.4-incubating

[Romain Manni-Bucau]

2016-07-20 10:58 GMT+02:00 Justin Mclean :

> Hi,
>
> > can you confirm which artifacts are missing it please?
>
> All of them.
>
>
Not sure I follow:

» unzip -p
/cygdrive/c/Users/romain/.m2/repository/org/apache/sirona/sirona-reporting-ui/0.4-incubating/sirona-reporting-ui-0.4-incubating.war
META-INF/NOTICE | egrep -i 'flot|boot'
website: http://startbootstrap.com/sb-admin
Based on Bootstrap. Icons by Font Awesome.
Twitter bootstrap
website: http://getbootstrap.com/
Bootstrap datetimepicker
website: https://github.com/eternicode/bootstrap-datepicker
JQuery Flot
website: http://www.flotcharts.org/
angular-ui-bootstrap.js
website: https://angular-ui.github.io/bootstrap/
angular-bootstrap-nav-tree.js
website: https://github.com/nickperkinslondon/angular-bootstrap-nav-tree


So not all of them, what do I miss?


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

Re: [VOTE] Apache Sirona 0.4-incubating

[Romain Manni-Bucau]

Hi Justin,

can you confirm which artifacts are missing it please? typically
reporting-ui references it (
https://github.com/apache/sirona/blob/23ca6902ba1a32650b06043f68d02c951629f0bb/server/reporting/reporting-ui/src/main/resources/META-INF/NOTICE#L39)
and global one too (
https://github.com/apache/sirona/blob/23ca6902ba1a32650b06043f68d02c951629f0bb/NOTICE#L46
)


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-07-20 9:13 GMT+02:00 Justin Mclean <jus...@classsoftware.com>:

> Hi,
>
> -1 binding due to LICENSE and NOTICE issues and missing DISCLAIMER files
>
> I checked:
> - artefact names contain incubating
> - signatures and hashes good
> - source DISCLAIMER exists
> - source LICENSE is missing many things. Note that the full text of the
> license needs to be included in some cases (MIT/BSD) if it is not in the
> header of the file, this is legally required by the terms of the license.
> It best to add a pointer in the LICENSE file to the license in this case [1]
> - source NOTICE contains stuff that should be in LICENSE. There is no need
> to list permissive items in NOTICE [1][2] under most cases.
> - NOTICE contains wrong year range (2008-2013). Has the project really
> been incubating that long?
> - No unexpected binaries in source release
> - Source files have ASF headers
> - Can compile from source
>
> LICENSE Is missing:
> - jQuery Flot (MIT) which also includes jQuery resize event (dual
> MIT/GPL) [3] Note that the various plugs have different authors and license
> dates.
> - Bootstrap (MIT) [4]
> - normalize.css (MIT) [5]
> - RequireJS (dual MIT/BSD)  [7]
> - jQuery table sorter (dual MIT/GPL) [8]
> - Raphael (MIT with two copyright owners) [9]
> - morris (BSD) [10]
> - angular bootstrap nav tree (MIT) [11]
> - angular (MIT) [12]
> - jQuery (MIT) [13]
> - moment (MIT) [14]
> - ng grid (MIT) [15]
> - angular ui bootstrap [16]
> - bootstrap table [17]
> - glyph icons halflings regular fonts (MIT?) [19]
> - font awesome font (SIL OSF) [20]
> - font awesome css (MIT) [21]
>
> No need to include in LICENSE as per [2]:
> - bootstrap date time picker (Apache) [6]
> - bootstrap table (Apache) [17]
> - bootstrap (Apache) [18] Note however that both the Apache 2.0 and MIT
> versions of Bootstrap are included.
> - SB Admin HTML template (Apache) [22]
>
> For the connivence binaries:
> - DISCLAIMERs are missing
> - LICENSE files do not represent what is bundled [23] and are missing the
> Apache license text
> - NOTICE file is missing ASF part
> - NOTICE file are likely missing information from bundled Apache v2
> licensed NOTICE files [2]
> - May contain creative commons licensed Category X software? [24]
>
> Thanks,
> Justin
>
> 1. http://www.apache.org/dev/licensing-howto.html#permissive-deps
> 2  http://www.apache.org/dev/licensing-howto.html#alv2-dep
> 3.
> ./server/reporting/reporting-ui/src/main/webapp/js/plugins/flot/jquery.flot.js
> 4. ./server/reporting/reporting-ui/src/main/webapp/js/bootstrap.3.2.0.js
> 5.
> ./server/reporting/reporting-webapp/src/main/resources/resources/css/bootstrap.css
> 6.
> ./server/reporting/reporting-webapp/src/main/resources/resources/js/bootstrap-datetimepicker.min.js
> 7. ./server/reporting/reporting-ui/src/main/webapp/js/require-2.1.14.js
> 8.
> ./server/reporting/reporting-webapp/src/main/resources/resources/js/jquery.tablesorter.js
> 9.
> ./server/reporting/reporting-ui/src/main/webapp/js/plugins/morris/raphael-2.1.2.min.js
> 10.
> ./server/reporting/reporting-ui/src/main/webapp/js/plugins/morris/morris.min-0.5.0.js
> 11.
> ./server/reporting/reporting-ui/src/main/webapp/js/abn_tree_directive.js
> 12. ./server/reporting/reporting-ui/src/main/webapp/js/angular-1.3.0.js
> 13. ./server/reporting/reporting-ui/src/main/webapp/js/jquery-1.11.0.min.js
> 14. ./server/reporting/reporting-ui/src/main/webapp/js/moment-2.8.1.min.js
> 15.
> ./server/reporting/reporting-ui/src/main/webapp/js/ng-grid-2.0.12.debug.js
> 16
> ./server/reporting/reporting-ui/src/main/webapp/js/ui-bootstrap-tpls-0.11.0.js
> 17.
> ./server/reporting/reporting-webapp/src/main/resources/resources/js/bootstrap-tab.js
> 18.
> ./server/reporting/reporting-webapp/src/main/resources/resources/js/bootstrap.js
> 19. ./server/reporting/reporting-ui/src/main/webapp/fonts/
> 20.
> ./server/reporting/reporting-ui/src/main/webapp/font-awesome

Re: [VOTE] Apache Sirona 0.4-incubating

[Romain Manni-Bucau]

up?


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-07-11 22:32 GMT+02:00 John D. Ament <johndam...@apache.org>:

> Ah ok, I see it on Pony Mail:
>
> https://lists.apache.org/thread.html/ec6f2b78221d6287d0db3cc8a07fdec72161a54b7e032961f664ec70@%3Cdev.sirona.apache.org%3E
>
> Though for some reason this is marked as a private list.
>
> John
>
> On Mon, Jul 11, 2016 at 4:21 PM Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>
> > @John: JL just voted too - why i closed the vote on dev@. Seems
> > mail-archives didn't eat it yet
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2016-07-11 22:19 GMT+02:00 John D. Ament <johndam...@apache.org>:
> >
> > > Romain,
> > >
> > > I'm failing to see the vote result on dev@sirona.  I see votes from
> you
> > > and
> > > Olivier.
> > >
> > > John
> > >
> > > On Mon, Jul 11, 2016 at 4:07 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > Hi guys,
> > > >
> > > >
> > > > sirona vote passed on dev@ so here is the general vote (the dev
> thread
> > > was
> > > >
> > http://mail-archives.apache.org/mod_mbox/sirona-dev/201607.mbox/browser
> > > ).
> > > >
> > > > This release is mainly about getting fixes out + some enhancements on
> > the
> > > > path tracking + few new features to integrate with existing
> > > infrastructures
> > > > like splunk.
> > > >
> > > > Release notes:
> > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314925=12334027
> > > > Keys file: *https://www.apache.org/dist/incubator/sirona/KEYS
> > > > <https://www.apache.org/dist/incubator/sirona/KEYS>*
> > > > Tag:
> > > >
> > > >
> > >
> >
> https://svn.apache.org/repos/asf/incubator/sirona/tags/sirona-0.4-incubating/
> > > > Staging repository:
> > > >
> > https://repository.apache.org/content/repositories/orgapachesirona-1003
> > > > Dev dist:
> > > >
> > https://dist.apache.org/repos/dist/dev/incubator/sirona/0.4-incubating/
> > > >
> > > > Vote will be open for 72h or until we get 3 +1 bindings. Binding or
> not
> > > > everyone is very welcomed to test and vote.
> > > >
> > > > Please vote:
> > > > [ ] +1 release it
> > > > [ ] +0 don't care
> > > > [ ] -1 no cause ${blocker}
> > > >
> > > > Thanks,
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > > <http://www.tomitribe.com> | JavaEE Factory
> > > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > > >
> > >
> >
>

Re: [VOTE] Apache Sirona 0.4-incubating

[Romain Manni-Bucau]

@John: JL just voted too - why i closed the vote on dev@. Seems
mail-archives didn't eat it yet


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-07-11 22:19 GMT+02:00 John D. Ament <johndam...@apache.org>:

> Romain,
>
> I'm failing to see the vote result on dev@sirona.  I see votes from you
> and
> Olivier.
>
> John
>
> On Mon, Jul 11, 2016 at 4:07 PM Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>
> > Hi guys,
> >
> >
> > sirona vote passed on dev@ so here is the general vote (the dev thread
> was
> > http://mail-archives.apache.org/mod_mbox/sirona-dev/201607.mbox/browser
> ).
> >
> > This release is mainly about getting fixes out + some enhancements on the
> > path tracking + few new features to integrate with existing
> infrastructures
> > like splunk.
> >
> > Release notes:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314925=12334027
> > Keys file: *https://www.apache.org/dist/incubator/sirona/KEYS
> > <https://www.apache.org/dist/incubator/sirona/KEYS>*
> > Tag:
> >
> >
> https://svn.apache.org/repos/asf/incubator/sirona/tags/sirona-0.4-incubating/
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachesirona-1003
> > Dev dist:
> > https://dist.apache.org/repos/dist/dev/incubator/sirona/0.4-incubating/
> >
> > Vote will be open for 72h or until we get 3 +1 bindings. Binding or not
> > everyone is very welcomed to test and vote.
> >
> > Please vote:
> > [ ] +1 release it
> > [ ] +0 don't care
> > [ ] -1 no cause ${blocker}
> >
> > Thanks,
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
>

[VOTE] Apache Sirona 0.4-incubating

[Romain Manni-Bucau]

Hi guys,


sirona vote passed on dev@ so here is the general vote (the dev thread was
http://mail-archives.apache.org/mod_mbox/sirona-dev/201607.mbox/browser).

This release is mainly about getting fixes out + some enhancements on the
path tracking + few new features to integrate with existing infrastructures
like splunk.

Release notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314925=12334027
Keys file: *https://www.apache.org/dist/incubator/sirona/KEYS
<https://www.apache.org/dist/incubator/sirona/KEYS>*
Tag:
https://svn.apache.org/repos/asf/incubator/sirona/tags/sirona-0.4-incubating/
Staging repository:
https://repository.apache.org/content/repositories/orgapachesirona-1003
Dev dist:
https://dist.apache.org/repos/dist/dev/incubator/sirona/0.4-incubating/

Vote will be open for 72h or until we get 3 +1 bindings. Binding or not
everyone is very welcomed to test and vote.

Please vote:
[ ] +1 release it
[ ] +0 don't care
[ ] -1 no cause ${blocker}

Thanks,
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

Re: [VOTE] Release Apache Tamaya 0.2-incubating

[Romain Manni-Bucau]

+1
Le 10 avr. 2016 22:28, "John D. Ament"  a écrit :

> Copying my +1 from the dev list.
>
> On Sun, Apr 10, 2016 at 2:59 PM Anatole Tresch  wrote:
>
> > Hi all!
> >
> > This is a call to vote on releasing Apache Tamaya 0.2-incubating.
> >
> > The new release is a major milestone of the project with:
> >
> > - Stable and bullet proof API
> > - Support for most major config formats
> > - Support for dynamic configuration and remote backends
> > - Unified configuration injection API for SE environments, but also
> > full Java EE/CDI support.
> > - Integration with Spring, Camel and OSGI.
> >
> > The artifacts are deployed to Nexus [1] (and [2]) and to [5].
> > The tag is available at [3].
> >
> > The release notes can be found here:
> >
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-tamaya.git;a=blob_plain;f=readme/ReleaseNotes-0.2-incubating.html;hb=64f9774ea0068f8247b7db0bf2d5551073008a35
> >
> >
> > The project vote has been passed with
> >
> >   5 binding +1,
> >   one non-binding +1
> > no 0 or -1 votes
> >
> > The vote thread can be found here:
> >
> >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-tamaya-dev/201604.mbox/%3ccafjidbfnvbbobafanopwwk9oho2wj3pc0spraycxvv1uuhh...@mail.gmail.com%3E
> >
> > Please take a look at the artifacts and vote!
> >
> > Please note:
> > This vote is a "majority approval" with a minimum of three +1 votes (see
> > [4]).
> >
> > 
> > [ ] +1 for community members who have reviewed the bits
> > [ ] +0
> > [ ] -1 for fatal flaws that should cause these bits not to be
> > released, and why..
> > 
> >
> > Thanks,
> > Anatole
> >
> > [1]
> > https://repository.apache.org/content/repositories/orgapachetamaya-1019
> > [2]
> >
> https://repository.apache.org/content/repositories/orgapachetamaya-1019/org/apache/tamaya/tamaya-distribution/0.2-incubating/tamaya-distribution-0.2-incubating-distribution-src.tar.gz
> >
> >
> https://repository.apache.org/content/repositories/orgapachetamaya-1019/org/apache/tamaya/tamaya-distribution/0.2-incubating/tamaya-distribution-0.2-incubating-distribution-bin.tar.gz
> > [3]
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-tamaya.git;a=commit;h=64f9774ea0068f8247b7db0bf2d5551073008a35
> > [4] http://www.apache.org/foundation/voting.html#ReleaseVotes
> > [5]
> > https://dist.apache.org/repos/dist/dev/incubator/tamaya/0.2-incubating
> >
> >
> > --
> > *Anatole Tresch*
> > Java Engineer & Architect,
> > ​JCP Star
> >  Spec Lead
> > ​, Apache Committer​
> >
> > *Switzerland, Europe Zurich, GMT+1*
> > *Twitter:  @atsticks*
> >
>

Re: [VOTE] Graduate Johnzon from the Incubator

[Romain Manni-Bucau]

> http://markmail.org/search/?q=list%3Aorg.apache.fleece.commits
> > > >> > > >
> > > >> > > > Niall
> > > >> > > >
> > > >> > > >
> > > >> > > > On Fri, Apr 1, 2016 at 8:49 PM, Hendrik Dev <
> > > hendrikde...@gmail.com
> > > >> >
> > > >> > > > wrote:
> > > >> > > >
> > > >> > > >>  The Apache Johnzon community has discussed and voted on
> > > >> graduation to
> > > >> > > >>  a top level project. The vote passed with 8 +1 votes (5
from
> > the
> > > >> > PPMC)
> > > >> > > >>  and no 0 or -1 votes.
> > > >> > > >>
> > > >> > > >>  Incubation Status:
> > > >> > > >>  http://incubator.apache.org/projects/johnzon.html
> > > >> > > >>  Maturity Assessment:
> > > >> > > >>  https://s.apache.org/d88S
> > > >> > > >
> > > >> > > >
> > > >> > > >>  Discussions:
> > > >> > > >>  https://s.apache.org/5vxO
> > > >> > > >>  https://s.apache.org/8VkX
> > > >> > > >>  Vote:
> > > >> > > >>  https://s.apache.org/suuK
> > > >> > > >>  (http://markmail.org/message/mawumtfqokgye5xn)
> > > >> > > >>  Result:
> > > >> > > >>  https://s.apache.org/Erd0
> > > >> > > >>  (http://markmail.org/message/qmqvk56ccqkq2gob)
> > > >> > > >>
> > > >> > > >>  Please vote on the resolution pasted below to graduate
Apache
> > > >> Johnzon
> > > >> > > >>  from the incubator to top level project.
> > > >> > > >>
> > > >> > > >>  [ ] +1 Graduate Apache Johnzon from the Incubator.
> > > >> > > >>  [ ] +0 Don't care.
> > > >> > > >>  [ ] -1 Don't graduate Apache Johnzon from the Incubator
> > because
> > > >> ...
> > > >> > > >>
> > > >> > > >>  This vote will be open for at least 72 hours.
> > > >> > > >>
> > > >> > > >>  Many thanks to our mentors and everyone else for the
support,
> > > >> > > >>
> > > >> > > >>  Hendrik Saly on behalf of the Apache Johnzon PPMC
> > > >> > > >>
> > > >> > > >>  Apache Johnzon top-level project resolution:
> > > >> > > >>  
> > > >> > > >>
> > > >> > > >>  WHEREAS, the Board of Directors deems it to be in the best
> > > >> > > >>  interests of the Foundation and consistent with the
> > > >> > > >>  Foundation's purpose to establish a Project Management
> > > >> > > >>  Committee charged with the creation and maintenance of
> > > >> > > >>  open-source software, for distribution at no charge to
> > > >> > > >>  the public, related to JSR-353 compliant JSON parsing and a
> > > >> > > >>  set of useful modules to help with the usage of JSR-353
> > > >> > > >>  as well as JSR successors (like JSR-374) or related JSRs
> > > >> > > >>  (like JSR-367).
> > > >> > > >>
> > > >> > > >>
> > > >> > > >>  NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> > > >> > > >>  Committee (PMC), to be known as the "Apache Johnzon
Project",
> > > >> > > >>  be and hereby is established pursuant to Bylaws of the
> > > >> > > >>  Foundation; and be it further
> > > >> > > >>
> > > >> > > >>  RESOLVED, that the Apache Johnzon Project be and hereby is
> > > >> > > >>  responsible for the creation and maintenance of software
> > > >> > > >>  related to JSR-353 compliant JSON parsing and a
> > > >> > > >>  set of useful modules to help with the usage of JSR-353
> > > >> > > >>  as well as JSR successors (like JSR-374) or related JSRs
> > > >> > > >>  (like JSR-367); and be it further
> > > >> > > >>
> > > >> > > >>  RESOLVED, that the office of "Vice President, Apache
Johnzon"
> > be
> > > >> > > >>  and hereby is created, the person holding such office to
> > > >> > > >>  serve at the direction of the Board of Directors as the
chair
> > > >> > > >>  of the Apache Johnzon Project, and to have primary
> > > responsibility
> > > >> > > >>  for management of the projects within the scope of
> > > >> > > >>  responsibility of the Apache Johnzon Project; and be it
> > further
> > > >> > > >>
> > > >> > > >>  RESOLVED, that the persons listed immediately below be and
> > > >> > > >>  hereby are appointed to serve as the initial members of the
> > > >> > > >>  Apache Johnzon Project:
> > > >> > > >>
> > > >> > > >>  * Justin Mclean 
> > > >> > > >>  * Romain Manni-Bucau 
> > > >> > > >>  * Jean-Louis Monteiro 
> > > >> > > >>  * Mark Struberg 
> > > >> > > >>  * Hendrik Saly 
> > > >> > > >>
> > > >> > > >>  NOW, THEREFORE, BE IT FURTHER RESOLVED, that Hendrik Saly
> > > (salyh)
> > > >> > > >>  be appointed to the office of Vice President, Apache
Johnzon,
> > to
> > > >> > > >>  serve in accordance with and subject to the direction of
the
> > > >> > > >>  Board of Directors and the Bylaws of the Foundation until
> > > >> > > >>  death, resignation, retirement, removal or
disqualification,
> > > >> > > >>  or until a successor is appointed; and be it further
> > > >> > > >>
> > > >> > > >>  RESOLVED, that the initial Apache Johnzon PMC be and
hereby is
> > > >> > > >>  tasked with the creation of a set of bylaws intended to
> > > >> > > >>  encourage open development and increased participation in
the
> > > >> > > >>  Apache Johnzon Project; and be it further
> > > >> > > >>
> > > >> > > >>  RESOLVED, that the Apache Johnzon Project be and hereby
> > > >> > > >>  is tasked with the migration and rationalization of the
Apache
> > > >> > > >>  Incubator Johnzon podling; and be it further
> > > >> > > >>
> > > >> > > >>  RESOLVED, that all responsibilities pertaining to the
Apache
> > > >> > > >>  Incubator Johnzon podling encumbered upon the Apache
Incubator
> > > >> > > >>  Project are hereafter discharged.
> > > >> > > >>
> > > >> > > >>  --
> > > >> > > >>  Hendrik Saly (salyh, hendrikdev22)
> > > >> > > >>  @hendrikdev22
> > > >> > > >>  PGP: 0x22D7F6EC
> > > >> > > >>
> > > >> > > >>
> > > >>
-
> > > >> > > >>  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: [VOTE] Graduate Johnzon from the Incubator

[Romain Manni-Bucau]

ged with the creation and maintenance of
> > >>  open-source software, for distribution at no charge to
> > >>  the public, related to JSR-353 compliant JSON parsing and a
> > >>  set of useful modules to help with the usage of JSR-353
> > >>  as well as JSR successors (like JSR-374) or related JSRs
> > >>  (like JSR-367).
> > >>
> > >>
> > >>  NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> > >>  Committee (PMC), to be known as the "Apache Johnzon Project",
> > >>  be and hereby is established pursuant to Bylaws of the
> > >>  Foundation; and be it further
> > >>
> > >>  RESOLVED, that the Apache Johnzon Project be and hereby is
> > >>  responsible for the creation and maintenance of software
> > >>  related to JSR-353 compliant JSON parsing and a
> > >>  set of useful modules to help with the usage of JSR-353
> > >>  as well as JSR successors (like JSR-374) or related JSRs
> > >>  (like JSR-367); and be it further
> > >>
> > >>  RESOLVED, that the office of "Vice President, Apache Johnzon" be
> > >>  and hereby is created, the person holding such office to
> > >>  serve at the direction of the Board of Directors as the chair
> > >>  of the Apache Johnzon Project, and to have primary responsibility
> > >>  for management of the projects within the scope of
> > >>  responsibility of the Apache Johnzon Project; and be it further
> > >>
> > >>  RESOLVED, that the persons listed immediately below be and
> > >>  hereby are appointed to serve as the initial members of the
> > >>  Apache Johnzon Project:
> > >>
> > >>  * Justin Mclean 
> > >>  * Romain Manni-Bucau 
> > >>  * Jean-Louis Monteiro 
> > >>  * Mark Struberg 
> > >>  * Hendrik Saly 
> > >>
> > >>  NOW, THEREFORE, BE IT FURTHER RESOLVED, that Hendrik Saly (salyh)
> > >>  be appointed to the office of Vice President, Apache Johnzon, to
> > >>  serve in accordance with and subject to the direction of the
> > >>  Board of Directors and the Bylaws of the Foundation until
> > >>  death, resignation, retirement, removal or disqualification,
> > >>  or until a successor is appointed; and be it further
> > >>
> > >>  RESOLVED, that the initial Apache Johnzon PMC be and hereby is
> > >>  tasked with the creation of a set of bylaws intended to
> > >>  encourage open development and increased participation in the
> > >>  Apache Johnzon Project; and be it further
> > >>
> > >>  RESOLVED, that the Apache Johnzon Project be and hereby
> > >>  is tasked with the migration and rationalization of the Apache
> > >>  Incubator Johnzon podling; and be it further
> > >>
> > >>  RESOLVED, that all responsibilities pertaining to the Apache
> > >>  Incubator Johnzon podling encumbered upon the Apache Incubator
> > >>  Project are hereafter discharged.
> > >>
> > >>  --
> > >>  Hendrik Saly (salyh, hendrikdev22)
> > >>  @hendrikdev22
> > >>  PGP: 0x22D7F6EC
> > >>
> > >>
-
> > >>  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] Graduate Johnzon from the Incubator

[Romain Manni-Bucau]

+1
Le 1 avr. 2016 21:49, "Hendrik Dev" <hendrikde...@gmail.com> a écrit :

> The Apache Johnzon community has discussed and voted on graduation to
> a top level project. The vote passed with 8 +1 votes (5 from the PPMC)
> and no 0 or -1 votes.
>
> Incubation Status:
> http://incubator.apache.org/projects/johnzon.html
> Maturity Assessment:
> https://s.apache.org/d88S
> Discussions:
> https://s.apache.org/5vxO
> https://s.apache.org/8VkX
> Vote:
> https://s.apache.org/suuK
> (http://markmail.org/message/mawumtfqokgye5xn)
> Result:
> https://s.apache.org/Erd0
> (http://markmail.org/message/qmqvk56ccqkq2gob)
>
> Please vote on the resolution pasted below to graduate Apache Johnzon
> from the incubator to top level project.
>
> [ ] +1 Graduate Apache Johnzon from the Incubator.
> [ ] +0 Don't care.
> [ ] -1 Don't graduate Apache Johnzon from the Incubator because ...
>
> This vote will be open for at least 72 hours.
>
> Many thanks to our mentors and everyone else for the support,
>
> Hendrik Saly on behalf of the Apache Johnzon PPMC
>
> Apache Johnzon top-level project resolution:
> 
>
> WHEREAS, the Board of Directors deems it to be in the best
> interests of the Foundation and consistent with the
> Foundation's purpose to establish a Project Management
> Committee charged with the creation and maintenance of
> open-source software, for distribution at no charge to
> the public, related to JSR-353 compliant JSON parsing and a
> set of useful modules to help with the usage of JSR-353
> as well as JSR successors (like JSR-374) or related JSRs
> (like JSR-367).
>
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> Committee (PMC), to be known as the "Apache Johnzon Project",
> be and hereby is established pursuant to Bylaws of the
> Foundation; and be it further
>
> RESOLVED, that the Apache Johnzon Project be and hereby is
> responsible for the creation and maintenance of software
> related to JSR-353 compliant JSON parsing and a
> set of useful modules to help with the usage of JSR-353
> as well as JSR successors (like JSR-374) or related JSRs
> (like JSR-367); and be it further
>
> RESOLVED, that the office of "Vice President, Apache Johnzon" be
> and hereby is created, the person holding such office to
> serve at the direction of the Board of Directors as the chair
> of the Apache Johnzon Project, and to have primary responsibility
> for management of the projects within the scope of
> responsibility of the Apache Johnzon Project; and be it further
>
> RESOLVED, that the persons listed immediately below be and
> hereby are appointed to serve as the initial members of the
> Apache Johnzon Project:
>
> * Justin Mclean 
> * Romain Manni-Bucau 
> * Jean-Louis Monteiro 
> * Mark Struberg 
> * Hendrik Saly 
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Hendrik Saly (salyh)
> be appointed to the office of Vice President, Apache Johnzon, to
> serve in accordance with and subject to the direction of the
> Board of Directors and the Bylaws of the Foundation until
> death, resignation, retirement, removal or disqualification,
> or until a successor is appointed; and be it further
>
> RESOLVED, that the initial Apache Johnzon PMC be and hereby is
> tasked with the creation of a set of bylaws intended to
> encourage open development and increased participation in the
> Apache Johnzon Project; and be it further
>
> RESOLVED, that the Apache Johnzon Project be and hereby
> is tasked with the migration and rationalization of the Apache
> Incubator Johnzon podling; and be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache
> Incubator Johnzon podling encumbered upon the Apache Incubator
> Project are hereafter discharged.
>
> --
> Hendrik Saly (salyh, hendrikdev22)
> @hendrikdev22
> PGP: 0x22D7F6EC
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Graduation for Apache Johnzon

[Romain Manni-Bucau]

Ok just pushed one we'll work on. thanks Bertrand.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2016-03-08 11:41 GMT+01:00 Bertrand Delacretaz <bdelacre...@apache.org>:

> On Mon, Mar 7, 2016 at 9:16 PM, John D. Ament <john.d.am...@gmail.com>
> wrote:
> > ...you're missing a proposed charter, the name of the proposed VP, who
> > the initial committers, initial PMC, etc...
>
> And although it's not required, an assessment of the project's health
> with respect the Project Maturity Model at [1] is very welcome.
>
> See for example the Groovy assessment at [2].
>
> -Bertrand
>
> [1]
> https://community.apache.org/apache-way/apache-project-maturity-model.html
>
> [2]
> https://github.com/apache/groovy/blob/576b3c5d6a7022ac4a8df1ef118666456ce627fb/MATURITY.adoc
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Graduation for Apache Johnzon

[Romain Manni-Bucau]

@John: thks, will do


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2016-03-07 21:16 GMT+01:00 John D. Ament <john.d.am...@gmail.com>:

> Yes, you're missing a proposed charter, the name of the proposed VP, who
> the initial committers, initial PMC, etc.  Please review it carefully and
> work with your mentors to define all this stuff.
>
> John
>
> On Mon, Mar 7, 2016 at 2:52 PM Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>
> > I did, the idea was to reuse asf charter (replacing ${PROJECT} by
> Johnzon),
> > ppmc vote was considered useless since everyone agreed and nobody
> objected
> > so we were at voting on IPMC step, did I miss something?
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com>
> >
> > 2016-03-07 20:47 GMT+01:00 John D. Ament <johndam...@apache.org>:
> >
> > > Romain,
> > >
> > > Please review the graduation guide:
> > > http://incubator.apache.org/guides/graduation.html
> > >
> > > John
> > >
> > > On Mon, Mar 7, 2016 at 2:42 PM Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > > wrote:
> > >
> > > > 2016-03-07 20:08 GMT+01:00 John D. Ament <john.d.am...@gmail.com>:
> > > >
> > > > > Usually graduation votes include things like the proposal.
> > > > >
> > > > > It seems like this wasn't particularly discussed on the dev list,
> and
> > > not
> > > > > voted on at the dev list...
> > > > >
> > > > >
> > > > Was not voted cause everyone agreed, it has been discussed twice and
> > > > acknowledged twice so a vote was not mandatory since there was a
> > > concensus
> > > > (
> > > >
> > > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-johnzon-dev/201603.mbox/browser
> > > > ).
> > > > Also Justin said we can just use the default ASF policy to graduate
> so
> > we
> > > > don't need our own. Should we still write it?
> > > >
> > > >
> > > > > John
> > > > >
> > > > > On Mon, Mar 7, 2016 at 1:55 PM Romain Manni-Bucau <
> > > > rmannibu...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > We discussed on johnzon@ and the graduation is out next goal
> > (there
> > > > was
> > > > > > several threads but the one triggering this vote is
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-johnzon-dev/201603.mbox/browser
> > > > > > ).
> > > > > >
> > > > > > I'd ilke the IPMC to recommend the resolution to the Board and
> > > > therefore
> > > > > > I'm asking for a vote for it.
> > > > > >
> > > > > > [ ] +1 great!
> > > > > > [ ] +0 don't care
> > > > > > [ ] -1 cause...
> > > > > >
> > > > > > Thanks,
> > > > > > Romain
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] Graduation for Apache Johnzon

[Romain Manni-Bucau]

I did, the idea was to reuse asf charter (replacing ${PROJECT} by Johnzon),
ppmc vote was considered useless since everyone agreed and nobody objected
so we were at voting on IPMC step, did I miss something?


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2016-03-07 20:47 GMT+01:00 John D. Ament <johndam...@apache.org>:

> Romain,
>
> Please review the graduation guide:
> http://incubator.apache.org/guides/graduation.html
>
> John
>
> On Mon, Mar 7, 2016 at 2:42 PM Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>
> > 2016-03-07 20:08 GMT+01:00 John D. Ament <john.d.am...@gmail.com>:
> >
> > > Usually graduation votes include things like the proposal.
> > >
> > > It seems like this wasn't particularly discussed on the dev list, and
> not
> > > voted on at the dev list...
> > >
> > >
> > Was not voted cause everyone agreed, it has been discussed twice and
> > acknowledged twice so a vote was not mandatory since there was a
> concensus
> > (
> >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-johnzon-dev/201603.mbox/browser
> > ).
> > Also Justin said we can just use the default ASF policy to graduate so we
> > don't need our own. Should we still write it?
> >
> >
> > > John
> > >
> > > On Mon, Mar 7, 2016 at 1:55 PM Romain Manni-Bucau <
> > rmannibu...@apache.org>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > We discussed on johnzon@ and the graduation is out next goal (there
> > was
> > > > several threads but the one triggering this vote is
> > > >
> > > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-johnzon-dev/201603.mbox/browser
> > > > ).
> > > >
> > > > I'd ilke the IPMC to recommend the resolution to the Board and
> > therefore
> > > > I'm asking for a vote for it.
> > > >
> > > > [ ] +1 great!
> > > > [ ] +0 don't care
> > > > [ ] -1 cause...
> > > >
> > > > Thanks,
> > > > Romain
> > > >
> > >
> >
>

Re: [VOTE] Graduation for Apache Johnzon

[Romain Manni-Bucau]

2016-03-07 20:08 GMT+01:00 John D. Ament <john.d.am...@gmail.com>:

> Usually graduation votes include things like the proposal.
>
> It seems like this wasn't particularly discussed on the dev list, and not
> voted on at the dev list...
>
>
Was not voted cause everyone agreed, it has been discussed twice and
acknowledged twice so a vote was not mandatory since there was a concensus (
http://mail-archives.apache.org/mod_mbox/incubator-johnzon-dev/201603.mbox/browser).
Also Justin said we can just use the default ASF policy to graduate so we
don't need our own. Should we still write it?


> John
>
> On Mon, Mar 7, 2016 at 1:55 PM Romain Manni-Bucau <rmannibu...@apache.org>
> wrote:
>
> > Hi,
> >
> > We discussed on johnzon@ and the graduation is out next goal (there was
> > several threads but the one triggering this vote is
> >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-johnzon-dev/201603.mbox/browser
> > ).
> >
> > I'd ilke the IPMC to recommend the resolution to the Board and therefore
> > I'm asking for a vote for it.
> >
> > [ ] +1 great!
> > [ ] +0 don't care
> > [ ] -1 cause...
> >
> > Thanks,
> > Romain
> >
>

[VOTE] Graduation for Apache Johnzon

[Romain Manni-Bucau]

Hi,

We discussed on johnzon@ and the graduation is out next goal (there was
several threads but the one triggering this vote is
http://mail-archives.apache.org/mod_mbox/incubator-johnzon-dev/201603.mbox/browser
).

I'd ilke the IPMC to recommend the resolution to the Board and therefore
I'm asking for a vote for it.

[ ] +1 great!
[ ] +0 don't care
[ ] -1 cause...

Thanks,
Romain

Fwd: [VOTE] Apache Johnzon 0.9.3-incubating release

[Romain Manni-Bucau]

FYI. Apache Johnzon is currently voting on 0.9.3-incubating.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

-- Forwarded message --
From: Romain Manni-Bucau <rmannibu...@gmail.com>
Date: 2016-02-17 10:47 GMT+01:00
Subject: [VOTE] Apache Johnzon 0.9.3-incubating release
To: d...@johnzon.incubator.apache.org


Hi

As mentioned on the list here is the release vote for johnzon 0.9.3:

he release is
*https://git-wip-us.apache.org/repos/asf?p=incubator-johnzon.git;a=commit;h=4ba9bca107c8f51f2e8340d05e500db19fe87366
<https://git-wip-us.apache.org/repos/asf?p=incubator-johnzon.git;a=commit;h=4ba9bca107c8f51f2e8340d05e500db19fe87366>*

Maven staging repo:
*https://repository.apache.org/content/repositories/orgapachejohnzon-1013/
<https://repository.apache.org/content/repositories/orgapachejohnzon-1013/>*

Distribution archives (zip/tar.gz) with their hashes can be found under:
*https://repository.apache.org/content/repositories/orgapachejohnzon-1013/org/apache/johnzon/apache-johnzon/0.9.3-incubating/
<https://repository.apache.org/content/repositories/orgapachejohnzon-1013/org/apache/johnzon/apache-johnzon/0.9.3-incubating/>*

The files are also here (apache-johnzon-0.9.3-incubating*)
https://dist.apache.org/repos/dist/dev/incubator/johnzon/

PGP release key:
https://dist.apache.org/repos/dist/release/incubator/johnzon/KEYS

Release note:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315523=12334032


The vote will be open for at least 72 hours or until we get 3 PMC +1 votes and
no blocker is found.

[ ] +1  yep
[ ] +0  don't care
[ ] -1  no because [fill this input with your reason]

Here is my +1

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

[ANNOUNCE] New committer: Reinhard Standtner

[Romain Manni-Bucau]

The Project Management Committee (PMC) for Apache BatchEE
has asked Reinhard Sandtner to become a committer and we are pleased to
announce that he has accepted.

Reinhard is already an incubator committer and an active BatchEE actor so
this is just an officialisation of the current state.

Being a committer allows many contributors to contribute more
autonomously. For developers, it makes it easier to submit changes and
eliminates the need to have contributions reviewed via the patch
submission process. Whether contributions are development-related or
otherwise, it is a recognition of a contributor's participation in the
project and commitment to the project and the Apache Way.

Please join me in congratulating Reinhard!

-- Romain Manni-Bucau
on behalf of the Incubator PMC

[ANNOUNCE] Apache sirona 0.3-incubating released

[Romain Manni-Bucau]

The Apache Sirona team is pleased to announce the immediate
availability of the 0.3-incubating release. The release note can be
found here [1]; The source code and binary package can be downloaded
from Sirona download page [2].

This release includes several enhancements on the javaagent and path
tracking features as well as new features like websocket push support
and new alerter API.

The Apache Sirona Team would like to hear from you and welcomes your
comments and contributions.

Thanks,
The Apache Sirona Team

[1] http://sirona.incubator.apache.org/docs/0.3-incubating/jira-report.html
[2] http://sirona.incubator.apache.org/download.cgi

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

Re: [VOTE] Apache Sirona 0.3-incubating

[Romain Manni-Bucau]

Hi Justin,

thanks, I opened https://issues.apache.org/jira/browse/SIRONA-49

also noted the point about git hashes!


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-11-05 20:54 GMT-08:00 Justin Mclean <jus...@classsoftware.com>:

> Hi,
>
> +1 (binding) but only if you raise a JIRA and fix up LICENSE and NOTICE
> issues for the next release.
>
>  Everything here is permissive so it's more a documentation issue than an
> licensing error.
>
> For the next release could you mind mentioning the git/svn hash that the
> released code corresponds to.
>
> I checked:
> - file contains incubating
> - DISCLAIMER exists
> - LICENSE and NOTICE have some issues
> - NOTICE has incorrect year
> - All source file had Apace headers (except a couple of shell scripts)
> - No unexpected binary files
> - Can compile from source
>
> As per [1][2] LICENSE should include:
>  - bootstrap (MIT)
>  - normalize.css (MIT)
>  - datetimepicker (MIT)
>  - fontawesome (MIT)
>  - font awesome fonts (SIL open font licence)
>  - angular (MIT)
>  - JQuery (MIT)
>  - moment.js (MIT)
>  - ng-grid (MIT)
>  - RequireJS (MIT or BSD)
>  - angular-ui-bootstrap (MIT)
>  - jquery.flot (MIT)
>  - raphael (MIT or BSD)
>  - jquery.tablesorter (MIT)
>  - morris.js (BSD)
>  - angular-bootstrap-nav-tree (MIT)
>
> I may of missed one or two from a quick glance I took. Basically anything
> that’s  MIT or BSD licensed that's bundled in this source release needs to
> be added to LICENSE. [2] None of these need to be mentioned in NOTICE. [3]
>
> Thanks,
> Justin
>
> 1. http://www.apache.org/dev/licensing-howto.html#guiding-principle
> 2. http://www.apache.org/dev/licensing-howto.html#permissive-deps
> 3. http://www.apache.org/dev/licensing-howto.html#mod-notice
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

[RESULT][VOTE] Apache Sirona 0.3-incubating

[Romain Manni-Bucau]

and with my +1 the vote passes with:

binding +1:
- Mark, Jean-Baptiste, Olivier, Jean-Louis, Justin, me

and no -1.

I'll promote the binaries now.



Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-11-06 8:47 GMT-08:00 Romain Manni-Bucau <rmannibu...@gmail.com>:

> Hi Justin,
>
> thanks, I opened https://issues.apache.org/jira/browse/SIRONA-49
>
> also noted the point about git hashes!
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
>
> 2015-11-05 20:54 GMT-08:00 Justin Mclean <jus...@classsoftware.com>:
>
>> Hi,
>>
>> +1 (binding) but only if you raise a JIRA and fix up LICENSE and NOTICE
>> issues for the next release.
>>
>>  Everything here is permissive so it's more a documentation issue than an
>> licensing error.
>>
>> For the next release could you mind mentioning the git/svn hash that the
>> released code corresponds to.
>>
>> I checked:
>> - file contains incubating
>> - DISCLAIMER exists
>> - LICENSE and NOTICE have some issues
>> - NOTICE has incorrect year
>> - All source file had Apace headers (except a couple of shell scripts)
>> - No unexpected binary files
>> - Can compile from source
>>
>> As per [1][2] LICENSE should include:
>>  - bootstrap (MIT)
>>  - normalize.css (MIT)
>>  - datetimepicker (MIT)
>>  - fontawesome (MIT)
>>  - font awesome fonts (SIL open font licence)
>>  - angular (MIT)
>>  - JQuery (MIT)
>>  - moment.js (MIT)
>>  - ng-grid (MIT)
>>  - RequireJS (MIT or BSD)
>>  - angular-ui-bootstrap (MIT)
>>  - jquery.flot (MIT)
>>  - raphael (MIT or BSD)
>>  - jquery.tablesorter (MIT)
>>  - morris.js (BSD)
>>  - angular-bootstrap-nav-tree (MIT)
>>
>> I may of missed one or two from a quick glance I took. Basically anything
>> that’s  MIT or BSD licensed that's bundled in this source release needs to
>> be added to LICENSE. [2] None of these need to be mentioned in NOTICE. [3]
>>
>> Thanks,
>> Justin
>>
>> 1. http://www.apache.org/dev/licensing-howto.html#guiding-principle
>> 2. http://www.apache.org/dev/licensing-howto.html#permissive-deps
>> 3. http://www.apache.org/dev/licensing-howto.html#mod-notice
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
>

[VOTE] Apache Sirona 0.3-incubating

[Romain Manni-Bucau]

Hi,

As mentionned on sirona list I'd like to release Apache Sirona
 0.3-incubating.

Fixed issues:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20SIRONA%20AND%20fixVersion%20%3D%200.3-incubating%20AND%20status%20%3D%20RESOLVED%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC

Highlights are:
- enhancements for our javaagent
- new Alert(er) API
- starting to rework of our web stack


Staging Maven repository:
*https://repository.apache.org/content/repositories/orgapachesirona-1002/
<https://repository.apache.org/content/repositories/orgapachesirona-1002/>*

Staging release:
*https://dist.apache.org/repos/dist/dev/incubator/sirona/0.3-incubating/
<https://dist.apache.org/repos/dist/dev/incubator/sirona/0.3-incubating/>*

Documentation:
*http://sirona.incubator.apache.org/docs/0.3-incubating/
<http://sirona.incubator.apache.org/docs/0.3-incubating/>*

Vote open for 72H

+1
0
-1

Thanks,
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

Re: [VOTE] Apache Sirona 0.3-incubating

[Romain Manni-Bucau]

put general as well trying to avoid to need to get twice the same votes.
Should have I cc-ed general instead?


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-11-03 13:27 GMT-08:00 John D. Ament <johndam...@apache.org>:

> I'm assuming this is a dev vote and general was copied ?
> On Nov 3, 2015 16:25, "Romain Manni-Bucau" <rmannibu...@gmail.com> wrote:
>
> > Hi,
> >
> > As mentionned on sirona list I'd like to release Apache Sirona
> >  0.3-incubating.
> >
> > Fixed issues:
> >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SIRONA%20AND%20fixVersion%20%3D%200.3-incubating%20AND%20status%20%3D%20RESOLVED%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC
> >
> > Highlights are:
> > - enhancements for our javaagent
> > - new Alert(er) API
> > - starting to rework of our web stack
> >
> >
> > Staging Maven repository:
> > *
> https://repository.apache.org/content/repositories/orgapachesirona-1002/
> > <
> https://repository.apache.org/content/repositories/orgapachesirona-1002/
> > >*
> >
> > Staging release:
> > *https://dist.apache.org/repos/dist/dev/incubator/sirona/0.3-incubating/
> > <https://dist.apache.org/repos/dist/dev/incubator/sirona/0.3-incubating/
> >*
> >
> > Documentation:
> > *http://sirona.incubator.apache.org/docs/0.3-incubating/
> > <http://sirona.incubator.apache.org/docs/0.3-incubating/>*
> >
> > Vote open for 72H
> >
> > +1
> > 0
> > -1
> >
> > Thanks,
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com>
> >
>

Re: Incubator PMC/Board report for Oct 2015 ([ppmc])

[Romain Manni-Bucau]

written


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-10-13 19:10 GMT+02:00 Ted Dunning <ted.dunn...@gmail.com>:

> It isn't OK. It may have to happen, but it isn't really OK.
>
> Why are you the only one who can write this report?
>
>
>
> On Tue, Oct 13, 2015 at 4:48 AM, Mark Struberg <strub...@yahoo.de> wrote:
>
> > Hi folks!
> >
> > I’m currently working on a few BatchEE fixes but got no time to write the
> > report this time.
> > Is it ok to report next months?
> >
> > txs and LieGrue,
> > strub
> >
> >
> > > Am 05.10.2015 um 16:17 schrieb Marvin <no-re...@apache.org>:
> > >
> > >
> > >
> > > Dear podling,
> > >
> > > This email was sent by an automated system on behalf of the Apache
> > Incubator PMC.
> > > It is an initial reminder to give you plenty of time to prepare your
> > quarterly
> > > board report.
> > >
> > > The board meeting is scheduled for Wed, 21 October 2015, 10:30 am PST.
> > The report
> > > for your podling will form a part of the Incubator PMC report. The
> > Incubator PMC
> > > requires your report to be submitted 2 weeks before the board meeting,
> > to allow
> > > sufficient time for review and submission (Wed, Oct 7th).
> > >
> > > Please submit your report with sufficient time to allow the incubator
> > PMC, and
> > > subsequently board members to review and digest. Again, the very latest
> > you
> > > should submit your report is 2 weeks prior to the board meeting.
> > >
> > > Thanks,
> > >
> > > The Apache Incubator PMC
> > >
> > > Submitting your Report
> > > --
> > >
> > > Your report should contain the following:
> > >
> > > * Your project name
> > > * A brief description of your project, which assumes no knowledge of
> the
> > project
> > >   or necessarily of its field
> > > * A list of the three most important issues to address in the move
> > towards
> > >   graduation.
> > > * Any issues that the Incubator PMC or ASF Board might wish/need to be
> > aware of
> > > * How has the community developed since the last report
> > > * How has the project developed since the last report.
> > >
> > > This should be appended to the Incubator Wiki page at:
> > >
> > >  http://wiki.apache.org/incubator/October2015
> > >
> > > Note: This is manually populated. You may need to wait a little before
> > this page
> > >  is created from a template.
> > >
> > > Mentors
> > > ---
> > > Mentors should review reports for their project(s) and sign them off on
> > the
> > > Incubator wiki page. Signing off reports shows that you are following
> the
> > > project - projects that are not signed may raise alarms for the
> > Incubator PMC.
> > >
> > > Incubator PMC
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: [RESULT][VOTE] Apache Johnzon 0.9.2-incubating release

[Romain Manni-Bucau]

2015-10-05 22:09 GMT+02:00 Mark Struberg <strub...@yahoo.de>:

> Yes, I also think johnzon is really ready to graduate. Project is really
> doing fine imo.
>
> And another yes, it was the intention to give other IPMC members a chance
> to review the the release and cast their -1 if they find something wrong.
> The project has quite a few PPMC members which are also IPMC, so if I
> counted correctly we already have the 3 IPMC +1, right? (Dan, Romain, me)
>
>
+Justin yes


> txs and LieGrue,
> strub
>
> > Am 05.10.2015 um 16:29 schrieb John D. Ament <johndam...@apache.org>:
> >
> > --001a113f19f2715fd305215c5853
> > Content-Type: text/plain; charset=UTF-8
> >
> > I don't believe that to be the case.
> >
> > You guys are mature enough, why not graduate?
> > On Oct 5, 2015 10:06 AM, "Romain Manni-Bucau" <rmannibu...@gmail.com>
> wrote:
> >
> >> Hi incubator,
> >>
> >> Mark forwarded the vote at the beginning of dev@ vote. Therefore it
> sounds
> >> to me we don't need to vote again on these binaries. Can you confirm it
> >> please?
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >> <http://rmannibucau.wordpress.com> | Github <
> >> https://github.com/rmannibucau> |
> >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> >> <http://www.tomitribe.com>
> >>
> >> -- Forwarded message --
> >> From: Romain Manni-Bucau <rmannibu...@gmail.com>
> >> Date: 2015-10-05 7:02 GMT-07:00
> >> Subject: [RESULT][VOTE] Apache Johnzon 0.9.2-incubating release
> >> To: d...@johnzon.incubator.apache.org
> >>
> >>
> >> So vote passed with 4 binding +1 and 2 non-binding +1.
> >>
> >>
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >> <http://rmannibucau.wordpress.com> | Github <
> >> https://github.com/rmannibucau> |
> >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> >> <http://www.tomitribe.com>
> >>
> >> 2015-10-02 6:44 GMT-07:00 Daniel Kulp <dk...@apache.org>:
> >>
> >>> +1
> >>>
> >>> Looks good to me.
> >>>
> >>> Dan
> >>>
> >>>
> >>>
> >>>> On Sep 30, 2015, at 3:33 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>>
> >>> wrote:
> >>>>
> >>>> Hi
> >>>>
> >>>> As mentioned on the list here is the release vote for johnzon 0.9.2:
> >>>>
> >>>> he release is
> >>>> *
> >>>
> >>
> https://git-wip-us.apache.org/repos/asf?p=incubator-johnzon.git;a=commit;h=d88918a3b2704cf76687a894f897b2d768fe5cd5
> >>>> <
> >>>
> >>
> https://git-wip-us.apache.org/repos/asf?p=incubator-johnzon.git;a=commit;h=d88918a3b2704cf76687a894f897b2d768fe5cd5
> >>>> *
> >>>>
> >>>> Maven staging repo:
> >>>> *
> >>>
> https://repository.apache.org/content/repositories/orgapachejohnzon-1009
> >>>> <
> >>>
> https://repository.apache.org/content/repositories/orgapachejohnzon-1009
> >>> *
> >>>>
> >>>> Distribution archives (zip/tar.gz) with their hashes can be found
> >> under:
> >>>> *
> >>>
> >>
> https://repository.apache.org/content/repositories/orgapachejohnzon-1009/org/apache/johnzon/apache-johnzon/0.9.2-incubating/
> >>>> <
> >>>
> >>
> https://repository.apache.org/content/repositories/orgapachejohnzon-1009/org/apache/johnzon/apache-johnzon/0.9.2-incubating/
> >>>> *
> >>>>
> >>>> The files are also here (apache-johnzon-0.9.2-incubating-src*)
> >>>> https://dist.apache.org/repos/dist/dev/incubator/johnzon/
> >>>>
> >>>> PGP release keys:
> >>>> https://dist.apache.org/repos/dist/release/incubator/johnzon/KEYS
> >>>>
> >>>>
> >>>> The vote will be open for at least 72 hours or until we get 3 PMC +1
> >>> votes and
> >>>> no blocker is found.
> >>>>
> >>>> [ ] +1  yeah do it!
> >>>> [ ] +0  don't care
> >>>> [ ] -1  clearly not because [fill this input with your reason]
> >>>>
> >>>> Here is my +1
> >>>>
> >>>> Romain Manni-Bucau
> >>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >>>> <http://rmannibucau.wordpress.com> | Github <
> >>> https://github.com/rmannibucau> |
> >>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> >>>> <http://www.tomitribe.com>
> >>>
> >>> --
> >>> Daniel Kulp
> >>> dk...@apache.org - http://dankulp.com/blog
> >>> Talend Community Coder - http://coders.talend.com
> >>>
> >>>
> >>
> >
> > --001a113f19
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Fwd: [RESULT][VOTE] Apache Johnzon 0.9.2-incubating release

[Romain Manni-Bucau]

Hi incubator,

Mark forwarded the vote at the beginning of dev@ vote. Therefore it sounds
to me we don't need to vote again on these binaries. Can you confirm it
please?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

-- Forwarded message --
From: Romain Manni-Bucau <rmannibu...@gmail.com>
Date: 2015-10-05 7:02 GMT-07:00
Subject: [RESULT][VOTE] Apache Johnzon 0.9.2-incubating release
To: d...@johnzon.incubator.apache.org


So vote passed with 4 binding +1 and 2 non-binding +1.




Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-10-02 6:44 GMT-07:00 Daniel Kulp <dk...@apache.org>:

> +1
>
> Looks good to me.
>
> Dan
>
>
>
> > On Sep 30, 2015, at 3:33 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
> >
> > Hi
> >
> > As mentioned on the list here is the release vote for johnzon 0.9.2:
> >
> > he release is
> > *
> https://git-wip-us.apache.org/repos/asf?p=incubator-johnzon.git;a=commit;h=d88918a3b2704cf76687a894f897b2d768fe5cd5
> > <
> https://git-wip-us.apache.org/repos/asf?p=incubator-johnzon.git;a=commit;h=d88918a3b2704cf76687a894f897b2d768fe5cd5
> >*
> >
> > Maven staging repo:
> > *
> https://repository.apache.org/content/repositories/orgapachejohnzon-1009
> > <
> https://repository.apache.org/content/repositories/orgapachejohnzon-1009>*
> >
> > Distribution archives (zip/tar.gz) with their hashes can be found under:
> > *
> https://repository.apache.org/content/repositories/orgapachejohnzon-1009/org/apache/johnzon/apache-johnzon/0.9.2-incubating/
> > <
> https://repository.apache.org/content/repositories/orgapachejohnzon-1009/org/apache/johnzon/apache-johnzon/0.9.2-incubating/
> >*
> >
> > The files are also here (apache-johnzon-0.9.2-incubating-src*)
> > https://dist.apache.org/repos/dist/dev/incubator/johnzon/
> >
> > PGP release keys:
> > https://dist.apache.org/repos/dist/release/incubator/johnzon/KEYS
> >
> >
> > The vote will be open for at least 72 hours or until we get 3 PMC +1
> votes and
> > no blocker is found.
> >
> > [ ] +1  yeah do it!
> > [ ] +0  don't care
> > [ ] -1  clearly not because [fill this input with your reason]
> >
> > Here is my +1
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>

Re: Fwd: [RESULT][VOTE] Apache Johnzon 0.9.2-incubating release

[Romain Manni-Bucau]

@Marvin: right for source/binary, sorry for this miswording

Think we should graduate soon yes, just one of us needs to take time to do
it.

Then I consider the vote done and will finish the release

Thanks guys!

2015-10-05 7:29 GMT-07:00 John D. Ament <johndam...@apache.org>:

> I don't believe that to be the case.
>
> You guys are mature enough, why not graduate?
> On Oct 5, 2015 10:06 AM, "Romain Manni-Bucau" <rmannibu...@gmail.com>
> wrote:
>
> > Hi incubator,
> >
> > Mark forwarded the vote at the beginning of dev@ vote. Therefore it
> sounds
> > to me we don't need to vote again on these binaries. Can you confirm it
> > please?
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com>
> >
> > -- Forwarded message --
> > From: Romain Manni-Bucau <rmannibu...@gmail.com>
> > Date: 2015-10-05 7:02 GMT-07:00
> > Subject: [RESULT][VOTE] Apache Johnzon 0.9.2-incubating release
> > To: d...@johnzon.incubator.apache.org
> >
> >
> > So vote passed with 4 binding +1 and 2 non-binding +1.
> >
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com>
> >
> > 2015-10-02 6:44 GMT-07:00 Daniel Kulp <dk...@apache.org>:
> >
> > > +1
> > >
> > > Looks good to me.
> > >
> > > Dan
> > >
> > >
> > >
> > > > On Sep 30, 2015, at 3:33 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > > wrote:
> > > >
> > > > Hi
> > > >
> > > > As mentioned on the list here is the release vote for johnzon 0.9.2:
> > > >
> > > > he release is
> > > > *
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-johnzon.git;a=commit;h=d88918a3b2704cf76687a894f897b2d768fe5cd5
> > > > <
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-johnzon.git;a=commit;h=d88918a3b2704cf76687a894f897b2d768fe5cd5
> > > >*
> > > >
> > > > Maven staging repo:
> > > > *
> > >
> https://repository.apache.org/content/repositories/orgapachejohnzon-1009
> > > > <
> > >
> https://repository.apache.org/content/repositories/orgapachejohnzon-1009
> > >*
> > > >
> > > > Distribution archives (zip/tar.gz) with their hashes can be found
> > under:
> > > > *
> > >
> >
> https://repository.apache.org/content/repositories/orgapachejohnzon-1009/org/apache/johnzon/apache-johnzon/0.9.2-incubating/
> > > > <
> > >
> >
> https://repository.apache.org/content/repositories/orgapachejohnzon-1009/org/apache/johnzon/apache-johnzon/0.9.2-incubating/
> > > >*
> > > >
> > > > The files are also here (apache-johnzon-0.9.2-incubating-src*)
> > > > https://dist.apache.org/repos/dist/dev/incubator/johnzon/
> > > >
> > > > PGP release keys:
> > > > https://dist.apache.org/repos/dist/release/incubator/johnzon/KEYS
> > > >
> > > >
> > > > The vote will be open for at least 72 hours or until we get 3 PMC +1
> > > votes and
> > > > no blocker is found.
> > > >
> > > > [ ] +1  yeah do it!
> > > > [ ] +0  don't care
> > > > [ ] -1  clearly not because [fill this input with your reason]
> > > >
> > > > Here is my +1
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > > <http://www.tomitribe.com>
> > >
> > > --
> > > Daniel Kulp
> > > dk...@apache.org - http://dankulp.com/blog
> > > Talend Community Coder - http://coders.talend.com
> > >
> > >
> >
>

Re: Fwd: [RESULT][VOTE] Apache Johnzon 0.9.2-incubating release

[Romain Manni-Bucau]

understood it hasnt been clear enough in Mark's mail but still matches the
incubator policy. If not we can do the same vote with the same votes, not a
big deal.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-10-05 8:50 GMT-07:00 John D. Ament <johndam...@apache.org>:

> I'm not sure that matches what we are saying.
> On Oct 5, 2015 10:34, "Romain Manni-Bucau" <rmannibu...@gmail.com> wrote:
>
> > @Marvin: right for source/binary, sorry for this miswording
> >
> > Think we should graduate soon yes, just one of us needs to take time to
> do
> > it.
> >
> > Then I consider the vote done and will finish the release
> >
> > Thanks guys!
> >
> > 2015-10-05 7:29 GMT-07:00 John D. Ament <johndam...@apache.org>:
> >
> > > I don't believe that to be the case.
> > >
> > > You guys are mature enough, why not graduate?
> > > On Oct 5, 2015 10:06 AM, "Romain Manni-Bucau" <rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > Hi incubator,
> > > >
> > > > Mark forwarded the vote at the beginning of dev@ vote. Therefore it
> > > sounds
> > > > to me we don't need to vote again on these binaries. Can you confirm
> it
> > > > please?
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > > <http://www.tomitribe.com>
> > > >
> > > > -- Forwarded message --
> > > > From: Romain Manni-Bucau <rmannibu...@gmail.com>
> > > > Date: 2015-10-05 7:02 GMT-07:00
> > > > Subject: [RESULT][VOTE] Apache Johnzon 0.9.2-incubating release
> > > > To: d...@johnzon.incubator.apache.org
> > > >
> > > >
> > > > So vote passed with 4 binding +1 and 2 non-binding +1.
> > > >
> > > >
> > > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > > <http://www.tomitribe.com>
> > > >
> > > > 2015-10-02 6:44 GMT-07:00 Daniel Kulp <dk...@apache.org>:
> > > >
> > > > > +1
> > > > >
> > > > > Looks good to me.
> > > > >
> > > > > Dan
> > > > >
> > > > >
> > > > >
> > > > > > On Sep 30, 2015, at 3:33 PM, Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > >
> > > > > wrote:
> > > > > >
> > > > > > Hi
> > > > > >
> > > > > > As mentioned on the list here is the release vote for johnzon
> > 0.9.2:
> > > > > >
> > > > > > he release is
> > > > > > *
> > > > >
> > > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-johnzon.git;a=commit;h=d88918a3b2704cf76687a894f897b2d768fe5cd5
> > > > > > <
> > > > >
> > > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-johnzon.git;a=commit;h=d88918a3b2704cf76687a894f897b2d768fe5cd5
> > > > > >*
> > > > > >
> > > > > > Maven staging repo:
> > > > > > *
> > > > >
> > >
> https://repository.apache.org/content/repositories/orgapachejohnzon-1009
> > > > > > <
> > > > >
> > >
> https://repository.apache.org/content/repositories/orgapachejohnzon-1009
> > > > >*
> > > > > >
> > > > > > Distribution archives (zip/tar.gz) with their hashes can be found
> > > > under:
> > > > > > *
> > > > >
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachejohnzon-1009/org/apache/johnzon/apache-johnzon/0.9.2-incubating/
> > > > > > <
> > > > >
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachejohnzon-1009/org/apache/johnzon/apache-johnzon/0.9.2-incubating/
> > > > > >*
> > > > > >
> > > > > > The files are also here (apache-johnzon-0.9.2-incubating-src*)
> > > > > > https://dist.apache.org/repos/dist/dev/incubator/johnzon/
> > > > > >
> > > > > > PGP release keys:
> > > > > >
> https://dist.apache.org/repos/dist/release/incubator/johnzon/KEYS
> > > > > >
> > > > > >
> > > > > > The vote will be open for at least 72 hours or until we get 3 PMC
> > +1
> > > > > votes and
> > > > > > no blocker is found.
> > > > > >
> > > > > > [ ] +1  yeah do it!
> > > > > > [ ] +0  don't care
> > > > > > [ ] -1  clearly not because [fill this input with your reason]
> > > > > >
> > > > > > Here is my +1
> > > > > >
> > > > > > Romain Manni-Bucau
> > > > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > https://github.com/rmannibucau> |
> > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > > > > <http://www.tomitribe.com>
> > > > >
> > > > > --
> > > > > Daniel Kulp
> > > > > dk...@apache.org - http://dankulp.com/blog
> > > > > Talend Community Coder - http://coders.talend.com
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: Fwd: [RESULT][VOTE] Apache Johnzon 0.9.2-incubating release

[Romain Manni-Bucau]

the +1 bindings listed in the result were the ipmc votes, ie:

- Mark
- Justin
- Daniel
- and me



Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-10-05 9:30 GMT-07:00 John D. Ament <johndam...@apache.org>:

> I'm fine either way.  Could the podling forward their result at least with
> the IPMC binding votes listed?
> On Oct 5, 2015 11:58, "Marvin Humphrey" <mar...@rectangular.com> wrote:
>
> > On Mon, Oct 5, 2015 at 8:50 AM, John D. Ament <johndam...@apache.org>
> > wrote:
> > > I'm not sure that matches what we are saying.
> >
> > It matches what I was saying -- I think the thread was (barely,
> > arguably) within the letter of Incubator policy and thus it's not
> > necessary to run another vote.  But it sure would be nice if the
> > original vote thread had been clearer and spared us all this extra
> > meta discussion.
> >
> > Marvin Humphrey
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

[VOTE] Apache Johnzon 0.9.1-incubating release

[Romain Manni-Bucau]

Due to last fixes, I'd like to release a 0.9.1-incubating for johnzon. Vote
passed on johnzon project so time to vote on general@ (see
http://mail-archives.apache.org/mod_mbox/incubator-johnzon-dev/201508.mbox/%3CCACLE%3D7NjEHG1wMd6gG0ktrXA_Jszv8GVVabEfzfiDH%3DQGgrmuw%40mail.gmail.com%3E
for johnzon vote)

Here are the artifacts under this vote:

Git commit for the release is
*https://git-wip-us.apache.org/repos/asf?p=incubator-johnzon.git;a=commit;h=0a60e0a7d43b7fe7e9e398ead265081f98938849
https://git-wip-us.apache.org/repos/asf?p=incubator-johnzon.git;a=commit;h=0a60e0a7d43b7fe7e9e398ead265081f98938849*

Maven staging repo:
*https://repository.apache.org/content/repositories/orgapachejohnzon-1008/
https://repository.apache.org/content/repositories/orgapachejohnzon-1008/*

Distribution archives (zip/tar.gz) with their hashes can be found under:
https://repository.apache.org/content/repositories/orgapachejohnzon-1008/org/apache/johnzon/apache-johnzon/0.9.1-incubating/

The files are also here (apache-johnzon-0.9.1-incubating-src*)
https://dist.apache.org/repos/dist/dev/incubator/johnzon/

PGP release keys (signed using 61078634):
https://dist.apache.org/repos/dist/release/incubator/johnzon/KEYS

This release is really about bugfixing previous release.

The vote will be open for at least 72 hours or until we get 3 PMC +1 votes
and no blocker is found.

[ ] +1  yeah do it!
[ ] +0  don't care
[ ] -1  clearly not because [fill this input with your reason]

Here is my +1

Romain Manni-Bucau
@rmannibucau https://twitter.com/rmannibucau |  Blog
http://rmannibucau.wordpress.com | Github https://github.com/rmannibucau |
LinkedIn https://www.linkedin.com/in/rmannibucau | Tomitriber
http://www.tomitribe.com

[RESULT] [VOTE] Apache Johnzon 0.9.1-incubating release

[Romain Manni-Bucau]

So vote passed with 3 +1 IPMC bindings votes and 2 +1 non IPMC votes.

@incubator: do we need another vote on general@ since we already got 3 IPMC
+1?


Romain Manni-Bucau
@rmannibucau https://twitter.com/rmannibucau |  Blog
http://rmannibucau.wordpress.com | Github https://github.com/rmannibucau |
LinkedIn https://www.linkedin.com/in/rmannibucau | Tomitriber
http://www.tomitribe.com

2015-08-26 15:54 GMT+02:00 Jean-Louis MONTEIRO jeano...@gmail.com:

 +1 (binding)

 Le mer. 26 août 2015 à 15:41, Romain Manni-Bucau rmannibu...@gmail.com a
 écrit :

 
 
  Romain Manni-Bucau
  @rmannibucau https://twitter.com/rmannibucau |  Blog
  http://rmannibucau.wordpress.com | Github
  https://github.com/rmannibucau | LinkedIn
  https://www.linkedin.com/in/rmannibucau | Tomitriber
  http://www.tomitribe.com
 
  -- Forwarded message --
  From: Daniel Cunha daniels...@gmail.com
  Date: 2015-08-26 15:27 GMT+02:00
  Subject: Re: [VOTE] Apache Johnzon 0.9.1-incubating release
  To: d...@johnzon.incubator.apache.org
 
 
  +1
 
  On Wed, Aug 26, 2015 at 10:18 AM, Mark Struberg strub...@yahoo.de
 wrote:
 
   +1
  
   LieGrue,
   strub
  
  
  
Am 25.08.2015 um 15:03 schrieb Romain Manni-Bucau 
  rmannibu...@gmail.com
   :
   
up?
   
   
Romain Manni-Bucau
@rmannibucau https://twitter.com/rmannibucau |  Blog
http://rmannibucau.wordpress.com | Github 
   https://github.com/rmannibucau |
LinkedIn https://www.linkedin.com/in/rmannibucau | Tomitriber
http://www.tomitribe.com
   
2015-08-22 14:32 GMT+02:00 Hendrik Dev hendrikde...@gmail.com:
   
+1
   
On Thu, Aug 20, 2015 at 10:36 PM, Romain Manni-Bucau
rmannibu...@gmail.com wrote:
oops, Hendrik just mentionned I used CA29F018 key to sign the
 release
which
is true, the key is in the KEYS file as well so no need to cancel
 the
vote
:)
   
   
Romain Manni-Bucau
@rmannibucau https://twitter.com/rmannibucau |  Blog
http://rmannibucau.wordpress.com | Github 
https://github.com/rmannibucau |
LinkedIn https://www.linkedin.com/in/rmannibucau | Tomitriber
http://www.tomitribe.com
   
2015-08-20 13:03 GMT-07:00 Romain Manni-Bucau 
 rmannibu...@gmail.com
  :
   
Due to last fixes, I'd like to release a 0.9.1-incubating for
  johnzon.
   
Here are the artifacts under this vote:
   
Git commit for the release is
*
   
  
 
 https://git-wip-us.apache.org/repos/asf?p=incubator-johnzon.git;a=commit;h=0a60e0a7d43b7fe7e9e398ead265081f98938849

   
  
 
 https://git-wip-us.apache.org/repos/asf?p=incubator-johnzon.git;a=commit;h=0a60e0a7d43b7fe7e9e398ead265081f98938849
*
   
Maven staging repo:
*
   
  
 
 https://repository.apache.org/content/repositories/orgapachejohnzon-1008/

   
  
 
 https://repository.apache.org/content/repositories/orgapachejohnzon-1008/
*
   
Distribution archives (zip/tar.gz) with their hashes can be found
   under:
   
   
   
  
 
 https://repository.apache.org/content/repositories/orgapachejohnzon-1008/org/apache/johnzon/apache-johnzon/0.9.1-incubating/
   
The files are also here (apache-johnzon-0.9.1-incubating-src*)
https://dist.apache.org/repos/dist/dev/incubator/johnzon/
   
PGP release keys (signed using 61078634):
https://dist.apache.org/repos/dist/release/incubator/johnzon/KEYS
   
This release is really about bugfixing previous release.
   
The vote will be open for at least 72 hours or until we get 3 PMC
 +1
votes
and no blocker is found.
   
[ ] +1  yeah do it!
[ ] +0  don't care
[ ] -1  clearly not because [fill this input with your reason]
   
Here is my +1
   
Thanks,
Romain Manni-Bucau
@rmannibucau https://twitter.com/rmannibucau |  Blog
http://rmannibucau.wordpress.com | Github
https://github.com/rmannibucau | LinkedIn
https://www.linkedin.com/in/rmannibucau | Tomitriber
http://www.tomitribe.com
   
   
   
   
--
Hendrik Saly (salyh, hendrikdev22)
@hendrikdev22
PGP: 0x22D7F6EC
   
  
  
 
 
  --
  Daniel Cunha (soro)
  https://twitter.com/dvlc_
 
 

Re: [VOTE] Apache Tamaya Release 0.1-incubating

[Romain Manni-Bucau]

+1
Le 14 août 2015 18:02, Anatole Tresch anat...@apache.org a écrit :

 Dear Incubator

 after the Apache Tamaya PPMC vote passed successfully with 5+ votes for the
 first release 0.1-incubating of Apache Tamaya, it's now the incubator's
 task to vote ;)

 Please see original [VOTE] thread:
 *
 http://mail-archives.apache.org/mod_mbox/incubator-tamaya-dev/201508.mbox/%3c71654d7c1e7f6c40b31060c6c584a5dd62750...@chw20013593.ch.ad.hedani.net%3E
 
 http://mail-archives.apache.org/mod_mbox/incubator-tamaya-dev/201508.mbox/%3c71654d7c1e7f6c40b31060c6c584a5dd62750...@chw20013593.ch.ad.hedani.net%3E
 *

 *and vote result: *

 *
 http://mail-archives.apache.org/mod_mbox/incubator-tamaya-dev/201508.mbox/%3c71654d7c1e7f6c40b31060c6c584a5dd62766...@chw20013593.ch.ad.hedani.net%3E
 
 http://mail-archives.apache.org/mod_mbox/incubator-tamaya-dev/201508.mbox/%3c71654d7c1e7f6c40b31060c6c584a5dd62766...@chw20013593.ch.ad.hedani.net%3E
 *

 Please take a look at the artifacts and vote!

 [ ] +1 Release this package
 [ ] 0 I don't feel strongly about it, but
 don't object
 [ ] -1 Do not release this package because...

 The vote will be open for 72 hours at least.



 References
 =

 The tag/commit is available here:
 https://github.com/apache/incubator-tamaya/tree/0.1-incubating
 *
 https://git-wip-us.apache.org/repos/asf?p=incubator-tamaya.git;a=commit;h=c07976ae65db58f02985307b79d317e1ffc4f036
 
 https://git-wip-us.apache.org/repos/asf?p=incubator-tamaya.git;a=commit;h=c07976ae65db58f02985307b79d317e1ffc4f036
 *

 The release notes can be found here:

 https://raw.githubusercontent.com/apache/incubator-tamaya/0.1-incubating/readme/ReleaseNotes-0.1-incubating.html
 and here:

 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315925version=12329050

 Release candidates are signed with a GPG key available at:
 *
 https://git-wip-us.apache.org/repos/asf?p=incubator-tamaya.git;a=blob_plain;f=keys/KEYS;hb=c07976ae65db58f02985307b79d317e1ffc4f036
 
 https://git-wip-us.apache.org/repos/asf?p=incubator-tamaya.git;a=blob_plain;f=keys/KEYS;hb=c07976ae65db58f02985307b79d317e1ffc4f036
 *


 The release candidate artifacts are here:


 https://repository.apache.org/content/repositories/orgapachetamaya-1003/org/apache/tamaya/tamaya-distribution/0.1-incubating/tamaya-distribution-0.1-incubating-distribution-bin.zip

 SHA-1 checksums: 3eb09278b914b96fb5c6059523b1bb3e69a09334
 MD5 checksums: 24a10473841be94bdfef029e45d901741afc4ea0


 https://repository.apache.org/content/repositories/orgapachetamaya-1003/org/apache/tamaya/tamaya-distribution/0.1-incubating/tamaya-distribution-0.1-incubating-distribution-bin.tar.gz
 SHA-1
 https://repository.apache.org/content/repositories/orgapachetamaya-1003/org/apache/tamaya/tamaya-distribution/0.1-incubating/tamaya-distribution-0.1-incubating-distribution-bin.tar.gzSHA-1
 checksums: 122997a3bacabd4d1589784a9110d0b38133785b
 MD5 checksums: 7e69859a07a1c84935e6cce360f4164b

 and


 https://repository.apache.org/content/repositories/orgapachetamaya-1003/org/apache/tamaya/tamaya-distribution/0.1-incubating/tamaya-distribution-0.1-incubating-distribution-src.zip
 SHA-1 checksums: 3eb09278b914b96fb5c6059523b1bb3e69a09334
 MD5 checksums: 1dfb81f25b88de37976ee2d83ec64bf2


 https://repository.apache.org/content/repositories/orgapachetamaya-1003/org/apache/tamaya/tamaya-distribution/0.1-incubating/tamaya-distribution-0.1-incubating-distribution-src.tar.gz
 SHA-1
 https://repository.apache.org/content/repositories/orgapachetamaya-1003/org/apache/tamaya/tamaya-distribution/0.1-incubating/tamaya-distribution-0.1-incubating-distribution-src.tar.gzSHA-1
 checksums: f0aeffb3304f300e6071019d31a73a812556b8c3
 MD5 checksums: 801cec5b3fa434a786f8ee82c692c3a0

 Obviously the whole closed staging repo is here:
 https://repository.apache.org/content/repositories/orgapachetamaya-1003



 What's in this release
 

 This is our first release. It contains:

 - API and Implementation (core) compatible with Java 7 and later
 - API with additional default methods and implementation (core) based on
 Java 8
 - Out of the box properties and xml-properties are supported configuration
 formats
 - Extension Modules for
   - resource location and path lookup of configuration resources
   - placeholders and cross references
   - a configuration builder implementation
   - modeling formats, that read configuration data into a normalized data
 structure.
   - additional configuration formats support for
 - json
   - dynamic configuration events API, including an example how a folder on
 disk can be observed for
 dynamically updating configuration
   - an purely SE based injection module supporting injection, templates and
 dynamic, updateable configuration values.
 - All extension modules despite the builder modules are compatible with
 Java 7 and later
 - A bunch of documentation for
   - Use Cases
   - High Level Design
   - The current draft extension modules
 - Also tagged, but not part of 

Re: [VOTE] Apache Johnzon 0.9-incubating release

[Romain Manni-Bucau]

+1


Romain Manni-Bucau
@rmannibucau https://twitter.com/rmannibucau |  Blog
http://rmannibucau.wordpress.com | Github https://github.com/rmannibucau |
LinkedIn https://www.linkedin.com/in/rmannibucau | Tomitriber
http://www.tomitribe.com

2015-08-13 11:03 GMT-07:00 Hendrik Dev hendrikde...@gmail.com:

 The Apache Johnzon PPMC has voted to release Apache Johnzon
 0.9-incubating based on the second release candidate described below. Now
 it
 is the IPMC's turn to vote.

 Git commit for the release is

 https://git-wip-us.apache.org/repos/asf?p=incubator-johnzon.git;a=commit;h=ab542d7208c2b60aa6fdab1b11fa01a1e9ad8241

 Maven staging repo:
 https://repository.apache.org/content/repositories/orgapachejohnzon-1007

 Source releases (zip/tar.gz):

 https://repository.apache.org/content/repositories/orgapachejohnzon-1007/org/apache/johnzon/apache-johnzon/0.9-incubating/apache-johnzon-0.9-incubating-src.zip
 SHA-1:51ab45e8fb5f315c482593923c9d85af6d1bc18b


 https://repository.apache.org/content/repositories/orgapachejohnzon-1007/org/apache/johnzon/apache-johnzon/0.9-incubating/apache-johnzon-0.9-incubating-src.tar.gz
 SHA-1:f80bfce2717d632e38eb12930e1f6a5f30f0180a

 The files are also here
 https://dist.apache.org/repos/dist/dev/incubator/johnzon/

 PGP release keys (signed using 90910A83):
 https://dist.apache.org/repos/dist/release/incubator/johnzon/KEYS

 This release is mainly a bugfixing release. The mapper also introduced
 basic map support for nested converter. Snapshot deps. removed.

 The vote will be open for at least 72 hours.

 Project vote passes with 3 binding +1 votes and no -1 votes:

 http://mail-archives.apache.org/mod_mbox/incubator-johnzon-dev/201508.mbox/%3C8173EB96-FC9B-433A-B659-06A5D83E4A14%40apache.org%3E

 The vote will be open for at least 72 hours.

 [ ] +1  approve
 [ ] -1  disapprove (and reason why)

 Thanks

 --
 Hendrik Saly (salyh, hendrikdev22)
 @hendrikdev22
 PGP: 0x22D7F6EC

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

Re: Are tests part of the r patelease?

[Romain Manni-Bucau]

Le 9 août 2015 03:31, Anatole Tresch atsti...@gmail.com a écrit :

 Even for a jsr tests are not part of a release, except the ones that are
 part of the TCK.

Doesnt mean it is good or apache way ;)

 In your case you may resolve/fix the snapshot dep to bind
 to the specific snapshot version currently used...?


Has been done already.

 Jusr my 5 cents.
 Anatole
 Am 09.08.2015 11:05 schrieb Justin Mclean jus...@classsoftware.com:

  Hi,
 
   Are tests are part of the release?
 
  If they are included as source code in the released artefact yes :-)
 
   Background: We have (accidentally) a dependency to a snapshot version
   for a library but only in maven test scope.
 
  Up to the project I’d say, but I’d just raise a JIRA and fix it next
  release/before graduation if a VOTE is already underway.
 
  I could be mistaken but seem to recall other incubator releases that
  depended on a snapshot or two.
 
  Thanks,
  Justin
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 
 

Re: Are tests part of the release?

[Romain Manni-Bucau]

A tag should be buildable anytime. Snapshots can be dropped from repos so
from my understanding it is an issue even if less impacting than direct
binaries dependencies.
Le 9 août 2015 02:05, Justin Mclean jus...@classsoftware.com a écrit :

 Hi,

  Are tests are part of the release?

 If they are included as source code in the released artefact yes :-)

  Background: We have (accidentally) a dependency to a snapshot version
  for a library but only in maven test scope.

 Up to the project I’d say, but I’d just raise a JIRA and fix it next
 release/before graduation if a VOTE is already underway.

 I could be mistaken but seem to recall other incubator releases that
 depended on a snapshot or two.

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

Re: Are tests part of the release?

[Romain Manni-Bucau]

@john: no since it would likely be deleted and has no link with revisions
so it is still highly mutable
Le 9 août 2015 07:11, John D. Ament johndam...@apache.org a écrit :

 And if you're using a snapshot, just switch to the timestamp based
 snapshot.

 On Sun, Aug 9, 2015 at 8:29 AM Romain Manni-Bucau rmannibu...@gmail.com
 wrote:

  A tag should be buildable anytime. Snapshots can be dropped from repos so
  from my understanding it is an issue even if less impacting than direct
  binaries dependencies.
  Le 9 août 2015 02:05, Justin Mclean jus...@classsoftware.com a
 écrit :
 
   Hi,
  
Are tests are part of the release?
  
   If they are included as source code in the released artefact yes :-)
  
Background: We have (accidentally) a dependency to a snapshot version
for a library but only in maven test scope.
  
   Up to the project I’d say, but I’d just raise a JIRA and fix it next
   release/before graduation if a VOTE is already underway.
  
   I could be mistaken but seem to recall other incubator releases that
   depended on a snapshot or two.
  
   Thanks,
   Justin
   -
   To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
   For additional commands, e-mail: general-h...@incubator.apache.org
  
  
 

Re: [VOTE] Release Apache Johnzon 0.8-incubating

[Romain Manni-Bucau]

+1


Romain Manni-Bucau
@rmannibucau https://twitter.com/rmannibucau |  Blog
http://rmannibucau.wordpress.com | Github https://github.com/rmannibucau |
LinkedIn https://www.linkedin.com/in/rmannibucau | Tomitriber
http://www.tomitribe.com

2015-06-06 21:22 GMT+02:00 Mark Struberg strub...@yahoo.de:

 +1

 LieGrue,
 strub


  Am 06.06.2015 um 01:05 schrieb Jean-Louis MONTEIRO jeano...@gmail.com:
 
  Looks good.
 
  +1
 
  Le jeu. 4 juin 2015 à 12:43, Hendrik Dev hendrikde...@gmail.com a
 écrit :
 
  The Apache Johnzon PPMC has voted to release Apache Johnzon
  0.8-incubating based on the release candidate described below. Now it
  is the IPMC's turn to vote.
 
  Git commit for the release is
 
 
 https://git-wip-us.apache.org/repos/asf?p=incubator-johnzon.git;a=commit;h=bb26c1e8c87d7e71f7b7f6917397ed91d0866ff7
 
  Maven staging repo:
 
 https://repository.apache.org/content/repositories/orgapachejohnzon-1005
 
  Source releases (zip/tar.gz):
 
 
 https://repository.apache.org/content/repositories/orgapachejohnzon-1005/org/apache/johnzon/apache-johnzon/0.8-incubating/apache-johnzon-0.8-incubating-src.zip
  SHA-1:ba84658479be7ce1f2d716050877dfcc60c968ae
 
 
 
 https://repository.apache.org/content/repositories/orgapachejohnzon-1005/org/apache/johnzon/apache-johnzon/0.8-incubating/apache-johnzon-0.8-incubating-src.tar.gz
  SHA-1:5f80019b159862f2178898f35061307762e51ba3
  
 https://repository.apache.org/content/repositories/orgapachejohnzon-1005/org/apache/johnzon/apache-johnzon/0.8-incubating/apache-johnzon-0.8-incubating-src.tar.gzSHA-1:5f80019b159862f2178898f35061307762e51ba3
 
 
  PGP release keys (signed using 90910A83):
  https://dist.apache.org/repos/dist/release/incubator/johnzon/KEYS
 
  This release introduces websocket (jsr356) integration, fixes some
  minor issues like encoding, java 1.6 build stuff and configuration
  defaults. It contains also a bugfix so that Johnzon does now work
  properly in OSGI environments.
 
  Project vote passes with 4 binding +1 votes, one non-binding +1 vote
  and no -1 votes:
  http://markmail.org/thread/cjmvumtobyprbs6j
  http://markmail.org/thread/i47a526iqxaw4vsf
 
  The vote will be open for at least 72 hours.
 
  [ ] +1  approve
  [ ] -1  disapprove (and reason why)
 
  Thanks
  Hendrik
 
  --
  Hendrik Saly (salyh, hendrikdev22)
  @hendrikdev22
  PGP: 0x22D7F6EC
 
  -
  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: May 2015 Report Timeline

[Romain Manni-Bucau]

Hello

this is pretty sure but as bval I suspect it will be a project moving by
batch (ie when needed) and very calm the remaining time - think we
already wrote it somewhere BTW.


Romain Manni-Bucau
@rmannibucau https://twitter.com/rmannibucau |  Blog
http://rmannibucau.wordpress.com | Github https://github.com/rmannibucau |
LinkedIn https://www.linkedin.com/in/rmannibucau | Tomitriber
http://www.tomitribe.com

2015-05-12 16:49 GMT+02:00 John D. Ament johndam...@apache.org:

 Is it possible that BatchEE needs a more diverse community so that the
 usual suspects working on all those other projects can stay focused on
 those?

 On Tue, May 12, 2015 at 10:41 AM Marvin Humphrey mar...@rectangular.com
 wrote:

  On Tue, May 12, 2015 at 7:39 AM, Mark Struberg strub...@yahoo.de
 wrote:
   Hi Folks!
  
   I fear the BatchEE project wont make it for this month. We are all
  currently busy getting a few other apache releases out (OWB, OpenJPA,
  TomEE, BVal, etc).
   Is it ok to report next month?
 
  Perfectly fine.  I've already set things up so that you'll get a
  report reminder.
 
  Thanks for checking in!
 
  Marvin Humphrey
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 
 

Re: [VOTE] Release Apache Johnzon 0.7-incubating

[Romain Manni-Bucau]

+1


Romain Manni-Bucau
@rmannibucau https://twitter.com/rmannibucau |  Blog
http://rmannibucau.wordpress.com | Github https://github.com/rmannibucau |
LinkedIn https://www.linkedin.com/in/rmannibucau | Tomitriber
http://www.tomitribe.com

2015-04-03 12:50 GMT+02:00 Hendrik Dev hendrikde...@gmail.com:

 The Apache Johnzon PPMC has voted to release Apache Johnzon
 0.7-incubating based on the release candidate described below. Now it
 is the IPMC's turn to vote.

 Git commit for the release is

 https://git-wip-us.apache.org/repos/asf?p=incubator-johnzon.git;a=commit;h=97930e2a8447c330115263afc83c094d48b163c8

 Maven staging repo:
 https://repository.apache.org/content/repositories/orgapachejohnzon-1004/

 Source releases (zip/tar.gz):

 https://repository.apache.org/content/repositories/orgapachejohnzon-1004/org/apache/johnzon/johnzon/0.7-incubating/johnzon-0.7-incubating-src.zip
 SHA-1:3612c5ca729688510f44a42230b4be199b9659a6


 https://repository.apache.org/content/repositories/orgapachejohnzon-1004/org/apache/johnzon/johnzon/0.7-incubating/johnzon-0.7-incubating-src.tar.gz
 SHA-1:392cc90bda48734d78c4c4094d9dd72ef0215a26

 PGP release keys (signed using 22D7F6EC):
 https://dist.apache.org/repos/dist/release/incubator/johnzon/KEYS

 Project vote passes with 4 binding +1 votes, one non-binding +1 vote
 and no -1 votes:
 http://markmail.org/thread/m7afbsmhxgxti4fa

 This release introduces new functionality for the mapper
 (@JohnzonProperty, @JohnzonVirtualObject and @ConstructorProperties).

 The vote will be open for at least 72 hours.

 [ ] +1  approve
 [ ] -1  disapprove (and reason why)

 Thanks

 --
 Hendrik Saly (salyh, hendrikdev22)
 @hendrikdev22
 PGP: 0x22D7F6EC

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

Re: Do we need @ASFIncubator ?

[Romain Manni-Bucau]

+1 to keep @TheASF, will avoid noise or misunderstanding when a project is
graduated + for general announcements it is more consistent.


Romain Manni-Bucau
@rmannibucau https://twitter.com/rmannibucau |  Blog
http://rmannibucau.wordpress.com | Github https://github.com/rmannibucau |
LinkedIn https://www.linkedin.com/in/rmannibucau | Tomitriber
http://www.tomitribe.com

2015-03-24 8:51 GMT+01:00 Bertrand Delacretaz bdelacre...@apache.org:

 On Mon, Mar 23, 2015 at 10:05 PM, Roman Shaposhnik r...@apache.org wrote:
  ...should we leverage @TheASF for
  the incubator-level announcements or should we
  establish our own handle?...

 I would prefer using @TheASF and keeping Sally in the loop so the can
 keep the overview on those announcements.

 But if people want to create and maintain a specific handle, I'm not
 opposed.

 -Bertrand

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

Re: [VOTE] Accept Groovy into the Apache Incubator

[Romain Manni-Bucau]

+1
 Le 19 mars 2015 09:07, Ashish paliwalash...@gmail.com a écrit :

 +1 non-binding

 On Thu, Mar 19, 2015 at 12:25 PM, Roman Shaposhnik r...@apache.org wrote:
  Following the discussion earlier in the thread:
 http://s.apache.org/KWE
 
  I would like to call a VOTE for accepting Groovy
  as a new incubator project.
 
  The proposal is available at:
  https://wiki.apache.org/incubator/GroovyProposal
  and is also included at the bottom of this email.
 
  Vote is open until at least Saturday, 21st March 2015, 23:59:00 PST
 
   [ ] +1 accept Groovy in the Incubator
   [ ] ±0
   [ ] -1 because...
 
  Thanks,
  Roman.
 
  == Abstract ==
  Groovy is an object-oriented programming language for the Java
  platform. It is a language with features similar to those of Python,
  Ruby, Java, Perl, and Smalltalk.
  Groovy, if accepted by Incubator, will be a first major programming
  language developed under the umbrella of Apache Software Foundation.
 
  == Proposal ==
  Groovy is a programming language for the Java platform. It is a
  primarily dynamic language with features similar to those of Python,
  Ruby, Perl, and Smalltalk. It also has optional static type checking
  and static compilation facilities. It can be used as a scripting
  language for the Java Platform or to write complete applications, is
  compiled to Java Virtual Machine (JVM) bytecode, and interoperates
  with other Java code and libraries. Groovy uses a Java-like
  curly-bracket syntax. Most Java code is also syntactically valid
  Groovy, although semantics may be different. Groovy has long been
  developed under an Apache License v2.0 under an open governance
  community management process. However, so far Groovy has been a
  project mostly sponsored by a single company. This proposal aims at
  bringing Groovy community under the umbrella of the Apache Software
  Foundation.
 
  It must be explicitly noted, that a few sister projects such as Groovy
  Eclipse and others (some of them hosted under
  https://github.com/groovy and listed at
  http://groovy-lang.org/ecosystem.html) are not covered by this
  proposal. It is possible that these other projects will be joining ASF
  either independently or as sub-projects of Apache Groovy in the
  future. For now, we are only proposing groovy-core.
 
  == Background ==
  Groovy 1.0 was released on January 2, 2007, and Groovy 2.0 in July,
  2012. Groovy 2.5 is planned for release in 2015. Groovy 3.0 is planned
  for release in 2016, with support for a new Meta Object Protocol.
  Since version 2, Groovy can also be compiled statically, offering type
  inference and performance very close to that of Java. Groovy 2.4 will
  be the last major release under Pivotal Software's sponsorship, which
  is scheduled to end on March 31, 2015.
 
  == Rationale ==
  Groovy is a pretty mature language. After 12 years of development, it
  has grown from being primarily a dynamic scripting language on the JVM
  to an optionally statically compiled language allowing the same
  performance level as Java applications. With the release of Groovy
  2.4, the language targets the largest pool of mobile developers with
  native Android support. Groovy has been integrated in a large number
  of applications, including well known open-source projects like
  Jenkins, Gradle, ElasticSearch, Spring and more.
 
  There are multiple alternative languages on the JVM: Scala, Clojure,
  Ceylon, Kotlin, JRuby, Golo and others but Groovy is the only one
  which has proved to be very easy to integrate with Java in both ways:
  Groovy code using Java code, but also Java code using Groovy code.
  Groovy even provides a joint compiler which allows interdependent Java
  and Groovy classes to compile together. Groovy also supports dynamic
  code generation, that is to say classes at runtime, making it a
  perfect fit for scripting. With a very lightweight and malleable
  syntax, it is also easy to build internal Domain Specific Languages
  (DSLs) which integrate smoothly within applications.
 
  Groovy provides a number of unique features, like builders (Java 8 has
  lambdas but still has syntactic overhead and no notion of delegate),
  AST transformations (compile-time metaprogramming) or type checking
  extensions (which allows the developer to bring the compiler to levels
  of type checking and type inference that go far beyond what other
  languages do). Groovy also provides powerful integration options and
  customizations which set it apart from other languages. Groovy is also
  unique in the way it allows the developer to choose between various
  paradigms without compromise: functional vs object-oriented,
  statically compiled vs dynamic, scripting vs applications, etc.
 
  Despite all those advantages, and the fact that Groovy is widely
  adopted (4.5 million downloads in 2014 for Groovy alone), only a few
  Apache projects include Groovy and not a lot of them leverage its full
  power. Some developers tend to choose Scala for 

Re: [VOTE] Release Apache Johnzon 0.6-incubating

[Romain Manni-Bucau]

+1


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-02-20 14:23 GMT+01:00 Hendrik Dev hendrikde...@gmail.com:
 The Apache Johnzon PPMC has voted to release Apache Johnzon
 0.6-incubating based on the release candidate described below. Now it
 is the IPMC's turn to vote.

 Git commit for the release is
 https://git-wip-us.apache.org/repos/asf?p=incubator-johnzon.git;a=commit;h=dda975b327211277fc96c4155b6e98bc54a4a7d9

 Maven staging repo:
 https://repository.apache.org/content/repositories/orgapachejohnzon-1003/

 Source releases (zip/tar.gz):
 https://repository.apache.org/content/repositories/orgapachejohnzon-1003/org/apache/johnzon/johnzon/0.6-incubating/johnzon-0.6-incubating-src.zip
 https://repository.apache.org/content/repositories/orgapachejohnzon-1003/org/apache/johnzon/johnzon/0.6-incubating/johnzon-0.6-incubating-src.tar.gz

 PGP release keys (signed using 22D7F6EC):
 https://dist.apache.org/repos/dist/release/incubator/johnzon/KEYS

 Project vote passes with 3 binding +1 votes, one non-binding +1 vote
 and no -1 votes:
 http://markmail.org/thread/25qwunhagpurthev
 http://markmail.org/thread/tppdxzn7dz3rhdxq

 This release fixes a few bugs related to comment parsing and mapper.

 The vote will be open for at least 72 hours.

 [ ] +1  approve
 [ ] -1  disapprove (and reason why)

 Thanks

 --
 Hendrik Saly (salyh, hendrikdev22)
 @hendrikdev22
 PGP: 0x22D7F6EC

 -
 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] Release Apache Johnzon 0.2-incubating

[Romain Manni-Bucau]

+1


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2014-11-18 15:54 GMT+01:00 Hendrik Dev hendrikde...@gmail.com:
 Hi all,

 Please vote on releasing the following candidate as Apache Johnzon
 0.2-incubating.
 This will be the second incubator release for Johnzon.

 The project vote on the dev list is here:
 http://markmail.org/thread/okwf7wpczerz2cq6

 Vote result:
 3 binding +1 votes
 2 non-binding +1 votes
 No -1 votes

 Git commit for the release is [56c9789]
 https://git-wip-us.apache.org/repos/asf?p=incubator-johnzon.git;a=commit;h=56c9789b3de1fbdcbf0a260ba2f26fce70171ffa

 Maven staging repo:
 https://repository.apache.org/content/repositories/orgapachejohnzon-1001

 Source releases (zip/tar.gz):
 http://repository.apache.org/content/repositories/orgapachejohnzon-1001/org/apache/johnzon/johnzon/0.2-incubating/johnzon-0.2-incubating-src.zip
 http://repository.apache.org/content/repositories/orgapachejohnzon-1001/org/apache/johnzon/johnzon/0.2-incubating/johnzon-0.2-incubating-src.tar.gz

 Site is here:
 http://people.apache.org/~salyh/johnzon-0.2-incubating-site/

 PGP release keys (signed using 22D7F6EC):
 https://dist.apache.org/repos/dist/release/incubator/johnzon/KEYS

 The vote will be open for at least 72 hours.

 [ ] +1  Release this packge
 [ ] -1  Do not release this package because ...

 Thanks
 Hendrik

 --
 Hendrik Saly (salyh, hendrikdev22)
 @hendrikdev22
 PGP: 0x22D7F6EC

 -
 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] Apache Tamaya for Incubation

[Romain Manni-Bucau]

 location pattern like access as well as
  ''injection'' of configured values.
   * it is simple in use and easily extensible.
   * it support integration with existing configuration solutions
  currently in use, both OSS as well as customized in-house proprietary
  solutions
 
 
  == Initial Goals ==
 
  The initial goals of the Apache Tamaya project are to:
 
   * Setup the governance structure of the project
   * Receive code donations from https://github.com/java-config
   * Ensure all donated code is appropriately licensed under the Apache
 License
   * Merge and rename code to reflect new project name
   * Define the project modules and structure (API, implementation
  modules, adapter modules, examples)
   * Provide examples demonstrating feature usage
   * Produce release/s based on a schedule created by the PMC
   * Attract contributions from the greater Java community
   * Setup collaboration with other projects and the JCP to bring in
  ideas and enhancement proposals, e.g. to Java EE 8
 
  == Current Status ==
  There is an existing running code base implementing a significant part
  of the features mentioned already athttps://github.com/java-config and
  licensed under Apache v2.0, which will be contributed into the
  incubator.
  The separation between API and implementation hereby should stay
 enforced, since
 
   * it reflects the structure also required for later JSRs
   * it helps focusing discussions on the core API artifacts before dive
 into implementation details.
   * it helps to ensure the core API is simple and overall comprehensive.
   * it enables to provide different implementations, especially also a
  Java ME compatible solution.
 
  == Meritocracy ==
  We plan to do everything possible to encourage an environment that
  supports a meritocracy. We did the same as well with
  JSR 354, were people throughout the world helped us to get the RI/TCK
  at a very good level. Similarly, whenever
  possible, we encouraged people to join the expert group, so they also
  would be capable of contributing to the
  API directly. In all cases we discussed all questions amd feedback
  transparently regardless if it was an EG member
  or just a member of Hackday, Hackergarten.
 
  == Community ==
  The project initiative already is significantly supported by JUGs such
  as SouJava, LJC, iJUG, Berlin Brandenburg JUG,
  JUG Zurich, as well as companies such as Credit Suisse and Walmart. It
  is expected that support will
  raise very quickly so the library will evolve and be widely used as well.
 
  == Core Developers ==
  The core team will be a set of well known experts from the Java SE and
  EE area (in random order):
 
   * '''Anatole Tresch''' (Lead) is employed at Credit Suisse. He leads
  JSR 354 (Money  Currency) and also was planned as cospec lead for
  Java EE configuration JSR together with Oracle. He also is a member of
  the CDI 2.0 expert group and is actively driving the configuration
  topic.
   * '''Gerhard Petracek''' is Apache MyFaces und DeltaSpike PMC chair.
   * '''Andres Almiray''': Groovy aficionado, Griffon project lead, Java
 Champion.
   * '''Joe Pullen''' is a known expert, especially for JPA and Batch
  and also former EC member of the corresponding JSRs.
   * '''Mark Struberg''' acts as PMC and Committer for Apache
  OpenWebBeans, BatchEE, MyFaces, Maven, OpenJPA, BVal, DeltaSpike and
  other projects
   * '''Werner Keil''' aka Java Godfather is individual JCP EC member
  and member of the Advisory Board of Developer Week contributing to
  several JSR's in the SE and EE area. He is spec lead of the Units and
  Measurements JSR. Werner is already a committer of ASF.
   * '''Otávio Gonçalves de Santana''' Member of ''SouJava'' and OpenJDK
  committer. He contributes regularly to several JSRs and recently was
  awarded in 2014 as most valuable JCP member.
   * '''Marco Zurmühle''': Member of Credit Suisse working in the Core
  Frameworks Area, which is also responsible for application
  configuration management, and a regular member of the Zurich
  Hackergarten.
   * '''Oliver B. Fischer''': Leader of the JUG Berlin Brandenburg and
  conference speaker.
   * '''David Blevins''': Founder of the Apache TomEE, OpenEJB and
  Geronimo projects. JCP participant in JavaEE and EJB.
   * '''John D. Ament''': Author of Arquillian Testing Guide an
  Enterprise software architect,
   * '''Romain Manni-Bucau''': Developer convinced by Open Source,
  highly active on Apache TomEE, Sirona and other Apache projects
  (OpenEJB, Camel, CXF, Sirona, BatchEE, OpenWebBeans...).
 
  It is expected that more people will join the incubator once it's
 running:
 
   * We are already in contact with several companies from Europe and
  US, that are heavily interested in contributing to this initiative.
   * '''LJC (London Java Community), SouJava,JUG Chennai''' will do
  Hackdays and provide feedback.
   * '''JUG Berlin Brandenburg''' is one of the bigger JUGs in Germany
  and would probably also

Re: [PROPOSAL] Apache Tamaya Configuration

[Romain Manni-Bucau]

+1, interested to be part of the project as well.
 Hi all,

Thanks for the feedback thus far on the Tamaya proposal.  Based on prior
discussion, I'd like to present the proposal found at
https://wiki.apache.org/incubator/TamayaProposal as well as copied below.

Please take a look and let me know what you think.  Please don't hesitate
to make any changes as seen fit on the wiki.

--
*Anatole Tresch*
Java Engineer  Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon

*Switzerland, Europe Zurich, GMT+1*
*Twitter:  @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
http://javaremarkables.blogspot.ch/*

*Google: atsticksMobile  +41-76 344 62 79*













































































*= Apache Tamaya - Proposal === Abstract ==Tamaya is a highly flexible
configuration solution based on an modular, extensible andinjectable
key/value based design, which should provide a minimal but
extendible modern and functional API leveraging SE, ME and EE
environments.''Tamaya'' hereby translates into ''in the middle'', which is
exactly, what configuration should be. It should bein the middle between
your code and your runtime.'''NOTE:''' Alternative names could be
''Mahkah=earth, Dakota=friend'' or ''Orenda=magic force''.== Proposal
==Tamaya is a highly flexible configuration API based on an modular,
extensible andinjectable key/value based design. The basic building blocks
hereby are: * ''property providers'' implementing a small and easily
implementable subset of a `MapString,String`.  * support for
configuration injection * a type-safe configuration template mechanism *
serializable and remote configuration support * a JMX/Rest based management
console * Configuration will follow the GoF composite pattern and support
several combination strategies. * An extendible and adaptable environment
model, so configuration can be provided dependent of the environment
currently active. * extension points and a powerful SPI to seamlessly add
additional logic to the API, such as secured views, multi-valued validation
schemes, en-/decryption etc. * Configuration (and property providers) are
designed and implemented as indirectly mutable types, providing thread-safe
and performant to configuration. * Configuration changes can be observed by
listening on `ConfigChange` events.The API's focus is on simplicity and
ease of use. Developers should only have to know a minimal set of artifacts
to work with the solution.The API is built on latest Java 8 features and
therefore fit perfectly with the functional features of Java 8.Additionally
Apache Tamaya will provide * A Java SE based implementation with minimal
features and dependencies. * A Java EE extension module for integration
with Java EE and Apache Deltaspike. * Once Java ME supports Lambdas,
default methods, method references and functional interfaces an
implementation targeting Java ME should be provided as well. * Extension
modules for different features. * Adapter/inter-operation modules for other
configuration solutions including Apache commons-config == Background
==There is a global initiative running now for about a year lead by Anatole
Tresch (Credit Suisse)with the target of standardizing configuration in
Java EE and SE. Due to several reasons itseems currently most sensible to
start an OSS project on the topic to join forces that activelywant to
contribute to the project. It is highly probably that standardization will
be restartedat a later point once we have a widely used Apache standard.For
further information you may look at http://javaeeconfig.blogspot.com
http://javaeeconfig.blogspot.com .== Rationale ==Configuration is one of
the most cross-cutting concerns, which still lacks of a standard. Java EE
is currently (EE7) in most areas strictly only configurable duringbuild
time of the deployed artifacts. Especially dynamic provisioning of
resources or runtime configurationis not supported and in many cases
impossible to add without tweaking the underlying application server.On the
other hand running two separate configuration solutions for Java EE and
Java SE as well make no orlittle sense. So it would be important we have a
unified configuration model at hand, that is flexible enough, so * it can
be used in Java SE, EE and ME * it can support contextual behaviour (like
in Java EE and multi-tenancy/SaaS scenarios) * it provides a uniform API,
regardless, if its used in SE or EE scenarios * it supports existing APIs,
e.g. `System.getProperties, java.util.preferences` in SE and `CDI, JNDI` in
Java EE * it supports service location pattern like access as well as
''injection'' of configured values. * it is simple in use and easily
extensible. * it support integration with existing configuration solutions
currently in use, both OSS as well as customized in-house proprietary
solutions== Initial Goals ==The initial goals of the Apache Tamaya project
are to: * Setup the governance structure of the project * Receive code
donations 

Re: [DISCUSS] New Incubator Project for Enterprise Configuration

[Romain Manni-Bucau]

2014-11-03 9:13 GMT+01:00 Jean-Louis MONTEIRO jeano...@gmail.com:
 I do think it's an interested and important topic.

 Was wondering what's Anatole position as the Configuration JSR as been
 deferred from Java EE 8.
 Even if Mark and Gerhard are also part of DeltaSpike, that'd be great to
 avoid having many different configuration projects in Apache and then
 splitting forces.
 Probably also a good opportunity to move commons-configuration from
 proper/dormant.


Not sure about this last part, [configuration] is active and it will
be important to keep it active. But it doesn't prevent to implement
any other JSR as we did for [jcs]. That's what I'd do: enrich an
existing project with this api and EE side.

wdyt?

 Jean-Louis

 2014-11-02 21:31 GMT+01:00 John D. Ament john.d.am...@gmail.com:

 Anatole,

 Thirded to the same notes.

 If you haven't read it already, please look at how to start the proposal
 (you have mostly the right form, just needs to be on the wiki).
 http://incubator.apache.org/guides/proposal.html .  You should be able to
 assume that the sponsoring entity is the incubator as well.  Your core
 developers and initial committers don't match.  Was this on purpose?
 Please also list a champion.  For all intents and purposes, that should be
 you Anatole.

 If you're looking for assistance in mentors you can include me.

 John

 On Sun Nov 02 2014 at 12:01:02 AM Roman Shaposhnik ro...@shaposhnik.org
 wrote:

  On Fri, Oct 31, 2014 at 1:42 AM, Bertrand Delacretaz
  bdelacre...@apache.org wrote:
   Hi Anatole,
  
   On Thu, Oct 30, 2014 at 8:58 PM, Anatole Tresch atsti...@gmail.com
  wrote:
   ...The current proposal is available on GitHub:
   https://github.com/java-config/javaconfig-api/blob/
  master/src/main/asciidoc/incubator-proposal-tamaya.adoc ...
  
   Looks interesting, I would vote +1 to incubate the project once you
   have recruited 3 mentors - maybe the people listed as sponsors would
   take this role?
  
   You'll need to move the proposal to http://wiki.apache.org/incubator/
   before we can vote on it, to get write access to that create an
   account and let us know your username.
 
  This looks interesting to me as well. Both points that Bertrand raised
  are fully seconded, btw.
 
  Thanks,
  Roman.
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 
 




 --
 Jean-Louis

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

Re: [DISCUSS] [PROPOSAL] HTrace for Apache Incubator

[Romain Manni-Bucau]

2014-11-03 20:04 GMT+00:00 Jean-Louis MONTEIRO jeano...@gmail.com:
 BTW, wondering how to get the Apache Sirona community involved or if there
 is a possible common road where the 2 projects could join.


+1. having a single solution would be awesome and sirona is just
starting to get there so wommunity will be happy to get help on this
part

 2014-11-03 20:27 GMT+01:00 Roman Shaposhnik r...@apache.org:

 Hi!

 Thanks for the positive feedback and volunteering. I think the
 more mentors the merrier -- all the folks who volunteered
 please add your names to the wiki.

 As for the name, personally, I really like Distrace. That said,
 I'd leave this bikesched to be painted for later ;-)

 Andrew, great point on the wording: I'll update the proposal.

 Finally, since I'm currently on vacation, I'll let this thread
 go for a little longer and will start the official VOTE in a few
 days.

 Thanks,
 Roman.

 On Fri, Oct 31, 2014 at 4:06 PM, Roman Shaposhnik r...@apache.org wrote:
  Hi!
 
  I would like to propose HTrace to be consider for
  Apache Incubator. The proposal is attached and
  is also available on the wiki:
  https://wiki.apache.org/incubator/HTraceProposal
 
  Please let me know what do you guys think and also
  don't hesitate to massage the proposal on the wiki
  based on the feedback from this thread.
 
  Thanks,
  Roman.
 
  == Abstract ==
  HTrace is a tracing framework intended for use with distributed
  systems written in java.
 
  == Proposal ==
  HTrace is an aid for understanding system behavior and for reasoning
  about performance
  issues in distributed systems. HTrace is primarily a low impedance
  library that a java
  distributed system can incorporate to generate ‘breadcrumbs’ or
  ‘traces’ along the path
  of execution, even as it crosses processes and machines. HTrace also
  includes various
  tools and glue for collecting, processing and ‘visualizing’ captured
  execution traces
  for analysis ex post facto of where time was spent and what resources
  were consumed.
 
  == Background ==
  Distributed systems are made up of multiple software components
  running on multiple
  computers connected by networks. Debugging or profiling operations run
  over non-trivial
  distributed systems -- figuring execution paths and what services,
 machines, and
  libraries participated in the processing of a request -- can be involved.
 
  == Rationale ==
  Rather than have each distributed system build its own custom
  ‘tracing’ libraries,
  ideally all would use a single project that provides necessary
  primitives and saves
  each project building its own visualizations and processing tools anew.
 
  Google described “...[a] large-scale distributed systems tracing
 infrastructure”
  in Dapper, a Large-Scale Distributed Systems Tracing Infrastructure. The
 paper
  tells a compelling story of what is possible when disparate systems
 standardize
  on a single tracing library and cooperate, ‘passing the baton’, filling
 out
  trace context as executions cross systems.
 
  HTrace aims to provide a rough equivalent in open source of the
 described core
  Dapper tools and library.  As it is adopted by more projects, there will
 be a
  ‘network effect’ as HTrace will provide a more comprehensive view of
 activity
  on the cluster.  For example, as HDFS gets HTrace support, we can
 connect this
  with the HTrace support in HBase to follow HBase requests as they enter
 HDFS.
 
  Given the success of HTrace depends on its being integrated by many
 projects,
  HTrace should be perceived as unhampered, free of any commercial,
 political,
  or legal ‘taint’. Being an Apache project would help in this regard.
 
  == Initial Goals ==
  HTrace is a small project of narrow scope but with a grand vision:
* Move the HTrace source and repository to Apache, a vendor-neutral
  location. Currently HTrace resides at a Cloudera-hosted repository.
* Add past contributors as committers and institute Apache governance.
* Evangelize and encourage HTrace diffusion. Initially we will
  continue a focus on the Hadoop space since that is where most of the
  initial contributors work and it is where HTrace has been initially
  deployed.
* Building out the standalone visualization tool that ships with
 HTrace.
* Build more community and add more committers
 
  == Current Status ==
  Currently HTrace has a viable Java trace library that can be interpolated
  to create ‘traces’.  The work that needs to be done on this library is
 mostly
  bug fixes, ease-of-use improvements, and performance tweaks.  In the
 future,
  we may add libraries for other languages besides Java.
 
  HTrace has means of dumping traces to the filesystem, Twitters’ Zipkin
  (a tracing
  sink and visualization system developed by Twitter
  https://github.com/twitter/zipkin),
  or Apache HBase.  Executions can be viewed either in Zipkin or in pygraph
  (https://code.google.com/p/python-graph/).
 
  Since the initial sprint in the summer