Re: [Mixxx-devel] infrastructure modernization

[Lets talk about the music - talk show]

Can someone please remove me from this forum? I am no longer instead in
using Mixxx.

Your board is too confusing and I have no clue what your talking about in
the forum to make your board work.

Please remove me.

Thanks

On Dec 31, 2017 9:21 AM, "Be"  wrote:

> I can't sign up without an invitation either. Daniel, I think you need to
> edit this setting:
> https://zulipchat.com/help/allow-anyone-to-join-without-an-invitation
>
> On 12/31/2017 03:32 AM, Ferran Pujol Camins wrote:
>
>> I need an invitation to say hi :)
>>
>> On 31 Dec 2017 10:28 a.m., "Daniel Schürmann" > > wrote:
>>
>> Hi Ferran,
>>
>> we are currently evaluating
>> https://mixxx.zulipchat.com/
>>
>> Just got thumbs up for a FOSS free hosting plan.
>>
>> Kind regards,
>>
>> Daniel
>>
>>
>>
>> Am 31.12.2017 um 10:16 schrieb Ferran Pujol Camins:
>>
>>> It's ironic that to read this conversation I've needed to look
>>> into four different email threads. Now I'm not even sure this is
>>> the last one.
>>>
>>> I Just wanted to add that if we move from email to a new tool as
>>> our main communication channel, we should make sure that the new
>>> tool has a good mobile app. Also that people not wanting to
>>> install yet another app can get a reasonable good experience with
>>> mail alerts.
>>>
>>> On 19 Nov 2017 12:36 p.m., "Daniel Schürmann" >> > wrote:
>>>
>>> Am 19.11.2017 um 11:46 schrieb Josep Maria Antolin:
>>>

 [...]

 I think it could be really helpful to make a GitLab
 repository for controller mappings. We could use its
 issue tracker to take requests for controller mappings so
 users could vote for mappings they want. That would give
 us data on what hardware is important to map, which could
 guide us on what to ask manufacturers for and/or what to
 spend donations on.


 As we did it for manuals, we may split out mappings from the
 main repo.
 [...]

 Now that you mention this, does Git have the concept of
 externals like Subversion has?  If it does, controllers,
 skins and manual could be separated repos and the Mixxx repo
 could use them as externals, so those that work on Mixxx have
 everything, and other contributors can focus on the manual,
 skins or controllers.

 Yes it has. We did experiment with it, but It was annoying to
>>> use.
>>>
>>>
>>> 
>>> --
>>> 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] infrastructure modernization

[Be]

Mixx's Zulip instance is now open for anyone to register:
https://mixxx.zulipchat.com/

On 12/31/2017 03:16 AM, Ferran Pujol Camins wrote:
It's ironic that to read this conversation I've needed to look into four 
different email threads. Now I'm not even sure this is the last one.


I Just wanted to add that if we move from email to a new tool as our 
main communication channel, we should make sure that the new tool has a 
good mobile app. Also that people not wanting to install yet another app 
can get a reasonable good experience with mail alerts.


On 19 Nov 2017 12:36 p.m., "Daniel Schürmann" > wrote:


Am 19.11.2017 um 11:46 schrieb Josep Maria Antolin:


[...]

I think it could be really helpful to make a GitLab repository
for controller mappings. We could use its issue tracker to
take requests for controller mappings so users could vote for
mappings they want. That would give us data on what hardware
is important to map, which could guide us on what to ask
manufacturers for and/or what to spend donations on.


As we did it for manuals, we may split out mappings from the main
repo.
[...]

Now that you mention this, does Git have the concept of externals
like Subversion has?  If it does, controllers, skins and manual
could be separated repos and the Mixxx repo could use them as
externals, so those that work on Mixxx have everything, and other
contributors can focus on the manual, skins or controllers.


Yes it has. We did experiment with it, but It was annoying to use.



--
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] infrastructure modernization

[Be]

This is why I like Zulip. Its two tiered threading model keeps 
conversations organized without the chaos of infinitely deep email threads.


As for GitLab, I still want to switch to it in the future, but for now 
it would not work for us. While they provide 50,000 minutes per month on 
their shared CI servers to public open source projects for free, those 
servers only run Linux. So we would still have to set up our own Windows 
and macOS build servers with the GitLab Runner software. However, there 
currently is not a good way to have those project-specific build servers 
make builds for merge requests from forks. This is one of the most 
highly requested features for GitLab Community Edition and it is 
assigned to their vague "Next 3-6 months" milestone, so I anticipate it 
will get implemented soonish. If people could give this issue a thumbs 
up, that would be nice:

https://gitlab.com/gitlab-org/gitlab-ce/issues/23902

On 12/31/2017 03:16 AM, Ferran Pujol Camins wrote:
It's ironic that to read this conversation I've needed to look into four 
different email threads. Now I'm not even sure this is the last one.


I Just wanted to add that if we move from email to a new tool as our 
main communication channel, we should make sure that the new tool has a 
good mobile app. Also that people not wanting to install yet another app 
can get a reasonable good experience with mail alerts.


On 19 Nov 2017 12:36 p.m., "Daniel Schürmann" > wrote:


Am 19.11.2017 um 11:46 schrieb Josep Maria Antolin:


[...]

I think it could be really helpful to make a GitLab repository
for controller mappings. We could use its issue tracker to
take requests for controller mappings so users could vote for
mappings they want. That would give us data on what hardware
is important to map, which could guide us on what to ask
manufacturers for and/or what to spend donations on.


As we did it for manuals, we may split out mappings from the main
repo.
[...]

Now that you mention this, does Git have the concept of externals
like Subversion has?  If it does, controllers, skins and manual
could be separated repos and the Mixxx repo could use them as
externals, so those that work on Mixxx have everything, and other
contributors can focus on the manual, skins or controllers.


Yes it has. We did experiment with it, but It was annoying to use.



--
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] infrastructure modernization

[Be]

I can't sign up without an invitation either. Daniel, I think you need 
to edit this setting:

https://zulipchat.com/help/allow-anyone-to-join-without-an-invitation

On 12/31/2017 03:32 AM, Ferran Pujol Camins wrote:

