On Jul 15, 2014 5:09 PM, "Andrew Grieve" <agri...@chromium.org> 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 <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 > > >> > >
