SELinux RPM scriplet issue annoucement

drago01 drago01 at gmail.com
Wed Jan 22 20:25:05 UTC 2014


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.


More information about the devel mailing list