| 2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 | Index | 2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Data Access / status of CVS repository |
| From: | Ralph Lange <[email protected]> |
| To: | ky9 <[email protected]> |
| Cc: | EPICS Core Talk <[email protected]> |
| Date: | Tue, 20 Sep 2005 11:27:21 +0200 |
ky9 wrote:
Maybe a way to go forward is to make the latest dataAccesss suite available, then we could be productive by trying it, finding shortcomings, maybe adding wrappers that might be more convenient etc.
I agree.While information hiding might be a good approach in OO programming, it doesn't seem appropriate for collaborative development.
But I also remember that Jeff has been severely bashed several times for comitting changes into the CVS repository that didn't compile successfully on all supported platforms. For DataAccess there have been complaints not too long ago (Aug 9th) about not all code in the DataAccess repository compiling, the documentation not being current, and test routines not matching the status of the libraries.
Demanding everything in the repository to be final, compiling and working and demanding all the latest changes and versions to be in the repository are contradictory positions that cannot be matched.
In the current situation - given the early and unfinished status of V4 and the separate location of the DataAccess repository - I would be fine with the stuff in the repository being not perfect, partly incomplete and not fully documented. I think we gain a lot more from seeing the current developments than from having a ready-to-use module at all times. If we tag versions that compile - maybe with a special tag that denotes the last compiling or "stable" version - anyone who needs something to compile against will still be able to get it.
To avoid misunderstandings I would like to have explicit agreement on this approach before encouraging Jeff to commit his latest changes. Asking him to commit unfinished work and then complaining about it being unfinished would be not too fair.
What do you think? Ralph