incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martijn Dashorst" <>
Subject Re: Re: Release Requirements
Date Thu, 12 Oct 2006 20:55:46 GMT

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

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.


On 10/12/06, Endre Stølsvik <> wrote:
> 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
> 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:
> For additional commands, e-mail:

<a href="">Vote</a>
for <a href="">Wicket</a>
at the <a href="">Best Stuff in
the World!</a>

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

View raw message