IRC log for #koha, 2007-08-19

All times shown according to UTC.

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:[…]es/
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:[…]
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:
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
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:
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 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's archive key:
17:36 kados wget -O - | 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 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: 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:
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[…]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?

| Channels | #koha index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary