storm-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Li <ethanopensou...@gmail.com>
Subject Re: [DISCUSS] Next 2.x release
Date Mon, 12 Aug 2019 13:15:36 GMT
Just in case if anyone happens to know the answer:

I created a branch https://github.com/apache/storm/tree/2.1.x-branch <https://github.com/apache/storm/tree/2.1.x-branch>
and ran “mvn:prepare” and “mvn:perform”. It created two commits and created a v2.1.0
git tag. But I realized that the pom version under storm-dist was not updated and it’s still
2.0.1-SNAPSHOT. I checked the commits in other tags like https://github.com/apache/storm/commits/v2.0.0
<https://github.com/apache/storm/commits/v2.0.0> and it looks like storm-dist got updated
within the “mvn:prepare” step.  How do I get storm-dist pom version updated with “mv:prepare”?

I am currently blocked on this. Any help will be appreciated.

Thanks,
Ethan


> On Aug 12, 2019, at 2:38 AM, Stig Rohde Døssing <stigdoessing@gmail.com> wrote:
> 
> Sounds good Ethan.
> 
> Derek, I also think being clear about how long we expect to support a
> release line is a good idea. Maybe we should do a separate discuss thread
> on this, or if you already have a good idea for what the policy should look
> like you could put it up as a PR for either the Downloads page or a new
> page on the Storm site?
> 
> Den søn. 11. aug. 2019 kl. 08.37 skrev Ethan Li <ethanopensource@gmail.com>:
> 
>> I am doing the release following
>> https://github.com/apache/storm/blob/master/RELEASING.md <
>> https://github.com/apache/storm/blob/master/RELEASING.md> . I made some
>> progress but I have some questions so I just sent an email to Taylor.
>> 
>> Please don’t merge anything to master or 2.1.x-branch for now. Thanks
>> 
>> Best,
>> Ethan
>> 
>> 
>>> On Aug 9, 2019, at 4:45 PM, Ethan Li <ethanopensource@gmail.com> wrote:
>>> 
>>> Currently we have two outstanding PRs that we wanted to include in the
>> new release:
>>> 
>>> https://github.com/apache/storm/pull/3096 <
>> https://github.com/apache/storm/pull/3096> (Travis has some issues
>> connecting to repository.apache.org <http://repository.apache.org/>
>> recently. Travis build fails consistently)
>>> https://github.com/apache/storm/pull/2878 <
>> https://github.com/apache/storm/pull/2878> (Some comments are to be
>> addressed but Author hasn’t responded yet.)
>>> 
>>> It’s not absolutely necessary to include them in this new release so I
>> think I should move forward with the release process. These two and other
>> PRs can be included in the next release.
>>> 
>>> For the release, I will create a new branch 2.1.x-branch based on
>> current master branch, and release 2.1.0 from there.   I will then move
>> master to 2.2.0-SNAPSHOT.  Please let me know if there is any objections.
>>> 
>>> Thanks,
>>> Ethan
>>> 
>>> 
>>>> On Aug 9, 2019, at 2:53 PM, Derek Dagit <dagit@apache.org <mailto:
>> dagit@apache.org>> wrote:
>>>> 
>>>>> We might not able to say how long we want to support a specific
>>>>> release line but I would love to see a clear release policy being
>>>>> made.
>>>> 
>>>> That makes sense. It seems better for us not to choose a specific
>>>> calendar date or duration of time.
>>>> 
>>>> - We do not want too many release lines supported concurrently.
>>>> - We want devs and users to know what to expect.
>>>> 
>>>> --
>>>> Derek
>>>> 
>>>> On Fri, Aug 09, 2019 at 10:32:59AM -0500, Ethan Li wrote:
>>>>> 
>>>>> Derek,
>>>>> 
>>>>> I think it’s a good idea to be more clear on the versioning and
>> release process so users and developers know what to expect. We might not
>> able to say how long we want to support a specific release line but I would
>> love to see a clear release policy being made.
>>>>> 
>>>>> Thanks,
>>>>> Ethan
>>>>> 
>>>>>> On Aug 9, 2019, at 8:53 AM, Derek Dagit <dagit@apache.org <mailto:
>> dagit@apache.org>> wrote:
>>>>>> 
>>>>>> On Fri, Aug 09, 2019 at 02:35:57PM +0200, Stig Rohde Døssing wrote:
>>>>>>> Where on the Traffic Server page do they list how long their
release
>>>>>>> trains survive? I only see dates of release, not how long e.g.
7.x is
>>>>>>> supposed to receive support.  Derek,
>>>>>> 
>>>>>> This is a better link:
>> https://cwiki.apache.org/confluence/display/TS/Release+Management <
>> https://cwiki.apache.org/confluence/display/TS/Release+Management>
>>>>>> 
>>>>>> This example, where "RM" means "Release Manager":
>>>>>> 
>>>>>>> 1. We promise to make 1 major release / year, but the RM and
>> community
>>>>>>> can of course make more as necessary
>>>>>>> 
>>>>>>> 2. We only make releases off the LTS branches, which are cut
once a
>>>>>>> year off master
>>>>>>> 
>>>>>>> 3. Master is always open, for any type of change (including
>>>>>>> incompatible changes). But don't break compatibility just for
fun!
>>>>>>> 
>>>>>>> 4. Master is always stable, i.e. commits should be properly tested
>> and
>>>>>>> reviewed before committed to master.
>>>>>>> 
>>>>>>> 5. All releases are stable releases, following strict Semantic
>>>>>>> Versioning.
>>>>>>> 
>>>>>>> 6. Minor releases are made at the discretion at the discretion
of the
>>>>>>> community and the RM.
>>>>>>> 
>>>>>>> 7. Minor releases can include new (small / safe) features, but
must
>> be
>>>>>>> compatible within the LTS major version.
>>>>>>> 
>>>>>>> 8. The LTS cycle, 2 years + 6 months Sunset, does not reset when
we
>>>>>>>  make a minor release.
>>>>>> 
>>>>>> 
>>>>>> Now, I am not proposing we do exactly this. The goal would be to
set
>>>>>> expectations among developers and the community, and here is one
>>>>>> concrete example of how it could be done.
>>>>>> 
>>>>>>> If we're going to promise that a release line survives for a
given
>>>>>>> amount of time, I think we should do it at the major version
level
>>>>>>> only
>>>>>> 
>>>>>> Yeah, that sounds reasonable to me. If we choose to commit to
>> something
>>>>>> like the above, we should base the decision in part on what kind
of
>>>>>> resources we have so that we do not over-commit.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> Den fre. 9. aug. 2019 kl. 00.15 skrev Derek Dagit <dagit@apache.org
>> <mailto:dagit@apache.org>>:
>>>>>>> 
>>>>>>>> What do we think about defining Long-Term Support branches
with a
>> fixed
>>>>>>>> period of support?
>>>>>>>> 
>>>>>>>> For example, we could say 2.0.x is an LTS release line with
support
>>>>>>>> ending no earlier than a certain calendar date.
>>>>>>>> 
>>>>>>>> The date could be extended, and it might ultimately be governed
by
>> the
>>>>>>>> timing of the subsequent release (e.g., 2.1.x or 3.0.x).
Keeping
>> things
>>>>>>>> clear would imply semantic versioning as mentioned earlier
>>>>>>>> (https://semver.org/ <https://semver.org/>).
>>>>>>>> 
>>>>>>>> Apache Traffic Server does something like this, to name one
project:
>>>>>>>> 
>>>>>>>> https://trafficserver.apache.org/downloads <
>> https://trafficserver.apache.org/downloads>
>>>>>>>> 
>>>>>>>> Having a regular cadence of releases might also help make
the
>> process
>>>>>>>> easier and help set expectations for users and devs.
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Derek
>>>>>>>> 
>>>>>>>> On Thu, Aug 08, 2019 at 02:50:07PM -0500, Ethan Li wrote:
>>>>>>>>> 
>>>>>>>>> Currently we don’t have a 2.0.x-branch and master is
actually
>>>>>>>> “2.0.1-SNAPSHOT”.
>>>>>>>>> 
>>>>>>>>> So if we  do a 2.1.0 release,  we will create a 2.1.x-branch
based
>> on
>>>>>>>> current master, release from there. And we change master
to
>>>>>>>> “2.2.0-SNAPSHOT”.
>>>>>>>>> 
>>>>>>>>> But we will have one problem: we will lose 2.0.x release
line.
>>>>>>>>> 
>>>>>>>>> There are two things I can do:
>>>>>>>>> 
>>>>>>>>> 1) create a 2.0.x-branch based on v2.0.0 tag.
>>>>>>>>> 
>>>>>>>>> 2) ignore it. If there is an issue with 2.0.x release,
 ask users
