On Wed, 2014-01-22 at 21:25 +0100, drago01 wrote: > On Wed, Jan 22, 2014 at 8:55 PM, Adam Williamson <awilliam@xxxxxxxxxx> 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@xxxxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
