SELinux RPM scriplet issue annoucement

Adam Williamson awilliam at redhat.com
Wed Jan 22 20:54:08 UTC 2014


On Wed, 2014-01-22 at 21:25 +0100, drago01 wrote:
> On Wed, Jan 22, 2014 at 8:55 PM, Adam Williamson <awilliam at redhat.com> wrote:
> > On Wed, 2014-01-22 at 10:36 -0700, Kevin Fenzi wrote:
> >> On Tue, 21 Jan 2014 12:43:47 -0700
> >> Luke Macken <lmacken at redhat.com> wrote:
> >>
> >> > Unfortunately, bodhi has not had dedicated full-time development
> >> > resources in a long time. Thankfully, I now have the cycles to put
> >> > into new features, such as improving the feedback mechanisms.
> >> >
> >> > Many components of the "Bodhi 2.0" vision are long-term, and rely on a
> >> > plethora of other pieces to fall into place, such as
> >> > python-fedora+fas-openid, koji+mash, taskotron, depcheck-mk-2, and so
> >> > on. Other pieces of the puzzle can be implemented and deployed
> >> > incrementally within the current tools now.
> >> >
> >> > My focus lately has been around the releng/infra side of the updates
> >> > process, but for a feature that would make things 'immeasurably
> >> > better' (even though I think it would actually be measurable :P), I'd
> >> > be happy to shift gears to the QA/frontend side of things to help get
> >> > it done sooner rather than later.
> >> >
> >> > As far as I can tell, you sent some ideas to a mailing list a few
> >> > years ago about it, and then Mathieu started a prototype. I can't
> >> > find any RFEs filed for it, so I'll create one and see what I can do
> >> > about getting the existing prototype polished and integrated for
> >> > testing.
> >>
> >> It would be absolutely lovely to get a bodhi-dev instance up on a cloud
> >> node running bodhi2 so we could see where we were and what needed to be
> >> worked on.
> >>
> >> Perhaps we could get interested folks together in irc sometime soon and
> >> discuss plans/status?
> >
> > I'd certainly be up for that.
> >
> > The thing I think would be most useful is just a lot more flexibility
> > over the karma definition: ideally the back end should be extremely
> > generic, a sort of set of possible conditions you can glue together any
> > way you like, and we'd provide some common 'templates' for use in
> > updates (and sensible defaults, of course). The Glorious Vision email
> > still pretty much holds true, I believe, if you can still find it (yell
> > if you can't, and I will).
> >
> 
> While at it ... can it be less paranoid about who can edit updates please?
> It is overly restrictive for no real reason.

Yeah, that's a real problem for teams working on multi-package updates,
it seems.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net



More information about the devel mailing list