[68cat] 6.7 issues

[Matthies, Niklas]

Quick questions:

- Does it make sense to report issues for 6.7 and put
  the [68cat] prefix on them because the problem hasn't
  been addressed yet?
  (As opposed to reporting them for 6.8, which would
  be less accurate?)

- Does it make sense to do this for 6.7 issues that we
  reported before the 68cat program started?

- ...or should such issues rather be "upgraded" to 6.8?

More generally: I presume that the NetCAT-tagged issues
get some sort of priority treatment. (Or what other purpose
does the tag have?) But then of course I'd like for unfixed
issues I reported earlier, or reported for an earlier version,
to get that same attention. It shouldn't matter when I
reported them (= when I noticed them), or for what version,
as long as they still apply. Right? Wrong?

-- Niklas Matthies

[joshis]

- Does it make sense to report issues for 6.7...

You should report an issues only if they are reproducible in the latest
dev build - we do not backport fixes to the older versions (we just
release patches to the current version)... therefore the information
that the bug is in 6.7 has no value for us (it is "less accurate" than
if you said "it is in today's dev build")...

Ideally, you always report an issue for the latest build and if you
submitted a bug in 6.5, for example, just add a comment "Still
reproducible in 6.8Beta", for example, in the issue description.

About the [68cat] prefixes - you should add those only to the issues you
submitted during the NetCat6.8, I guess...

--pd

[Ulf Zibis-2]

In that case I followed the practice to add [68cat] in front or edit the
given tag.

-Ulf


Am 26.10.2009 20:14, Matthies, Niklas schrieb:

> Quick questions:
>
> - Does it make sense to report issues for 6.7 and put
>   the [68cat] prefix on them because the problem hasn't
>   been addressed yet?
>   (As opposed to reporting them for 6.8, which would
>   be less accurate?)
>
> - Does it make sense to do this for 6.7 issues that we
>   reported before the 68cat program started?
>
> - ...or should such issues rather be "upgraded" to 6.8?
>
> More generally: I presume that the NetCAT-tagged issues
> get some sort of priority treatment. (Or what other purpose
> does the tag have?) But then of course I'd like for unfixed
> issues I reported earlier, or reported for an earlier version,
> to get that same attention. It shouldn't matter when I
> reported them (= when I noticed them), or for what version,
> as long as they still apply. Right? Wrong?
>
> -- Niklas Matthies
>
>
>  

[Michel Graciano]

Well, I usually add [68cat] for issues I can reproduce for the 6.8 version, even if these issues are still marked as 67cat for example.

Regards

On Mon, Oct 26, 2009 at 8:35 PM, Ulf Zibis <Ulf.Zibis@...> wrote:

In that case I followed the practice to add [68cat] in front or edit the given tag.

-Ulf


Am 26.10.2009 20:14, Matthies, Niklas schrieb:

Quick questions:

- Does it make sense to report issues for 6.7 and put
 the [68cat] prefix on them because the problem hasn't
 been addressed yet?
 (As opposed to reporting them for 6.8, which would
 be less accurate?)

- Does it make sense to do this for 6.7 issues that we
 reported before the 68cat program started?

- ...or should such issues rather be "upgraded" to 6.8?

More generally: I presume that the NetCAT-tagged issues
get some sort of priority treatment. (Or what other purpose
does the tag have?) But then of course I'd like for unfixed
issues I reported earlier, or reported for an earlier version,
to get that same attention. It shouldn't matter when I
reported them (= when I noticed them), or for what version,
as long as they still apply. Right? Wrong?

-- Niklas Matthies


 

--
Michel Graciano
Summa Technologies do Brasil Ltda.
http://www.michelgraciano.com
https://genesis.dev.java.net/
http://translatedfiles.netbeans.org/index_pt_BR.html
https://copypastehistory.dev.java.net/

[Jiri Kovalsky]

