Greetings, all,
As we head toward a significant upgrade of the hackystat core subsystem and
brand new user interface, I am reflecting on the level of 'ripple effect'
that Hongbing experienced with the workspace redesign.
I am thinking that we should consider "retiring" some modules that are not
actively used in order to reduce the overhead on our development resources.
My candidates for 'retirement' are:
- hackyApp_Cgqm
- hackyApp_Course
- hackyApp_Hpcs
- hackyApp_Mds
- hackyApp_Pri
- hackyApp_PrjSize
- hackyApp_Review
- hackySdt_ReviewActivity
- hackySdt_ReviewIssue
- hackySdt_WorkspaceMap
- hackySensor_JunitMaven
- hackySensor_LoccMaven
The benefit is that by reducing the number of modules to maintain, it will
be easier and faster for us to implement improvements to 'low level'
features since there is less code to upgrade. The disadvantage is that this
code will get out of date quickly and not even be able to compile. This
also means we would be able to delete the following configurations from our
daily build:
hackystat-cgqm
hackystat-cocomo
hackystat-hpc
hackystat-mds
The way I would do this is as follows:
1. Create a new svn repository called hackystat-exp (for 'experimental').
2. Import the head of these modules into the new repository.
3. Delete these modules from the hackystat repository.
4. Delete the above configurations from the daily build.
What's important to note about this is that people can always create local
hackystat/ source directories with a mixture of modules from the hackystat
and hackystat-exp repositories. Thus, if you really want hackyApp_Cgqm in
your local server, for example, and are willing to maintain it, then you
can still do so. The difference is that the UH hackystat development team
is no longer responsible for making sure the 'hackystat-exp' modules
compile and pass their unit tests as part of the daily build. I think this
will make us more nimble and able to move in our current directions
(improved usability and scalability) more efficiently and effectively. It
also creates the ability to differentiate between 'experimental' modules
and 'supported' modules, which we didn't have before.
So, please think about this and if you see any problems, please bring them
up. I would like to implement this change by the end of this week if
possible.
Cheers,
Philip
