osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: JIRA Workflow Proposals


My personal preference is to remove labels, but I don't see it as a huge
issue if they stay.

1. A
2. prefer to remove (I suppose I'm a -.1?)
3. +1
4. +1
5. No preference
6. +1



On Wed, Dec 5, 2018 at 11:43 AM jay.zhuang@xxxxxxxxx.INVALID
<jay.zhuang@xxxxxxxxx.invalid> wrote:

>  1: Component. (A) Multi-select
> 2: Labels: leave alone +1
> 3: No workflow changes for first/second review: +1
> 4: Priorities Including High: -1
> 5: Mandatory Platform and Feature: +1
> 6: Remove Environment field: +1
>
>     On Wednesday, December 5, 2018, 2:58:21 AM PST, Benedict Elliott Smith
> <benedict@xxxxxxxxxx> wrote:
>
>  Thanks for the feedback and further questions.  I’m sure there will be
> more, particularly around permissions and roles, so it’s good to get some
> of these other discussions moving.
>
> No doubt we’ll do a second poll once the first one concludes.  Please,
> everyone, keep your first poll answers coming!
>
> > On 5 Dec 2018, at 09:50, Sylvain Lebresne <lebresne@xxxxxxxxx> wrote:
> >
> > Thanks for all those that contributed to the proposal, and specifically
> to
> > Benedict for leading the discussion.
> >
> > On the general proposal, I suspect there is a few details we may have to
> > tweak going forward, but hard to be sure before trying and as I do think
> > it's progress, I'm personally happy to move forward with this. But for
> the
> > sake of discussions, a minor remarks that I don't think have been
> mentioned
> > above:
> > - at least the platform and feature fields will be moving targets (the
> > features hopefully more so than the platform, but new java version gets
> > release regularly for instance). Do we know technically if we can get
> those
> > easily updated without requiring an infra JIRA ticket?
>
> This is actually a really good question.  I had assumed this would be
> treated much like Component, Version, etc
>
> However, I was wrong:
>
> https://community.atlassian.com/t5/Jira-questions/Adding-options-to-a-custom-field-as-project-administrator/qaq-p/113311
> <
> https://community.atlassian.com/t5/Jira-questions/Adding-options-to-a-custom-field-as-project-administrator/qaq-p/113311
> >
>
> There are some possible workarounds, but none of them seem great.  There’s
> a plugin, but not sure if Infra would be OK with this:
> https://marketplace.atlassian.com/apps/1212096/customfield-editor-plugin?hosting=server&tab=overview
> <
> https://marketplace.atlassian.com/apps/1212096/customfield-editor-plugin?hosting=server&tab=overview
> >
>
> This is potentially a real blocker for these two fields.
>
> So, for feature an alternative is to merge Feature/[Feature] into
> Component.  This would implicitly make it non-mandatory, however.  This
> could potentially be fixed with a custom field validator, but this might
> need a plugin.
>
> For Platform, I don’t have a good alternative idea right now.  This is
> something that is best curated, but definitely needs to be easily updated.
>
>
> > - I'd personally probably remove the condition of being "jira
> contributor"
> > to move tickets out of triage. Being a "jira contributor" is a pretty
> > arbitrary in practice. Anyone that ever asked has been added, no question
> > asked, but it can actually be annoying to get added if no-one that knows
> > how to do it is around. So if, as I assume, the goal is to ensure that
> > fields are properly fielded, I don't think it will help much, and so I
> > suspect it would just be an annoyance to new, not-yet-"jira contributor"
> > users that are willing to fill all the required fields seriously (but
> will
> > see their ticket stuck in triage until they either get added, or some
> other
> > random user flip the switch). And why assume people will mis-field
> stuffs?
> > So I'd vote for just letting anyone transition out of triage as long as
> all
> > required field are there. Side-note: fwiw, I'd very much be in favor of
> > removing the "jira contributor" concept for the reasons exposed above: I
> > never felt it was anything else than an hindrance.
>
> I realise we have no real barrier to becoming a contributor, and that many
> of these permissions are going to have limited impact.  But I think a
> really easy to jump gate can still be helpful, and I don’t recall
> contributors overstepping their role.  But this isn’t a critical point, and
> it would be great to hear other’s opinions.
>
> > - Once we have 'complexity' and 'severity', I'm not entirely sure what
> > 'priority' really means in a voluntary-based project? Is it the
> gut-feeling
> > for how useful the ticket is of whomever triage the ticket? If that,
> > outside of not being convinced of the value, I'd argue that 1) it doesn't
> > make sense for bugs and 2) it's sufficiently imprecise that it's imo
> worth
> > keeping it simple, something like low/normal/high ought to be enough. If
> > it's not that, then what is it, cause it's genuinely not immediately
> > obvious to me?
>
> Well, if nothing else Priority is the thing I sort my outstanding work by,
> and for this reason I have a preference for it being present for all ticket
> types.  But I do see your point.
>
> In particular, Urgent probably is something we’re only likely to use for
> critical bugs.  It’s possible we could even automatically populate this for
> a Bug type, and potentially not show this option for non-bugs.  But I
> suspect we would need something like the ScriptRunner plugin for this.
>
> In my view Priority is essentially Low or Normal (or Urgent if critical
> bug) on initial filing.  But a High priority can be set by a contributor
> who particularly values the ticket, for their own work prioritisation.
> Wish is a priority to make room for the Wish ticket type we are removing,
> and for those occasional requests that come in that have no realistic
> timeline for being addressed.
>
>
> >
> > And with that, my poll results:
> > 1:A
> > 2:+1
> > 3:+1
> > 4:Don't mind
> > 5:Don't mind
> > --
> > Sylvain
> >
> >
> > On Tue, Dec 4, 2018 at 8:12 PM Benedict Elliott Smith <
> benedict@xxxxxxxxxx>
> > wrote:
> >
> >> Ok, so after an initial flurry everyone has lost interest :)
> >>
> >> I think we should take a quick poll (not a vote), on people’s positions
> on
> >> the questions raised so far.  If people could try to take the time to
> stake
> >> a +1/-1, or A/B, for each item, that would be really great.  This poll
> will
> >> not be the end of discussions, but will (hopefully) at least draw a line
> >> under the current open questions.
> >>
> >> I will start with some verbiage, then summarise with options for
> everyone
> >> to respond to.  You can scroll to the summary immediately if you like.
> >>
> >> - 1. Component: Multi-select or Cascading-select (i.e. only one
> component
> >> possible per ticket, but neater UX)
> >> - 2. Labels: rather than litigate people’s positions, I propose we do
> the
> >> least controversial thing, which is to simply leave labels intact, and
> only
> >> supplement them with the new schema information.  We can later revisit
> if
> >> we decide it’s getting messy.
> >> - 3. "First review completed; second review ongoing": I don’t think we
> >> need to complicate the process; if there are two reviews in flight, the
> >> first reviewer can simply comment that they are done when ready, and the
> >> second reviewer can move the status once they are done.  If the first
> >> reviewer wants substantive changes, they can move the status to "Change
> >> Request” before the other reviewer completes, if they like.  Everyone
> >> involved can probably negotiate this fairly well, but we can introduce
> some
> >> specific guidance on how to conduct yourself here in a follow-up.
> >> - 4. Priorities: Option A: Wish, Low, Normal, High, Urgent; Option B:
> >> Wish, Low, Normal, Urgent
> >> - 5. Mandatory Platform and Feature. Make mandatory by introducing new
> >> “All” and “None” (respectively) options, so always possible to select an
> >> option.
> >> - 6. Environment field: Remove?
> >>
> >> I think this captures everything that has been brought up so far, except
> >> for the suggestion to make "Since Version” a “Version” - but that needs
> >> more discussion, as I don’t think there’s a clear alternative proposal
> yet.
> >>
> >> Summary:
> >>
> >> 1: Component. (A) Multi-select; (B) Cascading-select
> >> 2: Labels: leave alone +1/-1
> >> 3: No workflow changes for first/second review: +1/-1
> >> 4: Priorities: Including High +1/-1
> >> 5: Mandatory Platform and Feature: +1/-1
> >> 6: Remove Environment field: +1/-1
> >>
> >> I will begin.
> >>
> >> 1: A
> >> 2: +1
> >> 3: +1
> >> 4: +1
> >> 5: Don’t mind
> >> 6: +1
> >>
> >>
> >>
> >>
> >>> On 29 Nov 2018, at 22:04, Scott Andreas <scott@xxxxxxxxxxxxxx> wrote:
> >>>
> >>> If I read Josh’s reply right, I think the suggestion is to periodically
> >> review active labels and promote those that are demonstrably useful to
> >> components (cf. folksonomy -> taxonomy<
> >> https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy>). I
> >> hadn’t read the reply as indicating that labels should be zero’d out
> >> periodically. In any case, I agree that reviewing active labels and
> >> re-evaluating our taxonomy from time to time sounds great; I don’t think
> >> I’d zero them, though.
> >>>
> >>> Responding to a few comments:
> >>>
> >>> –––
> >>>
> >>> – To Joey’s question about issues languishing in Triage: I like the
> idea
> >> of an SLO for the “triage” state. I am happy to commit time and
> resources
> >> to triaging newly-reported issues, and to JIRA pruning/gardening in
> >> general. I spent part of the weekend before last adding components to a
> few
> >> hundred open issues and preparing the Confluence reports mentioned in
> the
> >> other thread. It was calming. We can also figure out how to rotate /
> share
> >> this responsibility.
> >>>
> >>> – Labels discussion: If we adopt a more structured component hierarchy
> >> to treat as our primary method of organization, keep labels around for
> >> people to use as they’d like (e.g., for custom JQL queries useful to
> their
> >> workflows), and periodically promote those that are widely useful, I
> think
> >> that sounds like a fine outcome.
> >>>
> >>> – On Sankalp’s question of issue reporter / new contributor burden: I
> >> actually think the pruning of fields on the “new issue form” makes
> >> reporting issues easier and ensures that information we need is
> captured.
> >> Having the triage step will also provide a nice task queue for screening
> >> bugs, and ensures a contributor’s taken a look + screened appropriately
> >> (rather than support requests immediately being marked
> “Critical/Blocker”
> >> and assigned a fix version by the reporter).
> >>>
> >>> – On Sankalp’s question of the non-committer’s workflow during first
> >> pass of review, I think that’s covered here:
> >>
> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals#JIRAWorkflowProposals-Workflow
> >>>
> >>> –––
> >>>
> >>> I also want to step back and thank Benedict and Kurt for all of their
> >> analysis and information architecture work behind this proposal.
> "Workflow
> >> and bug tracker hygiene” can be a thankless endeavor; I want to make
> sure
> >> this one’s not. Thank you both!
> >>>
> >>> If we’re nearing consensus on “keeping labels, and considering them for
> >> promotion to components periodically,” are there other items we need to
> >> resolve before we generally feel good about the changes?
> >>>
> >>> – Scott
> >>>
> >>>
> >>> On November 26, 2018 at 3:14:05 PM, Benedict Elliott Smith (
> >> benedict@xxxxxxxxxx<mailto:benedict@xxxxxxxxxx>) wrote:
> >>>
> >>> Hmm. On re-reading your earlier email, I realise I may have anyway
> >> gotten confused about your suggestion.
> >>>
> >>> Are you suggesting we periodically clear any new labels, once we have
> >> replacements, and only leave the old ones that exist today and haven’t
> been
> >> categorised?
> >>>
> >>>
> >>>> On 26 Nov 2018, at 23:02, Benedict Elliott Smith <benedict@xxxxxxxxxx
> >
> >> wrote:
> >>>>
> >>>> Do we maintain a list of prior rejects? Revisit any that have
> increased
> >> in usage since last?
> >>>>
> >>>> Probably we’re bike shedding this one thing too closely. I would be
> >> happy with removing it, periodically cleaning it, or leaving it intact.
> >> Mining it for schema changes, or telling people to ask.
> >>>>
> >>>> But I fear it will all begin to go to pot again after this effort
> >> wanes, and my life has only one JIRA cleanup effort to call upon.
> >>>>
> >>>>
> >>>>> On 26 Nov 2018, at 18:24, Joshua McKenzie <jmckenzie@xxxxxxxxxx>
> >> wrote:
> >>>>>
> >>>>> I'm thinking something like "Every 6 months, we query on labels with
> >> count
> >>>>>> = 4 and consider promoting those. Anything < that only shows if
> >> people are
> >>>>> specifically looking for it."
> >>>>>
> >>>>> Taking count of occurrence of a label as a proxy for the potential
> >> value in
> >>>>> promoting it to something hardened isn't without flaws, but it's also
> >> not
> >>>>> awful IMO.
> >>>>>
> >>>>>
> >>>>> On Mon, Nov 26, 2018 at 12:37 PM Benedict Elliott Smith <
> >> benedict@xxxxxxxxxx>
> >>>>> wrote:
> >>>>>
> >>>>>>> Is there harm in leaving them in, aside from psychologically to all
> >> of us
> >>>>>>> knowing they're there? =/
> >>>>>>
> >>>>>> It would at least make it easier to triage the ‘new' ones and
> promote
> >>>>>> them. The pain of actually categorising the labels was high, and
> doing
> >>>>>> that every time would mean it never happens (though maybe there are
> >> ways to
> >>>>>> work around this). I also think there’s value in shedding noisy
> data,
> >> in
> >>>>>> an active process to promote good hygiene.
> >>>>>>
> >>>>>> But who said our state of mind isn’t also important :)
> >>>>>>
> >>>>>> This isn’t something I’ll fight hard for, though, I can see it’s at
> >> least
> >>>>>> partially a preference for cleanliness. Interested to see what
> others
> >>>>>> think.
> >>>>>>
> >>>>>>> On 26 Nov 2018, at 17:28, Joshua McKenzie <jmckenzie@xxxxxxxxxx>
> >> wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>> An alternative route might be to support labels, and (e.g.)
> >> bi-annually
> >>>>>>>> promote any useful ones to the schema, and clear the rest?
> >>>>>>>
> >>>>>>> +1 to promoting, probably should case-by-case the clearing (but
> >> mostly
> >>>>>> just
> >>>>>>> clear)
> >>>>>>>
> >>>>>>> The present labels are much too painful to clean up. I categorised
> >> the
> >>>>>> top
> >>>>>>>> 100 or so, and will migrate them (there’s a CSV embedded in the
> >> proposal
> >>>>>>>> you can look at). The rest have < 5 occurrences, so I cannot see
> >> what
> >>>>>>>> value they really provide us.
> >>>>>>>
> >>>>>>> Is there harm in leaving them in, aside from psychologically to all
> >> of us
> >>>>>>> knowing they're there? =/
> >>>>>>>
> >>>>>>> I _think_ several of your concerns are addressed by the new Triage
> >> state.
> >>>>>>>> The idea is for users to create a ticket without any field
> >> requirements.
> >>>>>>>> Contributors should liaise with the user to understand the
> problem,
> >> and
> >>>>>>>> transition it to Open.
> >>>>>>>
> >>>>>>> Shit, my bad, totally missed / didn't grok that. That makes a lot
> >> more
> >>>>>>> sense.
> >>>>>>>
> >>>>>>> On Mon, Nov 26, 2018 at 11:58 AM Benedict Elliott Smith <
> >>>>>> benedict@xxxxxxxxxx>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Sorry, I failed to respond to point (2) in the aggregate email.
> >>>>>>>>
> >>>>>>>> I’m not sure it’s worth complicating the flow for this scenario,
> as
> >> the
> >>>>>>>> ticket can simply return to ‘Patch Available’. But, I’m really
> >> unsure
> >>>>>> of
> >>>>>>>> the best option here. Does anyone else have any strong opinions /
> >>>>>> thoughts?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On 26 Nov 2018, at 14:33, Sankalp Kohli <kohlisankalp@xxxxxxxxx>
> >>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> I have following initial comments on the proposal.
> >>>>>>>>> 1. Creating a JIRA should have few fields mandatory like
> platform,
> >>>>>>>> version, etc. We want to put less burden on someone creating a
> >> ticket
> >>>>>> but I
> >>>>>>>> feel these are required for opening bugs.
> >>>>>>>>>
> >>>>>>>>> 2. What is the flow when a non committer does the first pass of
> >> review?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> On Nov 26, 2018, at 7:46 PM, Joshua McKenzie <
> >> jmckenzie@xxxxxxxxxx>
> >>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> 1) Removal of labels: one of the strengths of the current model
> is
> >>>>>>>>>> flexibility for groupings of concepts to arise from a
> >> user-perspective
> >>>>>>>>>> (lhf, etc). Calcifying the label concepts into components,
> >> categories,
> >>>>>>>> etc.
> >>>>>>>>>> is a strict loss of functionality for users to express and
> >> categorize
> >>>>>>>> their
> >>>>>>>>>> concerns with the project. This feels like an over-correction to
> >> our
> >>>>>>>>>> current lack of discipline cleaning up one-off labels.
> >>>>>> Counter-proposal:
> >>>>>>>>>>
> >>>>>>>>>> 1. We beef up the categories and components as proposed and
> >> migrate
> >>>>>>>>>> labels to those
> >>>>>>>>>> 2. We remove the one-off labels that aren't adding value,
> >> considering
> >>>>>>>>>> aggregating similar labels
> >>>>>>>>>> 3. We leave the "labels" field intact, perhaps with a bit of
> >> guidance
> >>>>>>>> on
> >>>>>>>>>> how to effectively use it
> >>>>>>>>>>
> >>>>>>>>>> 2) Required fields on transition: assuming these are required
> upon
> >>>>>>>> *issue
> >>>>>>>>>> creation*, that's placing a significant burden on a user that's
> >> seen
> >>>>>>>>>> something and wants to open a ticket about it, but isn't sure if
> >> it's
> >>>>>> a
> >>>>>>>>>> "Semantic Failure" or a "Consistency Failure", for instance. If
> >> this
> >>>>>> is,
> >>>>>>>>>> instead, a field required for transition to other ticket states
> >> by the
> >>>>>>>>>> developer working on it, I think that makes sense.
> >>>>>>>>>>
> >>>>>>>>>> 3) Priority Changes: to be blunt, this looks like shuffling
> >> chairs on
> >>>>>>>> the
> >>>>>>>>>> deck of the titanic on this one - in my experience, most users
> >> aren't
> >>>>>>>> going
> >>>>>>>>>> to set the priority on tickets when they open them (hence
> default
> >> ==
> >>>>>>>> major
> >>>>>>>>>> and most tickets are opened as major), so this is something that
> >> will
> >>>>>> be
> >>>>>>>>>> either a) left alone so as not to offend those for whom the
> >> priority
> >>>>>> is
> >>>>>>>>>> *actually* major or consistent with the default, or b) changed
> by
> >> the
> >>>>>>>> dev
> >>>>>>>>>> anyway and the added signal from a new "High vs. Urgent"
> >> distinction
> >>>>>> and
> >>>>>>>>>> communication of developer intent to engage with a ticket is
> >> something
> >>>>>>>>>> that'll be lost on most users that are just reporting
> something. I
> >>>>>> don't
> >>>>>>>>>> have a meaningful counter-proposal at this point as the current
> >>>>>> problem
> >>>>>>>> is
> >>>>>>>>>> more about UX on this field than the signal / noise on the field
> >>>>>> itself
> >>>>>>>> IMO.
> >>>>>>>>>>
> >>>>>>>>>> A meta question about the "What and Why" of what we're trying to
> >>>>>>>> accomplish
> >>>>>>>>>> here: it sounds like what you're looking at is:
> >>>>>>>>>>
> >>>>>>>>>> 1. to capture more information
> >>>>>>>>>> 2. simplify the data entry
> >>>>>>>>>> 3. nudge people towards more complete and accurate data entry
> >>>>>>>>>> 4. our ability as a project to measure release quality over time
> >> and
> >>>>>>>>>> identify when Cassandra is ready for (or due a) release.
> >>>>>>>>>>
> >>>>>>>>>> The proposal in its current form makes certain strong inroads in
> >> all
> >>>>>> of
> >>>>>>>>>> those 4 metrics, but I think the major thing missing is the UX
> of
> >> what
> >>>>>>>>>> we're thinking about changing:
> >>>>>>>>>>
> >>>>>>>>>> 1. Making it easy for / reduce friction for users to report bugs
> >> and
> >>>>>>>>>> requests into the project JIRA (easy to do things right, hard to
> >> do
> >>>>>>>> things
> >>>>>>>>>> wrong) (current proposal is a +1 on "do things right", though
> I'd
> >>>>>> argue
> >>>>>>>>>> against it being *easy*)
> >>>>>>>>>> 2. Asking from the users what they can provide about their
> >> experience
> >>>>>>>>>> and issues and no more
> >>>>>>>>>>
> >>>>>>>>>> Philosophically, are we trying to make it easier for people that
> >> are
> >>>>>>>> paid
> >>>>>>>>>> FT to work on C*, are we trying to make things easier for
> *users*
> >> of
> >>>>>> C*,
> >>>>>>>>>> both, neither? Who are we targeting here w/these project changes
> >> and
> >>>>>>>> what
> >>>>>>>>>> of their issues / problems are we trying to improve?
> >>>>>>>>>>
> >>>>>>>>>> And lastly: the TLC and management of the JIRA aspects of this
> >> project
> >>>>>>>> have
> >>>>>>>>>> *definitely* languished (not pointing any fingers here, I'm *at
> >> least*
> >>>>>>>> as
> >>>>>>>>>> guilty as anyone on this :) ) - so a big thanks to you and
> >> whomever
> >>>>>>>> you've
> >>>>>>>>>> collaborate with in getting this conversation started!
> >>>>>>>>>>
> >>>>>>>>>> On Mon, Nov 26, 2018 at 8:39 AM Benedict Elliott Smith <
> >>>>>>>> benedict@xxxxxxxxxx>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> We’ve concluded our efforts to produce a proposal for changes
> to
> >> the
> >>>>>>>> JIRA
> >>>>>>>>>>> workflow, and they can be found here:
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>
> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
> >>>>>>>>>>> <
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>
> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> I hope there will be broad consensus, but I’m sure it won’t be
> >> plain
> >>>>>>>>>>> sailing. It would be great to get a discussion going around the
> >>>>>>>> proposal,
> >>>>>>>>>>> so please take some time to read and respond if you think
> you’ll
> >>>>>> have a
> >>>>>>>>>>> strong opinion on this topic.
> >>>>>>>>>>>
> >>>>>>>>>>> There remains an undecided question in our initial proposal,
> >> that is
> >>>>>>>>>>> highlighted in the wiki. Specifically, there was no seemingly
> >>>>>>>> objective
> >>>>>>>>>>> winner for the suggested changes to Component (though I have a
> >>>>>>>> preference,
> >>>>>>>>>>> that I will express in the ensuing discussion).
> >>>>>>>>>>>
> >>>>>>>>>>> Other contentious issues may be:
> >>>>>>>>>>> - The removal of ‘labels’ - which is very noisy, the vast
> >> majority of
> >>>>>>>>>>> which provide no value, and we expect can be superseded by
> other
> >>>>>>>> suggestions
> >>>>>>>>>>> - The introduction of required fields for certain transitions,
> >> some
> >>>>>> of
> >>>>>>>>>>> which are new (complexity, severity, bug/feature category)
> >>>>>>>>>>> - The introduction of some new transitions (Triage, Review in
> >>>>>> Progress,
> >>>>>>>>>>> Change Requested)
> >>>>>>>>>>>
> >>>>>>>>>>> Look forward to hearing your thoughts!
> >>>>>>>>>
> >>>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> >>>>>>>>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> >>>>>>>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> >>>>>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> >>>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> >>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> >>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> >> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> >>
> >>
>



-- 
Jon Haddad
http://www.rustyrazorblade.com
twitter: rustyrazorblade