>
> 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
- tres.finocchi...@gmail.com
On Wed, Jan 28, 2015 at 3:44 PM, Amadeus Folego <amadeusfol...@gmail.com>
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
> LMMS-devel@lists.sourceforge.net
> 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
LMMS-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lmms-devel
