> I think we should be able to release from master without branching.
Having release branches is quite useful if only because we can do per-release
fixes while master/ has diverged / refactored that whole area.
--emi
‐‐‐ Original Message ‐‐‐
On 26 April 2018 5:08 PM, Wade Chandler wr
@Laszlo, Have you made it public?
It's not loading for me, even when I'm logged in.
Regards
John
On 27 April 2018 at 04:20, Laszlo Kishalmi
wrote:
> Well, I've got the rights to share my dashboard.
>
> It's called: NetBeans Overview
>
> https://issues.apache.org/jira/secure/Dashboard.jspa?s
Well, I've got the rights to share my dashboard.
It's called: NetBeans Overview
https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12332552
On 04/26/2018 03:53 PM, Laszlo Kishalmi wrote:
I went though the open issues with PR-s list.
I've marked 17 issues resolved due to it's PR
Here's a bug, with a pull request and some discussion, that's not quite a
blocker (it existed in 8.2) but still arguably critical:
https://issues.apache.org/jira/browse/NETBEANS-403
"Pressing Home/End scrolls to beginning/end of whole document if tooltip is
open"
There's an ongoing discussion o
I went though the open issues with PR-s list.
I've marked 17 issues resolved due to it's PR merged, and added some
flags for 9.0 as well.
Right now in JIRA we have 27 open issues with PR and 9 of them are
marked for 9.0 release.
We still have 31 open PRs.
As of 9.0: We have 40 issues open
On Thu, Apr 26, 2018 at 7:56 PM, Laszlo Kishalmi
wrote:
> Well,
>
> I'm trying to collect the remaining things to do for 9.0 release
There are 3 blockers:
https://issues.apache.org/jira/issues/?filter=12343308
Thanks,
Gj
> for a week now, from GitHub PR-s, JIRA and this mailing list. R
On Thu, Apr 26, 2018 at 8:26 PM, Peter Steele wrote:
> Just for my interest, which types of people can approve Pull Requests?
NetBeans is simply an Apache project, in the Apache incubator. Nothing that
we're doing here is specific to NetBeans, everything is the same as at
Apache Maven, Apache
Just for my interest, which types of people can approve Pull Requests? As
we are now open source the community is deciding what's important by
providing the PR's but we have quite a few stacked up. It has previously
been mentioned in someone else request to get one approved that they should
just se
Well,
I'm trying to collect the remaining things to do for 9.0 release for a
week now, from GitHub PR-s, JIRA and this mailing list. Regarding 9.0 in
numbers are the following (none may be accurate, though):
We have 31 open PR-s in GitHub (not necessary 9.0 related)
We have 44 open issues wi
I think a release branch serves several purposes, among others:
-ability to add changes that are specific for the release (in case of
NetBeans things like: release branding, updating module spec. versions to
release format, disabling exceptions, etc.)
-let development (features and general bugfixin
+1 and even if we don’t have a “dev” branch, I think we should be able to
release from master without branching. We should be working to stabilize things
near a release, and perhaps we ask folks not to merge new features to master,
but only fixes for a period of time. If we could support feature
only work on Feature branches. After the
> Feature is finished and ready to go, it will merged into develop. Someday
> you can create a release branch of develop.
>
>
> Cheer
>
> Chris
>
> Von: Neil C Smith
> Gesendet: Dienstag, 17. April 2018 14:53
> An: dev@netbe
On Tue, 17 Apr 2018 at 12:10 Jaroslav Tulach
wrote:
> Yeah, there are changes in the queue for the master branch that could be
> too destabilizing. To avoid something like that to negatively influence the
> 9.0 release, I'd suggest to create a branch release/9.0 and put only the
> safe fixes read
+1 for branching
Sven
John McDonnell schrieb am Di., 17. Apr. 2018,
14:08:
> I agree,
>
> But we need to make sure that only agreed/safe fixes get merged into the
> release candidate. Whats the criteria to use? Only accept blocking bug
> fixes?
>
> John
>
> On 17 April 2018 at 12:10, Jaroslav
I agree,
But we need to make sure that only agreed/safe fixes get merged into the
release candidate. Whats the criteria to use? Only accept blocking bug
fixes?
John
On 17 April 2018 at 12:10, Jaroslav Tulach
wrote:
> Yeah, there are changes in the queue for the master branch that could be
>
Yeah, there are changes in the queue for the master branch that could be
too destabilizing. To avoid something like that to negatively influence the
9.0 release, I'd suggest to create a branch release/9.0 and put only the
safe fixes ready for 9.0 there. The wild development would continue in the
ma
16 matches
Mail list logo
