Talking with Anis, CI would solve this problem.. On 9/20/12 11:53 AM, "Filip Maj" <[email protected]> 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, >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" <[email protected]> wrote: > >>Hi, >> >>On Thu, Sep 20, 2012 at 6:45 PM, Joe Bowser <[email protected]> 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 >
