1.2 feature definition/feature freeze

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

1.2 feature definition/feature freeze

Amadeus Folego
Hi everyone.

Could we make a definition on what should be planned to 1.2 and stop
tagging new issues as 1.2?

I've been sweeping the bug tracker trying to tackle all important
issues so that we can stabilize and improve LMMS for the next release,
but there are always new issues popping out, and if we continue tagging
them as 1.2 we will be like Sisyphus[0] until someone gets annoyed and
pushes forward with a lot of 1.2-tagged unresolved issues. This is
undesirable.

My suggestion is to define now if we want new features to 1.2, create
and tag them, then freeze the release.

This means that new issues should not be tagged 1.2, except if they are
bugs that are feasible to solve before the 1.2 release timeframe.

What do you think?

[0]: http://en.wikipedia.org/wiki/Sisyphus

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|

Re: 1.2 feature definition/feature freeze

Tres Finocchiaro
Not sure how I feel about this... 

Perhaps instead of a feature freeze just yet you and Dave can request a bump to the next milestone for items that you fee are out of scope given our resources.

The reason I say this is because rather than a rock rolling back to its place (Sisyphus), we're more of a snowball gaining size and momentum.  I'll let Vesa, Lukas and Dave chime in here too because proper milestone management was more of a nice-to-have and less of a line-in-the-sand previously, but I'm in favor of organized progress as well. :)


On Tue, Jan 27, 2015 at 8:39 PM, Amadeus Folego <[hidden email]> wrote:
Hi everyone.

Could we make a definition on what should be planned to 1.2 and stop
tagging new issues as 1.2?

I've been sweeping the bug tracker trying to tackle all important
issues so that we can stabilize and improve LMMS for the next release,
but there are always new issues popping out, and if we continue tagging
them as 1.2 we will be like Sisyphus[0] until someone gets annoyed and
pushes forward with a lot of 1.2-tagged unresolved issues. This is
undesirable.

My suggestion is to define now if we want new features to 1.2, create
and tag them, then freeze the release.

This means that new issues should not be tagged 1.2, except if they are
bugs that are feasible to solve before the 1.2 release timeframe.

What do you think?

[0]: http://en.wikipedia.org/wiki/Sisyphus

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel


------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|

Re: 1.2 feature definition/feature freeze

Dave French
LMMS's release cycle is new to me. I only started here a few weeks before 1.1 was finished so was just going with the flow. I  like to have something to aim at even if the goal posts do move, I find it keeps me motivated.  Is there a Target for 1.2 timewise, or feature wise?

On 28 January 2015 at 02:25, Tres Finocchiaro <[hidden email]> wrote:
Not sure how I feel about this... 

Perhaps instead of a feature freeze just yet you and Dave can request a bump to the next milestone for items that you fee are out of scope given our resources.

The reason I say this is because rather than a rock rolling back to its place (Sisyphus), we're more of a snowball gaining size and momentum.  I'll let Vesa, Lukas and Dave chime in here too because proper milestone management was more of a nice-to-have and less of a line-in-the-sand previously, but I'm in favor of organized progress as well. :)


On Tue, Jan 27, 2015 at 8:39 PM, Amadeus Folego <[hidden email]> wrote:
Hi everyone.

Could we make a definition on what should be planned to 1.2 and stop
tagging new issues as 1.2?

I've been sweeping the bug tracker trying to tackle all important
issues so that we can stabilize and improve LMMS for the next release,
but there are always new issues popping out, and if we continue tagging
them as 1.2 we will be like Sisyphus[0] until someone gets annoyed and
pushes forward with a lot of 1.2-tagged unresolved issues. This is
undesirable.

My suggestion is to define now if we want new features to 1.2, create
and tag them, then freeze the release.

This means that new issues should not be tagged 1.2, except if they are
bugs that are feasible to solve before the 1.2 release timeframe.

What do you think?

[0]: http://en.wikipedia.org/wiki/Sisyphus

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel


------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel



------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|

Re: 1.2 feature definition/feature freeze

diiz
In reply to this post by Tres Finocchiaro
On 01/28/2015 04:25 AM, Tres Finocchiaro wrote:

> Not sure how I feel about this...
>
> Perhaps instead of a feature freeze just yet you and Dave can request
> a bump to the next milestone for items that you fee are out of scope
> given our resources.
>
> The reason I say this is because rather than a rock rolling back to
> its place (Sisyphus), we're more of a snowball gaining size and
> momentum.  I'll let Vesa, Lukas and Dave chime in here too because
> proper milestone management was more of a nice-to-have and less of a
> line-in-the-sand previously, but I'm in favor of organized progress as
> well. :)

Organization? In the LMMS community?? BLASPHEMY.

Seriously though, if someone wants to clean up & organize tags, that's
fine. Remember though that a feature freeze doesn't concern bugs, only
features. So bugs that are tagged as 1.2 can still stay 1.2. Also the
next tag after 1.2 should probably be 2.0.

As for the freeze, I think we talked of February before? Maybe a week or
two from now? Is anyone working on any big features right now?

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|

Re: 1.2 feature definition/feature freeze

Amadeus Folego
On Wed, Jan 28, 2015 at 07:45:47AM +0200, Vesa wrote:
> As for the freeze, I think we talked of February before? Maybe a week or
> two from now? Is anyone working on any big features right now?

Well, I am not asking too much, my idea would be just to not tag any new
feature/enhancement as 1.2 and remove the 1.2 tag from any unrealistic
issues like huge features or bugs that are seemingly impossible to
solve.

