Hi Greg, In my case I use to separate changes in commits that are related to some concrete topic, with descriptive info description. So, you use it to read the commits and understand what's all about. But when I see many changes in just one commit it used to confuse me since the description used to be not enough to understand the complete change. I think that depends as well on the size of the change. If something just implies some changes in a file, it's easier. But if the change involves many changes in many files it could be tricky to follow all.
One thing we don't use most of the time is to handle changes in tickets and make each ticket a branch. This is the way many companies work (included Codeoscopic). They plan changes, make tickets, and the employee in charge creates a branch for the tickets that could be one or more commits. As the ticket is done and tested the branch is merged into develop and the ticket is closed. Anyway, all that implies more work, and maybe we can't ask people to follow a protocol like that since it implies more time that maybe they don't want to invest. El vie., 19 jun. 2020 a las 23:39, Greg Dove (<[email protected]>) escribió: > I don't think PRs are practical for routine use either. > > > One suggestion I'd like to make about merges in general: > I'd like to suggest that for any merge from a branch or PR with multiple > commits, that we always try to do that as a single squashed commit. This > makes it easier to understand all the changes IMO when looking at > the commit logs. Should help with Harbs concern "More like being able to > see at a glance what has been done without wading through commit messages." > > > > > > > > On Sat, Jun 20, 2020 at 12:14 AM Yishay Weiss <[email protected]> > wrote: > > > 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>* > > > > > -- Carlos Rovira http://about.me/carlosrovira
