g-wrap-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ripping out GLib bindings, depending on GLib


From: Andreas Rottmann
Subject: Re: Ripping out GLib bindings, depending on GLib
Date: Fri, 16 Jan 2004 22:20:25 +0100
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Rob Browning <address@hidden> writes:

> Last night, after realizing that switching to 1.4.0 for the next
> stable release would address my one last issue with the initial arch
> layout, I've finished setting up an arch g-wrap archive.  Though I
> still haven't used arch enough to know that I'll want to stick with
> it, I'd like to just get started and see how it goes.
>
OK.

> Right now, in my local archive, address@hidden, we have:
>
>   $ tla abrowse
>   address@hidden
>     g-wrap
>       g-wrap--main
>         g-wrap--main--1.4
>           base-0
>
>       g-wrap--main-dev
>         g-wrap--main-dev--0
>           base-0
>
> The base-0 revisions are both just the 1.3.4 source with a few minor
> (arch-related) modifications.
>
I hope you branched main--1.4 from main-dev--0...

> g-wrap--main--1.4 is for stable work, and g-wrap--main-dev--0 is for
> development work.  when we're ready for the 1.4.0 release, I'll tag it
> on a new g-wrap--main-release--1.4 tag branch.
>
> When we're ready for the 1.6 release (or 2.0 if that's what we want),
> I'll branch it as g-wrap--main--1.6 and then when we're ready, tag it
> as g-wrap--main-release--1.6.
>
Looks fine.

> I went ahead and adjusted =tagging-methods to allow .cvsignore files
> to be source (see below), and set "tla id-tagging-method tagline".  I
> also added arch-tag:'s to all the files where I felt it was
> reasonable.  This excluded many of the debian/* files, and files like
> AUTHORS and COPYING.LIB.  Those I gave IDs via "tla tag -i
> $(uuidgen)".  Note that this means we'll have to be careful to
> manually move the tags via "tla mv" for those particular files, though
> most of them are very unlikely to need to be moved.  You can tell
> which files will require an explicit "tla mv" by looking at "tla
> inventory --ids" and see if the id starts with "x_".  All of them are
> using uuidgen ids.
>
OK.

> My current plan is to keep savannah CVS around, but try having it be
> read-only, and only follow g-wrap--main-dev via sync from the main
> arch tree -- hence the .cvsignore files in the arch repo.
>
I follow the following policy: Make .cvsignore files an exception
(i.e. allow writes) and keep them out of the arch repo. Having them in
the arch repo doesn't hurt, though.

> I also tried to figure out a way to immediately provide my g-wrap arch
> archive via our file area on savannah, but was unable to get savannah
> to let me upload anything via sftp or rsync.  From the looks of the
> news on savannah, there may be some problem ATM.  As soon as that's
> cleared up, I'll like to try again.
>
Hmm, is there even supposed to be a way to upload using rsync/sftp? I
haven't seen any docs about that. The "Download areas" news item seems
to point out you can only upload single files (via anonymous FTP + GPG
signature, like the Debian anonftp upload queues). I think we would be
better off without depending on savannah (i.e. you putting the archive
somewhere you like). Except for requiring re-registration, moving an
archive is not a problem, AFAIK, so we can switch to savannah once it
supports sftp.

Cheers, Andy
-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Any technology not indistinguishable from magic is insufficiently advanced.
   -- Terry Pratchett




reply via email to

[Prev in Thread] Current Thread [Next in Thread]