I need an invitation to say hi :)

On 31 Dec 2017 10:28 a.m., "Daniel Schürmann" > wrote:


Hi Ferran,

we are currently evaluating
https://mixxx.zulipchat.com/

Just got thumbs up for a FOSS free hosting plan.

Kind regards,

Daniel



Am 31.12.2017 um 10:16 schrieb Ferran Pujol Camins:

It's ironic that to read this conversation I've needed to look
into four different email threads. Now I'm not even sure this is
the last one.

I Just wanted to add that if we move from email to a new tool as
our main communication channel, we should make sure that the new
tool has a good mobile app. Also that people not wanting to
install yet another app can get a reasonable good experience with
mail alerts.

On 19 Nov 2017 12:36 p.m., "Daniel Schürmann" > wrote:

Am 19.11.2017 um 11:46 schrieb Josep Maria Antolin:


[...]

I think it could be really helpful to make a GitLab
repository for controller mappings. We could use its
issue tracker to take requests for controller mappings so
users could vote for mappings they want. That would give
us data on what hardware is important to map, which could
guide us on what to ask manufacturers for and/or what to
spend donations on.


As we did it for manuals, we may split out mappings from the
main repo.
[...]

Now that you mention this, does Git have the concept of
externals like Subversion has?  If it does, controllers,
skins and manual could be separated repos and the Mixxx repo
could use them as externals, so those that work on Mixxx have
everything, and other contributors can focus on the manual,
skins or controllers.


Yes it has. We did experiment with it, but It was annoying to
use.



--
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] infrastructure modernization

[Sébastien Blaisot]

>> Hi Ferran,
>>
>> we are currently evaluating
>> https://mixxx.zulipchat.com/ 

> I need an invitation to say hi :)

So do I ;)

--
Sébastien
--
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] infrastructure modernization

[Ferran Pujol Camins]

I need an invitation to say hi :)

On 31 Dec 2017 10:28 a.m., "Daniel Schürmann"  wrote:

> Hi Ferran,
>
> we are currently evaluating
> https://mixxx.zulipchat.com/
>
> Just got thumbs up for a FOSS free hosting plan.
>
> Kind regards,
>
> Daniel
>
>
>
> Am 31.12.2017 um 10:16 schrieb Ferran Pujol Camins:
>
> It's ironic that to read this conversation I've needed to look into four
> different email threads. Now I'm not even sure this is the last one.
>
> I Just wanted to add that if we move from email to a new tool as our main
> communication channel, we should make sure that the new tool has a good
> mobile app. Also that people not wanting to install yet another app can get
> a reasonable good experience with mail alerts.
>
> On 19 Nov 2017 12:36 p.m., "Daniel Schürmann"  wrote:
>
>> Am 19.11.2017 um 11:46 schrieb Josep Maria Antolin:
>>
>>
>> [...]
>>
>>> I think it could be really helpful to make a GitLab repository for
>>> controller mappings. We could use its issue tracker to take requests for
>>> controller mappings so users could vote for mappings they want. That would
>>> give us data on what hardware is important to map, which could guide us on
>>> what to ask manufacturers for and/or what to spend donations on.
>>>
>>
>> As we did it for manuals, we may split out mappings from the main repo.
>> [...]
>>
>> Now that you mention this, does Git have the concept of externals like
>> Subversion has?  If it does, controllers, skins and manual could be
>> separated repos and the Mixxx repo could use them as externals, so those
>> that work on Mixxx have everything, and other contributors can focus on the
>> manual, skins or controllers.
>>
>>
>> Yes it has. We did experiment with it, but It was annoying to use.
>>
>> 
>> --
>> 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] infrastructure modernization

[Daniel Schürmann]

Hi Ferran,

we are currently evaluating
https://mixxx.zulipchat.com/

Just got thumbs up for a FOSS free hosting plan.

Kind regards,

Daniel



Am 31.12.2017 um 10:16 schrieb Ferran Pujol Camins:
It's ironic that to read this conversation I've needed to look into 
four different email threads. Now I'm not even sure this is the last one.


I Just wanted to add that if we move from email to a new tool as our 
main communication channel, we should make sure that the new tool has 
a good mobile app. Also that people not wanting to install yet another 
app can get a reasonable good experience with mail alerts.


On 19 Nov 2017 12:36 p.m., "Daniel Schürmann" > wrote:


Am 19.11.2017 um 11:46 schrieb Josep Maria Antolin:


[...]

I think it could be really helpful to make a GitLab
repository for controller mappings. We could use its issue
tracker to take requests for controller mappings so users
could vote for mappings they want. That would give us data on
what hardware is important to map, which could guide us on
what to ask manufacturers for and/or what to spend donations on.


As we did it for manuals, we may split out mappings from the main
repo.
[...]

Now that you mention this, does Git have the concept of externals
like Subversion has?  If it does, controllers, skins and manual
could be separated repos and the Mixxx repo could use them as
externals, so those that work on Mixxx have everything, and other
contributors can focus on the manual, skins or controllers.


Yes it has. We did experiment with it, but It was annoying to use.



--
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] infrastructure modernization

[Ferran Pujol Camins]

It's ironic that to read this conversation I've needed to look into four
different email threads. Now I'm not even sure this is the last one.

I Just wanted to add that if we move from email to a new tool as our main
communication channel, we should make sure that the new tool has a good
mobile app. Also that people not wanting to install yet another app can get
a reasonable good experience with mail alerts.

On 19 Nov 2017 12:36 p.m., "Daniel Schürmann"  wrote:

> Am 19.11.2017 um 11:46 schrieb Josep Maria Antolin:
>
>
> [...]
>
>> I think it could be really helpful to make a GitLab repository for
>> controller mappings. We could use its issue tracker to take requests for
>> controller mappings so users could vote for mappings they want. That would
>> give us data on what hardware is important to map, which could guide us on
>> what to ask manufacturers for and/or what to spend donations on.
>>
>
> As we did it for manuals, we may split out mappings from the main repo.
> [...]
>
> Now that you mention this, does Git have the concept of externals like
> Subversion has?  If it does, controllers, skins and manual could be
> separated repos and the Mixxx repo could use them as externals, so those
> that work on Mixxx have everything, and other contributors can focus on the
> manual, skins or controllers.
>
>
> Yes it has. We did experiment with it, but It was annoying to use.
>
> 
> --
> 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] infrastructure modernization

