Well, thats not true, so lets not revise history. We did have a documented process emergent at CuttingReleases and since its been refactored by many of us. Same is true for coho.
The difference is the recent refactoring has come about without discussion or consensus. The concern here is what precisely we want to do with coho. Before it just downloaded tags and created a archive. Now it does... lots. We want to help and work on this. Nobody is going to debate the value of automation or documentation. Lets not pretend those things didn't exist before or that the recent changes are 'for the better' without discussion or consensus. On Fri, Jul 12, 2013 at 11:40 AM, Andrew Grieve <agri...@chromium.org> wrote: > I assure you that I did not use magic to create coho. I've found it to be > useful, but you certainly don't have to use it. All it does is run commands > in the end (which it prints out). If you find it to be unmaintainable, you > are free to refactor it. > > To the best of my knowledge, there was no documented release process before > I wrote http://wiki.apache.org/cordova/CuttingReleases. Now that it is > documented, feel free to propose changes to it. > > > > On Fri, Jul 12, 2013 at 12:49 PM, Brian LeRoux <b...@brian.io> wrote: > >> I agree we should clearly scope what coho is for as a group and get >> that solid before charging ahead and making it central to automations. >> >> (Nobody here is against automation but I think the issue Joe brings up >> is that we like small clearly defined tools and agreed upon ceremonies >> for releases.) >> >> >> On Wed, Jul 10, 2013 at 4:03 PM, Joe Bowser <bows...@gmail.com> wrote: >> > Putting this here because it doesn't belong in the tag 3.0.0rc1 thread: >> > >> > I agree with Jesse, who doesn't like the magic behind coho. My main >> > issue with coho is that it's not a very maintainable chunk of JS, and >> > it appears to be the kitchen sink of automation, full of things that >> > just don't fit elsewhere. It seems to do everything from create bugs, >> > tag releases and package them with a single command. The only thing >> > it's consistently failed to do over and over again is actually test >> > and produce a quality release of Cordova. >> > >> > I think that we should really keep our release process the same, and >> > that we should talk about what we want coho to do after 3.0.0 is out. >> > I don't think there's a lot magical behind coho, but I want to know >> > why I would use coho over something like repo, which is another tool >> > that handles multiple git repositories that is used in the Android >> > Open Source Project. >> > >> > Anyway, I'm pretty sure there's some concerns over the insertion of >> > coho into flows, and I'm wondering if anyone else has any thoughts >> > about this. >> > >> > Joe >>
