cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: 4.0.x, efcedabe, Patch-Bombing and good faith
Date Wed, 16 Jul 2014 19:11:04 GMT
Good call here. I should have made JIRAs for a bunch of these. I've now
done so retroactively.


On Tue, Jul 15, 2014 at 8:56 PM, Joe Bowser <bowserj@gmail.com> wrote:

> On Jul 15, 2014 5:43 PM, "Andrew Grieve" <agrieve@chromium.org> wrote:
> >
> > On Tue, Jul 15, 2014 at 7:51 PM, Joe Bowser <bowserj@gmail.com> 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:
> > https://github.com/apache/cordova-android/commits/4.0.x
> >
> > 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.
> >
>
> They don't. There aren't issues attached. These are often one line.  Why
> can't we use JIRA for this?
>
> > 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
> > configs
>
> Cool. Is there an issue in JIRA?
>

https://issues.apache.org/jira/browse/CB-7152
https://issues.apache.org/jira/browse/CB-7153


> > 2. Delete @Deprecated things so as to not need a 5.0.x to do so
>
> Cool, is this tracked anywhere else?
>
https://issues.apache.org/jira/browse/CB-7154



>
> > 3. Refactor copy & pasted code between xwalkview & androidwebview
>
> Again, is this in JIRA?
>
https://issues.apache.org/jira/browse/CB-7156


>
> > 4. Shrink the API surface of CordovaWebView (less surface == more
> > maintainable)
> >
>

> This isn't cool. This should have been discussed more.  What will this
> break?


https://issues.apache.org/jira/browse/CB-7155


>
> > 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.
> >
>
> On dev or private?  Should it be discussed here?
>

I think we've agreed that this isn't a security bug, but rather a security
enhancement.
It's already been public discussed and is filed as an issue here:
https://issues.apache.org/jira/browse/CB-5988


>
> >
> >
> >
> > > 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?
> >
>
> Because Community > Code, and your opinion about commit messages is
> subjective.  If you used JIRA, I could have caught up instead of a one-line
> commit.
>
> > 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
> > branch.
> >
>
> JIRA is where this should have been done.  I don't just create issues just
> for the sake of creating them.  If I got a JIRA issue "I might have broke
> things, go check", I would go check.
>
> > 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.
> >
>
> Why can't we use JIRA to track issues and changes like this?  I can read a
> changelog on gitweb just as easily as on my Gmail.
>
> >
> > >
> > > On Tue, Jul 15, 2014 at 1:43 PM, Shazron <shazron@gmail.com> 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 <
> agrieve@chromium.org>
> > > 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 . &&
> git
> > > >> commit --all -a"
> > > >>
> > > >> Also - what's broken? Just did a test compile with 4.0.x &
> > > >>
> > >
> https://github.com/clelland/cordova-crosswalk-engine#plugin_with_arm_binary
> > > >> and it worked fine.
> > > >>
> > > >>
> > > >> On Tue, Jul 15, 2014 at 2:42 PM, Joe Bowser <bowserj@gmail.com>
> 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
> > > >>>
> > >
>

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