cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giles Sirett <giles.sir...@shapeblue.com>
Subject RE: [DISCUSS] Relax strict requirement of JIRA ID for PRs
Date Wed, 14 Mar 2018 10:57:32 GMT
Boris does have a valid point

We have to imagine a user - think of somebody installing cloudstack long  after a version
release.

They hit  problem, they google that problem. If its already been seen, they will *usually*
find a JIRA ticket which describes their problem and (depending on whether it has been fixed)
describe the fix, version numbers,etc

Think of JIRA as a documentation platform

As a non-developer, trying to decipher a PR and its comments simply does not give me that
same functionality. It may give people on this list what they want, but not necessarily users

Having said all of that, the discussion here has been about moving to Github issues. AKAIK,
that would recreate the functionality that I describe above - so his may be a moot point






Kind regards
Giles

giles.sirett@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-----Original Message-----
From: Daan Hoogland <daan.hoogland@gmail.com> 
Sent: 14 March 2018 10:05
To: dev <dev@cloudstack.apache.org>
Subject: Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

Let me add to the below that I do think a ticketing system is a big help for keeping track
of *un*implemented changes and *un*fixed bugs.

On Wed, Mar 14, 2018 at 11:04 AM, Daan Hoogland <daan.hoogland@gmail.com>
wrote:

