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