[Daniel Schürmann]

Am 19.11.2017 um 11:46 schrieb Josep Maria Antolin:


[...]

I think it could be really helpful to make a GitLab repository for
controller mappings. We could use its issue tracker to take
requests for controller mappings so users could vote for mappings
they want. That would give us data on what hardware is important
to map, which could guide us on what to ask manufacturers for
and/or what to spend donations on.


As we did it for manuals, we may split out mappings from the main repo.
[...]

Now that you mention this, does Git have the concept of externals like 
Subversion has?  If it does, controllers, skins and manual could be 
separated repos and the Mixxx repo could use them as externals, so 
those that work on Mixxx have everything, and other contributors can 
focus on the manual, skins or controllers.



Yes it has. We did experiment with it, but It was annoying to use.

--
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] infrastructure modernization

[Josep Maria Antolin]

[...]

> I think it could be really helpful to make a GitLab repository for
> controller mappings. We could use its issue tracker to take requests for
> controller mappings so users could vote for mappings they want. That would
> give us data on what hardware is important to map, which could guide us on
> what to ask manufacturers for and/or what to spend donations on.
>

As we did it for manuals, we may split out mappings from the main repo.
[...]

Now that you mention this, does Git have the concept of externals like
Subversion has?  If it does, controllers, skins and manual could be
separated repos and the Mixxx repo could use them as externals, so those
that work on Mixxx have everything, and other contributors can focus on the
manual, skins or controllers.
--
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] infrastructure modernization

[Be]

On 11/18/2017 03:24 PM, Daniel Schürmann wrote:
It is reasonable to distinguish 
between user support and bug tracking like we do with forums and 
Launchpad.


On IRC we have one combined channel for development and user support. On 
Zulip we can easily separate development chat and user support, so 
developers who only want to focus on development can do so. Having the 
chat streams so close together would also make it easy for newcomers to 
get involved in development.


--
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] infrastructure modernization

[Be]

On 11/18/2017 03:24 PM, Daniel Schürmann wrote:

Hi Be,

It's just as unreasonable to expect new contributors to sign up for 7 
different accounts (GitHub, IRC, phpBB, Freenode, mailing list, 
Launchpad, wiki) as it is to expect long time developers to pay 
attention to all of them. It would be easier if there were less things 
to pay attention to.


Yes sure. Sean is working on it. But It is reasonable to distinguish 
between user support and bug tracking like we do with forums and 
Launchpad. User support can help each others, contributors can jump in 
for unsupported use cases or bugs, that should be then tracked in a 
different domain.


Yes, it is good to distinguish between those, but often times the line 
is blurry. Often users come asking for support but they have actually 
encountered a bug. It would be nice to easily move a conversation from 
user support to the bug tracker in GitLab. GitLab also makes it easy to 
move conversations from code review to the bug tracker as well as other 
features that would make code review nicer. Please look through

https://docs.gitlab.com/ce/user/discussions/



Looking dated is important. Newcomers are telling us in no uncertain 
terms that they don't want to use Launchpad and by and large they 
aren't. What features Launchpad has are irrelevant if people don't use 
them.


Yes, right. But I am in doubt that this is a impossible hurdle.
Remember, the user asks for free support.


The bigger issue than the old fashioned design is requiring to register 
an account on a little known platform that has been in decline for 
years. Then when a user goes to sign up for Launchpad to report a bug 
for Mixxx, they're brought to a page that says "One account to log in to 
everything on Ubuntu". The sign on/register page says nothing about 
Mixxx or even Launchpad and has a totally different look and feel from 
Launchpad. That is confusing and I suspect turns away people who have no 
idea what Ubuntu is, or do know what Ubuntu is and don't trust it (see 
https://en.wikipedia.org/wiki/Ubuntu_(operating_system)#Amazon_controversy 
), or do like Ubuntu but get confused why they're suddenly at a page 
that says nothing about Mixxx or Launchpad. This is a bad user experience.


Can you elaborate on "has more bug states than just open and close"? 
What else is needed? GitHub and GitLab both have project-defined tags 
that can be used for further organization. GitLab allows projects to 
define priorities for custom tags.

...


This gives an explicit info about the bug state during it's live time.
We may use Label/Tags for it but than we loose the original tagging 
feature, we use for group bugs under a topic. Or we mix both state and 
loose a lot of clarity. If we than add additional tags for blueprints, 
we use a single feature for tree purposes, which is at least a 
regression compared to Launchpad.

...
> GitLab has a little more issue states.
> The bug states request was rejected in favour of the dashboard:
> https://gitlab.com/gitlab-org/gitlab-ce/issues/17186

I agree, it is nice to have a dedicated field for that apart from other 
tags. But I do not think it is essential. I am interested in trying 
GitLab's issue board solution.



The GitLab dashboard is only for registerd users with access right > I do not 
have discovered it for GitHub
If you compare the Homepages, you will see the difference:
https://github.com/mixxxdj
https://gitlab.com/inkscape/
https://launchpad.net/mixxx
Launchpad is more user focussed and giving the best overview.


I do not know why you can't see the issue board for Inkscape. Perhaps 
they haven't enabled the feature for their organization. But I can see 
it for the GitLab server software:

https://gitlab.com/gitlab-org/gitlab-ce/boards

I think it could be really helpful to make a GitLab repository for 
controller mappings. We could use its issue tracker to take requests 
for controller mappings so users could vote for mappings they want. 
That would give us data on what hardware is important to map, which 
could guide us on what to ask manufacturers for and/or what to spend 
donations on.


As we did it for manuals, we may split out mappings from the main repo.


Yes, and GitLab makes it easy to cross reference and move issues between 
repositories within an organization. This could help with the issue of 
keeping the manual updated as new features get developed without having 
to keep it in the same Git repository. Milestones in GitLab can be 
defined at the organization level and shared between all the 
organization's repositories.


FWIW, GitLab allows importing from GitHub Issues. We could do a 
roundabout import from Launchpad to GitHub then GitHub to GitLab.