> Boris, I hate to be strongly opinionated but I have to violently 
> disagree with you on some things here;
>
> On Wed, Mar 14, 2018 at 9:48 AM, Boris Stoyanov < 
> boris.stoyanov@shapeblue.com> wrote:
>
>> Hi all,
>>
>> I do understand your point as developers if you want to fix something 
>> just open the PR and not deal with any extra details like JIRA 
>> tickets and etc, but I must say that JIRA tickets are quite often 
>> looked up from users as they experience an issue.
>
> ​It is not more or less effort for users to look up github PRs than 
> Jira tickets. They still need to be clever about search terms and 
> still might miss out.
> ​
>
>
>> Let’s say we’ve fixed an annoying UI bug in master and there’s no 
>> ticket for it in JIRA. As a user, if you try to search for this 
>> particular issue where would you go? In JIRA or GitHub? How would you 
>> know which release to pickup if you’re just an infrastructure guy and not following
Github.
>>
> ​What is following here and why not Github but Jira.​ ​
>
>
>>
>> Tracking every change with such tool is proven good practice in SDLC,
>
> ​No it is not. Absolutely not. That is what we have revision control
> systems for. Your good practice is only true for enterprise controlled
> projects. In cloudstack there are a lot of wild forks because this
> enterprisy way of controlling change has pushed people away from
> mainstream. This is a force to be reckoned with and we can not completely
> ban it, but we have to minimise it if we want to survive as project.
> ​
>
>
>> it brings visibility and it’s a tool meant to be used not only from
>> developers, but from everyone involved in the project.
>>
> ​How is this true for Jira anywhere near as much as it is true for github?​
>
>
>
>>
>> I also got the feeling that lacking a JIRA ticket could become a common
>> practice in community submission and it’s yet another reason for me to be
>> -1 on this.
>
> ​Another reason to be very much +1 on it. That is a good thing. Think
> about it. People submistting features and bugfixes instead of asking for
> them in a ticket. That is great.
> ​
>
>
>> Also I don’t think it’s causing big overhead, since it’s being updated
>> mostly automatically.
>>
> ​No it is not. What is done automatically? put in progress?? closing?
> undertest status? Only noise is added to those tickets automatically.
> ​
>
>
>>
>> Boris Stoyanov
>>
>>
>> boris.stoyanov@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>> @shapeblue
>>
>>
>>
>> > On 13 Mar 2018, at 17:01, Khosrow Moossavi <kmoossavi@cloudops.com>
>> wrote:
>> >
>> > I'm completely +1 on using GH as source of truth, both PR and issue
>> wise,
>> > with Daan comment regarding Apache rules in mind.
>> > At least it doesn't need to have "yet another" integration to do
>> automated
>> > actions on an issue (such as auto close an issue by "Fixes NUMBER",
>> > "Closes NUMBER") directly from commit or PR body.
>> >
>> > Khosrow Moossavi
>> > CloudOps
>> >
>> > On Tue, Mar 13, 2018 at 10:11 AM, Syed Ahmed <sahmed@cloudops.com>
>> wrote:
>> >
>> >> I agree with the relaxation as Rohit pointed out. At this point we
>> should
>> >> ask if Jira is really needed. Most people here I believe agree that it
>> is
>> >> not. The only reason we have Jira is to track releases. This could
>> easily
>> >> be replicated in GitHub as I see that GitHub is the place where we all
>> >> collaborate. I would be completely in if we use GitHub issues and like
>> it
>> >> with Jira as we do with our PRs.
>> >>
>> >>
>> >> On Tue, Mar 13, 2018 at 10:03 AM Rafael Weingärtner <
>> >> rafaelweingartner@gmail.com> wrote:
>> >>
>> >>> I was checking and for some reason ACS does not have an issue tab (
>> >>> https://github.com/apache/cloudstack/issues). It might be some
>> >>> configuration in the repository.
>> >>>
>> >>> On Tue, Mar 13, 2018 at 10:54 AM, Rafael Weingärtner <
>> >>> rafaelweingartner@gmail.com> wrote:
>> >>>
>> >>>> What do you mean by issue? PR or issue (Github issue)?
>> >>>>
>> >>>> On Tue, Mar 13, 2018 at 10:53 AM, Daan Hoogland <
>> >> daan.hoogland@gmail.com
>> >>>>
>> >>>> wrote:
>> >>>>
>> >>>>> right, also when an issue is created?
>> >>>>>
>> >>>>>
>> >>>>> On Tue, Mar 13, 2018 at 2:50 PM, Rafael Weingärtner <
>> >>>>> rafaelweingartner@gmail.com> wrote:
>> >>>>>
>> >>>>>> We already have. All messages on ACS' GH go to commits@c.a.o
>> >>>>>>
>> >>>>>> On Tue, Mar 13, 2018 at 10:49 AM, Daan Hoogland <
>> >>>>> daan.hoogland@gmail.com>
>> >>>>>> wrote:
>> >>>>>>
>> >>>>>>> Ok, one issue there is Apache foundation rules. If we
copy every
>> >>> thing
>> >>>>>> into
>> >>>>>>> jira or the mail list we are fine, where ever we have
our
>> >>> discussions.
>> >>>>>> The
>> >>>>>>> only thing is that we need a Apache hosted record. (as
in not
>> >>> github)
>> >>>>>>>
>> >>>>>>> On Tue, Mar 13, 2018 at 2:09 PM, Rafael Weingärtner
<
>> >>>>>>> rafaelweingartner@gmail.com> wrote:
>> >>>>>>>
>> >>>>>>>> I prefer the workflow in Github as you guy, but
to be fair with
>> >>> Jira
>> >>>>>>> ticket
>> >>>>>>>> system I mentioned it.
>> >>>>>>>>
>> >>>>>>>> @Marc, yes Jira can facilitate a lot the management.
However, we
>> >>> do
>> >>>>> not
>> >>>>>>> use
>> >>>>>>>> it fully. In our workflow, there is no planning/roadmap
for the
>> >>> next
>> >>>>>>>> release per se. Things seem to work in an ad-hoc
fashion. On the
>> >>>>> other
>> >>>>>>>> hand, when you need to break down milestones into
>> >>>>> issues/tickets/tasks
>> >>>>>>> and
>> >>>>>>>> then divide them into sprints, and manage a team
of developers,
>> >>> the
>> >>>>>>>> oversight provided by Jira system is very good;
specially, when
>> >>>>> issues
>> >>>>>>>> start to take more than a single sprint to finish.
>> >>>>>>>>
>> >>>>>>>> On Tue, Mar 13, 2018 at 9:44 AM, Marc-Aurèle Brothier
<
>> >>>>>> marco@exoscale.ch
>> >>>>>>>>
>> >>>>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>>> @rafael, you said: they all required Jira tickets
to track the
>> >>>>>>> discussion
>> >>>>>>>>> and facilitate the management
>> >>>>>>>>>
>> >>>>>>>>> I can see the discussion happening in the PR
on github, but
>> >> the
>> >>>>> Jira
>> >>>>>>>> ticket
>> >>>>>>>>> by itself doesn't do much, except copy/pasting
the github
>> >>>>> discussion.
>> >>>>>>>> Then
>> >>>>>>>>> it's down to "facilitate the management", which
I only see as
>> >>>>> listing
>> >>>>>>> the
>> >>>>>>>>> changes for a release as far as I know. But
this can be
>> >> achieved
>> >>>>> on
>> >>>>>>>> github
>> >>>>>>>>> too.
>> >>>>>>>>>
>> >>>>>>>>> As Daan mentioned, there are those things that
are not code
>> >>>>> related
>> >>>>>>> which
>> >>>>>>>>> should have a way of tracking. But what's the
difference in
>> >>>>> tracking
>> >>>>>>> them
>> >>>>>>>>> as a Jira issue vs a Github issue (they can't
be a PR)? Those
>> >>> are
>> >>>>>> point
>> >>>>>>>> of
>> >>>>>>>>> view exchanges with messages & links, with
a final status,
>> >> most
>> >>> of
>> >>>>>> the
>> >>>>>>>> time
>> >>>>>>>>> without a strong link to a release number. If
they do, they
>> >> can
>> >>> be
>> >>>>>>> added
>> >>>>>>>> to
>> >>>>>>>>> a milestone.
>> >>>>>>>>>
>> >>>>>>>>> So far I don't see how things done with Jira
cannot be
>> >> achieved
>> >>> on
>> >>>>>>>> Github.
>> >>>>>>>>> It's just a matter of changing habits to simplify
the workflow
>> >>> for
>> >>>>>> new
>> >>>>>>>>> comers (and old joiners too ;-) ).
>> >>>>>>>>>
>> >>>>>>>>> On Tue, Mar 13, 2018 at 1:02 PM, Daan Hoogland
<
>> >>>>>>> daan.hoogland@gmail.com>
>> >>>>>>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>>> Will, you are speaking my mind; any external
registration
>> >> tool
>> >>>>>> should
>> >>>>>>>> be
>> >>>>>>>>>> based on the source. The only reason for
having an external
>> >>> tool
>> >>>>>>>> without
>> >>>>>>>>>> relation to the code is to keep track of
what is *not* (or
>> >> not
>> >>>>>> fully)
>> >>>>>>>>>> implemented.
>> >>>>>>>>>>
>> >>>>>>>>>> On Tue, Mar 13, 2018 at 12:58 PM, Rafael
Weingärtner <
>> >>>>>>>>>> rafaelweingartner@gmail.com> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>>> I meant a way of describing them (changes/proposals)
>> >>> further.
>> >>>>>>>> Sometimes
>> >>>>>>>>>> we
>> >>>>>>>>>>> have commits only with title, and then
the Jira ticket
>> >> would
>> >>>>> be a
>> >>>>>>> way
>> >>>>>>>>> of
>> >>>>>>>>>>> documenting that commit. I do prefer
the idea of inserting
>> >>> the
>> >>>>>>> whole
>> >>>>>>>>>>> description in the commit body though.
[for me] it looks
>> >>>>> easier
>> >>>>>> to
>> >>>>>>>> work
>> >>>>>>>>>>> directly with commits and PRs; as you
said, we can
>> >> generate
>> >>>>>> release
>> >>>>>>>>> notes
>> >>>>>>>>>>> based on commits directly [and issues
on GH]. However, for
>> >>>>> that,
>> >>>>>> we
>> >>>>>>>>> need
>> >>>>>>>>>> to
>> >>>>>>>>>>> fine-tune our workflow.
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> On Tue, Mar 13, 2018 at 8:40 AM, Will
Stevens <
>> >>>>>>> wstevens@cloudops.com
>> >>>>>>>>>
>> >>>>>>>>>>> wrote:
>> >>>>>>>>>>>
>> >>>>>>>>>>>> I am +1 to relaxing the requirement
of Jira ticket.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Rafael, what do you mean when you
say "Jira tickets are
>> >>>>> used to
>> >>>>>>>>>> register
>> >>>>>>>>>>>> changes"?
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> I think ever since 4.9 the actual
PRs included in the
>> >> code
>> >>>>> are
>> >>>>>>> the
>> >>>>>>>>>> source
>> >>>>>>>>>>>> of truth for the changes in the
actual code (at least
>> >>> from a
>> >>>>>>>> release
>> >>>>>>>>>>> notes
>> >>>>>>>>>>>> perspective).  This is why the release
notes can show
>> >>>>> changes
>> >>>>>>> that
>> >>>>>>>>> only
>> >>>>>>>>>>>> have PRs and no Jira ticket.  At
least my release notes
>> >>>>>> generator
>> >>>>>>>> is
>> >>>>>>>>>>> built
>> >>>>>>>>>>>> that way.  I think Rohit has built
a similar release
>> >> notes
>> >>>>>>>> generator,
>> >>>>>>>>>> so
>> >>>>>>>>>>> I
>> >>>>>>>>>>>> can't speak to his version...
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> *Will Stevens*
>> >>>>>>>>>>>> Chief Technology Officer
>> >>>>>>>>>>>> c 514.826.0190
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> <https://goo.gl/NYZ8KK>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> On Tue, Mar 13, 2018 at 6:42 AM,
Rafael Weingärtner <
>> >>>>>>>>>>>> rafaelweingartner@gmail.com>
wrote:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> Marc, yes Jira tickets are used
to register changes.
>> >>>>> However,
>> >>>>>>>> what
>> >>>>>>>>>>> Rohit
>> >>>>>>>>>>>>> and others (including me) are
noticing is that there
>> >> are
>> >>>>>>> certain
>> >>>>>>>>>> types
>> >>>>>>>>>>> of
>> >>>>>>>>>>>>> changes (minor/bureaucracy)
that do not require Jira
>> >>>>> tickets.
>> >>>>>>> The
>> >>>>>>>>>> issue
>> >>>>>>>>>>>> is
>> >>>>>>>>>>>>> the wording “change”. What
consist of a change that is
>> >>>>> worth
>> >>>>>>>>>> mentioning
>> >>>>>>>>>>>> in
>> >>>>>>>>>>>>> the release notes? Everything
we do in a branch is a
>> >>>>> change
>> >>>>>>>>> towards a
>> >>>>>>>>>>>>> release, but not everything
is useful for
>> >>>>>>>> operators/administrators
>> >>>>>>>>> to
>> >>>>>>>>>>>> see.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> I would say that to fix bugs,
introduce new features,
>> >>>>> extend
>> >>>>>>>>> existing
>> >>>>>>>>>>>>> features, introduce a major
change in the code such as
>> >>>>> that
>> >>>>>>>>> standard
>> >>>>>>>>>>>> maven
>> >>>>>>>>>>>>> thing that you did, they all
required Jira tickets to
>> >>>>> track
>> >>>>>> the
>> >>>>>>>>>>>> discussion
>> >>>>>>>>>>>>> and facilitate the management.
On the other side of
>> >> the
>> >>>>>>> spectrum,
>> >>>>>>>>> we
>> >>>>>>>>>>> have
>> >>>>>>>>>>>>> things such as removing dead/unused
code, opening a
>> >> new
>> >>>>>> version
>> >>>>>>>>>>> (creating
>> >>>>>>>>>>>>> the upgrade path that we still
use for the DB), fix a
>> >>>>>>> description
>> >>>>>>>>> in
>> >>>>>>>>>> an
>> >>>>>>>>>>>> API
>> >>>>>>>>>>>>> method, and so on. Moreover,
the excessive use of Jira
>> >>>>>> tickets
>> >>>>>>>>> leads
>> >>>>>>>>>> to
>> >>>>>>>>>>>>> hundreds of Jira tickets that
we do not know that
>> >> status
>> >>>>> of.
>> >>>>>> We
>> >>>>>>>>> have
>> >>>>>>>>>>>> quite
>> >>>>>>>>>>>>> a big number of tickets opened
that could be closed.
>> >>> This
>> >>>>> has
>> >>>>>>>> been
>> >>>>>>>>>>> worse;
>> >>>>>>>>>>>>> we are improving as time goes
by.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> I would say that to make this
more transparent to
>> >> others
>> >>>>>>>>> (especially
>> >>>>>>>>>>>>> newcomers), we need to discuss
it, then write it down
>> >> to
>> >>>>> make
>> >>>>>>> it
>> >>>>>>>>>>>>> transparent the way we are working.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> On Tue, Mar 13, 2018 at 6:59
AM, Marc-Aurèle Brothier
>> >> <
>> >>>>>>>>>>> marco@exoscale.ch
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> That's a good idea, because
people are more and more
>> >>>>> used
>> >>>>>> to
>> >>>>>>>> only
>> >>>>>>>>>>>> create
>> >>>>>>>>>>>>> PR
>> >>>>>>>>>>>>>> on github, and it would
be helpful to be more
>> >>>>> explanatory
>> >>>>>> on
>> >>>>>>>> the
>> >>>>>>>>>> way
>> >>>>>>>>>>> we
>> >>>>>>>>>>>>>> work to push changes. I
still think we should
>> >>> encourage
>> >>>>> the
>> >>>>>>> use
>> >>>>>>>>> of
>> >>>>>>>>>>> the
>> >>>>>>>>>>>>>> github milestone as Rohit
did with the 4.11.0 (
>> >>>>>>>>>>>>>> https://github.com/apache/clou
>> >>>>> dstack/milestone/3?closed=1)
>> >>>>>>> to
>> >>>>>>>>> list
>> >>>>>>>>>>> the
>> >>>>>>>>>>>>>> changes in the release notes
with the help of the
>> >>>>> labels to
>> >>>>>>> tag
>> >>>>>>>>> the
>> >>>>>>>>>>> PRs
>> >>>>>>>>>>>>>> instead of relying on the
jira ticket (it requires
>> >> to
>> >>>>> have
>> >>>>>>>>> another
>> >>>>>>>>>>>>> login).
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> As far as I can remember,
the JIRA tickets are used
>> >> to
>> >>>>> list
>> >>>>>>> the
>> >>>>>>>>>>> changes
>> >>>>>>>>>>>>> of
>> >>>>>>>>>>>>>> a release, but nothing else.
Or am I missing
>> >>> something?
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Marc-Aurèle
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> On Tue, Mar 13, 2018 at
9:57 AM, Rohit Yadav <
>> >>>>>>>>>>>> rohit.yadav@shapeblue.com>
>> >>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> All,
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> To make it easier for
people to contribute changes
>> >>> and
>> >>>>>>>>> encourage
>> >>>>>>>>>>>>>>> PR/contributions, should
we relax the requirement
>> >>> of a
>> >>>>>> JIRA
>> >>>>>>>>>> ticket
>> >>>>>>>>>>>> for
>> >>>>>>>>>>>>>> pull
>> >>>>>>>>>>>>>>> requests that solve
trivial/minor issues such as
>> >> doc
>> >>>>>> bugs,
>> >>>>>>>>> build
>> >>>>>>>>>>>> fixes
>> >>>>>>>>>>>>>> etc?
>> >>>>>>>>>>>>>>> A JIRA ticket may still
be necessary for new
>> >>> features
>> >>>>> and
>> >>>>>>>>>>> non-trivial
>> >>>>>>>>>>>>>>> bugfixes or changes.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> Another alternative
could be to introduce a
>> >>>>>> CONTRIBUTING.md
>> >>>>>>>> [1]
>> >>>>>>>>>>> that
>> >>>>>>>>>>>>>>> explains the list of
expected things to
>> >> contributors
>> >>>>> when
>> >>>>>>>> they
>> >>>>>>>>>>> send a
>> >>>>>>>>>>>>> PR
>> >>>>>>>>>>>>>>> (for example, a jira
id, links to fs or other
>> >>>>> resources,
>> >>>>>> a
>> >>>>>>>>> short
>> >>>>>>>>>>>>> summary
>> >>>>>>>>>>>>>>> and long description,
test results etc).
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> Thoughts?
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> [1] https://help.github.com/articl
>> >>>>> es/setting-guidelines-
>> >>>>>>>>>>>>>>> for-repository-contributors/
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> - Rohit
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> <https://cloudstack.apache.org>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> rohit.yadav@shapeblue.com
>> >>>>>>>>>>>>>>> www.shapeblue.com
>> >>>>>>>>>>>>>>> 53 Chandos Place, Covent
Garden, London  WC2N
>> >> 4HSUK
>> >>>>>>>>>>>>>>> @shapeblue
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> --
>> >>>>>>>>>>>>> Rafael Weingärtner
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> --
>> >>>>>>>>>>> Rafael Weingärtner
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> --
>> >>>>>>>>>> Daan
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> --
>> >>>>>>>> Rafael Weingärtner
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>> Daan
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> --
>> >>>>>> Rafael Weingärtner
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> Daan
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Rafael Weingärtner
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Rafael Weingärtner
>> >>>
>> >>
>>
>>
>
>
> --
> Daan
>



-- 
Daan
Mime
View raw message