[maemo-community] Extras and Fremantle

[From: Jeremiah Foster]

On Mar 4, 2009, at 2:00 PM, Quim Gil wrote:

> ext Jeremiah Foster wrote:
>
>> It can work for maemo, but debian is much larger and has grown over
>> the years, so it can take time to work out the kinks.
>
> Debian is applying this process for the whole platform, thousands of
> packages. Since Maemo SW takes care of the official platform and apps.
> maemo.org extras should take care only about a subset. A significant
> one, but not as big and complex as a whole patform that is stable,
> secure, builds, etc.

This is a good point. We may be able to save time and energy by using  
the tools that we already have plus some additional tools. We can't do  
everything we would like with the tools we have currently, but it  
might be easier to extend them than to take on dak. In fact, dak comes  
with lots of warnings _not_ to use it. :)
>
>>
>>> What is left for us is a clear definition of
>>> the QA policy,
>>
>> This is important, and involves a lot of community input. It should
>> most likely have a dedicated mailing list.
>
> In fact it requires a good draft in a wiki page. I don't think "lot of
> input" would bring much more than input from you driving plus a  
> dozen of
> contributors bringing ideas and reviewing drafts.

Well, I want everyone to feel they have input into the process. It  
would suck if the policy felt arbitrary to the developers - they have  
to be able to significantly alter it through a reasonable process.  
Which probably is a wiki page and some emails. =)
>
>>> the automated tests
>>
>> There are some issues - who currently is responsible for the  
>> automated
>> tools, automated tests and build daemons? To what degree do they
>> implement policy? Who maintains them, Nokia or maemo.org?
>
> Maemo SW has engineers and even project specializing in test  
> automation
> tools. I would expect some of their work for internal development to  
> be
> recyclable for maemo.org. If we connect the right people inside and  
> outside.

This can lead to a quick and useful quality upgrade, that kind of  
inside - outside contact is invaluable.

>
>>> and then adapt the current
>>> repository structure to this new one.
>>
>> Unfortunately this is not trivial. The simple reason is that debian
>> uses tools that are built for debian and seem to work poorly other
>> places. Debian uses dak (debian archive kit) to manage repos. Ubuntu
>> uses something else. dak is big, poorly documented, and is not
>> currently being used in maemo, this means the current repo system
>> would have to be adapted to dak. Think new repos, new documentation,
>> new policy, etc.
>
> Is it so difficult to come up with a script able to promote packages
> automatically based on certain discrete criteria?

Heavens no.

> I'm not saying it's
> easy but I don't think we need the whole Debian infrastructure for  
> that.

No we don't. But this is the first I have heard of the need for  
promotion script. Are there more details or is there a thread I should  
read?

There is a need to remove old packages currently in the maemo repos.  
One can do this with dak. Scripting this would be hard though not  
impossible (parsing debian version numbers is painful.)

>> Adapting debian tools to manage the maemo repositories might be a
>> really good idea, but there are some significant technical hurdles.
>
> So basically what we could have is:
>
> - Basically no tools for extras-experimental. Upload your stuff and  
> you
> are done.

Yes - this is a volatile repo, it comes with no warranty. If it breaks  
your system you get to keep both pieces.

> - Automated build and testing and policy tools for extras-devel. If  
> you
> can get there it means that you have done a decently good job already.
> Starting with what we have now and improving. Every time someone  
> (could
> be Nokia) complains about the poor QA you can answer 'feel free to
> provide tools or the means to get a better QA process'.

This is excellent. The new extras-devel motto; "patches welcome!"

> - Automatic promotion process from devel to testing and to stable  
> based
> on simple rules e.g. karma value, downloads, days in repo,
> critical/blocker bugs...

Lets define that, spec it out, and away we go.

Jeremiah