Re: [Mixxx-devel] TESTERS NEEDED: New windows installer

[Sébastien BLAISOT]

 

Thanks a lot daniel for your test. 

I will try to answer to all your points and will reorder them: 

* The setup seams to be not signed: "Unbekannter Herausgeber" 

Right. I will try to see if we can have it signed, but think this
involves having a mixxx-developper keypair to sign the package and I
don't think we have one 
 * Nice Artwork :-) However, it contains the 1.11 Deere Skin 

yes, this is only a quickly made test artwork. Controller photo also
needs to be changed by our own picture (or a free (as in free speech)
one) 
 * The XP warning feels to hard for me, compared to the fact that there
are no known issues. 

What will be correct wording for you ? 
 * The End-user license need to be polished. ** No pronotional Tracks 
** "You should have received a copy of" but the copy follows just after.

** It feels wired that the License starts with the external libraries 

The text is taken from the LICENCE file. If text update is needed,
please open a PR against this file. 
 ** Line breaks are looking missplaces 

yes, there are issues with linebreaks. starting from a text file with
linebreaks and transform it to RTF is not an easy task. so for now, I
just openned it with wordpad and saves it untouched as RTF. 
 ** Embedded links are highlighted but not clickable 

Windows installer framework limitation. Nothing I can do. 
 * Translations are a separate part, but there is no hint what will be
the language without it. 

ok, I will add that in the comment. 

* Clicking on "Disk Usage" stalls the setup with a pressed button for
approx 20 s 

Windows installer framework logic. It scan all drives to detect disk
usage => slow. 
The only thing I can do is to remove completely this dialog, but I don't
think it's a good idea. 

The following items are because you installed on top of a previous
installation: * Translations are 0 kB 

yes, the installer is smart enough to detect that you already have all
files installed in the destination path, so installing this will take no
additionnal space on your disk. 
Try installing on a mixxx-free system, you will see that size differ. 
 * After installation I have two "Manual" links in the start menu 

yes, old installer one and new installer one. 
 * The old uninstaller link remains in Startmenu 

yes 

* In control panel -> Software is a long list of Mixxx versions I have
testes. 

They were there before the installation with the new installer 

* Uninstall plain "Mixxx" entry works only partial 

can you explain a bit more this one ? 
I think it uninstalls correctly what it has installed, but former
installations let files behind. 

so not having a migration path from former installer to newer one seems
to be a problem. 
we have two ways of adressing this : 
1) detect if mixxx is already installed and forbid installation if a
former installation from the previous installer is detected 
2) write some (external and embedded) cleanup code that completely
remove all traces from a previous installation 

the second has my preference but seems harder as it involves writing an
autonomous cleanup executable and embedding it into the installer. 

---

Sébastien Blaisot 

Le 19/11/2015 08:44, Daniel Schürmann a écrit : 