We don't need actually to freeze development, one can continue working
on what they want, it's just that we would try to stabilize the 1.2
release.

Providing a release candidate and asking the community to test it would
be great to trace bugs that can be squished that are easy to fix or were
introduced in this release, this would increase the quality of LMMS
releases a lot.

Looking right now this is the stats for issues tagged 1.2:

Open: 56, Closed: 68.

So even if we stopped right now tagging issues to 1.2
we would have *a lot* of stuff to do, even though a lot of these issues
are bad described enhancements or bugs outside of lmms scope.

As for the next release being 2.0, I don't know. I would rather be
careful and try to take little steps as I know everyone has a lot of
expectations for 2.0 (and I know that I can't develop all these
incredible new features/core refactors/bug squashing myself for now).

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|

Re: 1.2 feature definition/feature freeze

diiz
On 01/28/2015 08:35 AM, Amadeus Folego wrote:
On Wed, Jan 28, 2015 at 07:45:47AM +0200, Vesa wrote:
As for the freeze, I think we talked of February before? Maybe a week or
two from now? Is anyone working on any big features right now?
Well, I am not asking too much, my idea would be just to not tag any new
feature/enhancement as 1.2 and remove the 1.2 tag from any unrealistic
issues like huge features or bugs that are seemingly impossible to
solve.

The tags are morelike guidelines. Or aspirations... they're more like what we aim to get done for a given release, but it's very common for issues to get bumped ahead when they don't get addressed in time. So I advise not to stress too much about them.

We don't need actually to freeze development,

Feature freeze is necessary for stabilization. It's what we do for every release.

Providing a release candidate and asking the community to test it would

We do that too.

As for the next release being 2.0, I don't know. I would rather be
careful and try to take little steps as I know everyone has a lot of
expectations for 2.0

The plan is to start working on 2.0 as soon as 1.2 is out. And in fact some of the work has already been started. I don't care really about expectations... it's a necessary step in the evolution of LMMS, if you want more detail you can read the mailing list archives where this has been discussed in the past.


------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|

Re: 1.2 feature definition/feature freeze

Amadeus Folego
On Wed, Jan 28, 2015 at 05:07:16PM +0200, Vesa wrote:
> The tags are morelike guidelines. Or aspirations... they're more like what we
> aim to get done for a given release, but it's very common for issues to get
> bumped ahead when they don't get addressed in time. So I advise not to stress
> too much about them.

Well, it's important to have some kind of organization about this, we
can't simply tag anything with anything we feel like, if I am the only
one on the boat who thinks this way I can try not to care very much. But
I feel that this is bad.

>
>
>     We don't need actually to freeze development,
>
>
> Feature freeze is necessary for stabilization. It's what we do for every
> release.

We don't need to freeze development: in the sense that anyone can still
work on any issues that are needed, we just can't merge new stuff on the
master branch on the stabilization phase.

>     Providing a release candidate and asking the community to test it would
>
>
> We do that too.

I am sorry, I just did not experience this yet on this project. I am not
saying that you never did this, I am not judging anyone, just trying to
move forward to a good future for LMMS.

> The plan is to start working on 2.0 as soon as 1.2 is out. And in fact some of
> the work has already been started. I don't care really about expectations...
> it's a necessary step in the evolution of LMMS, if you want more detail you can
> read the mailing list archives where this has been discussed in the past.

