Endre, I think you are missing the community part of ASF. ASF is not a company, nor a big old business. It is a community with a variety of projects, and as such a variety of packaging demands and wishes.
I like the idea of a (pretty) low bar entry to Apache where the only criteria are the ones currently stated in the incubator graduation requirements. Adding release particulars to these requirements is in my opinion too restrictive and too cumbersome for any project. We can't go and enforce all projects to release their artifacts on ibiblio in the maven repository. This would be very strange indeed for httpd or xmlc. We can't enforce that all projects have to supply an ant file for their build infrastructure, again this doesn't make sense in a C, perl, or python project. We can't enforce one type of code/project documentation standard: enforcement of txt, doxia, forrest, docbook, latex, tex, odf, sxw, doc, rtf, etc. Any project may choose what kind of documentation it creates, in what format it is released and maintained. We could argue that the format should be an open format, this being an open source community, but again I think this is something the community of the project should decide as they are their primary users. The only requirements ASF should enforce on projects is that they comply with the basic principles of the ASF in a legal and community sense. Anything else should be handled by the community/project itself, including how to compose a release. Martijn On 10/12/06, Endre Stølsvik <[EMAIL PROTECTED]> wrote:
Eelco Hillenius wrote: > On 10/12/06, Endre Stølsvik <[EMAIL PROTECTED]> wrote: >> 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). > > Imo ASF has enough written and unwritten rules. Following discussions > on this forum since a few weeks feels like making the transition from > a small young company to a large old one, where procedures and > politics are more prevalent than a more practical 'can do' spirit. It's also often the difference between an dotcom upstart company that probably won't make it, and a tried and tested, experienced company that generates cash. Or whatever. > Sorry, no offense intended. I just think that 'enforcing' anything > other than the bare necessities is a bad idea. Whether it is the > binary packaging, whether to have discussions on IRC or distributing > incubator releases via a maven repo. (This is beside the point, but what's the point in coming to Apache in the first place?) Things such as putting your jar here, and naming it in this way, with versioning, and having the src-jar in the same dir, with the same name, and some bla bla bla.. These aren't very limiting rules that will tie you up in months agonizing to comply by. They are really just "know how" from the good old company that knows, after years and years of doing this stuff, what works and what doesn't. And downloading 5 tarballs that all unpack differently just doesn't work for a company as reputable as Apache! This is stretching the dot-com vs. good'ol company analogy a little far. But yes, I guess we do disagree: I get your analogy, and I still think it would be right to enforce these simple things! > Forcing rules rather then > encouraging best practices is counter is hard to achieve and only > irritating for those who still don't agree even if they gave it a > serious thought. Best practices could work too, if it was "this is REALLY the way to do it". Is there any such document? (If yes, then just make it a requirement, and you're there!) > A more positive approach - documenting, discussing > and automated support like maven does provide with it's standard > layout and distros - works much better imho. Automating is just the thing I want, e.g. when downloading a bunch of stupid dependencies that I don't care for at all, it's just that the damn thing doesn't work without them. But automation requires a little work upfront - that's the whole point. And the work here, is actually to put them deliverances in those right holes, so that an automatic process, or my idling brain, can do the thing without any further thoughts. Regards, Endre --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- <a href="http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote</a> for <a href="http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket</a> at the <a href="http://www.thebeststuffintheworld.com/";>Best Stuff in the World!</a> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
