upload rights for my Debian packages

[Daniel Pocock]

On 31/12/13 14:48, Iain Lane wrote:
> Hi there,
>
> On Wed, Oct 16, 2013 at 12:54:43PM +0100, Iain Lane wrote:
>> […] 
>> We thought it might be easier to handle your application via email if
>> you'd prefer. It's asynchronous, so will take longer, but you might find
>> it more convenient.
>>
>> What do you think?
> I didn't see a reply to this, but your application now has testimonials
> on it, so I'm taking that as a sign that you're interested in this
> route.


I did send a reply back on 17 October, can you check your inbox or mail
logs?  Maybe the spam filter is playing up.  I am happy to continue the
process by email.

>
> We'll ask you a few questions over email and then once satisfied there
> will be a vote. You'll need 4 +1s to pass (the same as on IRC).
>
> I've got a couple of questions to check your knowledge of Ubuntu's
> freezes.
>
>   - What are the main freezes during a development cycle?


The Ubuntu freezes are
- Feature definition freeze
- Debian import freeze
- Feature freeze
- User interface freeze
- Documentation string freeze
- Final beta freeze
- Kernel freeze
- Final freeze



>   - How can you find their dates?
Wiki pages like this:

https://wiki.ubuntu.com/SaucySalamander/ReleaseSchedule


>   - How do they affect what you can upload?

The freeze items on the calendar link to wiki pages describing the
guidelines/restrictions that apply at each freeze

For example, Debian import freeze doesn't prevent packages coming into
Ubuntu from Debian, it just requires a manual approval on a case-by-case
basis

>
> One of the 'areas of improvement' on your application talks about test
> building packages. When you request or perform uploads explicitly (e.g.
> when asking for a sync after Debian Import Freeze), how do you check the
> package is suitable for Ubuntu?

I look at a lot of things

As upstream developer, I run automated test cases and manual tests
before I commit code or push the code to the upstream repository

The upstream repositories are usually linked to some kind of CI testing
(e.g. for reSIProcate, I've set up both travis-ci.org builds and the
coverity scans).  These give me emails and logs when things fail.

On top of that, and especially in cases where I am the upstream release
manager (the person who tags an upstream version), I usually build the
code on several virtual machines including Ubuntu, Fedora, RHEL/EPEL and
Solaris/OpenCSW.  For some projects I also build the code on more
diverse toolchains, including Android, Cygwin, MS Visual Studio and OpenWRT.

I also look closely at the logs from Debian's autobuilders on various
architectures and kernels and any compiler warnings or test case
failures from there are used to improve the upstream code.

Generally, if I have a positive experience of building and use the code
on several of these platforms then I consider it suitable for stable
releases.  Intermediate releases are usually tagged as betas or release
candidates to give further indication of which code I consider stable.