You may not care about expectations, but when someone says "Feature X,Y
and Z is going to be on release 2.0" and a few months later says "We started 2.0
development!" but just then notices how far fetched they were and comes
back again saying, "Actually we just implemented X, Y and Z were moved
to 2.1". Well, this is simply not a very good idea, it kills most of
predictability and development coordination of a team (that hopefully
will grow or at least mantain it's size).

Anyway, if this topic is difficult to talk about or something else you
don't need to worry.

I'll be happy just mindlessly fixing crashes and random enhancements, I
just wanted to improve the communication and try to create a sense of
union and maybe a team. In my experience having isolated developers
working on huge features without any constant communication is an issue
and bad for productivity, but if LMMS is an outlier or does not want to
change, what can I do?

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|

Re: 1.2 feature definition/feature freeze

Tres Finocchiaro
I'll be happy just mindlessly fixing crashes and random enhancements, I just wanted to improve the communication and try to create a sense of union and maybe a team. In my experience having isolated developers working on huge features without any constant communication is an issue and bad for productivity, but if LMMS is an outlier or does not want to change, what can I do?

We do want to change and that is happening with help from people like you.

What 2.0 represents is mostly conceptual.

What 1.2 represents is mostly well defined.

I tend to agree that if resources are thin on 2.0 we may want to focus on an interim milestone, but I also want to encourage the changes we need to make it to 2.0.

Since Vesa is pioneering most of the 2.0 effort and the changes it requires, I'll let him speak more on behalf of how that would fall into a reasonable timeline and whether or not it is a reasonable goal for our next release.

In support of Amadeus' points, I too see enough work to warrant a milestone that is less impacting.  The "small" things as musikBear would put it are a tremendous amount of coding, sanity checking and testing and we seem to be backlogged with just that at the moment.  Envisioning 2.0 as our next release does seem like a far reach, but I also want to do what I can to encourage forward progression. :)

-Tres




On Wed, Jan 28, 2015 at 3:44 PM, Amadeus Folego <[hidden email]> wrote:
On Wed, Jan 28, 2015 at 05:07:16PM +0200, Vesa wrote:
> The tags are morelike guidelines. Or aspirations... they're more like what we
> aim to get done for a given release, but it's very common for issues to get
> bumped ahead when they don't get addressed in time. So I advise not to stress
> too much about them.

Well, it's important to have some kind of organization about this, we
can't simply tag anything with anything we feel like, if I am the only
one on the boat who thinks this way I can try not to care very much. But
I feel that this is bad.

>
>
>     We don't need actually to freeze development,
>
>
> Feature freeze is necessary for stabilization. It's what we do for every
> release.

We don't need to freeze development: in the sense that anyone can still
work on any issues that are needed, we just can't merge new stuff on the
master branch on the stabilization phase.

>     Providing a release candidate and asking the community to test it would
>
>
> We do that too.

I am sorry, I just did not experience this yet on this project. I am not
saying that you never did this, I am not judging anyone, just trying to
move forward to a good future for LMMS.

> The plan is to start working on 2.0 as soon as 1.2 is out. And in fact some of
> the work has already been started. I don't care really about expectations...
> it's a necessary step in the evolution of LMMS, if you want more detail you can
> read the mailing list archives where this has been discussed in the past.

You may not care about expectations, but when someone says "Feature X,Y
and Z is going to be on release 2.0" and a few months later says "We started 2.0
development!" but just then notices how far fetched they were and comes
back again saying, "Actually we just implemented X, Y and Z were moved
to 2.1". Well, this is simply not a very good idea, it kills most of
predictability and development coordination of a team (that hopefully
will grow or at least mantain it's size).

Anyway, if this topic is difficult to talk about or something else you
don't need to worry.

I'll be happy just mindlessly fixing crashes and random enhancements, I
just wanted to improve the communication and try to create a sense of
union and maybe a team. In my experience having isolated developers
working on huge features without any constant communication is an issue
and bad for productivity, but if LMMS is an outlier or does not want to
change, what can I do?

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel


------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|

Re: 1.2 feature definition/feature freeze

Phil (list)
On Wed, 2015-01-28 at 17:00 -0500, Tres Finocchiaro wrote:


> What 2.0 represents is mostly conceptual.
>
> What 1.2 represents is mostly well defined.
>
>
> I tend to agree that if resources are thin on 2.0 we may want to focus
> on an interim milestone, but I also want to encourage the changes we
> need to make it to 2.0.
>
I'm still getting myself oriented with LMMS, but after reading through
the earlier 2.0 thread I wanted to toss out an idea that might help on
the road to 2.0 and minimize the pain of migration:

Are the changes planned for 2.0 really so radical that existing projects
can't be migrated or could a 1.x release be set up as a springboard to
2.0 that could help with migration?  It sounds like there's a lot of
legacy cruft that's planning to be removed as well as internal
restructuring to improve things going forward.  Assuming that's the
case, would it be feasible to start working toward a simplified 1.x
project file that could be migrated?  I'd imagine this as a two step
process:

1) Offering a lint check of sorts when opening an existing file that
would flag (either a dialog pop or writing out a log file) things that
aren't compatible giving the user an indication of what is going to
break and giving them an opportunity to rework those parts of the
project since they'll (hopefully) be better equipped to decide the best
way to 'fix' things.

2) Assuming they've iterated through 1 and done everything they can or
plan to in preparation for 2.0, provide a 'save as 1.x final' or
whatever to save out the streamlined project which would drop on the
floor any incompatibilities providing a smaller footprint / feature set
for 2.0 to deal with from a migration standpoint.

Not yet having an understanding of what sort of cruft is involved, I
have no idea if the effort involved in doing this is worth it.  But
dropping compatibility for existing work seems extreme.




------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|

Re: 1.2 feature definition/feature freeze

David Gerard-2
On 28 January 2015 at 22:58, Phil (list) <[hidden email]> wrote:

> Not yet having an understanding of what sort of cruft is involved, I
> have no idea if the effort involved in doing this is worth it.  But
> dropping compatibility for existing work seems extreme.



Just picture the FB page when 2.0 is released and people's old files
don't work at all. Will those users move to 2.0 or stick with 1.2?


- d.

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|

Re: 1.2 feature definition/feature freeze

Amadeus Folego
On Wed, Jan 28, 2015 at 11:31:38PM +0000, David Gerard wrote:

> On 28 January 2015 at 22:58, Phil (list) <[hidden email]> wrote:
>
> > Not yet having an understanding of what sort of cruft is involved, I
> > have no idea if the effort involved in doing this is worth it.  But
> > dropping compatibility for existing work seems extreme.
>
>
>
> Just picture the FB page when 2.0 is released and people's old files
> don't work at all. Will those users move to 2.0 or stick with 1.2?

If there are compelling reasons they'll move.

Wouldn't you prefer starting a project on LMMS 2.0 if it has LV2
support? No crashes? A lot of usability improvements? Improved midi
capabilities? Export individual FX Channels? Etc...

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|

Re: 1.2 feature definition/feature freeze

Amadeus Folego
In reply to this post by Phil (list)
On Wed, Jan 28, 2015 at 05:58:06PM -0500, Phil (list) wrote:
> 1) Offering a lint check of sorts when opening an existing file that
> would flag (either a dialog pop or writing out a log file) things that
> aren't compatible giving the user an indication of what is going to
> break and giving them an opportunity to rework those parts of the
> project since they'll (hopefully) be better equipped to decide the best
> way to 'fix' things.

This looks like a sensible idea.

