| 1 |
* Sebastian Pipping <sping@g.o> schrieb: |
| 2 |
|
| 3 |
Hi, |
| 4 |
|
| 5 |
> interesting concept. i'd like to comment on a few details: |
| 6 |
> |
| 7 |
> - licensing seems not be addressed, yet. |
| 8 |
> licensing can kill everything, it needs consideration. |
| 9 |
|
| 10 |
what problems do you see w/ licensing ? |
| 11 |
|
| 12 |
IMHO, each branch simply has to follow the upstream's license. |
| 13 |
|
| 14 |
> - branch and tag namespaces as currently defined have a few problems: |
| 15 |
> |
| 16 |
> - versioning: |
| 17 |
> |
| 18 |
> - the A.B.C.D scheme won't be fun to gentoo, both |
| 19 |
> due to no-letters-in-here and because of no-pre-releases. |
| 20 |
> while at that keeping pre-releases does not seem helpful to me. |
| 21 |
|
| 22 |
simply normalize: don't use letters but numbers. and I actually don't |
| 23 |
see any need for pre-releases: |
| 24 |
|
| 25 |
a) it' an real release - then it has to fit into the (linear) |
| 26 |
versioning scheme |
| 27 |
b) it's not really a release but just a development snapshot - |
| 28 |
that doesnt belong into the main oss-qm repository |
| 29 |
|
| 30 |
> - vendor concept: |
| 31 |
> |
| 32 |
> - uppercase vendor names look rather odd, especially with project |
| 33 |
> names in lowercase. |
| 34 |
> |
| 35 |
> - having the vendor first makes no sense to me. |
| 36 |
> a "package.vendor.subbranch" keeps all zlibs together, |
| 37 |
> instead of all gentoo stuff. if the project is about |
| 38 |
> packages, that makes more sense to me. |
| 39 |
|
| 40 |
I've chosen that scheme to make the borders more clear (also for |
| 41 |
automatic filtering, etc). In my concept, the vendor is the major |
| 42 |
point of distinction, package comes at second, ... |
| 43 |
|
| 44 |
> - renaming the concept to "downstream" would make it |
| 45 |
> fit better. gentoo is not a vendor to me. |
| 46 |
|
| 47 |
Well, the term vendor here is defined as a party which provides |
| 48 |
packages in certain variants. "UPSTREAM" is a kind of meta vendor, |
| 49 |
describing the upstreams. "Vendor" is IMHO more generic, since there |
| 50 |
may be vendors who aren't actually a real distro. For example, I |
| 51 |
myself don't publish a complete distro, but a foundation for clean |
| 52 |
building especially for special embedded devices or appliances. |
| 53 |
|
| 54 |
> - with one git repo used for many packages people |
| 55 |
> will need to know how to clone single branches only. |
| 56 |
> most git users probably won't, you will need to teach them. |
| 57 |
> the PDF seems a good place to do that. |
| 58 |
|
| 59 |
Yes, that's still an open topic. I've chosen to use one big repo |
| 60 |
for easier maintenance, but I'm aware of the problem that the |
| 61 |
repo might become very fat some day. I see two options: |
| 62 |
|
| 63 |
a) split it off into several ones, eg. on per-package basis |
| 64 |
and create a system for (semi-)automatic mass-repo maintenance |
| 65 |
(not completely trivial when using free git hosters as mirrors) |
| 66 |
|
| 67 |
b) add an selective filtering system. AFIAK current stable git |
| 68 |
doesnt provide that yet - I've added an little patch for that: |
| 69 |
http://repo.or.cz/w/oss-qm-packages.git/shortlog/refs/heads/METUX.git.master |
| 70 |
|
| 71 |
|
| 72 |
cu |
| 73 |
-- |
| 74 |
--------------------------------------------------------------------- |
| 75 |
Enrico Weigelt == metux IT service - http://www.metux.de/ |
| 76 |
--------------------------------------------------------------------- |
| 77 |
Please visit the OpenSource QM Taskforce: |
| 78 |
http://wiki.metux.de/public/OpenSource_QM_Taskforce |
| 79 |
Patches / Fixes for a lot dozens of packages in dozens of versions: |
| 80 |
http://patches.metux.de/ |
| 81 |
--------------------------------------------------------------------- |
Archives