Hi all,
In the light of Hen's great suggestions, I'd like to volunteer for the
"JIRA Juggler" role - unless there are objections/better suited
volunteers of course.
I can create a page on the WIKI already today and make a first
run-through of the open issues. Taking Hen's suggestions, shall we all
agree that 1.2 is what is being aimed for, with a 1.3 being the next one
version to be released? Or would it make sense time wise for the person
doing the releases (James I assume?), to split it up further, say in a
1.2.1 etc?
Cheers,
Johan
Henri Yandell wrote:
Find a JIRA juggler and you'll be able to :)
It's definitely a process that has worked well for Commons; and I did
the same thing over in Opensymphony for Quartz, where I was not a
committer and had to do the wiki page etc (subsequently becoming a
committer).
Hen
On Thu, May 15, 2008 at 2:11 PM, James Carman
<[EMAIL PROTECTED]> wrote:
I would love to be able to send in the next board report with the text:
"It's Alive! It's Alive!"
Don't think I wont! :)
On Thu, May 15, 2008 at 4:16 PM, Knut Wannheden
<[EMAIL PROTECTED]> wrote:
Hi all
Thanks for your input, Hen!
It's truly been a while since I last contributed anything to the
HiveMind project. But it actually looks like I might get back to work
on Java projects in about a month's time (nice change after 2 years of
PL/SQL...) and I am still very much into HiveMind! And I think it's
great seeing people here in Switzerland interested in HiveMind.
I think trying to finally get a 1.2 release out the door would be a
very good step towards breathing some life back into the project.
Cheers
--knut
On Thu, May 15, 2008 at 9:34 PM, Henri Yandell <[EMAIL PROTECTED]> wrote:
Thought I'd hop in with some thoughts - I'm not a Hivemind user, but
have been on the list for a while and have some ASF experience.
On Thu, May 15, 2008 at 5:05 AM, James Carman
<[EMAIL PROTECTED]> wrote:
I don't believe we can just let folks in as committers without seeing
a pattern of quality patches/contributions (unless perhaps they're a
contributor to another ASF project).
Agreed - in your current situation, be very open to anyone who happens
to be a committer at the ASF, but you still have to see non-committers
people showing commitment before granting karma.
I can take care of cutting the releases. I've learned more about
doing releases since working on Commons Proxy, so it shouldn't take me
as long to get them out the door. I would need to look at our build
and make sure it's up to date with Maven2 (it's easier to do releases
for me that way).
Yep. Step 1 is that someone needs to be prepared to step up and release manage.
This really means doing the actual release when the time comes AND
applying patches from the issue tracker. It doesn't mean the project
management aspects.
So:
#1 James volunteering as the man with the karma.
Next up you need someone who can step up and organize things. This
means trawling through the issue tracker,
http://issues.apache.org/jira/browse/HIVEMIND. If I was looking at
doing that, here would be my first steps:
Look at the JIRA. Some things jump out.
#1 there is an open issue on the released 4.1.2 version - that needs
fixing. Investigate and send an email on how to fix.
#2 there are 4 issues under 1.2 [wtf... 4.1.2 and 1.2?]. Work out the
version structure for Hivemind. Is 1.2 the next release?
#3 Assuming 1.2 is the next one, send an email asking for a 1.3 or
LATER-THAN-1.2 version.
#3.1 I'd be concerned about the 2.0-alpha-1 issue. Weird.
#4 Look through the 74 tickets without version, and put together a
wiki page if not a committer, or make the changes to jira themselves
if a committer, as to which issue should go in 1.2 and which should go
in LATER-THAN-1.2. Generally you'll want improvements with patches to
be in 1.2, and all bugs; and improvements without patches go in
LATER-THAN-1.2.
#5 for the 1.2 patches, recommend the ones that should be applied and
report that to the list. Ideally this should be something that
everyone is doing.
So... that's the role that someone needs to volunteer to do. Sorting
out the 74 issues - generally you should not have any issues in JIRA
that do not have a version (or a component, so I would also look at
the 9 component-less issues). If someone has the time to sit down and
start doing that; and keeps the mailing list hooked in, you'll be
surprised at how things start to move.
Don't worry about 2.0 etc. To go from 1.1->1.2 takes the above. To go
from 1.x to 2.0 takes a development community who have gone through
the above.
Hope that was worth reading :)
Hen
On Thu, May 15, 2008 at 8:01 AM, Achim Hügen <[EMAIL PROTECTED]> wrote:
I must confess, that I'm using spring today in all new projects.
It's difficult to resists the power of the spring movement.
It has excellent documentation, a very active community and broad tool
support.
The differences to HiveMind are subtle and not suited for convincing
project stakeholders to use it instead of Spring, I fear.
Nevertheless if somebody volunteers to keep HiveMind alive I would
appreciate it.
We could give you commit rights as soon as possible and at least some
support if questions
on releasing or architecture arise.
If you want to get a committer, just be immodest and start a vote, proposing
yourself as committer.
Achim
[EMAIL PROTECTED] schrieb:
OK, let's summarize :-)
There *is* some interest in Hivemind left, at least there were 4 or 5
people giving answers to the board report.
>From my point of view we need somebody to take the lead :-) In most posts
(this was true for the last board report in February, too) there is a
"maybe", "we should" and so on, but no one who actually decides something
and put it on the road ...
As I mentioned now for two or three times I know not much about the
structures of an open source project inside Apache, so I can be terribly
wrong, but: It seems like there should be a group of people that is
responsible for each project. In case of Hivemind there are not much people
left from that group, even not enough to put some other peoples in charge.
For example, there is no one who says: OK, Johan, go on, apply the patches
and prepare a release!
All what is said is a bit vague without concrete plan ...
For me, (based on my observations in this mailing list, don't want to
offend someone) there are only two (perhaps three) persons at the moment,
who could fill that gap:
James, Johan (and perhaps Achim, but he seems to be very busy, too).
Whoever takes the lead should make a concrete, but perhaps very small plan
for the very near future and ask the people who showed interest to follow
this plan and assign tasks to them. Then we can see if the interest is
really big enough to start some bigger efforts and if it is really worth to
start a discussion about the future of HiveMind ...
To come to that discussion:
If the Hivemind-vs-Spring - Philosophy article from Howard is still true
now, 4 years later, there *is* some difference in the philosophy of both
packages. And, if this differences still exists, this implies that you do
things in a slightly different way - even if it is possible to achieve the
almost same result in Spring. Without knowing Spring much it sounds like you
end up with a different application design ... A different application
design would be a good reason to choose one or another package, so this
alone would justify the existence of HiveMind as a standalone project. Or is
this difference to small? What are the things we can do with Hivemind we
can't do with Spring?
Cheers,
Jochen
-----Ursprüngliche Nachricht-----
Von: Johan Lindquist [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 14.
Mai 2008 11:12
An: dev@hivemind.apache.org
Betreff: Re: AW: HiveMind for Applications
As a start, maybe we should call for all interested parties to have a
look at issues (focusing on bugs primarily) and use the JIRA voting
system. This would give us a good hint as to what is immediately
wanted/needed. I can in parallel take a look to try to summarize
outstanding issues as well ...
It would also be nice perhaps to add a couple of new versions to JIRA
(1.2, 1.2.1 or even 1.3) and re-assign pending maintenance and
enhancements for 1.X - giving us small roadmap to work against.
Emphasis on 'maintenance updates' at the moment, to see where the wind
takes it ...
Jochen, a couple of Howards posts relating to Spring/Hivemind
differences below - somewhat outdated, but a start ...
http://tapestryjava.blogspot.com/2004/02/comparing-hivemind-to-spring.html
http://tapestryjava.blogspot.com/2004/06/hivemind-vs-spring-philosophy.html
Cheers,
Johan
[EMAIL PROTECTED] wrote:
| Yesterday evening I scanned all the JIRA Issues.
| I found quite a few bugs where patches already exists. As I see it
there are 78 issues, but only 13 bugs without a patch. All other issues
do have patches or are improvements, wishes or new feature requests (and
there are also some with patches already included).
|>From that 13 open bugs are some with comments that suggests that these
"bugs" could be solved with a different approach or aren't bugs at all,
some are for Hivemind 2.0 only, so I believe there are less than 10 real
bugs left for Hivemind 1.1.1 ...
|
| Perhaps someone (Johan? :-) should scan the issues (and patches) and
mark the ones (including feature requests) we need solved (or
refactored) for a 1.2 release. I made an Excel sheet where I marked the
issues that have patches supplied and the ones that are open, but I can
only send this in the evening, because I'm at work now :-)
|
| To start a discussion for "give Hivemind a new reason of existence":
| Could someone emphasise differences to Spring that exists at the moment?
| There must be some differences, I think Howard did something like this
in the past already, but I was not able to find the web page again where
I read this ... this could be a good start for a discussion ... what do
you think??
|
| Cheers,
| Jochen
|
| -----Ursprüngliche Nachricht-----
| Von: Johan Lindquist [mailto:[EMAIL PROTECTED]
| Gesendet: Mittwoch, 14. Mai 2008 08:44
| An: dev@hivemind.apache.org
| Betreff: Re: HiveMind for Applications
|
| Agree, but we should not forget the few faithfuls out there ;) And
| there has been interest out there for a 1.2 from quite a few ...
|
| Would an option be to trickle out a 1.2 release while putting more
| effort into re-defining Hivemind's reasons for not dying?
|
| Cheers,
|
| Johan
|
| Raffael Herzog wrote:
| | Am Dienstag, 13. Mai 2008 15.04:43 schrieb James Carman:
| |> On Tue, May 13, 2008 at 7:57 AM, <[EMAIL PROTECTED]>
wrote:
| |>> James - do you think that there is any chance that there will be
any
| |>> work on Hivemind in the future? Or is it really at its end?
| |> I really don't know at this point. Spring is very pervasive and even
| |> Howard stopped using HiveMind on Tapestry (our biggest source of
| |> customers by far) in version 5. I actually use Spring myself now.
| |
| | I think, this is exactly HiveMind's problem: In that moment, when
| Tapestry
| | stopped using HiveMind, HiveMind basically lost it's reason of
existence.
| | There are now two options:
| | a) we let it die
| | b) we give it a new reason of existence
| |
| | This might also include throwing away some existing efforts for 1.2 or
| 2.0,
| | no replacement planned. *might*, not *must*!
| |
| | I think, if we want to get HiveMind back to life, we should be open to
| take
| | some drastic measures.
| | Cheers,
| | Raffi
| |
|
--
you too?
