* Sebastian Pipping <sp...@gentoo.org> schrieb: Hi,
> > what problems do you see w/ licensing ? > > > > IMHO, each branch simply has to follow the upstream's license. > > i have yet to see easy cases with licensing. > i haven't thought about it in detail yet, tough, to be honest. well, let's just see if the first realworld case happens and then think about it ;-p > > simply normalize: don't use letters but numbers. > > i don't believe in simple normalization before i have seen it. well, the right normalization scheme always depends on the upstream's versioning scheme. most packages already have some consistent scheme, which can be mapped directly. the few really complicated cases (actually don't have any at the tip of my head right now) have to be done manually. remember that we only take stable releases, since we're in the dist maintainer role - not the upstream dev one (so, alpha's etc dont matter here) > > b) it's not really a release but just a development snapshot - > > that doesnt belong into the main oss-qm repository > > why doesn't it belong in there? because it's not ready to use. that's the primary distinction: snapshots are for devs (and maybe testers), not for production use. > > I've chosen that scheme to make the borders more clear (also for > > automatic filtering, etc). In my concept, the vendor is the major > > point of distinction, package comes at second, ... > > i guess we agree to disagree then. > i don't think the current scheme promotes cooperation well. why exactly ? BTW: if you dont like that scheme, you could add some filter for automatically rewrites the refnames ;-p > > Well, the term vendor here is defined as a party which provides > > packages in certain variants. "UPSTREAM" is a kind of meta vendor, > > describing the upstreams. "Vendor" is IMHO more generic, since there > > may be vendors who aren't actually a real distro. For example, I > > myself don't publish a complete distro, but a foundation for clean > > building especially for special embedded devices or appliances. > > yes, that's why i proposed "downstream" as a replacement. > you don't consider yourself downstream? *I* am downstream, right. But the "UPSTREAM"+* branches are what's coming from the upstream. Upstream's a special kind of (meta-)vendor, where everybody else (downstreams) forkes from. > > Yes, that's still an open topic. I've chosen to use one big repo > > for easier maintenance, but I'm aware of the problem that the > > repo might become very fat some day. > > my point is not about size, only about "users". In which way does my current approach make trouble here ? What would be the better approach ? > > I see two options: > > > > a) split it off into several ones, eg. on per-package basis > > and create a system for (semi-)automatic mass-repo maintenance > > (not completely trivial when using free git hosters as mirrors) > > are you aware that splitting it up will reduce the savings in space? > say if they all had byte-identical GPLv3 COPYING files that would be one > blob atm and N blobs in split mode. Right, that's the tradeoff here. But the few COPYING files shouldnt be the big issue ... > > b) add an selective filtering system. AFIAK current stable git > > doesnt provide that yet - I've added an little patch for that: > > > > http://repo.or.cz/w/oss-qm-packages.git/shortlog/refs/heads/METUX.git.master > > while i'm not sure about this in detail yet, could it be this loop > misses to filter the very first entry? > > + while (walk && (walk->next)) > + { > + if (_filter_remote_ref(transport, walk->next)) > + walk->next = walk->next->next; > + else > + walk = walk->next; > + } > + you missed the previous lines ;-P + while ((transport->remote_refs) && (_filter_remote_ref(transport, transport->remote_refs))) + transport->remote_refs = transport->remote_refs->next; + cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------