https://docs.gitlab.com/ce/user/project/import/github.html


This sounds the same as compressing and mp3 with aac :-P


Yeah, I suspect there would be information lost in an annoying way. We 
could try it anyway, or alternatively we could start the issue tracker 
fresh after the 

Re: [Mixxx-devel] infrastructure modernization

[Be]

Yes, Zulip has that. Also, every conversation is organized into its own 
thread within a Stream. I encourage you to try it out on Zulip's own 
Zulip instance:

https://chat.zulip.org/

On 11/18/2017 03:42 PM, Stéphane Lepin wrote:

Does Zulip has several channels like its counterpart Slack?
Because the lack of several sub-channels per project is Gitter's biggest 
drawback to me. It's not much of an issue for small projects, but a big 
project like Mixxx can benefit from several sub-channels under the same 
"server".


2017-11-17 20:59 GMT+01:00 Be >:

On 11/17/2017 10:18 AM, Sean M. Pappalardo - D.J. Pegasus wrote:>>
We have hundreds cross linkes, between GitHub, Forum, Wiki, and

Launchpad. Losing this had to be well considered compared to
some
missing convenient features.


I totally agree. Never mind the work it would take to do a
migration,
work that would be better spent on Mixxx itself, IMO.

So the question is: how much more productive would we be if bug and
blueprint tracking was integrated with code hosting? Put another
way,
how much is the current separation impairing productivity?

(Keep in mind that Launchpad supports Git now, so it would be
possible
to move code hosting back there, solving this particular concern.)


IMO our biggest issue as a project is a lack of labor. Here we have
a skilled, motivated new developer coming to us asking why we're
still using such fragmented and outdated infrastructure. This is
coming concurrently with a thread on the forum with several people
asking the same question. Most new contributors lately have been
asking this as well. This should be a giant red flag! We must
modernize our infrastructure soon or we will not attract and retain
contributors. I do not think it is a question of whether we should
migrate, it is only a question of what to migrate to.

IMO having to host our own server for project management is
practically a non-starter. There's no need to take on this burden,
especially consider our scarce labor resources. Which pretty much
leaves us with either GitHub or GitLab. I think we should consider
the trajectory of each company and software. GitHub was the first to
do Git hosting right and has become by far the most popular. But I
am not such a fan of the way they treat their users. It is ironic
that a company that thrives on open source repeatedly ignored the
community so badly for years that it took a widely publicized open
letter ( https://github.com/dear-github/dear-github
 ) to get them to budge
to implement highly requested features for Issues. They still have
no transparent feature request or development process. Requests for
GitHub get sent into the void of their official support channel and
are not publicized and rarely acted upon.

On the other hand, GitLab is growing very rapidly and shining where
GitHub is stagnating. Their issue tracker for the server software is
public and they receive many code contributions to the server
software from the community. They are very actively engaged with
their users and receptive to feedback. Prominent open source
projects are switching to GitLab, such as Debian, GNOME, Inkscape.
The company is relatively small but they recently received a lot of
capital investment and seem to be putting it to good use improving
their performance and adding new features.

A lot, if not most, of the stuff on our Launchpad bug tracker is old
noise with incomplete information. This is not so much a fault of
Launchpad as it is a collective fault of the project for not using
Launchpad effectively. I'm questioning if it's even worth importing
old data from Launchpad to a new system. Doing so would require
someone to spend a lot of time manually going through ~1500ish old
bugs and deciding what to do with them. If we start with a clean
slate, define a workflow for handling issues, and stick to that
process, important bugs that still exist in the current code will be
reported and taken care of.


Filing Bug inside Mixxx would be the most convenient solution.


Sure. The only problem is that we would have no way to
communicate back
to the user (since the bug filer would be a bot account) without
having
to create a separate E-mail thread. That would be quite a step
backwards, especially since it's not hard (anymore) to create an LP
account. (Plus if we make it too easy to file, we'll get
low-quality bug
reports.)


Automated crash reporting with backtraces would be helpful, but I'm
pretty sure building general bug reporting into the application
would lower the 

Re: [Mixxx-devel] infrastructure modernization (was: launchpad bugtracker)

[Stéphane Lepin]

Does Zulip has several channels like its counterpart Slack?
Because the lack of several sub-channels per project is Gitter's biggest
drawback to me. It's not much of an issue for small projects, but a big
project like Mixxx can benefit from several sub-channels under the same
"server".

2017-11-17 20:59 GMT+01:00 Be :

