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: [email protected] >>> Betreff: Re: AW: HiveMind for Applications >>> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> 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: [email protected] >>> | 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? >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.6 (GNU/Linux) >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >>> >>> iD8DBQFIKqzZpHYnED7evioRAjt/AJ9IXtMbFztUPE7ddNZfojYZOG2w/gCfUv2F >>> XwQlhX9kjoncfz0QLuuTD5E= >>> =SG3x >>> -----END PGP SIGNATURE----- >>> >>> >> >> >