> Are the changes planned for 2.0 really so radical that existing projects
> can't be migrated or could a 1.x release be set up as a springboard to
> 2.0 that could help with migration?

Major version numbers in software development most of the time means
compatibility breaks, although this may not be the case some times.

It's really a crazy thing, but if we are going to break stuff we need to
give a good reason for this, that's why it's very important to create
features/improvements/add support in a way that users really feel that
the migration is worth it.

> 2) Assuming they've iterated through 1 and done everything they can or
> plan to in preparation for 2.0, provide a 'save as 1.x final' or
> whatever to save out the streamlined project which would drop on the
> floor any incompatibilities providing a smaller footprint / feature set
> for 2.0 to deal with from a migration standpoint.

Again, very good ideas, maybe you can help us on github even if you
don't code?

You can add issues describing feature requests or bug reports.

Specifically for 2.0: we are not yet officially on 2.0 development
effort, as soon as we understand the breaking changes and see them we
can see if this is possible.

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|

Re: 1.2 feature definition/feature freeze

Phil (list)
On Wed, 2015-01-28 at 21:57 -0200, Amadeus Folego wrote:

> On Wed, Jan 28, 2015 at 05:58:06PM -0500, Phil (list) wrote:
> > 1) Offering a lint check of sorts when opening an existing file that
> > would flag (either a dialog pop or writing out a log file) things that
> > aren't compatible giving the user an indication of what is going to
> > break and giving them an opportunity to rework those parts of the
> > project since they'll (hopefully) be better equipped to decide the best
> > way to 'fix' things.
>
> This looks like a sensible idea.
>
> > Are the changes planned for 2.0 really so radical that existing projects
> > can't be migrated or could a 1.x release be set up as a springboard to
> > 2.0 that could help with migration?
>
> Major version numbers in software development most of the time means
> compatibility breaks, although this may not be the case some times.
>
> It's really a crazy thing, but if we are going to break stuff we need to
> give a good reason for this, that's why it's very important to create
> features/improvements/add support in a way that users really feel that
> the migration is worth it.
>

I understand that things will break/shift around/change, but dropping
existing projects seems like throwing the baby out with the bathwater.
One of the nice things about persisting things in an external file
format is that sweeping code changes can be made without breaking
everything from the users POV: they'll start up the new version but
their stuff will still be there.  Granted, it's more work than just
breaking everything, but once you go down the path of tossing their data
there's a significant goodwill cost involved.

> > 2) Assuming they've iterated through 1 and done everything they can or
> > plan to in preparation for 2.0, provide a 'save as 1.x final' or
> > whatever to save out the streamlined project which would drop on the
> > floor any incompatibilities providing a smaller footprint / feature set
> > for 2.0 to deal with from a migration standpoint.
>
> Again, very good ideas, maybe you can help us on github even if you
> don't code?
>

I code, but my C++ is rusty (basically means I can help, but my
productivity will be limited initially.)  I'm game for pitching in where
I can which is part of why I brought this up.

> You can add issues describing feature requests or bug reports.
>
> Specifically for 2.0: we are not yet officially on 2.0 development
> effort, as soon as we understand the breaking changes and see them we
> can see if this is possible.

Fair enough.


------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|

Re: 1.2 feature definition/feature freeze

Tres Finocchiaro
I understand that things will break/shift around/change, but dropping existing projects seems like throwing the baby out with the bathwater.

Vesa said he was going to break backwards compatibility for 2.0 and there has been an overwhelming amount of push-back on that statement.

What is important to understand is that backwards compatibility is not first and foremost in the current 2.0 design plans because it is an obstacle which can hurt progress.

This doesn't mean 1.x projects won't play in 2.0. We have some very skilled resources active on our development team that will do what is possible to upgrade 1.x projects to 2.0 projects. 

Some portions of the project will be lost, namely some automation track information if it proves too difficult to upgrade.

But we have every intention of making 1.x projects playable.  For those that upgraded from 0.4.x to 1.0.x you probably noticed quite a few places where the old project didn't play correctly.  This stuff is going to happen from version to version and we take the good with the bad.  It is part of progress.

But a reminder, this topic is more about how we track our bugs.  Our 2.0 initiatives have email threads and futuremaps which would probably be a better place to stir up the compat conversations.




On Wed, Jan 28, 2015 at 7:50 PM, Phil (list) <[hidden email]> wrote:
On Wed, 2015-01-28 at 21:57 -0200, Amadeus Folego wrote:
> On Wed, Jan 28, 2015 at 05:58:06PM -0500, Phil (list) wrote:
> > 1) Offering a lint check of sorts when opening an existing file that
> > would flag (either a dialog pop or writing out a log file) things that
> > aren't compatible giving the user an indication of what is going to
> > break and giving them an opportunity to rework those parts of the
> > project since they'll (hopefully) be better equipped to decide the best
> > way to 'fix' things.
>
> This looks like a sensible idea.
>
> > Are the changes planned for 2.0 really so radical that existing projects
> > can't be migrated or could a 1.x release be set up as a springboard to
> > 2.0 that could help with migration?
>
> Major version numbers in software development most of the time means
> compatibility breaks, although this may not be the case some times.
>
> It's really a crazy thing, but if we are going to break stuff we need to
> give a good reason for this, that's why it's very important to create
> features/improvements/add support in a way that users really feel that
> the migration is worth it.
>

