Hi, I will only answer some parts of your email, see below.
On Mon, 2020-09-28 at 11:33 +0900, David Leangen wrote: [...] > > > > This legacy is putting us in a very difficult situation: the > > codebase > > is huge, the test suite takes ages to execute, a lot of things are > > here > > for historical reasons but as we are careful about not breaking too > > much people deployments we don't remove enough things. > > Yes, it is a difficult situation, but I think we can overcome this. > The first step is recognizing the problems, which I think you have > quite well. > We know that for years. We tried the "work hard" strategy for now and it allowed us to deliver things. But It didn't allowed to make the project appealing enough to new users. > > > In short: we are not able to move fast, to simplify the codebase, > > to > > implement new things easily and finally it's hard to have fun for > > newcomers or even James veterans. > > I agree. I was initially excited about using James, but I realized > along the way that it would be a long-term commitment. I was not able > to accomplish what I wanted because I was not able to use it, and I > was also unable to understand it enough to make changes to be able to > use it. So I was not able to complete my project with any success. I > have changed tactic to try to accomplish this over the long term > instead. I hope to continue to invest maybe an hour or so each day, > but that is easier said than done. You personal experience with James is what most people experience. In my opinion there are two scenarios with James: * people who achieve to make it work for their purpose and move to the next thing they want to do, meaning little involvment on the project (I don't intend to be negative, it's ok to do that in my opinion) * people who want to make the project better and never reach their expectations James is thus a heap of unfinished initiatives, that's why we need to cut some parts. [...] > > 3. About versioning (3.x vs 4.0) > > > > Like roadmaps, major version numbers give people expectations: > > there > > must be something very new and/or very different because the > > community decided to increment major version number. > > Yes, you are absolutely right that a version number sets > expectations. And so it should. That is actually kind of the purpose. > > If possible, we should consider moving away from soft requirements > and use semantic versioning. I think that the concept of semantic > versioning is specified well enough to be considered as being quite > objective. Hopefully that should avoid this type of debate. I like semantic versioning, for libraries. I don't find that very relevant for end-user software. > > > Last time the community tried that (3.0) the projects almost died > > because too many things had to ship at the same time and then was > > never ready. It took years to finally release it after Linagora > > started to invest a lot it and by the way, we never finished what > > was supposed to, we just decided that, no software being perfect, > > we > > had to release this much-better-than-2.x version. > > Oh, that is interesting. It is always good to learn from experience. > > > > I would like to take the Linux Kernel path: > > > > * only increment minor version for the time being > > * don't build a backlog or any list of things we want to achieve > > before incrementing > > Can you explain this point more? What I mean is: ship what's ready, not what is planned. That way, we don't delay releases. > > > * release 2 to 4 times a years with what is ready > > * increment major version when what will be ready deserves it or > > when minor number get to big > > This seems a bit arbitrary. Maybe we could instead figure out what > semantic versioning means to James, so we can have a more objective > criterion? As said previously, semantic versioning is very good for libraries but not much for end-user software: every single minor release to date contained at least one breaking change so far. Is a database schema migration a breaking change for example? I prefer arbitrary community decision rather than loosing energy figuring out a rule for that. > > 4. About defining a vision > > > > You defined different kinds of software project styles and it's > > interesting to try to define where James is. > > > > Let me define how I see it. > > > > The community and the project doesn't have a vision yet. The > > community is small, mostly composed of people using James in > > enterprise context or paid to work on it. > > > > Apache Foundation projects should not be led by a single company > > so > > Linagora is not taking the lead on this side. > > Why do you state this? Is there some rule? Or you are worried about > appearance? It's a rule as far as I know: projects have to be neutral enough (not tied to a single vendor). > There is indeed a really heavy Linagora presence here. I think it’s > great, and I really appreciate your caution. Just to be clear, I'm not working on Linagora's projects anymore. I'm here as a individual contributor. > Without yet agreeing to this point, I don’t mind acting like a > moderator to capture the vision. As a moderator I can stamp my name > on it to assure the community that it is not too biased in favor of a > single company. > > > > It means to me that the best we can do as contributors is to > > contribute to the project in a way that is useful to us and try > > to > > welcome newcomers as well as we can. > > > > If the project is valuable to us, it will eventually be valuable > > to > > others. We have to stay commited to it for the time being, > > continue > > as we did for the past years. > > > > I can't see any vision that the community would be able to commit > > to, so let's say it's just a project that wait for its hour of > > glory. > > 😀 > > Well, I think we’ll have to be a bit more proactive, but let’s > continue this discussion to see where it takes us. I think from what > we experienced over the past few months that for a slowly evolving > project like this, the Documentation actually seems to be a great way > to capture all these ideas. We can debate the contents of the docs > and as a nice side-effect resolve issues like: should there be a > roadmap, and if so, what should it contain? > > Thanks a lot for always putting in so much effort and thought into > this. I hope we can have another live chat soon. > Thanks for your feedback too. -- Matthieu Baechler --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
