* Sebastian Pipping <sp...@gentoo.org> schrieb: Hi,
> interesting concept. i'd like to comment on a few details: > > - licensing seems not be addressed, yet. > licensing can kill everything, it needs consideration. what problems do you see w/ licensing ? IMHO, each branch simply has to follow the upstream's license. > - branch and tag namespaces as currently defined have a few problems: > > - versioning: > > - the A.B.C.D scheme won't be fun to gentoo, both > due to no-letters-in-here and because of no-pre-releases. > while at that keeping pre-releases does not seem helpful to me. simply normalize: don't use letters but numbers. and I actually don't see any need for pre-releases: a) it' an real release - then it has to fit into the (linear) versioning scheme b) it's not really a release but just a development snapshot - that doesnt belong into the main oss-qm repository > - vendor concept: > > - uppercase vendor names look rather odd, especially with project > names in lowercase. > > - having the vendor first makes no sense to me. > a "package.vendor.subbranch" keeps all zlibs together, > instead of all gentoo stuff. if the project is about > packages, that makes more sense to me. 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, ... > - renaming the concept to "downstream" would make it > fit better. gentoo is not a vendor to me. 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. > - with one git repo used for many packages people > will need to know how to clone single branches only. > most git users probably won't, you will need to teach them. > the PDF seems a good place to do that. 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. 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) 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 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/ ---------------------------------------------------------------------
