Op 25-11-11 08:35, Dobrica Pavlinusic schreef:
> Should I keep my hands off Status field in bugzilla or try to update
> them to current master?
No, it would be bad for me to rely on bugzilla for my own internal
processes. If it's in master and working, I think it should be always OK
to mark it res
Op 25-11-11 04:20, Paul Poulain schreef:
> In a few months, we will have 40 different files. And hashing/CRCing
> 40 files is not negligible.
File_names_, not files. And CRCing on string of 40 filenames is pretty
negligible.
I just want to avoid people trucking along with new code on an old
datab
I'm working on a system which would allow me to automatically apply
arbitrary number of patches from bug tracker to new koha instance (using
unique git branch for it) for easy testing of multiple-patch
interaction.
It's in planning stage, but I started going through my Cc bugs in
Bugzilla and stum
On Thu, Nov 24, 2011 at 10:27 AM, Paul Poulain
wrote:
> Le 23/11/2011 21:01, Chris Nighswonger a écrit :
>> It may be a bit of a pain to some, but
>> it has worked through at least three release cycles. The proposed
>> change does not affect the user in any case.
> Yes it does: if a customer has s
On Thu, Nov 24, 2011 at 10:20 AM, Paul Poulain
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Le 24/11/2011 13:22, Robin Sheat a écrit :
>> Op 25-11-11 00:49, Ian Walls schreef:
>>> I do like the idea of hashes... but looking at it, we'd
>>> essentially be mimicking the data structur
Le 23/11/2011 21:01, Chris Nighswonger a écrit :
> On Wed, Nov 23, 2011 at 12:21 PM, Paul Poulain
> wrote:
>> Is there still a case that would cause pain ?
>>
>> kf & others proposed an IRC meeting to discuss of this. Is it still needed ?
>
> I would like to see us do something like this:
>
> 1.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 24/11/2011 13:22, Robin Sheat a écrit :
> Op 25-11-11 00:49, Ian Walls schreef:
>> I do like the idea of hashes... but looking at it, we'd
>> essentially be mimicking the data structure we already have with
>> Git commits. Plus, readability goes do
Op 25-11-11 00:49, Ian Walls schreef:
> I do like the idea of hashes... but looking at it, we'd essentially be
> mimicking the data structure we already have with Git commits. Plus,
> readability goes down.
Is readability an issue here? I was thinking a process like:
1) on each page (and this'll
We were discussing the following at hackfest:
a directory of atomic database updates. While my intent was for .pl files,
we could adapt to include .sql, as well. I just really like the idea of a
CHECK/DO/UNDO interface
A YAML file, edited by the RM only, that assigns those update files to a
spe
2011/11/23 Jared Camins-Esakov :
> You know what this thread is missing? 2 cents from yours truly!
>
>>
>> Perhaps a quick hash/CRC of the filenames of the patches that have been
>> applied? Should be quick to generated and test, and will tell us
>> immediately if we need to run again.
>
> +1 from
On 2011-11-21, at 8:52 PM, Paul Poulain wrote:
>
> Le 20/11/2011 01:09, Mason James a écrit :
>> now.. how could an .SQL only solution achieve this? - its
>> impossible, right?
>>
>> - using .pl patches, with a *combination* of perl and sql, would
>> allow us the best of both options - using .s
I'm with Chris N that a proof-of-concept test for this change would be
required first, before we switch over our entire process. What we have
works, just not as well as our new method could.
I think that when the decision is made to implement this, we switch to it
completely. Ideally, I'd like t
Robin Sheat
> Perhaps a quick hash/CRC of the filenames of the patches that have been
> applied? Should be quick to generated and test, and will tell us
> immediately if we need to run again.
That was another idea, but I thought a sufficient hash would be a very
long version number from the start
> I explain again my idea:
> * a patch related to a bug, that would end in 3.6.x, will require a
> installer/data/mysql/updatedatabase patch, as previously (no change here)
> * a patch related to an improvement, that will be released in 3.8 will
> require a admin>updatedd patch, the new mechanism.
14 matches
Mail list logo
