[oi-dev] gates, queues

[Bayard Bell]

I'm bumping this, as part of the problem that needs sorting is where to manage security patches that need doing around 151. I had an agenda item for last week's meeting to discuss this.

Hopefully we'll be able to discuss this at today's meeting (which *is* happening? ;->).

On 18 May 2011, at 18:54, Bayard Bell wrote:

> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1515 bytes
Desc: not available
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20110524/a6618b62/attachment-0010.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 841 bytes
Desc: This is a digitally signed message part
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20110524/a6618b62/attachment-0011.bin>