I think PRs can be useful, but should be voluntary. I prefer to create a PR if I’m unsure of my changes, e.g. in the compiler code.
From: Piotr Zarzycki<mailto:[email protected]> Sent: Friday, June 19, 2020 3:09 PM To: Apache Royale Development<mailto:[email protected]> Subject: Re: Using PRs for commits Hi Guys, In my opinion Royale is not the type of project which can handle PR way of work. I've been working like that in one company and it has great benefits, but only if: - You are working every day on repository - payable job - Your active Team is bigger than 2-3 people - if one person won't be able to take a look into your PR - someone else can. It doesn't make sense to have PR way of work if there is no people who can look into your code. Disadvantage is that - creating PR is slower than pushing commit to repository - no matter how got you are in that. You may also experience during merge of PR conflicts - which is not the case if you commit straightforward into the main branch. Thanks, Piotr pt., 19 cze 2020 o 12:34 Carlos Rovira <[email protected]> napisał(a): > Yeah, sometimes is difficult to remember. I end going through all changes > in repo to add release notes when we release. > Also I think is important to add some working example for two reasons: > > 1.- To ensure code is compiling (then we need some it-tests too) > 2.- As a way to see how to use something. > > For Jewel, I use to add it to TDJ > > > > El vie., 19 jun. 2020 a las 12:00, Harbs (<[email protected]>) > escribió: > > > > > > For example yesterday I added Jewel SimpleLoader. Don't think that kind > > of > > > change will need to be a PR. > > > > Agree, but we should have some way to quickly see additions. Maybe > > immediate update of release notes? A quick note to a wiki page? > > > > > On Jun 19, 2020, at 12:56 PM, Carlos Rovira <[email protected]> > > wrote: > > > > > > Hi, > > > > > > I'm for what Alex suggests. Just email with some kind of "[Breaking > > > Change]" or "[API change]" warning, so we can discuss. > > > I think that would be more easy and will continue to make all flow and > > > avoid freezing. I think the problem is things like my > > > change of "BrowserResizeHandler". > > > > > > For example yesterday I added Jewel SimpleLoader. Don't think that kind > > of > > > change will need to be a PR. > > > > > > I must say that, in my mind the 1.0 version is what makes us to be even > > > more careful since it's what a major version dictates. > > > But it's real that we are currently in something that many of us > consider > > > 1.0, so we should be more careful since now. > > > > > > thanks > > > > > > > > > > > > > > > El vie., 19 jun. 2020 a las 9:05, Harbs (<[email protected]>) > > escribió: > > > > > >> Seems like a reasonable approach. I already try to do this. > > >> > > >>> On Jun 19, 2020, at 8:24 AM, Alex Harui <[email protected]> > > >> wrote: > > >>> > > >>> The cheapest solution, IMO, is just to get everyone to agree not to > > >> change APIs in Basic without prior discussion. Probably major > code-path > > >> changes too. > > >> > > >> > > > > > > -- > > > Carlos Rovira > > > http://about.me/carlosrovira > > > > > > -- > Carlos Rovira > http://about.me/carlosrovira > -- Piotr Zarzycki Patreon: *https://www.patreon.com/piotrzarzycki <https://www.patreon.com/piotrzarzycki>*
