Major Issues

[Joe Bowser <bo...@gmail.com>]

It's been a while, but I think it's time to spell things out.

I feel that it's next to impossible to contribute to this project in
any real meaningful way, and that this project has gone off the
tracks.  This is due to certain people posting huge essays that change
the architecture of the project, and how we do things, and then doing
it without any buy-in. We've gone along with this sort of unilateral
decision making for months, and all we've seen is reduced quality, and
developers getting frustrated because it's next to impossible to
figure out how to do things like tag a release.

We need to make things more simple for anyone to contribute, not more
difficult.  I think that we really need to change our release process
so that we use Git, and not some broken, half-baked tool that only one
person can seem to use.  We don't need to re-invent the wheel every
time we find a tool that we didn't invent, we really just need to
learn to use this tool.

The fact is that if I wasn't paid by Adobe to work on this project, I
would have just given up because this process is far too frustrating.
Given that I've been contributing the longest to this project, that's
saying something.

What I would like to see is the following:
 - Short e-mails detailing what people want to do. If you write a huge
essay, nobody is going to read it.  That's why everything comes as a
surprise for many people.  If you can't describe your feature in one
or two short paragraphs, perhaps it shouldn't be a feature
 - 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
 - People actually listening.  I don't think this ever happens on this
list, and I'm really sick of how things are decided unilaterally

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.

I know that this is a really long e-mail, but I'm really annoyed at
how complex things have gotten over the past year.  We need to make
things simpler for everyone.

Joe

Re: Major Issues

[Andrew Grieve <ag...@chromium.org>]

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

> My responses are also inline:
>
> On Tue, Sep 17, 2013 at 11:26 AM, Michal Mocny <mm...@chromium.org>
> wrote:
> > On Tue, Sep 17, 2013 at 9:16 AM, Joe Bowser <bo...@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.

Re: Major Issues

[Brian LeRoux <b...@brian.io>]

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 <pu...@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 <bo...@gmail.com> wrote:
>
> > My responses are also inline:
> >
> > On Tue, Sep 17, 2013 at 11:26 AM, Michal Mocny <mm...@chromium.org>
> > wrote:
> > > On Tue, Sep 17, 2013 at 9:16 AM, Joe Bowser <bo...@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
> >
>

Re: Major Issues

[Jesse <pu...@gmail.com>]

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 <bo...@gmail.com> wrote:

> My responses are also inline:
>
> On Tue, Sep 17, 2013 at 11:26 AM, Michal Mocny <mm...@chromium.org>
> wrote:
> > On Tue, Sep 17, 2013 at 9:16 AM, Joe Bowser <bo...@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
>

Re: Major Issues

[Joe Bowser <bo...@gmail.com>]

My responses are also inline:

On Tue, Sep 17, 2013 at 11:26 AM, Michal Mocny <mm...@chromium.org> wrote:
> On Tue, Sep 17, 2013 at 9:16 AM, Joe Bowser <bo...@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

Re: Major Issues

[Michal Mocny <mm...@chromium.org>]

Joe,

Really sorry to hear that you feel that way, and its super great of you to
be airing concerns out in the open.  At least we have a chance to address
them that way.

However, I'm disagree with many of your points, so let me attempt to
dissect them a bit.  As I do, I find it impossible to write in a way that
doesn't at times sound aggressive.  I sincerely do not mean it to.


On Tue, Sep 17, 2013 at 9:16 AM, Joe Bowser <bo...@gmail.com> wrote:

> It's been a while, but I think it's time to spell things out.
>
> I feel that it's next to impossible to contribute to this project in
> any real meaningful way, and that this project has gone off the
> tracks.  This is due to certain people posting huge essays that change
> the architecture of the project, and how we do things, and then doing
> it without any buy-in. We've gone along with this sort of unilateral
> decision making for months, and all we've seen is reduced quality, and
> developers getting frustrated because it's next to impossible to
> figure out how to do things like tag a release.
>

There have been some large proposals recently, its true.  I personally
think that is just a temporary effect of 3.0 release while we settle into a
whole different workflow.

I do not agree that things are being done without any buy-in.  Sure, there
may commits that may have been hasty, or just plain mistakes, but I'll
point out that all of us, yourself included, could be said to have done so.
 It seems the nature of very openly allowing contributions that some will
need to be reverted.

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.


> We need to make things more simple for anyone to contribute, not more
> difficult.  I think that we really need to change our release process
> so that we use Git, and not some broken, half-baked tool that only one
> person can seem to use.  We don't need to re-invent the wheel every
> time we find a tool that we didn't invent, we really just need to
> learn to use this tool.
>

We are using git.  The process (all of it) is being documented, and
everyone has a say in what it should be.  If it seems over complicated,
lets make it simpler!  No one has presented a way to do so, but everyone
would be open to a proposal.  We've been discussing that a lot recently,
and it seems the current (finally well documented I'll add) process is the
easiest we could come up with the address all of the concerns each of the
community members have address.  We've had to make it more complicated at
times specifically to address everyone's needs (see your point above).
 Simplicity and wider team buy-in seem goals at odds on this one.


>
> The fact is that if I wasn't paid by Adobe to work on this project, I
> would have just given up because this process is far too frustrating.
> Given that I've been contributing the longest to this project, that's
> saying something.
>
> What I would like to see is the following:
>  - Short e-mails detailing what people want to do. If you write a huge
> essay, nobody is going to read it.  That's why everything comes as a
> surprise for many people.  If you can't describe your feature in one
> or two short paragraphs, perhaps it shouldn't be a feature
>

We've (Google) been trying to do this, but I will admit have not always
done well enough.  Its a good point.  Its an organizational difference,
maybe, and I'll make it my effort to make sure that at least this team
adjusts.


>  - 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).
 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.

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.


>  - People actually listening.  I don't think this ever happens on this
> list, and I'm really sick of how things are decided unilaterally


> 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.


>
> I know that this is a really long e-mail, but I'm really annoyed at
> how complex things have gotten over the past year.  We need to make
> things simpler for everyone.
>

Again, proposals welcome.


>
> Joe
>


I'm seeing one really valid point here (essay sized proposals), one wild
accusation (quality and nosedive of contributions), and one general
discomfort with release process (fine, but such is life, none of us finds
this part fascinating, but its important to get right).

-Michal