geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Cabrera <l...@toolazydogs.com>
Subject Re: Discuss: Move Geronimo to Attic
Date Thu, 09 Mar 2017 23:55:31 GMT
I’m not opposed to aggregation, per se.  I’m just trying to point out a possibly different
way of jumpstarting community activity, a different way of searching for a new direction for
Geronimo.

It’s different than doing an inventory of stuff we have and thinking, “how can we make
this stuff more enticing to people?”  An inventory is good, but make sure that it’s not
an inventory of deck chairs on the Titanic.  Collecting such an inventory may just be busywork,
and a bit premature, without the the goal of fulfilling a specific need to provide direction.
 The inventory of stuff as a starting point may blind one to other possibilities for Geronimo.

Elucidating the need comes first.  The enumerating features to fulfill that need comes second.
 Once that is known it will help provide direction as to what parts of Geronimo are relevant
and what aren’t, what parts need to be spruced up and what parts are fine as is.

Think BIG!

I have one idea.  It’s something that I don’t think has been done yet, at least to the
extent that it’s been done at LinkedIn, and it fulfills a dire need.  

The management of runtime-configurations for heterogeneous global environments.  At LinkedIn,
we treat runtime properties like code.  Not just in the sense of a “source code repository”,
but also in the sense that services can declare what properties they consume and the CI/CD
pipeline will prevent those properties from being borked.  This is very handy when properties
are shared amongst multiple services across multiple fabrics.  It also does constraint checking
to make sure properties adhere to certain constraints that can be set at the component code
level, service level, and “SRE level”.

Such a system can provide visibility as to what properties are being used, not being used,
or need to be provided before rolling a service into a new fabric/edge.

It fulfills a need for what is usually given little thought as a service is tossed over the
wall for an SRE to contend with.  It forces early conversations between the component provider
and the service owner.  It forces early conversations between a service owner and the SRE,
before deployment.  It forces component and service owners to diligently consider how their
products will be managed out in the field, possibly before code is even cut, and globally
enforces those runtime contracts throughout the lifetime of that product in the CI/CD pipeline.

So, this isn’t just JEE.  This is JEE, Play, ATS, Docker, Rails, Httpd, NodeJS, Hadoop,
…

This isn’t just services.  This is the CI/CD pipeline of Jenkins, Travis, …

Well, that’s it.  One idea to consider.


Regards,
Alan

> On Mar 9, 2017, at 8:49 AM, Romain Manni-Bucau <rmannibucau@gmail.com> wrote:
> 
> I have quite a hard time to understand why it is an issue having a project led by the
aggregation of others and not by itself? Assume one sec we close Geronimo or it doesnt exist,
then we'll move the bit of code in one of the project - let say tomee - and tomee will becomes
the exact same kind of project. The alternative is to split in a lot of small projects but
as mentionned a lot of overlap is in these projects in term of forces and it doesn't work
really better, it just multiply the work load for each contributor. That's why I think G is
not a bad solution as it is today. Scope surely needs to be refined like Mark started to do
and objectives are clearly a bit different than a project pushing its own server/solution
but I think there is a space for it and for Apache I think it is saner this way.
> 
> 
> 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-03-09 17:01 GMT+01:00 Alan Cabrera <list@toolazydogs.com <mailto:list@toolazydogs.com>>:
> It has been my personal experience that need is the catalyst for a vibrant OSS project.
 The product and community spring forth from that.  Adopting an “if we build it they will
come” tactic does not usually result in success.  Rather than rummaging through the trunk
to see what bits people might be attracted to, maybe it might be better to look at the existing
JEE-related OSS communities out there and ask “what need are they not fulfilling?”
> 
> That would answer passersby’s questions of “why would I be interested in this project?”
 
