I’m going offline for two days so I’ll be quiet for a while, but it might be a good idea to ask infra whether they have a solution to this problem.
Harbs > On May 28, 2020, at 5:36 PM, Christofer Dutz <christofer.d...@c-ware.de> > wrote: > > Hi all, > > well perhaps searching for some experiences with this ... > my gut-feeling would make me expect to have the wiki content replaced by > Viagra ads ;-) > > But it would be in git, so easily undoable .... > > I did find this however: > https://www.growingwiththeweb.com/2016/07/enabling-pull-requests-on-github-wikis.html > > It's less convenient way, but probably safer. > > Chris > > > Am 28.05.20, 16:25 schrieb "Harbs" <harbs.li...@gmail.com>: > > Hmm. That’s a problem I was not aware of... > > What do folks think about enabling public editing of wikis?[1] > > Harbs > > > [1]https://help.github.com/en/github/building-a-strong-community/changing-access-permissions-for-wikis > > <https://help.github.com/en/github/building-a-strong-community/changing-access-permissions-for-wikis> > >> On May 28, 2020, at 5:00 PM, Christofer Dutz <christofer.d...@c-ware.de> >> wrote: >> >> Hi all, >> >> so I just had a look ... it seems as if the "fork" feature on github doesn't >> fork the wiki too ... >> So I could create my own pages, but not create PRs for documentation ... or >> I just didn't find the docs on how to do it. >> Do you have any pointers for me? >> >> Chris >> >> >> Am 28.05.20, 13:55 schrieb "Piotr Zarzycki" <piotrzarzyck...@gmail.com>: >> >> Chris, >> >> We are not using confluence at all. We are using Wiki [1], but you can >> write document in whatever place you wanted to if you are not comfortable >> with wiki. >> >> Andrew, >> >> Will you be willing to translate that document into our Wiki manner ? >> >> [1] https://github.com/apache/royale-asjs/wiki >> >> Thanks, >> Piotr >> >> czw., 28 maj 2020 o 13:43 Christofer Dutz <christofer.d...@c-ware.de> >> napisał(a): >> >>> Hi Piotr, >>> >>> I think the Royale project could grant my user write permissions to >>> confluence. >>> Then I could write such a document there. >>> >>> But I could also do a google doc outside, if this is more convenient. >>> >>> Chris >>> >>> >>> >>> Am 28.05.20, 13:39 schrieb "Piotr Zarzycki" <piotrzarzyck...@gmail.com>: >>> >>> Chris, >>> >>> I think I would like to be after Harbs and eventually Greg. Yes you can >>> send me a link, write a document with absolutely EVERY step which I >>> have to >>> do in order to get release done. Even if you think that I know some >>> steps >>> like signing - you can in such places point into some existing >>> document. >>> >>> I would like to be able to comment on every step to confront if I >>> really >>> for example had to copy/paste some command or just opposite I had to do >>> much more than only copy/paste. >>> >>> Thanks, >>> Piotr >>> >>> czw., 28 maj 2020 o 13:27 Christofer Dutz <christofer.d...@c-ware.de> >>> napisał(a): >>> >>>> Hi Piotr, >>>> >>>> we could change the configuration to use the jgit plugin on the CI >>> machine >>>> and to use the default on local machines. >>>> In that case you could do it on any machine you want (also windows) >>>> >>>> Who does releases in which order using which tooling ... I don't >>> really >>>> care ... >>>> >>>> I'm just happy that there's a line building up of people wanting to >>> do so >>>> and I get to use fresh releases :-) >>>> >>>> If there is anything I can help with ... just ping me and I'll be >>> happy to >>>> help. >>>> >>>> Chris >>>> >>>> >>>> >>>> Am 28.05.20, 13:18 schrieb "Piotr Zarzycki" < >>> piotrzarzyck...@gmail.com>: >>>> >>>> Hi Harbs, >>>> >>>> I would like to be a release manager as well, but using Chri's >>>> implementation which as far as I know is in place. I would like >>> to use >>>> his >>>> mentioned 3 steps and see how much things I will have to do on >>> my own >>>> to >>>> make release happen. I know that I will have to do that on Mac, >>> cause >>>> there >>>> some Maven/Git/Jenkins related plugin which allows use Jenkins, >>> but it >>>> prevents me from pushing artifacts from windows. >>>> >>>> I have some thoughts about above proposition, but I will wait >>> till we >>>> all >>>> pass trough the release process. >>>> >>>> Thanks, >>>> Piotr >>>> >>>> czw., 28 maj 2020 o 11:06 Christofer Dutz < >>> christofer.d...@c-ware.de> >>>> napisał(a): >>>> >>>>> Hi Harbs, >>>>> >>>>> makes sense. >>>>> >>>>> Chris >>>>> >>>>> >>>>> >>>>> Am 28.05.20, 10:48 schrieb "Harbs" <harbs.li...@gmail.com>: >>>>> >>>>> 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 < >>>>> christofer.d...@c-ware.de> 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 >>>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> >>>> Piotr Zarzycki >>>> >>>> Patreon: *https://www.patreon.com/piotrzarzycki >>>> <https://www.patreon.com/piotrzarzycki>* >>>> >>>> >>> >>> -- >>> >>> Piotr Zarzycki >>> >>> Patreon: *https://www.patreon.com/piotrzarzycki >>> <https://www.patreon.com/piotrzarzycki>* >>> >>> >> >> -- >> >> Piotr Zarzycki >> >> Patreon: *https://www.patreon.com/piotrzarzycki >> <https://www.patreon.com/piotrzarzycki>* >> > >
