| Re: [escet-dev] Eclipse ESCET v0.2 plans |
|
Hi all,
** 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:
Planning ahead:
Community involvement:
Openness/transparency:
** 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?
Van: escet-dev <escet-dev-bounces@xxxxxxxxxxx> namens Beek, Bert van <D.A.v.Beek@xxxxxx>
Verzonden: maandag 10 mei 2021 13:04 Aan: escet developer discussions <escet-dev@xxxxxxxxxxx> Onderwerp: Re: [escet-dev] Eclipse ESCET v0.2 plans Hi all,
I get the idea that we all agree on the June release date for v0.2 as it is defined and going now. The question then is what will come after that. I like the idea from Dennis to (in principle) aim for time-based releases. However, I would not see that as carved in stone. If at some point in time somebody would like to see a plan for a feature based release, for some specific feature (e.g. the new PLC code generator), that should be possible in my opinion. @Albert: what do you think about this? Bert > On 10 May 2021, at 09:16, Hofkamp, Albert <A.T.Hofkamp@xxxxxx> wrote: > > Hai Bert, > > > > It seems to me that nobody really understands how to go about releases, so I would say that needs to be discussed and agreed upon first before trying to release things. Currently, everybody seems to be waiting for someone else. > > > I don’t understand this. I see a lot of bug being fixed and am very pleased with progress. > > Dennis asked about a release plan, that is, some kind of agreement what we're going to aim for in V0.2 . > One form of such a release plan is a list of features that we'll try to get finished, but there are many forms. > > However, he did that out of the blue, without stating any boundaries. > > It makes a lot of difference whether you aim for feature-based releases (release when everything you promised is done), or time-based release (release when you pass the deadline with whatever is done at that point in time). > > It makes a lot of difference whether you aim for a deadline one year from now or one month from now. > > > > Thus the entire "release" discussion is not about what is currently happening in "develop". While like you I am very happy about it, it's pseudo-planned at best. Basically it's just ad-hoc low-hanging fruit being picked. Very useful, but not truely planned, and imho not long term sustainable since eventually you'll run out of low-hanging fruit. > > Instead, the "release-plan" discussion is about some form of basic general agreement within the project, and a set of standard decisions about all releases we'll ever do. Likely it also needs a set of standard questions that must be answered for making a release plan. [Just making educated guesses.] > > The global aim of such a general agreement is to reduce confusion and make everybody aware of what to do and who to consult when making such a plan. It should avoid the lack of progress in creating such a plan that you see now. > > > > I like end of June as release date, since my class of 180 students will start in September and I would like to have some time left for using the release. > > As said, I have no real objections against making a new release. > > From a release plan point-of-view though, Dennis just set the date all by himself in interest of the project. There was no discussion about it beforehand at all. Likely at least half the project members don't even know that this date exists since no project-progress information is exported beyond this dev discussion list afaik. > > While randomly making decisions is also a form of planning, I am not quite sure we should aim for that. > > Albert > From: escet-dev <escet-dev-bounces@xxxxxxxxxxx> on behalf of Beek, Bert van <D.A.v.Beek@xxxxxx> > Sent: Friday, May 7, 2021 11:07 > To: escet developer discussions <escet-dev@xxxxxxxxxxx> > Subject: Re: [escet-dev] Eclipse ESCET v0.2 plans > > Hi all, > > > On 7 May 2021, at 08:17, Hofkamp, Albert <A.T.Hofkamp@xxxxxx> wrote: > > > > Hai Dennis, > > > > > I've not yet received any responses on my proposal on my last message, see below. > > > > I didn't see any new leads to respond to. > > > > > > > be good to discuss the longer run, i.e. releases after v0.2 > > > > > I've just created a release entry for v0.2 ... june. > > > > I assume you're trying to make progress here, and that's good, but it looks like the wrong order of things to me. > > > > > > It seems to me that nobody really understands how to go about releases, so I would say that needs to be discussed and agreed upon first before trying to release things. Currently, everybody seems to be waiting for someone else. > > I don’t understand this. I see a lot of bug being fixed and am very pleased with progress. > > > > > To get out of this deadlock, I think we should start working according to the ESCET organization structure. > > > > > > One possible form on getting project-wide agreement on what to do, is 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. As an example that may be in those decisions, we probably should first have a target release date, and then ask ourselves what to aim for in that period (assuming time-based periods). > > 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 (ie the decision what to include or exclude in the framework is also something that should be discussed within the project in my view.) > > > > With a project-wide agreed framework we would have at least some agreed set of steps and their order, so everybody knows what to expect and understands what to do, hopefully avoiding the current confusion and resulting lack of progress. > > > > > > With such a framework, we can then make progress for release 0.2 and further (the latter should probably also be discussed in the framework, how far ahead do we go in planning?). > > 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. 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. > > > > > Within the ESCET organisation, I think the project leads are the persons that should take steps here. Given the scope probably the project board and committers should also know and agree. > > > > In any case, I am willing to give constructive feedback. > > > > ----- > > > > With such a framework, we can then make progress for release 0.2 and further (the latter should probably also be discussed in the framework, how far ahead do we go in planning?). > > > > [The framework doesn't look likely to be finished before June, which means the 0.2 release date should be moved or a decision needs to be made to go ahead (and likely include whatever is in the develop branch at that time).] > > I like end of June as release date, since my class of 180 students will start in September and I would like to have some time left for using the release. > > Bert > > > > Albert > > _______________________________________________ > escet-dev mailing list > escet-dev@xxxxxxxxxxx > To change your delivery options, retrieve your password, or unsubscribe from this list, visit > https://eur02.safelinks.protection.outlook.com/?url=""> > _______________________________________________ > escet-dev mailing list > escet-dev@xxxxxxxxxxx > To change your delivery options, retrieve your password, or unsubscribe from this list, visit > https://dev.eclipse.org/mailman/listinfo/escet-dev _______________________________________________ escet-dev mailing list escet-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/escet-dev |