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