Re: Using CVS for package development
> Communication should be done via a package-specific mailing list. The
> maintainer of the package decides who has commit privileges for this
> package and who gets on this package's developers' mailing-list.
>
> This mailing list could be used as target for the bug reports against
> this package.
>
> Regarding stability: We will need at least two branches: for stable
> and for unstable. When some people cooperate on porting to a specific
> architecture and this port does not work yet, they could create an
> extra branch. (Usually this won't be necessary.)
This discussion is making me feel guilty. I hinted a while back that I would
Debianize aegis, and have not got round to it.
To quote an earlier mail from me:
------------
There is a CASE tool called Aegis that would seem to fit into this scheme
quite well.
ftp://ftp.agso.gov.au/pub/Aegis/aegis.2.3.README
As I understand it, this would sit happily on top of CVS (or perhaps do what
CVS does), and also take care of asking for the test team(s) approval of each
change, and automatically building the system and running automated regression
tests against the built system.
The aim of Aegis is to maintain a baseline source tree that always passes it's
own tests, and so can be expected to work. It does this by seeking approval
of each change from a tester, and attempting to satisfy itself of the validity
of the change by building the system with the change applied and ensuring that
it passes any tests that exist.
If we could actually put up with the (not very large) overhead involved, I
think it would end up giving us a massive improvement in reliability.
If some of the CVS gurus could have a look at the Aegis docs and see how they
think it measures up --- I'll debianize it if it looks worthwhile.
----------
One reason I didn't rush to do anything about this was that I couldn't see a
worthwhile way of doing it without setting up a CVS server, and I don't have
the bandwidth.
Now that it looks like you are trying for at least a partial CVS and ``make
world'' system, Aegis might be more viable. If we could implement an Aegis
based system, even if only for the base packages, then a fair amount of
automated testing would become a possibility.
An alternative use might be to unpack _all_ the source for packages that go
into a release, and put it into CVS or aegis, and allow bug fixes to stable
only via that source.
Cheers, Phil.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: