On 04.01.2015 06:45, Franco Lanza wrote: > The idea is to have that for release branches but not for master so we > can easily integrate new upstream releases,
rebase. > considering not all sources are on an (external) git repo and we cannot > just merge changes on every new upstream release Just set up an mirror for those. Assign such issues to me - I'm going to set up a similar infrastructure for some customer anyways. > Yes, but it make harder to follow upstream new releases in future, as it > sounds like "a fork for every package" that needs to be rebased at any > upstream release No, it's not really a fork, but a downstream branch. And, in fact, we already have that since decades - just w/o calling it so, and using different tools (tarball+patches instead of a vcs). > Well, this was just for convenience, but another way can be used as long > as it's standardized to manage externally hosted upstream source and > doesn't make harder to maintain packages in sync with upstream We could simply put them into some file storage (http, ftp, ...) and sync them via rsync etc. But still, I'm not convinced at all on tarballs. Instead I'd set up an automatic vcs mirror/import infrastructure. Already did that about a decade ago (called the OSS-QM project - maybe some old maillist archives still have some bits about it ;-)). It's not a big deal. 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
