On Mon, Jun 21, 2021 at 3:53 PM Chris Lattner via cfe-dev <
cfe-...@lists.llvm.org> wrote:
> On Jun 9, 2021, at 10:50 AM, Philip Reames via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
> Specific to the dev lists, I'm very hesitant about moving from mailing
> lists to discourse. Why?
>
> Well,
On Thu, Jun 3, 2021 at 6:19 PM James Y Knight wrote:
> I've just tried out discourse for the first time. It is not clear to me
> how to use it to replace mailing lists. It has a setting "mailing list
> mode", which sounds like the right thing -- sending all messages via email.
> Except that optio
On Sat, Jun 5, 2021, 1:19 AM Mehdi AMINI wrote:
>
>
> On Thu, Jun 3, 2021 at 3:20 PM James Y Knight via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
>> I've just tried out discourse for the first time. It is not clear to me
>> how to use it to replace mailing lists. It has a setting "mailing li
I've just tried out discourse for the first time. It is not clear to me how
to use it to replace mailing lists. It has a setting "mailing list mode",
which sounds like the right thing -- sending all messages via email. Except
that option is global -- all messages in all categories on the llvm
disco
Custom prefixes are intended for autolinks to external systems -- I suspect
it would not work properly (but have not tested) if you used it to refer
back to github itself. E.g. putting reverse links in issues you refer to,
or closing an issue when writing "closes CUSTOM-123" in a commit message.
O
GitHub canonically uses "#NNN" to refer to its bugs or pull requests, and
also supports "GH-NNN". We'll want to switch to one of those schemes, so
that automatic linking works properly. So, in that case, PR1234 == legacy
issue, #1234 or GH-1234 == new issue.
(See
https://help.github.com/en/github/
In a previous discussion, one other suggestion had been to migrate all the
bugzilla bugs to a separate initially-private "bug archive" repository in
github. This has a few benefits:
1. If the migration is messed up, the repo can be deleted, and the process
run again, until we get a result we like.
I think we ought to setup some sort of organized scheme for volunteers to
do triage of incoming issues, to make sure they've got enough actionable
info, and direct to the correct people as needed.
(This would actually be a really nice thing to have, regardless of which
bugtracking system we have.)
On Thu, Oct 10, 2019 at 4:15 PM Jordan Rupprecht via llvm-dev <
llvm-...@lists.llvm.org> wrote:
>
>
> On Thu, Oct 10, 2019 at 12:29 PM Tom Stellard via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
>> On 10/10/2019 11:40 AM, Mehdi AMINI wrote:
>> >
>> >
>> > On Thu, Oct 10, 2019 at 10:59 AM Tom S
On Fri, Jul 12, 2019 at 10:35 AM Sam Elliott via llvm-dev <
llvm-...@lists.llvm.org> wrote:
> Tom
>
> I attempted to use `git llvm push` with the test-suite repository (which
> isn’t moving to the monorepo) and it didn’t work. I presume this was
> expected
Sorry about that -- it should work now,
Then we should not accept it. What if someone did the same on a phabricator
review?
On Wed, Mar 20, 2019 at 2:39 AM Anton Korobeynikov
wrote:
> > Github PRs are how everyone who is not already super-involved in the
> llvm project is going to want to contribute changes, and we ought to be as
> we
I think we definitely will want to support github PRs, at the very least as
an _option_, even if we continue running/preferring phabricator.
Github PRs are how everyone who is not already super-involved in the llvm
project is going to want to contribute changes, and we ought to be as
welcoming as
The new official monorepo is published to LLVM's github organization, at:
https://github.com/llvm/llvm-project.
At this point, the repository should be considered stable -- there won't be
any more rewrites which invalidate commit hashes (barring some _REALLY_
good reason...).
The import process i
It'd be nice to know what about our repository is breaking it. Do they have
any idea what that is?
For example -- I think that we probably will want to archive+discard many
of the random branches and tags currently in the repository. If the large
number of branches and tags is breaking it, then ma
At this point, Tuesday is definitely not going to happen. I'll recreate the
prototype tomorrow to fix the issue you discovered, and aim for Thursday to
make it final unless more changes are needed.
But yes, the goal is to, very soon, declare the conversion is "final",
publish it at the official ur
I don't think we should do any of that. It's too complicated -- and I don't
see the reason to even do it.
There's a need for the "llvm-project" repository -- that's been discussed
plenty -- but where does the need for a separate "id" that must be pushed
into all of the sub-projects come from? This
On Mon, Jun 27, 2016 at 12:13 PM, Renato Golin via llvm-dev <
llvm-...@lists.llvm.org> wrote:
> On 27 June 2016 at 17:03, Rafael Espíndola
> wrote:
> > I think that trying to create a ordering/rev number between independent
> git
> > repositories is fundamentally unreliable.
> >
> > If we want to
Two problems:
1) Submodules have some UX problems for developers around updating the
parent project and its effects on the submodule which make them annoying to
use.
2) I find the advantage you claim especially scary and bad. Put another
way: if a developer *doesn't* make a commit to clang with the
+1 to that. I would strongly suggest that we continue to commit to master
first, like we've always done in llvm.
On Jun 6, 2016 11:44 AM, "Joerg Sonnenberger via cfe-dev" <
cfe-...@lists.llvm.org> wrote:
> On Mon, Jun 06, 2016 at 10:32:45AM -0500, via llvm-dev wrote:
> > My only hesitation with t
We could also think about using gerrit in the future to manage code reviews
and commits into the repository. (perhaps via the gerrithub.io hosted
platform, which also has github integration, including the ability to deal
with pull requests).
Gerrit already has pretty good support for cross-reposit
IMO, if we're switching to git, we should just be clear up front that all
committers will be expected to switch to git as well -- or at least, if
they want to use something else (e.g. mercurial's git bridge/etc), that
it's their own problem.
It is truly NOT that big an imposition to require the us
21 matches
Mail list logo