I understand that things will break/shift around/change, but dropping
existing projects seems like throwing the baby out with the bathwater.
One of the nice things about persisting things in an external file
format is that sweeping code changes can be made without breaking
everything from the users POV: they'll start up the new version but
their stuff will still be there.  Granted, it's more work than just
breaking everything, but once you go down the path of tossing their data
there's a significant goodwill cost involved.

> > 2) Assuming they've iterated through 1 and done everything they can or
> > plan to in preparation for 2.0, provide a 'save as 1.x final' or
> > whatever to save out the streamlined project which would drop on the
> > floor any incompatibilities providing a smaller footprint / feature set
> > for 2.0 to deal with from a migration standpoint.
>
> Again, very good ideas, maybe you can help us on github even if you
> don't code?
>

I code, but my C++ is rusty (basically means I can help, but my
productivity will be limited initially.)  I'm game for pitching in where
I can which is part of why I brought this up.

> You can add issues describing feature requests or bug reports.
>
> Specifically for 2.0: we are not yet officially on 2.0 development
> effort, as soon as we understand the breaking changes and see them we
> can see if this is possible.

Fair enough.



------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|

Re: 1.2 feature definition/feature freeze

Stian Jørgensrud
In reply to this post by Amadeus Folego
Feature freeze for 1.2 as soon as possible IMO. It is going to take at least yet another month before it is out if we freeze it today.

And Vesa and Amadeus, I think you are talking about freeze as the exact same thing, no more new features for that version.
Reply | Threaded
Open this post in threaded view
|

Re: 1.2 feature definition/feature freeze

David Gerard-2
In reply to this post by Amadeus Folego
On 28 January 2015 at 23:44, Amadeus Folego <[hidden email]> wrote:

> If there are compelling reasons they'll move.
> Wouldn't you prefer starting a project on LMMS 2.0 if it has LV2
> support? No crashes? A lot of usability improvements? Improved midi
> capabilities? Export individual FX Channels? Etc...


If you break users' stuff, they will leave and not come back. And they
will be entirely correct to do so, else it would be encouraging you do
it again with 3.0.

When 2.0 comes out, the *first* thing users will do is try their 1.2
files in it.

If you break users' work, they will never forgive you, and it's
ridiculous for you to expect otherwise.


Tres Finocchiaro wrote:

> But we have every intention of making 1.x projects playable.  For those that upgraded from 0.4.x to 1.0.x you probably noticed quite a few places where the old project didn't play correctly.  This stuff is going to happen from version to version and we take the good with the bad.  It is part of progress.


I assume there will be a round of testing of back-compatibility breakages.

Has Vesa actually walked back his original statement that we should
throw away all our old work and write new stuff, or is this just you
saying this?


- d.

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|

Re: 1.2 feature definition/feature freeze

diiz
David Gerard kirjoitti 2015-01-29 12:16:

> On 28 January 2015 at 23:44, Amadeus Folego <[hidden email]>
> wrote:
>
>> If there are compelling reasons they'll move.
>> Wouldn't you prefer starting a project on LMMS 2.0 if it has LV2
>> support? No crashes? A lot of usability improvements? Improved midi
>> capabilities? Export individual FX Channels? Etc...
>
>
> If you break users' stuff, they will leave and not come back. And they
> will be entirely correct to do so, else it would be encouraging you do
> it again with 3.0.


You're suddenly the spokesman for the entire userbase of LMMS I see...

I've said this many times before, but APPARENTLY it still needs
repeating, so say it with me: LMMS is developed by volunteer efforts,
for free. There's absolutely no obligation on part of the developers to
offer any kind of technical support, the software is provided AS-IS
without any warranty etc.

Backwards compatibility is not our obligation, it's a service we provide
(again, for free), but if providing that service is counter-productive
in a certain case, then WE DON'T ACTUALLY OWE IT TO ANYONE TO PROVIDE
THAT SERVICE.


And sorry if I sound a bit harsh here, but I'm getting kind of tired of
people who have no idea about the amount of work and coordination
necessary for something like LMMS to be maintained, coming here and
telling us what we "need to do". As if we're some kind of trained
animals that have to be "encouraged" to do things the way the user feels
entitled to... newsflash, we're not. You use the software if you like
it, you don't if you don't. But unless you participate in development,
you have no business dictating to developers what they should do.
Suggestions, feature requests are fine, but demands are not. We're not
slaves nor even paid workers.


> When 2.0 comes out, the *first* thing users will do is try their 1.2
> files in it.
> If you break users' work, they will never forgive you, and it's
> ridiculous for you to expect otherwise.

You are making a mountain out of a molehill.

No work is being broken. Users who feel attached to their old project
files can keep on using the last version they work in for all eternity.
No one is stopping them from doing that. We're not visiting every user's
home and forcibly deleting old project files from their hard drive, nor
are we scouring the net free of old versions of LMMS.


That said... there's one more thing I want to say, and this is the only
thing I'm going to say about the 2.0 efforts in this thread.

The 2.0 plan is an ambitious one with upsides and downsides, and the
changes that are planned for it are drastic - controversy was and is
expected. But you can't actually develop a software the size of LMMS and
never piss off anyone, never break anyone's workflow, there's always
someone who is dissatisfied with some change.

However, I can't do the 2.0 transition alone. So if everyone else feels
they'd rather continue working on LMMS 1.3 and maintain backwards
compat, then that's that. I can't actually force people to accept the
idea.

But I personally have no interest in working on LMMS 1.3. At all.
Because the way I see it, these changes that are planned for 2.0 are
necessary for making LMMS a real, professional grade music application
instead of the "semibroken toy DAW" it is currently known as - and I'm
saying this as someone who loves LMMS, it's just that if you ask someone
who's used to working with pro-audio tools to take a look at LMMS,
that's the impression they'll get from it in its current state.

