Indeed, we need to bring these email discussions to the surface, i.e., please create proposals on the Wiki within the one below.
https://cwiki.apache.org/confluence/display/NETBEANS/Apache+Transition Gj On Tue, Oct 25, 2016 at 5:16 AM, Wade Chandler <cons...@wadechandler.com> wrote: > For me it is about the solid unit of work, not so much the tests, but they > are a required piece of good development. Why keep so much locally until it > is a full unit or commit a lot of less than finished yet testable thoughts? > Many features take more than a day if not your day job. > > Too, it gives you the individual good visibility into the changes. It also > makes working with another easy. The process is simple as well. I think > probably where people get crazy is the squashing locally and not merging > from the PR. The PR has a beginning and end hash code; a set. So, if it > needs pulled out, it is able to be done, and it reduces some of the > ceremony, but too, GitHub has solved the squashing problem I believe. > > https://github.com/blog/2141-squash-your-commits > > Either way, sure, the more process the more time, but a bunch of little > commits to development or master with 2℅-N℅ baked ideas isn't great either > IMO. At least using PRs, a full thought is baked into the merges, and to me > is the benefit. > > NB dev had always used reviews where API changes are involved, so to me > that part isn't new, but how branching is used as well as logical units > being fully merged would be. They had team branches/repos before, and was > essentially to limit collision. The same benefits come from feature > branching and PRs, and is scalable to the whole community. > > My proposal would be to use PRs for everything, feature branches for > committers, clones for non-committers, reviews happen there, as well as > non-committers contributions, squash if desired, but let GitHub do it for > you on PR merge, and then automation and test builds on development/develop > (where work happens), with master getting auto merged based on automation > results. Committers should be responsible enough to have already ran their > tests before asking for PR review and merges, and of course committers > should run tests from non-committers PRs to make sure things pass a sniff > test as well as review expected tests exist. > > That matches a lot of various git flows out there. > > The release cycle, how we tag, etc needs hashed too. > > On that, I propose the dailies come from master, as a usable build, like > the current main-golden, and then RCs are based on dailies which reach a > point of maturity. During the release hardening phase, no new features or > contributions are merged to development, but bug fixes etc are, a merge > freeze for some things, we harden, vote on the release, tag, release, and > roll it out. The merge freeze is released, and life continues on. > > That means the major branches are simply develop and master. There wouldn't > be release branches with some merge freezing, the hardening and releasing > would happen through the normal flow on develop and master respectively. > > We don't currently support multiple previous major release versions of the > IDE or platform, so I think that suits it well. When we don't bump the > major version, NB is rolling release capable per the update center. That > model also suits that well. > > Hopefully that sets things up process wise for faster and smaller releases > to get contributions into users (and contributors) hands sooner. Long > release cycles make it hard to get good return on investment for committers > without using dailies; which to me also favors feature branching and PRs > for more fully baked merges. Which may not always be a bad thing, but > probably not for users. > > I do wonder on the versioning however. Previously the major version bumped > arbitrarily based on the Java version. Is that a strategy to keep, and why? > On one hand, it has some cadence and nice tie into the Java ecosystem, but > on the other, NB is a great IDE for other tech. > > I think there are a few topics here. Each one I think needs some discussion > and voting. Do wiki documents facilitate comparing proposals for process, > or should we use email? > > I see: > 1. Git workflow > 2. Continuous Integration and Daily builds > 3. Release cycle management > 4. Release cycle time > 5. Release versioning > > If we setup some pages, then we can add proposals which can be compared, > and commented on in the wiki. Those can be referenced for voting. Maybe > these pages are already on the NB wiki, I haven't looked in a few days (day > job has been slammed). > > Opinions? > > Thanks > > Wade > > On Oct 24, 2016 4:20 PM, "Mark Struberg" <strub...@yahoo.de.invalid> > wrote: > > > I’ve seen this being used in a very productive way utilizing Gerrit. But > > apart from that it’s too error prone imo. What is the benefit of having a > > temp branch which needs to get CI-ed + pulled over to master from just > > running the tests locally? > > Ofc I assume that most of the tests run in a decently well performing way > > so everybody first runs the local tests before she commits. In most ASF > > projects we use CTR (commit, then review) and people ship patches or push > > their changes to github and send a mail to the list if they do changes > > where they have a feeling that it might break something. Or if they just > > need some feedback before they commit it. > > Of course, each project has different requirements and maturity level. > And > > I know that there is currently probably only a hand full of people who > can > > judge whether a NetBeans commit is good or no - but this exactly what you > > like to change, isn’t? > > So in practice it really works well without any technical restrictions. > > This is of course just my personal opinion without any impact on what you > > going to pick. > > > > LieGrue, > > strub > > > > > Am 24.10.2016 um 02:41 schrieb Wade Chandler <cons...@wadechandler.com > >: > > > > > > These processes are used all over OSS projects in GH and Bitbucket. > > > Googling for them yields many results. One of my emails linked to the > > main > > > GitHub page. See Ate's email on another thread for a link to how other > > > Apache projects are using them. Development doesn't come to any form > of a > > > standstill in my experience, but rather is pretty fluid. If nothing > else > > it > > > gives clear units of work, even if the reviewers are the coders, and > > leaves > > > a PR in a merged state which can even retrospectively be reviewed if > > needed. > > > > > > Wade > > > > > > On Oct 23, 2016 1:54 AM, "Emilian Bold" <emilian.b...@gmail.com> > wrote: > > > > > >> You don't need to be a committer to do a PR. Development will come to > a > > >> standstill if all the main committers would have to go through this. > > >> > > >> Seems to me that if you trust somebody to vote her to be a committer > you > > >> trust her to actually commit code without being vetted by someone > else. > > >> > > >> I know about the team repositories, main-golden and main-silver, the > > >> releases/ repository with the version branches, the tags, etc. > > >> > > >> But now that I think about it, I kind of learned it in time, I haven't > > read > > >> it all in one place. > > >> > > >> This workflow certainly is documented somewhere. Could we see it? > > >> > > >> Then we can judge if the Apache infra and usual processes are a good > > match. > > >> > > >> > > >> > > >> > > >> > > >> --emi > > >> > > >> On Sat, Oct 22, 2016 at 7:37 PM, Wade Chandler < > > cons...@wadechandler.com> > > >> wrote: > > >> > > >>>> > > >>>> On Oct 22, 2016, at 12:21, Emilian Bold <emilian.b...@gmail.com> > > >> wrote: > > >>>> > > >>>> I also wouldn't mind if we use code reviews. > > >>>> > > >>>> But code reviews don't make sense for every NetBeans commit. > > >>>> > > >>>> By definition a committer will not need approval to commit code. > > >>> > > >>> To me this is more of a community agreement, but one I’m in favor of. > > The > > >>> projects I work on in both GH and Bitbucket use PRs, and that process > > >> works > > >>> out really well. I think it is fair that even committers come > through a > > >> PR, > > >>> and get a review. We should be able to find at least “1” other person > > >> for a > > >>> review. Otherwise what processes are we doing to use? There are going > > to > > >> be > > >>> N number of orgs and individuals coalescing here. > > >>> > > >>> Every commit doesn’t go through a PR either btw, but instead it is > > based > > >>> on a feature branch, and thus it could be 1-N commits in a given PR. > > >>> Personally I think the only direct “develop” or “development” branch > > >>> commits should be to fix a broken build, if it is a couple lines, but > > >>> otherwise, using PRs keeps things sane, and too, gives a nice > historic > > >>> record of sets of changes grouped as wholes, and that “whole” of a > set > > of > > >>> work is what is reviewed in a PR. > > >>> > > >>> Wade > > >>> > > >>> =================== > > >>> > > >>> Wade Chandler > > >>> e: cons...@wadechandler.com > > >>> > > >>> > > >> > > > > >
