Re: Cloudstack collab conference 2018

[Tutkowski, Mike]

I am personally good with this venue and what it provides us. The dates look 
good, as well.

On 3/13/18, 3:01 AM, "Giles Sirett"  wrote:

All
I've been speaking with Rich Bowen about the feasibility of holding another 
Cloudstack Collaboration Conference in conjunction with Apachecon

https://www.apachecon.com/acna18/schedule.html
Apachecon is 24-27 September, Montreal


Rich has said that we can have a room for Monday 24th  + one other day 
(I'm, hoping that would be Tuesday) , so CCC could be 24-25 September

We could probably squeeze in 20 talks across the 2 days and would look to 
bolt on a hackathon at the end on Wednesday 26th (if Apachecon isn't able to 
accommodate the hackathon, we do know a friendly company in Montreal who *may* 
be able to host that)

WE NEED TO MOVE QUICKLY: The CFP for apachecon is already open and closes 
March 30
So, I'd like to get a broad feeling here of support to do this


Theres not much needed to make this happen:

  1.  Confirm with Rich that we want to do this
  2.  Get http://cloudstackcollab.org/ updated - volunteers needed
  3.  Point our community at the exisiting CFP  - and then help on the 
submissions process - volunteers needed
  4.  Promote, etc


Kind regards
Giles


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

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Khosrow Moossavi]

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  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 <
> rafaelweingart...@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 <
> > rafaelweingart...@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.hoogl...@gmail.com
> > >
> > > wrote:
> > >
> > >> right, also when an issue is created?
> > >>
> > >>
> > >> On Tue, Mar 13, 2018 at 2:50 PM, Rafael Weingärtner <
> > >> rafaelweingart...@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.hoogl...@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 <
> > >> > > rafaelweingart...@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 <
> > >> > ma...@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.hoogl...@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
> > 

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Will Stevens]

To add another $0.02 to this conversation, beyond what I posted above.

Ideally, in my humble opinion, we would use Github Issues for issues that
do not currently have code associated with it.  Jira is currently being
used for this and it is useful for users to be able to flag bugs without
knowing how to solve them.  I believe this would require that issues be
turn on for the repo and the details of the issue be pushed to one of our
apache mailing lists.

One of the reasons why Jira has remained in play and we have not gone with
Github Issues in the past was due to security related issues.  I don't
believe we have the ability in Github to have private issues, which I
believe use use in Jira to handle security/CVE related issues.  This is
something we may have to solve for if we do leverage Github Issues, but I
will lets someone closer to how that all goes down comment and confirm or
deny this.

If we could use Github Issues and Github PRs as the only location for
issues and development, I think that would make contribution more
approachable and easier to convey to users.

Those are my additional thoughts...

*Will Stevens*
Chief Technology Officer
c 514.826.0190



On Tue, Mar 13, 2018 at 10:11 AM, Syed Ahmed  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 <
> rafaelweingart...@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 <
> > rafaelweingart...@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.hoogl...@gmail.com
> > >
> > > wrote:
> > >
> > >> right, also when an issue is created?
> > >>
> > >>
> > >> On Tue, Mar 13, 2018 at 2:50 PM, Rafael Weingärtner <
> > >> rafaelweingart...@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.hoogl...@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 <
> > >> > > rafaelweingart...@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 <
> > >> > ma...@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, 

[NOTICE] Remove branches 4.1l10n, 4.2-*, 4.3.0-forward, and 4.4-* from Apache CloudStack official repository

[Rafael Weingärtner]

Following the protocol defined in [1], this is the notice email regarding
the removal branches from Apache CloudStack official repository. The Jira
ticket for the branches removal is
https://issues.apache.org/jira/browse/CLOUDSTACK-10324. The branches that
will be removed are the following:

   - 4.1l10n
   - 4.2-forward
   - 4.2-workplace
   - 4.3.0-forward
   - 4.4-automation
   - 4.4-forward
   - 4.4-forward-iam
   - 4.4-forward-iam-disabled


If you have objections, please do share your concerns before the deletion.
The removal will happen on 22/March/2018.
[1]
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Clean+up+old+and+obsolete+branches+protocol