> On 11/17/2017 10:18 AM, Sean M. Pappalardo - D.J. Pegasus wrote:>> We have
> hundreds cross linkes, between GitHub, Forum, Wiki, and
>
>> Launchpad. Losing this had to be well considered compared to some
>>> missing convenient features.
>>>
>>
>> I totally agree. Never mind the work it would take to do a migration,
>> work that would be better spent on Mixxx itself, IMO.
>>
>> So the question is: how much more productive would we be if bug and
>> blueprint tracking was integrated with code hosting? Put another way,
>> how much is the current separation impairing productivity?
>>
>> (Keep in mind that Launchpad supports Git now, so it would be possible
>> to move code hosting back there, solving this particular concern.)
>>
>
> IMO our biggest issue as a project is a lack of labor. Here we have a
> skilled, motivated new developer coming to us asking why we're still using
> such fragmented and outdated infrastructure. This is coming concurrently
> with a thread on the forum with several people asking the same question.
> Most new contributors lately have been asking this as well. This should be
> a giant red flag! We must modernize our infrastructure soon or we will not
> attract and retain contributors. I do not think it is a question of whether
> we should migrate, it is only a question of what to migrate to.
>
> IMO having to host our own server for project management is practically a
> non-starter. There's no need to take on this burden, especially consider
> our scarce labor resources. Which pretty much leaves us with either GitHub
> or GitLab. I think we should consider the trajectory of each company and
> software. GitHub was the first to do Git hosting right and has become by
> far the most popular. But I am not such a fan of the way they treat their
> users. It is ironic that a company that thrives on open source repeatedly
> ignored the community so badly for years that it took a widely publicized
> open letter ( https://github.com/dear-github/dear-github ) to get them to
> budge to implement highly requested features for Issues. They still have no
> transparent feature request or development process. Requests for GitHub get
> sent into the void of their official support channel and are not publicized
> and rarely acted upon.
>
> On the other hand, GitLab is growing very rapidly and shining where GitHub
> is stagnating. Their issue tracker for the server software is public and
> they receive many code contributions to the server software from the
> community. They are very actively engaged with their users and receptive to
> feedback. Prominent open source projects are switching to GitLab, such as
> Debian, GNOME, Inkscape. The company is relatively small but they recently
> received a lot of capital investment and seem to be putting it to good use
> improving their performance and adding new features.
>
> A lot, if not most, of the stuff on our Launchpad bug tracker is old noise
> with incomplete information. This is not so much a fault of Launchpad as it
> is a collective fault of the project for not using Launchpad effectively.
> I'm questioning if it's even worth importing old data from Launchpad to a
> new system. Doing so would require someone to spend a lot of time manually
> going through ~1500ish old bugs and deciding what to do with them. If we
> start with a clean slate, define a workflow for handling issues, and stick
> to that process, important bugs that still exist in the current code will
> be reported and taken care of.
>
>
>> Filing Bug inside Mixxx would be the most convenient solution.
>>>
>>
>> Sure. The only problem is that we would have no way to communicate back
>> to the user (since the bug filer would be a bot account) without having
>> to create a separate E-mail thread. That would be quite a step
>> backwards, especially since it's not hard (anymore) to create an LP
>> account. (Plus if we make it too easy to file, we'll get low-quality bug
>> reports.)
>>
>
> Automated crash reporting with backtraces would be helpful, but I'm pretty
> sure building general bug reporting into the application would lower the
> signal-to-noise ratio on the bug tracker even further.
>
>
>> We already have the "submit feedback" Google form which seems to be
>> working well as it has hundreds of responses. (I need to check on how to
>> publish them.) And indeed some are not useful.
>>
>> Launchpad offers to communicate via email. Maybe there is a solution
>>> to send Emails from Mixxx to Launchpad?
>>>
>>
> Email sucks. It dates to the very beginning of the Internet and is the
> lowest common denominator. Why is participating via email an important
> feature? 

Re: [Mixxx-devel] infrastructure modernization

[Daniel Schürmann]

Hi Be,

It's just as unreasonable to expect new contributors to sign up for 7 
different accounts (GitHub, IRC, phpBB, Freenode, mailing list, 
Launchpad, wiki) as it is to expect long time developers to pay 
attention to all of them. It would be easier if there were less things 
to pay attention to.


Yes sure. Sean is working on it. But It is reasonable to distinguish 
between user support and bug tracking like we do with forums and 
Launchpad. User support can help each others, contributors can jump in 
for unsupported use cases or bugs, that should be then tracked in a 
different domain.


Looking dated is important. Newcomers are telling us in no uncertain 
terms that they don't want to use Launchpad and by and large they 
aren't. What features Launchpad has are irrelevant if people don't use 
them.


Yes, right. But I am in doubt that this is a impossible hurdle.
Remember, the user asks for free support.

Can you elaborate on "has more bug states than just open and close"? 
What else is needed? GitHub and GitLab both have project-defined tags 
that can be used for further organization. GitLab allows projects to 
define priorities for custom tags.


* New
Not looked at yet, unconfirmed
* Incomplete
Cannot be verified, the reporter needs to give more info.
Will be closed automatically
* Opinion
Doesn't fit with the project, but can be discussed.
* Invalid
Not a bug. May be a support request or spam.
* Won't Fix
Doesn't fit with the project plans, sorry.
* Confirmed
Verified by someone other than the reporter.
* Triaged
Verified by the bug supervisor.
We use it for complete analysed bug that cannot be solved for a reason.
* In Progress
The assigned person is working on it.
* Fix Committed
Fixed, but not available until next release.
Available in the alpha
* Fix Released
The fix was released.
Available in the released version

This gives an explicit info about the bug state during it's live time.
We may use Label/Tags for it but than we loose the original tagging 
feature, we use for group bugs under a topic. Or we mix both state and 
loose a lot of clarity. If we than add additional tags for blueprints, 
we use a single feature for tree purposes, which is at least a 
regression compared to Launchpad.



Blueprints are nice but not necessary. Again, tags can be used for the 
same purpose.


Tags are not the same, they are somehow volatile. They need explanations 
to understand the purpose. In Launchpad the meaning of the field is hard 
coupled with a workflow.


I don't know what you mean. GitLab has a nice dashboard view for its 
issue tracker where you can filter by milestone and tag. You can 
drag-and-drop between tags in this view to keep issues organized. I 
think GitHub now has a similar capability too.


The GitLab dashboard is only for registerd users with access rights.
I do not have discovered it for GitHub
If you compare the Homepages, you will see the difference:
https://github.com/mixxxdj
https://gitlab.com/inkscape/
https://launchpad.net/mixxx
Launchpad is more user focussed and giving the best overview.

One of my biggest grievances with Launchpad is how the "Wishlist" marker 
is mutually exclusive with a priority designation. To me it feels like a 
slap in the face for a feature that's important to me to be designated 
with the lowest priority level. IMO there is little practical difference 
between a bug and the lack of a feature. Something that ought to get 
done is something that ought to get done. Whether it's implementing a 
useful feature or whether it's a bug doesn't matter for how important it 
is.


I can't confirm his. Launchpad has no priority field, it is am 
Importance field. We simply cannot give bugs priorities, because we 
cannot force anyone to work on critical bugs first. Every contributor 
has its own priority list and there is no higher authority which can 
change it.


I look at the Wishlist marker as an exception from Importance, since it 
is no malfunction, which is important to fix.


We can only express the opinion of the team how Important this bug is.
The same goes for milestones. We can define milestones as a term of:
"The milestone is reached when all the assigned bugs are done"
We can express which bug will be likely merge do which version, but we 
cannot stop anyone from working on other things.


I think it could be really helpful to make a GitLab repository for 
controller mappings. We could use its issue tracker to take requests for 
controller mappings so users could vote for mappings they want. That 
would give us data on what hardware is important to map, which could 
guide us on what to ask manufacturers for and/or what to spend donations 
on.


As we did it for manuals, we may split out mappings from the main repo.

The popularity of GitHub does give it an advantage, but I do not think 
it is important enough that we can't leave GitHub. 

Re: [Mixxx-devel] infrastructure modernization

[Be]

On 11/18/2017 08:30 AM, Daniel Schürmann wrote:

Hi Be,

It is not fair to blame the infra structure, for the leak of time the 
maintainers have to manage the different informations.

...
>
> The current fragmented infrastructure, has some drawbacks, but it has  a
> very big advantage. You can join discussions how your time allows.
>
> @Be: I am really happy, that you are active on all channels, thank you
> very much!
> Unfortunately, I  cannot do this because of leak of time. So I have
> decided not to join IRC and look to forums only when the time allows.

It's just as unreasonable to expect new contributors to sign up for 7 
different accounts (GitHub, IRC, phpBB, Freenode, mailing list, 
Launchpad, wiki) as it is to expect long time developers to pay 
attention to all of them. It would be easier if there were less things 
to pay attention to.



Launchpad looks somehow outdated, but the important features are there.


Looking dated is important. Newcomers are telling us in no uncertain 
terms that they don't want to use Launchpad and by and large they 
aren't. What features Launchpad has are irrelevant if people don't use them.


Especially, it shows possible duplicates when filing a bug, has more bug 
states than just open and close, has blueprints as a second way to group 
bugs in addition to milestones, the blueprints.


Can you elaborate on "has more bug states than just open and close"? 
What else is needed? GitHub and GitLab both have project-defined tags 
that can be used for further organization. GitLab allows projects to 
define priorities for custom tags.


Blueprints are nice but not necessary. Again, tags can be used for the 
same purpose.


If we assumed Launchpad is well managed (I am working on that now that I 
have permission) it gives a well structured overview for users, what the 
state of the project is. GitHub is more developers focused and does not 
offer this clarity.


I don't know what you mean. GitLab has a nice dashboard view for its 
issue tracker where you can filter by milestone and tag. You can 
drag-and-drop between tags in this view to keep issues organized. I 
think GitHub now has a similar capability too.




I am strictly against closing bugs, that are older then a certain 
deadline, because that feels like a hit in the face, for the people 
which may have investigated a significant time to file the bug. This 
happens to me in other projects and I took my consequences.


I agree. Fedora does this and it does feel like a slap in the face. Only 
bugs that are marked Incomplete should expire. Launchpad already does 
this. It would help to automatically add a friendly message warning 
about impending expiration and explaining that the issue can be reopened 
in the future if the reporter provides the required information.


One of my biggest grievances with Launchpad is how the "Wishlist" marker 
is mutually exclusive with a priority designation. To me it feels like a 
slap in the face for a feature that's important to me to be designated 
with the lowest priority level. IMO there is little practical difference 
between a bug and the lack of a feature. Something that ought to get 
done is something that ought to get done. Whether it's implementing a 
useful feature or whether it's a bug doesn't matter for how important it is.




By the way, I have loosed long finished post more than once, because of 
leak of internet connection.
Pressing "Submit" without a stable connection and you post is gone.  So 
that is really a field that could use an update.


This has happened to me with phpBB as well and it is frustrating. 
Discourse can automatically save draft posts. We may also consider 
opening a GitLab repository just for user support using GitLab's issue 
tracker. Then it would be easy to move a user support question from the 
user support repository to the main code repository's issue tracker 
without having to ask the user to make a new account or duplicate what 
they've already written.


I think it could be really helpful to make a GitLab repository for 
controller mappings. We could use its issue tracker to take requests for 
controller mappings so users could vote for mappings they want. That 
would give us data on what hardware is important to map, which could 
guide us on what to ask manufacturers for and/or what to spend donations on.




Email works very good here. I can manage my own priority list and can 
reach everyone in just a second.




I fully understand Be's concerns, and I agree that GitLab looks very 
mature.

So we are currently in this cycle:

* We want a integrated project management structure.
* We cannot leave GitHub because of the GitHub community
* We cannot move to Gitbub issues because they do not fit our 
requirements and we loose the history.


The popularity of GitHub does give it an advantage, but I do not think 
it is important enough that we can't leave GitHub. Please elaborate on 
what you don't like about GitLab's issue tracker.

Re: [Mixxx-devel] infrastructure modernization

[Gavin Swanson]

Maybe I've missed the conversation. What about GitHub issues doesn't fit
requirements?

On Sat, Nov 18, 2017, 6:30 AM Daniel Schürmann  wrote:

> Hi Be,
>
> It is not fair to blame the infra structure, for the leak of time the
> maintainers have to manage the different informations.
>
> Launchpad looks somehow outdated, but the important features are there.
> Especially, it shows possible duplicates when filing a bug, has more bug
> states than just open and close, has blueprints as a second way to group
> bugs in addition to milestones, the blueprints.
> If we assumed Launchpad is well managed (I am working on that now that I
> have permission) it gives a well structured overview for users, what the
> state of the project is. GitHub is more developers focused and does not
> offer this clarity.
>
> I am strictly against closing bugs, that are older then a certain
> deadline, because that feels like a hit in the face, for the people which
> may have investigated a significant time to file the bug. This happens to
> me in other projects and I took my consequences.
>
> The current fragmented infrastructure, has some drawbacks, but it has  a
> very big advantage. You can join discussions how your time allows.
>
> @Be: I am really happy, that you are active on all channels, thank you
> very much!
> Unfortunately, I  cannot do this because of leak of time. So I have
> decided not to join IRC and look to forums only when the time allows.
>
> By the way, I have loosed long finished post more than once, because of
> leak of internet connection.
> Pressing "Submit" without a stable connection and you post is gone.  So
> that is really a field that could use an update.
>
> Email works very good here. I can manage my own priority list and can
> reach everyone in just a second.
>
> I fully understand Be's concerns, and I agree that GitLab looks very
> mature.
> So we are currently in this cycle:
>
> * We want a integrated project management structure.
> * We cannot leave GitHub because of the GitHub community
> * We cannot move to Gitbub issues because they do not fit our requirements
> and we loose the history.
>
> :-/
>
> Kind regards,
>
> Daniel
>
>
>
>
>
> Am 18.11.2017 um 07:00 schrieb Be:
>
> On 11/17/2017 02:42 PM, Sean M. Pappalardo - D.J. Pegasus wrote:
>
> For the record, GitLab looks really interesting and exciting to me as
> well. If we were a new project, we could go there in a heartbeat. But we
> have to consider all of the not-fun practical matters and repercussions
> of migration of a large and storied existing project.
>
> On 11/17/2017 11:59 AM, Be wrote:
>
> IMO our biggest issue as a project is a lack of labor.
>
>
> Which is precisely why migrating at all would be problematic. We can
> ill-afford the labor to do it.
>
>
> I feel that the Mixxx project is in crisis and hanging by a thread. Let's
> stop making excuses for not taking action and start doing everything we can
> to make this project sustainable. We cannot afford to continue discouraging
> people from contributing by clinging to outdated, fragmented
> infrastructure.
>
>
> IMO having to host our own server for project management is practically
> a non-starter.
>
>
> What are you referring to? In the case of improving Launchpad, our work
> would be submitted upstream, to go live on Launchpad.net. We won't have
> to move or change anything, just make the existing platform better.
> Seems like the best return on effort invested to me.
>
>
> Not one person has asked for improving Launchpad. That would take an
> enormous effort which I doubt would even solve the current issues.
> Launchpad is an outdated technology with an outdated design, let's let it
> die. Trying to rescue it would be an uphill battle.
>
> On the other hand, we can join the momentum of GitLab, which has a very
> active company and community rapidly improving the server software. If
> there's something about GitLab that doesn't exactly fit what we want, we
> can file issues that actually have a chance of getting taking care of. We
> could also take care of them ourselves by sending a merge request to GitLab
> and not have to deal with hosting it ourselves.
>
>
> A lot, if not most, of the stuff on our Launchpad bug tracker is old
> noise with incomplete information.
>
>
> Please do not make sweeping assertions like this without data.
>
> In reality, 2774 (or 73.5%) of the bugs in the system are either
> confirmed (adequate information,) being worked on, or already fixed. A
> history of resolved bugs is very valuable in the case of regressions,
> similar but new occurrences, and when users search for a common problem
> they think is a bug.
>
>
> Getting good data on this would require spending quite a lot of effort to
> clean up the mess on Launchpad. For a start we have 361 "New" bugs. We have
> lots of "In Progress" bugs that have had no activity in years.
>
> I am skeptical of the importance of keeping old, resolved bugs easily
> accessible. The only 

Re: [Mixxx-devel] infrastructure modernization

[Daniel Schürmann]

Hi Be,

It is not fair to blame the infra structure, for the leak of time the 
maintainers have to manage the different informations.


Launchpad looks somehow outdated, but the important features are there.
Especially, it shows possible duplicates when filing a bug, has more bug 
states than just open and close, has blueprints as a second way to group 
bugs in addition to milestones, the blueprints.
If we assumed Launchpad is well managed (I am working on that now that I 
have permission) it gives a well structured overview for users, what the 
state of the project is. GitHub is more developers focused and does not 
offer this clarity.


I am strictly against closing bugs, that are older then a certain 
deadline, because that feels like a hit in the face, for the people 
which may have investigated a significant time to file the bug. This 
happens to me in other projects and I took my consequences.


The current fragmented infrastructure, has some drawbacks, but it has  a 
very big advantage. You can join discussions how your time allows.


@Be: I am really happy, that you are active on all channels, thank you 
very much!
Unfortunately, I  cannot do this because of leak of time. So I have 
decided not to join IRC and look to forums only when the time allows.


By the way, I have loosed long finished post more than once, because of 
leak of internet connection.
Pressing "Submit" without a stable connection and you post is gone.  So 
that is really a field that could use an update.


Email works very good here. I can manage my own priority list and can 
reach everyone in just a second.


I fully understand Be's concerns, and I agree that GitLab looks very 
mature.

So we are currently in this cycle:

* We want a integrated project management structure.
* We cannot leave GitHub because of the GitHub community
* We cannot move to Gitbub issues because they do not fit our 
requirements and we loose the history.


:-/

Kind regards,

Daniel





Am 18.11.2017 um 07:00 schrieb Be:

On 11/17/2017 02:42 PM, Sean M. Pappalardo - D.J. Pegasus wrote:

For the record, GitLab looks really interesting and exciting to me as
well. If we were a new project, we could go there in a heartbeat. But we
have to consider all of the not-fun practical matters and repercussions
of migration of a large and storied existing project.

On 11/17/2017 11:59 AM, Be wrote:

IMO our biggest issue as a project is a lack of labor.


Which is precisely why migrating at all would be problematic. We can
ill-afford the labor to do it.


I feel that the Mixxx project is in crisis and hanging by a thread. 
Let's stop making excuses for not taking action and start doing 
everything we can to make this project sustainable. We cannot afford 
to continue discouraging people from contributing by clinging to 
outdated, fragmented infrastructure.





IMO having to host our own server for project management is practically
a non-starter.


What are you referring to? In the case of improving Launchpad, our work
would be submitted upstream, to go live on Launchpad.net. We won't have
to move or change anything, just make the existing platform better.
Seems like the best return on effort invested to me.


Not one person has asked for improving Launchpad. That would take an 
enormous effort which I doubt would even solve the current issues. 
Launchpad is an outdated technology with an outdated design, let's let 
it die. Trying to rescue it would be an uphill battle.


On the other hand, we can join the momentum of GitLab, which has a 
very active company and community rapidly improving the server 
software. If there's something about GitLab that doesn't exactly fit 
what we want, we can file issues that actually have a chance of 
getting taking care of. We could also take care of them ourselves by 
sending a merge request to GitLab and not have to deal with hosting it 
ourselves.





A lot, if not most, of the stuff on our Launchpad bug tracker is old
noise with incomplete information.


Please do not make sweeping assertions like this without data.

In reality, 2774 (or 73.5%) of the bugs in the system are either
confirmed (adequate information,) being worked on, or already fixed. A
history of resolved bugs is very valuable in the case of regressions,
similar but new occurrences, and when users search for a common problem
they think is a bug.


Getting good data on this would require spending quite a lot of effort 
to clean up the mess on Launchpad. For a start we have 361 "New" bugs. 
We have lots of "In Progress" bugs that have had no activity in years.


I am skeptical of the importance of keeping old, resolved bugs easily 
accessible. The only times I remember referring to resolved bugs were 
to mark new reports as duplicates because we haven't had a release in 
2 years so people keep reporting the same critical bugs. If needed, we 
could still manually copy and paste Launchpad URLs on the new issue 
tracker on the rare occasion that would be helpful.

Re: [Mixxx-devel] infrastructure modernization

[Be]

On 11/17/2017 02:42 PM, Sean M. Pappalardo - D.J. Pegasus wrote:

For the record, GitLab looks really interesting and exciting to me as
well. If we were a new project, we could go there in a heartbeat. But we
have to consider all of the not-fun practical matters and repercussions
of migration of a large and storied existing project.

On 11/17/2017 11:59 AM, Be wrote:

IMO our biggest issue as a project is a lack of labor.


Which is precisely why migrating at all would be problematic. We can
ill-afford the labor to do it.


I feel that the Mixxx project is in crisis and hanging by a thread. 
Let's stop making excuses for not taking action and start doing 
everything we can to make this project sustainable. We cannot afford to 
continue discouraging people from contributing by clinging to outdated, 
fragmented infrastructure.





IMO having to host our own server for project management is practically
a non-starter.


What are you referring to? In the case of improving Launchpad, our work
would be submitted upstream, to go live on Launchpad.net. We won't have
to move or change anything, just make the existing platform better.
Seems like the best return on effort invested to me.


Not one person has asked for improving Launchpad. That would take an 
enormous effort which I doubt would even solve the current issues. 
Launchpad is an outdated technology with an outdated design, let's let 
it die. Trying to rescue it would be an uphill battle.


On the other hand, we can join the momentum of GitLab, which has a very 
active company and community rapidly improving the server software. If 
there's something about GitLab that doesn't exactly fit what we want, we 
can file issues that actually have a chance of getting taking care of. 
We could also take care of them ourselves by sending a merge request to 
GitLab and not have to deal with hosting it ourselves.





A lot, if not most, of the stuff on our Launchpad bug tracker is old
noise with incomplete information.


Please do not make sweeping assertions like this without data.

In reality, 2774 (or 73.5%) of the bugs in the system are either
confirmed (adequate information,) being worked on, or already fixed. A
history of resolved bugs is very valuable in the case of regressions,
similar but new occurrences, and when users search for a common problem
they think is a bug.


Getting good data on this would require spending quite a lot of effort 
to clean up the mess on Launchpad. For a start we have 361 "New" bugs. 
We have lots of "In Progress" bugs that have had no activity in years.


I am skeptical of the importance of keeping old, resolved bugs easily 
accessible. The only times I remember referring to resolved bugs were to 
mark new reports as duplicates because we haven't had a release in 2 
years so people keep reporting the same critical bugs. If needed, we 
could still manually copy and paste Launchpad URLs on the new issue 
tracker on the rare occasion that would be helpful.





This is not so much a fault of
Launchpad as it is a collective fault of the project for not using
Launchpad effectively.


Please provide suggestions on how we can better use Launchpad. Getting
the most out of existing tools is always a worthwhile endeavor.


1. Step up to assign yourselves to bugs, assign them to a milestone, and 
actually commit to taking care of it by that milestone. Unassign 
yourself from issues you don't actually end up fixing.
2. Think carefully on whether a bug is important enough and can be taken 
care of easily enough before assigning it to a milestone without any 
contributor assigned to take care of it. Assigning bugs to a milestone 
without assigning them to any person generates a lot of noise on the 
milestone. I had to spend an entire day last weekend cleaning up the 2.1 
milestone so we could see what actually needs to be done for the release.
3. Be quick to mark new reports as Incomplete and let them expire if the 
reporter does not supply the information necessary to make the report 
useful.





On that note, can we get rid of this old SourceForge mailing list that
appends spam to every post?


I'm going to look at migrating it to Launchpad after the login
consolidation work.


That's not going to solve the problem of people not wanting to use email 
lists. It's not going to solve the problem of requiring a Launchpad 
account to participate fully in Mixxx development. It's not going to 
solve the problem of having too many communication channels. I'm pretty 
sure I'm the only one who keeps up with every one of them and it's way 
more work than it should be.


--
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] infrastructure modernization

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

