This Project has no future!

Sun Apr 15 10:08:04 UTC 2018

Long Vu <long.vu at intelerad.com> schrieb am Di., 10. Apr. 2018 um 16:17 Uhr:

> On Mon, Apr 9, 2018 at 2:08 PM, Dominik Ruf <dominikruf at gmail.com> wrote:
> > Hi all,
> >
> > I was in denial in the past years. But it is time to face the facts. This
> > project isn't going anywhere.
>
> I am sad to hear this.  Kallithea is about the only *completely open
> source* all in one repo management, code review tool that also support
> Mercurial.
>
> Mercurial needs more tooling support.  Git is more popular not because
> Git itself is easier to use or have more features or can enable more
> workflows (Mercurial Evolve extension beat Git lightweight branching
> and server-side history rewriting by a long shot).
>
> Git is simply more popular because of the tooling support.  Tooling
> support is something Kallithea brings to the table.
>
I completely agree. That is also the reason why I worked on this project
and stayed so long.

>
> > 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.
> >
>
> I am guilty of this as well.  I have 1 or 2 PR that has been sitting
> there for over a year, or almost 2 years (ouch), simply because I have
> not had time to polish them for re-submission.
>
> > 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.
> >
> > 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!
> >
> > 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.
> >
> > 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!
>
> Just my 2 cents here, using Mercurial Evolve, it's super easy to
> change changeset history.
>
I/we already use evolve. But even though it is easy, it still burns a lot
of time. It is not so much time spend to do actual work, but waiting for
feedback for the next iteration. Because changes are easily made it looks
cheap, but in the end it isn't.

>
> I agree that changeset history is not a hard requirement but a very
> good nice to have if time allows.  Make the job of the reviewer easier
> and then the review can review more and give faster feedback.
>
Yes, but it comes the point where it is more work to re-do the changes,
then it helps the reviewer.

>
> Long term, it can help training new developper as well.  When working
> on new area of the code, I tend to annotate, dig the history the few
> files I think I will need to modify, just to see what kind of past
> features, bug fixes also touched these files so I know what kind of
> impact my change will induce and plan testing accordingly.  Too big a
> past commit and I will just get that something in the past needed this
> area of the code but not precisely why so it's harder to understand
> the implicit dependencies.
>
But in this case it doesn't help if the past changes have been split into
multiple smaller ones, does it? Having more, smaller changes means you'll
have to look at more changesets, which makes it more cumbersome. doesn't it?

>
> > - 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.
>
> Agree with that one.
>
> > - Start using JIRA to manage and prioritize the open issues, PRs and
> other
> > tasks.
>
> Doesn't necessarily have to be JIRA but any kind of project management
> tool is good.  I remember someone on this list was considering redmine
> or another newer tool with lots of potential.  Completely open-source
> tool is preferred of course but maintenance and support effort have to
> be considered.
>
I don't think redmine comes even close to JIRA in perms of user
friendliness. But the important thing is that the people in charge actually
do something about this.

>
> > This projects simply needs to get organized.
> > - 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.
>
> This one is big.  I've been using Riot for more than a year and I can
> vouch for it.  It basically replace Slack, Skype, Viber ... all those
> closed and proprietary walled garden.  It is completely open source,
> federated and uses an open protocol Matrix so any other app can
> implement support if desired.
>
> Group chat is first class citizen.  Group video conferencing works
> very well.  It has desktop (Linux, Windows, Mac), web (no install
> required for the occasional user, group video conferencing works very
> well in the web as well), Android, iPhone.
>
> If you want privacy, the same encryption algorithm as Signal that
> Edwards Snowden suggested can be enabled.
>
> Plenty of integration with other tools via bridges.
>
> So ... when was that IRC bridge setup?  Can it be announced on the
> main page https://kallithea-scm.org that there is a Riot bridge
> available?
>
> People can not use it if nobody knows about it !
>
> > Using the riot.io web and phone app can and will speed up the
> conversations
> > a lot.
> > - 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!
>
> Agree with this one.  If next release you guys wants my PR in, I can
> set aside time to polish it for re-submission.
>
> Just have to tell me or other PR author in advance.
>
> Silence treatment is even worse than a clear no we will never accept
> your PR type of response.
>
> > - 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)
> >
> > Since I see little to no chance that these things will actually change,
> I'm
> > afraid I'll have to cut my losses and give up as well.
> >
>
> I've been lurking on this list for a while.  I know Dominik, you have
> contributed quite a few features to Kallithea.

  One of which that I
> also helped tested and reviewed is the custom hooks/configs per repo
> so Evolve and non-publishing can be enabled per repo (these can not be
> global).
>
> For proper Mercurial Evolve support, we need that custom hooks/configs
> per repo feature in.  Mercurial Evolve is what blows away all the
> raves about Git lightweigh branching and the workflows around it.
>
The point is I TRIED to contribute, but after years this is still not
merged. Like you, I think this is an essential feature, but neither Mads
nor Thomas seem to care about it.

>
> Personal thank you for the features you added, they were useful.
>
> > cheers
> > Dominik
> >
> >
> > _______________________________________________
> > kallithea-general mailing list
> > kallithea-general at sfconservancy.org
> > https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
> >
>
>
>
> --
> Long Vu | Software Developer, Tools & Infrastructure | Intelerad |
> +1-514-931-6222 ext. 7743 <+1%20514-931-6222>
>
> --
>
>
> This email or any attachments may contain confidential or legally
> privileged information intended for the sole use of the addressees. Any
> use, redistribution, disclosure, or reproduction of this information,
> except as intended, is prohibited. If you received this email in error,
> please notify the sender and remove all copies of the message, including
> any attachments.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20180415/98c899c2/attachment.html>