incubator-kitty-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Sacks <>
Subject Re: Incubator PMC/Board report for Jan 2012 ([ppmc])
Date Thu, 16 Feb 2012 06:41:34 GMT
On 1/12/2012 2:36 PM, wrote:
> Hi All,
> I thought I would chime in to put things in perspective a bit.
> The original goal was originally to find a universal, fast, command 
> line JMX client.
> Such a tool would be incredibly useful, Java applications and 
> application servers, and JMX are not going anywhere, and each one has 
> its own management tool. Jmxsh and Jmanage fall short, and are not 
> fast and easy to use. This tool, I think became a bit convoluted in 
> the community process, with people checking in whatever they felt 
> should go into it. I still believe this tool fits a crucial need, as 
> was agreed upon when I presented this utility to LAJUG. Lack of talent 
> certainly isn't the problem here. I think that someone just has to 
> take the lead and get brave about rejecting commits and leading the 
> direction. I'm fine with that, as long as someone is willing to do the 
> development work. I'm also ok with retiring the project, if that's 
> what the community wants and votes on, but I think that there will 
> still be a void in the Java app world that will go unfulfilled which 
> this utility was supposed to serve.
> With that perspective expressed, what are the communities sentiments?
> Sincerely,
> msacks
> -----Original Message-----
> From: "Alessandro Novarini" <>
> Sent: Thursday, January 12, 2012 5:05am
> To:
> Subject: Re: Incubator PMC/Board report for Jan 2012 ([ppmc])
> Hi all,
> As I stated, I spoke basically for myself and the report may not
> reflect the general feeling of the current team.
> I wasn't blaming anyone, that has to be clear, because otherwise I'll
> be the first one to be blamed for having been away for such a long
> time.
> I completely understand everybody has its own
> life/job/interest/whatever, my regret is that we still haven't reached
> a critical mass for keeping the project going even if some of the
> developer stop working on the project.
> Unfortunately, I don't have a solution for that; as you said, some
> projects are interesting enough to attract more people, some other
> projects are not.
> This has nothing to do with the technical aspect of the project nor
> with the quality of the code; when I remarked that it was for pointing
> out that when Matthew started the project he was - i guess - the only
> one with a clear idea of how the project would progress.
> Now I think the only one left is Pid, but for my understanding he's
> quite busy at the moment, I really do hope he will have some time in
> the nearly future to hop on again, I enjoyed the time we all worked
> together.
> About the meritocracy thing: yes, I agree again with you here
> everybody as a team could be the PO, what I think is that some of the
> 'power' you get from acquired merit won't last a lifetime, but it
> could also be lost. To me that's something everybody should aim to
> keep what he gained, and there is no shame in changing their mind
> during the whole process. That's why I raised the point about how many
> people are still interested in Kitty.
> I honestly have no idea what the features for a project like Kitty
> should be added or improved, so I'm sorry, but I'm simply not fitted
> for that role.
> I would really read from other people their thoughts about the
> project, I hope everybody will find some spare time to join the
> discussion.
> Thanks and have a good day
> Ale
> On 12 January 2012 02:19, Kevan Miller <> wrote:
> >
> >
> > On Jan 11, 2012, at 6:19 PM, Alessandro Novarini wrote:
> >
> > > Hi all,
> > >
> > > I've just finished writing the report on the wiki page.
> > > Sorry if I might seem rude or not polite, I only tried to base the 
> report on facts relevant to me, as we didn't discuss together about 
> the actual status of the project.
> > > I trust if anybody had something to complain, he could freely 
> update the report with the due corrections.
> >
> > Hi Ale,
> > Thanks for the report. I don't have many quibbles with what you've 
> written.
> >
> > I do have a few general comments:
> >
> > Communities ebb and flow. Sometimes communities go through slow 
> periods. This is not necessarily a problem.
> >
> > Sometimes Incubating projects retire. Not all projects work out. Not 
> all projects attract a critical mass for an effective community. This 
> is not a failure -- and in no way necessarily reflects on the 
> technical aspects of the code. Nor does it reflect on the people who 
> contribute to the community.
> >
> > That said, if people care about the project. They can keep it going, 
> contribute, and eventually graduate from Incubator. I have no doubt 
> that can easily happen for Kitty… People make successful projects and 
> communities. They don't just happen...
> >
> > And a specific comment:
> >
> > Re: "The lack of a "Product Owner"" -- the "community" is the 
> "product owner". Anyone (or group of people) can assume this role. 
> Apache is a meritocracy. If someone has ideas on where the project 
> should go, wants to define/prioritize tasks, and provide the community 
> with what features need to be implemented -- they can do so. Anyone 
> can do this -- current committers or someone completely new to the 
> project can initiate this. So, if someone is interested in the 
> project, don't just wait for someone to tell you what to do -- *do*. 
> Or, better yet, do *and* tell other people what to do… ;-)
> >
> > --kevan
> >
> >
In response to this email, I think if we can tackle KITTY-5 and KITTY-6 
issues in JIRA we've met the goal of functionality of the original 
mission of KITTY.

Then, if we do a bit of bug squashing and documentation we should be set 
for a release candidate.

Once we have a release candidate, the goal will be to document the 
flexibility of using Kitty as a universal JMX client for various 
application types that support JMX.

Comments, disagreements, quibbles, accosts?



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message