incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <>
Subject Re: Lower-overhead release process
Date Thu, 20 Sep 2012 18:32:02 GMT

On Thu, Sep 20, 2012 at 6:45 PM, Joe Bowser <> wrote:
> I know, I'm just saying that this has the same effect as releasing the
> components independently.  I'm not convinced that this would reduce
> overhead when it comes to releases.

OK, fair enough.

> Also, how would this make us conform to the Apache requirements
> better?

Not strict requirements as such (the current release package is IMHO
fine from a policy perspective), but rather a more pragmatic point of
view that underlies the Apache policies.

The release guide [1] speaks of releases being "in the form of the
source materials needed to make changes to the software", which in
practice means that it's a good idea for the structure of the release
to be as close as possible to the structure of the source in the
version control system. The purpose of cutting a source release is not
to satisfy an abstract policy but rather to produce something that
downstream developers can easily use and modify to best match their

When looking at the current 2.1.0 release candidate my first
impression is that there's no build script and the only instructions
on how to build this thing is to "change directories to the platform
that you wish to build for and read the README file." And to get to
those platform sources I first need to unpack them to a separate
directory. I might be wrong, but it seems to me that most people would
rather simply start from a tag of a relevant platfrom repository
instead of building the release candidate. If that assumption is
correct, then I think it would be a good idea for the release
structure to better match the expected access patterns.

The main point I'm trying to address here is the grumbling I see about
the whole release process and its inefficiency. If the outcome of the
release process isn't something that's useful, then we're doing
something wrong and should fix that. If the process itself is too
complicated or otherwise takes too long, we should fix that too. I'd
love to hear also other ideas on how that could be done.



Jukka Zitting

View raw message