The future of this project

[Thomas De Schampheleire]

Hi Dominik, Mads, all,

2017-06-19 8:45 GMT+02:00 Dominik Ruf <dominikruf at gmail.com>:
>
>
> Mads Kiilerich <mads at kiilerich.com> schrieb am Do., 15. Juni 2017 um 03:32
> Uhr:
>>
>> On 06/12/2017 05:41 PM, Dominik Ruf wrote:
>> > Hello everyone,
>> >
>> > this mail is overdue, but I always hoped it would get better. :-/
>> > I know this is a community project and we all have other
>> > responsibilities. So I understand that a request does not get answered
>> > instantly.
>>
>> I understand and see your frustration.
>>
>> Not that it really answer your questions, but for what it's worth, some
>> comments to your examples:
>>
>> > But for example my pull requests about 'repository settings' is now
>> > literally waiting for YEARS.
>>
>> Yes. Also, the latest changesets in the PR still say WIP, suggesting
>> that it not really is considered ready yet. The previous iteration got
>> review feedback 2 weeks ago. I haven't had time to follow up on the
>> latest one, having spent time on ...
>
> Yes I got some feedback from a USER about the UI related (WIP) parts.
> And I'm thankful for that.
> It is WIP because I still got no feedback from any 'developer'.
> For the non-WIP parts I still got no review/feedback. And after 2 years
> 'I haven't had time...' is not longer a proper argument :-(

I think the main problem here is again the amount of active developers
with time to review.
In fact, I actually wanted this feature for a long time as well. I was
assuming too much that it would 'automatically' get in, which is also
wrong on my part.
I hope that in the long run, growing the community would help here.
In the short run, I will try to review your open changes and this way
hopefully help moving it forward.

>>
>>
>> > Or lately my 'Port Kallithea theme to Bootstrap' pull request. I asked
>> > multiple times for some feedback, but since 2 MONTH I got nothing. I
>> > understand that reviewing takes time, but at least some kind of
>> > comment is not too much to ask.
>>
>> Bootstrap has been very hard to land. Mainly because my initial requests
>> for splitting things up with clean history so they were reviewable were
>> refused or ignored.
>
> And I said I will not do it because I consider it a colossal waist of time.
> You on the other hand never explained that you'll split it up anyway.

It's a sword cutting on two edges. I understand that it feels like a
waste of time. I have felt the same sometimes during the TurboGears2
changes. However, seeing the end result for those changes, I do agree
that it is much better now even though it took longer: the amount of
changes has been reduced because it turned out that some changes were
not actually needed, some things were done differently/simpler/better,
and in general I feel that we (myself, Mads, in general all of us)
understand the changes much better than if we'd just have pushed the
original commit with almost everything in it.

In any case, I do support fully the request that proposed changes are
reviewable. This typically means splitting up the change so that each
commit does one thing, and can be added independently of subsequent
commits.
I understand that in changes as big as bootstrap introduction this is
not trivial, but not impossible either.

>>
>> I have thus spent a lot of time trying to
>> extract/redo and land parts that I could review and so I knew what was
>> changed and why.
>
> And why the hell did you not rebase it properly after that?

I think it is worth having a discussion on this topic, but please
let's keep it civil.

Mads, can you explain your workflow in such case? Do you at some point
have a repo with the rebased version, or do you start from a clean
one, and cherry-pick individual commits from the PR ?
In the former case we could share that result to alleviate the work of
the submitter, but in the latter case it is not necessarily logical to
expect the maintainer to do such rebase.


>>
>> The latest iteration of the Bootstrap PR is much better
>> and we are making progress - thanks!
>>
>> > And some pull request like 'catch MemoryErrors when calling git diff'
>> > are really trivial.
>>
>> Unfortunately, I also have the feeling that the approach in that PR is
>> wrong.
>
> Then why the hell did you not say so?

As I wrote in my earlier mail, I think more explicit communication
will help here.

>>
>> If we push the system so much that we get MemoryErrors, the
>> system might start swapping and other things might fail too. Instead, we
>> should make sure we don't use crazy amounts of memory but fail
>> gracefully.
>
> I don't think that is possible with the way we use git at the moment.
> But that discussion belongs in the PR. So add a comment to the PR already.
>>
>> But I haven't had time to investigate and propose a better
>> solution.
>
> 'A bird in the hand is worth two in the bush.'
> So even though there is a bigger problem we need to solve in the FUTURE,
> why the hell can we not solve a small part of the problem NOW?

Not neglecting other things I wrote above, I agree that sometimes we
should relax the requirements and accept certain changes if there is
no better solution available in reasonable time. I can't comment on
this particular PR because I don't know it well, but in general
changes that solve a problem and do not make the current situation
_worse_ , should be considered for inclusion.

>>
>>
>> > This can not continue in this way. This project is now almost 3 years
>> > old and we have very little to show for ourselves. In fact there were
>> > questions if this project is actually alive (can't find the link right
>> > now). And I can't blame anybody to think so. Kallithea has improved
>> > very little. Version 0.3 is 20 month ago.
>> >
>> > So my questions to you guys is this:
>> > What are your future plans for this project?
>>
>> My plan is to keep improving it, as contributions, time and priorities
>> allow it.
>>
>> > Are there any chances that this project will start moving more quickly?
>>
>> Yes, if more people help by adding more resources and by helping us
>> utilize resources better.
>>
>> Contributors can help reviewing, testing and improving contributions
>> from others to the point where they are willing to put it in production
>> right away and support it long term.
>>
>> Code contributors can also help by following the contributor guidelines
>> and structure the code changes in such a way that they are easy to
>> review and maintain.
>>


Best regards,
Thomas