Hello guys,

   Petr is right. Don't report bugs against old releases but rather verify them in current development builds and report them against 6.8. [68cat] get special attention on regular basis because we know such bug is coming from a trusted source. Furthermore, we track NetCAT income this way and you get 4 points for each bug you file and 2 points for an RFE. :-)

   Finally, it is possible to edit prefix and change it from [65cat] to [68cat] if the bug is still valid in 6.8 or add [68cat] if you didn't use simplified bug submission form. At least I do it myself whenever I spot some bug from NetCAT participant.

Hope this helps,
-Jirka

Michel Graciano wrote:

> Well, I usually add [68cat] for issues I can reproduce for the 6.8
> version, even if these issues are still marked as 67cat for example.
>
> Regards
>
> On Mon, Oct 26, 2009 at 8:35 PM, Ulf Zibis <Ulf.Zibis@...
> <mailto:Ulf.Zibis@...>> wrote:
>
>     In that case I followed the practice to add [68cat] in front or edit
>     the given tag.
>
>     -Ulf
>
>
>     Am 26.10.2009 20:14, Matthies, Niklas schrieb:
>
>         Quick questions:
>
>         - Does it make sense to report issues for 6.7 and put
>          the [68cat] prefix on them because the problem hasn't
>          been addressed yet?
>          (As opposed to reporting them for 6.8, which would
>          be less accurate?)
>
>         - Does it make sense to do this for 6.7 issues that we
>          reported before the 68cat program started?
>
>         - ...or should such issues rather be "upgraded" to 6.8?
>
>         More generally: I presume that the NetCAT-tagged issues
>         get some sort of priority treatment. (Or what other purpose
>         does the tag have?) But then of course I'd like for unfixed
>         issues I reported earlier, or reported for an earlier version,
>         to get that same attention. It shouldn't matter when I
>         reported them (= when I noticed them), or for what version,
>         as long as they still apply. Right? Wrong?
>
>         -- Niklas Matthies

[Matthies, Niklas]

Ok, thanks for clarifying.

-- Niklas Matthies


On Tue, 27. Oct 2009 20:45, Jiri.Kovalsky@... wrote:

> Hello guys,
>
>    Petr is right. Don't report bugs against old releases but
> rather verify them in current development builds and report
> them against 6.8. [68cat] get special attention on regular
> basis because we know such bug is coming from a trusted
> source. Furthermore, we track NetCAT income this way and you
> get 4 points for each bug you file and 2 points for an RFE. :-)
>
>    Finally, it is possible to edit prefix and change it from
> [65cat] to [68cat] if the bug is still valid in 6.8 or add
> [68cat] if you didn't use simplified bug submission form. At
> least I do it myself whenever I spot some bug from NetCAT participant.
>
> Hope this helps,
> -Jirka
>
> Michel Graciano wrote:
>
> > Well, I usually add [68cat] for issues I can reproduce for the 6.8
> > version, even if these issues are still marked as 67cat for example.
> >
> > Regards
> >
> > On Mon, Oct 26, 2009 at 8:35 PM, Ulf Zibis <Ulf.Zibis@...
> > <mailto:Ulf.Zibis@...>> wrote:
> >
> >     In that case I followed the practice to add [68cat] in front or

edit     the given tag.

> >
> >     -Ulf
> >
> >
> >     Am 26.10.2009 20:14, Matthies, Niklas schrieb:
> >
> >         Quick questions:
> >
> >         - Does it make sense to report issues for 6.7 and put
> >          the [68cat] prefix on them because the problem hasn't

been addressed yet?
> >          (As opposed to reporting them for 6.8, which would
be less accurate?)

> >
> >         - Does it make sense to do this for 6.7 issues that we
> >          reported before the 68cat program started?
> >
> >         - ...or should such issues rather be "upgraded" to 6.8?
> >
> >         More generally: I presume that the NetCAT-tagged issues
> >         get some sort of priority treatment. (Or what other purpose
> >         does the tag have?) But then of course I'd like for unfixed
> >         issues I reported earlier, or reported for an earlier

version,
> >         to get that same attention. It shouldn't matter when I
> >         reported them (= when I noticed them), or for what version,
> >         as long as they still apply. Right? Wrong?
> >
> >         -- Niklas Matthies

[esmithbss]

So Jiri,

Are you saying we should all go back through our reported open bugs in
[65cat] and [67cat] and check if they are still in 6.8, then update the
subjects .  Thereby bringing the bug to the development teams attention
and scoring more points in the process?

Eric

Jiri Kovalsky wrote:

> Hello guys,
>
>   Petr is right. Don't report bugs against old releases but rather
> verify them in current development builds and report them against 6.8.
> [68cat] get special attention on regular basis because we know such
> bug is coming from a trusted source. Furthermore, we track NetCAT
> income this way and you get 4 points for each bug you file and 2
> points for an RFE. :-)
>
>   Finally, it is possible to edit prefix and change it from [65cat] to
> [68cat] if the bug is still valid in 6.8 or add [68cat] if you didn't
> use simplified bug submission form. At least I do it myself whenever I
> spot some bug from NetCAT participant.
>
> Hope this helps,
> -Jirka
>
> Michel Graciano wrote:
>
>> Well, I usually add [68cat] for issues I can reproduce for the 6.8
>> version, even if these issues are still marked as 67cat for example.
>>
>> Regards
>>
>> On Mon, Oct 26, 2009 at 8:35 PM, Ulf Zibis <Ulf.Zibis@...
>> <mailto:Ulf.Zibis@...>> wrote:
>>
>>     In that case I followed the practice to add [68cat] in front or edit
>>     the given tag.
>>
>>     -Ulf
>>
>>
>>     Am 26.10.2009 20:14, Matthies, Niklas schrieb:
>>
>>         Quick questions:
>>
>>         - Does it make sense to report issues for 6.7 and put
>>          the [68cat] prefix on them because the problem hasn't
>>          been addressed yet?
>>          (As opposed to reporting them for 6.8, which would
>>          be less accurate?)
>>
>>         - Does it make sense to do this for 6.7 issues that we
>>          reported before the 68cat program started?
>>
>>         - ...or should such issues rather be "upgraded" to 6.8?
>>
>>         More generally: I presume that the NetCAT-tagged issues
>>         get some sort of priority treatment. (Or what other purpose
>>         does the tag have?) But then of course I'd like for unfixed
>>         issues I reported earlier, or reported for an earlier version,
>>         to get that same attention. It shouldn't matter when I
>>         reported them (= when I noticed them), or for what version,
>>         as long as they still apply. Right? Wrong?
>>
>>         -- Niklas Matthies
>

[Nigel Leck]

There a number of mine that I would call "fixed" now. For example #151111 which is about the IDE being locked up during a scan. The IDE is certainly not doing that now. Should I just close it ? always want it faster thou.

[P.N.]

Hello Jiri!

So, what about the following situation: I've filed issue #175441, which
has been resolved as a duplicate of #157151 (reported as RFE for 6.7, 9
months ago) - how is this handled? And how should I handle this?

OTOH, shouldn't NB support as many features as possible of a supported
tool? I.e., is it really "only" a RFE? As usage of the JAXB plugin is
decreased by the missing plugin support, IMO this should be taken more
important.

Kind regards

Peter


Jiri Kovalsky wrote:

> Hello guys,
>
> Petr is right. Don't report bugs against old releases but rather verify
> them in current development builds and report them against 6.8. [68cat]
> get special attention on regular basis because we know such bug is
> coming from a trusted source. Furthermore, we track NetCAT income this
> way and you get 4 points for each bug you file and 2 points for an RFE. :-)
>
> Finally, it is possible to edit prefix and change it from [65cat] to
> [68cat] if the bug is still valid in 6.8 or add [68cat] if you didn't
> use simplified bug submission form. At least I do it myself whenever I
> spot some bug from NetCAT participant.
>
> Hope this helps,
> -Jirka
>
> Michel Graciano wrote:
>
>> Well, I usually add [68cat] for issues I can reproduce for the 6.8
>> version, even if these issues are still marked as 67cat for example.
>>
>> Regards
>>
>> On Mon, Oct 26, 2009 at 8:35 PM, Ulf Zibis
>> <Ulf.Zibis@...
>> <mailto:Ulf.Zibis@...>> wrote:
>>
>> In that case I followed the practice to add [68cat] in front or edit
>> the given tag.
>>
>> -Ulf
>>
>>
>> Am 26.10.2009 20:14, Matthies, Niklas schrieb:
>>
>> Quick questions:
>>
>> - Does it make sense to report issues for 6.7 and put
>> the [68cat] prefix on them because the problem hasn't
>> been addressed yet?
>> (As opposed to reporting them for 6.8, which would
>> be less accurate?)
>>
>> - Does it make sense to do this for 6.7 issues that we
>> reported before the 68cat program started?
>>
>> - ...or should such issues rather be "upgraded" to 6.8?
>>
>> More generally: I presume that the NetCAT-tagged issues
>> get some sort of priority treatment. (Or what other purpose
>> does the tag have?) But then of course I'd like for unfixed
>> issues I reported earlier, or reported for an earlier version,
>> to get that same attention. It shouldn't matter when I
>> reported them (= when I noticed them), or for what version,
>> as long as they still apply. Right? Wrong?
>>
>> -- Niklas Matthies
>

