db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: Grant and Revoke ... DERBY-464...
Date Wed, 26 Oct 2005 23:42:34 GMT
Francois Orsini wrote:

> Fair enough - but at the same time, the proposal is an evolving one in
> my opinion - I posted some preliminary comments in the JIRA of items I
> think we need to take into consideration (add to the specs) - I don't
> mind adding comments sequentially to JIRA but the proposal (aka
> Functional Specs) will have to evolve as we find that we need to add
> more (items) to it.

When making comments and saying the spec needs to evolve, bear in mind
two things "scratch your own itch", and Satheesh's comment in the spec

'This paper describes a proposal to introduce Derby's SQL2003 compatible
access control system. There are many further enhancements possible in
access control and security areas. My current itch is to limit the scope
to what is proposed here.'

So for this spec adding things like CREATE ROLE and CREATE USER is not
what Satheesh wants to do, so they won't evolve his spec.

If you want to add CREATE ROLE/USER then that would be great, go ahead
and provide a spec and code, most likely referencing Satheesh's spec,
and maybe as both projects proceed they will impact each other's spec in
details, but most likely not in scope.

Thus it's wise to review this for what it is, adding grant/revoke
functionality. If it's thought that grant/revoke is useless without
roles, then we still shouldn't veto Satheesh's work, just because he
isn't doing roles. Instead we should see that he is adding value to
Derby, and with his project we are closer to grant/revoke with roles,
than not having Satheesh do the work.

> As far as the design and code, well, don't we need to finish commenting
> on the proposal and then agree we want to proceed via a Vote or not - I
> would have assumed so, expecially for such a big feature. Hence, one is
> always taking of risk to implement something before the proposal has
> been approved by a community, no? ;)

Well, technically you vote on code, not on proposals. A proposal more
falls into the long term plans category.

http://db.apache.org/decisions.html

<quote>
Long term plans are simply announcements that group members are working
on particular issues related to the Project. These are not voted on, but
Committers who do not agree with a particular plan, or think that an
alternative plan would be better, are obligated to inform the group of
their feelings.
</quote>

Though sometimes a vote can't hurt, especially along paths that have
contention e.g. shared code :-). For a new feature that's in line with
the charter, a vote is not needed for any proposal/functional spec,
unless there starts to be disagreement. Even then it depends on the
disagreement, if one person says they can do it better, then it really
doesn't matter until the code appears, as Andrew said "show me the
code!". As the quote says, disclose your plans and it's up to the
community to object early.

Also no matter what the community votes or disagrees on at the proposal
level, you can't stop an individual working on a project. It's their
time and interest. If they present completed code it to the list when it
was made clear the community didn't want it then they can't complain.
Hopefully it doesn't come to that, and instead some common ground is found.

> Also, am seeing that we're recoding comments here in this thread and
> within the JIRA - shouldn't we try to record all comments in JIRA rather
> than doing it at several places? just wondering - I understand email is
> fine but it is more for a manageability aspect that ideally it would be
> good to have comments in the JIRA ;) - but that is just my view...

Anyone is free to summarise comments from the e-mail in the Jira
comments. I'm in two minds, Jira doesn't provide an easy quoting
mechanism, so it's not the best to place to have a discussion, but the
single trail is also good. However I've also seen cases where incorrect
information is put in as a Jira comment, and so it remains there. I
guess it could be deleted.

Dan.


Mime
View raw message