The future of this project

[Thomas De Schampheleire]

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.

  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