hard-dep for Qt 4.8

[Dario Freddi]

2012/1/18 Thomas Zander <zander at kde.org>:
> On Wednesday 18 January 2012 09.05.32 Dario Freddi wrote:
>> > if you remember there are a lot of people using KDE that are not 'core'
>> > developers. Typically they are one-time developers, they are artists,
>> > they are translators etc
> []
>
>> That said, I am in favor of moving to Qt 4.8 for a simple reason: I
>> believe both of you are right, but you are missing a point: the
>> occasional contributor is very likely to work in a branch.
>
> Dario,
> you seem to have skipped over my main argument. This is not *just* about code-
> contributors, although they make a very strong point too.  Instaed think of
> the impact this has on all the groups I mentioned above. Artists trying to
> follow development. Translators trying to run stuff in order to figure out where
> a string comes from. Simple bugreporters that have little technical savy but
> can try out if a bug is still reproducable in 'master'.

Indeed, I reckon the situation is much more complex than how I painted it

>
> What some people here are arguing is that its Ok for a huge group of people
> that help KDE get better to have to wait for various months before they can
> compile KDE master again.
> And I want you to think about that long and hard because you may be
> underestimating the positive influence that group has on our community

I am way, way far from underestimating that, my efforts in helping and
mentoring new contributors should speak for me in this regard :)
.
>
> Kind of a postscript I just wanted to reply on your argument for a branch.  It
> doesn't in practice apply to the guys coming in with a simple bugfix.  Their
> starting point will very likely be the current main branch.

And that is exactly my point. This is very likely to happen, but it's
wrong. Because for how our repos are structured now, you will need to
commit to the stable branch anyway and forward-port your change after
that - so it's not like you should start from a stable branch, but you
*NEED* to. And this is how our communication towards new people
currently fails, and where we are failing in outlining a clear policy
on how to contribute to KDE after the big move. If you have a bug in
master and in master only, of course this reasoning does not apply,
but it's not the point of the discussion.

Of course, as I said before, I just gave my 2c, and I really do
appreciate your commitment to making KDE more accessible to anyone
(and want to thank you for that), I still think your points are way
more than valid (especially the ones about non-coders contributors)
and it's great that these kind of topics are brought up in these
discussions, so again thanks for considering and most of all for
making us consider that. Let's try to move the issue another way
round: can we think of a way in which we can safely make master depend
on new stuff without the risk of hurting these categories?

Let me start by saying I don't have an answer for that, or I wouldn't
haven posed the question :). When we discussed git workflows in Randa,
we tried to paint a situation where unstable branches were clearly
marked as such, but it came out to be a too much complex workflow for
how our community is structured. I think, again, modularization could
help us here. If we take for granted the main issue in this regard are
not code contributors, we probably need to find a way to allow the
needs of both "kinds" of contributors to be satisfied.

Our commitment to binary compatibility definitely helps here, and we
might even think to go as far as (in the future) making just some
components dependent on a particular Qt version, since we can afford
to do that. But again, that's just a personal rambling and I would
welcome brighter opinion. It's very hard to satisfy everybody, but if
there's one thing I totally agree with Thomas, as I said in my
previous mail, is that our needs should not be a barrier for new
people to join in. But I am confident we can get to a sensible
compromise.

>
> --
> Thomas Zander