Julian Fitzell <julian at beta4.com> wrote:
> goran.krampe at bluefish.se wrote:
> > Julian Fitzell <julian at beta4.com> wrote:
> > [SNIP]
> > 
> >>>For example, why not simply use filters smarter? I fail to see what
> >>>would need us to use multiple maps.
> >>
> >>Oh, it's not perfect by any means.  But it is simpler and it can be done 
> >>right now.
> > 
> > Eh, no. :) It is decidedly not simpler. The map contains not only
> > packages. It contains all the accounts too. So are we going to have them
> > duplicated in multiple maps? etcetc
> 
> Well, I realize this.  That's why I said below "shared an authentication 
> database"... ;)

Well, you said "it is simpler and it can be done today". I am saying, no
- it is not simpler since it *can't be done today* due to for example
the accounts.

> >>Even in the long term, I wonder whether the UI, etc mightn't be simpler 
> >>by having multiple SM instances that shared an authentication database 
> >>or something.  Not sure, but debian definitely keeps the three releases 
> >>very separate.
> > 
> > Maybe they do, but I stand very, very firm behind the fact that ONE map
> > is much simpler for us.
> 
> I don't actually see how it's simpler.  More redundant without sharing 
> accounts, maybe, but if they're shared...?

The point is that the map has objects that refer to each other.
Splitting it up will cause headaches. Period. For example - what about
the categories? Are we going to have three different category trees
then? etcetc

> > In fact - I claim that the perceived problem is in 95% due to poor UIs,
> > which of course is my fault. :)
> 
> Well, it's absolutely UI but I don't know it's your fault.  I think 
> doing stable/unstable/testing equivalents all in one UI is a pretty hard 
> problem.

I can't see it being that hard! Stable, unstable, testing are simply
three groups of package releases. Just create these three categories and
put the releases you like in each category. Done.


>  Hell, if you want to share one data set and provide three URLs 
> (or ports or whatever it is SMLoader uses to connect) so you can 
> configure your SMLoader to connect to the appropriate one that would be 
> fine too. 

> I don't even care if you want to try to come up with 
> something that integrates it all together.

Oh, good! :)

> But I think this will take time, and Lex' comment (as well as Avi's and 
> my responses) are a cry that we need this feature now.  We're already 
> seeing signs of outgrowing the current capabilities in terms of 
> specifying what versions people should be using in different cases.

Trust me - I am the one that has written 97% of SM - I think I know the
easiest way to deal with this, unless I am completely missing the point,
and I don't think I am.

> The stable/testing/unstable pattern is one that many people are familiar 
> with and we can do it easily right now, that's all. :)

Yes - we *can* do it easily right now - using categories.

No - we *can't* do it easily right now by creating three different maps.

> > The two biggest culprits are:
> > 
> > 1. The registration UI for releases. Namely how to select the proper
> > categories. Not easy today.
> 
> Agreed.  But the problem goes beyond that.  You need to mark one package 
> release as the current unstable; or the current stable.  This doesn't 
> want to be categories because you should never have more than one 
> release with that category on it.

Why are you saying "this doesn't want to be categories"? Just one or two
lines of code to enforce that validation you are talking about.

> > 2. The loader filtering possibilities. Currently it can't filter based
> > on categories.
> 
> Also a problem, agreed.  But same issue as above...

Sorry Julian, this time I think you guys are simply wrong. :) But I am
focusing on this issue and will make sure we get it all to work. And as
always, help is appreciated. :)

> (off for a day of snowboarding now so consider me out of the discussion :) )

Sounds great. Haven't had any snowboarding for a while...

> Julian

regards, Göran