Hello, This whole discussion is valid (personally, I think all contributions should be considered, and I'm talking beyond the NB9 milestone), however nothing of this answers my former question. I was talking about coding style guidelines (no matter if we're fixing a bug, adding a new feature or just refactoring). Perhaps we can borrow the general Java project directives.
Regards, Charles Edward Bedón Cortázar http://www.neotropic.co | Network Management, Data Analysis and Free Software | twitter.com/neotropic_co Open Source Network Inventory for the masses! http://kuwaiba.sourceforge.net | Follow Kuwaiba on Twitter <http://twitter.com/kuwaiba> Linux Registered User #386666 On Fri, Jan 12, 2018 at 5:18 PM, Eduard Karel de Jong <[email protected]> wrote: > To add my 2¢ to this discussion: > > To make these ideas more concrete, in my view, the result of the current > vote would be that at its closing a clearly marked branch is created that > implicitly freezes the feature set. A voter, when submitting a vote can > propose one or more PRs that should be included with the understanding > that such a PR should address a bug. Bug should be taken as not only > addressing reported code failures but also glitches and confusion in user > facing functions. Indicting multiple PRs their order could be interpreted > as a priority. > > A rule like this could be codified somewhere and then included when > calling for a vote. I haven't checked if other projects have something like > this, though, and there may be better ways to get the kind of process we > need. > > Cheers > Eduard > > Christian Lenz wrote: > >> If we are now at a Feature freeze, we should create a release/nb9 branch >> to make it clear, no new Features there and some documentation and so on. >> Everything else, so other PRs can still be handled in develop. >> >> Von: Geertjan Wielenga >> Gesendet: Freitag, 12. Januar 2018 11:41 >> An: [email protected] >> Betreff: Re: Pull requests need to be reviewed >> >> Yup, makes sense to me, Neil. We need to make these things explicit and >> indeed will take a look at the related NetBeans processes, though I agree >> however we’re looking at it we are now at a stage of feature freeze and >> should incorporate bug fixes only, ideally as part of the NetCAT phase >> post >> Beta — making it all the more urgent that everyone tries out the Beta >> artifact and specifies their vote on it in the vote thread. >> >> Gj >> >> On Friday, January 12, 2018, Neil C Smith<[email protected]> wrote: >> >> On Fri, 12 Jan 2018 at 08:04 Geertjan Wielenga< >>> [email protected]> wrote: >>> >>> I think we need to set up guidelines — e.g., a PR must be connected to an >>>> issue; a PR must solve a problem and not be cosmetic only; etc. >>>> >>>> I’d advise looking at pull/3 by Chris instead. >>>> >>>> I like Chris' PR, and see the benefit of it ... but, within those >>> guidelines are we going to have the concept of feature freeze? In my >>> opinion, if we're in beta vote phase, we should also only be accepting >>> bug >>> fixes. In which case, I'd be tempted to push that back to the next point >>> release? >>> >>> Out of interest, what were the old NetBeans policies around feature >>> freezing / release planning? >>> >>> Best wishes, >>> >>> Neil >>> >>> >>> >>> -- >>> Neil C Smith >>> Artist& Technologist >>> www.neilcsmith.net >>> >>> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org >>> >>> >> >> >
