← Back to team overview

launchpad-dev team mailing list archive

Re: Rethinking the official_<service> attributes

 

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'm not sure those are significant enough to make people explicitly set it.

But perhaps explicitly setting it is actually clearer:

 code/bugs/translations/.. is:
   - unknown
   - officially hosted on Launchpad
   - officially elsewhere (specify), but with some community branches
on Launchpad
   - we don't want people putting branches on Launchpad, they should
all be (where)
   - this project has no code

-- 
Martin



Follow ups

References