Hi Harbs, makes sense.
Chris Am 28.05.20, 10:48 schrieb "Harbs" <[email protected]>: Hi Chris, Thanks for you work helping with the 0.9.7 release as well. I’m definitely open to improving the structure and the process. My biggest hesitation is that I don’t understand the current release process well enough. Until recently Alex was the only one who really understood it. Yishay just went through the process so he has a good understanding now. I plan on doing another release the week following next (i.e. starting June 7 or so). My hope is that I will understand it better at that point. I don’t know whether Greg Dove is willing to do a release, but I think it would be very valuable to get his input as well. So my proposal is that we get some more of us familiar with the what and the why of the current process. I want to understand what was done and why it was done. I don’t feel comfortable having an opinion on changing things until I can weigh the pros and cons. I’d like more of us to be in the same position so we will be in the position of building consensus on changes. The reason I hope that Greg Dove specifically does a release is because I feel he’s pretty neutral on technology and I think he’ll have good valuable input. So here’s my proposal: 1. Let’s work on doing another 2-3 releases in rapid succession without making too many changes. 2. Let’s try and get as many of us familiar with that process as possible. 3. Once that’s done, let’s discuss the pain points and what can be done to improve the structure and/or the process with pros and cons. Maybe your suggestion is the way to go? Maybe something else? Similar? Don’t know, but I’d like to get to the point where we can have an intelligent discussion on the topic with different points of view. I don’t think we’re quite there yet. 4. Carefully start implementing changes. Making big changes is often disruptive and is often the cause of conflict. This is nothing specific to us, and there’s even accepted advice on the topic. I suggest we all read and follow James Duncan Davidson's “rules for revolutionaries”[1]. I appreciate having your proposed changes to ponder the next couple of weeks. In the meantime, please by all means, dive into Royale and create issues, pull requests, let us know difficulties, etc. I’ll make my best effort to be as responsive as possible and help where I can. If you’re feeling frustration, please reach out to me on Slack. Does this make sense? Harbs [1]http://s.apache.org/rules_for_revolutionaries <http://s.apache.org/rules_for_revolutionaries> > On May 28, 2020, at 10:56 AM, Christofer Dutz <[email protected]> wrote: > > Hi all, > > congrats to the successful release of 0.9.7 … it greatly simplified the last PLC4X release to have the artifacts out there in the wild. > > I would really like to see Royale as the tool in my toolbox for building industrial UI applications as I sort of am not that happy with the other existing alternatives. > > In order to do this I know that I have some areas of expertise I can offer to the project … Writing ActionScript and MXML code is definitely not where I can help best. > > However I’m really good at Java, Maven and Apache Infrastructure. I know that development is most active in the ASJS repo but I would be happy to help on the other sides ... perhaps even help the automated testing in the ASJS repo. > > I would have one proposal on how to really simplify things, but I would be hesitant to start working on this before we have consensus on this here. > It would probably involve multiple weeks of full time work in total to do it for me, but I would be happy to do it, if the project would accept it in the end and you folks would be willing to help with the parts I’m not too deep into (Ant-, NPM build adjustments). So that’s why I’m bringing this up here first. I know it might question some unwritten project rules, but I would kindly ask you to not just block the discussion and perhaps help re-evaluating why they became “project rules” and if the assumptions were correct or still apply. > > The benefit would be: > > * Less problems in getting set-up (just clone one repo) > * Simpler release (Only need to release one repository … no updating of version information in-between) > * Less things that can go wrong (I remember when compiler was already in 0.9.8-SNAPSHOT but the rest wasn’t yet … there were issues discussed on the list) > * I would use the opportunity to clean up some things in the maven build, because despite the probably common assumption … I’m not really happy with the usability of the maven build from a user’s perspective … I think there’s great room for improvement > > In general I would propose to merge all 3 repositories into one. Right now the Maven build would probably work with different releases of the compiler or typedefs but from what I can see … the Ant release would probably not work without modification. So the whole idea of releasing separately seems to be more a theoretical one. I think in the history of FlexJS and Royale it hasn’t been done once (please correct me if I’m wrong). If there are external entities only interested in consuming parts of the project, we could build source distribution for these that only contain the parts they are interest in. > > > * I propose to move the artifacts needed for the build but not being part of the build (build-tools, jburg-types) into a separate repository where they can be released independently and don’t cause confusion like they are doing right now. > * Then I would like to create a new repository (Let’s call it “royale”) which contains 3 directories: compiler, typedefs and asjs (or even with the current “royale-“ prefix, I don’t really care/mind). > * Now comes the biggest block … I would need to completely rewrite the royale-maven-plugin … the core of it would be also moved to the new build-tools repository. This plugin would sort of be an empty skeleton to load compiler plugins. This is needed as Maven can’t build a project where a plugin used in the project is also part of the build itself. So we couldn’t build all-in-one go without this change. > * Next step would be to add a new royale-parent pom in the new root of the project, the 3 old parents would be updated to use the new parent and a lot of duplicated configuration could be moved there, hereby greatly simplifying the 3 old root poms. > > A migration plan, could be to : > > * create a feature-branch in all 3 repositories > * create two new repos “royale” and “royale-build-tools” (or whatever you want to name them) > * Start with using git submodules to import the 3 branches into the new (I know submodules really suck, but they would only be needed until everything is finished) > * I would move/copy the build tools to the new repo and start working on the new maven plugin > * Then I would need to update the old compiler repo to produce something I can use as royale-maven-plugin plugins > * After that’s done I would update the typedefs to use the new plugin > * After that’s done I would update the asjs repo to use the new plugin > * Then I would add the new royale-parent pom > * After that’s done I would simplify and deduplicate the configuration > * Now I would definitely need some help with adjusting the Ant and possibly NPM build to these changes (Most of them should be profile-names and maybe directory names or paths) > * The last thing that would be required to be done now would be to remove the submodules in the “royale” repository and to import the real repos > * After this the 3 old repos could be archived > > I am really looking forward to some open discussion on this. > > > Chris >
