Re: [Savannah-hackers-public] support for repository(ies) contact/description

[Sylvain Beucler]

Hi,

I think I have some more suggestions about this.

One goal is to permit different kind of permission models. For
example: personal repositories, forks, etc.

So the permissions need to be stored in the database as well.
It can be a simple model:
  type enum ('shared', 'single_member', 'single_non_member')
  owner_user_id int

or more complex (ACLs)
table repo_users -- NxN
(
  repo_id int,
  user_id int,
  type enum ('member', 'admin')
)
or something like that.

Both could be combined (for both flexibility and simplicity), using
the ACL database, and allowing user to chose pre-configured ACLs
through the web interface that would mimic shared/single_member/etc.

-- 
Sylvain


On Mon, Jun 09, 2008 at 11:39:59PM +0200, Sylvain Beucler wrote:
> Hey,
> 
> On Mon, Jun 09, 2008 at 10:05:40AM +0200, Aleix Conchillo Flaqué wrote:
> > On Sun, Jun 8, 2008 at 11:27 AM, Sylvain Beucler <address@hidden> wrote:
> > >
> > > My main concern is: will this fit all VCSes? Though, maybe we can just
> > > add a separate joined table if a VCS requires additional fields .
> > >
> > > 'contact' is not used by 'bzr' afaics; maybe that field can be just
> > > ignored by the bzr backend, or maybe the field can be disabled in the
> > > edit form (so users don't expect it to be used).
> > >
> > 
> > I think it can also be used, not for any bzr internals, but just to
> > provide information. That is, there could be a page (read-only) or
> > existing one, providing repository description and contact
> > information.
> > 
> > >
> > > The alternate way is to create a specific table for each VCS, but this
> > > sounds much more difficult to me anyway.
> > >
> > 
> > And it likely has performance penalties. For example, if you want to
> > obtain all the repositories that 'show_in_source_menu', with one table
> > it can be done at once with a simple select. The other way would mean
> > as many selects as activated VCS (which is not a lot).
> > 
> > >
> > > I'd suggest changing 'is_default' to 'show_in_source_menu'.  This way,
> > > main repositories would be proeminently displayed in the "Source Code"
> > > menu, as well as in the project homepage. Other repositories would be
> > > displayed in a separate "other repositories" page; this would exclude,
> > > for example, experimental repos and obsolete repos (such as CVS repos
> > > if you switched to Mercurial, but still wish to keep the old CVS
> > > around :)).
> > >
> > > The bottom line is: I think some project will have several main
> > > repositories (I do :)).
> > >
> > 
> > OK, that makes more sense.
> > 
> > >
> > > I think listing all repositories at once is easier to edit.
> > >
> > 
> > OK.
> 
> I agree with everything :)
> 
> 
> We didn't consider the backend more than that, but I don't see any
> obvious problem there either.