> Hi Sébastien, 
> 
> Here my results from am instillation on a German Win XP using 
> mixxx-2.0-rc1-1.12-git5627-release-x86-en-us.msi 
> on to of an existing installation. 
> 
> * The setup seams to be not signed: "Unbekannter Herausgeber" * Nice Artwork 
> :-) However, it contains the 1.11 Deere Skin * The XP warning feels to hard 
> for me, compared to the fact that there are no known issues. * The End-user 
> license need to be polished. ** No pronotional Tracks ** Line breaks are 
> looking missplaces ** Embedded links are highlighted but not clickable 
> ** "You should have received a copy of" but the copy follows just after. ** 
> It feels wired that the License starts with the external libraries * 
> Translations are a separate part, but there is no hint what will be the 
> language without it. * Translations are 0 kB * Clicking on "Disk Usage" 
> stalls the setup with a pressed button for approx 20 s * After installation I 
> have two "Manual" links in the start menu * The old uninstaller link remains 
> in Startmenu 
> 
> * In control panel -> Software is a long list of Mixxx versions I have 
> testes. 
> * Uninstall plain "Mixxx" entry works only partial 
> 
> Kind regards, 
> 
> Daniel 
> 
> 2015-11-19 1:14 GMT+01:00 Sébastien Blaisot :
> 
>> Hi all,
>> 
>> I finally got wix to build an installer package for Mixxx and with the
>> help of Pegasus, I have my build env fixed.
>> 
>> So here you will find installer for 2.0-rc1-1.12-git5627 :
>> https://owncloud.blaisot.org/index.php/s/nyEDsb0vEV7aa1m [1]
>> 
>> There are 6 files.
>> The exe ones are old installers built with NSIS (same as what you can
>> download from the mixxx site except it was built on my own build env)
>> The MSI ones are new installers built with wix (a preview 

Re: [Mixxx-devel] controller mapping guidelines

[RJ Ryan]

Hi Be / Tuukka,

Sorry for missing this discussion. This is a great topic to have guidelines
around.

I'm concerned about expecting the preset contributor to be involved in our
development workflow (Git, GitHub). This is a high bar that's going to
exclude a large portion of our user base from participating.

The way we have functioned for years now is that users post presets on our
forums and we do some legwork to bundle them with Mixxx if they aren't
sending us merge requests directly. I don't think we should stop that but
instead (and what I have been doing for quite some time) is engage the
preset developer and ask them to submit PRs -- but if that isn't an option
for them or they aren't interested, regularly sync their version from them
on the forums to the codebase.

If there is an existing preset then we usually check that a couple of forum
users confirm it works well. If it diverges significantly from the original
preset functionality then we might stick it in alongside the existing one.

In particular,
https://github.com/mixxxdj/mixxx/pull/780
seemed fine to me. Multiple forum users confirmed it was a valuable
addition to the existing preset so it's pretty normal for us to include.

Thanks,
RJ





On Mon, Nov 16, 2015 at 3:22 AM, Tuukka Pasanen 
wrote:

> Hello,
> GIT would be best solution but probably will fail the reason you
> mentioned.. should we use pages talk-version as new stuff incubator and
> then add it to main page?
>
> Tuukka
>
> 13.11.2015, 09:06, Be kirjoitti:
> > Interesting idea, but I'm concerned that requiring people to do more
> > work to update the wiki would keep people away from contributing to
> > the wiki more.
> >
> > On 11/13/2015 01:01 AM, Tuukka Pasanen wrote:
> >> Hello,
> >> Dokuwiki also have markdown support with plugin so should we have
> >> 'original' in github as rst-file (If we like translations also). Then we
> >> could have these as base for Dokuwiki then use normal Pull Requests to
> >> update those. Little bit double effort but as Be said more qualified
> >> documentation but can be automated with script? Because how many edits
> >> regular Dokuwiki than Be? Because without good documentation application
> >> like Mixxx is unusable and it won't conquer world.
> >>
> >> Thanks,
> >> Tuukka
> >>
>
>
>
> --
> Presto, an open source distributed SQL query engine for big data, initially
> developed by Facebook, enables you to easily query your data on Hadoop in a
> more interactive manner. Teradata is also now providing full enterprise
> support for Presto. Download a free open source copy now.
> http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140
> ___
> 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
>
--
___
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

[Mixxx-devel] [Fwd: Re: [mixxx] Incorporate new mapping from bestdani on the forums. Thanks! (#780)]

[Owen Williams]

do we need to get this forum user to sign the contributor agreement?
Controller stuff is always hazy for me

 Forwarded Message 
> From: Sebastien BLAISOT 
> Reply-to: mixxxdj/mixxx  +000d906cb90481ea05ca72d15572950b649327d02a502a1492cf00011265a65b92a169ce0705e...@reply.github.com>
> To: mixxxdj/mixxx 
> Cc: Owen Williams 
> Subject: Re: [mixxx] Incorporate new mapping from bestdani on the
> forums. Thanks! (#780)
> Date: Thu, 19 Nov 2015 07:01:47 -0800
> 
> 
> 
> No new file => no need to update windows installer.
> Wiki page almost empty => I asked on the forum for someone to update
> the wiki page.
> 
> —
> Reply to this email directly or view it on GitHub.
> 
> 



--
___
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] [SPAM] Re: [Fwd: Re: [mixxx] Incorporate new mapping from bestdani on the forums. Thanks! (#780)]

[RJ Ryan]

Hi Be -- thanks for sharing your perspective,

On Thu, Nov 19, 2015 at 5:21 PM, Be  wrote:

> Grabbing mappings off the forum, with no review and often without
> consent, is how we got to the current messy state of mappings in Mixxx.
> One user saying the mapping works is a low bar.


Yes, this is an unfortunate inherent problem with not owning hardware to do
actual testing.


> Of course testing the
> functioning of the mapping with the controller would be ideal, but
> that's not an excuse for not bothering to review it at all. I don't know
> why the bar has been set so much lower for mappings than C++ code.


The standards are much lower since there is little risk to doing so. If we
took in C++ patches without review we could cause crashes or actual damage
to the user's computer. The sandboxed environment we run Javascript in is
not capable of this. While it's true that Javascript can trigger unexpected
behavior in Mixxx there is not an effective way to explore the set of
possible inputs a script will provide to Mixxx without the device in hand.
In most cases, a preset is not going to take down Mixxx.

The main downside of committing a bad preset is that users who want to use
that device will have a bad experience. That's not good of course, but it's
nowhere near as bad as things could go if we took random C++ patches
without review. On the other hand, if a device is not supported at all (or
the preset is many years old) then the benefit of including a newer (and
actively maintained by someone like bestdani) preset is IMO worth the risk
of the preset not working. In the event that there was no existing preset
then the user is no worse off. In the event that the old preset worked
better -- then that's a bad outcome but not irrecoverable as they can
downgrade if they find their way to the forums via the direct in-app link.
That's why we use positive comments from other forum users as a signal to
tell whether something is an improvement. In the specific instance of this
preset, there have been numerous positive comments telling bestdani that it
was a great improvement.



> None of us are lawyers, so we should not be making decisions about a
> legal grey area. I think the legally clearest and safest situation would
> be to require mappings to be licensed under the GPLv2 or later and have
> mapping authors sign the agreement.


I understand your position here. I've consulted lawyers about this. I'd
prefer to not discuss this any further on our public email list.



> I don't really see any good reason
> not to do this. Why should mappings be separate from the rest of Mixxx?
> The more, high quality mappings are included in Mixxx, the better users'
> experiences with Mixxx will be.
>

I think this is non-sequitor to the question of permission to distribute.
I'm all for efforts to improve the code quality and documentation of our
mappings and I'm thrilled you're interested in helping with that (and for
all of your efforts around documentation in general!).

I dropped some comments in your other thread on mapping guidelines.



>
> The author of that mapping did not ask for it to be included in Mixxx.
> When I was overhauling the wiki, I remember seeing this happen on some
> old forum threads too.


Yes -- this is what we have done for quite a long time. Without user
contributions our controller support would be non-existent. We make the
(quite reasonable, IMO) assumption that by posting a preset on our forums
they intend for it to be shared. Our installer and hardware support page
(or other wiki pages) describe what a "Community Mapping" is. Lastly, we
also give the author attribution in Mixxx itself when the mapping is
loaded. I think it would be hard to get too far into the process of making
a mapping without realizing that the Forum is the standard place we share
these things and that many of those shared on the forums end up distributed
with Mixxx as a Community Mapping.

It's worth noting that in nearly decade of doing this (wow -- time flies)
we haven't received a complaint of the type you're describing. I'm inclined
to say that we're doing OK on this front.

Thanks for the input (and your work in general! the wiki is in the best
shape it's ever been),
RJ



>
> On 11/19/2015 12:03 PM, RJ Ryan wrote:
> > I would prefer that we not collect signatures for preset contributors.
> > The reasons being that it will be hard to disentangle "real copyright
> > owners of the Mixxx codebase" from "people whose files we are
> > distributing with Mixxx" if we ever need to in the future.  They are
> > very different in legal standing!
> >
> > If the installer is unclear, we should add the text:  "All community
> > presets bundled with the permission of their respective authors. Consult
> > the preset file for licensing details or EULA."
> >
> >
> >
> >
> > On Thu, Nov 19, 2015 at 8:11 AM, Owen Williams  > > wrote:
> >
> >
> > ok I posted the link to 

Re: [Mixxx-devel] controller mapping guidelines

[RJ Ryan]

Hi Be,

On Thu, Nov 19, 2015 at 6:16 PM, Be  wrote:

> I'm concerned about having mapping developers not be involved in the
> development workflow. How can we expect mappings to be maintained and keep
> up with new features in Mixxx if they aren't? Moreover, how can we expect
> them to be documented? There are many undocumented mappings included in
> Mixxx that were made for versions that are now very old.


I'm totally with you -- but I think we have to acknowledge that some people
don't care that much about Mixxx (say it ain't so!). They got their preset
working and had just enough try-hard left to post about it on the forums.

This is ultimately a trade-off curve between mapping coverage and quality.
So far we've skewed more towards coverage. I agree that once the project
has grown to a certain size we will have the luxury of rejecting
contributions but as far as I'm concerned, the biggest problem we have
(which is backed up by data we collect in our yearly surveys) is lack of
support for devices. (not that we ship a broken mapping -- we just simply
don't have a mapping)

So -- to re-summarize my position -- for people who are closer to developer
on the side of the spectrum and have the willingness to give up some time
to get the tools installed, learn how to use them, obey our spec as
published, and then go through a few rounds of code review -- I think
that's great! If we get enough of those people involved then our device
support would be in great shape. We could create a new class of preset
"Community Gold Presets" which are those maintained on GitHub that have a
test suite and pass Mixxx's preset guidelines to incentivize it and maybe
give out badges or send people stickers/tshirts in the mail or something
like that.

But I think we're not yet in the position to have the luxury of turning
away mappings that are shared and reported by a few users to work but don't
happen to be high in code quality. Usually it's hard enough to get people
to fill out the  section with contact info, a Wiki and forum ink
(which I usually do ask people if they're up for doing but I do it myself
if they are not).



> Who knows if they work with current versions?


We take a lot of care on the C++-side to not break backwards compatibility.
I'm quite stern about this. Not that it doesn't happen in some cases.



> Cloning a git repo, committing two files, writing a wiki page, and opening
> a pull request is not a high bar. IMO it is lower than the bar required to
> write a mapping.


Given that you can create and export a working preset with nothing but the
Mixxx GUI-- I'm going to have to call BS on this. :)

It's hard to put yourself back in the beginner mindset -- but Git is really
freaking hard to use! Take Sean for example (sorry Sean). When we switched
to git it became a major obstacle to him contributing and he's a core
developer who's been around for many years. He's only just now (as in this
week) learning it!

Also -- understood that the plans aren't done yet -- but JSHint and other
tools require Node -- which a whole other set of skills you're requiring
(and thereby losing people to).



> I think your concern is nothing to be worried about considering all the
> high quality mappings that have been merged recently since I started
> improving the documentation. If this leaves out some low quality/incomplete
> mappings, IMO that is good. When a mapping is included in Mixxx, that gives
> the impression that it works well with Mixxx and spending money on that
> device is a wise decision. I doubt many people who buy a device with the
> intention of using it with Mixxx that find that it doesn't actually work
> well are going to continue using or contributing to Mixxx. I think
> including bad mappings is worse than not including anything.
>
> I think what really excludes a large portion of the user base from
> contributing is the clunkiness of the mapping system and the lack of
> guidelines. So far, every mapping author has figured out their own way of
> doing things, which has resulted in a lot of unnecessarily duplicated work.
> Most mapping authors are not JavaScript experts and only know the mapping
> system well enough to get by, so the approaches they have taken are of
> varying quality/readability/maintainability. Hence, why I will start a JS
> library to make mapping easier and more intuitive.


Providing a nice library sounds great! And building an easier to use
mapping system would also be great. I'm really thankful you're working to
improve things here.

Best regards,
RJ



>
> On 11/19/2015 07:36 PM, RJ Ryan wrote:
>
>> Hi Be / Tuukka,
>>
>> Sorry for missing this discussion. This is a great topic to have
>> guidelines around.
>>
>> I'm concerned about expecting the preset contributor to be involved in
>> our development workflow (Git, GitHub). This is a high bar that's going
>> to exclude a large portion of our user base from participating.
>>
>> The way we have functioned for years now is 

Re: [Mixxx-devel] controller mapping guidelines

[Be]

I'm concerned about having mapping developers not be involved in the 
development workflow. How can we expect mappings to be maintained and 
keep up with new features in Mixxx if they aren't? Moreover, how can we 
expect them to be documented? There are many undocumented mappings 
included in Mixxx that were made for versions that are now very old. Who 
knows if they work with current versions? They certainly don't use new 
features. Who knows how they work if they are not documented? Who knows 
if they're even complete? Users should be able to easily tell before 
they buy a controller how it will work with Mixxx so they can make an 
informed decision about what to get.

Cloning a git repo, committing two files, writing a wiki page, and 
opening a pull request is not a high bar. IMO it is lower than the bar 
required to write a mapping. I think your concern is nothing to be 
worried about considering all the high quality mappings that have been 
merged recently since I started improving the documentation. If this 
leaves out some low quality/incomplete mappings, IMO that is good. When 
a mapping is included in Mixxx, that gives the impression that it works 
well with Mixxx and spending money on that device is a wise decision. I 
doubt many people who buy a device with the intention of using it with 
Mixxx that find that it doesn't actually work well are going to continue 
using or contributing to Mixxx. I think including bad mappings is worse 
than not including anything.

I think what really excludes a large portion of the user base from 
contributing is the clunkiness of the mapping system and the lack of 
guidelines. So far, every mapping author has figured out their own way 
of doing things, which has resulted in a lot of unnecessarily duplicated 
work. Most mapping authors are not JavaScript experts and only know the 
mapping system well enough to get by, so the approaches they have taken 
are of varying quality/readability/maintainability. Hence, why I will 
start a JS library to make mapping easier and more intuitive.

On 11/19/2015 07:36 PM, RJ Ryan wrote:
> Hi Be / Tuukka,
>
> Sorry for missing this discussion. This is a great topic to have
> guidelines around.
>
> I'm concerned about expecting the preset contributor to be involved in
> our development workflow (Git, GitHub). This is a high bar that's going
> to exclude a large portion of our user base from participating.
>
> The way we have functioned for years now is that users post presets on
> our forums and we do some legwork to bundle them with Mixxx if they
> aren't sending us merge requests directly. I don't think we should stop
> that but instead (and what I have been doing for quite some time) is
> engage the preset developer and ask them to submit PRs -- but if that
> isn't an option for them or they aren't interested, regularly sync their
> version from them on the forums to the codebase.
>
> If there is an existing preset then we usually check that a couple of
> forum users confirm it works well. If it diverges significantly from the
> original preset functionality then we might stick it in alongside the
> existing one.
>
> In particular,
> https://github.com/mixxxdj/mixxx/pull/780
> seemed fine to me. Multiple forum users confirmed it was a valuable
> addition to the existing preset so it's pretty normal for us to include.
>
> Thanks,
> RJ
>
>
>
>
>
> On Mon, Nov 16, 2015 at 3:22 AM, Tuukka Pasanen
> > wrote:
>
> Hello,
> GIT would be best solution but probably will fail the reason you
> mentioned.. should we use pages talk-version as new stuff incubator and
> then add it to main page?
>
> Tuukka
>
> 13.11.2015, 09:06, Be kirjoitti:
> > Interesting idea, but I'm concerned that requiring people to do more
> > work to update the wiki would keep people away from contributing to
> > the wiki more.
> >
> > On 11/13/2015 01:01 AM, Tuukka Pasanen wrote:
> >> Hello,
> >> Dokuwiki also have markdown support with plugin so should we have
> >> 'original' in github as rst-file (If we like translations also). Then 
> we
> >> could have these as base for Dokuwiki then use normal Pull Requests to
> >> update those. Little bit double effort but as Be said more qualified
> >> documentation but can be automated with script? Because how many edits
> >> regular Dokuwiki than Be? Because without good documentation 
> application
> >> like Mixxx is unusable and it won't conquer world.
> >>
> >> Thanks,
> >> Tuukka
> >>
>
>
> 
> --
> Presto, an open source distributed SQL query engine for big data,
> initially
> developed by Facebook, enables you to easily query your data on
> Hadoop in a
> more interactive manner. Teradata is also now providing full enterprise
> support for Presto. Download a free open 

Re: [Mixxx-devel] controller mapping guidelines

[Be]

On 11/19/2015 08:47 PM, RJ Ryan wrote:
> Hi Be,
>
> On Thu, Nov 19, 2015 at 6:16 PM, Be >
> wrote:
>
> I'm concerned about having mapping developers not be involved in the
> development workflow. How can we expect mappings to be maintained
> and keep up with new features in Mixxx if they aren't? Moreover, how
> can we expect them to be documented? There are many undocumented
> mappings included in Mixxx that were made for versions that are now
> very old.
>
>
> I'm totally with you -- but I think we have to acknowledge that some
> people don't care that much about Mixxx (say it ain't so!). They got
> their preset working and had just enough try-hard left to post about it
> on the forums.

There isn't much of a trade off. In the last couple of months, since I 
have been asking everyone who posts a completed mapping on the forum to 
submit a pull request, I only recall one person who declined to do so. 
That was for a little-known device that frankly I'm not too concerned 
about (http://mixxx.org/forums/viewtopic.php?f=7=7448 ). If someone 
put the effort into making a mapping and sharing it with the world 
online, they're usually interested enough to open a pull request and 
have it reviewed.

I think you've mistaken people's confusion because of the lack of 
documentation and guidance for laziness. Make it easy to contribute, and 
contributors will come. That does not mean quality has to suffer. This 
has already been happening the last couple months.

> This is ultimately a trade-off curve between mapping coverage and
> quality. So far we've skewed more towards coverage. I agree that once
> the project has grown to a certain size we will have the luxury of
> rejecting contributions but as far as I'm concerned, the biggest problem
> we have (which is backed up by data we collect in our yearly surveys) is
> lack of support for devices. (not that we ship a broken mapping -- we
> just simply don't have a mapping)

How do you know that they don't consider broken mappings as an 
unsupported device? Where are the results of these surveys and who 
participates in them? Are you only thinking about current users? What 
about users who might use Mixxx if it worked with their hardware?

If I spent hundreds of dollars on a device that was supposedly supported 
by software but was really only kinda supported, I'd consider it 
effectively unsupported and be frustrated. I think most people in that 
situation would forget about Mixxx and just use the proprietary software 
the controller was designed for.

Also, what devices do people want supported? IMO it is a big problem 
that Mixxx lacks much support for popular brands that make quality 
hardware that is commercially available today. ~3/4 mappings in Mixxx 
are for devices that have been discontinued. Where is the support for 
contemporary Native Instruments, Pioneer, Akai, and DJ Tech Tools 
controllers? Write the documentation, and people step up to do the work. 
The HID mapping system is still undocumented years after it was 
implemented (Sean mentioned he could write documentation for it on IRC 
last night). Source code is not documentation.

> So -- to re-summarize my position -- for people who are closer to
> developer on the side of the spectrum and have the willingness to give
> up some time to get the tools installed, learn how to use them, obey our
> spec as published, and then go through a few rounds of code review -- I
> think that's great! If we get enough of those people involved then our
> device support would be in great shape. We could create a new class of
> preset "Community Gold Presets" which are those maintained on GitHub
> that have a test suite and pass Mixxx's preset guidelines to incentivize
> it and maybe give out badges or send people stickers/tshirts in the mail
> or something like that.
>
> But I think we're not yet in the position to have the luxury of turning
> away mappings that are shared and reported by a few users to work but
> don't happen to be high in code quality. Usually it's hard enough to get
> people to fill out the  section with contact info, a Wiki and
> forum ink (which I usually do ask people if they're up for doing but
> do it myself if they are not).

To summarize my position, there is no point to including dubious quality 
mappings in Mixxx. Users can go search the forum for those. Being 
included in Mixxx should be an indication that the controller can 
actually be used well with Mixxx.

> Cloning a git repo, committing two files, writing a wiki page, and
> opening a pull request is not a high bar. IMO it is lower than the
> bar required to write a mapping.
>
>
> Given that you can create and export a working preset with nothing but
> the Mixxx GUI-- I'm going to have to call BS on this. :)

Given that you can't actually use that to make a fully (or even close to 
fully) functioning mapping for most controllers available today and 
would have to 

Re: [Mixxx-devel] controller mapping guidelines

[Be]

This Docuwiki plugin looks helpful: 
https://www.dokuwiki.org/plugin:discussion

On 11/16/2015 05:22 AM, Tuukka Pasanen wrote:
> Hello,
> GIT would be best solution but probably will fail the reason you
> mentioned.. should we use pages talk-version as new stuff incubator and
> then add it to main page?
>
> Tuukka
>
> 13.11.2015, 09:06, Be kirjoitti:
>> Interesting idea, but I'm concerned that requiring people to do more
>> work to update the wiki would keep people away from contributing to
>> the wiki more.
>>
>> On 11/13/2015 01:01 AM, Tuukka Pasanen wrote:
>>> Hello,
>>> Dokuwiki also have markdown support with plugin so should we have
>>> 'original' in github as rst-file (If we like translations also). Then we
>>> could have these as base for Dokuwiki then use normal Pull Requests to
>>> update those. Little bit double effort but as Be said more qualified
>>> documentation but can be automated with script? Because how many edits
>>> regular Dokuwiki than Be? Because without good documentation application
>>> like Mixxx is unusable and it won't conquer world.
>>>
>>> Thanks,
>>> Tuukka
>>>
>

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

[Mixxx-devel] version of manual on the website

[Be]

http://mixxx.org/manual/1.12/ is out of date. How can it be updated? Can 
the build server build new manual HTML with each commit to the manual?

--
___
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] version of manual on the website

[RJ Ryan]

Manual publishes for 2.0 now go to:
http://mixxx.org/manual/2.0

Publishing on each commit would be nice... I'll see if I can get that
working.


On Thu, Nov 19, 2015 at 11:21 PM, Be  wrote:

> http://mixxx.org/manual/1.12/ is out of date. How can it be updated? Can
> the build server build new manual HTML with each commit to the manual?
>
>
> --
> ___
> 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
>
--
___
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] [Fwd: Re: [mixxx] Incorporate new mapping from bestdani on the forums. Thanks! (#780)]

[Sean M. Pappalardo - D.J. Pegasus]

On 11/19/2015 07:10 AM, Owen Williams wrote:
> do we need to get this forum user to sign the contributor agreement?
> Controller stuff is always hazy for me

The main reason for that agreement is to allow us to make license
changes to the source code if needed without having to track down every
past developer to get their permission. Since controller presets are
sort of "at arm's length" (not compiled in, just distributed with the
application,) they can have their own licenses. So we really just need
permission to distribute them with the application, since if we ever
change the application's license, it wouldn't necessarily apply to the
controller presets themselves.

That said, it wouldn't hurt to have preset writers sign the agreement
because it would avoid any future confusion. It's just not required.

IANAL so correct me if any of this is wrong.

Sincerely,
Sean M. Pappalardo
"D.J. Pegasus"
Mixxx Developer - Controller Specialist



smime.p7s
Description: S/MIME Cryptographic Signature
--
___
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] [Fwd: Re: [mixxx] Incorporate new mapping from bestdani on the forums. Thanks! (#780)]

[Sébastien BLAISOT]

 

from a phylosophical point of vue, the presets are bundled inside our
packages/installers and the licence agremment attached to that
package/installer doesn't make any difference between mapping and core
code IIRC. 

So making contributors sign the agreement doesn't hurt and avoid future
question that can be directed to this bundling. 

---

Sébastien Blaisot 

Le 19/11/2015 16:37, Sean M. Pappalardo - D.J. Pegasus a écrit : 

> On 11/19/2015 07:10 AM, Owen Williams wrote: 
> 
>> do we need to get this forum user to sign the contributor agreement?
>> Controller stuff is always hazy for me
> 
> The main reason for that agreement is to allow us to make license
> changes to the source code if needed without having to track down every
> past developer to get their permission. Since controller presets are
> sort of "at arm's length" (not compiled in, just distributed with the
> application,) they can have their own licenses. So we really just need
> permission to distribute them with the application, since if we ever
> change the application's license, it wouldn't necessarily apply to the
> controller presets themselves.
> 
> That said, it wouldn't hurt to have preset writers sign the agreement
> because it would avoid any future confusion. It's just not required.
> 
> IANAL so correct me if any of this is wrong.
> 
> Sincerely,
> Sean M. Pappalardo
> "D.J. Pegasus"
> Mixxx Developer - Controller Specialist
> 
> --
>  
> 
> ___
> Get Mixxx, the #1 Free MP3 DJ Mixing software Today
> http://mixxx.org [1]
> 
> Mixxx-devel mailing list
> Mixxx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mixxx-devel [2]
 

Links:
--
[1] http://mixxx.org
[2] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
--
___
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