launchpad-dev team mailing list archive

[John Arbash Meinel <john@xxxxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


...

> Are there any booby traps in the system that would blow up if we made
> 'sid' the development release, with squeeze etc forks off from it.
> This seems to represent what we do in debian better *anyway*: sid and
> squeeze are different branches, even if squeeze branches only have a
> strict prefix of the sid history.
> 
> -Rob

I think you mean "'sid' the development focus".

There are 2 effects that I know of from dev focus:

1) Stacking target
2) result of 'bzr branch lp:???'

As I understand it, people who are doing "bzr branch lp:ubuntu/project",
are doing so because they want to make changes to whatever is going to
be in the next release version (which is why we currently target Natty,
and we'll target O, etc.)

This happens to play nicely with both 1 and 2. You get to grab new data
from a full branch without stacking, and you get the target of what you
want to be developing on.

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?

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

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?)

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.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1LQOAACgkQJdeBCYSNAAOLXACgyyWwQzUDnECmZXquUmauaDhC
JGYAn3BEKEII6IU6TilJ44oicSABpM5+
=64kr
-----END PGP SIGNATURE-----