Backwards compat isn't being broken out of spite. There's a reason for
every planned breakage. And the reason they're all shoved into 2.0 is
that it's better if there isn't multiple versions with breakage, that
all the breakage happens at one version.

I don't actually have to work on LMMS. If everyone else thinks LMMS 2.0
is a bad idea, I can just go on to see if the qtractor guys need my
help, or something (or just concentrate on music and start coding LV2
plugins or something). The point is, without the 2.0 effort, I see no
future for LMMS, and maybe I'm wrong about that, but that's the way I
see it so I won't want to work on it. People can keep adding bandages to
the broken engine, keep on working on external features like UI and
stepping around design flaws, building up the legacy cruft... but I want
no part of that.

This is not meant as a blackmailing "my way or the highway" stance. It's
just that I really like LMMS, but I've also gotten familiar enough with
the codebase to see the limitations of it, and I want us to fix those
limitations so that we can create something greater in the future. If
that's not going to happen, then I just feel I have better uses for my
time.

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|

Re: 1.2 feature definition/feature freeze

Amadeus Folego
On Thu, Jan 29, 2015 at 03:19:47PM +0200, [hidden email] wrote:
> I don't actually have to work on LMMS. If everyone else thinks LMMS 2.0
> is a bad idea, I can just go on to see if the qtractor guys need my
> help, or something (or just concentrate on music and start coding LV2
> plugins or something).

I am sorry that my original discussion developed into this, that's
totally not I wanted.

> People can keep adding bandages to
> the broken engine, keep on working on external features like UI and
> stepping around design flaws, building up the legacy cruft... but I want
> no part of that.
>

I understand what you mean here, and I see where you're coming from.

But see, I am just a novice, entering now to work on this codebase. This
is the only thing I can do now confidently and competently (I hope so).
I am just trying to collaborate with what I can do, it may be not
the most exciting thing on the world.

I am not saying that you are forbidden to do what you want or develop
the software in the same way that you were before, actually I *want* you
to do this, because you're much more capable than me to diagnose bad
design, UI flaws, etc...

We're just trying to improve what we have
today, but if you come with a bomb that'll break and invalidate
everything we've done but is much, much better then it's fine,
I'll be happy :-). Because my main motivation to work on this is the
same as yours: LMMS is broken, LMMS *feels* broken, and it can be better
than this.

> However, I can't do the 2.0 transition alone. So if everyone else feels
> they'd rather continue working on LMMS 1.3 and maintain backwards
> compat, then that's that. I can't actually force people to accept the
> idea.
>
> But I personally have no interest in working on LMMS 1.3. At all.
> Because the way I see it, these changes that are planned for 2.0 are
> necessary for making LMMS a real, professional grade music application
> instead of the "semibroken toy DAW" it is currently known as - and I'm
> saying this as someone who loves LMMS, it's just that if you ask someone
> who's used to working with pro-audio tools to take a look at LMMS,
> that's the impresstion they'll get from it in its current state.

Well, I've re-read the 2.0 email you posted on November, and to be frank
It's not clear how I can help. If someone makes explicit what's the
roadmap do 2.0 and a definition of the product I would be very, very happy to
contribute.

The existence of 1.3 does not invalidate the progress to 2.0 as I see
though. It's just a release to 1.2, what's the problem with that? The
only possibility I see it's that it touches on something that's been a
source of frustration to you: the absence of developers who can help
deliver in a short amount of time a really amazing and not broken DAW.

I am doing what I can for now, taking bigger steps toward bigger
features, understanding the current design, trying to figure out how
things are done, etc.

========================================================================

I just started this thread because I wanted to move forward to small
release steps, but if this is a big issue, then it's fine. If staying
into 1.2 until you are able to develop and show us the big improvements
you are devising for 2.0 so that we also can work on it, then it's fine
as well.

I hope you understand that I am just trying to help, and if I am hurting
more than helping, please let me know so that I can help in a
different, better way.

I guess I am used to really fast-paced projects, with small releases and
etc, so when I saw that we have LV2 plans from the middle of this year
but nothing delivered, 2.0 plans and no visible progress. Well, that
this is probably not going in that direction for now. It's possible
though that we just need to be patient, and if that's the case it's fine
by me.

Also, working on a free software and receiving feedbacks from people
like the ones you have received is annoying I know, I assume you're
probably burned out from everyone saying what we should do or not,
invalidating our work with just a few words and never truly helping out:
etc.

I just want to say that just by following the limited knowledge of LMMS
evolution that I have that you've done an outstanding and great job, I
thank you for that.

And also, if we are doing something wrong or misoriented and it's going
to hurt more than help in achieving the LMMS of our dreams, please tell
us, I trust that your advice will be of utmost importance.

Thanks for everything!

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|

Re: 1.2 feature definition/feature freeze

Tres Finocchiaro
People can keep adding bandages to the broken engine, keep on working on external features like UI and stepping around design flaws, building up the legacy cruft... but I want no part of that.

I'd like to point out that the people working on this "legacy cruft" are critical to the success of 2.0 as well.  Also, many of these fixes are stepping around design flaws but many are fixes that will make it into 2.0.

I understand the point, but we need to be careful not to minimize the contributions on either side of the 2.0 fence.  We have a lot of progressive changes that have happened that will benefit both branches.

