On 03.01.2015 09:19, Franco Lanza wrote:

> Devuan have a workflow driven by the autobuild infrastructure based
> on gitlab + jenkins + dak

Ok, sounds good.

> and for external hosted sources the devuan gitlab project
> will have just the debian directory and a devuan specific script similar
> to the "watch" script used in debian.

I'd strongly suggest NOT doing it that way, but instead have a full
clone of the upstream repo (at least the relevant branches), and
directly apply our local changes (including the ./debian/ directory)
ontop of that.

The idea behind is _not_ having any additional logic for applying the
our local changes (eg. patch queues, etc) anymore, but instead having
the complete tree in our git repo. IMHO, this makes maintanance
_much_ easier and gives us independence from upstream sites.

Yes, it requires more storage space, but storage is pretty cheap.
And we dont need to have _full_ clones, just the relevant branches/tags,
even just the recent part of the history (aka shallow clones)

We can easily mirror everything to github (having an own organization
and an normalized repo namespace within that).

> 3- devuan version numbering or codenames

Release versions should be properly tagged (stable releases w/ signed
tags), of course.

> When branching for packaging external source hosted packages, a tarball
> of the specific version has to be built will be copied on the gitlab
> repo to permit package reproducibility.

Tarballs in git repos are not a good idea ...


cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287