I've been hoping to get into Mixxx development, and I remember noticing the lack of a developer guide when I sat down to try to figure things out once. My courseload this semester has turned out to be a bit heavier than anticipated, but no one else has had time put something together by the time I have time to try to learn the Mixxx source better (hopefully this summer?) I can attempt to write things up as I go through the code myself.
I'd imagine anything I come up with would need some reviewing by more experienced developers in case I miss details, but I figured it might help save you all the more arduous part of the work. Baltazar > On Mar 27, 2017, at 01:39, Tuukka Pasanen <pasanen.tuu...@gmail.com> wrote: > > Hello, > > Yes piling of PR is problem and getting them through is sometimes little > bit slow. Should we have something like kernel-next which have things > that are not in master but coming to it and people can test it and > report bugs against it. It would not so conservative what gets in and if > something doesn't go forward it's just removed. > > Mixxx could really do tagging which some projects does. So PR's could be > tagged as nealy finnish and need for testers. > > Just few thoughs... but let's face this it's positive problem there is > more and more people interested in contributing to Mixxx. > > One this Mixxx should start using is: https://github.com/coala/coala (as > python is already needed for scons) to lint every language with same > interface so all stupid linting and code formatting issues could be > fixed before PR state. > > > 25.03.2017, 20:43, Be kirjoitti: >> We do need to define a release process, but I think there is a bigger >> issue here that contributes to disorganization around releases. I've >> been thinking that the biggest issue Mixxx faces is a shortage of labor. >> Testing and reviewing pull requests is a lot of work, hence why I >> started this thread to try to get more people involved in that. >> >> Right now we have a lot of responsibility falling on very few people, so >> if one or two of them have less time to work on Mixxx it holds up >> everything. This is not a good situation, and I think the only fair way >> out of it is to get more people involved. I think we should consider >> what we can do to attract and retain more developers for Mixxx. >> Obviously, making the software better is a good start. Hopefully the new >> features and polishing in 2.1 will bring in more interest. Evidently >> though, putting code out in the open is not enough. I think we should >> consider the obstacles to contributing and how we can reduce them. >> >> I think the biggest issue is the lack of developer documentation. >> Comments in source code are helpful, but we also should have high level >> overviews of how the different parts of Mixxx fit together. Mixxx has a >> lot of code. It's difficult to start working on it, even to fix a small >> bug, without a considerable investment of time to understand what >> different parts of the code are doing and why it is organized that way. >> Requiring all new contributors to struggle through this themselves is >> inefficient. This information should be written out and easily >> accessible. We have http://mixxx.org/wiki/doku.php/developer_guide but >> it only covers a little bit of the core infrastructure. I think it would >> be a worthwhile investment of time after the 2.1 release to work on the >> Developer Guide. > Developer guide would be marvelous but does someone have time to write > it? Or do we not to have time to write it? >> Having the project scattered across a different service and account >> system for each part of it is another annoying barrier. We have GitHub, >> Launchpad, our wiki, our forum, a Freenode IRC channel, and this >> SourceForge mailing list (which injects spam into every post...). That's >> a lot to sign up for and a lot to keep track of. I could understand how >> it would be bewildering for someone new to Mixxx to figure out where to >> go for information or how to contribute. However, I think this is a >> relatively minor issue though and the cost of switching services would >> be high. > Let's drop launchpad altogether or at least for bugs. Translate them to > Github. >>> On 03/25/2017 08:12 AM, Josep Maria Antolin wrote: >>> I haven't commented on this yet, although I am involved in it too, as I >>> have several PRs pending approval. >>> >>> >>> My PRs are: >>> #1195 Restructuring related to recording dialog settings and encoders >>> #1171 Three fixes related to waveform generation, splitted from the >>> multithreaded-analysis branch >>> #1069 Multithreaded analysis >>> >>> First one is almost ready, pending some UI improvements, although I am >>> not so sure I can do it.(It adds 24bit and 32bit float for WAV and AIFF, >>> ABR and VBR for MP3 and FLAC encoding) >>> Second one seems ready (at least from my point of view), but hasn't been >>> merged yet. (As the name says, they are bugfixes related to waveform >>> generation) >>> Third one was ready, but it will require some changes once 1171 is >>> merged, because It's not up to date with those changes, and I think it >>> was not merged initially in order to change it to not use multiple >>> lists. I will need to work that a bit more, but as I said, 1171 has to >>> be merged first. (This one is mostly important for new users as well as >>> when adding many new tracks ) >>> >>> >>> Probably, the open source nature and lack of control about the features >>> that contributors decide to implement, is making harder to set a release >>> timeline, but it also feels a bit frustrating when PRs take long to get >>> ready to be merged. >>> >>> And this is only going to get worse for the "summer of code" (as in >>> having less resources to test and merge PRs). >>> >>> So maybe we, contributors included, need to sit down and put some >>> priorities and processes in place together, with the objective of >>> focusing on the release. I just don't know what can I do in this regard. >>> >>> And talking about Skins: It's something of which I don't have experience >>> yet. I'm not sure if i'm the right person for adapting any of those to >>> the new settings. >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Get Mixxx, the #1 Free MP3 DJ Mixing software Today >> http://mixxx.org >> >> >> Mixxx-devel mailing list >> Mixxx-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mixxx-devel > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Get Mixxx, the #1 Free MP3 DJ Mixing software Today > http://mixxx.org > > > Mixxx-devel mailing list > Mixxx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mixxx-devel ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
