> - I believe that there should also be a statement regarding performance > testing (since we have a framework for it now ;->), similar to the stament > regarding integration testing. Something like 'In addition each subproject is > expected to maintain a relevant set of performance tests in the form of > JMeter plans'.
Agree and added > - Regarding the up to date docs, I would like to explicitly add the need of > describing changes (especially backwards incompatible changes; simply a must > have) in the new release. Also I would like to see 'documentation' further > specified; WIKI, javadoc, example bundle, etc. I tried to keep the principles short and crispy. True that we need some consensus on what/where/how to document (I personally like to travel light). Anyway, a subpage could be added with details. > - Regarding 3 - reviewed commits. Of course I agree that each commit should > be reviewed, but I'm hesitant about creating and attaching patches for any > JIRA issue I resolve. It introduces overhead, both for the developer and the > reviewer. Furthermore, if I'm fixing many issues at the same time and the > reviewer is 'busy' this really becomes a struggle. I agree that this is the > way to go for large or high-risk changes but do not see any reason to do this > for all JIRA issues. Strict rules, lenient execution? I agree a lead on some code should be allowed to actively commit small changes. regards, Bram On Tue, Apr 5, 2011 at 10:51 AM, Ivo Ladage-van Doorn <[email protected]> wrote: > Hi Bram, > > A few comments; > > - I believe that there should also be a statement regarding performance > testing (since we have a framework for it now ;->), similar to the stament > regarding integration testing. Something like 'In addition each subproject is > expected to maintain a relevant set of performance tests in the form of > JMeter plans'. > - Regarding the up to date docs, I would like to explicitly add the need of > describing changes (especially backwards incompatible changes; simply a must > have) in the new release. Also I would like to see 'documentation' further > specified; WIKI, javadoc, example bundle, etc. > - Regarding 3 - reviewed commits. Of course I agree that each commit should > be reviewed, but I'm hesitant about creating and attaching patches for any > JIRA issue I resolve. It introduces overhead, both for the developer and the > reviewer. Furthermore, if I'm fixing many issues at the same time and the > reviewer is 'busy' this really becomes a struggle. I agree that this is the > way to go for large or high-risk changes but do not see any reason to do this > for all JIRA issues. > > For the rest I think the list is complete and OK. > > Regards, Ivo > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Bram de Kruijff > Sent: dinsdag 5 april 2011 9:26 > To: [email protected] > Subject: [Amdatu-developers] Site and qa > > Hi list, > > on the site: as you may have noticed by now I restructured our website > a little and put in some prev missing pages. Furthermore I have put > the important stuff (platform/subprojects) on top in seperate trees to > reflect their independence. Btw. note I sneaked in 'Amdatu Platform' > for the core project... Not at all final and I think we need to put in > some more effort for other people the be able to make sense of it ;) > Give me your feedback or, even better, contributions. > > on the qa: as requested in the offline discussion last week I have put > down for QA 'principles' at > http://www.amdatu.org/confluence/display/Amdatu/Conventions+and+guidelines > . Let me know if you can live by them. If not your input please! > > grz > Bram > _______________________________________________ > Amdatu-developers mailing list > [email protected] > http://lists.amdatu.org/mailman/listinfo/amdatu-developers > > _______________________________________________ > Amdatu-developers mailing list > [email protected] > http://lists.amdatu.org/mailman/listinfo/amdatu-developers > _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
