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
smime.p7s
Description: S/MIME cryptographic signature
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ oi-dev mailing list [email protected] http://openindiana.org/mailman/listinfo/oi-dev
