cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <rohit.ya...@shapeblue.com>
Subject Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs
Date Mon, 26 Mar 2018 06:34:40 GMT
All, I've started a voting thread for the proposal.


Please do vote and share any thoughts, questions that we've not already discussed. Thanks.


- Rohit

<https://cloudstack.apache.org>



________________________________
From: Rohit Yadav <rohit.yadav@shapeblue.com>
Sent: Friday, March 23, 2018 6:54:55 PM
To: dev@cloudstack.apache.org
Cc: users@cloudstack.apache.org
Subject: Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

Thanks all for your feedback. Since it's been positive so far, I'll start a vote on Monday
to formalize this.

In the meanwhile, please keep sharing your feedback and opinion. Thanks (and happy weekends).


- Rohit

<https://cloudstack.apache.org>



________________________________
From: Syed Ahmed <sahmed@cloudops.com>
Sent: Thursday, March 22, 2018 12:51:01 AM
To: dev@cloudstack.apache.org
Cc: users@cloudstack.apache.org
Subject: Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

+1 To Rohit’s suggestion
On Wed, Mar 21, 2018 at 11:35 AM Khosrow Moossavi <kmoossavi@cloudops.com>
wrote:

> Thanks Rohit, that's a really great sum-up of proposition!
>
> According to the private issue topic, as far as I understand, we don't have
> any private issue per se, unless they are security, vulnerability
> or CVE related and the process of reporting them -being really private
> until they are fixed- are well-defined. So I would say the mentioned
> security@ ML and have an interim ticket in Jira or the ML itself works and
> when the fix is out, for sake of archive, the issue can be created
> in GH and set as closed right away.
>
>
>
> On Wed, Mar 21, 2018 at 6:38 AM, Rafael Weingärtner <
> rafaelweingartner@gmail.com> wrote:
>
> > I think that works as well. Let's see what others think about it.
> >
> > On Wed, Mar 21, 2018 at 4:15 AM, Rohit Yadav <rohit.yadav@shapeblue.com>
> > wrote:
> >
> > > Thanks Rafael for your inputs. You're right about access control
> > > limitation on Github.
> > >
> > >
> > > However, I think having another repository to track security stuff can
> > add
> > > overhead (and to manage its custom ACLs with INFRA, as all cloudstack*
> > > repos are allowed access to all PMC/committers now).
> > >
> > >
> > > Users are advised to report security issues on security@, so how about
> > we
> > > continue to use JIRA for security issues (logging, tracking, and
> > > discussions) and limit the proposed change to just moving to Github
> > issues
> > > as a first step?
> > >
> > >
> > > - Rohit
> > >
> > > <https://cloudstack.apache.org>
> > >
> > >
> > >
> > > ________________________________
> > > From: Rafael Weingärtner <rafaelweingartner@gmail.com>
> > > Sent: Tuesday, March 20, 2018 11:46:32 PM
> > > To: dev
> > > Cc: users@cloudstack.apache.org
> > > Subject: Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs
> > >
> > > It looks like you have done all of the homework here. If it comes to a
> > > vote, I am +1 on migrating issues to Github, and even the Wiki in the
> > > future.  The Github would be able to pretty much provide everything
> that
> > we
> > > have in both Wiki and Jira. Therefore, it feels better to work on a
> > single
> > > platform than to spread information across them. However, we still have
> > one
> > > problem. The security issues/tickets in Jira. How can we manage them in
> > > Github? As far as I know, there is no way to control the access to
> > certain
> > > issues/tickets in Github.
> > >
> > > To tackle that problem with security issues we could open a ticket with
> > > Github; and in the meantime, we could set up a private repository in
> the
> > > Apache organization to hold the security issues (e.g.
> > cloudstack-security).
> > >
> > >
> > > Thanks Rohit.
> > >
> > >
> > >
> > > On Mon, Mar 19, 2018 at 7:58 AM, Rohit Yadav <
> rohit.yadav@shapeblue.com>
> > > wrote:
> > >
> > > > (I've cc-ed user ML to gather feedback from users for this email as
> > > well.)
> > > > All,
> > > > Thank you for your feedbacks, discussions, and suggestions. I have
> > tried
> > > > to take on board all the feedback from the discussion and I propose
> the
> > > > following:
> > > > # Problem
> > > > Let me summarize the problems we're facing and propose some solution
> > > > (which may require voting) in the next section:
> > > > - Search:
> > > > The source of truth is in the git repository (Github or asf mirror),
> > > > however, our issue tracking and wiki systems are different. Therefore
> > any
> > > > task requires us to move back and forth between these various
> > > > portals/systems. As an example - a contributor trying to find whether
> > an
> > > > issue was fixed, requires them to search both JIRA, Github for pull
> > > > requests or commits (and sometimes the release notes and MLs).
> > > > - Audience/Platform:
> > > > From an audience's perspective, the user ML and JIRA issue are for
> > users
> > > > to be able to reach the community and seek help with a bug or
> request a
> > > new
> > > > feature.
> > > > The dev ML, and github PR are ways that developers usually use to
> > > > fix/address an issue or develop a new feature, and get them accepted
> > > > towards a release.
> > > > CWiki is used by both to track articles, documentation and FSs, the
> > docs
> > > > website hosts docs for install/admin/release notes is user-facing.
> Both
> > > > JIRA and Confluence are slow compared to Github. The docs website is
> a
> > > > static website and is fast.
> > > > - Relationship and discovery:
> > > > Historically, the main reason for having a JIRA id with a PR/commit
> is
> > to
> > > > be able to track changes for an open bug and gather such a list in
> the
> > > > release notes. It also helps with cross-searching of a PR against a
> > JIRA
> > > > ticket and searching a JIRA id for possible discussion from an
> accepted
> > > PR.
> > > > A git commit (for example on github) can also help by telling us
> which
> > > tags
> > > > or branches the commit was included in, so helps in knowing which
> > version
> > > > of ACS will have that in.
> > > >  - Behaviours:
> > > > With the current strict requirement of JIRA ids for each PR, we see
> > these
> > > > behaviours:
> > > > (a) many times the author may not engage after sending the PR and may
> > not
> > > > add a JIRA id causing that PR to get blocked indefinitely,
> > > > (b) the author would create a JIRA id just for the sake of it with
> > > minimal
> > > > description and not filling all available fields such as affects
> and/or
> > > fix
> > > > version.
> > > > After a PR is accepted the JIRA ticket may not be properly
> > > closed/resolved
> > > > to leave us with several open tickets which are in fact close-able.
> > > > - Pollution:
> > > > Due to JIRA-caused behaviours 'administrative' changes such as
> changing
> > > of
> > > > versions, addition of upgrade paths after a version is cut, changes
> to
> > > > update the iso url, dependency version in pom.xml etc end up creating
> > > '00s
> > > > of new JIRA ticket. We're already in our 10k numbers. At this point
> in
> > > time
> > > > it is not likely that all these tickets will be addressed, the
> workload
> > > > involved would simply not make this feasible.
> > > > # Let's discuss Solutions
> > > > Let me acknowledge here that enforcing any process in the community
> is
> > a
> > > > challenge and to some extent not possible in a community of
> > contributors
> > > > doing work in their *free time*. In an ideal world, I understand we
> > would
> > > > want all procedures to be followed (as some of mentioned in favour of
> > > that)
> > > > but practically if there are other ways to fix our problems and
> reduce
> > > > red-tape we should explore that. Let me propose a comprehensive
> > solution
> > > > and request your feedback and thoughts:
> > > > - Search:
> > > > We've all organically made great progress with higher cadence after
> > > > switching to a Github based contribution workflow. I hope nobody
> > > disagrees
> > > > how easy it is now to contribute and review, compared to what we did
> in
> > > > past with "reviewboard". With the final/ultimate source of truth
> stored
> > > in
> > > > the git repository, it only make sense to stick to one platform that
> is
> > > > easier to use. Github, I think, is usually faster than both ASF jira
> > and
> > > > cwiki.
> > > > - Audience/Platform:
> > > > Based on a query with ASF INFRA, I was adivsed that a project can use
> > all
> > > > the features of Github (see https://issues.apache.org/
> > > > jira/browse/INFRA-16186). I also checked and confirmed that any
> changes
> > > > to Github repo goes to the commits ML.
> > > > I propose we stick with Github and for starters explore using the
> > 'github
> > > > issues' for issue tracking. We may explore wiki and projects in
> future
> > > (or
> > > > on an experimental basis). Having both issues and pull
> > requests/reviewing
> > > > on the same platform will make it easier for both users and
> developers
> > to
> > > > use one platform for searching, logging, and use.
> > > > I propose to limit our scope of changes and start with Github issues
> > > > first. A discussion of moving away from cwiki can be held in future.
> > > > Historical data in existing systems will be kept for reference, but
> may
> > > be
> > > > deprecated in the future. The legacy systems can avoid taking new
> > > > additions, and all users and developers encouraged to use the Github
> > > > equivalents
> > > > - Discovery and relationships:
> > > > As experimented with 4.11.0.0, we can use Github milestone (that are
> > > > basically CloudStack versions) to track PRs that should go towards a
> > > > release. Github project boards may also be used to track and triage
> > > > issues/pull-requests towards a release which especially RMs and
> co-RMs
> > > can
> > > > use.
> > > > Users would create an issue in Github, against which a developer can
> > > > create a PR. If a developer has identified an issue for which an
> > > > issue-ticket does not exist, they can choose to send a PR directly
> with
> > > all
> > > > the details and descriptions logged on the PR description. Both
> Github
> > > > issues and pull requests can be linked to a milestone, project, some
> > > > labels, and assignees.
> > > > I think this approach to the process will reduce a lot of overheads,
> > > > reduce duplication of description, reduce splitting of information
> > across
> > > > different information systems. List of changes can be simply related
> > via
> > > > milestones and release notes can be easily created using the
> milestone.
> > > > - Behaviours:
> > > > We will no longer need to create JIRA ids as a strict requirement. A
> > > great
> > > > deal of work in managing two disconnected portals will be resolved,
> > this
> > > > will also reduce overhead.
> > > > A user can log a Github issue. A developer may send a PR against a
> > logged
> > > > Github issue, or simply just send a PR linked to a milestone (and/or
> > > > project). Using milestones, we can reference what went towards a
> > release,
> > > > the same can be used to easily generate issues/changes list for
> release
> > > > notes.
> > > > Because JIRA are mostly used by users to log issues (or due to the
> > strict
> > > > requirements), usually developers may not follow it regularly and try
> > to
> > > > fix issues. Github is easy and faster, and having an issues tab
> (with a
> > > > count of outstanding issues) can cause more developers to participate
> > in
> > > > discussions for an open bug (like they do on pull requests). By
> having
> > > > issues tracked through Github, users may get more attention from
> > > developers.
> > > > Keep same merge guideline:
> > > > With the proposed changes, each PR will still require at least two
> > > > non-author reviews/LGTMs and regression test result OK to get them
> > > > accepted. So, any confusion (whether additional information,
> JIRA/Issue
> > > IDs
> > > > are needed) can be left at the discretion of non-PR authors. A pull
> > > request
> > > > template has been recently proposed and accepted for both 4.11 and
> > master
> > > > branches that will standardize how pull requests are reviewed/sent.
> > > > # Next Steps?
> > > > We discuss and rectify the proposal ^^ and if we're positive we can
> > vote
> > > > and ask the INFRA team to enable issues (and wikis) for cloudstack-*
> > > repos
> > > > on github.
> > > > Like we did with reviewboard, we can switch to Github issues over
> time
> > > and
> > > > stop using JIRA/issues while keeping the system accessible for legacy
> > > > referencing etc. We can update the project website around
> contribution,
> > > and
> > > > fix the CONTRIBUTING.md in the repository, and update the release
> > process
> > > > and related articles on cwiki.
> > > > Thoughts, feedback? Thanks.
> > > > - Rohit
> > > >
> > > > <https://cloudstack.apache.org>
> > > >
> > > >
> > > >
> > > > ________________________________
> > > >
> > > > rohit.yadav@shapeblue.com
> > > > www.shapeblue.com<http://www.shapeblue.com>
> > > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > > > @shapeblue
> > > >
> > > >
> > > >
> > > > From: Rohit Yadav
> > > > Sent: Tuesday, March 13, 2018 2:27:29 PM
> > > > To: dev@cloudstack.apache.org
> > > > Subject: [DISCUSS] Relax strict requirement of JIRA ID for PRs
> > > >
> > > >
> > > > 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
> > > >
> > > > <https://cloudstack.apache.org>
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Rafael Weingärtner
> > >
> > > rohit.yadav@shapeblue.com
> > > www.shapeblue.com<http://www.shapeblue.com>
> > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > > @shapeblue
> > >
> > >
> > >
> > >
> >
> >
> > --
> > Rafael Weingärtner
> >
>

rohit.yadav@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue




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


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