** Introduction **
Albert indicated: "It seems to me that nobody really understands how to go about releases [...] Currently, everybody seems to be waiting for someone else. To get out of this deadlock, I think we should start working according to the ESCET organization
structure. [...] Within the ESCET organisation, I think the project leads are the persons that should take steps here."
In general, I see us all as a team (project leads, committers, contributors). While there is some formal hierarchy, in practice I prefer to work together as much as possible. Specifically, I don't think that Bert and I as project leads should decide this
unilaterally. Also in the Eclipse Foundation Project Handbook typically not much distinction is made between project leads and committers, together the 'project team'. It in particular indicates that "The project team is responsible for determining development
methodology, establishing plans, etc.", "A Project Lead, the first level in the Project Leadership Chain, is responsible for the overall well-being of a specific Project and serves as the primary liaison between that Project and the EMO." and "The project
lead is more of a position of responsibility than one of power."
I also don't agree we're all waiting for someone else. I actually like the discussion we're having about release planning, with various viewpoints and with many different ideas being discussed. Clearly we're not there yet, several things are not yet in
place yet, and other things could be improved. But we're discussing it, and doing so together.
Albert proposed to "make a general plan, some sort of framework, a project-wide agreed collection of standard questions and decisions about releases in general, what steps to take for a release, who to inform, how, and perhaps when, etc." to "hopefully
[avoid] the current confusion and resulting lack of progress." I think that is exactly what we're working on at the moment through these discussions.
Albert also indicated: "If we want a more formal process, steps should have a list of roles that should give input, and a list of roles that should agree, but I am not sure this is necessary [...]". I agree with that. My preference would be to keep it
light, and not too formal.
** Questions **
As we're discussing many things, I'm getting a bit lost on where we stand for several of them. I hereby create an overview of the topics and questions, before providing a summary for each topic and my own opinions and proposals.
Release frequency:
- Do we use time-based releases, feature-based releases, or a mix of both?
- How often do we want to release? (also relevant for feature-based releases as it determines how many features to put into a release)
Planning ahead:
- How many releases ahead do we want to plan?
- In how much detail do we want to plan ahead?
Community involvement:
- How do we ensure the community is involved?
- How do we 'collect' ideas and plans from the community?
- How do we ensure the community knows of our plans and discussions?
Openness/transparency:
- How do we ensure we're open and transparent?
** Release frequency **
I earlier proposed quarterly time-based releases. This ensures regular and predictable releases for our users, without too much release overhead. Bert indicated being in favor of this. Bert and I both indicated this should not be set in stone, and we can
always decide for specific releases to e.g. choose a shorter period or make it feature-based. This would be one of the things to discuss for each release.
This proposal provides guidance (quarterly time-based releases by default) and flexibility (per release option to deviate). What do you think?
** Planning ahead **
I see two extremes: 1) don't plan much, just create issues along the way, and work on them, vs 2) have long detailed discussions resulting in complete detailed plans for current and future releases. Obviously this is a spectrum, with many options in between.
For inspiration, I looked at other Eclipse projects. Several have no release records for future releases at the moment, e.g. EGit, JustJ, Buildship, QVTo and EclEmma. Some have a release record, but no actual plans listed, e.g. PDT. Others are very brief,
listing a general statement like "Bug fixes, feature enhancements, performance improvements targeting SimRel 2021-06.", e.g. EMF and Oomph. Quite some projects use list of issues, e.g. Platform/JDT/PDE, Sirius, Graphiti, Trace Compass and Xtext. My quick scan
did not really reveal much detailed planning, although it could be that it exists but is not part of the release plan/record.
Bert, Albert and I have all indicated some (longer term) planning would be a good idea. Obviously, for the next release this would be more concrete than for further away releases. The question remains how long ahead do we plan, and in how much detail?
Bert indicated: "I think the problem here is time available for contributors. So in principle, if anybody want to fix something in cooperation with others, in the way Ferdie and Dennis are working, I am happy." This would be more towards 'extreme 1' on
the spectrum.
Albert considers this "not truely planned, and imho not long term sustainable since eventually you'll run out of low-hanging fruit." and also indicated that "While randomly making decisions is also a form of planning, I am not quite sure we should aim
for that."
I'm not completely sure about this yet. Some
more planning may be good, but I'd like to keep it simple and light rather than complex/length and complex.
I don't have all the answers/wisdom here.
What are your ideas to make this more concrete?
** Community involvement **
Albert indicated: "You seem to have a good grasp of what to aim for, but I think not everybody has thought that far. As a result, the discussion isn't quite happening." and "A handful of people read this, about half of the project members involved in the
project [...]" As a project we're open, anyone can contribute. We're also transparent, as we discuss everything on this escet-dev list, in GitLab issues, etc. If the 'other half' is not involved, I wonder how to get them involved?
I can't force them to join this list, submit issues, think about what the project should aim for, etc. We can obviously solicit their input by talking directly with them. But in my opinion, in general, it is up to them to get involved, or not. All we can
do is be welcoming and invite them to join. What we can discuss, and change, is the medium of communication. I earlier proposed it may be good to invite everyone for an online discussion (e.g. Teams call). Would that help? Do you see other ways to get more
people involved?
Albert further indicated: "Likely at least half the project members don't even know that this date exists [...]", "[...] with the long-term deciding people pretty much completey missing afaik." and "[...] Last but not least, I just wrote the above without
discussing it with others in the project."
An Eclipse project has project leads, committers and contributors, not considering the PMC, EMO, etc as they won't be actively involved at this level. As an open source project, in my opinion, if people are not involved, they don't get a say, and thus
can't be 'deciding people' and there are no 'others in the project' or 'other half of the project members'. This may be a bit of a bold statement, but maybe it helps the discussion?
** Openness/transparency **
As an Eclipse project we must be open and transparent about what we work on. We must openly indicate and discuss beforehand the ideas we have, to allow the community to work and discuss with us. We must also be transparent, meaning we must not work on
an issue in some external non-public repository and contribute the whole work afterwards in one go. We can't enforce this for contributors, although we can suggest and stimulate this. For ourselves as committers however, we must operate in this way.
Regarding openness, in my opinion, just creating a GitLab issue or discussing something on the escet-dev list can be enough to make our ideas known. Regarding transparency, we must work in branches and regularly push commits to the official Eclipse ESCET
GitLab repo. This is also described in the Eclipse Foundation Project Handbook.
This too is a work in progress I think. As an example, consider issue 63 (rail diagram generator). It was contributed more or less once development was finished. I realize in this particular case development probably started way earlier, maybe even while
working on our initial contribution. But in the future, we should avoid this. I wonder how this will for instance go for the new CIF PLC generator. It was announced/discussed on this list and in GitLab issues, but itself has no GitLab issue yet. It appears
some code is present somewhere, but it is not being developed in the transparent way as described above.
** Release v0.2 **
In the interest of progress for v0.2, and with discussions on structured release planning still in progress, I set the preliminary release date for v0.2 on June 30, 2021. I proposed some topics to work on, mostly left-overs from the initial contribution
and release v0.1, such as fixing long-standing bugs, documentation setup/output improvements and release engineering related things.
Bert indicated: "I see a lot of bug being fixed and am very pleased with progress." Albert indicated: "[...] what is currently happening in "develop" [...] like you I am very happy about it [...]" I'm pleased with current progress as well, so we seem to
agree on this.
Albert does indicate that "[...] the entire 'release' discussion is not about what is currently happening in 'develop'. [...] it's pseudo-planned at best." I think that's what these release planning discussions are all about. As they're in progress with
no final decisions yet, I think short term we can keep working on v0.2 as is for now.
Regarding the release date of June 30, Bert indicated: "I would be very happy if we could release v0.2 en of June with as many bugs fixed as possible along with some other issues." and "[...] since my class of 180 students will start in September and I
would like to have some time left for using the release." He had the idea that "we all agree on the June release date for v0.2 as it is defined and going now." I indeed agree with that. Does anybody disagree?
Dennis