In yesterday's IRC, "CVS and Arch" was one of the last things discussed and some of the developers had to be in other places by then, so I agreed to summarise to the list and start discussion here. Please wade in with comments or questions as you see fit. Here we go! Introduction: I introduced GNU Arch http://www.gnuarch.org/ which solved the problems I had getting 2.0 under control and making tarballs from it. The move mostly consisted from making a tarball from CVS, unpacking it and then adding the files to an Archive. That's what you can get from my development page at http://www.mjr.dsl.pipex.com/ Anyone can make their own copy of the koha2 archive and publish it if they have a public file space (web, ftp or sftp for sure). That works for mirrors and for development branches. So, new developers have full revision control easily, by default, rather than needing hacks or write access to the release source tree. A release manager can merge their changes into the release tree with a simple command. Apart from merging, all operations happen on your own file space, which eliminates the wait for a central server to answer that often holds me back with CVS. Suggestion and tasks: I suggest trying to move to arch for 2.4 development if we can get it working for current developers, because it should make the lives of the release managers and new developers a lot easier. I've offered to answer questions and improve my tutorial until it's good enough. Some commented about having large amounts of CVS experience, but there didn't really any great love for CVS, more a feeling of "better the devil we know". The sticking points are likely to be users of GUI interfaces and Microsoft Windows, so I'd be very happy about offers to help with those. No other public archives for 2.0 were posted, which I think is a shame, but I guess 2.2 has all the appeal for developers now. A couple of people mentioned that they would like 2.0 commit messages to koha-cvs, so I'll try to set that up. There was a suggestion of compiling a list of benefits and drawbacks of each system, but I think that's probably already covered by http://wiki.gnuarch.org/moin.cgi/SubVersionAndCvsComparison or could be (it's a wiki). Finally, what would happen to the CVS? I'd leave it as a historical record, with some clear marking that development has moved on. You can transfer some of the history to Arch, but it's an attempt to reconstruct information that isn't really kept by CVS, so it seems more trouble than its worth. -- MJR/slef My Opinion Only and not of any group I know Creative copyleft computing - http://www.ttllp.co.uk/ http://www.thewalks.co.uk stand 13,Lynn Carnival,12 Sep
MJR et al, I've installed arch and documented the process on my blog (http://kados.org). Thanks to MJ for putting the instructions together (at http://www.mjr.dsl.pipex.com/). I've also got a public mirror of my archive up at http://kados.org/arches So ... where in the archive is the Koha repository? I see a couple of tar.gz files ... is that it? And can we talk about naming conventions? the tar.gz files are called affsweb--mainline--2.0--base-0.tar.gz and ...patches.tar.gz. I think the term 'koha' should appear in those names. I'm sure as I play more with arch I'll have further questions, but that's it for now. Thanks, Joshua
On 2004-09-22 19:20:21 +0100 Joshua Ferraro <jmf@kados.org> wrote:
So ... where in the archive is the Koha repository? I see a couple of tar.gz files ... is that it? And can we talk about naming conventions? the tar.gz files are called affsweb--mainline--2.0--base-0.tar.gz and ...patches.tar.gz. I think the term 'koha' should appear in those names.
OK, first up, you've grabbed the project I wrote the example for originally. You want the details for koha2 from the page http://www.mjr.dsl.pipex.com/ I'll update/enlarge the instructions to make that clear, but basically: 1. Replace webmaster@affs.org.uk--2004/affsweb--mainline--2.0 with mjr@dsl.pipex.com--koha20/koha--release2--0.1 2. Replace affsweb--mainline--2.0 with koha--release2--0.1 There will be the first release2--0.2 upload in the next few hours. By the way, http://kados.org/ is a single page that says "<greek>kados</greek> is loading" and does nothing else. Is that correct? -- MJR/slef My Opinion Only and not of any group I know Creative copyleft computing - http://www.ttllp.co.uk/ LinuxExpo.org.uk village 6+7 Oct http://www.affs.org.uk
On Wed, Sep 22, 2004 at 08:37:03PM +0100, MJ Ray wrote:
By the way, http://kados.org/ is a single page that says "<greek>kados</greek> is loading" and does nothing else. Is that correct? Not anymore :-). I used a ScripAlias to direct index requests right to my blog page. BTW: for the sake of clarity, the permanent links to my arch blogs are:
http://kados.org/2004/09/22#arch_initial http://kados.org/2004/09/22#arch_install Thanks again MJ! Joshua
MJ et al, OK ... I've finally got the archive working and I was able to check out a working copy, etc. (http://kados.org/2004/09/23#arch_revisited) (BTW: here's the actual rgister-archive command ...) tla register-archive mjr@dsl.pipex.com--koha20 \ http://www.mjr.dsl.pipex.com/koha20/ However, I'm still not clear on how the mirror is supposed to work (at least it seems not to be working right for me). When I browse the archive in Mozilla (http://kados.org/arches) I don't see the actual Koha files anywhere (but they are in my working copy) ... just the tar.gz files (or does arch natively store the repo as a tar.gz file?) The commands I used to build the mirror are listed in the above blog entry. Thanks, Joshua
On 2004-09-23 13:03:41 +0100 Joshua Ferraro <jmf@kados.org> wrote:
However, I'm still not clear on how the mirror is supposed to work (at least it seems not to be working right for me). When I browse the archive in Mozilla (http://kados.org/arches) I don't see the actual Koha files anywhere (but they are in my working copy) ... just the tar.gz files (or does arch natively store the repo as a tar.gz file?)
Yes, arch basically stores the repo as a tar.gz of sources and a tar.gz of patchfiles and some instructions; along with that goes some metadata like the email-style log file. This is engine mechanics, though. To me, it has the benefit of being neatly compressed (quick to mirror) and allows a beta/pre tarball to be created with one simple command. The drawback is that you do have to download or checkout a working copy to look at the files. That's the same for CVS and most people using web access to cvs use viewcvs or similar. Some Arch frontends are on http://wiki.gnuarch.org/moin.cgi/Arch_20Revision_20Browsers
The commands I used to build the mirror are listed in the above blog entry.
That's not a mirror. That's your own local branch. You can do some work, commit it and tell me to merge it. You can branch it and generally moosh it about how you want. (One request: don't make more than one archive with the same name, else I may go nuts later.) Imagine having your own local CVS copy of koha that you have total admin control over. You can put more than one branch in each archive, too, which is what koha2--release2-0.2 will be. Mirrors are created by the archive-mirror command, but I think they're not very interesting other than for distributing files around the world, or publishing a local archive to a public site. -- MJR/slef My Opinion Only and not of any group I know Creative copyleft computing - http://www.ttllp.co.uk/ LinuxExpo.org.uk village 6+7 Oct http://www.affs.org.uk
MJ Ray a écrit :
The commands I used to build the mirror are listed in the above blog entry.
That's not a mirror. That's your own local branch. You can do some work, commit it and tell me to merge it. You can branch it and generally moosh it about how you want. (One request: don't make more than one archive with the same name, else I may go nuts later.) Imagine having your own local CVS copy of koha that you have total admin control over. You can put more than one branch in each archive, too, which is what koha2--release2-0.2 will be.
Mirrors are created by the archive-mirror command, but I think they're not very interesting other than for distributing files around the world, or publishing a local archive to a public site.
I've begun reading the arch tutorial in french (nice language to read ;-) ) I've a question and this message reminds me it. You say : "You can do some work, commit it and tell me to merge it". iiuc the tutorial and your message, it means you can't have X developpers working on the same "branch". The release manager has to pick commits from various coders ? If i'm right, then don't you think it's a big task for the release manager ? I find nice to have "cvs update" to get all developpers code, and, with the help of the cvs-mailing list, see what has been commited. Isn't there a way to reproduce CVS behaviour for this : the commit is transmitted automatically to the release manager (& other local copies) -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
On 2004-09-23 14:06:18 +0100 Paul POULAIN <paul.poulain@free.fr> wrote:
If i'm right, then don't you think it's a big task for the release manager ?
No. I think it's an essential tool for the release manager, to know what has finally gone into the release. This was part of the motive for taking 2.0 out of CVS to stabilise it.
I find nice to have "cvs update" to get all developpers code, and, with the help of the cvs-mailing list, see what has been commited. Isn't there a way to reproduce CVS behaviour for this : the commit is transmitted automatically to the release manager (& other local copies)
You can have logs emailed to a list and you can have an archive that automatically merges selected developer's work. I think this is an automatic approximation to the "Linus and lieutenants" way of working that used to be used for the kernel. Good for development, but maybe not so good for stabilisation. -- MJR/slef My Opinion Only and not of any group I know Creative copyleft computing - http://www.ttllp.co.uk/ LinuxExpo.org.uk village 6+7 Oct http://www.affs.org.uk
MJ Ray a écrit :
On 2004-09-23 14:06:18 +0100 Paul POULAIN <paul.poulain@free.fr> wrote:
If i'm right, then don't you think it's a big task for the release manager ?
No. I think it's an essential tool for the release manager, to know what has finally gone into the release. This was part of the motive for taking 2.0 out of CVS to stabilise it.
I find nice to have "cvs update" to get all developpers code, and, with the help of the cvs-mailing list, see what has been commited. Isn't there a way to reproduce CVS behaviour for this : the commit is transmitted automatically to the release manager (& other local copies)
You can have logs emailed to a list and you can have an archive that automatically merges selected developer's work. I think this is an automatic approximation to the "Linus and lieutenants" way of working that used to be used for the kernel. Good for development, but maybe not so good for stabilisation.
100% right. you will convince me if you continue with such args ;-) (PS : chris is linus, i may be alan cox, and you ? 8-D ) -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
On Thu, Sep 23, 2004 at 01:54:42PM +0100, MJ Ray wrote: > That's not a mirror. That's your own local branch. You can do some > work, commit it and tell me to merge it. You can branch it and > > Mirrors are created by the archive-mirror command, but I think they're > not very interesting other than for distributing files around the > world, or publishing a local archive to a public site. Well ... I did use that command (it's farther down in the blog entry): [jmf@frodo koha20]$ tla make-archive --listing --mirror jmf@kados.org--koha20 sftp://kados.org/build/websites/kados.org/html/arches/ jmf@kados.org's password: [jmf@frodo koha20]$ tla archive-mirror jmf@kados.org's password: * mirroring jmf@kados.org--koha20 to jmf@kados.org--koha20-MIRROR with limit (null) ** adding category koha ** adding branch koha--release2 ** adding version koha--release2--0.1 ** adding revision koha--release2--0.1--base-0 So does this mean that I can't merge back into the main branch ... that you have do do that? In CVS anyone with devel privs could commit to the main repo ... or am I mising something? Joshua
On 2004-09-23 14:18:59 +0100 Joshua Ferraro <jmf@kados.org> wrote:
Well ... I did use that command (it's farther down in the blog entry):
Well, that will teach me. jmf@kados.org--koha20 is your local archive, which is what I was rambling about. jmf@kados.org--koha20-MIRROR is a mirror of it, seen on kados.org, which seems to be exactly as it should be. You won't use it yourself, but I can view it: ; tla register-archive jmf@kados.org--koha20 http://kados.org/arches/ ; cd /tmp ; tla get jmf@kados.org--koha20/koha--release2--0.1 * from archive cached: jmf@kados.org--koha20/koha--release2--0.1--base-0 [big download, so aborted] Fortunately, a simple merge doesn't need me to do a remote get: ; tla get mjr@dsl.pipex.com--koha20/koha--release2--0.1 * from archive cached: mjr@dsl.pipex.com--koha20/koha--release2--0.1--patch-6 * patching for revision: mjr@dsl.pipex.com--koha20/koha--release2--0.1--patch-7 * making pristine copy * tree version set mjr@dsl.pipex.com--koha20/koha--release2--0.1 ; cd koha--release2--0.1--patch-7/ ; tla replay jmf@kados.org--koha20/koha--release2--0.1 * patching for revision jmf@kados.org--koha20/koha--release2--0.1--base-0 A {arch}/koha/koha--release2/koha--release2--0.1/jmf@kados.org--koha20/patch-log/base-0
So does this mean that I can't merge back into the main branch ... that you have do do that? In CVS anyone with devel privs could commit to the main repo ... or am I mising something?
Either the RM or their automaton will need to do the merge. This is a deliberate model change from CVS which both allows more people to do more development tasks without waiting for approval, and allows the RM to say "show me the code" before accepting it into the final release tree, if they want. -- MJR/slef My Opinion Only and not of any group I know Creative copyleft computing - http://www.ttllp.co.uk/ LinuxExpo.org.uk village 6+7 Oct http://www.affs.org.uk
I've been thinking about the best format for storing the Koha documentation, and I've got some ideas I'd like to share. It seems to me that the best way to store Koha documents is as a set of XML source trees. All of these could be pulled together into one XML document that uses entity references to grab them. We could then use a variety of tools to process the XML and create finished documents in many formats and many languages. Since gathering content is the biggest problem in documenting Koha, it also seems to me that we do not want to require that people submit their documents in XML. Instead, I think we should accept documents in any format (well, practically any format), which would then be converted by the documentation manager to XML source trees. For example, I currently link to several documents from the skemotah.com website. I can take these documents and convert them to XML, storing each as a separate XML source tree. Then I could reference each of these XML files as an entity from a "master" XML source tree that pulls all of the the documents together. This master XML file could be processed with XSL or CSS or some other tool and converted to HTML or Docbook or pdf or whatever. The processing tool could even select only those elements that contain German text, or French text, etc. Or only those elements of interest to librarians, or OPAC users, etc. Keeping the documentation up to date then would involve modifying the individual XML documents to include new information, or modifying the master XML source tree to add new entity references to new XML documents. Any comments? Any ideas about the best way to store these files? BTW, I have almost no experience with XML. Please feel free to correct anything you see above that is not right. -- Stephen Hedges Skemotah Solutions, USA www.skemotah.com -- shedges@skemotah.com
Responding to Stephen Hedges <shedges@skemotah.com>:
It seems to me that the best way to store Koha documents is as a set of XML source trees. All of these could be pulled together into one XML document that uses entity references to grab them. We could then use a variety of tools to process the XML and create finished documents in many formats and many languages.
Sounds good.
Since gathering content is the biggest problem in documenting Koha, it also seems to me that we do not want to require that people submit their documents in XML. Instead, I think we should accept documents in any format (well, practically any format), which would then be converted by the documentation manager to XML source trees.
I actually have a pair of GPLd wiki tools (one java, one usually the older wiki2xml tool) I've been using to make the conversions easier, but have had no place to host them for production/general use. These let someone input standard wiki text, and offer a "button" for XML (instead of HTML) output. Neither is perfect, but either offer a serious improvment over hand tagging. The material I've converted so far has largely been done with the simpler of the two of them.
For example, I currently link to several documents from the skemotah.com website. I can take these documents and convert them to XML, storing each as a separate XML source tree. Then I could reference each of these XML files as an entity from a "master" XML source tree that pulls all of the the documents together. This master XML file could be processed with XSL or CSS or some other tool and converted to HTML or Docbook or pdf or whatever. The processing tool could even select only those elements that contain German text, or French text, etc. Or only those elements of interest to librarians, or OPAC users, etc.
Several of the things hosted at archive I've already converted to the Docbook XML flavor. [note to self, get ahold of Mike Reavey, who has this material at his site...!]
Keeping the documentation up to date then would involve modifying the individual XML documents to include new information, or modifying the master XML source tree to add new entity references to new XML documents.
Incidentally, one service that we've always missed, but was never sure how to accomplish (short of subjecting even more people to CVS a la sourceforge, which is a little dicey IMO) was some sort of update notice for those willing to translate docs. Similar to the CVS notifier, I guess, informing them that changes (with perhaps a severity indication...?) were made to the original/English versions. Something automated would eliminate the sometimes-iffy reliance on memory to notify the various int'l groups of important changes. As far as the storage question goes, there are a few ways to address this. One is the XMl-backended wiki (unfortunately this tool has a quirk or two, but is the best I've stumbled across so far.... I await with interest more news re neodoc from Paul). There is also a mandrake-related webtool called Borges, but I've only ever seen a "mock up" install... Kartouche (sp?) has also been kicked around as a possibility [I seem to have mislaid the link to that, but I recall MJ Ray mentioning it]. Nick
participants (5)
-
Joshua Ferraro -
MJ Ray -
Nicholas Rosasco -
Paul POULAIN -
Stephen Hedges