specifying what services Activities may use
gregsmitholpc at gmail.com
Thu Jul 31 08:45:51 EDT 2008
I hear you that defining dependencies and APIs is a tough challenge. As
someone else mentioned, many projects do it effectively so we can do it
I'm not partial to any particular parsing of the data. Maybe the
activity developers have an opinion...
The key points are:
1 - When can we announce "no more changes" and activity developers can
do a final test? Hopefully we give enough notice for them to fix
anything that is broken before the release.
2 - Where and when can we document the changes in 8.2.0 which may affect
Is your categorization getting us closer to that?
I think we know what to do but if its still not clear we can get an
activity developer on the phone (or IRC) and they can tell us what they
need. It has to be a listening meeting with no push back or argument.
They tell us what they need and we figure out how well we can respond.
That's one idea for moving forward but perhaps we have all we need from
this thread and just need to write it down.
Morgan's related thread ([sugar] Proposal: Activity developers mailing
list) will help improve communication so it may all come together if we
strike while the iron is hot!
Erik Garrison wrote:
> On Wed, Jul 30, 2008 at 12:03:52PM -0400, Michael Stone wrote:
>> On Wed, Jul 30, 2008 at 11:03:41AM -0400, Greg Smith wrote:
>>> Hi Daniel,
>>> We need a list of anything that might "break" an activity.
>> The list of things that have to work in order for an activity
>> (particularly a networked one) to "work" is larger than the memory and
>> comprehension of any individual working on this project. It includes
>> nasty things like
> Is this a reasonable categorization?:
> kernel version dependent:
>> * syscall semantics
> system library dependent:
>> * availability of language interpreters
>> * library APIs
> nasty things we tend to change:
>> * file-system layouts
>> * authorization data like file-system permissions
>> * statistical biases in the outcomes of non-deterministic computations
>> * computational complexity of default algorithms
More information about the Devel