The future of this project

[Dominik Ruf]

Thomas De Schampheleire <patrickdepinguin at gmail.com> schrieb am Di., 13.
Juni 2017 um 20:23 Uhr:

> Hi all,
>
> Thanks Dominik for bringing up this issue, hopefully we can find solutions
> in a
> constructive way.
>
> 2017-06-12 22:21 GMT+02:00 Andrew Shadura <andrew at shadura.me>:
> > Hi Dominik,
> >
> > Thanks for this mail. This is something I've been thinking about too.
> >
> > On 12/06/17 17:41, Dominik Ruf wrote:
> >> 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.
> >> But for example my pull requests about 'repository settings' is now
> >> literally waiting for YEARS.
> >> 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. And some pull request like 'catch MemoryErrors
> >> when calling git diff' are really trivial.
> >
> > Yes, I agree. There's too much bikeshedding and too little real work
> > done. We need to do something about it.
> >
> > Debian is now looking for a replacement for Alioth, which currently runs
> > FusionForge. The replacement has to support SSH, which — with us not
> > having merged the SSH support — immediately makes us worse than the
> > alternatives, even though we have a benefit of also supporting Mercurial
> > and having nice review tools. It's a shame, as being used by Debian
> > could bring new contributors and breath new life into the project.
> >
> >> 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?
> >> Are there any chances that this project will start moving more quickly?
> >> If not, I believe it has no real future. :-(
> >> Which would be a shame. I have quite a few ideas for it and think it
> >> really has potential.
> >
> > I think the first step should be to give power in the project to people
> > who need it. As you currently have the most time and motivation to work
> > on the project, I feel you should try to take it over, at least
> > temporarily, until we, the rest, find more time for it.
> >
> > I think that even if you break things in short term, moving forward and
> > breaking things is better than staying stable without any development.
> >
> > Mads, Thomas, what do you think?
>
>
> Below some of my input, with an attempt to structure it in topics:
>
> Releases:
> - I agree that we should have more releases. In particular, once a bug
>   has been fixed, I think we should not wait longer than a max. amount of
> time
>   to create a new release based on the stable branch. For example, max. one
>   month.
>
> - For feature releases based on the default branch, we had quite some big
> flux
>   passing by the last year: pytest, Turbogears2/gearbox, Bootstrap. As
> these
>   changes gradually were taken in, I think it can be difficult to
> coordinate a
>   moment in time where things are stable enough to base a release on,
> while not
>   holding off some other changes for too long.
>
> - While this seems like a none-issue, I have first hand evidence that at
> least
>   in some companies it does not: since we consider Kallithea as safe for
>   production use, we should use version numbers starting with a non-zero
> major
>   number, rather than 0.x. Some companies are effectively _not_ using
> Kallithea
>   just because the 0.x 'indicates' that it is not ready.
>   My proposal is to either jump from 0.3 to 1.4, or alternatively to 1.0,
> but in
>   any case not stick at 0.x.
>
>
> Speed of intake of changes:
> - For my own changes last year, mostly pytest and Turbogears2 but also some
>   minor fixes, I can really not complain about response time for each
> iteration.
>
> - The conservative approach of change intake, where a PR may need several
>   iterations with rework requests before being final, means that the total
> time
>   to get merged completely can be long, but it does make sure that the
> quality
>   of the new code is high, and the codebase as a whole only improves.
>   It requires motivation from the submitter though, and this may scare off
> some
>   potential contributors. Perhaps it could thus be helpful to relax a bit
> in
>   this respect, but swinging to the other extreme of allowing pretty rough
>   changes to be merged is also not a good idea.
>
> - I understand the frustration of Dominik regarding some of his PRs. I
> value
>   that he suggests improvements in different areas, even outside of
> code such as Jenkins.
>
>   On the other hand, taking the Bootstrap changes as example, it's not that
>   there is a total stand-still; things do seem to move and I see
> several style-related
>   changes coming in.
>
I'm fine with improving PRs in iterations. But like Andrew already said
there is a lot of bikeshedding. And one other point about the bootstrap
changes is, that since about half a year I see no UI improvements or fixes
anymore. My changes only get sliced and diced and rearranged.
And Mads always just picked some of my changes, pushed them and left the
rebasing to me. With which I was fine in the beginning. I though okay if
that is what it takes I'll rebase it. But it never ended and not once did
he contact me to talk about how to continue. And now after the last
iteration I asked multiple times and for 2 MONTH I got no response. Only to
see that yesterday he push some more changes (still without comment to my
questions) and I again I sit here and can figure out what and how to rebase
the remaining things.

>
>   We talked about this at the meetup early 2016 in Antwerp, and one of the
>   problems is the limited amount of review. There is only a very small
> amount of
>   people that review other's changes, most of the time just Mads himself.
> His
>   job would be much easier if others review the incoming changes and
> provide
>   comments to improve them. Unfortunately, the limited number of main
>   contributors is still small, too small it seems for good distributed
> review.
>   For myself, I don't have enough time to really play this role.
>
>
> Maintainership:
> - There are at least two aspects in maintaining a project: coordinating new
>   changes, and coordinating/handling user queries/issues. In practice, Mads
>   handles both tasks almost exclusively and he should get credit for that.
>
>   I therefore don't think we should 'switch' maintainers. If anything,
> depending
>   on discussion on the other items, additional people could get commit
> rights
>   and help move the project forward.
>
>
> Best regards,
> Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20170614/1ac36a31/attachment-0001.html>