[Rpm-maint] RPM 4.9 Release Timeline?

[Panu Matilainen]

On Wed, 6 Oct 2010, Ware, Ryan R wrote:

> On 10/5/10 11:09 PM, "Panu Matilainen" <pmatilai at laiskiainen.org> wrote:
>
>> On Tue, 5 Oct 2010, Ware, Ryan R wrote:
>>
>>> Hello Everyone,
>>
>> Hi,
>>
>>> New here.  Looking through the RPM mail archives and web site, I wasn't
>>> able
>>> to find the answer to the question on my mind.
>>
>> Oops, we even have the 4.8.0 roadmap still open despite having been
>> released many, many moons ago, never mind any new information... :-/ Will
>> fix.
>
> Yeah, I knew what I saw there wasn't up to date.  Sometimes time for
> documentation just doesn't happen.
>
>>
>>> I'm trying to find out what the release timeline is for 4.9.  For the
>>> Mobile Simplified Security Framework (MSSF) that we want to release in
>>> MeeGo 1.2, we would like to utilize the plugin functionality that was
>>> created for SELinux.  We'd really rather not backport the changes to
>>> 4.8.1.
>>>
>>> Any rough timeframe would be helpful.
>>
>> The idea is to a beta out in November and final in December / early
>> January, depending on how things go with the beta. So fairly soon in any
>> case.
>
> That might be a little late depending on what we're looking for.  If I
> might ask, what's driving this timeline?  Is it a resource issue?
> Alignment target with other projects?  Something else I'm completely
> ignorant of?

Mostly just "the fastest schedule I think we can manage to pull off."

The current development cycle has gone on longer and drifted further out 
than I'd like, and because of that there's a fair amount of finishing off 
work-in-progress API's and features work to do before we can make a 
release.

It's not entirely unlike having overslept and then scrambling to get to 
work as fast as you can to minimize the damage :) Calling it bad planning 
and release management is also applicable...

>> Note however that the collections/plugins system has some open
>> questions/issues still and WILL change to some extent, and unless those
>> odds and ends get sorted out before the beta (which is of course what we
>> want, but time's getting a bit short), it'll be marked experimental in
>> the
>> next release to allow room to make those changes in the nearish future.
>> So
>> you'll want to proceed cautiously when planning / building something
>> fundamentally important on top of it right now.
>
> If there is anything we can do from the MeeGo side of things to help get
> some of those odds and ends sorted out for you, please let me know.  I
> understand that having a plugin infrastructure is a totally new thing for
> RPM and it's going to be an exercise in feeling out how things go for a
> while and that things will change as we go forward.

Wider-scale testing of HEAD + reporting any oddities would be helpful 
certainly, extra bonus for fixing any regressions found - I'm sure there 
are /some/ regressions the test-suite + our own day-to-day testing hasn't 
caught out.

>> Can you share some information on what are you planning to do with the
>> plugin functionality? Something akin to the SELinux plugin I presume?
>
> No, I want to keep everyone outside MeeGo completely in the dark.  ;-)
>
> MeeGo will have a security framework that will heavily leverage SMACK and
> IMA/EVM.  When packages are installed, we need to be able to set SMACK
> labels, calculate/verify/set the digsigsum's and run scripts with specific
> credentials.  I know that the plugin will not support all we need with
> respect to this.  For example, there is no plugin support for getting
> called right after a file has been extracted which would seem to be the
> optimal time (from a security perspective) to handle the digsigsum and
> SMACK label.  Also, running installation scripts with separate credentials
> can't be done from the plugin.  RPM does support doing both of these
> things for SELinux, but the functionality to do that resides outside of
> the plugin in older code.  I would actually love to see some of this
> functionality that was created for SELinux in other parts of the RPM code
> base migrate into the plugin so that others can utilize the functionality,
> but I also understand the limited scope of the plugin as it currently
> exists.

Ok. Work towards abstracting SELinux specifics out of core rpm into 
plugin(s), enabling use of other similar (security) frameworks to be used 
without changing rpm itself, would be very welcome. Perhaps too late to 
get into rpm 4.9.0 at this point but there's always the next release :)

>
> Does that all make sense?  Am I missing something that you had interest in?

Makes sense, sure. I basically just wanted to know what aspects of the 
plugin/collection system you're interested in and the above answers that 
quite sufficiently, thanks.

 	- Panu -