Re: [Mixxx-devel] test builds for PRs

2017-03-27 Thread Daniel Schürmann
Hi Baltazar,

that sounds great.
Thank you very much, for offering your time.

If you need help, just ask on this list.

Kind regards,

Daniel




2017-03-27 16:22 GMT+02:00 Baltazar Ortiz :

> 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 
> 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
> >>> 

Re: [Mixxx-devel] test builds for PRs

2017-03-26 Thread Tuukka Pasanen
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 

Re: [Mixxx-devel] test builds for PRs

2017-03-25 Thread Be
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.

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.

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

Re: [Mixxx-devel] test builds for PRs

2017-03-23 Thread Be
I have been waiting for testers for the new loop controls for over a month:
https://github.com/mixxxdj/mixxx/pull/1187
You need to use it with the Deere redesign in 
https://github.com/mixxxdj/mixxx/pull/940
Refer to the wiki for tips on setting up multiple git worktrees for this:
http://mixxx.org/wiki/doku.php/using_git#working_on_mappings_and_skins_separately_from_other_changes
I don't want to make any more big(ish) C++ changes for 2.1 other than 
the PRs I already have open.

The biggest task that must be done before final release is updating 
LateNight and Shade. I've put a ton of work into redesigning Deere, so 
I'd appreciate if others stepped up to implement the new effects UI in 
the other skins. Refer to the wiki for documentation on the new 
ControlObjects:
http://mixxx.org/wiki/doku.php/mixxxcontrols#effects_framework
That does not have to be completed to start beta releases though.

Ferran, will you have time to work on LateNight? Or should someone else 
take care of it?

On 03/23/2017 05:01 PM, Daniel Schürmann wrote:
> Hi Markus,
>
> I am also quite unhappy, that we missed a suitable release date as we
> have original planed "short after 2.0". Later in September, we had also
> a very stable alpha version that was suitable for merge.
>
> Now we are in a middle of a giant feature creep, polishing skins and
> controller interface. It would feel bad to release Mixxx with this halve
> finished. The involved contributors are very productive and hard
> working, so I think we are ready for release soon.
>
> My tasks are already done and pending as PR
>
> Mandatory:
> HiDPI Skin Scaling https://github.com/mixxxdj/mixxx/pull/1204
> Hint rounding https://github.com/mixxxdj/mixxx/pull/1223
>
> Optional:
> LV2 support: https://github.com/mixxxdj/mixxx/tree/lv2_support2
> Optional network clock reference https://github.com/mixxxdj/mixxx/pull/894
> Auto dj crates improvements https://github.com/mixxxdj/mixxx/pull/1214
> Show native separators in user visible strings (GUI)
> https://github.com/mixxxdj/mixxx/pull/1215
>
> If I find time, I would also look at the DB rename detection.
> I am afraid it is broken, because I have a lot of missing tracks in my
> library.
>
> What else is mandatory for the release?
>
>
> Kind regards,
>
> Daniel
>
>
>
>
>
>
>
>
>
>
> Maybe they can give an
>
>
> Am 23.03.2017 um 21:34 schrieb Markus Klösges:
>>> We have accumulated a rather large backlog of pull requests that are
>> awaiting review and testing.
>>
>> IMHO it would also be nice to have some more info on release schedules
>> or plans, what could be merged and what is laying around for next alpha.
>> What to focus on, where help is wanted. Maybe GitHub tags could be used
>> for marking 'please test', 'next alpha', ...? In combination with some
>> more communication about planned releases, that could probably help
>> focusing the work.
>> What do you think?
>>
>> Am 23. März 2017 16:56:03 MEZ schrieb Be :
>>
>> We have accumulated a rather large backlog of pull requests that are
>> awaiting review and testing. I wrote a new wiki page and put it on the
>> front page of the wiki to help users get involved with testing:
>> http://mixxx.org/wiki/doku.php/testing
>>
>> To get more testers, it would be helpful to make the builds Travis makes
>> available for download. AppVeyor already does this and keeps the builds
>> on the AppVeyor site. Could we host those on Travis or have the Travis
>> VMs send the builds to our build server for hosting?
>>
>> 
>>
>> 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
> 

Re: [Mixxx-devel] test builds for PRs

2017-03-23 Thread Radu Suciu
My mapping PR for the Mixtrack Pro 3 is ready to go and works well with the
current master version (tested live several times now)

https://github.com/mixxxdj/mixxx/pull/1180

On Thu, Mar 23, 2017 at 3:01 PM, Daniel Schürmann 
wrote:

