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