For the record, GitLab looks really interesting and exciting to me as
well. If we were a new project, we could go there in a heartbeat. But we
have to consider all of the not-fun practical matters and repercussions
of migration of a large and storied existing project.

On 11/17/2017 11:59 AM, Be wrote:
> IMO our biggest issue as a project is a lack of labor.

Which is precisely why migrating at all would be problematic. We can
ill-afford the labor to do it.

> IMO having to host our own server for project management is practically
> a non-starter.

What are you referring to? In the case of improving Launchpad, our work
would be submitted upstream, to go live on Launchpad.net. We won't have
to move or change anything, just make the existing platform better.
Seems like the best return on effort invested to me.

> A lot, if not most, of the stuff on our Launchpad bug tracker is old
> noise with incomplete information.

Please do not make sweeping assertions like this without data.

In reality, 2774 (or 73.5%) of the bugs in the system are either
confirmed (adequate information,) being worked on, or already fixed. A
history of resolved bugs is very valuable in the case of regressions,
similar but new occurrences, and when users search for a common problem
they think is a bug.

> This is not so much a fault of
> Launchpad as it is a collective fault of the project for not using
> Launchpad effectively.

Please provide suggestions on how we can better use Launchpad. Getting
the most out of existing tools is always a worthwhile endeavor.

> On that note, can we get rid of this old SourceForge mailing list that
> appends spam to every post?

I'm going to look at migrating it to Launchpad after the login
consolidation work.

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



smime.p7s
Description: S/MIME Cryptographic Signature
--
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