| Re: [platform-dev] Intended Bug-Tracker for Platform-projects hosted on GitHub |
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 Thu, Mar 31, 2022 at 10:54 AM Ed Merks <ed.merks@xxxxxxxxx> 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 reduced2. 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 work4. 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 KurtakovRed Hat Eclipse Team
_______________________________________________ platform-dev mailing list platform-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev