(Please, reply to the developers mailing list.)
Hi all,
we are at risk loosing control over the CDK project.
A new hierarchy is needed to throttle CDK development at its new speed. The
growth in use and involvement in the project endangers maintenance. The
recent Bug Squash Party partially showed this: the participants were not able
to bring down the number of bugs in a significant way. Instead, the number
of failing bugs went up, though this is partly cause by the around 150 new
JUnit tests adding during that BSP.
Point is, however, the central role of me and Christoph as routing patching,
bug reports, etc, no longer scales. We need to reorganize, to handle keep up
with the current speed of development. (A similar reorganization is happening
for the CDK News.) At this moment, my CDK involvement is mainly driven by
keeping up with maintenance, instead of the CDK development being driven by
my needs.
This is my proposal: divide and conquer. That is, let's conquer CDK
development again, instead of having CDK conquer my spare hours.
I would like to propose the roles of "module maintainer" and "upstream author"
in the CDK development process with these responsibilities. I also added the
role of "CDK user", just to indicate how the rest of us interacts with these
first two, new roles.
===== Upstream Author =====
The upstream author is the author of a piece of code. Principally, the
original upstream author is identified by the Copyright statement in the
source header, though that is not updated in all files yet. If, for some
reason, the original author is no longer able to maintain the code, he can
orphan the code, and someone else can take over (*1), or, otherwise, the code
will end up in the CDK module 'orphaned'.
The current upstream author (upstream for short) has the responsibility of
fixing bugs in his or her source code (*2). Upstream will reply to bug
reports assigned to him, and apply or decline patches in his code. Upstream
does not wait until the MM says something must be done, but is proactive. The
MM just makes sure that you do your job properly.
===== ===== ===== =====
===== Module Maintainer =====
The module maintainer (MM) is a CDK developer who helps in managing CDK
development, by maintaining a CDK module (one of core, data, standard,
smiles, reaction, forcefield, etc. See [1]). His main responsibility is being
information broker; the responsibilities of the MM include making sure that:
- upstream gets notified about bugs
- upstream replies to bug reports
- bugs are reported in the source code using @cdk.bug
- bugs get assigned to a module in the SF bug tracker
- JUnit tests get written (by himself, bug reporter or upstream)
- bugs get fixed when a release is due
- keep an eye on code quality and report bugs if appropriate
Hence, it his *not* the MM's responsibility to fix bugs! He might happen to do
that, but then not in his role of MM. The MM is just an information broker.
===== ===== ===== =====
===== CDK User =====
The CDK user is just like the current user. The one who uses the CDK in
another project or directly in research. His responsibilities include:
- report problems to the bug list on SourceForge
- file patches to the patch tracker on SourceForge (optional)
===== ===== ===== =====
So, the setup looks like:
"User" <-> "SF Bug/Patch tracker" <-"Module Maintainer"-> "Upstream Author"
This is really just a formalization of what is currently being done. It's just
that I was MM for all modules. However, it is getting too much, and things
are going so fast now that I can no longer keep up. (help!)
Fortunately, we already have modules in the CDK. So, implementing this new
scheme should just be easy.
Therefore, who want to become MM? Let me know if you like to do this, or if
you have additional questions. Important is to let me know which module you
are interested in. The full current list is at [1]. But there is plenty in
the current extra which needs to be refactored into additional modules.
Again, being a MM does *not* require super-cow programming skills.
Egon
Notes
*1:use @cdk.upstream to indicate the active upstream author, if different from
the Copyright line
*2:this is now often *not* the case!
References
1.http://cheminfo.informatics.indiana.edu/~rguha/code/java/nightly/junitsummary.html
--
http://chem-bla-ics.blogspot.com/
Spam detection software, running on the system "smeltpunt.science.ru.nl", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
[EMAIL PROTECTED] for details.
Content preview: (Please, reply to the developers mailing list.) Hi all,
we are at risk loosing control over the CDK project. [...]
Content analysis details: (5.1 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
5.1 BAYES_99 BODY: Bayesian spam probability is 99 to 100%
[score: 0.9956]
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Cdk-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cdk-user
