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" <[email protected]>: 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 <[email protected]> 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" <[email protected]>: > > 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 <[email protected]> > 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" <[email protected]>: >> >> 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 <[email protected]> >> 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" < >> [email protected]>: >>> >>> 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 < >> [email protected]> >>> napisał(a): >>> >>>> 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 >>>>> >>>> >>>> >>>> >>> >>> -- >>> >>> 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>* >
