Thanks for the reply Jan, my comments are inline:
On 05/26/2014 04:19 PM, Jan Kundrát wrote:
> 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.
>
I completely understand that other things demand your time and energy,
we've all been very happy working with you as the upstream, and I don't
see that changing. These are just a few bumps in the road we can smooth out.
> 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.
>
If those guys can help by providing reviews and feedback on RB, we would
certainly welcome it, and it would reduce some of the review burden on you.
> 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.
>
You are correct that we should be reviewing each others patches, I think
Dan and Boren have been doing some of this already, but I'll be sure to
bring it up in our next meeting to see if we can do more of it.
I think that concern about how our patches affect the DesktopGui parts
of Trojita is limited to our understanding of those parts. While
building the Ubuntu UI we get a deep understanding of our UI and the
common core of Trojita, which we don't necessarily have on the
DesktopGui parts. We can start making that a part of our decision making
while building the Ubuntu UI, but it's going to take some time for these
developers to feel as comfortable making changes to that part of the
codebase as they are to the parts that are their main focus.
> 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.
>
I think we're doing okay with motivation, Trojita is a nice email client
and I think we're all eager and interested in making it work on all of
Ubuntu's form factors. If anybody is feeling discouraged or unmotivated
though, please do let me know.
> 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/
>
As I said earlier we've been very happy working with you. I just wanted
to make you aware of the situation we are facing so we can improve it
before it can become a problem. I think you've identified some good ways
for us to improve things going forward, which we'll start to work on
from our side. Thank you again for your help and encouragement.
> 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?
>
>
Michael Hall
[email protected]
