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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
