Hi Dominik, Mads, all, 2017-06-19 8:45 GMT+02:00 Dominik Ruf <[email protected]>: > > > Mads Kiilerich <[email protected]> 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 _______________________________________________ kallithea-general mailing list [email protected] https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