> 
> That would be a slam dunk to present to the ASF board, “Geronimo is now focused on
fulfilling a new need, X”.
> 
> What unfulfilled need is out there?
> 
> 
> Regards,
> Alan
> 
> 
> 
>> On Mar 9, 2017, at 7:04 AM, Mark Struberg <struberg@yahoo.de <mailto:struberg@yahoo.de>>
wrote:
>> 
>> I totally agree.
>> 
>> But interest from the community is always a product of a good product and feature
roadmap.
>> Without any good product you will not be able to build a sustainable community around
it.
>> 
>> Of course there are many things which can trash a community despite a good product.
But without product there is no community.
>> At the end we are not here only because the people are great, but because we see
a benefit in the product we create in this project - AND the people are great ;)
>> 
>> So my first goal was to identify the features which might be of interest.
>> The next step is to check whether there is enough community interest in those features
or whether we could move then to another community. Ideally with still using the org.apache.geronimo
groupId and packages. Otherwise it would be quite some problem for the users.
>> 
>> LieGrue,
>> strub
>> 
>>> Am 09.03.2017 um 14:46 schrieb Alex Karasulu <akarasulu@apache.org <mailto:akarasulu@apache.org>>:
>>> 
>>> I think more important than whether or not JEE is popular (or whatever along
those lines), are the questions about community health and is the PMC still capable of fulfilling
its duties.
>>> 
>>> My 2 cents,
>>> --Alex
>>> 
>>> On Thu, Mar 9, 2017 at 12:08 PM, Mark Struberg <struberg@yahoo.de <mailto:struberg@yahoo.de>>
wrote:
>>> Romain and I went through the Geronimo SVN and made a list of which components
are used by other projects.
>>> 
>>> 
>>> Useful Geronimo components from https://svn.apache.org/repos/asf/geronimo/ <https://svn.apache.org/repos/asf/geronimo/>
>>> 
>>> https://svn.apache.org/repos/asf/geronimo/KEYS <https://svn.apache.org/repos/asf/geronimo/KEYS>
>>> 
>>> https://svn.apache.org/repos/asf/geronimo/components/txmanager <https://svn.apache.org/repos/asf/geronimo/components/txmanager>
>>>        • TomEE (txmgr+connector)
>>>        • Meecrowave (txmgr)
>>>        • Aries (txmgr)
>>> 
>>> https://svn.apache.org/repos/asf/geronimo/components/geronimo-schema-javaee_6
<https://svn.apache.org/repos/asf/geronimo/components/geronimo-schema-javaee_6>
>>> 
>>> https://svn.apache.org/repos/asf/geronimo/genesis/ <https://svn.apache.org/repos/asf/geronimo/genesis/>
>>>        • Maven parents for geronimo-specs
>>> 
>>> https://svn.apache.org/repos/asf/geronimo/javamail/ <https://svn.apache.org/repos/asf/geronimo/javamail/>
>>>        • TomEE as delivery
>>>        • Lot of standalone
>>>        • -> we can ask Hendrik pby
>>> 
>>> https://svn.apache.org/repos/asf/geronimo/specs/ <https://svn.apache.org/repos/asf/geronimo/specs/>
>>>        • TomEE
>>>        • OpenWebBeans
>>>        • Meecrowave
>>>        • OpenJPA
>>>        • Johnzon
>>>        • BatchEE
>>>        • Karaf
>>>        • Aries
>>>        • Tons of external customer projects which don’t want to use some
official javax jars due to licensing concerns
>>> 
>>> https://svn.apache.org/repos/asf/geronimo/xbean/ <https://svn.apache.org/repos/asf/geronimo/xbean/>
>>>        • TomEE
>>>        • OpenWebBeans
>>>        • Meecrowave
>>>        • Aries
>>>        • Karaf
>>>        • OpenJPA
>>>        • CXF (supported)
>>> 
>>> Osgi-locator too but guess this one can drop and belong to karaf or servicemix.
>>> Q: well we need the osgi locator in our geronimo-specs, isn’t?
>>> 
>>> 
>>> I've created a google doc. Just ping me if you want to edit something and I'll
share it.
>>> 
>>> David, you mentioned JASPIC. I could not find that even. Is this inside the geronimo-server
probably?
>>> Are there other gems which are not maintained as components but just inside geronimo?
>>> 
>>> txs and LieGrue,
>>> strub
>>> 
>>> 
>>>> Am 09.03.2017 um 08:44 schrieb David Jencks <david.a.jencks@gmail.com
<mailto:david.a.jencks@gmail.com>>:
>>>> 
>>>> I go back and forth on whether to shut G down completely.  Perhaps it would
be useful to inventory which parts are used by which other projects? Off the top of my head….
>>>> 
>>>> Specs …. who uses G’s and who has their own?
>>>> 
>>>> Components…. I think there are several users of the transaction manager,
I don’t know about the connector framework, and I’m pretty sure no one uses my jaspic
implementation.  The TM is stable but now that faster than spinning rust persistent memory
is popular the logger could probably be rewritten to be much faster.
>>>> 
>>>> xbean …. tomee I believe, anyone else?  Does activemq still use xbean-spring?
 Knowing more about osgi now I might be able to gets xbean-blueprint to work:-)
