From: Thien-Thi Nguyen <ttn@gnuvola.org>
To: guile-devel@gnu.org
Subject: Re: The Big Switch to Git
Date: Thu, 27 Mar 2008 15:07:52 +0100 [thread overview]
Message-ID: <87r6dwjm4n.fsf@ambire.localdomain> (raw)
In-Reply-To: 87bq53lnlk.fsf@ossau.uklinux.net
() Neil Jerram <neil@ossau.uklinux.net>
() Mon, 24 Mar 2008 23:16:23 +0000
> It would be nice to have workbook and guile-scripts as peers of
> guile-core, since that forms the minimal set to reproduce "cvs
> checkout hack" of yore. (Basically, the cvs-module "hack"
> included only those three cvs-modules.)
I'm not aware that this "hack" collection has been doing anything for
us recently. At least, it's true that guile-core does not currently
depend on workbook, as it did once.
It's only value would be for history browsing. Granted, that history is
shallow; interest quickly moved away from the non-guile-core cvs modules.
I'm sure there is stuff in workbook and guile-scripts that is still
useful, but I prefer to import it lazily (and as and when it becomes a
priority). That will also allow us to consider where each imported
item should go within the Git repository.
I urge you to reconsider. It's no big deal to import them and leave them be
(for historians). You can even make them read-only.
Wouldn't it make sense for guile-www to be a separate Savannah
project?
Yes. If Guile maintainers don't mind, i can pursue that angle. More
precisely, i would create a Guile-WWW project on Savannah (w/ myself its
sole administrator), make a Git repo available, shutdown the gnuvola
guile-www Git repo, and post an announcement to the guile-user list.
In case this sounds like I'm singling out guile-www, I've actually
always had a problem understanding the structure and existence of the
Guile CVS modules other than guile-core - and I think the fact that
many of them are obsolete and/or bitrotted is a clue that this is a
problem in practice.
Yes, there's a lot of hoarding of lost bits, there. However, i think
singling out Guile-WWW is fine; it has undergone continued development,
whereas the others have not.
thi
next prev parent reply other threads:[~2008-03-27 14:07 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-14 16:23 The Big Switch to Git Ludovic Courtès
2008-03-14 18:38 ` Greg Troxel
2008-03-15 21:30 ` Ludovic Courtès
2008-03-16 20:57 ` Thien-Thi Nguyen
2008-03-24 23:16 ` Neil Jerram
2008-03-27 14:07 ` Thien-Thi Nguyen [this message]
2008-03-27 14:28 ` Han-Wen Nienhuys
2008-03-27 14:45 ` Thien-Thi Nguyen
2008-03-28 4:33 ` Han-Wen Nienhuys
2008-03-28 7:39 ` Thien-Thi Nguyen
2008-03-28 16:11 ` Han-Wen Nienhuys
2008-03-28 8:10 ` Ludovic Courtès
2008-03-28 16:14 ` Han-Wen Nienhuys
2008-03-15 16:22 ` Thien-Thi Nguyen
2008-03-22 0:41 ` Han-Wen Nienhuys
2008-03-26 22:36 ` Ludovic Courtès
2008-03-24 22:56 ` Neil Jerram
2008-03-26 10:06 ` Ludovic Courtès
2008-03-26 18:47 ` Neil Jerram
2008-03-26 22:31 ` Ludovic Courtès
2008-03-27 20:22 ` Ludovic Courtès
2008-03-27 22:16 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r6dwjm4n.fsf@ambire.localdomain \
--to=ttn@gnuvola.org \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).