If we were to relate this to a bee colony, we'd be observing a "waggle dance".  This "waggle" is the hope of something better and more accommodating elsewhere.  This hope eventually turns into a promise once everyone agrees but it can't be forced.  It is a convincing that happens over time.


If 1.x is our current beehive and 2.x is our future beehive, we still have some waggle dancing to do. :)

In history, many projects have started a drastic rewrite and stopped, include in the past with LMMS itself where the master branch and the 0.4 branch drifted too far apart.  0.4 won.  It wasn't out of spite either.  It is just how it happened.  For example, the code for the new mixer was old master code from the 0.4 days (IIRC).  It wasn't until 1.1 was released when the mixer code finally made it in and was considered stable (BTW, it's not stable, it has many bugs which have started even further debate).

What I see now is very little waggle dancing happening for 2.x and no one should take that personally nor take sides.  Trusting change is a natural progression and I think we're doing damn well on that front.  If Vesa needs help we may need him to pinpoint some places that would immediately benefit 2.x and have a few people take a look and start waggling themselves. :)
 
-Tres


On Thu, Jan 29, 2015 at 10:59 AM, Amadeus Folego <[hidden email]> wrote:
On Thu, Jan 29, 2015 at 03:19:47PM +0200, [hidden email] wrote:
> I don't actually have to work on LMMS. If everyone else thinks LMMS 2.0
> is a bad idea, I can just go on to see if the qtractor guys need my
> help, or something (or just concentrate on music and start coding LV2
> plugins or something).

I am sorry that my original discussion developed into this, that's
totally not I wanted.

> People can keep adding bandages to
> the broken engine, keep on working on external features like UI and
> stepping around design flaws, building up the legacy cruft... but I want
> no part of that.
>

I understand what you mean here, and I see where you're coming from.

But see, I am just a novice, entering now to work on this codebase. This
is the only thing I can do now confidently and competently (I hope so).
I am just trying to collaborate with what I can do, it may be not
the most exciting thing on the world.

I am not saying that you are forbidden to do what you want or develop
the software in the same way that you were before, actually I *want* you
to do this, because you're much more capable than me to diagnose bad
design, UI flaws, etc...

We're just trying to improve what we have
today, but if you come with a bomb that'll break and invalidate
everything we've done but is much, much better then it's fine,
I'll be happy :-). Because my main motivation to work on this is the
same as yours: LMMS is broken, LMMS *feels* broken, and it can be better
than this.

> However, I can't do the 2.0 transition alone. So if everyone else feels
> they'd rather continue working on LMMS 1.3 and maintain backwards
> compat, then that's that. I can't actually force people to accept the
> idea.
>
> But I personally have no interest in working on LMMS 1.3. At all.
> Because the way I see it, these changes that are planned for 2.0 are
> necessary for making LMMS a real, professional grade music application
> instead of the "semibroken toy DAW" it is currently known as - and I'm
> saying this as someone who loves LMMS, it's just that if you ask someone
> who's used to working with pro-audio tools to take a look at LMMS,
> that's the impresstion they'll get from it in its current state.

Well, I've re-read the 2.0 email you posted on November, and to be frank
It's not clear how I can help. If someone makes explicit what's the
roadmap do 2.0 and a definition of the product I would be very, very happy to
contribute.

The existence of 1.3 does not invalidate the progress to 2.0 as I see
though. It's just a release to 1.2, what's the problem with that? The
only possibility I see it's that it touches on something that's been a
source of frustration to you: the absence of developers who can help
deliver in a short amount of time a really amazing and not broken DAW.

I am doing what I can for now, taking bigger steps toward bigger
features, understanding the current design, trying to figure out how
things are done, etc.

========================================================================

I just started this thread because I wanted to move forward to small
release steps, but if this is a big issue, then it's fine. If staying
into 1.2 until you are able to develop and show us the big improvements
you are devising for 2.0 so that we also can work on it, then it's fine
as well.

I hope you understand that I am just trying to help, and if I am hurting
more than helping, please let me know so that I can help in a
different, better way.

I guess I am used to really fast-paced projects, with small releases and
etc, so when I saw that we have LV2 plans from the middle of this year
but nothing delivered, 2.0 plans and no visible progress. Well, that
this is probably not going in that direction for now. It's possible
though that we just need to be patient, and if that's the case it's fine
by me.

Also, working on a free software and receiving feedbacks from people
like the ones you have received is annoying I know, I assume you're
probably burned out from everyone saying what we should do or not,
invalidating our work with just a few words and never truly helping out:
etc.

I just want to say that just by following the limited knowledge of LMMS
evolution that I have that you've done an outstanding and great job, I
thank you for that.

And also, if we are doing something wrong or misoriented and it's going
to hurt more than help in achieving the LMMS of our dreams, please tell
us, I trust that your advice will be of utmost importance.

Thanks for everything!

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel


------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|

Re: 1.2 feature definition/feature freeze

Tres Finocchiaro
I think we're nearing in on a 1.2 feature freeze...
  • The 1.1 changes need to be synced up to 1.2.  Lukas/Vesa can you help with this?
  • I've bumped all of the remaining 1.1 bugs to 1.2 milestone (since there doesn't seem to be any movement on them)
  • I've also taken the liberty to bump/consolidate some bug reports to help narrow our 1.2 efforts.
There are 41 open bugs reports/enhancements still on our 1.2 milestone.  If you see one that you feel is unreasonable for the 1.2 milestone, please post a comment and we can decide to bump it.  If you see one you can fix, please post a comment too.

