* 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 potenti
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 stil
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 Cam
Jared:
> Weighing in...
>
> I prefer option 1.
Me too. As soon as x.x.0 comes out, libraries start asking for
upgrades, we exist to provide services they want, so we'd like to give
them that. It's already enough to explain the versioning scheme,
without having numbered releases that aren't usab
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 opt
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
Weighing in...
I prefer option 1.
A specific problem is that we tend to test functionality of an
> enhancement not necessarily how that enhancement integrates with the
> eco-system of Koha and its these kind of conflicts that tend not to
> surface until its been deployed in the real world.
>
Thi
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 educa
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 r
+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 de
Nothing to say against that, of course :)
Option 1 is/has been our goal, but what actually happened was option 2..
Van: koha-devel-boun...@lists.koha-community.org
[mailto:koha-devel-boun...@lists.koha-community.org] Namens Ian Walls
Verzonden: donderdag 12 juli 2012 13:50
Aan: Fischer, Katrin
CC
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.
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 r
Hi all,
I agree with Chris on option 1).
We should always aim for the most stable release possible. Part of that is to
add more automated tests and to get our human testing better organized.
I think releasing a beta will mean that we will end up pushing risky things to
that version, because t
* 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 wha
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
Hello koha-devel,
I have some points to rise about our release process.
Koha 3.8 has been released 2.5 months ago, and some libraries have
reported major problems with 3.8.0. The main origin of those problems
came from the fact that a large feature (hourly loans) has been pushed
close to the relea
17 matches
Mail list logo
