[oi-dev] gates, queues

[Alasdair Lumsden]

Hi Bayard,

On 24 May 2011, at 17:00, Bayard Bell wrote:

> 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.

My apologies for taking quite some time to respond to this thread - it's quite a big topic with difficult questions and no easy answers.

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

And again my apologies for this not getting discussed at the meeting, there was quite a lot on the agenda. I've made this one of the main discussion points of the next meeting on the 31st here:

http://wiki.openindiana.org/oi/Developer+Meetings

> 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.

If we offer the source with the queue pre-applied, the existence of the patch queue is hidden and ergo those wanting to contribute may not be aware of it, which could be a concern. Ideally people working on the source trees should get used to the "hg qnew/qrefresh" workflow early on in the contribution process so changesets don't have to be reworked as patches.

>> 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.

But then again, this is a valid point! It would be useful for eyeballing the source quickly.

So I guess offering pre-applied source would be fine, as long as the documentation on how to contribute and develop the OS makes it clear that for now at least, we're maintaining patch queues. But hopefully not for too long, expect an email to the list about this soon.

>> It doesn't seem auspicious to me that the top of the OI builds docs contain a pointer to a page on using MQ.

The docs are I guess more geared up on the assumption people will make changes to the source and want to submit a changeset to the mq tree rather than the upstream source itself.

>> 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.]

Are the leaf nodes (eg oi_147) tags, branches or a full clone of the source tree?

We definitely need to tidy the mercurial tree and I like the split of upstream, oi and mq - that seems logical to me so +1

>> 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.]

A big +1 - this seems fine to me.

Again are the oi_14X leaf nodes branches/tags/something else?

>> 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.

Things were thrown together quickly without much planning, and few of us on the project have experience managing such a bizarre workflow where we're having to maintain/modify a fast moving upstream with our own improvements. It's not by design! :-)

Cheers,

Alasdair