--
Rafael Weingärtner

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Syed Ahmed]

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 <
rafaelweingart...@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 <
> rafaelweingart...@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  >
> > wrote:
> >
> >> right, also when an issue is created?
> >>
> >>
> >> On Tue, Mar 13, 2018 at 2:50 PM, Rafael Weingärtner <
> >> rafaelweingart...@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.hoogl...@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 <
> >> > > rafaelweingart...@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 <
> >> > ma...@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.hoogl...@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 <
> >> > > > > > rafaelweingart...@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
> >> > 

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Rafael Weingärtner]

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 <
rafaelweingart...@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 
> wrote:
>
>> right, also when an issue is created?
>>
>>
>> On Tue, Mar 13, 2018 at 2:50 PM, Rafael Weingärtner <
>> rafaelweingart...@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.hoogl...@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 <
>> > > rafaelweingart...@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 <
>> > ma...@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.hoogl...@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 <
>> > > > > > rafaelweingart...@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 <
>> > > wstev...@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

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Rafael Weingärtner]

What do you mean by issue? PR or issue (Github issue)?

On Tue, Mar 13, 2018 at 10:53 AM, Daan Hoogland 
wrote:

> right, also when an issue is created?
>
>
> On Tue, Mar 13, 2018 at 2:50 PM, Rafael Weingärtner <
> rafaelweingart...@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  >
> > 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 <
> > > rafaelweingart...@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 <
> > ma...@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.hoogl...@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 <
> > > > > > rafaelweingart...@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 <
> > > wstev...@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 

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Daan Hoogland]

right, also when an issue is created?


On Tue, Mar 13, 2018 at 2:50 PM, Rafael Weingärtner <
rafaelweingart...@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 
> 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 <
> > rafaelweingart...@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 <
> ma...@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.hoogl...@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 <
> > > > > rafaelweingart...@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 <
> > wstev...@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
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > On Tue, Mar 13, 2018 at 6:42 AM, Rafael Weingärtner <
> > > > > > > rafaelweingart...@gmail.com> wrote:
> > > > > > >
> > > > > 

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Rafael Weingärtner]

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 
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 <
> rafaelweingart...@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  >
> > 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.hoogl...@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 <
> > > > rafaelweingart...@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 <
> wstev...@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
> > > > > >
> > > > > > 
> > > > > >
> > > > > > On Tue, Mar 13, 2018 at 6:42 AM, Rafael Weingärtner <
> > > > > > rafaelweingart...@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
> > > > > > 

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Daan Hoogland]

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 <
rafaelweingart...@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 
> 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 
> > 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 <
> > > rafaelweingart...@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  >
> > > > 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
> > > > >
> > > > > 
> > > > >
> > > > > On Tue, Mar 13, 2018 at 6:42 AM, Rafael Weingärtner <
> > > > > rafaelweingart...@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 

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Rafael Weingärtner]

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 
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 
> 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 <
> > rafaelweingart...@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 
> > > 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
> > > >
> > > > 
> > > >
> > > > On Tue, Mar 13, 2018 at 6:42 AM, Rafael Weingärtner <
> > > > rafaelweingart...@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 

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Marc-Aurèle Brothier]

@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 
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 <
> rafaelweingart...@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 
> > 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
> > >
> > > 
> > >
> > > On Tue, Mar 13, 2018 at 6:42 AM, Rafael Weingärtner <
> > > rafaelweingart...@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 <
> > ma...@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/cloudstack/milestone/3?closed=1) to list
> > the
> > > > > changes in the release notes with the help of the labels 

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Daan Hoogland]

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 <
rafaelweingart...@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 
> 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
> >
> > 
> >
> > On Tue, Mar 13, 2018 at 6:42 AM, Rafael Weingärtner <
> > rafaelweingart...@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 <
> ma...@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/cloudstack/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.ya...@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] 

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Rafael Weingärtner]

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  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
>
> 
>
> On Tue, Mar 13, 2018 at 6:42 AM, Rafael Weingärtner <
> rafaelweingart...@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  >
> > 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/cloudstack/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.ya...@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/articles/setting-guidelines-
> > > > for-repository-contributors/
> > > >
> > > >
> > > > - Rohit
> > > >
> > > > 
> > > >
> > > >
> > > >
> > > > rohit.ya...@shapeblue.com
> > > > www.shapeblue.com
> > > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > > > @shapeblue
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Rafael Weingärtner
> >
>



