Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of agrieve@google.com designates
 209.85.192.170 as permitted sender)
MIME-Version: 1.0
Sender: agrieve@google.com
In-Reply-To: 
 <CAOBL_k63MCgj6Uuj++FmwdL3a=hYEhzbPf7EB98g8vmpTXvqtA@mail.gmail.com>
References: 
 <CAOBL_k6sYkt35zh_wSqPS8JWAEamYDuv_pv89PkNd9hKhtsPRA@mail.gmail.com>
 <CAEeF2TceF0ErQKr13BBGbXqg7d576Qh8eNgCRuOd3j6yFrCeFw@mail.gmail.com>
 <CAOBL_k63MCgj6Uuj++FmwdL3a=hYEhzbPf7EB98g8vmpTXvqtA@mail.gmail.com>
From: Andrew Grieve <agrieve@chromium.org>
Date: Tue, 17 Sep 2013 15:58:23 -0400
Message-ID: 
 <CABiQX1X6vjiNwzsr+MuqTr5=64QepDm1KG3hvY2KMnTroWHi2A@mail.gmail.com>
Subject: Re: Major Issues
To: dev <dev@cordova.apache.org>, bowserj@apache.org
Content-Type: multipart/alternative; boundary=047d7b10cb3d77a6dc04e699bf46

--047d7b10cb3d77a6dc04e699bf46
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Sep 17, 2013 at 3:21 PM, Joe Bowser <bowserj@gmail.com> wrote:

> My responses are also inline:
>
> On Tue, Sep 17, 2013 at 11:26 AM, Michal Mocny <mmocny@chromium.org>
> wrote:
> > On Tue, Sep 17, 2013 at 9:16 AM, Joe Bowser <bowserj@gmail.com> wrote:
> >
> > Regarding unilateral decision making, I can't find examples of this.  I'm
> > looking back at all the essay sized proposals and see quite a bit of open
> > dialog and push back from various contributors, as well as significant
> > adjustment made to accompany everyone's needs.  Perhaps the complaint is
> > with quantity and rate of proposals recently, and a general sense of
> > overwhelmingness?  Not sure how to solve that problem.  I hope this will
> > resolve itself naturally as soon as we settle after 3.0.
> >
>
>  Using COHO for our release process.
>
I don't think this fits into the essay-sized proposal bucket. Certainly has
been a contentious issue though.

>
> >>  - Simple scripts that JUST DO ONE THING - I hate coho.  I don't like
> >> how it was injected in our process practically against the will of
> >> many of the developers
> >>
> >
> > It isn't necessary for you or anyone to use coho.  Andrew is writing it
> to
> > make it easier to do the tedious manual steps of a proper release.  If
> you
> > prefer to do it manually, you can, but you risk making mistakes (which, I
> > hear, you yourself have done consistently with each of the last
> releases).
>
> You didn't need to add the last part.
>
> >  I'm not saying that to point a finger, but to point out that its just
> too
> > easy to make mistakes without a tool, and I think Andrew has done us all
> a
> > huge service to document and automate the release flow.  We've seen many
> > contributors using coho with great fanfare so your opinion on coho, even
> if
> > not entirely unique, is certainly not universal.
>
> Honestly, everyone has made mistakes.  In fact, coho has modified the
> VERSION number on cordova-js on the 3.1.x branch to say 3.2.x-dev.
> The fact is that there's numerous people here who don't use it because
> it either doesn't work on their platform.  It's not ready to take the
> place of just running git and going through the process manually.
>
I've had to tweak coho for each release, so I in no way think it's perfect,
but I don't see that it's done this.
It also never pushes anything be default, and has a command for running git
log / git diff so that you can vet the commits it does before pushing them.


>
> > Really, if you hate coho so, just don't use it.  If you hate the release
> > process so, lets try to improve it.  I'm not sure where yelling about the
> > things we don't like gets us.
> >
> > I really would, however, advise that you do just attempt to learn the
> tool.
> >  It has changed rapidly recently which has meant effort to keep on top of
> > (sorry), but that will not be the case forever.
>
> I will never use coho for releases. I don't like how that tool was
> sprung on us at the last minute when getting 3.0 out.  Also, if
> someone else is going to do the release, they should do the testing as
> well.
>
> >> Honestly, this shouldn't be about who can beat the other person down
> >> with the longest e-mails, it should be about actually working on this
> >> project and allowing people to make apps that don't suck.  If things
> >> don't change, I expect that quality is going to keep taking a
> >> nosedive, and that a year from now it'll be impossible for anyone to
> >> do anything with Cordova.
> >>
> >
> > That last prediction sounds stretched.
> >
>
> How many people are still using 2.9 instead of 3.0? Probably most
> people, because we're promoting the CLI instead of giving people the
> choice, even though the CLI has a ton of issues. I never use the CLI
> when working on Cordova, and I wouldn't if I was using an app, because
> it has a ton of issues and gets in the way of the core platforms,
> which I may want to modify. It also confines cordova to a single use
> case, and it means that I can't make a truly hybrid application
> without a lot of effort.
>
> Honestly, I think we should be putting more time into making Cordova a
> viable choice for building an application, and not just more scripting
> and plugins.  Sure, this may make development of the app easier, but
> the app at the end of the day could still look like garbage if certain
> things don't work right (like InAppBrowser, which honestly should be a
> last resort, since it only makes sense on iOS).  We should focus on
> tighter integration with the host platform so that you can't tell
> whether an app is native or a web application.  That's something that
> I think is still lacking.  Of course, this is my personal opinion.
>
>
> Joe
>

Sounds like there are two things you don't like:
1 - Using coho
2 - CLI

For coho - I think more than just myself has found the tool useful, but
it's purpose is not to be "the tool we use for releases", but rather, to
help automate mundane tasks that we have to do over-and-over. I had hoped
that it would also serve as documentation (since you can see what commands
are required to accomplish things, either by looking at the code or by
reading the output). I'd love it if you could figure out why it's not
working for you, but I don't think it has to be the only way things are
done.

For CLI - Not everyone has switched to it, and there are certainly still
many rough edges, but we've gotten a lot of positive feedback about it and
it is still improving a lot. Improving our platforms is still very
important, I think we have enough people on the project to accomplish both.
Have a look at the RELEASENOTES.md I added for cordova-android - there's
been a good amount of progress made.

--047d7b10cb3d77a6dc04e699bf46--