Hi Michael, (and the list, after an OK from Michael),
I guess I understand your frustration -- it always sucks when you hit an
issue like that.
There was a dead march at $work lately which was sucking a ton of energy
from me, leaving no time for Trojita, as you noticed. The good news is that
this should be slowly getting over, and that in the end it might bring some
improvements for Trojita as well in the long run (at least I would surely
like Gerrit with a pre-merge CI) -- hopefully.
Technically, any KDE developer has enough rights to merge these changes. In
real world, only the pre-established set of people usually do this (that
would be Thomas Lübking, Caspar Schutijser and Stephan Platz). These folks
have my full trust and are capable of evaluating the proposed changes on
their own. At the same time, I can understand that they did not want to
merge these changes when I was commenting on the technical details and
making an impression that I am capable of handling the merges. An
especially bad example is [1] where I quite explicitly said that it needs a
thorough design, and that I need more time to answer whether this should be
the way forward or not. Thaknfully, there are other unsolved issues with
that particular patch, but of course I understand that Gilles doesn't want
to fix these small details before I make up my mind.
You're also asking whether you could somehow change your process in order
to make these merges easier. I think you're all working really well; I'm
sure that the code which gets submitted is as good as you could get. What
would help is more mutual review -- perhaps it's already happening and just
not visible enough for me in the RB, but if more developers tested these
patches and looked into them with a very sceptical eye (in general, "would
I like this patch if I was to maintain it for ten more years", or "how does
this duplicate the code in the DesktopGui"), that would definitely improve
the situation a bit as well. There are some common parts where the
functionality is going to duplicate the DesktopGui a bit. If the patch
submission makes it clear that "you guys" care not only about the QML,
Ubuntu-specific version, but instead it is obvious to me that the author
tried hard to come up with e.g. a refactoring which enables a certain piece
of code to be used by both versions, now that's something which means that
I switch from a mode of "how is this patch going to make further changes
more difficulut" into a "hey, those people are helping me while they're
building another UI, cool". Basically, the sense of shared responsibility
about the whole project and not about just the parts which are critical for
the touch version. To be perfectly clear here, I'm not saying that this is
in any way mandatory for accepting patches; I was just asked what I think
could help, and I believe that this is indeed one possibility.
There's always the question of motivation. I have no idea what would other
Trojita developers like, whether a contract would do, or a shiny new phone
with a latest Ubuntu build, or a ticket to $hackathon, or whether they
already have a ton of work on their plates and are not willing to take on
any more -- I really don't know, and I surely have no idea whether "you"
could afford any of that within your budget. For me, the motivation is
mainly about willing to have Trojita succeed, to see it getting further
adoption, and not enough time with a $dayjob and $other-life is the main
problem.
Anyway, this reply is already longer than I expected. Thomas, Caspar,
Stephan -- please feel free to use your best judgement and merge these
patches (or any other patches, for that matter) at will. As I said, I trust
your ability to review stuff and to maintain it in the long term.
I'm leaving the original mail below for reference as it didn't go through
the ML at first ("wow, Jan is top-posting!" :) ).
With kind regards, and thanks for reminding me that I should get into patch
review,
Jan
[1] https://git.reviewboard.kde.org/r/118030/
On Monday, 26 May 2014 18:54:10 CEST, Michael Hall wrote:
Hi Jan,
During the IRC meeting last week, Dan expressed some concerns that
development on the Ubuntu UI port is sometimes being blocked waiting on
branches to land in trunk. He doesn't want to make a separate branch
for Ubuntu development, he wants to continue working against upstream
trunk, but at the same time there is work that others are trying to do
that depends on branches proposed but not yet landed in upstream trunk.
One specific example is https://git.reviewboard.kde.org/r/117588/ which
Dan says Boren needs in order to continue the work that he is doing.
So far I think you have been the only person who has been able to
approve these branches to land, which means that when you're unavailable
they can't progress. Is there anybody else in the Trojita project who
can review and approve these? Or, barring that, anything we can change
about how we're working to speed up the process of review and landing?
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
