On 1 December 2011 08:47, Paul wrote:
> Just built a new server (Ubuntu 11.10) and preparing it for a fresh install
> of Koha 3.6.1 -- we're trying to take all precautions ahead of time, so ran
> the Perl dependencies script:
>
> paul@nelson:~/koha/koha-3.06.01$ perl koha_perl_deps.pl -m -u
> [Wed
Just built a new server (Ubuntu 11.10) and preparing it for a fresh install
of Koha 3.6.1 -- we're trying to take all precautions ahead of time, so ran
the Perl dependencies script:
paul@nelson:~/koha/koha-3.06.01$ perl koha_perl_deps.pl -m -u
[Wed Nov 30 09:07:17 2011] koha_perl_deps.pl: could
On Wed, Nov 30, 2011 at 11:34 AM, Paul Poulain
wrote:
> Le 30/11/2011 16:58, Chris Nighswonger a écrit :
>> I maintain my opposition to not back-porting the db update changes.
>
> Just to be clear: I have no opposition to back-port this improvement. I
> just was not seeing why it would be necessar
Le 30/11/2011 16:58, Chris Nighswonger a écrit :
> I maintain my opposition to not back-porting the db update changes.
Just to be clear: I have no opposition to back-port this improvement. I
just was not seeing why it would be necessary. Now I understand. And agree.
And nothing must be changed on
Le 30/11/2011 17:18, Ian Walls a écrit :
> As eager as I am to have a more robust database update method, I think
> the ship has sailed for 3.8. I believe the new mechanism should be part
> of both 3.6.x and master, so we're going to need a time when 3.6.x ==
> master, at least on the DB level. T
As eager as I am to have a more robust database update method, I think the
ship has sailed for 3.8. I believe the new mechanism should be part of
both 3.6.x and master, so we're going to need a time when 3.6.x == master,
at least on the DB level. That may or may not happen, as new features come
a
On Wed, Nov 30, 2011 at 10:53 AM, Paul Poulain
wrote:
> Le 30/11/2011 15:54, Chris Nighswonger a écrit :
>> 2. If the db update improvements are introduced into master during the
>> 3.7.x development cycle, they must be back ported to the 3.6.x branch.
>> The only condition I will withdraw this ob
Le 30/11/2011 15:54, Chris Nighswonger a écrit :
> We do need to make adjustments to make the life of a vendor as easy as
> possible.
OK, so we agree. I just want that ! (is my english saying something so
different than this ?)
> But rushing a db update change because Biblibre, or any
> other ven
On Wed, Nov 30, 2011 at 12:50 AM, Paul Poulain
wrote:
> Le 24/11/2011 17:02, Chris Nighswonger a écrit :
>> On Thu, Nov 24, 2011 at 10:27 AM, Paul Poulain
>> IMHO customers who want features before master inclusion is really a
>> vendor issue, not a community issue.
> Chris_n, I disagree (strongly
Le 30/11/2011 10:50, Magnus Enger a écrit :
> http://wiki.koha-community.org/wiki/2011-12-07_Global_bug_squashing_day
Just to let everybody know: BibLibre has planned working on bugzilla on
friday (in 2 days). It's too late for us to switch to dec 7th, so you
can expect an unusual activity on bugz
Yes, that's right, after some consultation on IRC I'm proposing two
dates, to avoid the short notices that have been creeping up on us
lately:
http://wiki.koha-community.org/wiki/2011-12-07_Global_bug_squashing_day
http://wiki.koha-community.org/wiki/2012-01-06_Global_bug_squashing_day
And yes, 2
Hi,
I agree with Paul that we need a clear description to be able to test a big
feature like this:
- does it add new system preferences?
- new options in other configuration parameters?
- does it need a cronjob?
- does it introduce new requirements?
- which modules/parts of Koha might be affec
Hello koha-devel,
I sometimes face patches that have a lot of comments, more than one
patch, and it's not always easy to understand how to test the proposed
patches.
We need the following things to be very clearly explained:
* test case / step to reproduce
* which patch(es) to apply
(* anything el
13 matches
Mail list logo
