"be structured, too, is with three roles: external (just adding bugs), internal (developing code, assigning/fixing bugs), and admin. We can rename these roles to something more obvious, but I think those 3 levels of permission are specific enough."
Ok, I see the point now and I agree. But the code does not respect that. For example, right now in baf-assignments.tcl (to assign issues to someone) it calls user_can_edit_package_p, which only returns true if the user is a package admin. It doesn't even check if you are internal or not.
user_can_edit_package_p is probably doing what it's intended to do. But then we should have another proc, like user_can_assign_issues_p or just a query to check if the user is internal. In other words, we should change the permission model to check for the roles/actions (I did that to user_can_see_package_p).
"For submitting patches, try using the existing patch data model / code, so that a patch can be linked to a bug."
The existing patch data model doesn't allow that:
create table sdm_package_patches (
patch_id integer not null primary key,
user_id integer not null references users,
package_id integer not null references packages,
package_release_id integer not null references package_releases,
submission_date datetime,
patch_file varchar(200),
patch_description varchar(4000),
accepted_p char(1) check (accepted_p in ('t','f')),
action_user integer references users,
action_date datetime,
action_description varchar(4000)
);
"CVS improvements: what are you thinking of doing there?"
Mostly interface issues. For example, I like the way cvsweb/viewcvs shom me which lines have been added/removed/changed. It helps to quickly identify a change, learn from it, or spot an error introduced in a revision.
I haven't studied the CVS portion of SDM very much, but I think it puts somethings in the DB, and the admin has to manually update the CVS on SDM, which is not doable with something as dynamic as a CVS tree.
What do you think about the idea of assigning projects to teams?