[Jiri Kovalsky]

You (as the reporter) are in the best position to close your bug if you think it is no longer valid. So, yes please close it.

   Although I understand that people always want more, speed improvements have their limits. Parsing huge codebases is an expensive task which will always take some time depending on hardware, number of classes, projects setup, their dependencies etc.

   However, if you see that some operation is significantly faster in some competitive IDE, file new bug with precise measurements and as much information as possible.

Thanks for your ongoing support Nigel!
-Jirka

Nigel Leck wrote:
> There a number of mine that I would call "fixed" now. For example #151111
> which is about the IDE being locked up during a scan. The IDE is certainly
> not doing that now. Should I just close it ? always want it faster thou.

[Jiri Kovalsky]

Hi Eric,

   no, I am not requesting you to go through all your issues and check their validity in 6.8. On the other hand, any change on issue generates an e-mail notification that attracts attention and reminds developers about it. There are thousands of open issues and if you dedicate some time to highlighting few of them it might help when developer thinks about which bug to fix next. In addition to that you can also find out that some bug magically disappeared. :-)

I hope you understand what I mean.
-Jirka

Eric M. Smith wrote:

> So Jiri,
>
> Are you saying we should all go back through our reported open bugs in
> [65cat] and [67cat] and check if they are still in 6.8, then update the
> subjects .  Thereby bringing the bug to the development teams attention
> and scoring more points in the process?
>
> Eric
>
> Jiri Kovalsky wrote:
>> Hello guys,
>>
>>   Petr is right. Don't report bugs against old releases but rather
>> verify them in current development builds and report them against 6.8.
>> [68cat] get special attention on regular basis because we know such
>> bug is coming from a trusted source. Furthermore, we track NetCAT
>> income this way and you get 4 points for each bug you file and 2
>> points for an RFE. :-)
>>
>>   Finally, it is possible to edit prefix and change it from [65cat] to
>> [68cat] if the bug is still valid in 6.8 or add [68cat] if you didn't
>> use simplified bug submission form. At least I do it myself whenever I
>> spot some bug from NetCAT participant.
>>
>> Hope this helps,
>> -Jirka

[snip]

[Jiri Kovalsky]

Hello Peter,

   while I understand your frustration, we have only limited resources and we simply can't develop everything in superior quality in one release. Hence we must prioritize what is important in terms of alignment with Sun business goals and decide what will come next, what will stay as is and what will be dropped. It would be nice to support all available technologies but we really can't afford it. Luckily this is an open source project and everybody can contribute. That's why we have NetFIX [1] or NetDEV [2] programs.

[1] http://wiki.netbeans.org/NetFIX
[2] http://wiki.netbeans.org/NetDEV

   What happened in your case is normal. What you see as an obvious defect, represents RFE for us, because JAXB plugin support was never implemented, thus it is not a regression in reality.

Thanks for your understanding,
-Jirka

epdv wrote:

> Hello Jiri!
>
> So, what about the following situation: I've filed issue #175441, which
> has been resolved as a duplicate of #157151 (reported as RFE for 6.7, 9
> months ago) - how is this handled? And how should I handle this?
>
> OTOH, shouldn't NB support as many features as possible of a supported
> tool? I.e., is it really "only" a RFE? As usage of the JAXB plugin is
> decreased by the missing plugin support, IMO this should be taken more
> important.
>
> Kind regards
>
> Peter
>
>
> Jiri Kovalsky wrote:
>> Hello guys,
>>
>> Petr is right. Don't report bugs against old releases but rather verify
>> them in current development builds and report them against 6.8. [68cat]
>> get special attention on regular basis because we know such bug is
>> coming from a trusted source. Furthermore, we track NetCAT income this
>> way and you get 4 points for each bug you file and 2 points for an
>> RFE. :-)
>>
>> Finally, it is possible to edit prefix and change it from [65cat] to
>> [68cat] if the bug is still valid in 6.8 or add [68cat] if you didn't
>> use simplified bug submission form. At least I do it myself whenever I
>> spot some bug from NetCAT participant.
>>
>> Hope this helps,
>> -Jirka

[snip]

[P.N.]

Thanks for Your reply - but You answered only the second question. ;)

However, I'd like to work on the JAXB module, but whenever I'm doing
sth. with NetBeans, there're some problems:
- modules using - often undocumented - friend apis
   (don't yet know for xml.jaxb)
- xml models (xam/xdm) without documentation (the only available docs
   about xam-usage are incomplete and outdated)
- functionality not described, so it's hard to find out where to fix
   some problems
- ...

I'm currently trying to solve some of my older problems. One of my
problems is, that editors are found by mime types. I've some docs which
should get a special mime type only if they're referenced by my own
project type. The only possible solution without breaking part of the
netbeans functionality will be to implement a FileSystem for the sub
directory containing my data, and to use this as my source path ...

Kind regards

Peter


Jiri Kovalsky wrote:

> Hello Peter,
>
> while I understand your frustration, we have only limited resources and
> we simply can't develop everything in superior quality in one release.
> Hence we must prioritize what is important in terms of alignment with
> Sun business goals and decide what will come next, what will stay as is
> and what will be dropped. It would be nice to support all available
> technologies but we really can't afford it. Luckily this is an open
> source project and everybody can contribute. That's why we have NetFIX
> [1] or NetDEV [2] programs.
>
> [1] http://wiki.netbeans.org/NetFIX
> [2] http://wiki.netbeans.org/NetDEV
>
> What happened in your case is normal. What you see as an obvious defect,
> represents RFE for us, because JAXB plugin support was never
> implemented, thus it is not a regression in reality.
>
> Thanks for your understanding,
> -Jirka
>
> epdv wrote:
>
>> Hello Jiri!
>>
>> So, what about the following situation: I've filed issue #175441,
>> which has been resolved as a duplicate of #157151 (reported as RFE for
>> 6.7, 9 months ago) - how is this handled? And how should I handle this?
>>
>> OTOH, shouldn't NB support as many features as possible of a supported
>> tool? I.e., is it really "only" a RFE? As usage of the JAXB plugin is
>> decreased by the missing plugin support, IMO this should be taken more
>> important.
>>
>> Kind regards
>>
>> Peter
>>
>>
>> Jiri Kovalsky wrote:
>>> Hello guys,
>>>
>>> Petr is right. Don't report bugs against old releases but rather verify
>>> them in current development builds and report them against 6.8. [68cat]
>>> get special attention on regular basis because we know such bug is
>>> coming from a trusted source. Furthermore, we track NetCAT income this
>>> way and you get 4 points for each bug you file and 2 points for an
>>> RFE. :-)
>>>
>>> Finally, it is possible to edit prefix and change it from [65cat] to
>>> [68cat] if the bug is still valid in 6.8 or add [68cat] if you didn't
>>> use simplified bug submission form. At least I do it myself whenever I
>>> spot some bug from NetCAT participant.
>>>
>>> Hope this helps,
>>> -Jirka
>
> [snip]
>

[Jiri Kovalsky]