> Hi Markus,
>
> I am also quite unhappy, that we missed a suitable release date as we
> have original planed "short after 2.0". Later in September, we had also
> a very stable alpha version that was suitable for merge.
>
> Now we are in a middle of a giant feature creep, polishing skins and
> controller interface. It would feel bad to release Mixxx with this halve
> finished. The involved contributors are very productive and hard
> working, so I think we are ready for release soon.
>
> My tasks are already done and pending as PR
>
> Mandatory:
> HiDPI Skin Scaling https://github.com/mixxxdj/mixxx/pull/1204
> Hint rounding https://github.com/mixxxdj/mixxx/pull/1223
>
> Optional:
> LV2 support: https://github.com/mixxxdj/mixxx/tree/lv2_support2
> Optional network clock reference https://github.com/mixxxdj/mixxx/pull/894
> Auto dj crates improvements https://github.com/mixxxdj/mixxx/pull/1214
> Show native separators in user visible strings (GUI)
> https://github.com/mixxxdj/mixxx/pull/1215
>
> If I find time, I would also look at the DB rename detection.
> I am afraid it is broken, because I have a lot of missing tracks in my
> library.
>
> What else is mandatory for the release?
>
>
> Kind regards,
>
> Daniel
>
>
>
>
>
>
>
>
>
>
> Maybe they can give an
>
>
> Am 23.03.2017 um 21:34 schrieb Markus Klösges:
> >> We have accumulated a rather large backlog of pull requests that are
> > awaiting review and testing.
> >
> > IMHO it would also be nice to have some more info on release schedules
> > or plans, what could be merged and what is laying around for next alpha.
> > What to focus on, where help is wanted. Maybe GitHub tags could be used
> > for marking 'please test', 'next alpha', ...? In combination with some
> > more communication about planned releases, that could probably help
> > focusing the work.
> > What do you think?
> >
> > Am 23. März 2017 16:56:03 MEZ schrieb Be :
> >
> > We have accumulated a rather large backlog of pull requests that are
> > awaiting review and testing. I wrote a new wiki page and put it on
> the
> > front page of the wiki to help users get involved with testing:
> > http://mixxx.org/wiki/doku.php/testing
> >
> > To get more testers, it would be helpful to make the builds Travis
> makes
> > available for download. AppVeyor already does this and keeps the
> builds
> > on the AppVeyor site. Could we host those on Travis or have the
> Travis
> > VMs send the builds to our build server for hosting?
> >
> > 
> 
> >
> > 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
>
--
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

Re: [Mixxx-devel] test builds for PRs

2017-03-23 Thread Daniel Schürmann
Hi Markus,

I am also quite unhappy, that we missed a suitable release date as we 
have original planed "short after 2.0". Later in September, we had also 
a very stable alpha version that was suitable for merge.

Now we are in a middle of a giant feature creep, polishing skins and 
controller interface. It would feel bad to release Mixxx with this halve 
finished. The involved contributors are very productive and hard 
working, so I think we are ready for release soon.

My tasks are already done and pending as PR

Mandatory:
HiDPI Skin Scaling https://github.com/mixxxdj/mixxx/pull/1204
Hint rounding https://github.com/mixxxdj/mixxx/pull/1223

Optional:
LV2 support: https://github.com/mixxxdj/mixxx/tree/lv2_support2
Optional network clock reference https://github.com/mixxxdj/mixxx/pull/894
Auto dj crates improvements https://github.com/mixxxdj/mixxx/pull/1214
Show native separators in user visible strings (GUI) 
https://github.com/mixxxdj/mixxx/pull/1215

If I find time, I would also look at the DB rename detection.
I am afraid it is broken, because I have a lot of missing tracks in my 
library.

What else is mandatory for the release?


Kind regards,

Daniel










Maybe they can give an


Am 23.03.2017 um 21:34 schrieb Markus Klösges:
>> We have accumulated a rather large backlog of pull requests that are
> awaiting review and testing.
>
> IMHO it would also be nice to have some more info on release schedules
> or plans, what could be merged and what is laying around for next alpha.
> What to focus on, where help is wanted. Maybe GitHub tags could be used
> for marking 'please test', 'next alpha', ...? In combination with some
> more communication about planned releases, that could probably help
> focusing the work.
> What do you think?
>
> Am 23. März 2017 16:56:03 MEZ schrieb Be :
>
> We have accumulated a rather large backlog of pull requests that are
> awaiting review and testing. I wrote a new wiki page and put it on the
> front page of the wiki to help users get involved with testing:
> http://mixxx.org/wiki/doku.php/testing
>
> To get more testers, it would be helpful to make the builds Travis makes
> available for download. AppVeyor already does this and keeps the builds
> on the AppVeyor site. Could we host those on Travis or have the Travis
> VMs send the builds to our build server for hosting?
>
> 
>
> 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


Re: [Mixxx-devel] test builds for PRs

2017-03-23 Thread Markus Klösges
> We have accumulated a rather large backlog of pull requests that are 
awaiting review and testing.

IMHO it would also be nice to have some more info on release schedules or 
plans, what could be merged and what is laying around for next alpha. What to 
focus on, where help is wanted. Maybe GitHub tags could be used for marking 
'please test', 'next alpha', ...? In combination with some more communication 
about planned releases, that could probably help focusing the work.
What do you think?

Am 23. März 2017 16:56:03 MEZ schrieb Be :
>We have accumulated a rather large backlog of pull requests that are 
>awaiting review and testing. I wrote a new wiki page and put it on the 
>front page of the wiki to help users get involved with testing:
>http://mixxx.org/wiki/doku.php/testing
>
>To get more testers, it would be helpful to make the builds Travis
>makes 
>available for download. AppVeyor already does this and keeps the builds
>
>on the AppVeyor site. Could we host those on Travis or have the Travis 
>VMs send the builds to our build server for hosting?
>
>--
>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