incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Endre Stølsvik <>
Subject Re: Release Requirements
Date Thu, 12 Oct 2006 20:27:38 GMT
Eelco Hillenius wrote:
> On 10/12/06, Endre Stølsvik <> 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 

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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message