>> to
>>>>>>>> upgrade to 2.1.0.
>>>>>>>>> 
>>>>>>>>> I prefer 1) but not sure if it’s the right way to make
things
>> right. Or
>>>>>>>> please let me know if I misunderstood something and it’s
not an
>> issue.
>>>>>>>>> 
>>>>>>>>> Btw, I am seeing the same issue with 1.x-branch. We shouldn’t
have
>>>>>>>> 1.x-branch. Instead, we should have 1.2.x-branch. But this
is not a
>> problem
>>>>>>>> since we will not release 1.3.x.
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Ethan
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On Aug 7, 2019, at 10:43 AM, Ethan Li <ethanopensource@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Yes thanks.
>>>>>>>>>> 
>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing
<
>>>>>>>> stigdoessing@gmail.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Sounds great. Remember to add your key to
>>>>>>>>>>> https://dist.apache.org/repos/dist/release/storm/KEYS,
you
>> should be
>>>>>>>> able
>>>>>>>>>>> to update it with an SVN client. See also
>>>>>>>>>>> https://www.apache.org/dev/openpgp.html#update.
>>>>>>>>>>> 
>>>>>>>>>>> Den ons. 7. aug. 2019 kl. 15.05 skrev Ethan Li
<
>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>> 
>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call
<bcall@apache.org
>> <mailto:
>>>>>>>>>>>> bcall@apache.org>> (Thanks to him).
>>>>>>>>>>>> 
>>>>>>>>>>>> My pgp key:
>>>>>>>>>>>> 
>>>>>>>> 
>> http://pgp.surfnet.nl/pks/lookup?op=vindex&fingerprint=on&search=0xA4A672F11B5050C8
>>>>>>>>>>>> <
>>>>>>>>>>>> 
>>>>>>>> 
>> http://pgp.surfnet.nl/pks/lookup?op=vindex&fingerprint=on&search=0xA4A672F11B5050C8
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> My understanding is that I am good to do
release with this key
>> now.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Here is a list of PRs that we might want
to include in the new
>>>>>>>> release:
>>>>>>>>>>>> 
>>>>>>>>>>>> https://github.com/apache/storm/pull/3098
<
>>>>>>>>>>>> https://github.com/apache/storm/pull/3098>
>>>>>>>>>>>> https://github.com/apache/storm/pull/3096
<
>>>>>>>>>>>> https://github.com/apache/storm/pull/3096>
>>>>>>>>>>>> https://github.com/apache/storm/pull/2878
<
>>>>>>>>>>>> https://github.com/apache/storm/pull/2878>
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Please review if you get a chance.  Thanks
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Ethan
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> On Aug 1, 2019, at 4:19 AM, Stig Rohde
Døssing <
>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev
Ethan Li <
>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> It’s a good point. I will start
a discussion thread for it.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> For the new release, I went through
the list:
>>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>> 
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20fixVersion%20%3D%202.0.1
>>>>>>>>>>>>>> <
>>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>> 
>> https://issues.apache.org/jira/issues/?jql=project%20=%20STORM%20AND%20fixVersion%20=%202.0.1
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> We introduced some new functionalities,
including
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-2720
<
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-2720>
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3412
<
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3412>
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3411
<
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3411>
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3442
<
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3442>
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3396
<
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3396>
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3392
<
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3392>
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3395
<
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3395>
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> So I think we should release 2.1.0
rather than 2.0.1.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> There are a few pull requests we
may want to review before
>> the next
>>>>>>>>>>>>>> release:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3094
<
>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3094>
>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2990
<
>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2990>
>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878
<
>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878>
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Ethan
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Jul 29, 2019, at 10:11 AM,
Hugo Louro <hmclouro@gmail.com
>>> 
>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I think it would facilitate more
frequent releases to
>> summarize
>>>>>>>> in a
>>>>>>>>>>>> page
>>>>>>>>>>>>>>> the testing that all contributors/committers
do in
>> anticipation
>>>>>>>> of the
>>>>>>>>>>>>>>> release, plus any "new" testing
that may become relevant for
>> the
>>>>>>>> newer
>>>>>>>>>>>>>>> releases. Doing so would make
it easy to create a check form
>> or or
>>>>>>>>>>>> email
>>>>>>>>>>>>>>> template that what we feel should
be done to guarantee a
>> stable
>>>>>>>>>>>> release.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Hugo
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Mon, Jul 29, 2019 at 7:15
AM Ethan Li <
>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Thanks Stig. I will look
into it.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06
PM, Stig Rohde Døssing <
>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> I think ideally we've
been trying for semver, but it's been
>>>>>>>> pretty
>>>>>>>>>>>>>> loose,
>>>>>>>>>>>>>>>>> e.g. there were breaking
changes in one of the 1.2.x
>> releases
>>>>>>>> for
>>>>>>>>>>>>>>>>> storm-kafka-client. I
don't know what rules we've actually
>> been
>>>>>>>>>>>> using,
>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>> any.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Semver for binary compatibility
would probably be a good
>> rule of
>>>>>>>>>>>> thumb.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019
kl. 20.01 skrev Ethan Li <
>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Stig,
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Do you know what’s
the versioning standard we have been
>>>>>>>> following
>>>>>>>>>>>> (to
>>>>>>>>>>>>>>>>>> determine a 2.0.1
release or 2.1.0 release) ?
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> On Jul 26, 2019,
at 12:26 PM, Stig Rohde Døssing <
>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Sounds great,
thanks Ethan.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Den fre. 26.
jul. 2019 kl. 19.16 skrev Ethan Li <
>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> It’s good
idea to do more frequent release. I can run
>> the
>>>>>>>> next
>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> I will take
a look at both PRs. Other than that, I
>> think we
>>>>>>>> should
>>>>>>>>>>>>>>>> also
>>>>>>>>>>>>>>>>>>>> get https://github.com/apache/storm/pull/3093
<
>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3093>
 in the new
