[pkg-s48-maint] list to do

Lionel Elie Mamane lionel@mamane.lu
Fri May 20 17:41:17 2005

Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, May 20, 2005 at 03:29:03PM +0200, Jorgen Schaefer wrote:

> Sorry for the long delay in the response, I got sidetracked by "real
> life" issues.

No problem.

> Lionel Elie Mamane <lionel@mamane.lu> writes:

>>> We wanted to use tla or darcs for the version control. At the
>>> moment, I use dpatch for the Scheme 48 package, and I wonder why
>>> we (I) should use a more elaborate setup at all - I never used a
>>> revision control system for my packages yet,

>> And you tell me that *now*? Couldn't you have mentioned this *before*
>> we started discussing which VC system we would use and how?

> I hope that was not meant as annoyed as it sounds,

It sounds far too annoyed, yes. And on top of that, I've significantly
cooled down since then.

> I definitively wanted to use a VC for the packages, but never got
> around to do it. I should have done so earlier.

> My current (local) Scheme 48 package uses darcs-buildpackage. It's
> quite ok to use and work with. dpb-importorig does most of the
> annoying work, the rest is just creating the debian repository and
> working on that one. I used a separate branch to pull my patches to,
> and darcs-buildpackage built the packages quite well. So that works
> here, and I'm quite happy about that.

I understand that you *are* using darcs for the package now? Or is it
somehow possible to use darcs-buildpackage, but not darcs?

(Now working under the assumption you are using darcs for the rest of
 the email.)

The web space of the project sits in

I have created a "darcs" directory there. Shall we put the common
darcs repository there? It will then be publicly accessible
(read-only) at http://pkg-scheme48.alioth.debian.org/darcs/ . I'll let
you create it, and populate it with the s48 package.

Should we use one repository per package or one repository total? One
repository total seems to be what the other similar projects are
doing, so I'd go along with that, unless darcs creates specific
problems in this situation. Is it possible in darcs to push/pull only
patches affecting a subtree of a repository? (Probably not, because a
patch may affect both the subtree and the rest?) Hmm... One repo per
package starts to sound good, but then we loose handling and tracking
of inter-package "synchronised" changes... :-| What do you think?

Please take care of creating files and directories with mode 775, so
that we can both work with the repository. (Setting umask to 002
before doing it should ensure this.)

Do we need to have darcs installed on alioth.d.o for this to work? I
presume so. Alas, alioth has moved from costa to haydn, and while
costa has darcs, haydn doesn't; bummer, I wanted to get all this
started this week-end. :-(

Maybe we can use a directory in my home on costa in the meantime, and
move to haydn later? I've created costa:~lmamane/pkg-scheme48/ for
this purpose.

> I don't want to enforce my preferences on revision control tools on
> you.

I definitely think we should have a common repository, so that (for
example), if you do an upload while I'm away, you put into the upload
the "pending small changes not worth a separate upload" I may have. Or
if "synchronised changes" are necessary, we can prepare them in the
repository. Etc.

> If you want to use darcs and have any questions, please let me know.

I'll look a bit at the darcs documentation, and go from there. Once
you have created the repository, I'll add my scsh and scsh-install-lib
packages to it.

> Naming conventions:
> - Libraries:
>   lib<package>-s48
>   lib<package>-scsh-0.6
> - Other programs:
>   Upstream name, no specific mentioning of what it is "written in"

> - If it's too generic (install-lib), add scsh/s48 prefix:
>   scsh-install-lib
> - For scsh, add the version:
>   libsunterlib-scsh-0.6

> Does that sum it up well?




Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

Version: GnuPG v1.2.5 (GNU/Linux)