curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McKenzie <mckenzie....@gmail.com>
Subject Re: CURATOR-217?
Date Wed, 26 Aug 2015 01:02:22 GMT
I have raised CURATOR-254 for this.

On Wed, Aug 26, 2015 at 10:41 AM, Cameron McKenzie <mckenzie.cam@gmail.com>
wrote:

> I've had a bit of a look at it and the test seems very fragile. It already
> has a bit of built in margin for error, but it relies on the consumers
> being able to consume messages off the queue faster than they are produced.
> If more than 20 messages end up on the queue at any time then test test
> fails.
>
> Anyway, I will raise a JIRA and we can discuss there.
>
> On Wed, Aug 26, 2015 at 9:29 AM, Cameron McKenzie <mckenzie.cam@gmail.com>
> wrote:
>
>> Thanks Mike,
>> On master. I'll have a bit of a look into it and let you know. I think
>> that it's a race condition based on how the test is structured.
>> cheers
>>
>> On Wed, Aug 26, 2015 at 9:18 AM, Mike Drob <madrob@cloudera.com> wrote:
>>
>>> Is this on 3.0 or master? Can you create a JIRA with some log output?
>>>
>>> On Tue, Aug 25, 2015 at 6:15 PM, Cameron McKenzie <
>>> mckenzie.cam@gmail.com>
>>> wrote:
>>>
>>> > Is anyone seeing fairly consistent failure of the
>>> >
>>> > TestBoundedDistributedQueue.testMulti:184
>>> >
>>> > test? When I run from inside eclipse in isolation it seems ok, but
>>> running
>>> > a 'mvn test' seems to fail on this test with some consistency. The
>>> changes
>>> > for CURATOR-167 certainly haven't caused this to happen.
>>> > cheers
>>> >
>>> > On Wed, Aug 26, 2015 at 7:45 AM, Cameron McKenzie <
>>> mckenzie.cam@gmail.com>
>>> > wrote:
>>> >
>>> > > Thanks Scott,
>>> > > I will merge into master.
>>> > > cheers
>>> > >
>>> > > On Wed, Aug 26, 2015 at 1:00 AM, Scott Blum <dragonsinth@gmail.com>
>>> > wrote:
>>> > >
>>> > >> Yep, that looks perfect.  Is CURATOR-167 done?  If so, we can just
>>> > >> fast-foward merge it into master now.
>>> > >>
>>> > >> On Tue, Aug 25, 2015 at 12:11 AM, Cameron McKenzie <
>>> > >> mckenzie.cam@gmail.com>
>>> > >> wrote:
>>> > >>
>>> > >> > Thanks Scott,
>>> > >> > Done, would you mind checking the origin/CURATOR-167 to make
sure
>>> > that I
>>> > >> > haven't done anything wrong! I have done a git pull on a different
>>> > >> machine
>>> > >> > and it seems to be ok.
>>> > >> > cheers
>>> > >> >
>>> > >> > On Tue, Aug 25, 2015 at 1:49 PM, Scott Blum <
>>> dragonsinth@gmail.com>
>>> > >> wrote:
>>> > >> >
>>> > >> > > You just force push your branch.
>>> > >> > >
>>> > >> > > If it's your feature branch, and you know you have it
in a good
>>> > state
>>> > >> > > locally, you can just force push the remote branch into
the same
>>> > >> state.
>>> > >> > >
>>> > >> > > You'd never want to do that to master, a release branch,
or
>>> someone
>>> > >> > else's
>>> > >> > > branch.
>>> > >> > > On Aug 24, 2015 11:15 PM, "Cameron McKenzie" <
>>> > mckenzie.cam@gmail.com>
>>> > >> > > wrote:
>>> > >> > >
>>> > >> > > > Thanks Mike,
>>> > >> > > > That was a good description. The CURATOR-167 branch
is
>>> definitely
>>> > >> there
>>> > >> > > as
>>> > >> > > > it's been a pull request for the last few months.
So, I'll
>>> await
>>> > >> your
>>> > >> > > > thoughts in the morning. Alternatively, I can just
merge
>>> master
>>> > >> instead
>>> > >> > > of
>>> > >> > > > rebasing it.
>>> > >> > > >
>>> > >> > > > On Tue, Aug 25, 2015 at 1:00 PM, Mike Drob <
>>> madrob@cloudera.com>
>>> > >> > wrote:
>>> > >> > > >
>>> > >> > > > > Yea, that's the big downside with rebasing,
is that remotes
>>> > don't
>>> > >> > > exactly
>>> > >> > > > > keep up with the history. I'm going to try
to explain this
>>> as
>>> > best
>>> > >> > as I
>>> > >> > > > > can, but usually I point people towards this
excellent "Git
>>> for
>>> > >> Ages
>>> > >> > 4
>>> > >> > > > and
>>> > >> > > > > Up" video https://www.youtube.com/watch?v=1ffBJ4sVUb4
- he
>>> > talks
>>> > >> > about
>>> > >> > > > > rebases at the very very end, around the 1:30
mark.
>>> > >> > > > >
>>> > >> > > > > Essentially, your current version of the branch
does not
>>> have
>>> > the
>>> > >> > > remote
>>> > >> > > > > version of the as an ancestor. Which is correct,
when you
>>> did
>>> > the
>>> > >> > > rebase,
>>> > >> > > > > you wrote a new commit lineage.
>>> > >> > > > >
>>> > >> > > > > I didn't realize that there was already a CURATOR-167
branch
>>> > >> pushed
>>> > >> > to
>>> > >> > > > the
>>> > >> > > > > repo when I gave you those steps. I'll have
to look at
>>> what's
>>> > >> going
>>> > >> > on
>>> > >> > > > with
>>> > >> > > > > a fresh set of eyes in the morning.
>>> > >> > > > >
>>> > >> > > > > On Mon, Aug 24, 2015 at 8:37 PM, Cameron McKenzie
<
>>> > >> > > > mckenzie.cam@gmail.com>
>>> > >> > > > > wrote:
>>> > >> > > > >
>>> > >> > > > > > I just tried this and obviously I'm doing
something wrong.
>>> > >> > > > > >
>>> > >> > > > > > git checkout CURATOR-167
>>> > >> > > > > > git pull
>>> > >> > > > > > git rebase -i origin/master
>>> > >> > > > > >
>>> > >> > > > > > #This gives me a dialog with one commit
with pick
>>> > >> > > > > > Save and exit
>>> > >> > > > > > #This gives a merge conflict and leaves
me in a detached
>>> head
>>> > >> state
>>> > >> > > (I
>>> > >> > > > > > presume this is ok).
>>> > >> > > > > > Fix up the merge conflict
>>> > >> > > > > > git rebase --continue
>>> > >> > > > > > #This gives me a dialog to commit the
changes
>>> > >> > > > > > Save and exit
>>> > >> > > > > > #Everything seems fine at this point.
Builds ok, tests
>>> run ok.
>>> > >> > > > > >
>>> > >> > > > > > git push
>>> > >> > > > > >
>>> > >> > > > > >  ! [rejected]        CURATOR-167 ->
CURATOR-167
>>> > >> (non-fast-forward)
>>> > >> > > > > > error: failed to push some refs to '
>>> > >> > > > > > https://git-wip-us.apache.org/repos/asf/curator.git'
>>> > >> > > > > > hint: Updates were rejected because the
tip of your
>>> current
>>> > >> branch
>>> > >> > is
>>> > >> > > > > > behind
>>> > >> > > > > > hint: its remote counterpart. Integrate
the remote changes
>>> > (e.g.
>>> > >> > > > > > hint: 'git pull ...') before pushing again.
>>> > >> > > > > > hint: See the 'Note about fast-forwards'
in 'git push
>>> --help'
>>> > >> for
>>> > >> > > > > details.
>>> > >> > > > > >
>>> > >> > > > > > There have been no changes on the branch
since I did the
>>> pull
>>> > >> > before
>>> > >> > > > the
>>> > >> > > > > > rebase.
>>> > >> > > > > >
>>> > >> > > > > > Any ideas?
>>> > >> > > > > >
>>> > >> > > > > >
>>> > >> > > > > >
>>> > >> > > > > >
>>> > >> > > > > >
>>> > >> > > > > >
>>> > >> > > > > > On Tue, Aug 25, 2015 at 8:48 AM, Cameron
McKenzie <
>>> > >> > > > > mckenzie.cam@gmail.com>
>>> > >> > > > > > wrote:
>>> > >> > > > > >
>>> > >> > > > > > > Thanks Mike,
>>> > >> > > > > > > Will give it a spin today some time.
>>> > >> > > > > > > cheers
>>> > >> > > > > > >
>>> > >> > > > > > > On Tue, Aug 25, 2015 at 8:36 AM,
Mike Drob <
>>> > >> madrob@cloudera.com>
>>> > >> > > > > wrote:
>>> > >> > > > > > >
>>> > >> > > > > > >> if you're going to tray that,
here's what you want to
>>> do
>>> > >> > (assuming
>>> > >> > > > > > command
>>> > >> > > > > > >> line)
>>> > >> > > > > > >>
>>> > >> > > > > > >> git checkout CURATOR-167 # start
with the branch that
>>> you
>>> > are
>>> > >> > > > changing
>>> > >> > > > > > >> git rebase -i master # rebase
the current branch on
>>> top of
>>> > >> the
>>> > >> > > given
>>> > >> > > > > > >> branch
>>> > >> > > > > > >>
>>> > >> > > > > > >> On Mon, Aug 24, 2015 at 5:07
PM, Cameron McKenzie <
>>> > >> > > > > > mckenzie.cam@gmail.com
>>> > >> > > > > > >> >
>>> > >> > > > > > >> wrote:
>>> > >> > > > > > >>
>>> > >> > > > > > >> > Scott,
>>> > >> > > > > > >> > I've been using a similar
approach to Jordan given
>>> that's
>>> > >> what
>>> > >> > > I'm
>>> > >> > > > > > used
>>> > >> > > > > > >> to,
>>> > >> > > > > > >> > but I'm happy to try your
approach. I'm going to try
>>> and
>>> > >> fix
>>> > >> > up
>>> > >> > > > > > >> CURATOR-167
>>> > >> > > > > > >> > as it will no longer cleanly
merge (it's been sitting
>>> > >> there a
>>> > >> > > > > while).
>>> > >> > > > > > >> So, I
>>> > >> > > > > > >> > should rebase master into
the CURATOR-167 branch?
>>> > >> > > > > > >> > cheers
>>> > >> > > > > > >> >
>>> > >> > > > > > >> > On Tue, Aug 25, 2015 at
2:55 AM, Scott Blum <
>>> > >> > > > dragonsinth@apache.org
>>> > >> > > > > >
>>> > >> > > > > > >> > wrote:
>>> > >> > > > > > >> >
>>> > >> > > > > > >> > > LOL!  So sorry to hear
that.  Yeah, it's definitely
>>> > >> possible
>>> > >> > > to
>>> > >> > > > > mess
>>> > >> > > > > > >> > > things up badly.  If
I'm doing something
>>> particularly
>>> > >> risky,
>>> > >> > > > I'll
>>> > >> > > > > > just
>>> > >> > > > > > >> > "git
>>> > >> > > > > > >> > > branch original" before
I start, so as to leave a
>>> > branch
>>> > >> > > pointer
>>> > >> > > > > at
>>> > >> > > > > > my
>>> > >> > > > > > >> > > start point as a safe
recovery if it goes south.  I
>>> > also
>>> > >> use
>>> > >> > > > gitk
>>> > >> > > > > to
>>> > >> > > > > > >> > > visualize sometimes.
>>> > >> > > > > > >> > >
>>> > >> > > > > > >> > > Another major selling
point for rebase (-i) is that
>>> > it's
>>> > >> > > > *really*
>>> > >> > > > > > >> hard to
>>> > >> > > > > > >> > > merge the wrong branch.
 If the list of commits
