On Jun 07 14:44, Peter Robinson wrote: > On Tue, Jun 2, 2015 at 4:43 AM, Mike McLean <[email protected]> wrote: > > It's been eight years since koji 1.0. In that time Koji has grown a lot, but > > always incrementally and with great care to avoid breaking compatibility. > > Over the years, we've found numerous things that we wanted to add or change, > > but that we dismissed as too big, too complicated, or too invasive. > > > > Bumping the major release number gives use the freedom to shake things up a > > bit. Koji 2.0 is about making major changes, otherwise it would just be koji > > 1.13. > > > > Koji 2.0 will take some time. We will maintain Koji 1.x until 2.0 is > > sufficiently stable. Some features (e.g. content generators) will also > > appear in 1.x. > > > > The list below is probably not complete, it is ambitious, and it is > > certainly open to discussion. If you are a Koji user, or otherwise invested > > in Koji, then you are encouraged to join in. I expect there will be a lot to > > say, so I've created a new mailing list devoted specifically to Koji > > development. > > > > https://lists.fedorahosted.org/mailman/listinfo/koji-devel > > > > Also, apologies for the tense summary listing. I can certain expound on any > > of these as necessary. I hope this suffices to start some conversation. > > > > > > = High level goals = > > > > • better documentation > > • more community involvement > > • refactor/modernize code > > • more modular design > > ∘ content generators > > ∘ broader, better plugin framework > > • better support for different types of build processes > > • better support for for different types build output > > • make hard-wired restrictions more configurable > > • easier to deploy > > • better qa process > > • better release process > > > > > > = Highlights/Major changes = > > > > • python3 support > > ∘ the bulk of the code will target python 2.6 + python-six > > ∘ we'll create a basic client lib for older systems (e.g rhel5 > > clients/builders) > > • drop xmlrpc in favor a json based rpc > > • build namespaces > > ∘ allow for use cases that require multiple builds of the same NVR (or > > NVRA) > > • refactor task scheduling > > • extend content generator support > > ∘ content generators will land in 1.x fairly soon, but in 2.0 they will be > > more integral > > ∘ refactor kojid to use content generator calls > > ∘ (possibly) tighter integration in the db > > • unify handling of rpms with other build types in the db > > ∘ e.g. unify rpminfo and archiveinfo tables > > • support different ways of building (possibly via content generators) > > • utilize jsonb fields in postgres > > • modular auth > > ∘ make it easier to add new auth mechanisms > > ∘ support openid auth > > I'd like to add to this more granular access control, groups etc. It > would be great if every task could be assigned groups and each group > could be given things like Read, Execute, Execute scratch, Delete, Tag > etc style of ACLs.
+1 > > One of the requests we get on occasion is the ability for someone to > run image scratch builds, at the moment to do that you need to be > admin as there's no ability for non admin to do image builds, but we'd > likely want enough granularity to differentiate between scratch versus > official builds. Read/NoRead ACLs would nicely enable people doing builds of sources under embargo. > > Peter --Brian -- buildsys mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/buildsys
