Re: ct-ng -> git repos instead of single patches

[Enrico Weigelt <weigelt at metux dot de>]

* Allan Clark <allanc@chickenandporn.com> wrote:

> "Q" and "M" stand for "Quick" and "Massive", or is there a definition
> such as "OSS-QM stands for ..." missing?

*rofl*

Of course, it's about quality management ... but yes, most of the
stuff isn't really documented yet (still gathered around on bunches
of paper pieces on my desk ;-o).

> It's a very, very old idea.  It actually seems you checked around
> first, but maybe you generated the same pattern by simply putting
> "most significant" on the left, and "least significant" on the right.

Right. I wasn't aware of that, just did it intuitively ;-)

> > Well, the vendor name has to be globally unique by definition,
> 
> ... which is perhaps why Java uses a FQDN.

Yes, but in java world there are way more vendors and names 
than in oss-qm. It's completely different world.

But: yes, we could also fqdns, but with the drawbacks that:

a) vendor names (and so all refs) get much longer
b) the naming scheme has to be changed to support dots in vendor names.

When defining the naming scheme, I played around with slashes as
delimiters, but that tended to confuse git (in it's own namespacing)
Maybe we could use some other character ?
 
> "UPSTREAM" may have two hops -- UPSTREAM-1 and UPSTREAM-2 ?

Just technically (eg. when the real upstream's scm first has to be
mirrored into git). The generic rule for UPSTREAM.* is:

a) if upstream has git: directly use that (just set appropriate tags)
b) if upstream has some other scm: set up an (ro) mirror to git first, 
   and then handle it like a)
c) if upstream only has tarballs: unpack the tarballs (one by one)
   and maybe remove autogenerated files (eg. ./configure scripts
   created by autoconf)

Feel free to propose a better solution ;-)

> > Where do a dates appear there ?
> > Version numbers are natually very different from dates, and
> > using dates as versions is generally not a good idea.
> 
> I'm aware of a difference between dates and versions.
> 
> ":)" indicates a bit of a joke.

Okay, perhaps I was a bit too much in a hurry to read carefully ;-)
 
But a little clarification to version numbers:

They really should be normalized as described in the paper (eg. higher
number _always_ has to indicate a newer version)
 
> To address your response, a date is a sequential number that can be
> generated.  Versions are arbitrary numbers.  The conflicts occur when:
> 1) two releases occur on the same quantum of date
> 2) the date implies stale-ness, and triggers attempts to update

Right. The conflicts can get really ugly when coping with different 
branches ;-p

BTW: a version number also contains some more information than just
a sequence of releases, eg. increased major implies some bigger
things happened (maybe even semantic changes), where minor or 
patchlevel increase just indicates small changes, eg. bugfixes.
Of course that's a big vague and project specific.

And of course, version numbers are assigned within the release
management process. Sometimes even before the actual code has
been written (eg. if the release manager specifies what the next
release, as a product, has to have, and then the development 
resources are allocated to actually produce that defined product).
This all heavily depends on the actual workflows.


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

--
For unsubscribe information see http://sourceware.org/lists.html#faq