Just a couple of notes as I've been been a bit frustrated with the way that merge queues are used in OI. I've got nothing against merge queues, it just seems that the source should be offered with merges already done. OI source should be accessible in the repos for cloning or browsing without requiring someone to merge. That's not to say that the patches shouldn't also be just as accessible, as well as the upstream source. It doesn't seem auspicious to me that the top of the OI builds docs contain a pointer to a page on using MQ. What I'd prefer to see is a source namespace that looks like:
hg.openindiana.org\
upstream\
illumos-gate\
onnv_147\
[etc.]
userland-gate\
build-165\
[etc.]
[etc.]
oi\
illumos-gate\
oi_147\
[etc.]
userland-gate\
oi_147\
[etc.]
mq\
illumos-gate\
onnv_147-oi_147\
[etc.]
userland-gate\
build-165-oi_147\
[etc.]
If people want to see what's in OI or pull OI source, there it is. OI releases
under active development may be a separate case that require people to pull
merge queues. I've also been thinking about how to maintain patches for CVE
audits/incident response going forward. What I'd suggest, building on the
previous suggestion is just to have a second series of merge queue that goes on
top of an OI release and is regularly merged into the release, so that it can
remain private. Thus:
sec_mq\
illumos-gate\
oi_147\
[etc]
userland-gate\
oi_146
[etc.]
I'll admit some of this is just plain branding: OI, as source should be able to
be somewhat self-referential. If people want to understand how it works back
upstream, fine, but the current system comes across to me as a bit baroque. I'm
sure I don't entirely appreciate the reasoning of the current system, but
hopefully your responses will get me there.
Cheers,
Bayard
smime.p7s
Description: S/MIME cryptographic signature
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
