This Project has no future!

Tue Apr 10 20:21:32 UTC 2018

Thomas De Schampheleire <patrickdepinguin at gmail.com> writes:

> Hi Dominik,
>
> 2018-04-09 20:08 GMT+02:00 Dominik Ruf <dominikruf at gmail.com>:
>> Hi all,
>>
>> I was in denial in the past years. But it is time to face the facts. This
>> project isn't going anywhere.
>> About a year ago I already expressed my worries, but next to nothing has
>> changed since. There are still pull requests that are multiple years old.
>>
>> For example, my bootstrap PR is still not pulled completely. There is still
>> a discussion about whether (and how) we should use minification and source
>> maps.
>> These are technologies that practically every web application in the world
>> are using. So this should be a no-brainer. And yet, after more then 2 years
>> we discuss if adding the source map flag should be in a separat changeset.
>> Seriously guys, this could be in the dictionary as the very definition of
>> bikeshedding.
>
> I'm sorry you feel this way.

I am sorry that the only public free in price and freedom project that
have been launch have been immediately killed by people of git because
it use the name git ... in a way we should all stop to respire
... someone get the name air ;-)

> I don't agree that the project is not going anywhere or it has no future.
> It's just so that at this moment the pace of development is quite slow
> because we are near the end of the bootstrap PR, and there are some
> changesets where there is still a discussion. It is not so much about
> whether or not to use minification or source maps. There was some
> unclarity on how the source map actually works and whether the feature
> was complete, that is clear to me now.
> There is also an open point about the 'watch' feature and whether or
> not it should be integrated in gearbox --reload rather than
> introducing a new 'nodemon' mechanism.
> The introduction of 'npm run X' has also raised some comments in the
> past regarding cross-platform support. These is IMHO not bikeshedding,
> it's about being careful in adding extra complexity or going in a
> wrong direction.
>
> There are other examples of changes that go through quickly and
> without a lot of problem. Examples are the changes regarding 'issue
> references' (issue_pat and friends), the refactoring of the VCS test
> classes, and the recent update to V2 reCaptcha.
>
> Regarding clean commits: it is an explicit part of the project
> culture. From the docs/contributing.rst file:
>     "We care about quality and review and keeping a clean repository history."
>
> You have made clear in the past that you think this is often a waste
> of time, but I disagree (and I'm pretty sure Mads does too). A clean
> repository history is invaluable both during review, as during future
> changes, to understand why something was done.
> It would save time and frustration from all people involved if all
> contributors take along this principle from the start when designing
> and ordering commits. If you think from the start how your commit path
> will be, the lost time is minimal. And when these commits are small
> and well documented in the commit message, then review will be much
> easier.
> I'm glad that you split up the one big remaining bootstrap commit 'in
> small parts', like we asked. Honestly, I think it was the only way
> forward, and thanks to your cooperation we landed already a big part
> of it.
>
>>
>> What troubles me the most about this, is the lag of communication. It
>> sometimes takes weeks or even month to get any kind of feedback.
>> I understand that people are busy, but as a leader of a project like this
>> you should at least drop a quick sorry note and say when you will be able to
>> look into the thing. Or delegate!
>
> I agree that this is a weak point at the moment, and that we should
> improve here.
>
>>
>> And I'm not the only one who has this problem. Our bitbucket is full of old
>> PRs that went nowhere. Take the ssh PR for example. That one is 3.5 years
>> old! I believe most of those people just gave up.
>
> It's true that we need to pick up these old PRs or reject them. This
> was agreed upon already a long time ago.
> But the total bandwidth is limited, number of contributors is small,
> so you can only do one thing at a time.
> In the release 'roadmap' I proposed earlier [1] I suggested to finish
> the bootstrap changes and then make a release 0.9, and shortly after
> 1.0.
> At that point, I think we should try to reduce the open backlog. But
> it makes no sense in trying to clean up the old backlog if the current
> active PRs like bootstrap are not yet finished. It would only disperse
> focus of all people involve, and slow down the bootstrap PR.
>
> This is also the reason why I'm currently not actively looking at your
> other PRs (like 'various changes' and 'hooks'): it would move away
> focus from what we said is first priority. Just like you, I would like
> to get over bootstrap as soon as possible so we can move on.
>
>>
>> I really believed this project had potential. But all my attempts to improve
>> the communications or the projects organisation have been ignored. And my
>> PRs were treated purely and very slow.
>>
>> What needs to change:
>> - Stop pondering if some small change should be its own changeset
>> This wastes A LOT of time. The quality of the code needs to have a higher
>> priority then the quality of the changeset history!
>
> Like I said above, I don't agree on this one. It's perfectly possible
> to achieve qualitative code at the same time as a qualitative
> changeset history. I would say it's the case for the commits currently
> in Kallithea, and I have the same experience with other projects like
> Buildroot.
>
>> - Stop making the 'better', the enemy of the 'good'.
>> If somebody comes up with a better solution in the future, great, but up
>> until then settle with the good solution you have now.
>
> In general I agree, partial progress is better than none.
> But:
> - the partial progress should be in the same direction as we want to
> go in the long run, not a different one (so it means there may be
> discussion to get agreement on what that direction should be),
> - and when the 'distance' between the partial solution and the full
> one is not too big, it makes sense to request the full solution at
> once. Otherwise you end up with a codebase with only half-solutions
> and nothing completely done.
>
>> - Start using JIRA to manage and prioritize the open issues, PRs and other
>> tasks.
>> This projects simply needs to get organized.
>
> I agree, have responded positively about this in the past, and we
> 'just need to do it'.
> (not necessarily JIRA, like I said trac or something could be a good
> alterative).
>
>> - Promote riot.io as communication tool for more direct engagement.
>> I mentioned before, that I think mailing lists and IRC are anachronistic
>> tools. And they are not ideal to engage with people.
>> In the mean time, Andrew set up the matrix.org bridge, which allows to use
>> apps like riot.io to chat with our IRC channel. riot.io allows to always
>> stay online and search in the conversation. But AFAIK practically nobody
>> knows about it.
>> Using the riot.io web and phone app can and will speed up the conversations
>> a lot.
>
> Like Long Vu, I'm unaware about this, I have not seen an announcement
> on what and how.
>
> While I dislike our IRC because the relevant people are not listening
> at the same time, and there is no permanent presence,
>
> I don't agree with mailing lists being a tool from the past. It is a
> tool used in almost all FOSS projects I use, and that is because it is
> something that works well.
> You may perceive its asynchronicity as a bad thing and would prefer
> more direct interaction, but that may be difficult with people having
> different work and life schedules.
>
> In fact, I would actually even argue to use the mailing list _more_
> rather than _less_. Today, the list looks 'dead' because most activity
> happens in PRs on either bitbucket or OOK. But these discussions are
> not really 'public' in the sense that everyone can easily see them.
> You have to explicitly search or follow these PRs to see any updates.
> With such an approach, it's hard to build a community where different
> people react to each other's changes. A mailing list PATCH sending
> approach works better for that, or alternatively let OOK send updates
> to the mailing list but this requires some changes like grouping the
> comments (draft comment feature proposed at some point) and public
> registration on OOK.
>
> I would like to learn about and try riot/matrix before taking a stance about it.
>
>> - Engage with people.
>> It can not be that our PRs and open issues lay around for years. If there is
>> no activity, a person in charge needs to reach out to the
>> assignee/commiter/reporter. And if there is no hope that the issue/PR will
>> be solved it needs to be closed. In general, talk to the people. There can
>> be no silent treatment!
>
> Generally I agree. But catching up with this takes time, and like I
> wrote above it is also a matter of finishing ongoing things first.
>
>> - Get serious about new features that make kallithea competitive.
>> SSH, custom (git) hooks (activatable per repository) and scaleability are
>> must haves. (kallithea currently does not work well with many user, many
>> repositories or big git repositories)
>
> I think we all agree that these are important points.
> From my point of view, the most constrained resource is time to write,
> review and merge these changes.
>
> I'm sure we'll get there. Any help from other community members is
> more than welcome.
> But let's first finish bootstrap, and then create some kind of roadmap
> of what to tackle first.
>
> /Thomas
> _______________________________________________
> kallithea-general mailing list
> kallithea-general at sfconservancy.org
> https://lists.sfconservancy.org/mailman/listinfo/kallithea-general