-- 
Rafael Weingärtner

Re: [DISCUSS] CloudStack Connection Pools

[Rafael Weingärtner]

Spring data would be awesome. It is very flexible and has a very good API.
However, this would require commitment from our side to slowly migrate
things to it.

Regarding the connection pool management libraries; I would prefer either
C3P0 or 2.* DBCP. The other two sound trendy, but I worry about this type
of project in the long run. Both DBCP from Apache and C3P0 from Hibernate
(RedHat) sound a more reasonable selection for me. They have been around
for years, and have a solid community base already.

On Mon, Mar 12, 2018 at 11:31 PM, Khosrow Moossavi 
wrote:

> Hi Nicolas
>
> From my past experiences, I prefer 1) HikariCP 2) Tomcat Pool 3) C3P0 4)
> DBCP in that order. Although I don't have
> any benchmark of my own to provide, and the ones you mentioned are really
> informative anyway.
>
> To me the broader subject is the _one_ who uses the pool, I mean if the
> transactions are handled in a faster way and
> released sooner and with shorter locks, generally speaking if it's more
> efficient, I don't think from ACS point of view
> there won't be much difference between the above mentioned options.
>
> On the same subject, it might be more interesting to use Spring Boot in
> general and Spring Boot Data in particular
> rather than only changing the CP functionality, and slowly refactor/retire
> the DAO layer in favor of Spring Boot equivalent
> implementation.
>
>
> Khosrow Moossavi
>
> CloudOps
>
>
>
> On Mon, Mar 12, 2018 at 9:32 PM, Nicolas Vazquez <
> nicolas.vazq...@shapeblue.com> wrote:
>
> > Hi all,
> >
> >
> > I would like to introduce a topic for discussion, regarding DB connection
> > pools used in CloudStack, currently Apache Commons DBCP 1.4 (
> > http://commons.apache.org/) is used. I've been investigating this topic
> > as we are having complains of random issues on MySQL connection pool on
> > large environments. Please let me know if this topic has already been
> > discussed before.
> >
> >
> > First of all, DBCP 1.4 has been released on 2010 (
> > https://commons.apache.org/proper/commons-dbcp/changes-report.html), and
> > no minor/patch version has been released since then. It seems to work in
> > high performance with relatively low traffic and low load applications.
> > However, it is single threaded, and in order to be thread-safe, the
> entire
> > pool needs to be locked. It is also reported that an CPU and concurrent
> > threads increases, the performance gets affected. This is a serious issue
> > on highly concurrent systems, such as CloudStack.
> >
> >
> > I've been investigating some options to replace it:
> > - The first option can be upgrading to version 2.x. Issues on performance
> > and concurrency could be solved using this version.
> > - Tomcat JDBC Connection Pool. Please check: https://tomcat.apache.org/
> > tomcat-7.0-doc/jdbc-pool.html.
> >
> > - Other replacement options found: BoneCP, C3P0, HikariCP
> >
> >
> > Given these options, I've been looking for benchmarks to compare them
> (*).
> > Looks like HikariCP (http://brettwooldridge.github.io/HikariCP/) could
> be
> > the best replacement, improving performance and stability. Another good
> > replacement option could be Tomcat.
> >
> >
> > I've been also examining the codebase, data source initialization is done
> > on TransactionLegacy class under the cloud-framework-db project.
> > Replacement work should be done on this class. Instead of pure
> replacement,
> > a global setting can be introduced to make the admins able to select
> which
> > connection pool to use.
> >
> > What do you think? Any possitive/negative feedback is welcome as well as
> > new ideas. As mentioned before, I don't know if it has been discussed
> > before, sorry in advance if it has.
> >
> > Kind regards,
> > Nicolas
> >
> > (*) Links to benchmarks and comparissons:
> > https://www.wix.engineering/single-post/how-many-threads-
> > does-it-take-to-fill-a-pool
> > https://www.wix.engineering/single-post/how-does-hikaricp-
> > compare-to-other-connection-pools
> >  > compare-to-other-connection-pools>https://beansroasted.
> > wordpress.com/2017/07/29/connection-pool-analysis/
> > https://beansroasted.wordpress.com/tag/connection-pool-comparison/
> > 
> > https://github.com/brettwooldridge/HikariCP/wiki/%22My-benchmark-
> > doesn't-show-a-difference.%22
> > http://www.trustiv.co.uk/2014/06/battle-connection-pools
> >
> > nicolas.vazq...@shapeblue.com
> > www.shapeblue.com
> > ,
> > @shapeblue
> >
> >
> >
> >
>



-- 
Rafael Weingärtner

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Will Stevens]

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



On Tue, Mar 13, 2018 at 6:42 AM, Rafael Weingärtner <
rafaelweingart...@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 
> 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/cloudstack/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 
> > 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/articles/setting-guidelines-
> > > for-repository-contributors/
> > >
> > >
> > > - Rohit
> > >
> > > 
> > >
> > >
> > >
> > > rohit.ya...@shapeblue.com
> > > www.shapeblue.com
> > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > > @shapeblue
> > >
> > >
> > >
> > >
> >
>
>
>
> --
> Rafael Weingärtner
>

RE: Cloudstack collab conference 2018

[Paul Angus]

Is everyone happy with a cutdown collab - with only one track?
I'm seeing quite a refreshing number of new names in the mailing list 
currently, I worry that it will be hard to cater for everyone with just one 
track.

paul.an...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-Original Message-
From: Giles Sirett  
Sent: 13 March 2018 09:01
To: dev@cloudstack.apache.org
Subject: Cloudstack collab conference 2018

All
I've been speaking with Rich Bowen about the feasibility of holding another 
Cloudstack Collaboration Conference in conjunction with Apachecon

https://www.apachecon.com/acna18/schedule.html
Apachecon is 24-27 September, Montreal


Rich has said that we can have a room for Monday 24th  + one other day (I'm, 
hoping that would be Tuesday) , so CCC could be 24-25 September

We could probably squeeze in 20 talks across the 2 days and would look to bolt 
on a hackathon at the end on Wednesday 26th (if Apachecon isn't able to 
accommodate the hackathon, we do know a friendly company in Montreal who *may* 
be able to host that)

WE NEED TO MOVE QUICKLY: The CFP for apachecon is already open and closes March 
30 So, I'd like to get a broad feeling here of support to do this


Theres not much needed to make this happen:

  1.  Confirm with Rich that we want to do this
  2.  Get http://cloudstackcollab.org/ updated - volunteers needed
  3.  Point our community at the exisiting CFP  - and then help on the 
submissions process - volunteers needed
  4.  Promote, etc


Kind regards
Giles


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

Re: Cloudstack collab conference 2018

[Rafael Weingärtner]

Let's do it. We have a short time for CFP, so it is better not to wait much
longer.

The CFP will happen as last year, right? I mean, we will use Apache's main
CFP, and tag our proposals, so they get directed to the right group of
reviewers.

On Tue, Mar 13, 2018 at 6:01 AM, Giles Sirett 
wrote:

> All
> I've been speaking with Rich Bowen about the feasibility of holding
> another Cloudstack Collaboration Conference in conjunction with Apachecon
>
> https://www.apachecon.com/acna18/schedule.html
> Apachecon is 24-27 September, Montreal
>
>
> Rich has said that we can have a room for Monday 24th  + one other day
> (I'm, hoping that would be Tuesday) , so CCC could be 24-25 September
>
> We could probably squeeze in 20 talks across the 2 days and would look to
> bolt on a hackathon at the end on Wednesday 26th (if Apachecon isn't able
> to accommodate the hackathon, we do know a friendly company in Montreal who
> *may* be able to host that)
>
> WE NEED TO MOVE QUICKLY: The CFP for apachecon is already open and closes
> March 30
> So, I'd like to get a broad feeling here of support to do this
>
>
> Theres not much needed to make this happen:
>
>   1.  Confirm with Rich that we want to do this
>   2.  Get http://cloudstackcollab.org/ updated - volunteers needed
>   3.  Point our community at the exisiting CFP  - and then help on the
> submissions process - volunteers needed
>   4.  Promote, etc
>
>
> Kind regards
> Giles
>
>
> giles.sir...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>


-- 
Rafael Weingärtner

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Rafael Weingärtner]

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 
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/cloudstack/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 
> 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/articles/setting-guidelines-
> > for-repository-contributors/
> >
> >
> > - Rohit
> >
> > 
> >
> >
> >
> > rohit.ya...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > @shapeblue
> >
> >
> >
> >
>



-- 
Rafael Weingärtner

Re: [NOTICE] Remove branches “4.6.*-RC*” from Apache CloudStack official repository

[Rafael Weingärtner]

The following branches were removed from our official repository.


   - 4.6.0-RC20151104T1522
   - 4.6.0-RC20151110T1545
   - 4.6.1-RC20151130T2246
   - 4.6.1-RC20151130T2258
   - 4.6.2-RC20151213T1914
   - 4.6.2.1-RC20160525T1218

Thanks for the understanding.


On Fri, Mar 9, 2018 at 7:42 AM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> Final warning, these branches will be deleted today 17:00 (UTC-03:00). If
> you disagree, please do so before the deadline.
>
>
>
> On Wed, Feb 28, 2018 at 8:53 AM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
> >
> > Following the protocol defined in [1], this is the notice email
> regarding the removal of "4.6.*-RC*" branches from Apache CloudStack
> official repository. The Jira ticket for the branches removal is
> https://issues.apache.org/jira/browse/CLOUDSTACK-10313. The branches that
> will be removed are the following:
> >
> > 4.6.0-RC20151104T1522
> > 4.6.0-RC20151110T1545
> > 4.6.1-RC20151130T2246
> > 4.6.1-RC20151130T2258
> > 4.6.2-RC20151213T1914
> > 4.6.2.1-RC20160525T1218
> >
> >
> > If you have objections, please do share your concerns before the
> deletion. The removal will happen on 09/March/2018.
> >
> > [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/
> Clean+up+old+and+obsolete+branches+protocol
> >
> > --
> > Rafael Weingärtner
>
>
>
>
> --
> Rafael Weingärtner
>



-- 
Rafael Weingärtner

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Marc-Aurèle Brothier]

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/cloudstack/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 
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/articles/setting-guidelines-
> for-repository-contributors/
>
>
> - Rohit
>
> 
>
>
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>

Cloudstack collab conference 2018

[Giles Sirett]

All
I've been speaking with Rich Bowen about the feasibility of holding another 
Cloudstack Collaboration Conference in conjunction with Apachecon

https://www.apachecon.com/acna18/schedule.html
Apachecon is 24-27 September, Montreal


Rich has said that we can have a room for Monday 24th  + one other day (I'm, 
hoping that would be Tuesday) , so CCC could be 24-25 September

We could probably squeeze in 20 talks across the 2 days and would look to bolt 
on a hackathon at the end on Wednesday 26th (if Apachecon isn't able to 
accommodate the hackathon, we do know a friendly company in Montreal who *may* 
be able to host that)

WE NEED TO MOVE QUICKLY: The CFP for apachecon is already open and closes March 
30
So, I'd like to get a broad feeling here of support to do this


Theres not much needed to make this happen:

  1.  Confirm with Rich that we want to do this
  2.  Get http://cloudstackcollab.org/ updated - volunteers needed
  3.  Point our community at the exisiting CFP  - and then help on the 
submissions process - volunteers needed
  4.  Promote, etc


Kind regards
Giles


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

[DISCUSS] Relax strict requirement of JIRA ID for PRs

[Rohit Yadav]

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/articles/setting-guidelines-for-repository-contributors/


- Rohit





rohit.ya...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue