Hi guys, I'm sorry to hear about this... but honestly it didn't surprise me. I think anyone could have seen that this was going to happen, it was only a matter of time - few months, a year or two maybe.
What I'm really sad about is that the issue has been raised a couple of times already, yet (former) maintainers didn't take the time and effort to involve new people in the project. I would probably be a smoother transition now if they did. I disagree that a 20hrs/week commitment is required from someone. I don't think it's the right model, and we're unlikely to find anyone. There were times (about a year ago) when I had tons of time to contribute, yet mainstream dev's resources were the bottleneck in reviewing these changes. At other times they were active but I didn't have time to contribute. Instead, I believe it should be a core with 3-5 people who have similar working style and similar vision of the project, and each contribute just a few hours per week. There'd be code review for every nontrivial change, but it could be done by anyone from this team who happens to have some free time. IMO that's the way to avoid bottlenecks, yet guarantee a certain level of code quality. 1-2 people at the core will always be bottleneck, and allowing write access to pretty much anyone who has already contributed something could easily lead to the whole project falling apart due to no clear goals, no clear coding and quality standards, every random hacker with hardly any coding experience pushing for their unmaintainable dirty solution to be committed. And, that being said, while I'm open bringing in brand new folks (e.g. Luca), I'm quite conservative here and would prefer to see him joining conversations at some tickets and posting several great patches (that is, gaining trust in those who already have some) before giving him write access. I'd be happy to see Mooffie on the team right away, his work (along with his style and the contents of the homepage) totally convinced me. I'm sorry to say this, but I myself cannot guarantee anything and cannot make any commitments. I'm spending a long vacation right now where I was planning to do some coding on my primary hobby project (gnome-terminal), and maybe address one or two issues on my secondary hobby project (mc); all subject to my mood. After this vacation I'll start a new job which will require 100% of me. So I'd rather stay an occasional contributor as I am now, and not devote myself to anything with mc. G-t is my personal hobby project in the sense that I do hunt down and address bugs that cause problems to other people but I myself don't particularly care about. Mc never reached this level for me, I never took time to look at bugs and patches that I myself wasn't personally interested in. Don't ask me why it turned out this way, I don't know - maybe it was because on g-t I got quick feedback of my work, whereas on mc I often had to wait for so long that I almost lost interest, and often missed the free time I had when I could have worked on these issues. As for the current segfault issue, I think the broken change should be reverted for now and a .15 released until we come up with a proper solution. Generally it would be good to make releases closer to each other, let's say every 2 months or so, and much sooner when some critical bug sneaks in. This is because I think most users will use mc as shipped by their distros, and distros pick the newest tarball at a random time, hardly ever caring about backporting a fix from git, let alone from trac discussions and vagrant patches. Anyway... I really don't have any wise words on how it should work out from here. Let's hope we manage to come up with something great. Giant thanks to you guys who maintained this project for years, I'm sad to see you go, and wish you all the best! e.
_______________________________________________ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
