From: Egon W. <ego...@gm...> - 2008-06-26 11:35:20
|
Hi all, I ran into a small situation yesterday about making commits to trunk/... 'We' recently adopted a scheme where new development is basically outside trunk, but the scope regarding bug fixes is more difficult to decide. Having maintained the CDK for years and having made numerous CDK releases, I know how difficult it is to maintain and further develop the CDK. Various reasons can be named that make this hard, such as: * incomplete or no JavaDoc * ambiguous JavaDoc * API duplication (sometimes with slightly different functionality) * bug fixes and workarounds * attempts to add (missing) functionality Etc Over the years a number of tools have been set up, like PMD, CDK modularization, JavaDoc checks, etc, to make the maintainability and releasing of the CDK easier. More recently, Rajarshi and Christoph also expressed concerns, which lead to the 'dictator' decision by the three of us, that the project must implement a new mechanism that ensure certain coding standards. One such 'tool' that has recently been considered is the use of branches. This allows code to be developed in a free manner, but also allows implementation of the requirement that code must be reviewed before entering trunk/. This ensures that any new code, has some basic level of maintainability. Now, what the exact final policies are regarding future CDK development, should be discussed by all CDK developers, and must be written up (documented) in a formal policy. The nice spin off of that is, that anyone who read and understood the content, and agrees with it, can automatically have SVN write access. No more fuzz about having a patch record, etc. Anyone can get SVN write access, when he/she accepts the policy. So, I started a new project cdk-policy in trunk/, where these currently implicit rules will be described and their purposes explained. IMPORTANT: it's a draft. The final version will require (as described in the draft) a 2/3 majority in-favor votes made by CDK Developers. Yes, it also describes who qualifies as CDK Developer, basically being those who have SVN write access (see above on how to get that). Yes, that introduces some bootstrapping issue, and I suggest that everyone can join the discussion and that the current people with SVN write access can vote on the final version. One more time, this is not about being bureaucratic; it's about ensuring CDK maintainability. The policy should be simple, easy to implement, easy to follow. Egon -- ---- http://chem-bla-ics.blogspot.com/ |
From: Egon W. <ego...@gm...> - 2008-06-28 14:02:32
|
Hi all, I am happy that no one disagreed much with what I wrote... On Thu, Jun 26, 2008 at 1:35 PM, Egon Willighagen <ego...@gm...> wrote: > So, I started a new project cdk-policy in trunk/, where these > currently implicit rules will be described and their purposes > explained. One thing I describe in the draft is a number of roles. Keep in mind that CDK is an open project, where anyone has a vote. Traditionally, those who actually code up solutions have a higher vote. CDK Member: Anyone who is subscribed to cdk...@li.... Therefore, anyone can become a CDK member; it's a bit more than just a CDK User (see below). There are ~74 CDK users (probably lower, as at least I have a few email addresses registered) [1]. CDK Developer: Any CDK Member with SVN write access. In the future, anyone who agrees to promises to live by the new CDK Policy can get SVN write access. Unlike now, where there needs to be some (marginal) patch history; however, since anyone can set up branches now to hack away, and that trunk/ is more controlled, people have the option to learn things while things can still be contributed to SVN. There currently are 57 CDK Developers [2]. There are a few sub categories, with extra/special rights and responsibilities: CDK Maintainer: A CDK Developer who supervises a particular CDK project and/or module. For example, Miguel for the reaction module, Christoph for the SDG module, and Thomas for the CDK-Taverna project. CDK Project Leader: A CDK Developer who oversees a particular bit of the CDK project infrastructures, such as the main CDK website, CDK News, and CDK Nightly. CDK User: Anyone else who is using a CDK project. It would be nice if we could use this Google map again: http://cdk.sourceforge.net/maps/people/ Red = developer, Yellow = user. Details are given on that page on how to get yourself added, though we could consider thinking about making icons for on webpages, with some links, so that a simple crontab script can check some Apache log, and grep long/lat from the image provider script, and automatically update the map. Egon 1.http://sourceforge.net/mail/?group_id=20024 2.http://sourceforge.net/project/memberlist.php?group_id=20024 -- ---- http://chem-bla-ics.blogspot.com/ |
From: Christoph S. <ste...@eb...> - 2008-06-29 16:25:51
|
Egon Willighagen wrote: > I am happy that no one disagreed much with what I wrote... Egon, there are people in this world with scan-through-all-email cycles with durations larger than two days :-) But I still do not disagree but do in fact applaud for taking our earlier discussion a step further. The Policy is a good way to do that. Thanks, Chris -- 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 What is man but that lofty spirit - that sense of enterprise. ... Kirk, "I, Mudd," stardate 4513.3.. |
From: Rajarshi G. <rg...@in...> - 2008-06-29 17:26:55
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jun 29, 2008, at 12:25 PM, Christoph Steinbeck wrote: > Egon Willighagen wrote: >> I am happy that no one disagreed much with what I wrote... > Egon, > > there are people in this world with scan-through-all-email cycles with > durations larger than two days :-) This raises a related point - how long should one wait for comments to a request? This is more relavent to some design issues (as opposed to a usage question or bug). In addition, this is relevant to the CDK Developer category - if someone wants to make a change, and they put out a message for discussion, at what point do/can they go ahead and just do it? One week? 2 Weeks? Is this approach even required? (I think so!) - ------------------------------------------------------------------- Rajarshi Guha <rg...@in...> GPG Fingerprint: D070 5427 CC5B 7938 929C DD13 66A1 922C 51E7 9E84 - ------------------------------------------------------------------- Got Mole problems? Call Avogadro at 6.02 x 10^23. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkhnxdwACgkQZqGSLFHnnoQUIwCguqDaR0M6WTWFhiwKuSpPjxt0 pRYAoK13o/bGLP/qGppcC3tF7sEBdzUL =dxC6 -----END PGP SIGNATURE----- |
From: Egon W. <ego...@gm...> - 2008-06-29 17:45:30
|
On Sun, Jun 29, 2008 at 7:26 PM, Rajarshi Guha <rg...@in...> wrote: > This raises a related point - how long should one wait for comments > to a request? This is more relavent to some design issues (as opposed > to a usage question or bug). In addition, this is relevant to the CDK > Developer category - if someone wants to make a change, and they put > out a message for discussion, at what point do/can they go ahead and > just do it? One week? 2 Weeks? Let's inherit the RFC policy for that. > Is this approach even required? (I think so!) Agreed. Egon -- ---- http://chem-bla-ics.blogspot.com/ |
From: Egon W. <ego...@gm...> - 2008-06-29 17:48:44
|
On Sun, Jun 29, 2008 at 7:26 PM, Rajarshi Guha <rg...@in...> wrote: > Is this approach even required? (I think so!) In any case... a Policy does come into action until voted upon, by all current CDK Developers, and a majority of the voters is in favor. So, a quick change will not be possible... Right now, it's just a draft... and I don't anticipate it to be ready before September earliest... We can then have our final discussion phase, followed by a voting phase. Egon -- ---- http://chem-bla-ics.blogspot.com/ |