github project boards can span multiple repos
https://help.github.com/en/github/managing-your-work-on-github/about-project-boards
On Wed, Jan 15, 2020 at 12:09 AM Gregory Nutt wrote:
>
> > The Mynewt project, for example, has many repositories. I can
> > find the page but I recall that i
The Mynewt project, for example, has many repositories. I can
find the page but I recall that it is on the order of a dozen or so
repositories. ...
17
See https://gitbox.apache.org/repos/asf
Part of the issues to consider is that If you use GitHub issues, having
multiple repos you may need to enable issues in multiple places. This means
more to manage and track. Having all issues for multiple repos on a single
github repo also has issues.
There would certainly be some scalabil
My understanding is that most patch will come via the mailing list anyway and
it will be mostly up o the PPMX to create and manage the issues for the users.
That is true. There was one this morning (my time): "SMTP send mail
example build failure"
Hi,
> Why can't we use both JIRA and Github, since they are linked?
The downside would be multiple places to look for issues, They are not closely
linked if you raise an issue in GitHub one doesn’t get raised in JIRA.
My understanding is that most patch will come via the mailing list anyway and
Not apposed to any solution.
However, the argument that people not having access to Github is still
out there.
Why can't we use both JIRA and Github, since they are linked?
On Wed, Jan 15, 2020 at 12:50 AM Gregory Nutt wrote:
>
>
> > Speaking about bugzilla. I know JIRA is linked which is what I
Speaking about bugzilla. I know JIRA is linked which is what I proposed
first, but got heavily pushed against.
I didn't perceive things that way. I recall only Alin having a strong
position to use github issues.
Speaking about bugzilla. I know JIRA is linked which is what I proposed
first, but got heavily pushed against.
On Tue, Jan 14, 2020, 4:43 PM Justin Mclean
wrote:
> Hi,
>
> > I don't believe it has great integration with GitHub (I did not see any
> > mention in infra)
>
> It has some integration
Hi,
> I don't believe it has great integration with GitHub (I did not see any
> mention in infra)
It has some integration e.g. mention a JIRA in a commit message (or PR) and it
automatically get linked up to that JIRA.
At the ASF Infra manages JIRA so that reduces a little of the load in regard
I don't believe it has great integration with GitHub (I did not see any
mention in infra) and when I used it at RedHat it was really heavy and
clunky, and designed to manage all the software under some enterprise
organization. The only thing I think it has going for it is that it's
opensource unlik
On Tue, Jan 14, 2020 at 7:17 PM Gregory Nutt wrote:
> Most pull-back from Jira would be, I think, because it is a heavyweight
> solution (but also does much more than just track issues).
When you say that Jira is a heavyweight solution, do you mean in terms
of the infrastructure required to run i
On Tue, Jan 14, 2020 at 7:17 PM Gregory Nutt wrote:
> The implication is the you would be opposed to Bugzilla. Bugzilla is
> more primitive but is has the advantage of being lightweight and fast.
> Most pull-back from Jira would be, I think, because it is a heavyweight
> solution (but also does mu
Can people also respond on the Projects feature of GitHub?
I imagined it would be used for thinks like new ports, releases, and large
features. Most of these would have tasks spanning two repos.
Take crypto. There is an OS interface component, at least a demo app, and
likely a configuration to be
I am fine with either of the following two options (not in any order of
preference):
(1) GitHub issues with separate issues for each repository, i.e., issues
with "apps" are reported against "apps," *not* against NuttX.
Pros: Convenience and widespread familiarity across the FOSS world.
On Tue, Jan 14, 2020 at 6:32 PM Justin Mclean
wrote:
> Hi,
>
> Part of the issues to consider is that If you use GitHub issues, having
> multiple repos you may need to enable issues in multiple places. This means
> more to manage and track. Having all issues for multiple repos on a single
> githu
Part of the issues to consider is that If you use GitHub issues, having
multiple repos you may need to enable issues in multiple places. This means
more to manage and track. Having all issues for multiple repos on a single
github repo also has issues.
I don’t think there’s an ideal solution
Hi,
Part of the issues to consider is that If you use GitHub issues, having
multiple repos you may need to enable issues in multiple places. This means
more to manage and track. Having all issues for multiple repos on a single
github repo also has issues.
I don’t think there’s an ideal solutio
Hi,
You don’t need an apache account to raise either a GitHub issue or a JIRA
issues.
> In that reference web page, there is also something called the Contributor's
> role that has almost as many privileges as a committer does. I am not
> exactly sure what a Contributor role is. I suppose it
But, I think that the user who hasn't an apache account can't create
an issue in JIRA.
I don't think that is true, is it? I think it is role-based:
https://cwiki.apache.org/confluence/display/INFRA/Role+Based+JIRA+Authorization
It looks like any registered user (even non-committers) can
But, I think that the user who hasn't an apache account can't create
an issue in JIRA.
I don't think that is true, is it? I think it is role-based:
https://cwiki.apache.org/confluence/display/INFRA/Role+Based+JIRA+Authorization
It looks like any registered user (even non-committers) can cr
But, I think that the user who hasn't an apache account can't create
an issue in JIRA.
On Sun, Jan 5, 2020 at 10:51 AM Gregory Nutt wrote:
>
>
> >>> Maybe people should not file a bug for hardware-specific issues that
> >>> affect only their specific configuration. As you point out, it is
> >>> u
Maybe people should not file a bug for hardware-specific issues that
affect only their specific configuration. As you point out, it is
unlikely that anyone else will be able to fix or test such an issue.
So, for those cases, maybe we should encourage people not to file an
issue but rather to fi
On Fri, Jan 3, 2020 at 4:50 PM Gregory Nutt wrote:
>
> > Maybe people should not file a bug for hardware-specific issues that
> > affect only their specific configuration. As you point out, it is
> > unlikely that anyone else will be able to fix or test such an issue.
> > So, for those cases, may
Maybe people should not file a bug for hardware-specific issues that
affect only their specific configuration. As you point out, it is
unlikely that anyone else will be able to fix or test such an issue.
So, for those cases, maybe we should encourage people not to file an
issue but rather to fi
Hi Nathan,
On 1/3/20, Nathan Hartman wrote:
> On Fri, Jan 3, 2020 at 4:01 PM Justin Mclean
> wrote:
>> >> Re which tool to use, which one are your users likely to use. From
>> >> previous discussion I don’t think many would have used git issues, but
>> >> I’m not sure than many would be familiar
On Fri, Jan 3, 2020 at 4:01 PM Justin Mclean wrote:
> >> Re which tool to use, which one are your users likely to use. From
> >> previous discussion I don’t think many would have used git issues, but I’m
> >> not sure than many would be familiar with JIRA.
> >
> > The majority problem reports ..
HI,
>> Re which tool to use, which one are your users likely to use. From previous
>> discussion I don’t think many would have used git issues, but I’m not sure
>> than many would be familiar with JIRA.
>
> The majority problem reports .. well over 90% ... are recieved via email.
> Sometimes
With many people on the PPMC taking responsibility for any issues that come in
I don’t see that they would be ignored, unless the PPMC is not acting as a
PPMC. Other committers and contributors can alas help out and that’s one way
you grow your community and get more committers / PPMC membe
Hi,
> When you say that all the issue tracker(s) were ignored (and
> eventually lost anyway), that indicates a deeper problem than just
> choosing an issue tracking software.
With many people on the PPMC taking responsibility for any issues that come in
I don’t see that they would be ignored, un
When you say that all the issue tracker(s) were ignored (and
eventually lost anyway), that indicates a deeper problem than just
choosing an issue tracking software.
Issues will be ignored if there is no process to management them.
I think we need to first and foremost get input from our mento
On Fri, Jan 3, 2020 at 9:45 AM Gregory Nutt wrote:
> > The primary place that I keep issue is in the TODO list file in the
> > nuttx/ top-level directory. That used to be a simple way for me to
> > keep track of issues and has travel from CVS on SourceForge, to GIT on
> > sourceforge, to Bitbucke
The primary place that I keep issue is in the TODO list file in the
nuttx/ top-level directory. That used to be a simple way for me to
keep track of issues and has travel from CVS on SourceForge, to GIT on
sourceforge, to Bitbucket (all issues were lost on each transition).
It was simple b
32 matches
Mail list logo
