Re: [DISCUSS] Community diversity (again)
Thilo Goetz wrote: It's just that to an outsider, it is totally unclear what that means. And it may be impossible to really convey the meaning of it in a few sentences. So why don't we just say so. Make it absolutely clear that the diversity of the community will be judged by the IPMC based on the overall conduct of the project, mailing list, commit activity etc. I know it's there already, but it could be reinforced. Perhaps at the end of the Creating an Open and Diverse community (community should be capitalized, btw) paragraph: The IPMC will judge diversity of the project based on many criteria. These include mailing list activity, commit activity and the affiliations of the committers. There is no single sufficient criterion, it is the overall conduct of the development community that counts. Or something like that. One obvious problem with such approaches is that the criteria will become very unevenly/unfairly applied. Some projects might just slip past with very little scrutiny, while others suddenly rack up a lot of discussion, where everybody has something to say and the project gets lots of (somewhat unwanted!) scrutiny. The amount of scrutiny and subjective evaluation will be affected by time of year, holidays and daily moods of the PMC members etc etc..! An idea would be to have a pretty clear set of rules, with X committers, where all must actively have participated in email and subversion activity, blah blah - SOMETHING that can be objectively evaluated and the project may strive towards - and then some final line about this will however be up to a final subjective evaluation where obvious attempts at circumventing/bypassing/minimal-efforting the system will (hopefully) be caught and stopped. Endre. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
Paul Querna wrote: Santiago Gala wrote: El dom, 17-02-2008 a las 19:02 -0500, Noel J. Bergman escribió: No. This is the wrong forum. What we've said here is that there won't be any deviation from the ASF infrastructure for source control; changing ASF infrastructure is out of scope for the Incubator. I already tried to move the discussion to [EMAIL PROTECTED], where I think it belongs, but people insists on answering here. Making requests to a closed team Infrastructure isn't a closed team by any means, and I am tired of people propagating that bullshit. Come help, and karma comes. in a private list does not accord with *our way of working*, I think. And I don't think there is any need to use a private, unarchived list for discussions on infrastructure improvements. infrastructure is open to all committers. infrastructure-dev is open to all committers. infrastructure-private is open to all members. Why should this discussion be moved into a Apache-private realm, and not just stay fully public, so that I can watch the proceedings? This is an interesting discussion. So far, Santiago has some pretty neat arguments going! :-) Endre. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
Justin Erenkrantz wrote: On Feb 18, 2008 10:48 AM, Santiago Gala [EMAIL PROTECTED] wrote: outright FUD? Sorry but I don't think there is Fear, Uncertainty or Doubt in this thread. There are several testimonies of good experiences I feel there has been lots of FUD and if you don't realize that, then I recommend taking a step back. Please define FUD for us, will you? Because I haven't seen one single iota of FUD on this thread - it has stayed strangely on topic, with good arguments from both sides, and not once has the discussion gone into SCM XYZ often ruins the code base by introducing strange bit errors-style half-lies which is what I associate with FUD. A/k/a The Microsoft Tactics in regards to Linux. Endre. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
Upayavira wrote: Justin put it very well in a related thread elsewhere (permission sought): [ CHOP interesting adamant view from Justin ] (Where is elsewhere, btw?) What I find strange in all this is the view that ALL projects at Apache would have to change to OtherSCM if one project would want that.. Indeed, I find the decision to use one single SVN repo for the entire organization's source pretty strange. I'd believe that one repo for every TLP, for example, would be great (AFAIK, TLP-promotion can be handled too with history preserved). This would help in every single aspect in regard to the volume of source and activity, could use multiple servers etc - and incidentally using another SCM for a particular project wouldn't be that big a deal anymore. The only downside I see is a slight bit more configuration management, and that copying/moving a file from one repo to another would not keep history that well. How often does this happen, though? However, I'm no SVN expert, so I can easily have misunderstood everything. Endre. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [***SPAM***] - [List1] U.M.A. II English International Open Judo Back to Back Ne
Upayavira wrote: On Thu, 2008-02-14 at 09:48 -0500, Ben Ramsey wrote: On 2/14/08 6:07 AM, Dynamis Gym wrote: I have completed the UNSUBSCRIBE REQUEST twice now, and you are still sending me these e-mails. Please REMOVE ME FROM YOUR LIST immediately, or I will report you for harvesting my e-mail from the internet and NOT allowing me to unsubscribe. As of right now, ITS AGAINST THE LAW TO CONTINUE SENDING ME MAIL! DITTO! I did not sign up for this mailing list, and I cannot unsubscribe via the mailman interface. Ben, I'm afraid I cannot work out exactly what list is sending you mail. This mail came to me through general@incubator.apache.org, but you are not subscribed to that list. I can only deduce that you are referring to the umauk.co.uk list that is CCd. If there is anything you want to see done relating to apache.org lists, please do contact me. However, as far as lists at apache.org, I do not currently believe any action is required. A common problem is when someone in your company (or similar) has subscribed the developers list (or similar) of that company onto the Apache list (or similar). But this should be possible to deduce from the headers. Endre. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] NoNameYet - Pluto
Leo Simons wrote: Sure, activity is not that high, and there's not a *huge* developer community, but there does not really seem to be any problem, either. Apache doesn't require projects to be huge successes (by whatever metric) as long as they're healthy and self-sustaining. This was not healthy up until quite recently - I'd even question whether the code and the community is _healthy_ now. And the main point was that IBM, the dumpsters, fled the plot pretty fast after the import was done, not bothering about creating The Healthy Community around the code they off-loaded before leaving. This should raise at least some slight concerns in Apache, IMO. However, much more importantly, proposals should be evaluated on their own merits, not based on what happened to some other unrelated project 4 years ago. How is that project unrelated?? It is a JSR-RI/TCK implementation that supposedly shall be done at Apache, one of the companies that come with the proposal and code is the very same company that did the Pluto stuff, and the code is delivered in the form of a finished product: a complete RI, and a complete TCK. Out of actual curiosity, what is their actual interest in having this at Apache, rather than using Sourceforge or Google Code if the single aim is getting this published in an open source fashion? (On a tangent, I really would expect a Reference Implementation and a Test Compatibility Kit to be quite bare bones, both pretty much merely defining the standard, and to NOT evolve much. Changes would only be fixes of actual deviations from the specification. That would be a rather different aim than what one would want of a fully fledged product) It is quite interesting to see the amount of action, questions and hassle many other projects are instantly getting when being proposed, for example the current project Thrift, compared to the meager attention this one has gotten. The spectacular amount of answers e.g. Paul's questions have elicited from the supposed proposers is also striking. But in the end, I believe this project will magically just happen anyway. Endre. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] NoNameYet : Link Error - please use this link
kelvin goodson wrote: I think what we were trying to say is that this work belongs in a project of it own ... The new project requires an environment where it can focus on the clear aim of implementing this JSR RI and TCK, or future versions, Is this really what Apache is for? without the distractions that would come with being part of a larger project; needing to address the community issues that having a wider remit would require. .. and again, The Community being exactly what Apache strives for?? Endre. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] NoNameYet - Pluto
Bill Stoddard wrote: Endre Stølsvik wrote: Leo Simons wrote: Sure, activity is not that high, and there's not a *huge* developer community, but there does not really seem to be any problem, either. Apache doesn't require projects to be huge successes (by whatever metric) as long as they're healthy and self-sustaining. This was not healthy up until quite recently - I'd even question whether the code and the community is _healthy_ now. And the main point was that IBM, the dumpsters, fled the plot pretty fast after the import was done, not bothering about creating The Healthy Community around the code they off-loaded before leaving. This should raise at least some slight concerns in Apache, IMO. Endre, Disclosure... I work for IBM. I agree with your concern about code dumping and I completely respect your comments. However, I object to the logic you are applying here. IBM'ers participate on projects as individuals and it's the actions of individuals that should be judged. To tar all IBM'ers because of bad behavior (perceived or real) of a few is just wrong. I don't group all IBM'ers, really - I actually believe IBM'ers do tons of good in many open source projects. Also I think IBM itself is a somewhat good open source citizen in several regards. But it is not individuals that propose this particular project, as I understand it: it is IBM and BEA. And it was IBM that, in my view, dumped the JSR 168 RI and then fled - not any individuals as such. I don't think Apache necessarily is the right place to dump a JSR RI and TCK implementation (because, lets face that, it isn't *developed* here) - it goes against the entire grain of Apache, AFAIU. At least, if it is put here, then just don't pretend that it more than that either: It's just the RI and TCK implementations, staying at Apache as Apache are good guardians of code on a general basis. Thus, if it happens, this particular project's name shouldn't be anything fancy, probably not include the name Apache, maybe just be JSR-235 with two subfolders: RI and TCK. On the other side, some server implementing JSR-235 could be called Apache What-Ever, would run its own incubation, have its own infrastructure, possibly use the RI as a code starting point - but nothing more. This would keep the distinction very clear. The goals seems too different to mix. Endre. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] NoNameYet - Pluto
Stefan Hepper wrote: It is not true that after the JSR was final everything stopped. In fact once we had finished 1.0 there was still work done to get to a more stable 1.0.1 release. After that the pluto community re-structed the code which led to the pluto 1.1 stream, so you can see that it was an active community not only some code drop. I mentioned this. JSR 168 itself was Final Release on 27 Oct, 2003. Wading through the repository: The first entry of Pluto in Subversion is Tue Sep 30 14:03:01 2003 (cvs2svn import). Pluto 1.0.1-RC1 was tagged Thu Oct 7 09:25:40 2004. Pluto 1.0.1-RC4 was tagged Mon Jul 25 01:06:54 2005. Pluto 1.0.1 was ReTagged Mon Oct 10 18:29:33 2005. 1.0.1, the first minor-revision above the inital code drop, being a fix of the most crazy bugs, was tagged more than two years after the inital code drop. Pluto 1.1.0 was tagged [maven-scm] copy for tag pluto-1.1.0 Sun Feb 11 17:29:23 2007. 1.1.0 was, IIRC, a larger refactor to make the code somewhat more embeddable. If the tags don't lie, the 1.1.0 came out less than a year ago, 3 years and 4 months after the initial drop. This time period isn't really extreme in itself, but compared to the developer activity on a project that literally screamed for help, it becomes sad. The following fact I'm not _quite_ certain of, and it takes a bit too much time to search the archives to prove it (this isn't exactly some court), but I do believe I have my words intact if I state that there wasn't much involvement in any of those versions after the initial dump to come from any of you IBM folks. Repos and mailing list archives are available. And for my comments of code quality - I might be wrong, I might be a nit-picker, or I might just be a bad coder - but the initial drop and all the versions are still there in the repository: have a look-see. There might be some tools better than ViewVC to run through the repository and mailing lists to get a better picture of these facts. But AFAIK, and I've been lurking lots (due to the fact that I had interests in a embeddable standards compliant container at the time), Pluto has *never* had much of an active community. I believe most of the 1.1.0 was done by one man. Had the initial code been of quite a bit better quality, or had it had quite a bit more backing from the droppers to bootstrap any community, it had at least had ONE more active developer, that I can guarantee. I tried, but I could just not start anywhere with that code, and I could not start doing a complete rewrite of that dump on my own (I'd actually rather start from scratch, to be honest). Also in my view pluto was a success, take a look at all the projects using the pluto container: http://portals.apache.org/pluto/powered.html. Compared to the amount of portals, this isn't exactly amazing. That IBM doesn't use it itself (I belive?), an Apache product which they themselves created, is quite telling, compared to the fact that IBM isn't exactly shy of using lots of other Apache products in their products and services. Endre. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSSION] BlueSky Proposal
Bill Stoddard wrote: Incubator PMC, http://wiki.apache.org/incubator/BlueSky This sounds like a really interesting project. I mean that in two ways: first, the project looks very worthwhile in itself, helping rural communities a couple of extra steps up the education ladder by way of high tech. Secondly, possibly even more important in the long term, having a Chinese initiated project at Apache would be a huge political win, setting precedents: Despite the vast amount of (talented) Chinese people, I feel that there are rather few widespread Chinese-initiated or -led open source software projects - at least I don't know of many (And if I'm making a fool of myself right there, then please give me a clue-by-four right now!). It would be a boon to the universe if this situation could be remedied as fast as possible. I actually have no doubt that this will happen sooner or later, but if Apache can make it happen sooner, possibly by helping just this project along the road to worldwide open source adoption, that would be a really great side-goal of this incubation. And yes - this would obviously have to happen in English. Acknowledging that Chinese is a HUGE language in terms of the number of people speaking it, it is still no world language in terms of the number of nationalities speaking it. This can present a problem for many Chinese, given that English education hasn't been, _as far as I understand_, a top priority in China until somewhat recently. Thus, to make this happen, there will probably have to be made some extra efforts on both sides. But this can, as mentioned, make a precedent - BlueSky will be an example of Chinese initiated, world wide developed and adopted, open source software - and I believe that the potential long term rewards, not only for this project, can be big. Endre, lurker. PS: Due to the scope of the project, localization to the native languages in the region of deployment, or the use of pictograms and similar, will of course be of huge importance. This focus is also shared with projects like Ubuntu and OLPC, as far as I understand - there might be interest in collaboration. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE WITHDRAWN] publish openjpa 0.9.6-incubating release
James Strachan wrote: On 11/21/06, Patrick Linskey [EMAIL PROTECTED] wrote: What do you do when it comes time to vote? Clearly, you can't be voting on the RC build, as that's not the final build (the final build doesn't include RC in the name, does it?), and it's my understanding that only final bits are voted on. Have a look at the recent number of RC's we've had to do to get our releases in shape... http://people.apache.org/~chirino/ basically we create a maven repo for each RC but the artifacts inside them are all 'the final build' with no RC in their name - then if the vote goes well, the RC is just moved to the right place. That way we don't have to do another build after the vote - but folks can still compare each RC etc. ($0.002 from me): I positively don't like this way. If I download this build, and unpack it and use it, I have _no idea_ at a later stager whether it was the proper release or a RC. There might even be several rounds of RCs, in which case the problem is even worse - and the final flaw for me using and potentially distributing the wrong version might be hefty. I think that a proper RC should be voted on, in which case all jars, MANIFESTs, tarballs, and toplevel unpack dirs should have a _clear_ RC in their name, and then if the vote goes through, a _direct rebuild_ of the release with the content of the preferably _sole file_ denoting the release's name changed from blah-RC to blah should be done and posted on the official places. IMHO, of course. Endre. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Requirements
If you tried to use the release and it is broken, you have a ground for -1 vote, but if you expected a Makefile in the src folder, and it wasn't there (e.g. because the build procedure is a little more involved than that), you probably don't. For what it's probably not worth, I'd like to point out that I did specifically NOT talk about the source distribution and pointedly NOT about the build system. I did however talk about the bin-distribution and what jars to include there (both a bin (class), and an IDE src), it having a root-directory when unpacking the tarball, where the javadoc should go (and e.g. having an index.html file in the docs dir, to map out all other docs), and the names of these artifacts (I'd _E.G_ personally prefer that the rootdir and the jars have the version included in the actual filename).. However, since I was repeatedly talking about 'jars' and 'javadocs', I just assumed that the readers of these emails would understand that I wrote about java specifics. I pretty much assumed that it was given that the bin-distribution of a C project would have a different layout, but in my opinion, that layout should also be enforced as much as possible. The underlying point is that for consumers of Apache projects, Apache with its multiple subprojects _could_ seem to have a consistent and quality _end-user_ packaging (that's not the source, folks) without surprises for the consumer part. It would be a huge plus for each and every person that have to download something from Apache, both if it is just some damn dependency from another project, but also if it is downloaded in its own right. Such enforcement would really not imply any strict rules about anything, except for how the end product should in most circumstances be packaged (given that it can be packaged in such a way (read: libraries) - e.g. Tomcat probably can't). Having people repeatedly bring up a Makefile in a java project is thus in two ways a strong indication about the person not actually reading the emails in the thread, or intentionally trying to derail the discussion: I referred to the bin distribution (they _shalln't_ have a bleedin' Makefile, nor a build.xml), and _java_. Endre. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Requirements
Yoav Shapira wrote: Hi, On 10/12/06, Noel J. Bergman [EMAIL PROTECTED] wrote: Can we agree that regardless of which style one might prefer the packaging, there are multiple valid approaches, and that this level of difference should not be a release criteria for the Incubator? Yes, agreed, +1. This is a technical decision to be made by the project team in the best interest of their users, not by the Incubator PMC. My two (probably rather worthless) cents: I find it slightly annoying that even different bin-balls within commons have different layouts when you unpack them. In particular when there are dependencies - you will actually have to check out each and every thing you download, and in some instances also download the src package, and some packages even don't have a root dir, thus unpacking directly in current dir (that is however more or less unified now, isn't it?) In particular libraries would benefit a lot if there was a common way that they were packaged. For example that the binary distribution had a packagename-ide.jar (or whatever you'd want to call them), having the source-files for easy integration into your ide, and maybe that the javadoc was at a predefined place. What about version-naming of the jars? Versioning of the root-dir? Check out CPAN - that's structure for you! Regards, Endre. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Requirements
Noel J. Bergman wrote: Endre Stølsvik wrote: My two (probably rather worthless) cents: Not at all worthless. What you posted is perfectly valid feedback, and should be considered by projects. But does it rise to the standard of needing to be enforced? In my opinion, yes. This is because if not, every project might insist that their packaging is better, or just not think about it, and thus not follow the defacto standard, if there is such a thing. Why are there such differences now, then? This is, if one would go for such an approach, a top-level decision that shouldn't be up to the projects to decide - you're apache compliant only if you follow this packaging. And it really isn't a big enforcement either, it's just that it should be crammed in from the get-go, so that the projects do think about it, and started out in line with the rest. Note that I do not in any way suggest that the entire layout of the system, nor the build system (!!) or similar should be enforced, just the end-packaging for the bins (which really is what (most) people download - they want the working stuff, the open source aspect is in this regard just a potential tailorability and important safety (and hopefully quality) sign). Regards, Endre. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache Agila : BPM engine
On Wed, 29 Sep 2004, Geir Magnusson Jr. wrote: | All, | | The Jakarta PMC has voted to accept in Jakarta the contribution of a | BPM engine from Gluecode, my employer, and I am starting the basic work | of getting it into [and out of] incubation. BPM.. Rite. DJ-lingo: Beats Per Minute Some journal: British Postgraduate Musicology BSD: BSD Ports Manipulator Here we got it, I guess: Business Process Management ? Sounds cool! What is it? Endre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