-Tres






On Thu, Jan 29, 2015 at 11:42 AM, Tres Finocchiaro <[hidden email]> wrote:
People can keep adding bandages to the broken engine, keep on working on external features like UI and stepping around design flaws, building up the legacy cruft... but I want no part of that.

I'd like to point out that the people working on this "legacy cruft" are critical to the success of 2.0 as well.  Also, many of these fixes are stepping around design flaws but many are fixes that will make it into 2.0.

I understand the point, but we need to be careful not to minimize the contributions on either side of the 2.0 fence.  We have a lot of progressive changes that have happened that will benefit both branches.

If we were to relate this to a bee colony, we'd be observing a "waggle dance".  This "waggle" is the hope of something better and more accommodating elsewhere.  This hope eventually turns into a promise once everyone agrees but it can't be forced.  It is a convincing that happens over time.


If 1.x is our current beehive and 2.x is our future beehive, we still have some waggle dancing to do. :)

In history, many projects have started a drastic rewrite and stopped, include in the past with LMMS itself where the master branch and the 0.4 branch drifted too far apart.  0.4 won.  It wasn't out of spite either.  It is just how it happened.  For example, the code for the new mixer was old master code from the 0.4 days (IIRC).  It wasn't until 1.1 was released when the mixer code finally made it in and was considered stable (BTW, it's not stable, it has many bugs which have started even further debate).

What I see now is very little waggle dancing happening for 2.x and no one should take that personally nor take sides.  Trusting change is a natural progression and I think we're doing damn well on that front.  If Vesa needs help we may need him to pinpoint some places that would immediately benefit 2.x and have a few people take a look and start waggling themselves. :)
 
-Tres


On Thu, Jan 29, 2015 at 10:59 AM, Amadeus Folego <[hidden email]> wrote:
On Thu, Jan 29, 2015 at 03:19:47PM +0200, [hidden email] wrote:
> I don't actually have to work on LMMS. If everyone else thinks LMMS 2.0
> is a bad idea, I can just go on to see if the qtractor guys need my
> help, or something (or just concentrate on music and start coding LV2
> plugins or something).

I am sorry that my original discussion developed into this, that's
totally not I wanted.

> People can keep adding bandages to
> the broken engine, keep on working on external features like UI and
> stepping around design flaws, building up the legacy cruft... but I want
> no part of that.
>

I understand what you mean here, and I see where you're coming from.

But see, I am just a novice, entering now to work on this codebase. This
is the only thing I can do now confidently and competently (I hope so).
I am just trying to collaborate with what I can do, it may be not
the most exciting thing on the world.

I am not saying that you are forbidden to do what you want or develop
the software in the same way that you were before, actually I *want* you
to do this, because you're much more capable than me to diagnose bad
design, UI flaws, etc...

We're just trying to improve what we have
today, but if you come with a bomb that'll break and invalidate
everything we've done but is much, much better then it's fine,
I'll be happy :-). Because my main motivation to work on this is the
same as yours: LMMS is broken, LMMS *feels* broken, and it can be better
than this.

> However, I can't do the 2.0 transition alone. So if everyone else feels
> they'd rather continue working on LMMS 1.3 and maintain backwards
> compat, then that's that. I can't actually force people to accept the
> idea.
>
> But I personally have no interest in working on LMMS 1.3. At all.
> Because the way I see it, these changes that are planned for 2.0 are
> necessary for making LMMS a real, professional grade music application
> instead of the "semibroken toy DAW" it is currently known as - and I'm
> saying this as someone who loves LMMS, it's just that if you ask someone
> who's used to working with pro-audio tools to take a look at LMMS,
> that's the impresstion they'll get from it in its current state.

Well, I've re-read the 2.0 email you posted on November, and to be frank
It's not clear how I can help. If someone makes explicit what's the
roadmap do 2.0 and a definition of the product I would be very, very happy to
contribute.

The existence of 1.3 does not invalidate the progress to 2.0 as I see
though. It's just a release to 1.2, what's the problem with that? The
only possibility I see it's that it touches on something that's been a
source of frustration to you: the absence of developers who can help
deliver in a short amount of time a really amazing and not broken DAW.

I am doing what I can for now, taking bigger steps toward bigger
features, understanding the current design, trying to figure out how
things are done, etc.

========================================================================

I just started this thread because I wanted to move forward to small
release steps, but if this is a big issue, then it's fine. If staying
into 1.2 until you are able to develop and show us the big improvements
you are devising for 2.0 so that we also can work on it, then it's fine
as well.

I hope you understand that I am just trying to help, and if I am hurting
more than helping, please let me know so that I can help in a
different, better way.

I guess I am used to really fast-paced projects, with small releases and
etc, so when I saw that we have LV2 plans from the middle of this year
but nothing delivered, 2.0 plans and no visible progress. Well, that
this is probably not going in that direction for now. It's possible
though that we just need to be patient, and if that's the case it's fine
by me.

Also, working on a free software and receiving feedbacks from people
like the ones you have received is annoying I know, I assume you're
probably burned out from everyone saying what we should do or not,
invalidating our work with just a few words and never truly helping out:
etc.

I just want to say that just by following the limited knowledge of LMMS
evolution that I have that you've done an outstanding and great job, I
thank you for that.

And also, if we are doing something wrong or misoriented and it's going
to hurt more than help in achieving the LMMS of our dreams, please tell
us, I trust that your advice will be of utmost importance.

Thanks for everything!

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel



------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
12