Hi, Thanks for the thanks, but lots of people a helping. I cannot comment every point but I wan't just put emphase on the PR review.
PR review should be green, but if red we should remove the warning that make RM/PR reviewer take 15mins to dig what is wrong. (If not internet issue with repository) For me, on approval, if a reviewer say yes and if there is an open question that shoudn't be possible. It should be unapprouved to me until question is answered. A RM is not necessarily knowing each face of NetBeans and know the impact of open question. (Different of request for change). I cannot remember how many time I asked it it's ok to be merged because of unclear comment. For beta and dev build, We have maven snapshots that's all restricted access to people who can connect to snapshot repos (commiter I guess). Can we use our netbeans-vm for that, with restricted access ? More sensitive, We should have a way to publish our native code (launcher, platform launcher,.. ) in a ASF way, sources + vote if we need to improve them. Maybe we should create another repo to handle that and maven can help. (because releasing with maven is 2 command line + vote ) On documentation We release installer, Apache NetBeans, Html4j, vscode and all the small utilities, snap package we should have dedicated triage page for RM to refer to. It was too short from 11.3 to 12.0 for me to handle that. But I would like to consolidate this point. Regards Eric -----Message d'origine----- De : Neil C Smith <[email protected]> Envoyé : lundi 15 juin 2020 11:11 À : dev <[email protected]> Objet : Re: [DISCUSS] NetBeans 12.0 Retrospective Couple of quick responses, and then let other people respond :-) ... On Sat, 13 Jun 2020 at 17:59, Laszlo Kishalmi <[email protected]> wrote: > On 6/13/20 2:12 AM, Neil C Smith wrote: > > I think we had problems between > > 9 and 10 like this, where the same issues recurred in 10? > Well, it might happened, maybe due to human error (me). However as far > as I remember, there were generally no problem cherry picking changes > from the master, No, nothing to do with you - there were a few times I remember noticing things that were fixed in release branches were not properly fixed in master because by the time of the fix they'd diverged. ie. bugs fixed in 9 were not as well fixed in master before 10. To me, it's the linear history, that next release builds on the previous release, that's most useful about freeze. > > We could stop having LTS, > > Well, I do not know, I'd probably open a separate discussion on that > topic. Yes, maybe, let's see where this goes - the question of why we have one and what it is keeps coming up. Of course, answering the latter might help with the former. > > If we keep LTS, we could have a month freeze again, then vote on a > > release candidate. > I'm not sure I understand this correctly, but: Let's do a 12.0 on > master like a regular feature release. but bring it just to beta > release, then release patches via UC. and once we think it is ready > for release, do another full release for voting and finally release > that one (assuming that it passed the voting round)? Yes, that's pretty much what I meant (and badly described)! I'd call it release candidate though. Currently we have betas that are not voted on and distributed direct from the build. Theoretically, under ASF rules those links should not go beyond dev@. A release candidate that was properly voted on and distributed via mirrors could be much more widely publicised. > > A general > > principle of, if the PR is ready to merge on Monday, it's in the > > beta on Wednesday (or whatever days suit the RM) is something I'd > > personally like to make a documented part of the release process. > Go for it, document it. Generally I like the idea of being more time > based. On the other hand we are still a bunch of people doing most of > the work in our free time, so I'm bit skeptic on that, but we never > know if we won't even try it. Yes, personally I find it easier to block out a regular slot in the diary for the free time stuff than to pick it up piecemeal, so that's why I did it that way. I realise that we're all in different work / free time scenarios so it might not work for everyone. 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
