cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: 4.0.x, efcedabe, Patch-Bombing and good faith
Date Tue, 15 Jul 2014 23:51:48 GMT
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 <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
View raw message