cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <>
Subject Re: Major Issues
Date Tue, 17 Sep 2013 18:26:33 GMT

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

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


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message