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 bu
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 ot
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/clouds
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, Ra
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
th
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:
>
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, Lon
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).
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
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 w
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
@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", w
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 fashi
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
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 n
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 foundat
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 g
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 (
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
collab
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
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
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 c
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
23 matches
Mail list logo
