Maybe a heads up reminder to the dev and users mailing list re feature freeze coming up and pointing to the release schedule would be good.
Happy to do it too, though don't want to tread on your release manager toes. :-) Happy to take the process forward however you see fit, the quarterly release cycle idea is working out well and has provided a great deal of stability. Gj On Wed, Sep 4, 2019 at 8:49 PM Laszlo Kishalmi <[email protected]> wrote: > Well, IMHO > > GitFlow was a result of an over engineering. There was a big hype about > that around 6-7 years ago, I really think it is just for blind upper > managements to migrate to Git. I saw many projects at our company, > gitflow was usually pushed from above, though nobody is actually using > that, it is simply too bureaucratic. Maybe it could have benefit to have > a big project, probably with Waterfall methodology. > > We simply do not have that many contributor, and real feature streams. > My usual work is to create a branch from a fresh master with the JIRA > issue ID, push it to my local fork, and request for a PR on master. I > wish if we were in a position where such a workflow would be not > efficient anymore, dou to the large number of PR-s and committers, but > right now that is not the case. > > On 9/4/19 4:39 AM, Eric Bresie wrote: > > I think folks tend to work of master branch so maybe something different > could help some. > > > > Was wondering if the “gitflow” model may help in the branching process. > > > > http://datasift.github.io/gitflow/IntroducingGitFlow.html > > > > https://nvie.com/posts/a-successful-git-branching-model/ > > > > Eric Bresie > > [email protected] > >> On September 4, 2019 at 6:06:59 AM CDT, Neil C Smith < > [email protected]> wrote: > >> Hi All, > >> > >> I meant to kick this off a couple of weeks ago, but .. work .. > apologies. > >> > >> So, hardly has the dust settled on NB 11.1 and the feature freeze date > >> for NB 11.2 is just around the corner! From my perspective, I think > >> the release process for NB 11.1 went well, with a few caveats, but I > >> wanted to open up some discussion if people want to suggest possible > >> tweaks for NB 11.2. > >> > >> I think overall NB 11.1 showed we can meet our quarterly release > >> target, and a month is a realistic gap between freeze and release for > >> non-LTS. I realise we ended up a week later with NB 11.1, but this > >> was almost entirely due to allowing JavaEE / Payara support to go in a > >> week after freeze. That was my call to suggest, and I still think the > >> right one, but does highlight that we should try to get features in > >> earlier rather than later in the release cycle. It also highlighted > >> some issues we have with spurious failures in Travis leading up to the > >> freeze date, only one of which was an actual problem. > >> > >> From my perspective, freezing master to anything but fixes intended > >> for the release, and not cherry-picking, made things much simpler. It > >> also ensured we started NB 11.2 development (mostly!) from the stable > >> release state. How much of an issue was that for continued > >> development though? Do we definitely continue with that as was for > >> 11.2? > >> > >> We unfortunately had to revert a PHP 7.4 PR not intended for release, > >> and I take some responsibility for not communicating the master freeze > >> better. However, how did setting up a separate branch on the repo for > >> PHP 7.4 after that work in practice? Is this something we should > >> encourage more of anyway, whether in freeze or not? > >> > >> For NB 11.1 we needed a release branch from the start of the process > >> due to various changes that need to be made. Further work since may > >> mean that differences between release branch and master will be less, > >> but for NB 11.2 I think we'll still branch at freeze?! > >> > >> I wasn't sure when kicking off the process the best approach to > >> merging from master to release branch, and decided to try pull > >> requests. This actually worked really well, as by opening a pull > >> request early it meant that all merges to master got tested against > >> the release branch automatically, and we ended up with a page with a > >> clear view of differences from one beta to the next. I think that's > >> something to continue for NB 11.2. > >> > >> With the first (failed) voting candidate I made the mistake of fixing > >> a bug (in Payara Micro) from the previous beta, which in turn exposed > >> another bigger one! We should probably aim in future for no code > >> changes from final beta to voting candidate. If a legitimate critical > >> or blocker is opened against the beta, then we should always have > >> another beta with the fix prior to release voting?! > >> > >> There was some discussion afterwards on need to pull Maven artefacts > >> vote because of implementation versions / whether we vote on all > >> binaries / whether all binaries are included in the release vote. > >> Personally I still think we should keep vote to sources only, and just > >> have oversight on binaries from a few PMC members. But, if we are > >> voting for binaries we will need to decide whether to have one > >> (sources and binaries) or two (sources then binaries) votes. And if > >> we include binaries in the release vote, we'll need to rethink the > >> voting template and instructions we've used for all previous releases > >> to emphasise that binaries are *not* irrelevant to the vote! > >> > >> From the perspective of not landing major things in master close to > >> freeze, or seeking a freeze bypass, are we in a position where we > >> acknowledge C/C++ support isn't going to make it in to NB 11.2? > >> > >> I'm unfortunately really tied up until freeze date (Sep 15th) but am > >> keeping some time free afterwards. Once I get my head around the new > >> Jenkins task for release builds, which I assume we'll be using(?), I'm > >> aiming to go for weekly betas again, hopefully mid-week, until we're > >> ready for release vote. Maybe we'll see if we can even out the last > >> one and get this one out a week early! :-) > >> > >> OK, that's my brain dump on it all - any thoughts to add? > >> > >> Best wishes, > >> > >> Neil > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> For further information about the NetBeans mailing lists, visit: > >> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > >> > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
