On Sun, May 31, 2015 at 08:30:49PM +0200, Yury V. Zaytsev wrote: > * Regarding mc^2 fork, I would like to review the code and get it > merged. After that, we can make a major 5.0.0 release, which may take > some time to stabilize. I would need help with code review to make this > happen in finite time though. > you can count on at least some attention from me.
> * If you want to invest a large amount of work into something to prove > yourself, but are unsure about it, ask on the list. If you want to > tell me (or anyone) what and how we should do, but aren't ready to > invest large amounts of work yourself, then please don't. > you certainly realize that the boundary of what is considered constructive input/feedback and useless noise is highly individual and context-sensitive. luckily, the effort to reject (or outright ignore) a particular contribution is roughly inversely proportional to how outlandish it is. just don't overdo it. > * Regarding the infrastructure & the development process that we have > set up and followed while still being active: nothing is set in stone. > > However, keep in mind that the best way to convince me is to actually do > the work, e.g. if someone has been triaging Trac for some time, and can > explain why it's been painful, and how a proper migration to service X > that he is ready to prepare will solve all the problems and make him > über productive, I'm likely to fall for this argument. > i have no problem whatsoever with trac as a bug tracking system (obviously, as long as the performance doesn't break down entirely). it isn't awesome, but it certainly does everything a project of the size of mc needs. however, as i have expressed multiple times over the past years, i do have a problem with it being used as a code review tool - because it simply isn't one. even you guys effectively demonstrated that: while you used it as a patch tracker (with rather clumsy workflow management), you did all the actual feedback on jabber. so while i'm not exactly a fan of github (as indicated in my other mail), i certainly consider it a significant improvement over trac, and would fully support making it the official channel for patches. one might argue that the fragmentation of tools is a disadvantage, but i don't really see a significant problem with that. one idea, though: it would be awesome if you could set up github authentication for trac. https://trac-hacks.org/wiki/OAuth2Plugin however, there *is* a significant problem with people using the github issue tracker while trac is the official one - i'd disable the github one instantly. _______________________________________________ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