>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> On Jul
26, 2019, at 11:58 AM, Stig Rohde Døssing <
>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> I think
we've talked about more frequent releases
>> before.
>>>>>>>>>>>> Releasing
>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>>>>>> versions
every few months means people don't have to
>> wait
>>>>>>>> long
>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>> fixes
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> get out,
and smaller releases are probably also easier
>> for
>>>>>>>> users
>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> grips
with (the fix list for 2.0.0 is enormous).
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> With
that in mind, I think we should start looking at
>> the
>>>>>>>> next
>>>>>>>>>>>> 2.x
>>>>>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>>>>> (2.0.1
or 2.1.0?), since it's been a couple of months
>> since
>>>>>>>> 2.0.0
>>>>>>>>>>>>>>>>>>>> released.
>>>>>>>>>>>>>>>>>>>>> The fix
list would be
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>> 
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20fixVersion%20%3D%202.0.1
>>>>>>>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Govind
and Ethan have offered to run the next release,
>> and
>>>>>>>> help
>>>>>>>>>>>>>>>>>> validate
>>>>>>>>>>>>>>>>>>>>> our release
process guidelines. Would one of you have
>> time
>>>>>>>> to
>>>>>>>>>>>> work
>>>>>>>>>>>>>>>> on a
>>>>>>>>>>>>>>>>>>>>> release
in the near future?
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> It would
be good to take a look at currently open PRs
>> and
>>>>>>>> decide
>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>> feel
need to get merged before the next release.
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> I would
like to see at least
>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2990
>>>>>>>>>>>>>>>>>>>>> merged
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878
seems like
>> it's
>>>>>>>> close
>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>> mergeable
too?
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>> 
>>> 
>> 
>> 


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