Hi Helix
1. The issues regarding experimental features may have been avoided by
using: http://wiki.lib.sun.ac.za/index.php/SUNScholar/Reference_Architecture,
as i mentioned in an email previously to the dspace-tech mailing list I
think.
2. About the solution - let me expand - the previous email was long and I
did not want to lose reader attention.
It's simple... Some very large production institutions who have the full
technology support stack available can be the "official new release
testers" for new features for a certain amount of time, before a "stable"
release is issued. This is if they are willing to do it to help the
Duraspace community. My analogy with Debian seems to have misled the lists
- sorry. The issue is to test new features in large production environments
with all types of reference architecture before a stable release is
announced.
Cheers
hg
*Hilton Gibson*
Ubuntu Linux Systems Administrator
JS Gericke Library
Room 1025D
Stellenbosch University
Private Bag X5036
Stellenbosch
7599
South Africa
Tel: +27 21 808 4100 | Cell: +27 84 646 4758
http://scholar.sun.ac.za
http://bit.ly/goodir
http://library.sun.ac.za
http://za.linkedin.com/in/hiltongibson
On 28 January 2014 16:56, helix84 <[email protected]> wrote:
> Hi Hilton,
>
> On Tue, Jan 28, 2014 at 3:09 PM, Hilton Gibson <[email protected]>
> wrote:
> > 1. We had to set the "maxHttpHeaderSize" parameter for Tomcat 6, when
> using
> > Tomcat without the Apache "mod_jk" module.
>
> this was specific to your environment:
> 1) You enabled the (optional in DSpace 3) Discovery module and
> 2) you had a large number of users in a group, that exceeded the
> default limits of Tomcat (HTTP header size).
>
> I agree that, with Discovery being the default in DSpace 4, it's
> important to fully support it. But, unfortunately, limits in Tomcat is
> something we have zero influence on. The only thing we can do better
> is to document it.
>
> > 2. We had to delete some old tables in the PostgreSQL DB relating to the
> > conversion of the browse indexes to the SOLR DB.
>
> Again, you chose to enable a non-default, experimental feature in
> DSpace 3 (Solr browse DAOs). It had a known bug with a documented
> workaround and it's fixed in DSpace 4 where this is enabled by
> default.
>
> As you can see, there is little else that could have been done to
> prevent this, regardless of our release/versioning/support
> infrastructure. Bugs do happen and we do try to fix them.
>
> > ==Possible Solution==
>
> I'm very familiar with both Debian and DSpace. As you know, several
> years ago DSpace opted for time-based releases. These are basically
> the anti-thesis of "released when ready", although we do adopt its
> freeze/test/release strategy for all major releases. It is my personal
> opinion that time-based releases have proved to work very well for the
> DSpace community and I don't see the incentive to change them. A
> similar strategy - LTS releases - could work, but from a practical
> standpoint there would have to be developers commited to maintaining
> an old version with bug fixes for many years including the stack of
> old versions of dependencies which are also being phased out of
> support - I currently don't see anyone interested in doing this.
>
>
> Regards,
> ~~helix84
>
> Compulsory reading: DSpace Mailing List Etiquette
> https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
>
------------------------------------------------------------------------------
WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
security issues and trends. Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
