incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <>
Subject Re: Lower-overhead release process
Date Thu, 20 Sep 2012 18:57:53 GMT
Talking with Anis, CI would solve this problem..

On 9/20/12 11:53 AM, "Filip Maj" <> wrote:

>I agree with Joe in that the specific, automated steps to create a
>sub-project's release won't help in streamlining the release process for
>this project. Appreciate your efforts to help in this regard though,
>The underlying issue is that this project has a lot of shared resources.
>The javascript, example "hello world" app and the test suite are
>standalone projects but are used by all platform implementations. The crux
>of the slow release process is this: the shared projects need to be tagged
>before the platform implementations can be. If we find a problem in the
>shared projects, then all platforms need a retagging.
>If the above problem can be solved, then the release flow will improve.
>Perhaps this is more a matter of diligence and testing than a problem with
>the release steps themselves. If we are better at catching issues with
>shared sub-projects on all platforms, then the retag cycle (ideally) would
>be eliminated.
>Either way, there is ceremony and process involved. A lot of testing. Many
>devices. Lots of platforms. Communication and a bit of planning can help
>here. A week before a potential tag we could create an issue to track
>progress of testing JS+test suite+hello world sub-projects across all
>platforms. Only once all of those tasks are done can we with confidence
>say that the shared projects are stable and we can copy them into the
>platform implementations that we ship and tag those.
>On 9/20/12 11:32 AM, "Jukka Zitting" <> wrote:
>>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