Contractor usage

Derek Neighbors derek at gnue.org
Thu Nov 6 23:12:56 CST 2003


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Question from the bleachers....

Would it make the most sense to just finish a gtk2 port and not spend
time refactoring code (which is probably what would have to occur to
change something like thtis) until that is done?

~From a project management prospective generally it is a bad to chew off
two many focus items at one time.  As they always "seem" like they would
be easier to tackle together cause "you are already making other changes".

However, what always ends up happening is that releases become extremely
delayed and quality assurance suffers because of time decay and too
extreme of change to effectively manage.  At least that has been my
experience in both Free Software and Proprietary Software development.

I think you would be better served to label what are the most important
focuses of the coming release (short of bug fixes), pick one or two of
them and stick to those changes until complete.  Again this is strictly
from the bleachers and can completely be ignored as I have no time to
actively contribute code at this point. :)

- -Derek Neighbors

Derek Atkins wrote:
| Let me think about this and get back to you.  At a first
| approximation, the "user" should have some "user authentication
| context", and ALL engine APIs should require (either explicitly or
| implicitly) that context and verify the user's permission to perform
| the operation.
|
| Whether the underlying architecture is role-based, capability-based,
| or ACL-based can be decided later.  The important point is that every
| API function need to check the context for permission to perform the
| operation -- which requires each API to have access to the user
| context.
|
| -derek
|
| linas at linas.org (Linas Vepstas) writes:
|
|
|>Um, Derek,  Since I'm busy tearing things up with qof anyway,
|>this might be a good time to discuss this.  Do you have any
|>particular opinions or good ideas on how to accomplish priveldge
|>separation, etc. ?  Would you want a capabilites system?
|>Something with ACL's/MAC-like thingy? Hooks for both?   Users?
|>Roles?
|>
|>All I'm thinking of would be to add appripriate hooks to
|>appropriate places, and 'refactor' as needed, and add the bare-bones
|>minimal to keep it working as it currently does.  But I haven't
|>given this design much thought, so now is a good time to point
|>out any of the 'fundamental design flaw' type issues, and possible
|>blue-sky workarounds for them.
|>
|>Let me know ...
|>
|>
|>--
|>pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas at linas.org>
|>PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933
|>
|>
|
|

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQE/qzfnHb99+vQX/88RAjs3AKCEnYCxZEIV2LHqDswkmElHKTryqQCfYq7e
kXNkMSxgDdvrkCEpjPpuIa4=
=o6m9
-----END PGP SIGNATURE-----



More information about the gnucash-user mailing list