cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: too long to package a release?
Date Thu, 24 Jan 2013 22:14:34 GMT
Nice Shaz, but I was hoping it was a github style network visualization
that included a few versions worth of merges.
Who wants to draw that?

On Thu, Jan 24, 2013 at 2:05 PM, Shazron <shazron@gmail.com> wrote:

> Inline image got mangled, here it is linked: http://cl.ly/MOrD
>
>
> On Thu, Jan 24, 2013 at 1:39 PM, Shazron <shazron@gmail.com> wrote:
>
>> Thanks for the pseudocode Andrew, seems simpler to understand ;) Jesse's
>> re-factor makes it even easier. Here's my contrib for those more visually
>> inclined:
>>
>>
>> [image: Inline image 2]
>>
>>
>> On Thu, Jan 24, 2013 at 1:29 PM, Andrew Grieve <agrieve@chromium.org>wrote:
>>
>>> Nice! even simpler. :)
>>>
>>>
>>> On Thu, Jan 24, 2013 at 3:44 PM, Jesse <purplecabbage@gmail.com> wrote:
>>>
>>> > Thanks for clarifying Andrew. et al, I guess I was mis-understanding
>>> some
>>> > of the earlier discussion around naming stuff.
>>> >
>>> > So everything is going to master all the time, and we only care about
>>> > 'next' if we are inReleaseMode and it is a bug fix?
>>> >
>>> > if(inReleaseMode && isBugFix) {
>>> >     commitToBranch('next');
>>> >     mergeBranch('next').into('master');
>>> > }
>>> > else {
>>> >     commitToBranch('master');
>>> > }
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Thu, Jan 24, 2013 at 12:29 PM, Andrew Grieve <agrieve@chromium.org
>>> > >wrote:
>>> >
>>> > > Just to clarify - there should be *no* using of the git
>>> cherry-picking
>>> > > command, only git merge.
>>> > >
>>> > > Jesse - not sure what you're referring to with "branch must be named
>>> x".
>>> > > The latest revision of the proposal has only two branches: master and
>>> > next.
>>> > > Do you mean you don't like the name "next"?
>>> > >
>>> > > Maybe the proposal will seem simpler if put in the form of code :)
>>> > >
>>> > > if (!inReleaseMode) {
>>> > >     commitToBranch('master');
>>> > > } else {
>>> > >   if (isBugFix) {
>>> > >     commitToBranch('next');
>>> > >     mergeBranch('next').into('master');
>>> > >   } else {
>>> > >     commitToBranch('master');
>>> > >   }
>>> > > }
>>> > >
>>> > >
>>> > > On Thu, Jan 24, 2013 at 3:06 PM, Braden Shepherdson <
>>> braden@chromium.org
>>> > > >wrote:
>>> > >
>>> > > > Most of the time the flow will be unchanged: push to master.
>>> Tagging
>>> > > things
>>> > > > we already know how to do; that doesn't change.
>>> > > >
>>> > > > The only new flow for most people is cherrypicking bug fixes from
>>> > master
>>> > > to
>>> > > > next, which we can give examples of. Plus that could remain the
>>> > > > responsibility of the main platform maintainers, who are doing
the
>>> > > tagging.
>>> > > >
>>> > > > Braden
>>> > > >
>>> > > >
>>> > > > On Thu, Jan 24, 2013 at 2:56 PM, Jesse <purplecabbage@gmail.com>
>>> > wrote:
>>> > > >
>>> > > > > On Thu, Jan 24, 2013 at 11:09 AM, Braden Shepherdson <
>>> > > > braden@chromium.org
>>> > > > > >wrote:
>>> > > > >
>>> > > > > > The founding goal we're trying to accomplish here is
that we
>>> don't
>>> > > want
>>> > > > > > everyone sitting on changes to be in the next version
while we
>>> use
>>> > > > master
>>> > > > > > to prep a release.
>>> > > > > >
>>> > > > > > I don't think having one branch for prepping the release
and
>>> > another
>>> > > > for
>>> > > > > > main development is a lot of bureaucracy.
>>> > > > > >
>>> > > > >
>>> > > > > It is not, the 'branch must be named x' is mainly where I
have
>>> > > concerns.
>>> > > > > Really I just want things simple.
>>> > > > >
>>> > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > > On Thu, Jan 24, 2013 at 1:57 PM, Jesse MacFadyen <
>>> > > > > purplecabbage@gmail.com
>>> > > > > > >wrote:
>>> > > > > >
>>> > > > > > > I have been quietly listening on this thread, but
thought I
>>> > should
>>> > > at
>>> > > > > > > least share my opinion.
>>> > > > > > >
>>> > > > > > > I don't think adding contribution rules helps anyone.
Git is
>>> > > > > > > complicated enough as it is, and this just all
seems like
>>> > > > bureaucracy.
>>> > > > > > >
>>> > > > > > > I think master should always contain the latest
stable code,
>>> and
>>> > be
>>> > > > > > > periodically tagged with rc's and versions.
>>> > > > > > > All work should be done in personal forks and feature
>>> branches.
>>> > > > > > > If the latest tag of master is an rc, then we should
only be
>>> > > merging
>>> > > > > > > bugfixes, until the release.
>>> > > > > > > Immediately after tagging a version we decide which
feature
>>> > > branches
>>> > > > > > > and pull requests to pull in, and go for it.
>>> > > > > > >
>>> > > > > > > I don't think this is much different from what
we have, but I
>>> > think
>>> > > > > > > that is good.
>>> > > > > > > The suggestions thus far, while interesting, don't
increase
>>> our
>>> > > > > > > velocity in my opinion. Also, I can also pretty
much guaranty
>>> > I'll
>>> > > > > > > screw it up for the next 3-4 versions. ( because
I'm dumb )
>>> > > > > > >
>>> > > > > > > Cheers,
>>> > > > > > >   Jesse
>>> > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > > On 2013-01-24, at 5:53 AM, Andrew Grieve <
>>> agrieve@chromium.org>
>>> > > > wrote:
>>> > > > > > >
>>> > > > > > > On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks
<
>>> > > > > > michael@michaelbrooks.ca
>>> > > > > > > >wrote:
>>> > > > > > >
>>> > > > > > > > Before we move forward, I have a few questions
about the
>>> "no
>>> > > > master"
>>> > > > > > > > approach.
>>> > > > > > > >
>>> > > > > > > > There is *no* master branch, so that community-driven
pull
>>> > > requests
>>> > > > > > will
>>> > > > > > > be
>>> > > > > > > >> forced to think about which branch to
request against.
>>> > > > > > > >
>>> > > > > > > >
>>> > > > > > > > - Andrew, can you cite other projects that
do not use a
>>> master
>>> > > > > branch?
>>> > > > > > > This project is my first time using git / github,
so I don't
>>> have
>>> > > > much
>>> > > > > to
>>> > > > > > > draw from. I was going off of others' suggestions
on this
>>> thread
>>> > > > when I
>>> > > > > > > proposed the names.
>>> > > > > > >
>>> > > > > > >
>>> > > > > > > > - On Github, you must have a default branch.
If not
>>> master, it
>>> > > must
>>> > > > > be
>>> > > > > > > > something else. So, users are not forced to
think about the
>>> > > branch
>>> > > > to
>>> > > > > > > send
>>> > > > > > > > a pull request again... they will likely just
use the
>>> default.
>>> > > > > > >
>>> > > > > > > Hmm, good point. The goal is to get people downloading
>>> Cordova
>>> > for
>>> > > > use
>>> > > > > to
>>> > > > > > > end up with Stable, and for developers to send
pull requests
>>> > > against
>>> > > > > dev.
>>> > > > > > > With a forced default branch, I don't think we
can accomplish
>>> > this.
>>> > > > > > >
>>> > > > > > >
>>> > > > > > > >
>>> > > > > > > > - Why is the "stable" branch not just "master"?
>>> > > > > > >
>>> > > > > > > My thinking was that it's not obvious whether Master
==
>>> bleeding
>>> > > > edge,
>>> > > > > or
>>> > > > > > > Master == Stable version. Using the names "dev"
and "stable"
>>> > makes
>>> > > > it a
>>> > > > > > bit
>>> > > > > > > clear.
>>> > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > > So... If github forces us to have a default branch,
I'm
>>> thinking
>>> > > that
>>> > > > > > > having users send pull requests against "dev" is
more
>>> valuable
>>> > than
>>> > > > > > having
>>> > > > > > > people download the latest "stable" by default.
If people are
>>> > > pulling
>>> > > > > > code
>>> > > > > > > from github rather than from our release .zip files,
then
>>> it's
>>> > > likely
>>> > > > > > they
>>> > > > > > > want to hack on it anyways, or that they want the
dev
>>> version to
>>> > > see
>>> > > > if
>>> > > > > > > bugs are fixed.
>>> > > > > > >
>>> > > > > > > Soo.... Here's version #3! If anyone can think
of how to
>>> keep the
>>> > > > three
>>> > > > > > > branches while addressing being forced to have
a default
>>> branch,
>>> > > feel
>>> > > > > > free
>>> > > > > > > to speak up! :)
>>> > > > > > >
>>> > > > > > >
>>> > > > > > > Cordova repositories have two main branches:
>>> > > > > > > 1. master
>>> > > > > > > 2. next
>>> > > > > > >
>>> > > > > > > Topic branches exist for collaborating on features,
or for
>>> > > > code-review
>>> > > > > > > purposes.
>>> > > > > > >
>>> > > > > > > Cordova uses tags to label releases.
>>> > > > > > > - Each release candidate has a tag. e.g. "2.2.0rc1"
>>> > > > > > > - Each release has a tag. e.g. "2.2.0"
>>> > > > > > > - The "latest" tag points to the last stable release
(this
>>> > follows
>>> > > > npm
>>> > > > > > > conventions)
>>> > > > > > >
>>> > > > > > >
>>> > > > > > > 1. The "next" branch.
>>> > > > > > > - This branch is used only when in the process
of doing a
>>> > release.
>>> > > > > > > - All tags are created from this branch.
>>> > > > > > > - All release-candidate bug-fixes are done on this
branch.
>>> > > > > > >
>>> > > > > > > 2. The "master" branch.
>>> > > > > > >  - When not in the release-process, all commits
are made here
>>> > > > > > >  - When in the release-process, all non-bugfix
commits are
>>> made
>>> > > here
>>> > > > > > >  - This is where topic-branches are merged into.
>>> > > > > > >
>>> > > > > > > Cutting a release:
>>> > > > > > > 1. git checkout next && git merge --ff-only
master
>>> > > > > > > 2. Test test test!
>>> > > > > > > 3. Fix bugs by committing them directly to "next"
and then
>>> doing
>>> > a
>>> > > > > non-ff
>>> > > > > > > merge of next into master
>>> > > > > > > 4. Tag release candidate
>>> > > > > > > 5. Repeat steps 2-4 as necessary
>>> > > > > > > 6. Tag the release (both by version and by updating
the
>>> "latest"
>>> > > tag)
>>> > > > > > > 7. Create distribution .zip file
>>> > > > > > > 8. Test one last time using the dist files
>>> > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > > >
>>> > > > > > > > Thanks,
>>> > > > > > > > Michael
>>> > > > > > > >
>>> > > > > > > > On Wed, Jan 23, 2013 at 11:25 AM, Brian LeRoux
<b@brian.io
>>> >
>>> > > wrote:
>>> > > > > > > >
>>> > > > > > > >> I'm liking it. Start in 2.5?
>>> > > > > > > >>
>>> > > > > > > >> On Wed, Jan 23, 2013 at 1:19 PM, Filip
Maj <fil@adobe.com
>>> >
>>> > > wrote:
>>> > > > > > > >>> Looks great Andrew!
>>> > > > > > > >>>
>>> > > > > > > >>> If everyone's on board, how are we
going to test run
>>> this?
>>> > > Flip a
>>> > > > > > > > switch
>>> > > > > > > >>> at a certain point, give it a shot
with one repo for one
>>> RC?
>>> > > > > > > >>>
>>> > > > > > > >>> On 1/22/13 12:29 PM, "Andrew Grieve"
<
>>> agrieve@chromium.org>
>>> > > > wrote:
>>> > > > > > > >>>
>>> > > > > > > >>>> Braden, you're right. I've now
done some local playing
>>> > around
>>> > > in
>>> > > > > > git,
>>> > > > > > > > and
>>> > > > > > > >>>> have an updated proposal that
uses merges instead of
>>> > deleting
>>> > > > > > > branches.
>>> > > > > > > >>>> PTAL:
>>> > > > > > > >>>>
>>> > > > > > > >>>> Cordova repositories have three
main branches:
>>> > > > > > > >>>> 1. stable
>>> > > > > > > >>>> 2. next
>>> > > > > > > >>>> 3. dev
>>> > > > > > > >>>>
>>> > > > > > > >>>> Topic branches also exist for
collaborating on
>>> features, or
>>> > > for
>>> > > > > > > >>>> code-review
>>> > > > > > > >>>> purposes.
>>> > > > > > > >>>>
>>> > > > > > > >>>> There is *no* master branch, so
that community-driven
>>> pull
>>> > > > > requests
>>> > > > > > > > will
>>> > > > > > > >>>> be
>>> > > > > > > >>>> forced to think about which branch
to request against.
>>> > > > > > > >>>>
>>> > > > > > > >>>> 1. The "stable" branch.
>>> > > > > > > >>>> - Sits at the latest stable release
of cordova
>>> > > > > > > >>>> - This changes only when doing
fast-forward merges from
>>> > "next"
>>> > > > > > > >>>>
>>> > > > > > > >>>> 2. The "next" branch.
>>> > > > > > > >>>> - This branch is used only when
in the process of doing
>>> a
>>> > > > release.
>>> > > > > > > >>>> - All tags (both stable and RC)
are done on this branch.
>>> > > > > > > >>>> - All release-candidate bug-fixes
are done on this
>>> branch.
>>> > > > > > > >>>>
>>> > > > > > > >>>> 3. The "dev" branch.
>>> > > > > > > >>>> - This is where non-release-candidate
commits are done
>>> > > > > > > >>>> - This is where topic-branches
are merged into.
>>> > > > > > > >>>>
>>> > > > > > > >>>> Cutting a release:
>>> > > > > > > >>>> 1. git checkout next &&
git merge --ff-only dev
>>> > > > > > > >>>> 2. Test test test!
>>> > > > > > > >>>> 3. Fix bugs by committing them
directly to "next" and
>>> then
>>> > > > doing a
>>> > > > > > > > non-ff
>>> > > > > > > >>>> merge of next into dev
>>> > > > > > > >>>> 4. Tag release candidate
>>> > > > > > > >>>> 5. Repeat steps 2-4 as necessary
>>> > > > > > > >>>> 6. Tag the release
>>> > > > > > > >>>> 7. Create distribution .zip file
>>> > > > > > > >>>> 8. Test one last time using the
dist files
>>> > > > > > > >>>> 9. git checkout stable &&
git merge --ff-only next
>>> > > > > > > >>>>
>>> > > > > > > >>>>
>>> > > > > > > >>>>
>>> > > > > > > >>>> On Tue, Jan 22, 2013 at 1:59 PM,
Braden Shepherdson
>>> > > > > > > >>>> <braden@chromium.org>wrote:
>>> > > > > > > >>>>
>>> > > > > > > >>>>> I think deleting and recreating
branches with the same
>>> name
>>> > > can
>>> > > > > > cause
>>> > > > > > > >>>>> badness in git[1] because
of remotes. It's not really
>>> the
>>> > > same
>>> > > > > > branch
>>> > > > > > > >> in
>>> > > > > > > >>>>> terms of commits, and git
thinks that your old stable
>>> and
>>> > the
>>> > > > new
>>> > > > > > > >> stable
>>> > > > > > > >>>>> differ by all of each of their
commits. Tags can be
>>> moved
>>> > > > > > > > arbitrarily,
>>> > > > > > > >>>>> so I
>>> > > > > > > >>>>> think stable makes sense as
a tag. I'm not sure about
>>> how
>>> > > best
>>> > > > to
>>> > > > > > > >> handle
>>> > > > > > > >>>>> next.
>>> > > > > > > >>>>>
>>> > > > > > > >>>>> [1]
>>> > > > > > > >
>>> > > > > > >
>>> > > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>> http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
>>> > > > > > > >>>>> h
>>> > > > > > > >>>>>
>>> > > > > > > >>>>>
>>> > > > > > > >>>>> On Tue, Jan 22, 2013 at 11:31
AM, Andrew Grieve <
>>> > > > > > > > agrieve@chromium.org
>>> > > > > > > >>>>>> wrote:
>>> > > > > > > >>>>>
>>> > > > > > > >>>>>> Michal's attending hackathons
for the week, and I'm
>>> not
>>> > sure
>>> > > > we
>>> > > > > > > > need
>>> > > > > > > >>>>> to
>>> > > > > > > >>>>> do
>>> > > > > > > >>>>>> a hang-out for this, as
I think we really are quite
>>> close
>>> > to
>>> > > > > > > >> resolving
>>> > > > > > > >>>>>> this. I'd really like
to resolve this ASAP so that we
>>> > don't
>>> > > > need
>>> > > > > > to
>>> > > > > > > >>>>> have
>>> > > > > > > >>>>> a
>>> > > > > > > >>>>>> code-freeze for this release.
>>> > > > > > > >>>>>>
>>> > > > > > > >>>>>> Here's a proposal:
>>> > > > > > > >>>>>>
>>> > > > > > > >>>>>> Cordova repositories have
three main branches:
>>> > > > > > > >>>>>> 1. stable
>>> > > > > > > >>>>>> 2. next
>>> > > > > > > >>>>>> 3. dev
>>> > > > > > > >>>>>>
>>> > > > > > > >>>>>> Topic branches also exist
for collaborating on
>>> features,
>>> > or
>>> > > > for
>>> > > > > > > >>>>> code-review
>>> > > > > > > >>>>>> purposes.
>>> > > > > > > >>>>>>
>>> > > > > > > >>>>>> There is *no* master branch,
so that community-driven
>>> pull
>>> > > > > > requests
>>> > > > > > > >>>>> will
>>> > > > > > > >>>>> be
>>> > > > > > > >>>>>> forced to think about
which branch to request against.
>>> > > > > > > >>>>>>
>>> > > > > > > >>>>>> 1. The "stable" branch.
>>> > > > > > > >>>>>> - Sits at the latest stable
release of cordova
>>> > > > > > > >>>>>> - No one ever commits
to the "stable" branch. It
>>> exists
>>> > only
>>> > > > as
>>> > > > > a
>>> > > > > > > >>>>>> short-cut for checking
out the latest stable tag.
>>> > > > > > > >>>>>>
>>> > > > > > > >>>>>> 2. The "next" branch.
>>> > > > > > > >>>>>> - This branch exists only
when in the process of
>>> doing a
>>> > > > > release.
>>> > > > > > > >>>>>> - All tags (both stable
and RC) are done on this
>>> branch.
>>> > > > > > > >>>>>> - When a stable tag is
done:
>>> > > > > > > >>>>>>    - The existing "stable"
branch is deleted
>>> > > > > > > >>>>>>    - A new "stable" branch
is created from "next".
>>> > > > > > > >>>>>>    - The "next" branch
is deleted.
>>> > > > > > > >>>>>>
>>> > > > > > > >>>>>> 3. The "dev" branch.
>>> > > > > > > >>>>>>  - This is where all commits
are done
>>> > > > > > > >>>>>>  - This is where topic-branches
are merged into.
>>> > > > > > > >>>>>>
>>> > > > > > > >>>>>> Cutting a release:
>>> > > > > > > >>>>>> 1. Create "next" from
the HEAD of "dev"
>>> > > > > > > >>>>>> 2. Test test test!
>>> > > > > > > >>>>>> 3. Fix bugs by committing
them to "dev" and then
>>> > > > cherry-picking
>>> > > > > > > > them
>>> > > > > > > >>>>> into
>>> > > > > > > >>>>>> "next"
>>> > > > > > > >>>>>> 4. Tag release candidate
>>> > > > > > > >>>>>> 5. Repeat steps 2-4 as
necessary
>>> > > > > > > >>>>>> 6. Tag the release
>>> > > > > > > >>>>>> 7. Create distribution
.zip file
>>> > > > > > > >>>>>> 8. Test one last time
using the dist files
>>> > > > > > > >>>>>> 9. Delete "stable"
>>> > > > > > > >>>>>> 10. Create a new "stable"
by branching from the HEAD
>>> of
>>> > > "next"
>>> > > > > > > >>>>>> 11. Delete the "next"
branch
>>> > > > > > > >>>>>>
>>> > > > > > > >>>>>>
>>> > > > > > > >>>>>>
>>> > > > > > > >>>>>> On Wed, Jan 16, 2013 at
10:34 AM, Michal Mocny <
>>> > > > > > > > mmocny@chromium.org>
>>> > > > > > > >>>>>> wrote:
>>> > > > > > > >>>>>>
>>> > > > > > > >>>>>>> Just going to throw
out one of my personal
>>> requirements
>>> > for
>>> > > > > > > >> whatever
>>> > > > > > > >>>>>>> proposal we come up
with, so it doesn't get lost:
>>> > > > > > > >>>>>>>
>>> > > > > > > >>>>>>> * Feature branches
are great for feature work and/or
>>> > large
>>> > > > > > > > sweeping
>>> > > > > > > >>>>>>> changes, as are JIRA
bugs for tracking them, but
>>> cordova
>>> > > has
>>> > > > > many
>>> > > > > > > >>>>> many
>>> > > > > > > >>>>>>> trivial issues that
could be fixed with "drive-by"
>>> > patches
>>> > > > that
>>> > > > > > > >>>>> require
>>> > > > > > > >>>>>> as
>>> > > > > > > >>>>>>> little friction to
commit as possible.
>>> > > > > > > >>>>>>>
>>> > > > > > > >>>>>>>
>>> > > > > > > >>>>>>> On Tue, Jan 15, 2013
at 3:05 PM, Marcel Kinard <
>>> > > > > > > > cmarcelk@gmail.com
>>> > > > > > > >>>
>>> > > > > > > >>>>>> wrote:
>>> > > > > > > >>>>>>>
>>> > > > > > > >>>>>>>> How about if there
is a specific straw man proposal
>>> at
>>> > the
>>> > > > > > > >>>>> beginning
>>> > > > > > > >>>>> of
>>> > > > > > > >>>>>>>> the face-time?
Then the folks that are in agreement
>>> > won't
>>> > > > need
>>> > > > > > > > to
>>> > > > > > > >>>>> say
>>> > > > > > > >>>>>>>> anything ;-)
>>> > > > > > > >>>>>>>>
>>> > > > > > > >>>>>>>> Seriously, making
adjustments to something tangible
>>> is
>>> > > > easier
>>> > > > > > > >> than
>>> > > > > > > >>>>>>>> instantiating
it from scratch. A volunteer for a
>>> very
>>> > > simple
>>> > > > > > > >>>>> writeup
>>> > > > > > > >>>>> on
>>> > > > > > > >>>>>>> the
>>> > > > > > > >>>>>>>> wiki?
>>> > > > > > > >>>>>>>>
>>> > > > > > > >>>>>>>> -- Marcel Kinard
>>> > > > > > > >>>>>>>>
>>> > > > > > > >>>>>>>>
>>> > > > > > > >>>>>>>> On 1/14/2013 10:06
PM, Michal Mocny wrote:
>>> > > > > > > >>>>>>>>
>>> > > > > > > >>>>>>>>> Okay gentlemen,
I think there have been countless
>>> good
>>> > > > points
>>> > > > > > > >>>>> made
>>> > > > > > > >>>>>> from
>>> > > > > > > >>>>>>>>> all
>>> > > > > > > >>>>>>>>> parties, but
also some bike-shedding.
>>> > > > > > > >>>>>>>>>
>>> > > > > > > >>>>>>>>> Perhaps it
is time to schedule some face-time to
>>> better
>>> > > > > > > >>>>> articulate
>>> > > > > > > >>>>>> some
>>> > > > > > > >>>>>>> of
>>> > > > > > > >>>>>>>>> the finer
points, and to help come to some
>>> consensus?
>>> > > > > > > >>>>>>>>>
>>> > > > > > > >>>>>>>>> -Michal
>>> > > > > > > >
>>> > > > > > >
>>> > > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > --
>>> > > > > @purplecabbage
>>> > > > > risingj.com
>>> > > > >
>>> > > >
>>> > >
>>> >
>>> >
>>> >
>>> > --
>>> > @purplecabbage
>>> > risingj.com
>>> >
>>>
>>
>>
>


-- 
@purplecabbage
risingj.com

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