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.
