Hi Paul, all,
* Release the 3.X.0 saying it's a beta, could have some bugs not detected.
The 3.X.1 being a RC, and the 3.X.2 being the 1st really stable version.
+1 for this second option. You could say that it makes more formal what one
could already suspect about a 3.X.0 release.. No real
* Marcel de Rooy (m.de.r...@rijksmuseum.nl) wrote:
Hi Paul, all,
* Release the 3.X.0 saying it's a beta, could have some bugs not detected.
The 3.X.1 being a RC, and the 3.X.2 being the 1st really stable version.
+1 for this second option. You could say that it makes more formal what one
I'm mostly in favour of solution 1 (in that it's close to what I think we
should to, and solution 2 is not good in my opinion). But I think there is
a little more to it.
There are several factors in our current workflow and environment that are
causing these bugs and regressions:
- *Lack of
I think I too side with option 1.
As much as I would enjoy googleizing our naming scheme and adding beta to
the end of every initial release I don't think it is practical for our
product. While enhancements are an important part of Koha I don't believe
we should put them ahead of its stability.
+1 - I think Ian made a lot of good points in his mail
And I also agree with Marcel, I only think we should stop it from happening in
the first place J
Katrin
From: koha-devel-boun...@lists.koha-community.org
[mailto:koha-devel-boun...@lists.koha-community.org] On Behalf Of Marcel
On Thu, Jul 12, 2012 at 06:54:36AM -0500, Elliott Davis wrote:
I think I too side with option 1.
Releases are inherently evil things, (like all deadlines). There is a
temptation always to pack stuff in there to make a release an event. I
dont think having beta releases helps ( or skipping .1
I think a recruitment and training effort by the Koha community
targeting potential programmers should be considered; I do understand
the decentralized structure of the open-source community might make this
difficult. Below I suggest one potential candidate pool of Koha developers.
I have an
Hello.
Triggered by bug 8206 (add additional search options to authority browser
on OPAC: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8206)
Marcel, Katrin, and I have been discussing the inconsistent indexes used
for searching authorities in the staff client an OPAC. Somewhere in git
Hello -
We have recently hired another Developer (Elliot Davis - libsysguy ;) ),
who is charged with creating a more integrated testing suite for ByWater
and getting/challenging some of our partners to complete testing that isn't
automated already or would be difficult to automate.
As for the
If no one can voice a reason to have separate indexes for the OPAC v. the
staff client, best to use the same ones. It's what we do for biblios, and
authorities is just another Zebra database.
Keeping things simple will improve life for everyone.
-Ian
On Thu, Jul 12, 2012 at 12:35 PM, Jared
Brendan,
I think the thing that I struggle with is the definition of a Freeze...
Please speak up and correct me if I am wrong here. This is what I think it
means currently - if something has an enhancement bug listed (i.e. the idea
is out there before the freeze date) - then it could still be
* glaws (glaw...@rhcl.org) wrote:
I think a recruitment and training effort by the Koha community targeting
potential programmers should be considered; I do understand the
decentralized structure of the open-source community might make this
difficult. Below I suggest one potential
12 matches
Mail list logo
