On Feb 2, 2009, at 9:09 PM, Donohoe, Mark wrote:
> Bob Gobeille wrote:
>>
>> For this discussion it helps to keep the terms straight. There are
>> "jobs" and "jobqueue entries". A job queue entry is just a single
>> task. One Job can have multiple jobqueue entries.
> So let me make sure I have the table relationship correct. Job to
> jobqueue is a one to many relationship (1 job many jobqueues).
> Correct?
Yes. And uploading one file to the repository may spawn multiple
jobs, with each job containing multiple jobqueue entries, and jobqueue
entries that depend on other jobqueue entries in other jobs.
>> So a license job, has 7 tasks (jobqueue entries), where each task
>> is just another part of the license pipeline. It is the jobqueue
>> that
>> has dependencies. Job was supposed to be on top, with 1-n jobqueue
>> entries under it. This hierarchy was butchered when we added
>> dependencies on jobqueue entries.
>
>> So a jobqueue entry typically depends on another task in a different
>> job (as opposed to being dependent on the job)
> Huh, really? So if I have 4 'jobs' for the request (I'm watching an
> upload as I type this...)
> - Unpack
> - License
> - Default Meta Agents
> - Meta Analysis
>
> Each composed of sub-jobs, you are saying that the license sub-job
> sqlagent can have a dependency on let's say Meta-Analysis sub-job
> pkgmetagetta? Holy dependencies!
>
> Ah, I see what you are saying... it's not that bad, but we use the
> dependency between jobs to order them....
Yep.
>>>> The users table does have an email address but that doesn't mean
>>>> that
>>>> email notification is desired. So are you saying that you will
>>>> add a
>>>> field to indicate if email notifications should be sent by default
>>>> (but potentially overridden during upload time)?
>>>
>>> Yes, I would add a checkbox for email notification and and area
>>> to list
>>> other e-mail addresses that want to be notified by email.
>>
>> Why not just keep the comma separated list, like we have now?
> To me it seems strange from a UI perspective to mix 'others' with the
> user email addresses. It seems sorta spam like as well. 'Just put
> your
> comma separated email address in here and we'll be happy to send
> them out'.
>
> Hmm, just looked at the code, the fields are only 60 characters
> long...
> some email address can be long. Using my work address as a poor
> sample, 60 characters is long enough for 2-3 addresses.
>
> I guess I can live with it either way... but I would make the fields
> 128
> or 512 characters long so a decent list could be supplied.
I was just trying to keep it as simple as possible. But I agree with
you, two fields would be better.
>>>> What tests are you including?
>>>
>>> Huh? I'm not sure what you are asking. I plan to write tests for
>>> this
>>> agent/function. Plus, all of the user pages need tests written for
>>> them. Either Mary or I can code those.
>>
>> I meant, what conditions are you going to test? For example, killing
>> a jq_pk manually, cross site scripting in the email address, ...
> Hmm, I usually don't put that in a design doc. At least not at that
> detail. That sorta detail would be in a test plan. I do plan to
> study
I don't know that we need any more of a test plan than:
Test the following -
killing jq_pk manually
cross site scripting in the email address
...
>> What reply-to are you using in the email? What subject?
> I'm mocking the e-mail up now.
>> I think your design should list the files and tables you are going to
>> change along with what is going to change logically.
> I did, but I guess I wasn't clear enough. Please see the design doc
> to
> see if it now has enough detail.
It wasn't complete. I'll look at the updated http://fossology.org/email-design
b
_______________________________________________
fossology mailing list
[email protected]
http://fossology.org/mailman/listinfo/fossology
