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 brian.leroux@gmail.com
 designates 74.125.82.176 as permitted sender)
MIME-Version: 1.0
Sender: brian.leroux@gmail.com
In-Reply-To: 
 <CAKP6k2uJzNwPA-XSciBhitm78Xg5UdWF5p_pnwGkS_WADWQ3NQ@mail.gmail.com>
References: 
 <CAOBL_k6sYkt35zh_wSqPS8JWAEamYDuv_pv89PkNd9hKhtsPRA@mail.gmail.com>
	<CAEeF2TceF0ErQKr13BBGbXqg7d576Qh8eNgCRuOd3j6yFrCeFw@mail.gmail.com>
	<CAOBL_k63MCgj6Uuj++FmwdL3a=hYEhzbPf7EB98g8vmpTXvqtA@mail.gmail.com>
	<CAKP6k2uJzNwPA-XSciBhitm78Xg5UdWF5p_pnwGkS_WADWQ3NQ@mail.gmail.com>
Date: Wed, 18 Sep 2013 11:31:53 +0200
Message-ID: 
 <CADVgkyP+R960EZtg191LhWBtC0VJy=JbgDqAoKfL6BvMS15Cdg@mail.gmail.com>
Subject: Re: Major Issues
From: Brian LeRoux <b@brian.io>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>,
 Brian LeRoux <brianl@adobe.com>
Cc: bowserj@apache.org
Content-Type: multipart/alternative; boundary=089e0102e6da9c3d7d04e6a51b15

--089e0102e6da9c3d7d04e6a51b15
Content-Type: text/plain; charset=ISO-8859-1

Two points to re-iterate.

1. We have a release tool of beta quality is probably isn't quite ready for
prime time. That's ok. We're all on the same page of automation to reduce
complexity and likely human error. Lets fix it.

2. Essay's in email or docs are a bit of a pain to read and sometimes have
the vibe of a big up front design hence the lazy consensus being won on
things that probably more important than that. A pull request with lots of
tests and clear docs seems like a better idea for working
openly/collaboratively.

One point to add. I'm of the opinion we need a F2F hackathon to work
through some of this stuff. None of it actually that bad.

Post PhoneGap Day EU I'll get to work on making that happen October-ish.


On Tue, Sep 17, 2013 at 10:03 PM, Jesse <purplecabbage@gmail.com> wrote:

> Essay proposals have got to stop.  In the past it seems it became an easy
> way to get lazy-consensus, because the reader was too bored to disagree.
> The same is true of some thread discussions we have, on numerous cases we
> have lengthy feature conversations ( with conversation forks as well ) to
> the point that it is hard to stay interested, because the point gets
> muddied.  Most email threads longer than 8 devolve into tl;dr which may
> then be seen as lazy consensus.
>
> We do need to embrace simplicity, imho things have become more complex than
> they need to be, this has lead to the need for tools, just to manage the
> increased complexity. I see many opportunities to simplify things, which I
> will explore some more before starting a new thread.
>
> While we do have better docs, and more tests of our apis, I do agree with
> part of Joe's quality ( or at least perceived quality ) assessment.  This
> is mostly from a tooling standpoint, and not the actual runtime code.
>  Watching a developer wade through our process would reveal a lot.  Short
> of that, spend some time helping people on the 'real' mailing list [1] to
> gain some insight into the problems we should focus on.
>
> re: coho, I can see why it might be useful, but I have never needed/trusted
> it.  I definitely see it's use in tagging all the plugin repos, but I don't
> think the plugins should be tagged based on the passage of time, which is
> another discussion.
>
>
> [1] https://groups.google.com/forum/#!forum/phonegap
>
>
>
>
>
> @purplecabbage
> risingj.com
>
>
> On Tue, Sep 17, 2013 at 12: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.
> >
> > >>  - 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.
> >
> > > 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
> >
>

--089e0102e6da9c3d7d04e6a51b15--