Re: Apache JIRA vs GitHub issues / discussions

[László Kishalmi]

Well, first of all, I'm fine with whatever tool we use for tracking issues.

Though I think first we shall show that we could do manage those issues
that are reported. Close those which are no longer valid, old, not enough
info whatever. Respond on new ones, etc. Once we can do that. We can
discuss on tools. Otherwise we just let the crap flowing to a new place,
while confusing users.



On Sun, Sep 26, 2021, 09:10 Eric Bresie  wrote:

> A long one coming I know but hear me out please
>
> I know everyone involved here has their day jobs and does this mainly as
> an advocate for the product, as a hobby, or supporting their own interest
> so I think it's important to focus on how to make this easier for those
> involved.
>
> Changing from JIRA to Github would only risk further confusing things as
> happens when transitioning from bugzilla (https://bz.apache.org/netbeans/) to
> jira.
>
> Discussions can happen in JIRA tickets just as easily as in GitHub and
> PRs.  Having the PR owner drive the "discussion" is the same as a ticket
> owner driving the ticket discussion.  PR discussions seem to me to be
> focused on the changes made in the PR, not necessarily the higher level
> discussions for possible solutions of the ticket.
>
> The reason there are so many tickets is no one or no group has taken
> ownership of it (i.e. no change control).  I still think some form of
> "change management team" or "JIRA Triage" team could help here.  Is it
> possible to have a Slack channel for CCB activities or a mailing list?
>
> Or even wilder ideas, since less emphasis has been given to LTR and Netcat
> activities, maybe the Netcat list should be repurposed for some of this
> change control activity.  If a given test case is relevant to a given
> component and functionality, it can be linked up with that and then when
> run if it is verified to not be an issue then close it.
>
> Seems to mean like there isn't a clear process of how JIRA usage is
> expected to be used.  If there is one, where is it (confluence, Wiki,
> etc.)?
>
> JIRA / Change Process seems like :
>
> (1) New ticket is raised by someone
> (2) (Hopefully) Details on how to reproduce and verify it's closed are
> clearly defined
> (3) Ticket is analyzed (i.e. impacted components, priority
> (4) Someone is assigned, volunteers, or takes ownership of the ticket
> (5) Someone comes up with a possible fix
> (6) Someone associated PR to fix
> (7) Testers (including [1] capability subject matter expert, and [2] the
> author of the ticket) test the fix and confirm/reject the change
> (8) If accepted then the ticket is ready to transition to "integration
> gate" [i.e. can be labels or tagged for a milestones for an upcoming
> release [maybe "candidate" of some type).
> (9) Release team can review candidates based on applicable labeled or
> milestone an evaluate for merging
> (10) Merged into a release candidate build
> (11) Beta/Release Candidate/Final Build released for community review
> (12) Team accepts based on vote
> (13) Release is released
> (14) All tickets associated with a given release are "Closed"
> (15) If an issue is later found to not have been fixed then either
> "Reopen" the ticket or "Raise a new ticket with more specifics" (goto (1))
>
> There is lots of power in JIRA if it's used. For example
> * Note: I would share these JIRA searches but I don't have the ability to
> "Share" filters so will provide a URL based link instead.
>
> (1) Find tickets created in the last 7 days
> project = NetBeans AND created >= -7d
> 
> * Would propose with tickets like these they could be "triaged" weekly and
> set applicable minimum things (i.e. impacted components,priority, potential
> target releases, complexity, etc.)
>
> (2) Tickets which are not closed yet
> project = NetBeans AND status not in (Closed)
> 
> * Can help identify tickets not in "Closed" even those that have been
> "resolved".
> * Items resolved and in a build if verified should be "Closeable"
>
> (3) Tickets not assigned to anyone
> project = NetBeans AND assignee is EMPTY
> 
> * Helps identify who is not actively working on given tickets
>
> (4) Tickets not tagged to any components
> project = NetBeans AND component is EMPTY
> 
> * Grouping things by components may help potential similar or related
> issues
> * Can group tickets to a given component which can localize issues and
> allow component exports to be more aware of changes and provide oversite or
> input on changes for the given component
> (5) Tickets tagged to a specific component (as an example)
> project = NETBEANS AND component = "pr

Re: LSP Language Server Protocol

[Eric Bresie]

Some of this may be of help…

(1) https://langserver.org/
(2)
https://lists.apache.org/thread.html/r004212da38a55a7779b58ed03e851e6f017b150abe43d7a868bea236%40%3Cdev.netbeans.apache.org%3E

Eric

On Wed, Sep 8, 2021 at 11:55 AM Jack W.  wrote:

> Thanks for the pointer, John, very helpful.
>
> On Wed, Sep 8, 2021 at 10:52 AM John Kostaras  wrote:
>
> > There is this
> > .
> >
>
> ---
> Jack Woehr   # Woehr's Asymptote: The ratio of the time spent
> Box 51, Golden CO 80402  # administering productivity software over the
> time
> http://www.softwoehr.com # saved by said software eventually approximates
> 1.
>
-- 
Eric Bresie
ebre...@gmail.com

Re: Release numbers, ranges, semantic versioning, etc. was:Postmortem 12.5

[Geertjan Wielenga]

NetBeans can support all the languages and technologies of the world while
still being coupled to JDK versions...

Gj

On Sun, Sep 26, 2021 at 7:48 PM Christian Lenz 
wrote:

> I don’t know why everyone is trying to pitch NetBeans back to be a Java
> IDE? It can even more. Problematic again is also the other APIs for
> HTML/CSS/JS they are not public by default. Everything is as stable as
> possible now. Make them open and let people like me contribute to the other
> parts of the IDE. Everything is working for years now.
>
> Yes, NetBeans don’t need more Bugs but it has bugs like every other
> software 😃 so what will be the solution for that? Ignoring Bugs of
> NetBeans? Seems so.
>
> So I’m totally against to couple the version to the JDK Version. Don’t set
> the focus back to Java to this awesome IDE.
>
>
> Cheers
>
> Chris
>
> Von: Eric Bresie
> Gesendet: Sonntag, 26. September 2021 18:44
> An: Netbeans Developer List
> Betreff: Re: Release numbers, ranges, semantic versioning, etc.
> was:Postmortem 12.5
>
> I know since Netbeans IDE is java centric, it is by no means specific to
> Java and linking to java version may be valuable to java developers but may
> not be for those for other languages.
>
> Think that has been discussed before but I'm going to throw it out just in
> case...
>
> Would it be worth changing the number to date based versions like other
> folks have (i.e. -mm, or some "quarterly" based nomenclature [i.e.
> 2021-Q3 or Q4])?
>
> Eric Bresie
> ebre...@gmail.com
>
>
> On Sat, Sep 25, 2021 at 2:48 AM Jaroslav Tulach  >
> wrote:
>
> > > >> This essentially makes release numbers meaningless, which seems to
> be
> > the
> > > >> way things are going...
> >
> > There is a difference between "marketing" release number and
> "engineering"
> > release numbers. Marketing release numbers are meaningless - it doesn't
> > matter
> > whether it is going to be NetBeans 13, 14, or 12.6, 12.7 - it's just a
> > marketing campaign.
> >
> > Engineering numbers are more important when it comes to discussion
> whether
> > a
> > plugin works with certain system version or not. A scientific take on
> that
> > can
> > be found at my website:
> >
> > http://wiki.apidesign.org/wiki/RangeDependenciesAnalysed
> >
> > NetBeans Module System allows you to easily specify the "lower bound".
> Do
> > it.
> > There is also  an implicit "upper bound" - restricted by the same major
> > release number, but Apache NetBeans project avoids changing the major
> > release
> > number as much as possible and rather we keep (signature based)
> > compatibility.
> >
> > In any case my advice is: Upload to update center. Specify the lower
> > bound.
> > Open up the "upper bound" as much as possible, unless it is known there
> is
> > a
> > problem in "future versions". In such case restrict the upper bound or
> > rather
> > report and fix the problem in NetBeans code itself.
> >
> >
> > > >> There is a, perhaps, unintended consequence. The plugins I support
> > have
> > > >> continued to work, and be available in the plugin manager, through
> all
> > > >> of 12.x without any effort on my part.
> >
> > That's result of the hard work of Apache NetBeans contributors and
> release
> > managers! Everyone pays attention to "sigtest" signatures and as such we
> > don't
> > have linkage problems (so common in Oracle NetBeans) and even runtime
> > problems
> > are rare.
> >
> >
> > > The before times update center required a new plugin download for every
> > > NB release. The netbeans.apache update center is friendlier since you
> > > can specify which /major/ releases a plugin works with; so it's not
> > > dependent on a NB minor release, and you can specify multiple NB
> > > releases. But it's easily possible that going from 12.2 to 12.3 a
> plugin
> > > needs to be changed, but there's no way to specify that in the update
> > > center, for example see
> > > https://issues.apache.org/jira/browse/NETBEANS-5064 which demonstrates
> > > that the current association of NB-version with plugin is broken.
> >
> > Repeat: marketing numbers (12.2 and 12.3) are useless. Only the
> > engineering
> > numbers make (some) sense. E.g. watch for individual module dependencies.
> >
> > > The old method of tying a full version number to a plugin is more
> > > reliable.
> >
> > Of course. Only "no flexibility" (in version dependencies) allows some
> > form of
> > certification - that's the approach QA guys like.  However...
> >
> > > But with 4 releases a year there's more overhead, not only for
> > > plugin developers, but for doing plugin verification.
> >
> > ... as we are short on time and resources, we'd rather worship "semantic
> > versioning" and understand proximity:
> > http://wiki.apidesign.org/wiki/Proximity
> >
> > > Some way to loosely couple seems desirable. If the portal had a list of
> > > all version numbers, and spec'ing vers-X means "vers-X and all later
> > > releases, up to the next spec'd" would do the trick.
> > >
> > > > If we want 

AW: Release numbers, ranges, semantic versioning, etc. was:Postmortem 12.5

[Christian Lenz]

I don’t know why everyone is trying to pitch NetBeans back to be a Java IDE? It 
can even more. Problematic again is also the other APIs for HTML/CSS/JS they 
are not public by default. Everything is as stable as possible now. Make them 
open and let people like me contribute to the other parts of the IDE. 
Everything is working for years now.

Yes, NetBeans don’t need more Bugs but it has bugs like every other software 😃 
so what will be the solution for that? Ignoring Bugs of NetBeans? Seems so.

So I’m totally against to couple the version to the JDK Version. Don’t set the 
focus back to Java to this awesome IDE.


Cheers

Chris

Von: Eric Bresie
Gesendet: Sonntag, 26. September 2021 18:44
An: Netbeans Developer List
Betreff: Re: Release numbers, ranges, semantic versioning, etc. was:Postmortem 
12.5

I know since Netbeans IDE is java centric, it is by no means specific to
Java and linking to java version may be valuable to java developers but may
not be for those for other languages.

Think that has been discussed before but I'm going to throw it out just in
case...

Would it be worth changing the number to date based versions like other
folks have (i.e. -mm, or some "quarterly" based nomenclature [i.e.
2021-Q3 or Q4])?

Eric Bresie
ebre...@gmail.com


On Sat, Sep 25, 2021 at 2:48 AM Jaroslav Tulach 
wrote:

> > >> This essentially makes release numbers meaningless, which seems to be
> the
> > >> way things are going...
>
> There is a difference between "marketing" release number and "engineering"
> release numbers. Marketing release numbers are meaningless - it doesn't
> matter
> whether it is going to be NetBeans 13, 14, or 12.6, 12.7 - it's just a
> marketing campaign.
>
> Engineering numbers are more important when it comes to discussion whether
> a
> plugin works with certain system version or not. A scientific take on that
> can
> be found at my website:
>
> http://wiki.apidesign.org/wiki/RangeDependenciesAnalysed
>
> NetBeans Module System allows you to easily specify the "lower bound".  Do
> it.
> There is also  an implicit "upper bound" - restricted by the same major
> release number, but Apache NetBeans project avoids changing the major
> release
> number as much as possible and rather we keep (signature based)
> compatibility.
>
> In any case my advice is: Upload to update center. Specify the lower
> bound.
> Open up the "upper bound" as much as possible, unless it is known there is
> a
> problem in "future versions". In such case restrict the upper bound or
> rather
> report and fix the problem in NetBeans code itself.
>
>
> > >> There is a, perhaps, unintended consequence. The plugins I support
> have
> > >> continued to work, and be available in the plugin manager, through all
> > >> of 12.x without any effort on my part.
>
> That's result of the hard work of Apache NetBeans contributors and release
> managers! Everyone pays attention to "sigtest" signatures and as such we
> don't
> have linkage problems (so common in Oracle NetBeans) and even runtime
> problems
> are rare.
>
>
> > The before times update center required a new plugin download for every
> > NB release. The netbeans.apache update center is friendlier since you
> > can specify which /major/ releases a plugin works with; so it's not
> > dependent on a NB minor release, and you can specify multiple NB
> > releases. But it's easily possible that going from 12.2 to 12.3 a plugin
> > needs to be changed, but there's no way to specify that in the update
> > center, for example see
> > https://issues.apache.org/jira/browse/NETBEANS-5064 which demonstrates
> > that the current association of NB-version with plugin is broken.
>
> Repeat: marketing numbers (12.2 and 12.3) are useless. Only the
> engineering
> numbers make (some) sense. E.g. watch for individual module dependencies.
>
> > The old method of tying a full version number to a plugin is more
> > reliable.
>
> Of course. Only "no flexibility" (in version dependencies) allows some
> form of
> certification - that's the approach QA guys like.  However...
>
> > But with 4 releases a year there's more overhead, not only for
> > plugin developers, but for doing plugin verification.
>
> ... as we are short on time and resources, we'd rather worship "semantic
> versioning" and understand proximity:
> http://wiki.apidesign.org/wiki/Proximity
>
> > Some way to loosely couple seems desirable. If the portal had a list of
> > all version numbers, and spec'ing vers-X means "vers-X and all later
> > releases, up to the next spec'd" would do the trick.
> >
> > > If we want version numbers to be meaningful,
> >
> > NetBeans might the the prime example of where semantic versioning would
> > not work well.
>
> NetBeans versioning scheme has been designed before semantic versioning
> website was created. There may be some differences, but in general, I
> suggest
> to follow semantic versioning and think about proximity.
>
> > Each NB module has it's own version number.
> >
> > jVi was comp

Re: Using test distribution & Apache's Jenkins pipelines was: Time it takes for Test PHP Cluster

[Eric Bresie]

I know there have been discussions in the past on CI builds issues like
[1], [2]. [3], [4], [5], "Build Strategies" [6], and time on the builds [7]
but...

It seems some build jobs are done on GitHub commits, Travis CI, Jenkins,
etc.  Assume some of this is dependent on the type of jobs and tests (OS or
capability focus), and the infrastructure and available resources involved
(i.e. Apache CI-Jenkins across Apache projects, GitHub build [across apache
projects], Travis CI [assume constrained in some way]).

So, what specifically needs to be done?

Do the types of jobs need to be grouped and run by intent/needs in an
applicable CI environment?
Do the types of jobs need to be migrated into a single place (i.e. Github,
Travis, Jenkins, etc.)?

Eric Bresie
ebre...@gmail.com

References
[1]
https://lists.apache.org/thread.html/r944d5e9e79b6abdf9337293f417c3b51229e8b7d7989833028328359%40%3Cdev.netbeans.apache.org%3E
[2]
https://lists.apache.org/thread.html/rcddd3063fb087fb894eeea38b6c555c802c4412e15a27ada1b4dccbe%40%3Cdev.netbeans.apache.org%3E
[3]
https://lists.apache.org/thread.html/r3d55f95ee5dc6383a4330ee2cf4cf98785149df461063330bd1cb535%40%3Cdev.netbeans.apache.org%3E
[4]
https://lists.apache.org/thread.html/r7937df039aea7254d6d6f0847e47a1bb3f14ee603d97bed58e8f7ccc%40%3Cdev.netbeans.apache.org%3E
[5]
https://lists.apache.org/thread.html/r22e89737af4b1c0808d6f06385e5fd00c37a6b435e7a81cf06619501%40%3Cdev.netbeans.apache.org%3E
[6]
https://lists.apache.org/thread.html/rcdcb7a718c01fec2796bdb472e979a8900c346efb9aebcc6024e31b9%40%3Cdev.netbeans.apache.org%3E
[7]
https://lists.apache.org/thread.html/r8694f9ca65746542f1ee1c73c219f17acea5a527f5809d5c68394de6%40%3Cdev.netbeans.apache.org%3E

On Sat, Sep 25, 2021 at 1:52 AM Jaroslav Tulach 
wrote:

> Dne pátek 24. září 2021 17:25:39 CEST, Eric Barboni napsal(a):
> > Hi,
> >
> > I juste retrieved an old mail for Jaroslav.
>
> ;-)
>
> > I'm a bit "irritated" because of
> > CI. I'm haunted  by the "restart job button".
>
> I can live with the "restart button", but I agree: Such frequent failures
> aren't professional.
>
> > Is a only Apache jenkins build + PR review something we can do ?
> > or would we have some limitation and should rely also on GA or travis
> too?
> >
> >
> > Hector started something https://github.com/apache/netbeans/pull/2443
> to do
> > jenkins PR test.
> >
> > BUT on jenkins
> > This build trigger test error:
> > https://ci-builds.apache.org/job/Netbeans/job/netbeans-linux/
> > ant build test-platform build-nbms generate-uc-catalog build-source-zips
> > => 1 issue on
> > org.openide.filesystems.annotations.LayerBuilderTest.testSourcePath The
> > same ant call on my ubuntu
> > => 0 issue
> >
> > Complicated to trust jenkins too.
> > But I would like to see the CI issues tackled so Release
> Manager,commiter,
> > reviewers may have better life :D. --
>
> +1
>
> My original may was however about "test distribution" - e.g. build the IDE
> and
> the test distribution once, and then use it for running the tests across
> different nodes.
>
> Yes, Jenkins pipelines (on Apache own infra) would be ideal for that I
> think.
> -jt
>
>
>
> > -Message d'origine-
> > De : Jaroslav Tulach 
> > Envoyé : lundi 26 avril 2021 06:16
> > À : dev@netbeans.apache.org
> > Cc : Petr Zajac 
> > Objet : Using test distribution & Apache's Jenkins pipelines was: Time it
> > takes for Test PHP Cluster
> > Dne pátek 16. dubna 2021 18:53:31 CEST, Tomáš Procházka napsal(a):
> > > I stareted conversion of other jobs
> > > (https://github.com/apache/netbeans/pull/2708) but stopped given
> > > current status of Github Actions
> > > (https://cwiki.apache.org/confluence/display/BUILDS/GitHub+Actions+sta
> > > tus)
> >
> > Hello guys,
> > maybe there is a time to improve the structure of build jobs and to
> increase
> > the throughput by eliminating duplicated tasks.
> >
> > These days every job builds the IDE, builds the tests and then it
> executes
> > some tests. We can do better than that! There has been a "test
> > distribution" in NetBeans for years and according to its creator Petr
> > Zajac, it is still working!
> >
> > It would be good to have one job that builds the ZIP of the IDE and
> builds
> > the ZIP for the test distribution. Only then other "testing" jobs are
> > started, download the two ZIP files and use them to perform the tests
> only.
> >
> > Btw. When at it, shouldn't we consider to use
> https://ci-builds.apache.org/
> > ? It is an infrastructure that fully runs on Apache's hardware - e.g. we
> > aren't going to be influenced deals with external providers like Travis
> or
> > Azure. Moreover Jenkins supports pipelines to pass the ZIPs from one job
> to
> > another...
> >
> > Together we can save the planet!
> > -jt
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> > For additional commands, e-mail: dev-h...@netbeans.apache.org
> >
> > For further

Re: Release numbers, ranges, semantic versioning, etc. was: Postmortem 12.5

[Eric Bresie]

I know since Netbeans IDE is java centric, it is by no means specific to
Java and linking to java version may be valuable to java developers but may
not be for those for other languages.

Think that has been discussed before but I'm going to throw it out just in
case...

Would it be worth changing the number to date based versions like other
folks have (i.e. -mm, or some "quarterly" based nomenclature [i.e.
2021-Q3 or Q4])?

Eric Bresie
ebre...@gmail.com


On Sat, Sep 25, 2021 at 2:48 AM Jaroslav Tulach 
wrote:

> > >> This essentially makes release numbers meaningless, which seems to be
> the
> > >> way things are going...
>
> There is a difference between "marketing" release number and "engineering"
> release numbers. Marketing release numbers are meaningless - it doesn't
> matter
> whether it is going to be NetBeans 13, 14, or 12.6, 12.7 - it's just a
> marketing campaign.
>
> Engineering numbers are more important when it comes to discussion whether
> a
> plugin works with certain system version or not. A scientific take on that
> can
> be found at my website:
>
> http://wiki.apidesign.org/wiki/RangeDependenciesAnalysed
>
> NetBeans Module System allows you to easily specify the "lower bound".  Do
> it.
> There is also  an implicit "upper bound" - restricted by the same major
> release number, but Apache NetBeans project avoids changing the major
> release
> number as much as possible and rather we keep (signature based)
> compatibility.
>
> In any case my advice is: Upload to update center. Specify the lower
> bound.
> Open up the "upper bound" as much as possible, unless it is known there is
> a
> problem in "future versions". In such case restrict the upper bound or
> rather
> report and fix the problem in NetBeans code itself.
>
>
> > >> There is a, perhaps, unintended consequence. The plugins I support
> have
> > >> continued to work, and be available in the plugin manager, through all
> > >> of 12.x without any effort on my part.
>
> That's result of the hard work of Apache NetBeans contributors and release
> managers! Everyone pays attention to "sigtest" signatures and as such we
> don't
> have linkage problems (so common in Oracle NetBeans) and even runtime
> problems
> are rare.
>
>
> > The before times update center required a new plugin download for every
> > NB release. The netbeans.apache update center is friendlier since you
> > can specify which /major/ releases a plugin works with; so it's not
> > dependent on a NB minor release, and you can specify multiple NB
> > releases. But it's easily possible that going from 12.2 to 12.3 a plugin
> > needs to be changed, but there's no way to specify that in the update
> > center, for example see
> > https://issues.apache.org/jira/browse/NETBEANS-5064 which demonstrates
> > that the current association of NB-version with plugin is broken.
>
> Repeat: marketing numbers (12.2 and 12.3) are useless. Only the
> engineering
> numbers make (some) sense. E.g. watch for individual module dependencies.
>
> > The old method of tying a full version number to a plugin is more
> > reliable.
>
> Of course. Only "no flexibility" (in version dependencies) allows some
> form of
> certification - that's the approach QA guys like.  However...
>
> > But with 4 releases a year there's more overhead, not only for
> > plugin developers, but for doing plugin verification.
>
> ... as we are short on time and resources, we'd rather worship "semantic
> versioning" and understand proximity:
> http://wiki.apidesign.org/wiki/Proximity
>
> > Some way to loosely couple seems desirable. If the portal had a list of
> > all version numbers, and spec'ing vers-X means "vers-X and all later
> > releases, up to the next spec'd" would do the trick.
> >
> > > If we want version numbers to be meaningful,
> >
> > NetBeans might the the prime example of where semantic versioning would
> > not work well.
>
> NetBeans versioning scheme has been designed before semantic versioning
> website was created. There may be some differences, but in general, I
> suggest
> to follow semantic versioning and think about proximity.
>
> > Each NB module has it's own version number.
> >
> > jVi was compatible with NB-7.* and NB-8.*. In module restore, jVi
> > checked each module it cared about and set some flags to control
> > behavior;
>
> Clever.
>
> > a hassle but easier than having different plugin versions for
> > each NB version, especially when it comes to features and bug fixes (I
> > wasn't comfortable with saying you had to use the latest NB version).
>
> Obviously. It is desirable to offer a system when one jVi module can work
> with
> all (released/marketing) versions NetBeans IDE since some "lower bound".
>
> > BTW, when I said "release numbers meaningless, which seems to be the way
> > things are going" I was referring to the industry, thinking
> firefox/chrome.
>
> If you invest into pushing users to the latest version (like browsers or
> iOS
> does), then you simplify the burden of suppo

Re: Release Team for 12.6?

[Eric Bresie]

As I am not a PMD member, contributor, or release experience yet I don't
feel eligible to volunteer but

I did want to point to the JIRA vs GitHub discussion thread [1] for
suggestions on change control / JIRA triage / release planning related
activities which may help going forward in the coming release (i.e. which
tickets may have PRs, higher priorities, higher votes, etc.),

For example, this could be an opportunity for the Netbean community to vote
on tickets they feel should be considered to work (if no PRs yet) or vote
on those with PRs.

Eric Bresie
ebre...@gmail.com

[1]
https://lists.apache.org/thread.html/r05c3d5721d0d53135e1b6c7fb7926f254725a3363829641e2f7ae89e%40%3Cdev.netbeans.apache.org%3E

On Sat, Sep 25, 2021 at 3:02 AM Jaroslav Tulach 
wrote:

> > Hi all,
> >
> > Who'd like to volunteer to join Neil and me on the release team for 12.6?
>
> I confess I believe the Apache NetBeans project members are the best
> release
> team NetBeans ever had!
>
> Thank you for keeping the project vibrant!
> -jt
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: [CND] - Makefile projects + cpplite editors?

[Eric Bresie]

+1

Not sure if this work may related to any of the other possible open CND
tickets [3] but figured I would throw it out there

[3]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20NetBeans%20AND%20text%20~%20CND%20and%20status%20not%20in%20(Closed)

Eric Bresie
ebre...@gmail.com


On Sat, Sep 25, 2021 at 7:21 PM Tristan Lewis  wrote:

> I think maintainability is worth making some sacrifices for, as at the
> moment it isn't possible to release new versions of the CND plugin, and
> there are some substantial issues with the plugin as it stands (primarily
> debugger reliability).
>
> If we can leverage as much of clang as possible, that would seem to be a
> good way to lessen the amount of work required.
>
> Tristan
>
> Get Outlook for Android
> 
> From: antonio 
> Sent: Wednesday, September 22, 2021 6:32:01 AM
> To: dev@netbeans.apache.org 
> Subject: [CND] - Makefile projects + cpplite editors?
>
> Hi all,
>
> I've isolated a small subset of the "cnd" branch that restores support
> for C/C++ projects [1], this is, you can open/create/compile/run C/C++
> projects the same way as in NetBeans 8.X.
>
> This subset does not contain the C/C++ editor (nor debugger, completion,
> etc.), which would require recreating the quite-old ANTLR grammars (and
> build/maintain a C preprocessor). When one opens a C/C++ file there's
> syntax highlighting, but the IDE complains because there's no language
> registered for "text/x-c++".
>
> I was thinking we could:
>
> a) CPPLITE: Use the editors/completion/etc. from the cpplite branch
> (note these editors are registered for "text/X-c++", not "text/x-c++"),
> that is backed by a C/C++ LSP Server (clangd, for instance).
>
> b) Trimmed-CND: Try to use the C/C++ projects from this small subset of
> "cnd" to generate a compilation database for cpplite (C/C++ projects in
> cnd should have all information required to generate these compilation
> databases).
>
> As far as I understand, with this we could recover the C/C++ support for
> Apache NetBeans but with a more powerful/mainteinable LSP backed
> completion, right?
>
> Cheers,
> Antonio
>
>
> [1]
> https://github.com/vieiro/netbeans/tree/cnd-projects
>
> The list of modules in the cnd subset is at
>
>
> https://github.com/vieiro/netbeans/blob/20f732f9af3a8fc0871c7042a5253571268b3c0f/nbbuild/cluster.properties#L1081
>
> (not sure cnd.kit should be there? Maybe cpplite.kit is good enough?)
>
>
> [2]
>
> file=org.netbeans.modules.cnd.source.CCDataObject@5f3c2943
> [C:\Users\XXX\AppData\Local\Temp\CppApplication_2\main.cpp@4e7a192d
> :6bb83680]
>   [exec] java.lang.Exception: no language for
> org.netbeans.modules.editor.NbEditorDocument@56cadb2b,
> mimeType='text/x-c++', kitClass=null, length=404, version=1,
> file=org.netbeans.modules.cnd.source.CCDataObject@5f3c2943
> [C:\Users\antvie\AppData\Local\Temp\CppApplication_2\main.cpp@4e7a192d
> :6bb83680]
>   [exec] @[slowDocumentPropertiesSetup]
>   [exec] at
> org.netbeans.modules.cnd.utils.CndUtils.severe(CndUtils.java:188)
>   [exec] at
>
> org.netbeans.modules.cnd.utils.CndUtils.assertUnconditional(CndUtils.java:123)
>   [exec] at
>
> org.netbeans.modules.cnd.source.CppEditorSupport.setupSlowDocumentProperties(CppEditorSupport.java:253)
>   [exec] at
>
> org.netbeans.modules.cnd.source.CppEditorSupport.access$200(CppEditorSupport.java:84)
>   [exec] at
>
> org.netbeans.modules.cnd.source.CppEditorSupport$3.run(CppEditorSupport.java:368)
>   [exec] at
> org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
>   [exec] at
>
> org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
>   [exec] at
> org.openide.util.lookup.Lookups.executeWith(Lookups.java:278)
>   [exec] at
> org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: Apache JIRA vs GitHub issues / discussions

[Eric Bresie]

A long one coming I know but hear me out please

I know everyone involved here has their day jobs and does this mainly as an
advocate for the product, as a hobby, or supporting their own interest so I
think it's important to focus on how to make this easier for those involved.

Changing from JIRA to Github would only risk further confusing things as
happens when transitioning from bugzilla (https://bz.apache.org/netbeans/) to
jira.

Discussions can happen in JIRA tickets just as easily as in GitHub and
PRs.  Having the PR owner drive the "discussion" is the same as a ticket
owner driving the ticket discussion.  PR discussions seem to me to be
focused on the changes made in the PR, not necessarily the higher level
discussions for possible solutions of the ticket.

The reason there are so many tickets is no one or no group has taken
ownership of it (i.e. no change control).  I still think some form of
"change management team" or "JIRA Triage" team could help here.  Is it
possible to have a Slack channel for CCB activities or a mailing list?

Or even wilder ideas, since less emphasis has been given to LTR and Netcat
activities, maybe the Netcat list should be repurposed for some of this
change control activity.  If a given test case is relevant to a given
component and functionality, it can be linked up with that and then when
run if it is verified to not be an issue then close it.

Seems to mean like there isn't a clear process of how JIRA usage is
expected to be used.  If there is one, where is it (confluence, Wiki,
etc.)?

JIRA / Change Process seems like :

(1) New ticket is raised by someone
(2) (Hopefully) Details on how to reproduce and verify it's closed are
clearly defined
(3) Ticket is analyzed (i.e. impacted components, priority
(4) Someone is assigned, volunteers, or takes ownership of the ticket
(5) Someone comes up with a possible fix
(6) Someone associated PR to fix
(7) Testers (including [1] capability subject matter expert, and [2] the
author of the ticket) test the fix and confirm/reject the change
(8) If accepted then the ticket is ready to transition to "integration
gate" [i.e. can be labels or tagged for a milestones for an upcoming
release [maybe "candidate" of some type).
(9) Release team can review candidates based on applicable labeled or
milestone an evaluate for merging
(10) Merged into a release candidate build
(11) Beta/Release Candidate/Final Build released for community review
(12) Team accepts based on vote
(13) Release is released
(14) All tickets associated with a given release are "Closed"
(15) If an issue is later found to not have been fixed then either "Reopen"
the ticket or "Raise a new ticket with more specifics" (goto (1))

There is lots of power in JIRA if it's used. For example
* Note: I would share these JIRA searches but I don't have the ability to
"Share" filters so will provide a URL based link instead.

(1) Find tickets created in the last 7 days
project = NetBeans AND created >= -7d

* Would propose with tickets like these they could be "triaged" weekly and
set applicable minimum things (i.e. impacted components,priority, potential
target releases, complexity, etc.)

(2) Tickets which are not closed yet
project = NetBeans AND status not in (Closed)

* Can help identify tickets not in "Closed" even those that have been
"resolved".
* Items resolved and in a build if verified should be "Closeable"

(3) Tickets not assigned to anyone
project = NetBeans AND assignee is EMPTY

* Helps identify who is not actively working on given tickets

(4) Tickets not tagged to any components
project = NetBeans AND component is EMPTY

* Grouping things by components may help potential similar or related
issues
* Can group tickets to a given component which can localize issues and
allow component exports to be more aware of changes and provide oversite or
input on changes for the given component
(5) Tickets tagged to a specific component (as an example)
project = NETBEANS AND component = "projects - Gradle"

* See above

(6) Tickets created in a specific timeframe (example, those created for
2020)
project = NetBeans AND created >= "2020-01-01" AND created <= "2020-12-31"

* Can identify tickets creating in a given time frame which can help in
identifying when (maybe due to a specific release) or how long ticke