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"... ;)

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

> 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.  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.

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.

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

> 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.

> 2. The loader filtering possibilities. Currently it can't filter based
> on categories.

Also a problem, agreed.  But same issue as above...

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

Julian