On 13/06/17 20:23, Thomas De Schampheleire wrote: > 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.
I think we can do development releases too, just snapshots every $period once things stabilised a bit. > - 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. I agree. > 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. It is difficult to hold balance between taking changes conservatively and bikeshedding, I know thing myself from other projects as well. I feel we're too conservative now, and while this makes sense, as you're saying it may scare people off. And it does, even myself sometimes :) > - 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. I haven't realised my proposal can be understood this way, sorry if it sounded too harsh. I didn't mean taking the maintainer's or coordinator's role away from Mads. I merely suggested that because he's apparently overloaded and we all lack sufficient time to spend on the project, some of the maintainer's duties may — and probably should — be offloaded to people who can and are willing to take them. -- Cheers, Andrew _______________________________________________ kallithea-general mailing list kallithea-general@sfconservancy.org https://lists.sfconservancy.org/mailman/listinfo/kallithea-general