cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <>
Subject Re: 4.0.x, efcedabe, Patch-Bombing and good faith
Date Wed, 16 Jul 2014 00:42:56 GMT
On Tue, Jul 15, 2014 at 7:51 PM, Joe Bowser <> wrote:

> I finally managed to reproduce the setup that Andrew finally has.  The
> multiple repositories thing is super frustrating, and I am not
> convinced that these changes help the project, since none of them were
> communicated.  I still don't understand why these had to happen on the
> 4.0.x branch and not on a topic branch on GitHub.

The changelog on github is here:

I think the commit messages are pretty good and communicate what the
commits contain fairly well. Of course, mine is a very biased opinion here.

Here's the goals I've had with the changes I've made recently:
1. Make it possible to have multiple webviews in an app with separate
2. Delete @Deprecated things so as to not need a 5.0.x to do so
3. Refactor copy & pasted code between xwalkview & androidwebview
4. Shrink the API surface of CordovaWebView (less surface == more

I've also added the bridgeSecret thing (to master) for making the bridge
more secure. This I emailed about & would still like it if someone else
could audit it.

> Even though everything works now, I still think we have a major
> problem with patch bombing and a lack of communication.  The solution
> being proposed was "revert everything", and if I did do that today, I
> would have reverted code just because it was patchbombed in. Perhaps
> we should revert code that's patchbombed?  I honestly would like to be
> able to go out of 4G coverage without everything being rewritten "just
> because".  Can we agree to actually collaborate instead of trying to
> win the race for most commits, especially since we know that when
> Simon comes back, he's going to win it anyway.

> I'm not asking that everything be discussed before being committed,
> but if there are tons of commits (more than 20), it should be on its
> own branch before it gets pushed and discussed.

So long as commit messages are good, and changes are reasonable & don't
break things, then why extend the odds of merge conflicts?

Many changes required changes to the xwalk engine plugin as well, and I
think it would have been more work than its worth to have created multiple
dependent topic branches on multiple repos that would have a bunch of merge
conflicts to deal with, all to maintain the state of a pretty experimental

If you subscribe to changelog emails, you get an email for each one. I
actually do read these, and I'd encourage others to as well. If there was a
change I thought was reasonable, but you disagree, then let's discuss it. I
think you'll find that at least most of the changes are pretty reasonable.

> On Tue, Jul 15, 2014 at 1:43 PM, Shazron <> wrote:
> > More communication is always better -- I feel that might be the
> > missing piece here.
> >
> > Let's try to move on from this and discuss this in the call to solve
> > this situation:
> > 1. Identify what's broken and fix that, with verifying tests
> > 2. Revert for now so others can continue, while trying to fix what's
> > broken in the new patch (in a branch for merging later)
> > 3. Another option(?)
> >
> > I would err on the side of more communication over less (Apache
> > "Community over Code" etc). A massive patch integration without
> > discussion imo is not pro-community.
> >
> > I may have missed it (apologies if I did) but the series of patches
> > started July 3, 2014 and I did not see any discussion of it in dev@
> > prior to that.
> >
> > Shaz
> >
> > On Tue, Jul 15, 2014 at 12:42 PM, Andrew Grieve <>
> wrote:
> >> Let's discuss tonight, but it is actually pretty easy to revert things
> >> without --force. "git revert" can do it, or "git checkout HASH . &&
> >> commit --all -a"
> >>
> >> Also - what's broken? Just did a test compile with 4.0.x &
> >>
> >> and it worked fine.
> >>
> >>
> >> On Tue, Jul 15, 2014 at 2:42 PM, Joe Bowser <> wrote:
> >>
> >>> Due to the recent changes, I propose that we revert everything back to
> >>> a prior commit on this branch.  Given that we use the interfaces to
> >>> define the API for the ThirdParty WebViews used by Crosswalk and
> >>> others, the irony of reverting is should be clear.  The fact is that
> >>> we can't have people dumping hundreds of commits that totally destroy
> >>> months of work that we've done, including all the consensus-building
> >>> that was done.  This totally undermines the feeling that everyone is
> >>> contributing in good faith.
> >>>
> >>> Honestly, if I even remotely tried to do the same thing, I know that
> >>> many people on this project would have major objections to this, so I
> >>> don't know why people are being silent about this now.  We can't have
> >>> hundreds of commits just dumped into any branch of the ASF repos,
> >>> since we have no easy way to do a revert of this.  We have no --force,
> >>> and I'm probably going to have to fork and delete the 4.0.x branch.
> >>> I'm going to do this after the conference call, but I'm extremely
> >>> upset about the recent changes.
> >>>
> >>> We can't just say "shit will be broken anyway" and use it as an excuse
> >>> to break other people's work.  I honestly don't know what to say about
> >>> this at this point, since we've never had to do something like this
> >>> before.  I'm extremely frustrated at the fact that I've been ignored
> >>> every time I've raised concerns on this list and that some of us are
> >>> held to higher standards than others.
> >>>
> >>> I really hope we can talk about this on the call, because this is
> >>> beyond unacceptable.  I'm not sure what was supposed to be
> >>> accomplished, and why talking about features is some sort of unknown
> >>> barrier that we're trying to avoid.  At this point, there's no way we
> >>> could even remotely vote on a major release.
> >>>
> >>> How can we work past this so that we can actually work on this project
> >>> again?
> >>>
> >>> Joe
> >>>

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