cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Khosrow Moossavi <kmooss...@cloudops.com>
Subject Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs
Date Wed, 21 Mar 2018 15:35:11 GMT
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
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > @shapeblue
> >
> >
> >
> >
>
>
> --
> Rafael Weingärtner
>

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