launchpad-dev team mailing list archive

[Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

I am moving this to the public list because every launchpad hacker
should understand the issues.

The issue is where to we place code that is shared by the registry and
another application.

On Fri, 2009-08-14 at 19:40 +0200, Danilo Šegan wrote:
> У пет, 14. 08 2009. у 11:58 -0400, Barry Warsaw пише:
> > 
> > Isn't this why we have 'coop'?  horribly name that it is ;)
> > 
> 
> If it is, almost Entire Registry can move there. :)
> 
> I thought that 'coop' was for bits with more limited scope, i.e.
> integration between two applications.

Correct. It is for application-to-application features. The registry is
an exception because is you cannot consider running launchpad without
it. That is the key to understanding where code lives. Let's use a real
example.

        To remove bounties all I need to do is not load its ZCML in the
        main configure.zcml, then delete lp.bounties, then delete the
        coop modules.

Well we all know that will not work because bounties is not strictly in
its own module. The code is everywhere. Discounting c.l, I see:
        
        lib/lp/registry/configure.zcml
        lib/lp/registry/model/product.py
        lib/lp/registry/model/distribution.py
        lib/lp/registry/model/project.py
        lib/lp/registry/interfaces/product.py
        lib/lp/registry/interfaces/distribution.py
        lib/lp/registry/interfaces/project.py
        lib/lp/registry/templates/object-portlet-bounties.pt
        lib/lp/registry/templates/bounty-link.pt
        lib/lp/registry/templates/person-bounties.pt
        lib/lp/registry/templates/related-bounties.pt
        lib/lp/registry/browser/configure.zcml
        lib/lp/registry/browser/product.py
        lib/lp/registry/browser/distribution.py
        lib/lp/registry/browser/person.py
        lib/lp/registry/browser/project.py
        lib/lp/soyuz/stories/soyuz/xx-distribution-bounties.txt
        lib/lp/translations/browser/potemplate.py

The implementation can confuse the issue. Look at
structuralsubscriptions in c.i.l. This looks like cross-domain code
because it joins bugs and specs to pillars. I think this is an
implementation detail though. I think this is lp/registry.

There is the case of sprints, which will disappear if blueprint is
disabled. A blueprint is associated to a pillar by a specification. But
is this right? I think a sprint in the real world happens because of a
release planning for a project, maybe a team. I want to refactor sprints
and move them registry.

So back to the question of our many kinds of packages. If we turn of
Soyuz, would I be able to use these objects. I link to use Baltix as an
example because I know it is a distribution that does not use Soyuz:

        Can Baltix have DistributionSourcePackages?
                The answer seems to be no because I cannot search for a
                dsp, but if we generated a cache for other distros, the
                answer is yes
        Can a Baltix series have a SourcePackage?
                If it can have a dsp, then I think it must have an sp.
        Can a Baltic series have an architecture?
                The answer is yes, but it is not clear how it is used
                without Soyuz
        Can Baltix have a DistributionMirror?
                According to the bug tracker no, but I see that it does
                and it works. I think the real answer is yes.

-- 
__Curtis C. Hovey_________
http://launchpad.net/

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