| Time |
S |
Nick |
Message |
| 13:23 |
|
thd |
ryan: have you had time to test the authority frameworks? |
| 13:56 |
|
kados |
thd: g'morning |
| 13:56 |
|
kados |
thd: i did try the old one with 3.0 and it didn't have the problem that the new one had |
| 13:57 |
|
kados |
thd: http://staff-jmf.dev.kohalibra[…]es/authorities.pl |
| 13:57 |
|
kados |
thd: thd / thd |
| 14:14 |
|
owen |
Hi kados |
| 14:48 |
|
owen |
ryan, are you there? |
| 16:23 |
|
thd |
kados: what do you mean by old one and new one? |
| 16:40 |
|
thd |
kados: which one is the old one and which one is the new one? |
| 16:44 |
|
kados |
hi thd |
| 16:44 |
|
kados |
thd: i will explain |
| 16:44 |
|
thd |
hello kados |
| 16:45 |
|
kados |
thd: http://staff-jmf.dev.kohalibra[…]thorities-home.pl |
| 16:45 |
|
kados |
thd: thd / thd |
| 16:46 |
|
kados |
thd: thd you will see that those authorities work properly |
| 16:46 |
|
thd |
kados: I cannot do anything requiring more bandwidth than IRC for half an hour while my Debian update finishes downloading |
| 16:46 |
|
kados |
thd: they don't exhibit the issues that we had with the recent ones you committed to HEAD |
| 16:47 |
|
thd |
kados: so which ones do work? |
| 16:47 |
|
kados |
I don't know their origin |
| 16:47 |
|
kados |
but they are the ones currently in git |
| 16:47 |
|
kados |
and they aren't streamlined at all |
| 16:48 |
|
thd |
kados: we did not lose version history moving to git did we? |
| 16:48 |
|
kados |
no |
| 16:49 |
|
thd |
kados: so do you mean that they are only default or do they represent the various authorities |
| 16:49 |
|
kados |
thd: I will attempt to find the exact file |
| 16:50 |
|
kados |
thd: kados.org/stuff/02_authorities_normal_marc21.sql |
| 16:51 |
|
kados |
thd: that is the file currently in git that works |
| 16:51 |
|
thd |
kados: does that file have a header comment created by me? |
| 16:52 |
|
kados |
no |
| 16:53 |
|
thd |
kados: so that file has only one authority type, that is that file is only default, correct? |
| 16:58 |
|
kados |
hmmm |
| 16:58 |
|
kados |
I don't think so |
| 16:58 |
|
thd |
kados: or rather that file has no specific authority type because it is only default. Is that right? |
| 16:58 |
|
kados |
I think it has several types |
| 16:58 |
|
kados |
but all of them use the default framework |
| 16:58 |
|
kados |
I don't know for sure |
| 17:00 |
|
kados |
ahh |
| 17:00 |
|
thd |
kados: can you select a particular type from the authorities editor drop down list box even if all the types look the same? |
| 17:00 |
|
kados |
there's also an auth_types file |
| 17:00 |
|
kados |
kados.org/stuff/01_auth_types.sql |
| 17:00 |
|
kados |
thd: that contains the list of types |
| 17:01 |
|
thd |
kados: really, the design changed for 3.0 |
| 17:01 |
|
kados |
it did? |
| 17:01 |
|
kados |
how so? |
| 17:03 |
|
thd |
kados: well, maybe not but I populated 2 tables from one frameworks file for authorities just like it worked for bibliographic |
| 17:04 |
|
kados |
that should be fine |
| 17:04 |
|
kados |
you can see the two files |
| 17:04 |
|
kados |
auth_types is very small |
| 17:04 |
|
kados |
thd: http://kados.org/stuff/01_auth_types.sql |
| 17:05 |
|
kados |
thd: it won't affect your debian download |
| 17:05 |
|
thd |
kados: maybe the content for each of the respective tables was meant to use a separate file if there is an auth_types file and that would be small |
| 17:05 |
|
thd |
ok trying with lynx |
| 17:05 |
|
kados |
it shoudln't matter if it uses one file or many |
| 17:05 |
|
kados |
so long as the sql is formed correctly |
| 17:10 |
|
thd |
kados: if the SQL was malformed you would have had and SQL error |
| 17:11 |
|
thd |
I see that file now and that is the other table which only needs authority codes matching the ones I used. |
| 17:12 |
|
thd |
kados: have you tried marc21_standard_auth_frameworks.sql on Koha 2? |
| 17:17 |
|
kados |
no, I don't have a koha 2 to try it on |
| 17:17 |
|
kados |
I have been waiting for ryan to try it there |
| 17:18 |
|
thd |
kados: but you are still installing them for customers, and will be for the customer in question |
| 17:18 |
|
kados |
yes, but not me personally |
| 17:18 |
|
thd |
oh :) |
| 17:21 |
|
thd |
This should be an exciting Debian update. Bind is being replaced which is a little scary. |
| 17:24 |
|
thd |
kados: so what is ryan doing today? |
| 17:25 |
|
kados |
he isn't working today |
| 17:26 |
|
thd |
kados: does he work less than 20hrs a day 7 days a week? |
| 17:26 |
|
kados |
only this week :-) |
| 17:27 |
|
thd |
kados: are there instructions in the wiki about how to set up git for Koha versioning? |
| 17:32 |
|
thd |
kados: which git package should I install? There are many. |
| 17:34 |
|
kados |
are you running etch? |
| 17:34 |
|
thd |
yes |
| 17:34 |
|
kados |
ok, standby |
| 17:34 |
|
kados |
are you using pinning? |
| 17:34 |
|
thd |
git-cvs looks like a likely choice for importing CVS history |
| 17:35 |
|
thd |
kados: yes, I have always used pinning |
| 17:35 |
|
kados |
and if so, do you have a pinning config established for backports? |
| 17:35 |
|
thd |
yes |
| 17:35 |
|
thd |
well no |
| 17:35 |
|
kados |
/etc/apt/sources.list needs a line: |
| 17:36 |
|
kados |
deb http://www.backports.org/debian etch-backports main contrib non-free |
| 17:36 |
|
kados |
your preferences file needs: |
| 17:36 |
|
kados |
Package: mutt |
| 17:36 |
|
kados |
Pin: release a=etch-backports |
| 17:36 |
|
kados |
Pin-Priority: 999 |
| 17:36 |
|
kados |
you need to import backport.org's archive key: |
| 17:36 |
|
kados |
wget -O - http://backports.org/debian/archive.key | apt-key add - |
| 17:36 |
|
kados |
then apt-get update |
| 17:37 |
|
kados |
then apt-get install git-core |
| 17:38 |
|
thd |
kados: my pinning gives preference to version which is the most recent and etch which therefore gives preference to all backports |
| 17:38 |
|
kados |
ok, well you can test that theory by running: |
| 17:39 |
|
kados |
apt-cache showpkg git-core |
| 17:39 |
|
kados |
and make sure it is going to install version 1.5.2.1 of git-core |
| 17:39 |
|
thd |
kados: why would I ever need to explicitly give preference to backports unless I wanted to restrict particular backports from being installed? |
| 17:40 |
|
kados |
you wouldn't |
| 17:40 |
|
kados |
I do restrict particular backports from being installed though |
| 17:40 |
|
kados |
because in general, I trust the debian package maintainer above the backports one |
| 17:40 |
|
kados |
except in specific instances |
| 17:41 |
|
kados |
where I have time to confirm that the backports one is a sound update |
| 17:41 |
|
thd |
kados: that version of git-core is the default install or only available install on my current set up |
| 17:41 |
|
kados |
great! |
| 17:42 |
|
thd |
kados: I use an apt package which reports critical bugs before installation and gives a chance to abort |
| 17:42 |
|
kados |
*nod* |
| 17:43 |
|
thd |
kados: do I need anything in addition to git-core? |
| 17:44 |
|
kados |
nope |
| 17:45 |
|
thd |
kados: git-web looks useful |
| 17:46 |
|
thd |
kados: and git-load-dirs is described as a solution for potential loss of version history in git |
| 17:48 |
|
kados |
thd: that has already been taken care of |
| 17:48 |
|
kados |
thd: git.koha.org preserves all the hisotry of koha |
| 17:49 |
|
thd |
ok |
| 17:49 |
|
thd |
kados: is it running git-web? |
| 17:50 |
|
thd |
or some web browsing interface to the repository? |
| 17:51 |
|
kados |
yes |
| 17:51 |
|
thd |
kados: is that git-web or something different? |
| 17:53 |
|
thd |
kados: did you look at git-buildpackage for building Debian packages? |
| 17:55 |
|
kados |
no |
| 17:55 |
|
kados |
maybe mj knows about it though |
| 17:55 |
|
kados |
slef around? |
| 17:57 |
|
thd |
kados: I am sure it requires a little more effort than what one might hope but could be a major time saver for building Debian support for Koha if it lives up to the description. |
| 18:59 |
|
thd |
kados: how do I clone the repository as a committer? |
| 19:04 |
|
owen |
thd, do you mean do you have to clone a repository differently if you're committing or if you're not? |
| 19:05 |
|
owen |
I don't think you do |
| 19:05 |
|
owen |
git doesn't have CVS's concept of 'anonymous' |
| 19:06 |
|
thd |
owen: yes, but the Savannah maintainers told me that obtaining source as anonymous was a bad idea if I was also committing |
| 19:08 |
|
thd |
owen: so if anonymous source access is a bad idea for committers on CVS I assume that it is also bad on git. |
| 19:09 |
|
owen |
No, there's no way to clone a repo in an "authorized" manner, as far as I know |
| 19:09 |
|
owen |
In fact, anyone can commit, because they're committing to their /own/ repository |
| 19:09 |
|
thd |
owen: I never enquired about what the potential hazard is I just believed what they told me |
| 19:10 |
|
owen |
Changes only make it into the "master" repo if the developer submits the changes "upstream" (to the QA manager and RM) |
| 19:10 |
|
owen |
thd: that sounds right for CVS, just not for git |
| 19:12 |
|
thd |
owen: that sound like a terrible amount of extra work for the release and quality assurance managers if updating is timely |
| 19:12 |
|
thd |
s/sound/seems/ |
| 19:12 |
|
owen |
I think it will be more work, but it will also mean that the quality of accepted code should be higher |
| 19:13 |
|
owen |
With CVS you have trusted developers who can commit whatever they want. With git you've got at least one if not two other sets of eyes checking things before they go in |
| 19:14 |
|
owen |
I guess it's a trade-off. I had the same reaction as you--it sounds like a lot more work |
| 19:15 |
|
thd |
owen: actually that seems like the main repository will not be especially timely, that is it will have major bugs which are unreported and simply do not signify with the release and quality assurance managers because they are simply fixed by someone instead of reporting them |
| 19:15 |
|
owen |
I think for developers it will be a better system because each of us can have our own repo with our own commits and "personal" revision history |
| 19:15 |
|
owen |
Meaning people fix bugs in their own repos without sending patches to QA? |
| 19:16 |
|
thd |
owen: almost every time I have committed to CVS, I was fixing an unreported bug |
| 19:17 |
|
owen |
...and there's no reason why you can't continue to do so. You simply have to take the step of submitting a patch each time you've tested and committed a fix in your own repo |
| 19:17 |
|
thd |
owen: the bugs may have been minor but I certainly do not have time to fill out bug reports for every minor bug so that someone takes my commit seriously |
| 19:17 |
|
owen |
You don't have to fill out a bug report. When I say submit a patch, I don't mean via Bugzilla |
| 19:18 |
|
owen |
I mean via Git |
| 19:18 |
|
thd |
owen: I had forgotten about patches. yes , that is good |
| 19:18 |
|
owen |
At least that's my understanding of it. I've only been using Git for a week now :) |
| 19:19 |
|
thd |
owen: I just downloaded git and have not been using it yet |
| 19:20 |
|
thd |
owen: kados promised a formal announcement about the switch to git but I have not seen one yet |
| 19:20 |
|
owen |
I think there are still some details to work out in terms of what the recommended procedures will be |
| 19:20 |
|
thd |
owen: does it run well on MS Windows? |
| 19:21 |
|
thd |
s/well/easily/ |
| 19:21 |
|
owen |
Yes, it seems to work just fine. Although I haven't really given it much of a test since I'm just starting out. |
| 19:22 |
|
owen |
Here's what I'm using: http://code.google.com/p/msysgit/ |
| 19:23 |
|
thd |
owen: If there is anything noteworthy about the process of installing or using git on MS Windows please document that for Tumer. |
| 19:24 |
|
thd |
owen: I would like to keep tumer's fork as up to date as he can manage. |
| 19:25 |
|
owen |
tumer's fork is in CVS still though? I wonder if there's any reason not to leave it there. |
| 19:26 |
|
thd |
owen: the main Koha repository should eventually catch up with tumer's work and then he should have less need for a fork |
| 19:31 |
|
thd |
owen: how can I manage more than one project in the same git installation? |
| 19:32 |
|
owen |
As far as I know, you can clone any number of projects. The working files end up in their own directories, and git keeps track of what you're working on based on where you are in the directory structure |
| 19:33 |
|
thd |
owen: what do you mean by based on where you are? |
| 19:33 |
|
owen |
Again, this is all "as far as I know," because I'm just getting started... |
| 19:34 |
|
owen |
If I clone a repository into a directory, koha... |
| 19:34 |
|
owen |
And I'm navigating that directory or subdirectories in the command line... |
| 19:35 |
|
owen |
Then git knows that I'm working on the 'koha' repo clone |
| 19:35 |
|
owen |
If I change directories and move to where another project's working files are, git knows from that context that I'm in another project. |
| 19:38 |
|
thd |
owen: how is that different from working with CVS? |
| 19:39 |
|
owen |
I'm the wrong person to ask about that, because I'm used to working with CVS in Windows |
| 19:39 |
|
thd |
s/CVS/CVS checkouts |
| 19:40 |
|
thd |
owen: does the MS Windows version of git use a GUI instead of the command line? |
| 19:40 |
|
owen |
No |
| 19:41 |
|
owen |
It's just a package of files that replicate the right environment to run git as does on Linux |
| 19:43 |
|
thd |
owen: what exact URL should I use to clone all branches of the Koha repository? |
| 19:44 |
|
owen |
http://wiki.koha.org/doku.php?[…]public_repository |
| 19:44 |
|
owen |
...although I don't know what you mean by "all branches." That gets you rel_3_0. |
| 19:44 |
|
owen |
Nothing else is in git |
| 19:45 |
|
thd |
owen: so rel_2_2 is still being maintained in CVS? |
| 19:45 |
|
owen |
Yes |
| 19:45 |
|
thd |
;) |
| 19:45 |
|
owen |
rel_2_2 and dev_week |
| 19:45 |
|
thd |
I really missed the memo on how this was being done |
| 19:46 |
|
thd |
owen: is the intention to move everything to git and HEAD is the initial test? |
| 19:46 |
|
owen |
I don't know |
| 19:52 |
|
owen |
thd, fact-check everything I've said with kados or chris ;) |
| 19:53 |
|
thd |
owen: did you not receive the memo either? :) |
| 19:54 |
|
owen |
the memo? |
