[Development] Android: Merge or no merge?

[Oswald Buddenhagen]

On Thu, Feb 21, 2013 at 02:50:26PM +0100, Eskil Abrahamsen Blomfeldt wrote:
> On 02/21/2013 02:16 PM, Oswald Buddenhagen wrote:
> >> and I fear it will jeopardize our chances of meeting the Qt 5.1
> >> deadline.
> >>
> > ah, yeah, there it is: we have a deadline to meet. let's ignore good
> > practice!
> 
> Yes, of course it is a trade-off. In this case, the negative effects of 
> having a code drop with some amendments is outweighed by

> the positive effects of having usable SHA1s in Jira
>
just re-iterating that argument doesn't get you anywhere. start with a
rebuttal of my argument.

> and of being able to focus the time of developers on more important
> issues.
>
there is always something "more important". that's not a free ticket to
dump best practices. we have some people in the project who consistently
think they can do it, and it shows in the quality of their code.

> As far as I can gather from the attention this discussion is getting, 
> having the code drop with amendments in the Android-specific parts of 
> the code is not unacceptable to anyone but you,
>
hmm, how could that be? oh, right: because the biggest mess is in the
build system, and i'm the only guy who will have to deal with it. for
months or years to come.

> The history provides documentation of what has happened to the code, 
> also of the mistakes that are made. The history in this case also 
> documents why the code differs from the Necessitas project, which might 
> also be useful to some people.
> 
none of this is relevant. necessitas can import the current branch from
qt-project into a branch of their own if they care for a precise
representation. if you care for any specific differences, document them
in the initial commit. but frankly, *that* is a waste of time.

oh, and as we are on documenting the initial commit: it isn't
documented. there is a *whole lot* of stuff in the squashed commit where
the only reason given for its existence is "Say hello to Android.",
because this is how it came to be in qt-project. sounds like i really
would want to work with that history in a year from now. almost as
pleasurable as qmake's (the one the public cannot see).

> As we've said earlier, we're hoping to do the merge this week, which 
> means tomorrow.
> 
which is another thing that baffles me to no end. you have a branch that
doesn't even do CI, and your worry is getting it into dev like ...
tomorrow? hello?
neither is the hurry justified, nor is the process in any way
reasonable. paul didn't even post an updated squashed diff for two
weeks.
in particular, you have very little feedback on the parts of the
buildsystem which you did not redo from scratch yet.
i'll simply block the merge, and i don't even need to resort to my pet
process reasons for that.