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 00:08:41 GMT
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 <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