Hi Peter,

   xml.jaxb is a wrapper library module for jaxb JARs and it is currently divided into two modules xml.jaxb (API friend module) and xml.jaxb.api (API public module). xam/xdm has been created some time ago by developers in the US, who are no longer with us and it belongs to "xml" category. We also use it and also didn't find any useful documentation. :-( All I can suggest is to take a look at examples for example XML Retriever (org.netbeans.modules.xml.retriever.catalog package).

We have unfortunately no more information to share with you.

Hope at least this helps,
-Jirka

epdv wrote:

> Thanks for Your reply - but You answered only the second question. ;)
>
> However, I'd like to work on the JAXB module, but whenever I'm doing
> sth. with NetBeans, there're some problems:
> - modules using - often undocumented - friend apis
>   (don't yet know for xml.jaxb)
> - xml models (xam/xdm) without documentation (the only available docs
>   about xam-usage are incomplete and outdated)
> - functionality not described, so it's hard to find out where to fix
>   some problems
> - ...
>
> I'm currently trying to solve some of my older problems. One of my
> problems is, that editors are found by mime types. I've some docs which
> should get a special mime type only if they're referenced by my own
> project type. The only possible solution without breaking part of the
> netbeans functionality will be to implement a FileSystem for the sub
> directory containing my data, and to use this as my source path ...
>
> Kind regards
>
> Peter

[snip]

[P.N.]

Hi Jiri,

could You explain me within some words, what the XML retriever does?
Just to know the context/use cases in which it is used might help a lot.

Regards

Peter


Jiri Kovalsky wrote:

> Hi Peter,
>
> xml.jaxb is a wrapper library module for jaxb JARs and it is currently
> divided into two modules xml.jaxb (API friend module) and xml.jaxb.api
> (API public module). xam/xdm has been created some time ago by
> developers in the US, who are no longer with us and it belongs to "xml"
> category. We also use it and also didn't find any useful documentation.
> :-( All I can suggest is to take a look at examples for example XML
> Retriever (org.netbeans.modules.xml.retriever.catalog package).
>
> We have unfortunately no more information to share with you.
>
> Hope at least this helps,
> -Jirka
>
> epdv wrote:
>
>> Thanks for Your reply - but You answered only the second question. ;)
>>
>> However, I'd like to work on the JAXB module, but whenever I'm doing
>> sth. with NetBeans, there're some problems:
>> - modules using - often undocumented - friend apis
>> (don't yet know for xml.jaxb)
>> - xml models (xam/xdm) without documentation (the only available docs
>> about xam-usage are incomplete and outdated)
>> - functionality not described, so it's hard to find out where to fix
>> some problems
>> - ...
>>
>> I'm currently trying to solve some of my older problems. One of my
>> problems is, that editors are found by mime types. I've some docs
>> which should get a special mime type only if they're referenced by my
>> own project type. The only possible solution without breaking part of
>> the netbeans functionality will be to implement a FileSystem for the
>> sub directory containing my data, and to use this as my source path ...
>>
>> Kind regards
>>
>> Peter
>
> [snip]
>

[Jiri Kovalsky]

Hello Peter,

   it demonstrates how to download remote XML resources (for example WSDL) to local disk for use in a project. Imagine you have some *.wsdl file on web which references some XML schema which references another XML schema etc. You can check it out on your local disk and project will work normally even without Internet connection.

Hope this helps,
-Jirka

P.N. wrote:

> Hi Jiri,
>
> could You explain me within some words, what the XML retriever does?
> Just to know the context/use cases in which it is used might help a lot.
>
> Regards
>
> Peter
>
>
> Jiri Kovalsky wrote:
>> Hi Peter,
>>
>> xml.jaxb is a wrapper library module for jaxb JARs and it is currently
>> divided into two modules xml.jaxb (API friend module) and xml.jaxb.api
>> (API public module). xam/xdm has been created some time ago by
>> developers in the US, who are no longer with us and it belongs to "xml"
>> category. We also use it and also didn't find any useful documentation.
>> :-( All I can suggest is to take a look at examples for example XML
>> Retriever (org.netbeans.modules.xml.retriever.catalog package).
>>
>> We have unfortunately no more information to share with you.
>>
>> Hope at least this helps,
>> -Jirka

[snip]