Re: 4.0.x, efcedabe, Patch-Bombing and good faith
On Thu, Jul 17, 2014 at 8:10 PM, Marcel Kinard wrote: > > On Jul 16, 2014, at 3:11 PM, Andrew Grieve wrote: > >> Good call here. I should have made JIRAs for a bunch of these. I've now >> done so retroactively. > > Watching this, I very much agree that if Jira issues were created before the > commit and included in the commit message, that would have been a > communication improvement. The “before” benefit enables tracing a commit > message back to a more detailed context description in Jira. > > Another potential miscommunication here could be the intended scope of the > 4.0.x branch. The impression I get from Joe is that it was basically limited > to enabling third-party webviews. The impression I get from Andrew is that is > was more generally for breaking changes. If there is a mismatch in intention > of scope, I think that is where most of the gear-grinding may be coming from. The goal was to be where new features for 4.0.x wind up once we're done implementing them and generally agree upon them. When people said "Let's merge the pluggable_webview branch into 4.0.x and other 4.0.x stuff into that branch" I understood that to mean that this would be what 4.0.x would eventually look like. I didn't expect it to be somewhere that people could dump 50 commits into at once just because they wanted to try something and felt that they didn't have to create their own topic branch. That's what still irritates me. The big issue is that people believe they can make arbitrary changes without caring that it affects other people on both master and on 4.0.x, and I don't see this as being resolved. This project wasn't created yesterday, and it took the effort of a lot of people to get it this far, and to just dump these commits in without caring about those people is disrespectful. The number one reason my main gut reaction to any changes to this codebase is no is because I know that a lot of people depend on what we have as an API, and when we break it, they come to me to complain. If they don't talk to me, they'll go to Simon, Tommy or other visible committers, and not the people who actually break it. I know that merging in new features is a lot of work, and it's tempting to take the shortcut, but we really should actually at least try to make an effort to work together instead of just being glib and discounting what's being said. At this point, I'm not sure it's worth the effort because we've been down this road before numerous times. I don't think this will ever sink in.
Re: 4.0.x, efcedabe, Patch-Bombing and good faith
On Jul 16, 2014, at 3:11 PM, Andrew Grieve wrote: > Good call here. I should have made JIRAs for a bunch of these. I've now > done so retroactively. Watching this, I very much agree that if Jira issues were created before the commit and included in the commit message, that would have been a communication improvement. The “before” benefit enables tracing a commit message back to a more detailed context description in Jira. Another potential miscommunication here could be the intended scope of the 4.0.x branch. The impression I get from Joe is that it was basically limited to enabling third-party webviews. The impression I get from Andrew is that is was more generally for breaking changes. If there is a mismatch in intention of scope, I think that is where most of the gear-grinding may be coming from. I believe that everyone is “trying to do the right thing”, just with a bit different goals.
Re: 4.0.x, efcedabe, Patch-Bombing and good faith
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 wrote: > On Jul 15, 2014 5:43 PM, "Andrew Grieve" wrote: > > > > 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: > > 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 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
Re: 4.0.x, efcedabe, Patch-Bombing and good faith
I'm new here but I agree with Joe that most/all commits should have a corresponding item in JIRA. The mailing list isn't enough, as it's really hard to track things down that way. With so many people contributing, I think it's a necessity to make sure it's logged in JIRA. Marc On Tue, Jul 15, 2014 at 8:56 PM, Joe Bowser wrote: > On Jul 15, 2014 5:43 PM, "Andrew Grieve" wrote: > > > > 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: > > 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? > > > 2. Delete @Deprecated things so as to not need a 5.0.x to do so > > Cool, is this tracked anywhere else? > > > 3. Refactor copy & pasted code between xwalkview & androidwebview > > Again, is this in JIRA? > > > 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? > > > 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? > > > > > > > > > > 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 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
Re: 4.0.x, efcedabe, Patch-Bombing and good faith
On Jul 15, 2014 5:43 PM, "Andrew Grieve" wrote: > > 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: > 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? > 2. Delete @Deprecated things so as to not need a 5.0.x to do so Cool, is this tracked anywhere else? > 3. Refactor copy & pasted code between xwalkview & androidwebview Again, is this in JIRA? > 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? > 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? > > > > > 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 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 . && 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
Re: 4.0.x, efcedabe, Patch-Bombing and good faith
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: 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. 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 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 maintainable) 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 branch. 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 . && 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 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
Re: 4.0.x, efcedabe, Patch-Bombing and good faith
On Jul 15, 2014 5:09 PM, "Andrew Grieve" wrote: > > We could revert, but I'd really like to know what's broken first? I've been > making sure mobilespec has been green all along, and ever since Joe pointed > the junit tests out to me, I've been making sure they compile and pass (at > least the ones that pass on master anyways) as well. For demoing > experimental code on personal branches, I don't think it's that bad to have > to checkout an old commit. Maybe even use submodules in your demo repo? > Nothing is broken now for my demo. The issue is a complete communication breakdown and me having to spend a whole day trying to figure out what happened and why. I still don't know why the changes were made, why they're better and what was gained. I care more about that than if anything is broken. > 4.0.x is definitely not a release branch. At least, that was not my > understanding. I also wouldn't say that we've had agreement on what the > final API should look like, but rather agreement that we have a starting > point. Perhaps this was a misunderstanding on my part. I would certainly > have emailed out more if these changes went to master, but I really think > 4.0.x is still in an experimental phase. If there's changes that I made > that you don't like, let's discuss them. If something is broken, let me > know what it is and I'll help you fix it. Is it > https://github.com/infil00p/MozillaView/? > That's got to be deleted and redone entirely due to the updates. It was broken on Mozilla's side, but now it's totally broken now you did your API change. > I do use a topic branch and then merge it in once I'm happy with the change > and make sure tests pass. Things are a bit hairy because xwalk and gecko > are in separate repos (and I didn't know about gecko). > Gecko isn't even close to ready. > Proposal - let's add a createmobilespec.js variant that installs all engine > plugins so that we can ensure they are not broken (or send PRs to fix them). > That should be done anyway. Can we at least give a heads up, like a single e-mail that this was happening? The fact that there was zero communication until after the fact is the problem. We can't keep doing this. > > > > On Tue, Jul 15, 2014 at 4: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 . && 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 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 > >
Re: 4.0.x, efcedabe, Patch-Bombing and good faith
We could revert, but I'd really like to know what's broken first? I've been making sure mobilespec has been green all along, and ever since Joe pointed the junit tests out to me, I've been making sure they compile and pass (at least the ones that pass on master anyways) as well. For demoing experimental code on personal branches, I don't think it's that bad to have to checkout an old commit. Maybe even use submodules in your demo repo? 4.0.x is definitely not a release branch. At least, that was not my understanding. I also wouldn't say that we've had agreement on what the final API should look like, but rather agreement that we have a starting point. Perhaps this was a misunderstanding on my part. I would certainly have emailed out more if these changes went to master, but I really think 4.0.x is still in an experimental phase. If there's changes that I made that you don't like, let's discuss them. If something is broken, let me know what it is and I'll help you fix it. Is it https://github.com/infil00p/MozillaView/? I do use a topic branch and then merge it in once I'm happy with the change and make sure tests pass. Things are a bit hairy because xwalk and gecko are in separate repos (and I didn't know about gecko). Proposal - let's add a createmobilespec.js variant that installs all engine plugins so that we can ensure they are not broken (or send PRs to fix them). On Tue, Jul 15, 2014 at 4: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 . && 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 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 > >> >
Re: 4.0.x, efcedabe, Patch-Bombing and good faith
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. 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. 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 . && 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 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 >>>
Re: 4.0.x, efcedabe, Patch-Bombing and good faith
On Tue, Jul 15, 2014 at 1:24 PM, Michal Mocny wrote: > May we keep these topics within existing email threads? Some of these > topics have been addressed elsewhere and the conversation is forking. > > RE: topic branches -- thats what 4.0.x is, no? What's the topic? 4.0.x is a broad topic. If we look at my workflow for pluggable_webview, it was as follows: 1. Personal topic thread: https://github.com/infil00p/cordova-android/tree/pluggable_webview 2. Sent an e-mail asking if it was cool to add to ASF repos 3. After working on that and other issues, create a separate 4.0.x for various topic branches to be added. 4. Sent e-mail asking about rebasing to 4.0.x, get rough consensus. This process started months ago, back when we first started working on pluggable webview. Once we actually merge things in a potential release branch, we should try to not break it unless we have a good reason to not break it. This shouldn't be broken on a single person's whim. > I guess as more people > start to actually consume it, we should start to care more about compat. > We didn't care about making breaking changes in the first weeks, and now > its the end of the world (okay I'm exaggerating here, just trying to > counterbalance the original tone ;) > The problem is that this isn't the only part of the project that gets patch bombed. There's also the fact that we managed to actually get a feature working and everyone mostly agreeing how it was supposed to work, which is a really hard thing. You can try and downplay this, but if we're constantly getting into revert wars, we can't do anything else. Time I could spend on prototyping things and on our JIRA issues, which are constantly increasing, is now time I'm spending reviewing 30+ commits trying to find what broke things, and writing e-mails about them. > Also, 4.0.x also doesn't exactly have a well defined set of things to test > against, so we should discuss that tonight. I think its hard to include > other peoples demos which you don't know exist in that set.. 4.0.x has one main feature, which is pluggable webviews. It has other things, like the UriHelper logic that was created to fix how intents are managed and deprecations, but we should at least make sure we don't break the one feature that we agreed upon. Right now there's classes that are missing that make this webview not work: https://github.com/clelland/cordova-crosswalk-engine/tree/plugin_with_arm_binary.
Re: 4.0.x, efcedabe, Patch-Bombing and good faith
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 . && 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 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 >>
Re: 4.0.x, efcedabe, Patch-Bombing and good faith
I'd consider 4.0 an in progress release branch. A topic might be remove-get-plugin, for example. On Tue, Jul 15, 2014 at 1:24 PM, Michal Mocny wrote: > May we keep these topics within existing email threads? Some of these > topics have been addressed elsewhere and the conversation is forking. > > RE: topic branches -- thats what 4.0.x is, no? I guess as more people > start to actually consume it, we should start to care more about compat. > We didn't care about making breaking changes in the first weeks, and now > its the end of the world (okay I'm exaggerating here, just trying to > counterbalance the original tone ;) > > Also, 4.0.x also doesn't exactly have a well defined set of things to test > against, so we should discuss that tonight. I think its hard to include > other peoples demos which you don't know exist in that set.. > > -Michal > > > On Tue, Jul 15, 2014 at 3:48 PM, Brian LeRoux wrote: > > > 1. patch bombing is never ok > > 2. topic branches people: its not hard > > 3. testing: this is why you do it > > > > +1 revert. back and forth justifications have been going on for weeks, > > joe's work is totally borked and blocked which is unfair. > > > > > > On Tue, Jul 15, 2014 at 11:42 AM, 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 > > > > > >
Re: 4.0.x, efcedabe, Patch-Bombing and good faith
For the sake of the commit history, I would prefer to revert, either with a push -f or a new branch (4.0.y?) rather than push a "negative commit" onto the existing branch. Topic branches would have worked well in this case, I'm sure. Having an "api-sanity" branch and/or a "multi-webview" branch from the 4.0.x branch that could have been discussed before being merged in. Re: Testing -- I'm pretty sure that we've been testing everything against mobilespec all along; I know that Andrew's changes have required multiple major updates to CrosswalkView, which has been a pain, but plugins and apps have continued to work untouched. With pluggable-webview, we are defining a new interface, and it's going to be hard; it's going to go through changes before it's releasable. Thankfully, its not a public interface until it's released. The only people who should be affected right now (hopefully) are those people working on third-party webviews, which I think is mostly me, Andrew, and Joe. We should have realized that these changes would have a major impact on Joe's work with MozillaView, and definitely could have coordinated things better. Let's revert if we have to, (but I'd like to hear Andrew's reasons for the changes that were made first), and then figure out how to work together without breaking each other's work. On Tue, Jul 15, 2014 at 3:48 PM, Brian LeRoux wrote: > 1. patch bombing is never ok > 2. topic branches people: its not hard > 3. testing: this is why you do it > > +1 revert. back and forth justifications have been going on for weeks, > joe's work is totally borked and blocked which is unfair. > > > On Tue, Jul 15, 2014 at 11:42 AM, 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 > > >
Re: 4.0.x, efcedabe, Patch-Bombing and good faith
May we keep these topics within existing email threads? Some of these topics have been addressed elsewhere and the conversation is forking. RE: topic branches -- thats what 4.0.x is, no? I guess as more people start to actually consume it, we should start to care more about compat. We didn't care about making breaking changes in the first weeks, and now its the end of the world (okay I'm exaggerating here, just trying to counterbalance the original tone ;) Also, 4.0.x also doesn't exactly have a well defined set of things to test against, so we should discuss that tonight. I think its hard to include other peoples demos which you don't know exist in that set.. -Michal On Tue, Jul 15, 2014 at 3:48 PM, Brian LeRoux wrote: > 1. patch bombing is never ok > 2. topic branches people: its not hard > 3. testing: this is why you do it > > +1 revert. back and forth justifications have been going on for weeks, > joe's work is totally borked and blocked which is unfair. > > > On Tue, Jul 15, 2014 at 11:42 AM, 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 > > >
Re: 4.0.x, efcedabe, Patch-Bombing and good faith
1. patch bombing is never ok 2. topic branches people: its not hard 3. testing: this is why you do it +1 revert. back and forth justifications have been going on for weeks, joe's work is totally borked and blocked which is unfair. On Tue, Jul 15, 2014 at 11:42 AM, 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 >
Re: 4.0.x, efcedabe, Patch-Bombing and good faith
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 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 >
4.0.x, efcedabe, Patch-Bombing and good faith
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
