launchpad-dev team mailing list archive

[Max Bowsher <maxb@xxxxxxx>]

On 03/02/11 23:57, John Arbash Meinel wrote:
> There are 2 effects that I know of from dev focus:
> 
> 1) Stacking target
> 2) result of 'bzr branch lp:???'
...
> For Debian, what is the normal starting point for proposing a patch? It
> sounds like things are generally proposed against sid anyway. Or is sid
> *too* unstable, and people want to target whatever is currently
> targetted for release?

The former, normally you look at sid as a base for future development.

> Especially considering the various points in time. What happens at
> Freeze times, etc.

During a Debian freeze, it's generally recommended to still work through
the ->sid->testing workflow, and try to keep sid from diverging from
what would want to go into the release, if possible.

> It sounds like targetting sid as the dev focus would fit both 1 and 2.
> With the only caveats
>  a) sid is pretty fixed, so it is easy to create a different shortcut
>     for it (eg, deb-sid:project)
>  b) Are packages taken directly from sid, or is it more a bunch of
>     stuff, and *some* of the patches in the sid code will be pulled
>     into the stable version.
>     (If I'm doing a new patch, do I want sid even though someone else
>     might have broken it, because that's what my patch has to deal
>     with, or do I want squeeze-to-be?)

It depends on whether you are doing feature development, or a security /
critical bug fix.

> Then again, I don't think many people are doing UDD for debian branches
> anyway, so just fixing on sid sounds like a decent way to go.

I'd like it if the dev focus was set to sid. It seems incongruous that
it isn't.

My usual use case for using Debian branches is to inspect history of the
Debian packaging, in which case I always want all the history, not just
the subset that has entered testing.

Max.

Attachment: signature.asc
Description: OpenPGP digital signature