>>>> 
>>>> yoko is used by IBM, I doubt anyone else will get all excited about CORBA
and start contributing.
>>>> 
>>>> Any other bits being used?
>>>> 
>>>> If we kept G around in a reduced state, how will we maintain enough interest
to file the board reports?  Some days  I think I might have enough interest and some days
not.
>>>> 
>>>> If we did not shut down the whole project would we mark the removed bits
(server primarily) as not being developed or move them to the attic?
>>>> 
>>>> thanks
>>>> david jencks
>>>> 
>>>>> On Mar 8, 2017, at 11:15 PM, Romain Manni-Bucau <rmannibucau@gmail.com
<mailto:rmannibucau@gmail.com>> wrote:
>>>>> 
>>>>> A valid point is activity related to G happens elsewhere, However elsewhere
is not "tomee" which would make things simple to move but A, B, C so shutting down G is likely
the easiest solution for G itself but also the worse for all its dependent projects - and
ASF consistency since G is now seen as the owner of specs, xbean etc....Today G is the result
of communities and I don't see it as a bad thing even if not common @ASF. It allows new interactions
with sometimes completely different area of knowledge which is actually great and can't happen
elsewhere IMHO (the dead of G would mean fork per project probably).
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Romain Manni-Bucau
>>>>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
>>>>> 
>>>>> 2017-03-09 5:13 GMT+01:00 Matt Hogstrom <matt@hogstrom.org <mailto:matt@hogstrom.org>>:
>>>>> I’ve monitored G for several years since my departure.  For me, JEE
is not my main area of focus and as such, I’ve invested little time in the project apart
from reading the e-mail threads.  This is a community decision and posting the discussion
to dev@ is the right venue.
>>>>> 
>>>>> As an inactive member I don’t have a strong vote, but, my observation
is that most of the community has moved on and there is little activity.  If those that are
still active want to keep going then God’s speed.
>>>>> 
>>>>> Matt Hogstrom
>>>>> matt@hogstrom.org <mailto:matt@hogstrom.org>
>>>>> +1-919-656-0564
>>>>> PGP Key: 0x90ECB270
>>>>> Facebook  LinkedIn  Twitter
>>>>> 
>>>>> "I’m smart enough to know how dumb I am."
>>>>> -  Hogstrom
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Mar 9, 2017, at 08:47, Jason Dillon <jdillon@apache.org <mailto:jdillon@apache.org>>
wrote:
>>>>>> 
>>>>>> On March 8, 2017 at 10:44:45 AM, Mark Struberg (struberg@yahoo.de
<mailto:struberg@yahoo.de>) wrote:
>>>>>>> Alan, I understand that you don't want to put much more energy
into this project. That is totally understandable and fine.
>>>>>>> But while you are PMC chair you still cannot declare that the
project is dead as long as there are enough PMC members still active to keep the project going.
>>>>>> 
>>>>>> Mark, I agree with Alan and Kevan, though put into my own words I
think the project and community is no longer viable (and has not been for a while).  I do
believe there are still useful aspects to the project, but I don’t think its enough to leave
on its own.
>>>>>> 
>>>>>> We can certainly wait for more PMC members to chime in if they are
still monitoring.  As Jeff recommended I’m including the private@ list for PMC folks that
may not be paying as much attention to the dev@ list.
>>>>>> 
>>>>>>> Before we dump the project I suggest we start with an analysis
of where we are right now.
>>>>>>> 
>>>>>>> What about starting look into
>>>>>>> .) Who is still active and willing to continue Geronimo as a
ee-commons project?
>>>>>> So far I’ve not really seen anyone over the past days of communication
about this.  But we’ll see.
>>>>>> 
>>>>>> —jason
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> .) Which project parts of the project are of some shared interest
and might be good to get some maintenance love and some realistic chance that this is gonna
happening?
>>>>>> I can’t speak for the others, but I have zero interested in putting
any love in to any of what is presently here.
>>>>>> 
>>>>>> I will defer to others to explain if they feel otherwise, though
I do recall some chatter on private@ but will probably need those folks to re-post to dev@
to include that discussion.
>>>>>> 
>>>>>> —jason
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Best Regards,
>>> -- Alex
>> 
> 
> 


Mime
View raw message