launchpad-dev team mailing list archive

[Jelmer Vernooij <jelmer@xxxxxxxxxxxxx>]

On Wed, 2010-07-28 at 14:46 +1000, Martin Pool wrote:
> On 28 July 2010 05:13, Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx> wrote:
> > I have talked about removing or changing official_<service> attributes
> > before. Today is the day we need to make that decision. The bool state
> > does not work, and we are more interested in knowing where the service
> > is hosted, not that the service is hosted on Launchpad. We cannot
> > complete the project configuration progress bar, or update all app pages
> > to state if an application is used in Launchpad or used elsewhere when
> > all we know is if a project chooses to officially use Launchpad.
> >
> > Each app has it own circumstances, and I would like the team to review
> > them. The three states we care about for an service are:
> > UNKNOWN, LAUNCHPAD, EXTERNAL (name/url of location). Replacing the bools
> > with a vocabulary accomplishes part of goal. Knowing where the service
> > is would be helpful.
> >
> > official_codehosting:
> > This means nothing. It is not used in the code at all.
> >        UNKNOWN: Project branch is not set.
> >        LAUNCHPAD: Project branch is set and it is hosted on Lp.
> >        EXTERNAL: Project branch is set and it is a mirror.
> >
> > Nothing actually needs to change. We could have an attribute the returns
> > the states three states we care about
> 
> There are a couple of other cases.
> 
>  * the development focus is a mirror of a bot-managed branch hosted
> elsewhere, but the code is still primarily on Launchpad
>  * the development focus is a bzr-svn or other mirror, but they
> encourage development to be done in branches on Launchpad
I agree it would be nice to at least have a setting for the second
situation you mention. It's great to know if proposing a merge into
lp:<projectname> will have an effect, even if lp:<projectname> is a
mirror but the project cares about what's done in Launchpad. 

This sort of setting would also be useful if we have the infrastructure
in place to let package maintainers forward Debian patches (loom
threads?) upstream as part of UDD.

Cheers,

Jelmer

Attachment: signature.asc
Description: This is a digitally signed message part