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 <bows...@gmail.com> wrote: > On Jul 15, 2014 5:43 PM, "Andrew Grieve" <agri...@chromium.org> wrote: > > > > On Tue, Jul 15, 2014 at 7:51 PM, Joe Bowser <bows...@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 <shaz...@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 < > agri...@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 <bows...@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 > > > >>> > > > >