>>> that
>>> > >> comes
>>> > >> > up
>>> > >> > > > > > doesn't
>>> > >> > > > > > >> > look
>>> > >> > > > > > >> > > basically correct,
you probably did something
>>> wrong--
>>> > >> trying
>>> > >> > > to
>>> > >> > > > > > rebase
>>> > >> > > > > > >> > onto
>>> > >> > > > > > >> > > the wrong branch will
give you tons of commits,
>>> most of
>>> > >> > which
>>> > >> > > > > aren't
>>> > >> > > > > > >> > yours.
>>> > >> > > > > > >> > >
>>> > >> > > > > > >> > > I think what you've
been doing is fine, it's
>>> definitely
>>> > >> the
>>> > >> > > > right
>>> > >> > > > > > >> > approach
>>> > >> > > > > > >> > > if you're doing a merge
strategy!  I've just ended
>>> up
>>> > >> > > > gravitating
>>> > >> > > > > > to a
>>> > >> > > > > > >> > > rebase strategy over
the years for the reasons I've
>>> > >> > mentioned.
>>> > >> > > > > > >> > >
>>> > >> > > > > > >> > > On Mon, Aug 24, 2015
at 12:43 PM, Jordan Zimmerman
>>> <
>>> > >> > > > > > >> > > jordan@jordanzimmerman.com>
wrote:
>>> > >> > > > > > >> > >
>>> > >> > > > > > >> > >> I’ll admit that
rebase terrifies me. I’ve f’d up
>>> > several
>>> > >> > > > projects
>>> > >> > > > > > >> with
>>> > >> > > > > > >> > it
>>> > >> > > > > > >> > >> so I can’t even
type the letters without breaking
>>> > into a
>>> > >> > > sweat.
>>> > >> > > > > > "git
>>> > >> > > > > > >> > rebase
>>> > >> > > > > > >> > >> -i” is a lot
safer, though. Here’s what I’ve been
>>> > doing
>>> > >> -
>>> > >> > let
>>> > >> > > > me
>>> > >> > > > > > >> know if
>>> > >> > > > > > >> > >> it’s OK. For
branches that are off of
>>> CURATOR-3.0, I
>>> > >> never
>>> > >> > > > merge
>>> > >> > > > > > >> > master. I
>>> > >> > > > > > >> > >> only merge CURATOR-3.0:
“git merge CURATOR-3.0”.
>>> In
>>> > >> fact,
>>> > >> > > > should
>>> > >> > > > > we
>>> > >> > > > > > >> > have a
>>> > >> > > > > > >> > >> branch naming scheme
to enforce this?
>>> > >> > > > > > >> > >>
>>> > >> > > > > > >> > >> -Jordan
>>> > >> > > > > > >> > >>
>>> > >> > > > > > >> > >>
>>> > >> > > > > > >> > >>
>>> > >> > > > > > >> > >> On August 24, 2015
at 11:30:50 AM, Scott Blum (
>>> > >> > > > > > >> dragonsinth@apache.org)
>>> > >> > > > > > >> > >> wrote:
>>> > >> > > > > > >> > >>
>>> > >> > > > > > >> > >> Correct. When I
say "main" branch vs. "feature"
>>> > branch I
>>> > >> > just
>>> > >> > > > > mean
>>> > >> > > > > > >> the
>>> > >> > > > > > >> > >> stable branch everyone
is working against (3.0 or
>>> > >> master)
>>> > >> > > vs. a
>>> > >> > > > > > >> feature
>>> > >> > > > > > >> > >> branch where you're
actively working.
>>> > >> > > > > > >> > >>
>>> > >> > > > > > >> > >> You'll get to a
point in development where you'll
>>> > think
>>> > >> > "Hey,
>>> > >> > > > > there
>>> > >> > > > > > >> are
>>> > >> > > > > > >> > >> changes on the
main branch I'm working against
>>> that I
>>> > >> > really
>>> > >> > > > need
>>> > >> > > > > > to
>>> > >> > > > > > >> > pull
>>> > >> > > > > > >> > >> into my feature
branch." At that point
>>> (particularly
>>> > if
>>> > >> you
>>> > >> > > > have
>>> > >> > > > > an
>>> > >> > > > > > >> svn
>>> > >> > > > > > >> > >> background) you'll
be tempted to merge the main
>>> branch
>>> > >> into
>>> > >> > > > your
>>> > >> > > > > > >> feature
>>> > >> > > > > > >> > >> branch. I would
suggest not doing that, as it
>>> makes
>>> > the
>>> > >> > > history
>>> > >> > > > > > very
>>> > >> > > > > > >> > muddy
>>> > >> > > > > > >> > >> to follow. Instead,
my workflow is usually more
>>> like
>>> > >> this:
>>> > >> > > > > > >> > >>
>>> > >> > > > > > >> > >> Suppose I'm working
on CURATOR-218. It was
>>> originally
>>> > >> > > branched
>>> > >> > > > > off
>>> > >> > > > > > >> 3.0,
>>> > >> > > > > > >> > >> and I want to pull
in new changes.
>>> > >> > > > > > >> > >>
>>> > >> > > > > > >> > >> git remote update
>>> > >> > > > > > >> > >> git rebase -i origin/CURATOR-3.0
>>> > >> > > > > > >> > >>
>>> > >> > > > > > >> > >> This pulls up an
editor that gives me the list of
>>> > >> commits
>>> > >> > to
>>> > >> > > > > > rebase.
>>> > >> > > > > > >> I
>>> > >> > > > > > >> > >> would typically
exit out of the editor to at this
>>> > point
>>> > >> to
>>> > >> > > > accept
>>> > >> > > > > > the
>>> > >> > > > > > >> > >> commit list, but
if I'm so inclined, I'll do
>>> things
>>> > like
>>> > >> > > > reorder
>>> > >> > > > > > the
>>> > >> > > > > > >> > list,
>>> > >> > > > > > >> > >> or squash commits
like like "wip" or "minor
>>> reformat"
>>> > >> into
>>> > >> > a
>>> > >> > > > more
>>> > >> > > > > > >> > curated
>>> > >> > > > > > >> > >> set of logical
commits.
>>> > >> > > > > > >> > >>
>>> > >> > > > > > >> > >> Once you exit the
editor, git goes through and
>>> applies
>>> > >> each
>>> > >> > > > > commit,
>>> > >> > > > > > >> one
>>> > >> > > > > > >> > at
>>> > >> > > > > > >> > >> a time, to the
head of the target branch. It's
>>> like
>>> > >> picking
>>> > >> > > up
>>> > >> > > > > your
>>> > >> > > > > > >> > commit
>>> > >> > > > > > >> > >> chain and dumping
it at the end of the target
>>> branch,
>>> > >> as if
>>> > >> > > all
>>> > >> > > > > > your
>>> > >> > > > > > >> > work
>>> > >> > > > > > >> > >> had been done against
what's now the head of that
>>> > >> branch.
>>> > >> > > > You'll
>>> > >> > > > > > may
>>> > >> > > > > > >> > have
>>> > >> > > > > > >> > >> to fix conflicts
along the way, but usually not
>>> much
>>> > >> more
>>> > >> > > than
>>> > >> > > > if
>>> > >> > > > > > you
>>> > >> > > > > > >> > did
>>> > >> > > > > > >> > >> it as a merge.
>>> > >> > > > > > >> > >>
>>> > >> > > > > > >> > >> I'd encourage us
to try this out a couple times
>>> and
>>> > get
>>> > >> a
>>> > >> > > feel
>>> > >> > > > > for
>>> > >> > > > > > >> the
>>> > >> > > > > > >> > >> rebase flow. It's
a little more to get your head
>>> > around
>>> > >> at
>>> > >> > > > first,
>>> > >> > > > > > but
>>> > >> > > > > > >> > the
>>> > >> > > > > > >> > >> upside is you end
up with really easy to follow
>>> commit
>>> > >> > > > histories,
>>> > >> > > > > > >> which
>>> > >> > > > > > >> > >> makes it way easier
to untangle problems later if
>>> they
>>> > >> crop
>>> > >> > > up.
>>> > >> > > > > > >> > >>
>>> > >> > > > > > >> > >> On Mon, Aug 24,
2015 at 12:17 PM, Jordan
>>> Zimmerman <
>>> > >> > > > > > >> > >> jordan@jordanzimmerman.com>
wrote:
>>> > >> > > > > > >> > >>
>>> > >> > > > > > >> > >> > Can you explain
this in detail? For me, I have
>>> some
>>> > >> > > features
>>> > >> > > > > that
>>> > >> > > > > > >> are
>>> > >> > > > > > >> > >> > 3.0.0 based
so I’m treating CURATOR-3.0 as a
>>> kind of
>>> > >> > > master.
>>> > >> > > > > The
>>> > >> > > > > > >> true
>>> > >> > > > > > >> > >> > “master”
is Curator 2.x only, right?
>>> > >> > > > > > >> > >> >
>>> > >> > > > > > >> > >> > -Jordan
>>> > >> > > > > > >> > >> >
>>> > >> > > > > > >> > >> >
>>> > >> > > > > > >> > >> >
>>> > >> > > > > > >> > >> > On August
24, 2015 at 11:10:08 AM, Scott Blum (
>>> > >> > > > > > >> dragonsinth@apache.org
>>> > >> > > > > > >> > )
>>> > >> > > > > > >> > >> > wrote:
>>> > >> > > > > > >> > >> >
>>> > >> > > > > > >> > >> > BTW: I noticed
a couple of new commits
>>> > >> > > > > > >> > >> > (ba4b5d8cb1f9733d3901b0b619528454d3dbf8c8
>>> > >> > > > > > >> > >> > & 2343daf29388566b0efa0b0a2ad21574fb534a27)
>>> where
>>> > 3.0
>>> > >> is
>>> > >> > > > > getting
>>> > >> > > > > > >> > merged
>>> > >> > > > > > >> > >> > into feature
branches. Almost every project I've
>>> > been
>>> > >> on
>>> > >> > we
>>> > >> > > > > don't
>>> > >> > > > > > >> tend
>>> > >> > > > > > >> > >> to
>>> > >> > > > > > >> > >> > do that as
it leads to confusing history (this
>>> isn't
>>> > >> just
>>> > >> > > > > > >> aesthetic,
>>> > >> > > > > > >> > it
>>> > >> > > > > > >> > >> > can
>>> > >> > > > > > >> > >> > get harder
for tooling to figure out what
>>> happened).
>>> > >> If I
>>> > >> > > > want
>>> > >> > > > > to
>>> > >> > > > > > >> pull
>>> > >> > > > > > >> > >> > changes from
the main branch into my feature
>>> > branch, I
>>> > >> > > would
>>> > >> > > > > > >> typically
>>> > >> > > > > > >> > >> > *rebase* my
feature branch against the main
>>> branch.
>>> > >> > > > > > >> > >> >
>>> > >> > > > > > >> > >> > On Mon, Aug
24, 2015 at 12:05 PM, Scott Blum <
>>> > >> > > > > > >> dragonsinth@apache.org>
>>> > >> > > > > > >> > >> > wrote:
>>> > >> > > > > > >> > >> >
>>> > >> > > > > > >> > >> > > Yeah,
217 & 161 were the first two big things
>>> in
>>> > >> 3.0.
>>> > >> > > > > > >> > >> > >
>>> > >> > > > > > >> > >> > > On Mon,
Aug 24, 2015 at 9:53 AM, Jordan
>>> Zimmerman
>>> > <
>>> > >> > > > > > >> > >> > > jordan@jordanzimmerman.com>
wrote:
>>> > >> > > > > > >> > >> > >
>>> > >> > > > > > >> > >> > >> OK
- Also, is CURATOR-161 complete? The
>>> issue is
>>> > >> still
>>> > >> > > > open
>>> > >> > > > > in
>>> > >> > > > > > >> > Jira.
>>> > >> > > > > > >> > >> > >>
>>> > >> > > > > > >> > >> > >>
>>> > >> > > > > > >> > >> > >>
>>> > >> > > > > > >> > >> > >> On
August 24, 2015 at 12:47:21 AM, Cameron
>>> > >> McKenzie (
>>> > >> > > > > > >> > >> > >> mckenzie.cam@gmail.com)
wrote:
>>> > >> > > > > > >> > >> > >>
>>> > >> > > > > > >> > >> > >> Yes,
I merged it in last week some time.
>>> > >> > > > > > >> > >> > >>
>>> > >> > > > > > >> > >> > >> On
Mon, Aug 24, 2015 at 3:25 PM, Jordan
>>> > Zimmerman <
>>> > >> > > > > > >> > >> > >> jordan@jordanzimmerman.com>
wrote:
>>> > >> > > > > > >> > >> > >>
>>> > >> > > > > > >> > >> > >> >
Scott, did CURATOR-217 get merged into the
>>> new
>>> > >> > > > > CURATOR-3.0?
>>> > >> > > > > > >> > >> > >> >
>>> > >> > > > > > >> > >> > >> >
-Jordan
>>> > >> > > > > > >> > >> > >> >
>>> > >> > > > > > >> > >> > >> >
>>> > >> > > > > > >> > >> > >> >
>>> > >> > > > > > >> > >> > >>
>>> > >> > > > > > >> > >> > >
>>> > >> > > > > > >> > >> > >
>>> > >> > > > > > >> > >> >
>>> > >> > > > > > >> > >> >
>>> > >> > > > > > >> > >>
>>> > >> > > > > > >> > >
>>> > >> > > > > > >> > >
>>> > >> > > > > > >> >
>>> > >> > > > > > >>
>>> > >> > > > > > >
>>> > >> > > > > > >
>>> > >> > > > > >
>>> > >> > > > >
>>> > >> > > >
>>> > >> > >
>>> > >> >
>>> > >>
>>> > >
>>> > >
>>> >
>>>
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message