Re: [Cdk-jchempaint] Split JChemPaint engine bug reports from applet/application bug reports

[Christoph S. <ste...@eb...>]

I have my problems with this proposal because as it has been pointed out 
not for all bugs the underlying problem can so clearly be identified.

We decided a while ago that JCP would be re-integrated into the CDK and 
we certainly do not want to reverse that, even if it affects the work of 
one very important project leader.

I understand that you have a lot of work but in my opinion this move has 
the potential to make the life of others more difficult and more 
importantly is has a socially exclusive attitude. I'm fully aware, Egon, 
that that would never be your intention but still.

I agree, however, that we need to take to make a clear distinction 
between bugs and feature requests. I suggest to try to solve the problem 
of the underlying tool (no proper negative filter) instead of messing 
with our nice integrated community :-)

Regards,

Christoph

On 15/10/2009 17:26, Egon Willighagen wrote:
> 2009/10/15 Angel Herráez<ang...@ua...>:
>> Sorry, Egon, some of us lay users do not understand the implications
>> of your proposal. Maybe we don't need to...
>
> Oh, the more you understand the better... below is some things to keep
> in mind, but important is that if you, as user, find a bug in the
> JChemPaint applet or Swing application, and you do not know if it is a
> CDK library problem, you file it against that applet of application.
> Similarly, if you find, as user, a bug in the JChemPaint functionality
> in Bioclipse, the Bioclipse bug tracker is the first bug track system
> you should think about.
>
> If the bug is really in the CDK library, the developers of either
> applications that use the new rendering and editor functionality in
> the CDK branch will find its way into the CDK bug track system.
>
> Or, as I formulated it to another list earlier today:
>
> "Now, it is clear that users will not always directly see if the bug he
> is looking at is a JChemPaint applet bug, or a bug in the CDK library
> (which includes the new cdk.render and cdk.control modules developed
> under the jchempaint-primary branch)...
>
> While it is up to the developers primarily to decide whether a bug is
> a applet bug or a CDK library bug, here are some points how you can
> recognize the source of bugs (or just limitations such as missing
> features):
>
> CDK bugs include (but are not limited to):
> * incorrect information parsed from input formats
> * incorrect creation of output formats
> * 'clean up' throws an exception or draws ugly molecules
>
> JChemPaint application/applet bugs include (but not limited to):
> * printing does not work
> * file is saved in the wrong location
> * copy/paste to the clipboard is not working
> * that button(...) looks ugly
> * I cannot change the charge(...) of that atom
>
> I hope this gives you come feeling where bugs originate from and can
> best be filed. If you are uncertain, and you want to file a bug in the
> applet (which is not discouraged at all!), just pick the JChemPaint
> tracker, and it will get sorted out. Just like how CDK library bugs
> found with the JChemPaint functionality in Bioclipse eventually find
> the CDK bug tracker... those are filed first at the application bug
> tracker first too."
>
> If you have more questions, please don't hesitate and ask.
>
> Egon
>

-- 
Dr. Christoph Steinbeck
Head of Chemoinformatics and Metabolism
European Bioinformatics Institute (EBI)
Wellcome Trust Genome Campus
Hinxton, Cambridge CB10 1SD UK
Phone +44 1223 49 2640

Video meliora proboque deteriora sequor.
                 ... Ovid, Metamorphoses VII, 20/21