zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Hunt <ph...@apache.org>
Subject Re: [VOTE] move Apache Zookeeper to git
Date Mon, 05 Dec 2016 23:07:48 GMT
No problem Edward. Did you get any insight on what to do with the PR?

Patrick

On Thu, Nov 24, 2016 at 10:52 AM, Edward Ribeiro <edward.ribeiro@gmail.com>
wrote:

> Hi, Patrick,
>
> Thanks for merging this change. :)
>
> Sincerely, I don't know why it didn't close the PR automatically. Nor why
> you can close it in the GH mirror. In any case, I manually closed it.
>
> I will ping folks from other Apache projects using similar tool to inquire
> why it didn't close the PR and why it gave this 'write access' error
> message.
>
> Edward
>
>
>
> On Fri, Nov 18, 2016 at 8:13 PM, Patrick Hunt <phunt@apache.org> wrote:
>
>> Thanks Edward, this should be very helpful for folks. I committed,
>> however I notice the PR is still open. I followed the steps here:
>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/Committing+changes
>> however I don't see a way to close the PR? https://github.com/apache/
>> zookeeper/pull/103 says I don't have "write access".
>>
>> Patrick
>>
>> On Thu, Nov 10, 2016 at 10:23 AM, Edward Ribeiro <
>> edward.ribeiro@gmail.com> wrote:
>>
>>> Hi Patrick,
>>>
>>> I've just opened a PR  https://github.com/apache/zookeeper/pull/103/ PR
>>>
>>> It asks for JIRA_PASSWORD at CLI prompt *IF* it's absent but
>>> JIRA_USERNAME
>>> is already set. Please, when you have time, see if it fits what you need
>>> and then I can open a JIRA, rename the feature branch, etc.
>>>
>>> Let me know if you have other ideas. I am open to other ways of
>>> incorporating the passing of JIRA_PASSWORD too.
>>>
>>> Edward
>>>
>>> On Wed, Nov 9, 2016 at 5:03 PM, Edward Ribeiro <edward.ribeiro@gmail.com
>>> >
>>> wrote:
>>>
>>> > Hi Patrick,
>>> >
>>> > We can change the script so that it asks for jira password input on CLI
>>> > prompt if the JIRA username is set, for example. The change should be
>>> > straigthforward.
>>> >
>>> > Alternatively, the python systems I have dealt with put credentials for
>>> > database access, etc, in configuration -- sometimes hidden -- files
>>> (say,
>>> > .env), but yet it is clear text stored.
>>> >
>>> > Anyone has other suggestions?
>>> >
>>> > Eddie
>>> >
>>> > Em 9 de nov de 2016 4:18 PM, "Patrick Hunt" <phunt@apache.org>
>>> escreveu:
>>> >
>>> >> Is there any alternative to step 4 as documented here?
>>> >> https://cwiki.apache.org/confluence/display/ZOOKEEPER/Mergin
>>> >> g+Github+Pull+Requests
>>> >>
>>> >> specifically it's asking to "export JIRA_PASSWORD=mypassword" which I
>>> feel
>>> >> very uncomfortable doing.
>>> >>
>>> >> Patrick
>>> >>
>>> >> On Wed, Oct 26, 2016 at 11:12 AM, Edward Ribeiro <
>>> >> edward.ribeiro@gmail.com>
>>> >> wrote:
>>> >>
>>> >> > AFAIK, yes. I say, if you mean to run unit tests and other CI tasks
>>> on
>>> >> PR.
>>> >> >
>>> >> > PS: I have just created a simple script HowTo at
>>> >> > https://cwiki.apache.org/confluence/display/ZOOKEEPER/
>>> >> > Merging+Github+Pull+Requests
>>> >> > and linked from https://cwiki.apache.org/confl
>>> uence/display/ZOOKEEPER/
>>> >> > Index
>>> >> >
>>> >> > On Wed, Oct 26, 2016 at 3:59 PM, Flavio Junqueira <fpj@apache.org>
>>> >> wrote:
>>> >> >
>>> >> > > What about QA, are we still missing a github pre-commit queue?
>>> >> > >
>>> >> > > -Flavio
>>> >> > >
>>> >> > > > On 26 Oct 2016, at 18:53, Michael Han <hanm@cloudera.com>
>>> wrote:
>>> >> > > >
>>> >> > > > The comment bridging should be fixed now - see INFRA-12752 for
>>> more
>>> >> > > > details.
>>> >> > > >
>>> >> > > > On Wed, Oct 26, 2016 at 10:03 AM, Michael Han <
>>> hanm@cloudera.com>
>>> >> > wrote:
>>> >> > > >
>>> >> > > >>>> The git PR *review* comments for ZOOKEEPER-2597 didn't show
>>> up on
>>> >> > > JIRA.
>>> >> > > >>
>>> >> > > >> The bridge was working the day Infra made the change - see the
>>> >> > previous
>>> >> > > >> comments made by git bot on ZOOKEEPER-761. Now it seems stop
>>> >> working.
>>> >> > I
>>> >> > > am
>>> >> > > >> reopening INFRA-12752 and building a case.
>>> >> > > >>
>>> >> > > >> On Wed, Oct 26, 2016 at 9:45 AM, Edward Ribeiro <
>>> >> > > edward.ribeiro@gmail.com>
>>> >> > > >> wrote:
>>> >> > > >>
>>> >> > > >>> Dear community,
>>> >> > > >>>
>>> >> > > >>> The zk-merger-pr.py script has been merged into master
>>> (thanks a
>>> >> LOT
>>> >> > > Ben
>>> >> > > >>> Reed for reviewing/discussing/testing and commiting):
>>> >> > > >>> https://issues.apache.org/jira/browse/ZOOKEEPER-2597
>>> >> > > >>>
>>> >> > > >>> As stated in the issue and on GH, this tool is a modified
>>> version
>>> >> of
>>> >> > > >>> similar tools from Kafka, that is a copy of a Spark's one. It
>>> has
>>> >> > some
>>> >> > > >>> rough edges so we will certainly benefit from further
>>> enhancements
>>> >> > and
>>> >> > > >>> fixes. I changed the smallest possible pieces of code, just to
>>> >> make
>>> >> > it
>>> >> > > >>> work
>>> >> > > >>> on a ZK repo so the credits go to the original authors.
>>> >> > > >>>
>>> >> > > >>> Some notes:
>>> >> > > >>>
>>> >> > > >>> 1. The git PR *review* comments for ZOOKEEPER-2597 didn't
>>> show up
>>> >> on
>>> >> > > JIRA.
>>> >> > > >>> Only the opening and closing of the issue. Can we double check
>>> >> this
>>> >> > as
>>> >> > > >>> INFRA-12752 is closed, Michael Han?
>>> >> > > >>>
>>> >> > > >>> 2. I scribbled a draft on how use the tool at
>>> >> > > >>> https://docs.google.com/document/d/1i00ZXjrW2fu17vr_h7F1bUrq
>>> >> > > >>> Xg3urw4Hm7KirQDpPIU/edit
>>> >> > > >>> (still very crude, but feel free to improve it). I would like
>>> to
>>> >> move
>>> >> > > >>> this
>>> >> > > >>> text to https://cwiki.apache.org/confl
>>> >> uence/display/ZOOKEEPER/Index
>>> >> > > but
>>> >> > > >>> looks like I don't have permission to create a page there
>>> yet. Any
>>> >> > > help?
>>> >> > > >>>
>>> >> > > >>> Best regards,
>>> >> > > >>> Eddie
>>> >> > > >>>
>>> >> > > >>> On Sat, Oct 22, 2016 at 7:08 PM, Michael Han <
>>> hanm@cloudera.com>
>>> >> > > wrote:
>>> >> > > >>>
>>> >> > > >>>> FYI infra did some work in INFRA-12752 and the git PR
>>> comments
>>> >> can
>>> >> > be
>>> >> > > >>>> pushed to Apache JIRA.
>>> >> > > >>>>
>>> >> > > >>>> On Sat, Oct 8, 2016 at 8:01 AM, Flavio Junqueira <
>>> fpj@apache.org
>>> >> >
>>> >> > > >>> wrote:
>>> >> > > >>>>
>>> >> > > >>>>> This is not supported at the moment if nothing has changed:
>>> >> > > >>>>>
>>> >> > > >>>>> https://issues.apache.org/jira/browse/INFRA-11000 <
>>> >> > > >>>>> https://issues.apache.org/jira/browse/INFRA-11000>
>>> >> > > >>>>>
>>> >> > > >>>>> -Flavio
>>> >> > > >>>>>
>>> >> > > >>>>>> On 08 Oct 2016, at 00:54, Benjamin Reed <breed@apache.org>
>>> >> wrote:
>>> >> > > >>>>>>
>>> >> > > >>>>>> it doesn't look like we need to setup keys. this seems to
>>> work
>>> >> for
>>> >> > > >>> me:
>>> >> > > >>>>>>
>>> >> > > >>>>>> https://git-wip-us.apache.org/#committers-getting-started
>>> >> > > >>>>>>
>>> >> > > >>>>>> it does seem strange that we aren't using public keys and
>>> that
>>> >> i'm
>>> >> > > >>>>> sticking
>>> >> > > >>>>>> a password in .netrc :P i'm wondering if other projects
>>> were
>>> >> able
>>> >> > to
>>> >> > > >>>> get
>>> >> > > >>>>>> this going over ssh.
>>> >> > > >>>>>>
>>> >> > > >>>>>> i'll take a whack at cleaning up the svn and subversion
>>> >> > references.
>>> >> > > >>>>>>
>>> >> > > >>>>>> ben
>>> >> > > >>>>>>
>>> >> > > >>>>>> On Fri, Oct 7, 2016 at 12:59 PM, Camille Fournier <
>>> >> > > >>> camille@apache.org>
>>> >> > > >>>>>> wrote:
>>> >> > > >>>>>>
>>> >> > > >>>>>>> Hey folks,
>>> >> > > >>>>>>>
>>> >> > > >>>>>>> So I'm trying to get in a patch but this has not been
>>> updated
>>> >> to
>>> >> > > >>> tell
>>> >> > > >>>>>>> committers how to actually get the git keys set up:
>>> >> > > >>>>>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
>>> >> > > >>>>> Committing+changes
>>> >> > > >>>>>>>
>>> >> > > >>>>>>> Can someone float me a link that says how to do this?
>>> >> > > >>>>>>>
>>> >> > > >>>>>>> Also a bunch of our documentation still discusses SVN and
>>> not
>>> >> > git,
>>> >> > > >>>> which
>>> >> > > >>>>>>> means we are not done with this migration. If you were
>>> pushing
>>> >> > for
>>> >> > > >>>> this
>>> >> > > >>>>>>> change can you please do some due diligence on the wikis
>>> and
>>> >> > > >>> correct
>>> >> > > >>>> the
>>> >> > > >>>>>>> stuff that refers to SVN?
>>> >> > > >>>>>>>
>>> >> > > >>>>>>> Thanks,
>>> >> > > >>>>>>> C
>>> >> > > >>>>>>>
>>> >> > > >>>>>>> On Wed, Oct 5, 2016 at 1:02 PM, Edward Ribeiro <
>>> >> > > >>>>> edward.ribeiro@gmail.com>
>>> >> > > >>>>>>> wrote:
>>> >> > > >>>>>>>
>>> >> > > >>>>>>>> Excuse me guys!
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>> I've written on Macbook Pro. No idea why GMail messed it
>>> up.
>>> >> I
>>> >> > was
>>> >> > > >>>> only
>>> >> > > >>>>>>>> able to see the strange characters when I pasted on a
>>> gist
>>> >> text
>>> >> > > >>> area.
>>> >> > > >>>>> The
>>> >> > > >>>>>>>> previous message is below, but if anyone is still having
>>> >> trouble
>>> >> > > >>> (I
>>> >> > > >>>>> tried
>>> >> > > >>>>>>>> to remove the weird character), I left a copy at:
>>> >> > > >>>>>>>> https://gist.github.com/eribei
>>> ro/da2a6a6c9a508610d52d0755fae
>>> >> 835
>>> >> > 2d
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>> "Hi,
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>> The patch attached on ZOOKEEPER-2597 is a straightforward
>>> >> > > >>> adaptation
>>> >> > > >>>> of
>>> >> > > >>>>>>>> Kafka's one. It takes care of merging Github PR into
>>> Apache
>>> >> git
>>> >> > > >>> repo
>>> >> > > >>>>> and
>>> >> > > >>>>>>> a
>>> >> > > >>>>>>>> subsequent closing of the PR on the GH side, among other
>>> >> things
>>> >> > > >>>>>>> (rewriting
>>> >> > > >>>>>>>> of commit messages, etc). The current status is: the
>>> script
>>> >> > needs
>>> >> > > >>> to
>>> >> > > >>>> be
>>> >> > > >>>>>>>> reviewed/validated by a committer. It has been some time
>>> >> since I
>>> >> > > >>>>> uploaded
>>> >> > > >>>>>>>> the patch, so I gonna do another pass through it in the
>>> >> > meantime.
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>> There are some workflow issues beyond the scope of
>>> >> > ZOOKEEPER-2597
>>> >> > > >>>> that
>>> >> > > >>>>>>> need
>>> >> > > >>>>>>>> to be sorted out (IMO):
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>> 1. The normal workflow is to open a JIRA ticket before
>>> doing
>>> >> any
>>> >> > > >>> GH
>>> >> > > >>>> PR,
>>> >> > > >>>>>>>> that is, no JIRA-less PRs. The PR should have a title of
>>> the
>>> >> > form
>>> >> > > >>>>>>>> "ZOOKEEPER-xxxx: Title". This will trigger the Apache
>>> >> > JIRA-Github
>>> >> > > >>>>>>>> integration and it's opening show up in the JIRA ticket.
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>> 2. OTOH, not every Kafka PR needs a corresponding JIRA
>>> >> ticket.
>>> >> > > >>> There
>>> >> > > >>>>> are
>>> >> > > >>>>>>> a
>>> >> > > >>>>>>>> class of PRs with "MINOR" title that represent trivial
>>> code
>>> >> > > >>> changes
>>> >> > > >>>> and
>>> >> > > >>>>>>>> "HOT-FIX" title that fix urgent, but simple bugs. Both
>>> bypass
>>> >> > the
>>> >> > > >>>> JIRA
>>> >> > > >>>>>>>> creation step, even tough they are still subject to
>>> review.
>>> >> It's
>>> >> > > >>>> worth
>>> >> > > >>>>>>>> adopting a similar approach for ZK project?
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>> 3. IIRC (didn't find any page to confirm), Cassandra
>>> project
>>> >> > > >>>>> encourages,
>>> >> > > >>>>>>>> but not demands, that contributors also upload a patch
>>> file
>>> >> to
>>> >> > > >>> JIRA
>>> >> > > >>>>> even
>>> >> > > >>>>>>> in
>>> >> > > >>>>>>>> the case of a GH PR (as to leave a audit trail, I guess).
>>> >> Or, at
>>> >> > > >>>>> least,
>>> >> > > >>>>>>> C*
>>> >> > > >>>>>>>> project leaves up to the contributors to either open a
>>> GH PR
>>> >> or
>>> >> > > >>>> upload
>>> >> > > >>>>>>> the
>>> >> > > >>>>>>>> patch file to JIRA.
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>> +1 about having a 'paper trail' of review comments on
>>> JIRA
>>> >> > and/or
>>> >> > > >>>>> mailing
>>> >> > > >>>>>>>> list (I would prefer the mailing list tbh). But as
>>> Michael
>>> >> and
>>> >> > > >>> Flavio
>>> >> > > >>>>>>>> pointed out, I never seen GH PR review **comments** being
>>> >> > written
>>> >> > > >>>> back
>>> >> > > >>>>> to
>>> >> > > >>>>>>>> JIRA, at least not in Kafka, Cassandra or Solr projects,
>>> >> that I
>>> >> > > >>> have
>>> >> > > >>>>>>>> followed more closely.
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>> Eddie"
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>> On Wed, Oct 5, 2016 at 1:35 PM, Michael Han <
>>> >> hanm@cloudera.com>
>>> >> > > >>>> wrote:
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>>> Eddie's mail contains lots of '=E2=80=8B'' which is
>>> unicode
>>> >> > > >>>> character
>>> >> > > >>>>>>>>> zero-width space, which might cause parsing trouble for
>>> some
>>> >> > mail
>>> >> > > >>>>>>>> clients.
>>> >> > > >>>>>>>>>
>>> >> > > >>>>>>>>> On Wed, Oct 5, 2016 at 6:42 AM, Flavio Junqueira <
>>> >> > fpj@apache.org
>>> >> > > >>>>
>>> >> > > >>>>>>> wrote:
>>> >> > > >>>>>>>>>
>>> >> > > >>>>>>>>>> Dude, I'm just not able to parse your e-mail, did you
>>> write
>>> >> > that
>>> >> > > >>>> on a
>>> >> > > >>>>>>>>>> phone or something?
>>> >> > > >>>>>>>>>>
>>> >> > > >>>>>>>>>> -Flavio
>>> >> > > >>>>>>>>>>
>>> >> > > >>>>>>>>>>> On 05 Oct 2016, at 03:54, Edward Ribeiro <
>>> >> > > >>>> edward.ribeiro@gmail.com
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>>>> wrote:
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>> Hi,
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>> The patch attached on ZOOKEEPER-2597 is a
>>> >> > > >>>>>>>>>>> ​straightforward adaptation of
>>> >> > > >>>>>>>>>>> Kafka's one. It takes care of merging Github PR into
>>> >> Apache
>>> >> > git
>>> >> > > >>>>>>> repo
>>> >> > > >>>>>>>>> and
>>> >> > > >>>>>>>>>>> ​ a​
>>> >> > > >>>>>>>>>>> subsequent closing of the PR on the GH side
>>> >> > > >>>>>>>>>>> ​ among other things (rewriting of commit messages,
>>> etc)​
>>> >> > > >>>>>>>>>>> . The current status is: the script needs to be
>>> >> > > >>> reviewed/validated
>>> >> > > >>>>>>>> by a
>>> >> > > >>>>>>>>>>> committer.
>>> >> > > >>>>>>>>>>> ​It has been some time since I uploaded the patch, so
>>> I
>>> >> gonna
>>> >> > > >>> do
>>> >> > > >>>>>>>>> another
>>> >> > > >>>>>>>>>>> pass through it in the meantime.​
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>> ​T
>>> >> > > >>>>>>>>>>> here are some workflow issues beyond the scope of
>>> >> > > >>> ZOOKEEPER-2597
>>> >> > > >>>>>>>>>>> ​ that need to be sorted out (IMO)​
>>> >> > > >>>>>>>>>>> :
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>> 1. The normal workflow is to open a JIRA ticket before
>>> >> doing
>>> >> > > >>> any
>>> >> > > >>>> GH
>>> >> > > >>>>>>>> PR
>>> >> > > >>>>>>>>>>> ​, that is, no JIRA-less PRs.​
>>> >> > > >>>>>>>>>>> The PR should have a title of the form
>>> "ZOOKEEPER-xxxx:
>>> >> > Title".
>>> >> > > >>>>>>> This
>>> >> > > >>>>>>>>> will
>>> >> > > >>>>>>>>>>> trigger the Apache JIRA-Github integration and it's
>>> >> opening
>>> >> > > >>> show
>>> >> > > >>>> up
>>> >> > > >>>>>>>> in
>>> >> > > >>>>>>>>>> the
>>> >> > > >>>>>>>>>>> JIRA ticket.
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>> 2.
>>> >> > > >>>>>>>>>>> ​OTOH, ​n
>>> >> > > >>>>>>>>>>> ot every Kafka PR needs a corresponding JIRA ticket
>>> >> > > >>>>>>>>>>> ​. ​
>>> >> > > >>>>>>>>>>> There are a class of PR
>>> >> > > >>>>>>>>>>> ​s​
>>> >> > > >>>>>>>>>>> with "MINOR"
>>> >> > > >>>>>>>>>>> ​ title​
>>> >> > > >>>>>>>>>>> that represent trivial code changes
>>> >> > > >>>>>>>>>>> ​ and "HOT-FIX" title that fix urgent, but simple
>>> bugs.
>>> >> Both​
>>> >> > > >>>>>>>>>>> bypass the JIRA creation step
>>> >> > > >>>>>>>>>>> ​, even tough they are still ​
>>> >> > > >>>>>>>>>>> subject to review
>>> >> > > >>>>>>>>>>> ​.​
>>> >> > > >>>>>>>>>>> It's worth adopting a similar approach for ZK project?
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>> 3. IIRC
>>> >> > > >>>>>>>>>>> ​ (didn't find any page to confirm)​
>>> >> > > >>>>>>>>>>> , Cassandra project encourages, but not demands, that
>>> >> > > >>> contributors
>>> >> > > >>>>>>>> also
>>> >> > > >>>>>>>>>>> upload a patch file to JIRA even in the case of a GH
>>> PR
>>> >> > > >>>>>>>>>>> ​ (as to leave a audit trail, I guess)​
>>> >> > > >>>>>>>>>>> ​.​
>>> >> > > >>>>>>>>>>> Or
>>> >> > > >>>>>>>>>>> ​,​
>>> >> > > >>>>>>>>>>> at
>>> >> > > >>>>>>>>>>> ​ ​
>>> >> > > >>>>>>>>>>> least
>>> >> > > >>>>>>>>>>> ​,​
>>> >> > > >>>>>>>>>>> ​C* project ​
>>> >> > > >>>>>>>>>>> leave
>>> >> > > >>>>>>>>>>> ​s​
>>> >> > > >>>>>>>>>>> up to the contributor
>>> >> > > >>>>>>>>>>> ​s​
>>> >> > > >>>>>>>>>>> to either open a GH PR or upload the patch file
>>> >> > > >>>>>>>>>>> ​ to JIRA. In fact, Github allows the access to a raw
>>> >> patch
>>> >> > or
>>> >> > > >>>>>>> diff,
>>> >> > > >>>>>>>>> it's
>>> >> > > >>>>>>>>>>> just a matter of adding the ".patch" or ".diff"
>>> suffix to
>>> >> the
>>> >> > > >>> end
>>> >> > > >>>>>>> of
>>> >> > > >>>>>>>>> the
>>> >> > > >>>>>>>>>>> Pull Request URL.
>>> >> > > >>>>>>>>>>> ​
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>> +1 about having a 'paper trail'
>>> >> > > >>>>>>>>>>> ​ of review comments​
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>> ​o​
>>> >> > > >>>>>>>>>>> n JIRA and
>>> >> > > >>>>>>>>>>> ​/or​
>>> >> > > >>>>>>>>>>> mailing list (I
>>> >> > > >>>>>>>>>>> ​ would​
>>> >> > > >>>>>>>>>>> prefer the mailing list tbh). But as Michael and
>>> Flavio
>>> >> > pointed
>>> >> > > >>>>>>> out,
>>> >> > > >>>>>>>> I
>>> >> > > >>>>>>>>>>> never seen
>>> >> > > >>>>>>>>>>> ​GH ​
>>> >> > > >>>>>>>>>>> PR review
>>> >> > > >>>>>>>>>>> ​**​
>>> >> > > >>>>>>>>>>> comments
>>> >> > > >>>>>>>>>>> ​**​
>>> >> > > >>>>>>>>>>> being written back to JIRA, at least not in Kafka,
>>> >> Cassandra
>>> >> > > >>>>>>>>>>> ​or​
>>> >> > > >>>>>>>>>>> Solr projects
>>> >> > > >>>>>>>>>>> ​, that I have followed more closely.​
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>> Eddie
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>> On Tue, Oct 4, 2016 at 6:40 PM, Michael Han <
>>> >> > hanm@cloudera.com
>>> >> > > >>>>
>>> >> > > >>>>>>>> wrote:
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>> as long as the opening/closing/commenting all get
>>> sent
>>> >> to
>>> >> > > >>> the
>>> >> > > >>>>>>>>> mailing
>>> >> > > >>>>>>>>>>>> list or recorded in jira
>>> >> > > >>>>>>>>>>>> Yeah, this is my impression as well, that we need to
>>> keep
>>> >> > > >>> certain
>>> >> > > >>>>>>>>> paper
>>> >> > > >>>>>>>>>>>> trail regarding activities and comments on ASF side
>>> >> (JIRA or
>>> >> > > >>> mail
>>> >> > > >>>>>>>>> list).
>>> >> > > >>>>>>>>>>>> Infra page said:
>>> >> > > >>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>> - Any Pull Request that gets opened, closed,
>>> reopened or
>>> >> > > >>>>>>>>> **commented**
>>> >> > > >>>>>>>>>>>> on now gets recorded on the project's mailing list
>>> >> > > >>>>>>>>>>>> - If a project has a JIRA instance, any PRs or
>>> >> *comments* on
>>> >> > > >>> PRs
>>> >> > > >>>>>>>>> that
>>> >> > > >>>>>>>>>>>> include a JIRA ticket ID will trigger an update on
>>> that
>>> >> > > >>> specific
>>> >> > > >>>>>>>>>> ticket
>>> >> > > >>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>> I checked a couple Kafka and Spark JIRAs but I don't
>>> see
>>> >> any
>>> >> > > >>> of
>>> >> > > >>>>>>> the
>>> >> > > >>>>>>>>>>>> comments made in github PR were posted on JIRA,
>>> except
>>> >> the
>>> >> > > >>>>>>>> activities
>>> >> > > >>>>>>>>>> (open
>>> >> > > >>>>>>>>>>>> a PR, close a PR). Since both projects have been
>>> using
>>> >> > github
>>> >> > > >>> for
>>> >> > > >>>>>>> a
>>> >> > > >>>>>>>>>> while I
>>> >> > > >>>>>>>>>>>> assume such practice of NOT integrating comments
>>> between
>>> >> > > >>> github
>>> >> > > >>>>>>> and
>>> >> > > >>>>>>>>> ASF
>>> >> > > >>>>>>>>>>>> JIRA is acceptable? Though I feel it would be really
>>> >> useful
>>> >> > if
>>> >> > > >>>>>>>>> comments
>>> >> > > >>>>>>>>>>>> could converge in a single place as well, that will
>>> >> provide
>>> >> > a
>>> >> > > >>>>>>> clear
>>> >> > > >>>>>>>>>> history
>>> >> > > >>>>>>>>>>>> for a given technical issue.
>>> >> > > >>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>> On Tue, Oct 4, 2016 at 12:06 PM, Flavio Junqueira <
>>> >> > > >>>> fpj@apache.org
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>>>> wrote:
>>> >> > > >>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>> Until ZOOKEEPER-2597 <https://issues.apache.org/
>>> >> > > >>>>>>>>>>>> jira/browse/ZOOKEEPER-2597>
>>> >> > > >>>>>>>>>>>>> is fixed, we can't merge via github.
>>> >> > > >>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>> For code reviews, we can use GH as long as the
>>> >> > > >>>>>>>>>> opening/closing/commenting
>>> >> > > >>>>>>>>>>>>> all get sent to the mailing list or recorded in
>>> jira. I
>>> >> > don't
>>> >> > > >>>>>>> think
>>> >> > > >>>>>>>>> we
>>> >> > > >>>>>>>>>>>> have
>>> >> > > >>>>>>>>>>>>> that yet, but it is possible according to this:
>>> >> > > >>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>> https://blogs.apache.org/infra/entry/improved_
>>> >> > > >>>>>>>>>>>>> integration_between_apache_and <
>>> >> https://blogs.apache.org/
>>> >> > > >>>>>>>>>>>>> infra/entry/improved_integrati
>>> on_between_apache_and>
>>> >> > > >>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>> For now, we do need to upload patches and converge
>>> using
>>> >> > > >>> jira.
>>> >> > > >>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>> I think Eddie has been looking at this process
>>> trying to
>>> >> > > >>>>>>> replicate
>>> >> > > >>>>>>>>> the
>>> >> > > >>>>>>>>>>>>> Kafka setup, so perhaps he can give an update if I'm
>>> >> right.
>>> >> > > >>>> Kafka
>>> >> > > >>>>>>>>>> doesn't
>>> >> > > >>>>>>>>>>>>> send every comment to the mailing list, though, but
>>> I'm
>>> >> not
>>> >> > > >>> sure
>>> >> > > >>>>>>> if
>>> >> > > >>>>>>>>>>>> that's
>>> >> > > >>>>>>>>>>>>> acceptable according to the ASF, I need to
>>> double-check.
>>> >> > > >>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>> -Flavio
>>> >> > > >>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>> On 04 Oct 2016, at 19:42, Michael Han <
>>> >> hanm@cloudera.com>
>>> >> > > >>>>>>> wrote:
>>> >> > > >>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>> Hi,
>>> >> > > >>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>> Now we've moved to git, what is the policy for
>>> >> uploading
>>> >> > > >>>> patches
>>> >> > > >>>>>>>> and
>>> >> > > >>>>>>>>>>>>> doing
>>> >> > > >>>>>>>>>>>>>> code reviews? I am asking because I've seen
>>> recently
>>> >> there
>>> >> > > >>> are
>>> >> > > >>>>>>> git
>>> >> > > >>>>>>>>>> pull
>>> >> > > >>>>>>>>>>>>>> requests coming in without associated patch file
>>> >> uploaded
>>> >> > to
>>> >> > > >>>>>>> JIRA.
>>> >> > > >>>>>>>>>> I've
>>> >> > > >>>>>>>>>>>>>> checked
>>> >> > > >>>>>>>>>>>>>> https://cwiki.apache.org/confl
>>> uence/display/ZOOKEEPER/
>>> >> > > >>>>>>>>> HowToContribute
>>> >> > > >>>>>>>>>> ,
>>> >> > > >>>>>>>>>>>>>> looks like there is not much change regarding patch
>>> >> > process
>>> >> > > >>> -
>>> >> > > >>>> so
>>> >> > > >>>>>>>>>>>>> presumably
>>> >> > > >>>>>>>>>>>>>> we still need to generate and upload patch file to
>>> JIRA
>>> >> > for
>>> >> > > >>> the
>>> >> > > >>>>>>>>>> record,
>>> >> > > >>>>>>>>>>>>>> while using github (maybe in addition of review
>>> board,
>>> >> or
>>> >> > in
>>> >> > > >>>> the
>>> >> > > >>>>>>>>>> future
>>> >> > > >>>>>>>>>>>>>> with gerrit) to do code reviews?
>>> >> > > >>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>> On Wed, Sep 21, 2016 at 6:05 AM, Edward Ribeiro <
>>> >> > > >>>>>>>>>>>>> edward.ribeiro@gmail.com>
>>> >> > > >>>>>>>>>>>>>> wrote:
>>> >> > > >>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>> Cool, just open https://issues.apache.org/
>>> >> > > >>>>>>>>> jira/browse/ZOOKEEPER-2597
>>> >> > > >>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>> PS: I removed the REPO_HOME global variable.
>>> >> > > >>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>> On Wed, Sep 21, 2016 at 6:53 AM, Flavio Junqueira
>>> <
>>> >> > > >>>>>>>> fpj@apache.org>
>>> >> > > >>>>>>>>>>>>> wrote:
>>> >> > > >>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>> Better to have that in the form of a pull
>>> request or
>>> >> > diff.
>>> >> > > >>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>> REPO_HOME does seem to be unused.
>>> >> > > >>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>> -Flavio
>>> >> > > >>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>> On 20 Sep 2016, at 18:57, Edward Ribeiro <
>>> >> > > >>>>>>>>> edward.ribeiro@gmail.com
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>> wrote:
>>> >> > > >>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>> Hey, I have started porting the kafka-merge.py
>>> to
>>> >> work
>>> >> > > >>> on ZK
>>> >> > > >>>>>>>>> repos.
>>> >> > > >>>>>>>>>>>> I
>>> >> > > >>>>>>>>>>>>>>>> would
>>> >> > > >>>>>>>>>>>>>>>>> need someone to review it and help me test it
>>> now.
>>> >> > > >>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>> The files were uploaded below, but I will
>>> create a
>>> >> > github
>>> >> > > >>>>>>> repo
>>> >> > > >>>>>>>>> yet
>>> >> > > >>>>>>>>>>>>>>> today.
>>> >> > > >>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>> https://www.dropbox.com/sh/od8bet2574jttm3/
>>> >> > > >>>>>>>>>>>>>>>> AADv1DXTb8vfyVCmelFbYCEha?dl=0
>>> >> > > >>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>> I uploaded the kafka version script so that you
>>> can
>>> >> use
>>> >> > > >>> diff
>>> >> > > >>>>>>> or
>>> >> > > >>>>>>>>>> Meld
>>> >> > > >>>>>>>>>>>>> to
>>> >> > > >>>>>>>>>>>>>>>>> spot my changes, but feel free to grasp the
>>> original
>>> >> > file
>>> >> > > >>>>>>> here:
>>> >> > > >>>>>>>>>>>>>>>>> https://github.com/apache/
>>> >> > kafka/blob/trunk/kafka-merge-
>>> >> > > >>>> pr.py
>>> >> > > >>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>> PS: It's just me or REPO_HOME env variable is
>>> not
>>> >> used
>>> >> > > >>>>>>> anywhere
>>> >> > > >>>>>>>>> in
>>> >> > > >>>>>>>>>>>> the
>>> >> > > >>>>>>>>>>>>>>>>> merge script???
>>> >> > > >>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>> Cheers,
>>> >> > > >>>>>>>>>>>>>>>>> Eddie
>>> >> > > >>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>> On Tue, Sep 20, 2016 at 12:19 PM, Patrick Hunt <
>>> >> > > >>>>>>>> phunt@apache.org
>>> >> > > >>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>> wrote:
>>> >> > > >>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>> On Mon, Sep 19, 2016 at 4:11 PM, Benjamin Reed
>>> <
>>> >> > > >>>>>>>>> breed@apache.org>
>>> >> > > >>>>>>>>>>>>>>>> wrote:
>>> >> > > >>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>> what you are suggesting sounds good, but i
>>> don't
>>> >> know
>>> >> > > >>> how
>>> >> > > >>>>>>> to
>>> >> > > >>>>>>>> do
>>> >> > > >>>>>>>>>>>> it?
>>> >> > > >>>>>>>>>>>>>>>> since
>>> >> > > >>>>>>>>>>>>>>>>>>> in the end we are still just accepting diffs
>>> on
>>> >> > > >>> patches,
>>> >> > > >>>>>>> the
>>> >> > > >>>>>>>>> only
>>> >> > > >>>>>>>>>>>>>>> thing
>>> >> > > >>>>>>>>>>>>>>>>>>> that changes is that we use svn rather than
>>> git
>>> >> > right?
>>> >> > > >>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>> Notice the workflow Kafka uses - which includes
>>> >> "git
>>> >> > > >>> apply"
>>> >> > > >>>>>>>> and
>>> >> > > >>>>>>>>>>>>>>>> specifying
>>> >> > > >>>>>>>>>>>>>>>>>> the author tag when committers commit (so that
>>> the
>>> >> OP
>>> >> > > >>> gets
>>> >> > > >>>>>>>>> proper
>>> >> > > >>>>>>>>>>>>>>>>>> attribution in the commit itself)
>>> >> > > >>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>> https://cwiki.apache.org/confl
>>> uence/display/KAFKA/
>>> >> > > >>>>>>>>>>>>>>>> Manual+Commit+Workflow
>>> >> > > >>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>> Patrick
>>> >> > > >>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>> i LOVE chris's idea! lets do it!
>>> >> > > >>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>> ben
>>> >> > > >>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>> On Sun, Sep 18, 2016 at 3:22 PM, Patrick Hunt
>>> <
>>> >> > > >>>>>>>>> phunt@apache.org>
>>> >> > > >>>>>>>>>>>>>>>> wrote:
>>> >> > > >>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>> Ben, do you also want to update the
>>> "Applying a
>>> >> > patch"
>>> >> > > >>>>>>>> section
>>> >> > > >>>>>>>>>> to
>>> >> > > >>>>>>>>>>>>>>> make
>>> >> > > >>>>>>>>>>>>>>>>>> it
>>> >> > > >>>>>>>>>>>>>>>>>>>> git specific?
>>> >> > > >>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>> We (committers) should move to a model where
>>> >> authors
>>> >> > > >>> get
>>> >> > > >>>>>>>>> proper
>>> >> > > >>>>>>>>>>>>>>> credit
>>> >> > > >>>>>>>>>>>>>>>>>> in
>>> >> > > >>>>>>>>>>>>>>>>>>>> git. Our old workflow in svn resulted in
>>> only the
>>> >> > > >>>>>>> committer
>>> >> > > >>>>>>>>>> being
>>> >> > > >>>>>>>>>>>>>>>>>> listed
>>> >> > > >>>>>>>>>>>>>>>>>>>> (except that we listed the patch author in
>>> the
>>> >> > commit
>>> >> > > >>>>>>>>> message).
>>> >> > > >>>>>>>>>>>> We
>>> >> > > >>>>>>>>>>>>>>>>>> should
>>> >> > > >>>>>>>>>>>>>>>>>>>> move to a model where the author of the patch
>>> >> gets
>>> >> > > >>> proper
>>> >> > > >>>>>>>>> credit
>>> >> > > >>>>>>>>>>>> in
>>> >> > > >>>>>>>>>>>>>>>>>> git.
>>> >> > > >>>>>>>>>>>>>>>>>>> I
>>> >> > > >>>>>>>>>>>>>>>>>>>> believe we will get that if we use git for
>>> patch
>>> >> > > >>>>>>>>>>>>>>> creation/application?
>>> >> > > >>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>> Chris brought up getting rid of CHANGES.txt
>>> >> recently
>>> >> > > >>> on
>>> >> > > >>>>>>> the
>>> >> > > >>>>>>>>> dev
>>> >> > > >>>>>>>>>>>>> list
>>> >> > > >>>>>>>>>>>>>>>>>> in a
>>> >> > > >>>>>>>>>>>>>>>>>>>> separate thread - Chris do you want to
>>> implement
>>> >> > that
>>> >> > > >>>>>>> change
>>> >> > > >>>>>>>>> now
>>> >> > > >>>>>>>>>>>>>>> that
>>> >> > > >>>>>>>>>>>>>>>>>>> we've
>>> >> > > >>>>>>>>>>>>>>>>>>>> moved to git?
>>> >> > > >>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>> Patrick
>>> >> > > >>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>> On Wed, Sep 14, 2016 at 9:01 PM, Benjamin
>>> Reed <
>>> >> > > >>>>>>>>>> breed@apache.org
>>> >> > > >>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>> wrote:
>>> >> > > >>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>>>> 1) actually in the previous step that was
>>> just
>>> >> > > >>> adding
>>> >> > > >>>>>>> new
>>> >> > > >>>>>>>>>>>> files.
>>> >> > > >>>>>>>>>>>>>>> you
>>> >> > > >>>>>>>>>>>>>>>>>>>>>> still
>>> >> > > >>>>>>>>>>>>>>>>>>>>>>> need the commit -a for the rest of the
>>> >> changes.
>>> >> > > >>> that's
>>> >> > > >>>>>>> my
>>> >> > > >>>>>>>>>>>> normal
>>> >> > > >>>>>>>>>>>>>>>>>>>>>> workflow.
>>> >> > > >>>>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>>>> I think that will be confusing for most
>>> folks.
>>> >> > They
>>> >> > > >>>>>>>>> typically
>>> >> > > >>>>>>>>>>>>>>> stage
>>> >> > > >>>>>>>>>>>>>>>>>>>>>> all the changes and then commit or don't
>>> stage
>>> >> and
>>> >> > > >>> use
>>> >> > > >>>>>>> -a.
>>> >> > > >>>>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>>> do you mind fixing it with your workflow.
>>> >> commit -a
>>> >> > > >>>>>>> doesn't
>>> >> > > >>>>>>>>> get
>>> >> > > >>>>>>>>>>>>> new
>>> >> > > >>>>>>>>>>>>>>>>>>>>> files, which is why you need to do the add,
>>> but
>>> >> i'm
>>> >> > > >>> not
>>> >> > > >>>>>>> the
>>> >> > > >>>>>>>>>> most
>>> >> > > >>>>>>>>>>>>>>>>>>>>> sophisticated git user, so
>>> >> > > >>>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>>>>> 2) i figured since we are using git now
>>> that
>>> >> we
>>> >> > > >>> should
>>> >> > > >>>>>>>> use
>>> >> > > >>>>>>>>>>>> git's
>>> >> > > >>>>>>>>>>>>>>>>>>>>>> default.
>>> >> > > >>>>>>>>>>>>>>>>>>>>>>> the patch should work (by default it
>>> seems to
>>> >> > strip
>>> >> > > >>>> the
>>> >> > > >>>>>>>>> first
>>> >> > > >>>>>>>>>>>>>>> path
>>> >> > > >>>>>>>>>>>>>>>>>>>>>> element).
>>> >> > > >>>>>>>>>>>>>>>>>>>>>>> does it not work for you?
>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>>>> It will fail precommit in it's current
>>> state.
>>> >> > > >>>>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>>> fixed
>>> >> > > >>>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>> --
>>> >> > > >>>>>>>>>>>>>> Cheers
>>> >> > > >>>>>>>>>>>>>> Michael.
>>> >> > > >>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>> --
>>> >> > > >>>>>>>>>>>> Cheers
>>> >> > > >>>>>>>>>>>> Michael.
>>> >> > > >>>>>>>>>>>>
>>> >> > > >>>>>>>>>>
>>> >> > > >>>>>>>>>>
>>> >> > > >>>>>>>>>
>>> >> > > >>>>>>>>>
>>> >> > > >>>>>>>>> --
>>> >> > > >>>>>>>>> Cheers
>>> >> > > >>>>>>>>> Michael.
>>> >> > > >>>>>>>>>
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>
>>> >> > > >>>>>
>>> >> > > >>>>>
>>> >> > > >>>>
>>> >> > > >>>>
>>> >> > > >>>> --
>>> >> > > >>>> Cheers
>>> >> > > >>>> Michael.
>>> >> > > >>>>
>>> >> > > >>>
>>> >> > > >>
>>> >> > > >>
>>> >> > > >>
>>> >> > > >> --
>>> >> > > >> Cheers
>>> >> > > >> Michael.
>>> >> > > >>
>>> >> > > >
>>> >> > > >
>>> >> > > >
>>> >> > > > --
>>> >> > > > Cheers
>>> >> > > > Michael.
>>> >> > >
>>> >> > >
>>> >> >
>>> >>
>>> >
>>>
>>
>>
>

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