Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of fil@adobe.com designates
 64.18.1.25 as permitted sender)
From: Filip Maj <fil@adobe.com>
To: "callback-dev@incubator.apache.org" <callback-dev@incubator.apache.org>
Date: Thu, 20 Sep 2012 11:53:07 -0700
Subject: Re: Lower-overhead release process
Thread-Topic: Lower-overhead release process
Thread-Index: Ac2XYSsOmCP+sSfrTQi+RSRVhDdgjw==
Message-ID: <CC80B1A4.E2F5%fil@adobe.com>
In-Reply-To: 
 <CAOFYJNZAJ34Q-BU_XtmF_y9uP+usXtfRJbdFs6Gbj8Wep0HWiQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.2.3.120616
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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, Jukka.

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.

Thoughts?

On 9/20/12 11:32 AM, "Jukka Zitting" <jukka.zitting@gmail.com> wrote:

>Hi,
>
>On Thu, Sep 20, 2012 at 6:45 PM, Joe Bowser <bowserj@gmail.com> 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
>needs.
>
>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.
>
>[1] http://www.apache.org/dev/release.html#what
>
>BR,
>
>Jukka Zitting