[pkg-s48-maint] sunterlib CVS access

[Anthony Carrico]

On Mon, Jun 27, 2005 at 08:55:44AM +0200, Lionel Elie Mamane wrote:
> On Mon, Jun 27, 2005 at 04:39:48AM +0200, Jorgen Schaefer wrote:
> 
> > I just had an interesting talk with acarrico, the current maintainer
> > of sunterlib. He missed the bug report you sent, as apparently, he
> > was not Cc'd as he thought he would be.
> 
> Maybe that's because you are "only" project admin and not "bug tracker
> techn. & manager". If you add yourself the "bug tracker technician"
> bit, you'll get email notification of bug reports - I think. Unless
> you have disabled it in your preferences or some such.

It looks like all members are already listed as "Techn. & Manager" for
Bug Tracker, including me, so that must not trigger notifications. In
the Administration "manage notifications" tab there is a box for a
"Global List", currently empty. I'll try putting my email address
there. There should be place for each member to choose notification of
new bugs, but I can't find one.

> > <acarrico> forcer: do you or Lionel have cvs access to Sunterlib?
> > > acarrico: Nope
> > <acarrico> Set yourself up at Savannah and request membership if you are
> >     interested.
> 
> Done. (Imagine there is here a plug for a better system than CVS: GNU
> Arch (tla / baz), darcs, ...)

I agree. I would like svn or darcs, but those aren't options at
Savannah.

> > > acarrico: Do you want the Debian modifications in sunterlib itself? I.e. a> >     debian/ subdirectory? Or what did you have in mind with giving us CVS
> >     access? :-)
> > <acarrico> I only had in mind that you can easily propagate bugs upstream if
> >     you have access. But also, It would be fine to put the Debian subdir in
> >     CVS (assuming it doesn't clash with other uses).
> > <acarrico> propagate --bug fixes-- not --bugs--!
> 
> Forcer and I actually use darcs repositories for our Scheme48 / Scsh
> packages. I'd like to continue doing so, but we can mirror our changes
> to Sunterlib's CVS repository.

> As for bug fixes, I understand that this is "social permission" to
> commit bug fixes we judge correct directly to HEAD without your
> review?

Yes. You may.

Sunterlib is a collection of libraries. In theory, each library is
added and maintained by its own authors. I happen to be the one that
setup the basic policy, designed the directory layout, and the system
to create releases, etc., but I don't claim know much about any
library in particular. In practice, authors may contribute their code
and abandon it, so I would say that any project member could and
should fix bugs in any library, but out of courtesy try to contact the
author about a major change.

> How will we handle differences between the Debian version and CVS
> HEAD? Examples of differences include backports of bug fixes to stable
> version (but not backports of new feature that are also in CVS HEAD),
> backports of security bugs to the version of sunterlib in Debian
> stable, etc. I see these possibilities:
> 
>  - We don't. Debian "branches" stay out of sunterlib CVS and "only" in
>    our darcs repositories. The Debian maintainers only commit their
>    "bleeding edge" work to sunterlib CVS.
> 
>  - We create many branches in the sunterlib CVS, and many managerial
>    tags to handle the merging between the branches.
> 
>    The list of branches would be something like DEBIAN_UNSTABLE,
>    DEBIAN_STABLE, DEBIAN_OLDSTABLE. Managerial tags would be at least
>    DEBIAN_UNSTABLE_to_HEAD_merge_point and
>    HEAD_to_DEBIAN_UNSTABLE_merge_point. (To use with the
>     cvs merge -j foo -j bar
>    command.)
> 
>    CVS branches are messy... I do with them if I have to, but their
>    messiness is one of the big reasons I try to move away from CVS :)

I agree that we should certainly avoid doing branches in CVS--keep
them in darcs, so the question becomes, which branch to propagate to
CVS? I think UNSTABLE or even bleeding edge is fine.

There is currently no guarantee or policy about stability of the code
in CVS, but obviously people would try not to check in broken code. In
practice there is no way for the person who does a release (me,
basically) to know if a library is broken.

A release usually goes as follows: generally, I get an email from
someone saying bug fixes or new libraries are ready. I review the
recent changes, and try to make sure that new libraries conform to
README.contrib. Then I follow the list in README.admin. Anytime there
is a policy or procedure change I am careful to put it README.contrib
or README.admin.

We don't currently have a policy for users. We don't say if and when
they can expect changes in the interfaces.

Let me know if you have more questions/comments.

-- 
Anthony Carrico
http://giftfile.org