public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Enrico Weigelt <weigelt@metux.de>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] paper on oss-qm project
Date: Sat, 8 May 2010 22:11:42 +0200	[thread overview]
Message-ID: <20100508201141.GA23216@nibiru.local> (raw)
In-Reply-To: <4BDF18C3.1070507@gentoo.org>

* Sebastian Pipping <sping@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/
---------------------------------------------------------------------



  reply	other threads:[~2010-05-08 20:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-02 22:32 [gentoo-dev] paper on oss-qm project Enrico Weigelt
2010-05-03 18:41 ` Sebastian Pipping
2010-05-08 20:11   ` Enrico Weigelt [this message]
2010-05-09  6:03     ` Sebastian Pipping
2010-05-17  2:19       ` Enrico Weigelt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100508201141.GA23216@nibiru.local \
    --to=weigelt@metux.de \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox