Firstly, I want to apologize for my 'whim' comment, which is indeed
overly general without context. I was specifically referring to
https://github.com/eclipse-platform/eclipse.platform/issues/7 where the
idea was to merge eclipse.platform and eclipse.platform.team and where I
could see no basis for that decision, making it feel like a whim.
Your comments below are super constructive and basically outlines a
strategy for a plan. I think this excellent content should go in an
issue, e.g., #7 , where it can guide the decision making process because
you perfectly outline the factors to be considered which we shouldn't
lose in this endless email thread! Maybe some other folks will also
have some additional considerations that should be taken into account.
With "just" 15 repos, it should not be too difficult to at least outline
plan for which ones we'd like to combine, guided by informed choices.
E.g., I was super happy with
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/24
which gathered all the migration information in one place. We could do
the same thing again for this merge topic, I hope...
On 31.03.2022 11:19, Aleksandar Kurtakov wrote:
On Thu, Mar 31, 2022 at 10:54 AM Ed Merks <ed.me...@gmail.com> wrote:
I think the broader generalized message here is "please let's make
decisions as group".
Merging repos now feels like a whim. I'd personally like to see a
documented strategy of which repos we will have when we reach the
end point. Why only these? Why not more, like what we have now?
Why not have just one?
I'm not arguing for nor against merging. I would just really
appreciate understanding the strategy and seeing a plan so that we
committers could comment on a cohesive them. This affects us all
and we should all be included...
So this is not a whim but rather a long going effort started years ago:
* https://www.eclipse.org/lists//eclipse-pmc/msg03054.html - merging
projects was just the first step. The artificial separation between UI
and UA for example was a nightmare at organizational level which we
fixed but it stayed at code level.
* https://bugs.eclipse.org/bugs/show_bug.cgi?id=475932 as an example
that made it possible for version checks to work (it can't detect
multi repos) so releng was freed from one more case where we had to
jump in.
So let me explain what my vision is. There are certain questions which
drive it:
1. Is the current state of XYZ creating extra work which we can
reduce? E.g. few more commits for each new stream, separately
maintained Jenkinsfiles, build scripts update, non functional version
checks and etc. that could all be reduced
2. Will such a change make it better or harder for committers and
potential contributors in the long run? E.g. repositories to clone,
ease to setup new development machine, finding your way in the code.
3. Will such a change make it better or harder for the releng team in
the long run? E.g. build automation, using more standard tools, giving
better reports/feedback to developers for their daily work
4. Do we have a deadline? E.g. service will be terminated, lower level
dependency will no longer be part of the next version of OS and etc.
5. Do we have any limitations that prevent us from doing that change
now? E.g. too slow build times destroying CI feedback
So can I say that there is a strategy based on ^^ - Yes and no.
So the current strategy is to look up for cases which will have "Yes"
as an answer to 1-3 and after that analyze 4. and 5.
If there is a deadline act fast so we are ahead of the deadline (I
still remember the time when we had no builds for certain period as
all scripts and etc. were run by committer account with cron jobs on
machines not being accessible and the stress from that) so I'm 100%
convinced that at the first point a change is "inevitable" it should
be acted upon.
Last comes 5. - quite often it requires some reorganization and even
further changes to make it work. Merging all platform repos would not
work right now as it will make CI response time totally unbearable but
this doesn't prevent doing steps in that direction.
E.g. merging platform.team into platform:
* releng will simplify as even on the next cycle we will save time and
more automation will kick in as there would be less limitations
imposed by git repos boundaries
* both build in less than 10 minutes on CI and big chunk of of time is
actually spent in downloading dependencies (huge overlap for both
repos) so combined build would probably be not more than 2-3 mins
slower than building them separately
* committers will have to clone one less repo next time they setup new
machine, short time inconvenience could be having to change local
scripts/setups
* is our setup harder or easier to understand with such a change -
https://git.eclipse.org/c/platform/eclipse.platform.team.git/tree/
shows and explains nothing about this repo - is it smth about the
eclipse committers team to do or actual team provider? and the new one
https://github.com/eclipse-platform/eclipse.platform.team is not
better, the worst part is we got used to it and no longer question it,
it becomes noticeable only now because new tools stress on these
things. This makes me believe that the setup will improve if they are
merged as there would be less potential misunderstanding and guidance
needed for people to find where to get the code, submit patches,
report bugs, etc.
So is all of the above some grand plan? No. Having a plan requires
being able to set dates, plan work, etc. which we don't have the
luxury anymore. The surrounding ecosystem changes so fast (Java 19,
Win 11, Gtk 4, ..... all out of our control and we being at the mercy
of what JDK devs put in Java 19 or GTK devs put in GTK 4 or Microsoft
puts in Win11) that we are forced to act reactively quite often. Of
course, I wish we were able to react to all these changes and still
execute "our" plan. Unfortunately, this is not the case and quite
often these "reactive" changes even eat the time for planning.
That's why I stopped even looking or trying to do grand plans.
"Pruning" as done in orchards seems to be quite good explanation of
the workflow - the roots are strong enough for X number of fruits,
prune some branches that have "defects" or even just growing in the
wrong direction and preventing others to see enough sunshine/air,
create comfort for "master" (ecj, swt...) branches as without them the
whole tree would be compromised, look for ways to "fertilize" ( direct
maven usage) and so on. The most important thing there is realizing
that what looked promising in the spring may happen to be broken by
summer storms and requires significant changes in the way you plan the
tree's growth.
Please share your thoughts on all of the above as I fully agree with
Ed - we have to decide where we want to go? do we want to go to the
same place? and can we do it?
--
Aleksandar Kurtakov
Red Hat Eclipse Team
_______________________________________________
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list,
visithttps://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
