This Project has no future!

[Dominik Ruf]

Sorry for the late response, but I wanted to give more people (especially
Mads) the chance to respond as well.

But sadly he didn't. I mean, I claimed that this project faces an
existential crises. And yet, the project lead doesn't even bother to
respond. Sorry, but this is the last nail in the coffin of this project.

Thomas De Schampheleire <patrickdepinguin at gmail.com> schrieb am Di., 10.
Apr. 2018 um 22:05 Uhr:

> 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 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
>
It is slow for years.

> because we are near the end of the bootstrap PR

Even the progress for the bootstrap PR is slow.

> , 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.
>
And it took you more then 2 years to ask about it!?
BTW I don't think it is my job to explain basic web technologies in a
commit message.

> 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.
>
It'd be a legitimate question whether to use gearbox to generate the less
files. But after more then 2 years the time to discuss this has passed.
And like I said, stop making the better the enemy of the good.
If there were really go reasons to use gearbox we could still implement
that later. Adding 'nodemon' (or remove it) is not a big deal.

> The introduction of 'npm run X' has also raised some comments in the
> past regarding cross-platform support. These is IMHO not bikeshedding,
>
The bikeshedding refereed to the source map flag that you wanted in a
separate changeset. If you really think it must be in its own changeset,
then just move it there and don't waste another communication cycle. It is
not worth discussing about.

> 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.

Yes, I also had some trivial changesets that went through quickly. But that
is not the point. We talk about the big important stuff.

> 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.
>
I don't know about this, I can't see the changes in the bitbucket PR
anymore. But I guess it did not involve any difficult decisions. And that
is where the problem occur.

>
> 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.

Sorry, but you should know that this is not always possible.
The current history does not represent the natural way how the bootstrap
stuff evolved. There is no way that I could anticipated the changes from
the beginning.

> And when these commits are small
> and well documented in the commit message, then review will be much
> easier.
>
I will admit that my commit messages were not very detailed at the
beginning (quite often I believed it was just not necessary). But fine, I
see some value in it and my commit messages are more detailed now. But
again this is not what I'm criticizing here.

> 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.
>
Note that in order to move forward I had to remove stuff.
And that results in a worse quality of the current code. The less code is
not as clean as it should be.

>
> >
> > 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 what do you plan to do about it?

>
> >
> > 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.
>
And leaving the bootstrap PR untouched for 9 days is your idea of focusing
on the problem?!

>
> >
> > 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'.
>
Then 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
>
One last thing:
In the beginning, when I started to work on bootstrap, it felt like I'm
working together with Andrew on it.
But not once did I feel like I work with Mads, it always felt like I have
to work against him.
Thomas, I appreciate that you are trying to improve things. But I'm sorry,
it feels like "too little too late".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20180415/5984096e/attachment-0001.html>